[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNU-traductores] gnudist:/home/www/html/server/standards/README.savanna
|
From: |
gnudist's file diff daemon |
|
Subject: |
[GNU-traductores] gnudist:/home/www/html/server/standards/README.savannah.html -- New file |
|
Date: |
Mon, 26 Feb 2001 05:11:05 -0800 (PST) |
This is an automated report from gnudist.
This appears to be a new file or has only recently been added to
the list of monitored files:
33 -rw-rw-r-- 1 webcvs www 32470 Feb 26 03:11
/home/www/html/server/standards/README.savannah.html
Contents:
<html lang="en"><head>
<title>`Savannah'</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name=description content="`Savannah'">
<meta name=generator content="makeinfo 4.0">
<link href="http://texinfo.org/"; rel=generator-home>
</head><body>
<p><hr>
Node:<a name="Top">Top</a>,
Next:<a rel=next href="#Introduction">Introduction</a>,
Previous:<a rel=previous href="#(dir)">(dir)</a>,
Up:<a rel=up href="#(dir)">(dir)</a>
<br>
<h1>Savannah</h1>
<p>This document is for Savannah administrators, not Savannah users.
<a href="http://savannah.gnu.org/";>Savannah</a> is a <a
href="http://www.sourceforge.net";>SourceForge</a>
clone based on the
<a
href="http://download.sourceforge.net/alexandria/SF2_0.tar.gz";>SourceForge-2.0</a>
software. It is dedicated the GNU projects.
<p>Because of the highly specific
nature of the software, Savannah is a fork of the SourceForge-2.0 software.
Attempting to make it modular and configurable is a waste of time.
The whole Savannah software is <a
href="http://savannah.gnu.org/cvs/?group_id=11";>available from CVS</a> and is
managed by the <a
href="http://savannah.gnu.org/projects/savannah/";>Savannah</a> project. The
ChangeLog explains the modifications made
to the original code.
<ul>
<li><a href="#Introduction">Introduction</a>:
<li><a href="#Installation">Installation</a>:
<li><a href="#CVS%20repositories">CVS repositories</a>:
<li><a href="#Database">Database</a>:
<li><a href="#Mails%20and%20aliases">Mails and aliases</a>:
<li><a href="#Unlock%20alias%20at%20gnu.org%20account">Unlock alias at gnu.org
account</a>:
<li><a href="#Migration">Migration</a>:
<li><a href="#Users%20and%20CVS%20synchronization">Users and CVS
synchronization</a>:
<li><a href="#Publishing%20this%20document">Publishing this document</a>:
<li><a href="#System%20Administration">System Administration</a>:
<li><a href="#Concept%20Index">Concept Index</a>:
<p>--- The Detailed Node Listing ---
<p>CVS respositories
</p><li><a href="#Sources%20CVS%20repositories">Sources CVS repositories</a>:
<li><a href="#Web%20CVS%20repositories">Web CVS repositories</a>:
<li><a href="#Projects%20and%20Web%20CVS">Projects and Web CVS</a>:
<p>Database
</p><li><a href="#Skill%20List">Skill List</a>:
<p>System Administration
</p><li><a href="#SSL%20certificate">SSL certificate</a>:
<li><a href="#Savannah%20crontab">Savannah crontab</a>:
<li><a href="#Savannah%20software%20root">Savannah software root</a>:
<li><a href="#NGROUPS_MAX">NGROUPS_MAX</a>:
</ul>
<p><hr>
Node:<a name="Introduction">Introduction</a>,
Next:<a rel=next href="#Installation">Installation</a>,
Previous:<a rel=previous href="#Top">Top</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Introduction</h1>
<p>Savannah currently provides the CVS frontend. Check the <a
href="http://savannah.gnu.org/pm/task.php?group_project_id=1&group_id=11&func=browse";>Task
List</a> for details on planned developments.
<p>Setting up Savannah is not an easy task because it has to integrate existing
habits and projects without breaking anything. However, the <a
href="http://www.zoy.org/~guillaum/SF/";>SourceForge Installation Guide</a> by
<a href="mailto:address@hidden";>Guillaume Morin</a> helps a lot
understanding the software.
<p><hr>
Node:<a name="Installation">Installation</a>,
Next:<a rel=next href="#CVS%20repositories">CVS repositories</a>,
Previous:<a rel=previous href="#Introduction">Introduction</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Installation</h1>
<p>Savannah is installed on the machine subversions.gnu.org. The root
of the installation is in /subversions/sourceforge. All the software
that is not system wide and is needed to run Savannah is installed in
this directory. The structure of this directory is similar to FHS-2.1.
In the following table the path names are relative to the installation
root. All directories covered by the <a
href="http://www.zoy.org/~guillaum/SF/";>SourceForge Installation Guide</a> are
omitted.
<dl>
<br><dt><code>tmp</code>
<dd>Directory to run the backend scripts.
<br><dt><code>src/savannah</code>
<dd>The SourceForge software and the <a
href="http://savannah.gnu.org/";>Savannah</a>
web pages.
<br><dt><code>src/savannah/www</code>
<dd>The document root of <a href="http://savannah.gnu.org/";>Savannah</a>
web pages.
<br><dt><code>src/savannah/gnuscripts</code>
<dd>Savannah specific backend scripts.
</dl>
<p>The whole Savannah software is <a
href="http://savannah.gnu.org/cvs/?group_id=11";>available from CVS</a> and is
managed by the <a
href="http://savannah.gnu.org/projects/savannah/";>Savannah</a> project.
<p>In order to install changes commmited in the savannah project CVS tree,
proceed as follows:
<pre>login subversions
su -
export CVS_RSH=ssh
cd /subversions/sourceforge/src/savannah
cvs -q update
</pre>
<p><hr>
Node:<a name="CVS%20repositories">CVS repositories</a>,
Next:<a rel=next href="#Database">Database</a>,
Previous:<a rel=previous href="#Installation">Installation</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>CVS respositories</h1>
<p>For each project registered on Savannah there may be two CVS repositories.
One to store the sources of the project and one to store the web of the
project. The sources repository is in /subversions/cvs/software and the
web repository is in /subversions/cvs/gnuweb. The /webcvs symbolic link
points to /subversions/cvs/gnuweb and the /cvsroot symbolic link points to
/subversions/cvs/software.
<ul>
<li><a href="#Sources%20CVS%20repositories">Sources CVS repositories</a>:
<li><a href="#Web%20CVS%20repositories">Web CVS repositories</a>:
<li><a href="#Projects%20and%20Web%20CVS">Projects and Web CVS</a>:
</ul>
<p><hr>
Node:<a name="Sources%20CVS%20repositories">Sources CVS repositories</a>,
Next:<a rel=next href="#Web%20CVS%20repositories">Web CVS repositories</a>,
Previous:<a rel=previous href="#CVS%20repositories">CVS repositories</a>,
Up:<a rel=up href="#CVS%20repositories">CVS repositories</a>
<br>
<h2>Sources CVS respositories</h2>
<p>When a project has a license that is not <code>website</code> a source
repository is created under /subversions/cvs/software/project with
a private CVSROOT that only contains anoncvs. The developers of the
project have access to the CVSROOT directory.
<p>The group <code>project</code> is created to grant write access to the
repository
to all the members of the project.
<p>It allows them to add commit notification by doing the following,
replacing <code>project</code> with the name of their project:
<pre>cvs -d subversions.gnu.org:/cvsroot/project co CVSROOT
In CVSROOT/commitinfo
^project /usr/local/bin/commit_prep -T project -r
In CVSROOT/loginfo
^project /usr/local/bin/log_accum -T project -C -m address@hidden -s %{sVv}
</pre>
<p>The email address must exist, it will not be automatically generated.
<p>For compatibility with the cvs setup before Savannah was introduced,
/subversions/cvs/common contains repositories that existed before Savannah.
When a project is registered in Savannah, a symbolic link is created
(/subversions/cvs/software/project/project) that points to the already
existing /subversions/cvs/common/project directory.
<p>The /cvs symbolic link points to /subversions/cvs/common so that people
already using it to access their repositories can continue to do so. Before
Savannah existed a pserver access was available and Savannah continues to
maintain it for these projects, updating the CVSROOT/passwd files with
user/password pairs that are in the Savannah database.
<p><hr>
Node:<a name="Web%20CVS%20repositories">Web CVS repositories</a>,
Next:<a rel=next href="#Projects%20and%20Web%20CVS">Projects and Web CVS</a>,
Previous:<a rel=previous href="#Sources%20CVS%20repositories">Sources CVS
repositories</a>,
Up:<a rel=up href="#CVS%20repositories">CVS repositories</a>
<br>
<h2>Web CVS respositories</h2>
<p>When a project has an <code>html_cvs</code> field that is not empty in the
<code>group</code> table, a web repository is created in
/subversions/cvs/gnuweb/<code>html_cvs</code>. By default the
<code>html_cvs</code>
field has the value <code>/software/project/</code> but it may be edited with
the savannah.gnu.org/admin/. See the gnujobs, greve and bravegw projects
for examples.
<p>The group <code>webproject</code> is created to grant write access to the
repository
to all the members of the project.
<p>The /subversions/cvs/gnuweb/CVSROOT/loginfo file contains triggers that
update the gnudist.gnu.org:/home/www/html directory whenever a commit
is done. There is a single CVSROOT for all the projects that have a
web repository.
<p>All the www.gnu.org web was imported in /subversions/cvs/gnuweb.
When a project is registered on Savannah and there already exists
a directory for it in the repository (either .../software/project or
the value of the <code>html_cvs</code> field), a chgrp -R webproject is done
on this repository to grant the members of the project a write access
to this portion of the web repository and only this one.
<p>The <code>www</code> project in Savannah is treated in a special way. All the
members of the <code>www</code> project have access to the whole repository
in /webcvs. It means that they are always included in every
<code>webproject</code>
created.
<p><hr>
Node:<a name="Projects%20and%20Web%20CVS">Projects and Web CVS</a>,
Previous:<a rel=previous href="#Web%20CVS%20repositories">Web CVS
repositories</a>,
Up:<a rel=up href="#CVS%20repositories">CVS repositories</a>
<br>
<h2>Projects and Web CVS</h2>
<p>The special project <code>www</code> have write access to all the /webcvs
repository. It is possible to create projects that will limit write
access of the members of the project to a subdirectory of the /webcvs
repository only. For instance the <code>bravegw</code> Savannah project only
give write access to the /webcvs/brave-gnu-world part of the repository.
<p>A project bound to a specific subdirectory will grante write access to
all the tree under this subdirectory. There is no way, for instance,
to grant write access to group B to /webcvs/thispart and write access
to group A to /webcvs/thispart/subdir. If you do this group B win and
will have write access to /webcvs/thispart recursively and group A will
have access to nothing. If you see a way to overcome this limitation,
let us know.
<p><hr>
Node:<a name="Database">Database</a>,
Next:<a rel=next href="#Mails%20and%20aliases">Mails and aliases</a>,
Previous:<a rel=previous href="#CVS%20repositories">CVS repositories</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Database</h1>
<p>Savannah uses MySQL and the <code>sourceforge</code> database. The root user
has
a ~/.my.cnf file that defines the user/passwd. It is not necessary to
specify them on the command line.
<ul>
<li><a href="#Skill%20List">Skill List</a>:
</ul>
<p><hr>
Node:<a name="Skill%20List">Skill List</a>,
Previous:<a rel=previous href="#Database">Database</a>,
Up:<a rel=up href="#Database">Database</a>
<br>
<h2>Skill List</h2>
<p>The tables <code>people_skill</code> and <code>people_skill_level</code> are
loaded
from the skill database maintained by CJN (http://cjn.sourceforge.net/).
The script /subversions/sourceforge/src/savannah/gnuscripts/sf_skill
loads the XML skill files from CJN and replace the content of the
tables in the sourceforge database.
<p>If some proprietary software shows on the skill list, add it to the
%ignore table in the sf_skill script and re-run it.
<pre>cd /subversions/sourceforge/src/savannah/gnuscripts
edit sf_skill
sf_skill
cvs commit -m 'Ignore proprietary software xxxx'
</pre>
<p><hr>
Node:<a name="Mails%20and%20aliases">Mails and aliases</a>,
Next:<a rel=next href="#Unlock%20alias%20at%20gnu.org%20account">Unlock alias
at gnu.org account</a>,
Previous:<a rel=previous href="#Database">Database</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Mails and aliases</h1>
<p>Savannah will try to send mail to users under various circumstances (bug
reports notification, account creation etc.). In some cases it will use
the real mail address of the user, in others it will use
address@hidden In order for the address@hidden address
to work properly for outgoing mails, the /etc/aliases file is updated
automatically every 5 minutes with the following command:
<pre>sf_aliases
</pre>
<p>The address@hidden can <code>never</code> be used to recieve mail for
the good reason that savannah.gnu.org does not listen on the SMTP port.
<p><hr>
Node:<a name="Unlock%20alias%20at%20gnu.org%20account">Unlock alias at gnu.org
account</a>,
Next:<a rel=next href="#Migration">Migration</a>,
Previous:<a rel=previous href="#Mails%20and%20aliases">Mails and aliases</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Unlock alias at gnu.org account</h1>
<p>People who have a simple alias address@hidden but no account on Kerberos
cannot create an account on Savannah. When they ask to unlock the
account name on address@hidden, tell them to create an account
using a fake username and to send this username to address@hidden
When receiving that user name substitute the fake login name by the desired
one:
<pre>mysql -e "update user set user_name = 'desired' where user_name = 'fake'"
sourceforge
</pre>
<p><hr>
Node:<a name="Migration">Migration</a>,
Next:<a rel=next href="#Users%20and%20CVS%20synchronization">Users and CVS
synchronization</a>,
Previous:<a rel=previous href="#Unlock%20alias%20at%20gnu.org%20account">Unlock
alias at gnu.org account</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Migration</h1>
<p>Must be root to run this script. You are advised to run it in
/subversions/sourceforge/tmp, although it is not mandatory.
<p>The <code>sf_migrate</code> script creates a Savannah project for an
existing project
in the /subversions/cvs/common directory. It is done in three steps:
<ul>
<li>sf_migrate -add project | mysql sourceforge
<li>sf_migrate -bind project | mysql sourceforge
<li>sf_migrate -mail project
</ul>
<dl>
<dt><code>--add</code>
<dd>Will create the project in Savannah if it does not yet exists.
It will also scan the /etc/passwd and /etc/group files and create
users in Savannah.
<p>When explaining the situation to a user added to Savannah in this
way, one could say it like this. If you have a Kerberos account on
gnu.org, use the same login and password on Savannah and change the
password immediately afterwards: it will not change your Kerberos
password, just the Savannah password. If you only have a pserver
account, use the same login and password on Savannah. If you have
both, use the Kerberos account login and password. If you have none
and access CVS using SSH public keys, ask to address@hidden to
give you a password. This last case requires human interaction to
prevent someone from stealing your account name.
<br><dt><code>--bind</code>
<dd>Will bind the users created to the project. This cannot be done in
one step (-add -bind) because of unique identifiers allocations by
the MySQL database.
<br><dt><code>--mail</code>
<dd>Generate a Emacs-VM formated mail ready to send to all contributors
of the project that explains what has been done.
</dl>
<p>When a user with SSH access thru public key was added by sf_migrate,
she/he will be instructed to ask for a password to address@hidden
The sf_pass script can be used to set her/his password. A mail must be sent
by the user requesting the password with the encrypted password. Instruct
the user to generate the password using the following command:
<pre>perl -e 'print crypt("mypassword",
join "", (".", "/", 0..9, "A".."Z", "a".."z")[rand 64, rand 64])'
</pre>
<p>When the user send the password crypted, set it using:
<pre>sf_pass --set thename cryptpass | mysql sourceforge
</pre>
<p>After 24 hours, check user logged in and lock the user if it is not the
case. This is to prevent obvious holes.
<pre>sf_pass --unset thename | mysql sourceforge
</pre>
<p><hr>
Node:<a name="Users%20and%20CVS%20synchronization">Users and CVS
synchronization</a>,
Next:<a rel=next href="#Publishing%20this%20document">Publishing this
document</a>,
Previous:<a rel=previous href="#Migration">Migration</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Users and CVS synchronization</h1>
<p>Must be root to run this script. Must export CVS_RSH=ssh. You are
advised to run it in /subversions/sourceforge/tmp, although it is not
mandatory.
<p>The <code>sf_cvs</code> script generates a shell script that will synchronize
the system files with the state of the Savannah database (sourceforge).
<p>This script only generates lines if something needs to be done. When
the resulting script is executed, another run <code>must not</code> display
any action, unless the database was modified in the meantime.
<p>It performs the following tasks, in this order.
<dl>
<br><dt><code>Add new projects</code>
<dd>/subversions/cvs/software/project and
/subversions/cvs/gnuweb/software/project
directories are created.
<br><dt><code>Update existing projects</code>
<dd>Fixes projects that do not have a /subversions/cvs/gnuweb/software/project
directory.
<br><dt><code>Add missing users</code>
<dd>Create users that are bound to at least a project in Savannah.
<br><dt><code>Remove users</code>
<dd>Remove users not bound to any project in Savannah
If user belongs to groups not managed by Savannah, just redefine
its group list.
<br><dt><code>Update existing users</code>
<dd>Modify the system files if they are not in sync with the Savannah
database.
<br><dt><code>Update the CVS password file</code>
<dd>Update the /subversions/cvs/CVSROOT/passwd file to reflect the
passwd and users bound to projects in Savannah.
<br><dt><code>Update xinetd.conf</code>
<dd>Update the cvspserver/cvskserver with all possible pserver roots
</dl>
<p><hr>
Node:<a name="Publishing%20this%20document">Publishing this document</a>,
Next:<a rel=next href="#System%20Administration">System Administration</a>,
Previous:<a rel=previous href="#Users%20and%20CVS%20synchronization">Users and
CVS synchronization</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Publishing this document</h1>
<p>The HTML version of this document is published in two places:
<a href="http://savannah.gnu.org/savannah.html";>Savannah Administration
Guide</a>
and
<a href="http://www.gnu.org/server/standards/README.savannah.html";>Savannah
Administration Guide</a>. The source is stored in the subversions.gnu.org:/cvs
co gnudocs repository.
To facilitate the publication process you can edit it in the
subversions.gnu.org:/subversions/sourceforge/src/gnudocs directory and
then issue a
<pre>make publish
</pre>
<p>The <code>publish</code> goal assumes that the Savannah document root is in
../savannah/www and a read-write checkout of the www.gnu.org/server/standards
directory is in ../server/standards. It will format the document to
HTML and commit the changes to the repository.
<p><hr>
Node:<a name="System%20Administration">System Administration</a>,
Next:<a rel=next href="#Concept%20Index">Concept Index</a>,
Previous:<a rel=previous href="#Publishing%20this%20document">Publishing this
document</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>System Administration</h1>
<ul>
<li><a href="#SSL%20certificate">SSL certificate</a>:
<li><a href="#Savannah%20crontab">Savannah crontab</a>:
<li><a href="#Savannah%20software%20root">Savannah software root</a>:
<li><a href="#NGROUPS_MAX">NGROUPS_MAX</a>:
</ul>
<p><hr>
Node:<a name="SSL%20certificate">SSL certificate</a>,
Next:<a rel=next href="#Savannah%20crontab">Savannah crontab</a>,
Previous:<a rel=previous href="#System%20Administration">System
Administration</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>SSL certificate</h2>
<p>The SSL certificate for savannah.gnu.org was generated in /etc/apache-ssl/.
Check the README file for a log of the command. There has been a lot of
discussions regarding the root certificate for GNU, the use of a PKI. At
some point the savannah certificate will be generated using a proper
root certificate.
<p><hr>
Node:<a name="Savannah%20crontab">Savannah crontab</a>,
Next:<a rel=next href="#Savannah%20software%20root">Savannah software root</a>,
Previous:<a rel=previous href="#SSL%20certificate">SSL certificate</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>Savannah crontab</h2>
<p>The Savannah crontab jobs are in /etc/cron.d/savannah. Every cron command
output is sent to address@hidden
<p><hr>
Node:<a name="Savannah%20software%20root">Savannah software root</a>,
Next:<a rel=next href="#NGROUPS_MAX">NGROUPS_MAX</a>,
Previous:<a rel=previous href="#Savannah%20crontab">Savannah crontab</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>Savannah software root</h2>
<p>All software that is not system wide but only used for the purpose of
Savannah must be installed in the prefix /subversions/sourceforge.
<p>The MySQL installation is an exception that must be fixed. It is installed
with the /usr/local/mysql prefix. It was not installed from the debian
package because I (address@hidden) was not able to fix the MySQL-3.23
package to make it work on potato.
<p><hr>
Node:<a name="NGROUPS_MAX">NGROUPS_MAX</a>,
Previous:<a rel=previous href="#Savannah%20software%20root">Savannah software
root</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>NGROUPS_MAX</h2>
<p>The large number of groups a user can have (>32) implies to modify
some basic programs (namely useradd and usermod).
<p>Gordon Matzigkeit <address@hidden> modified
/usr/local/src/cvs-1.10.8/src/server.c to overcome the limit builtin glibc.
He also installed the /boot/vmlinuz-2.2.12-256groups kernel that was
compiled with NGROUPS_MAX set to 256. The system files have not been
reinstalled to match this version.
<p>Here is the patch applied to /usr/local/src/shadow-19990827. The
modified usermod and useradd have been installed in
/subversions/sourceforge/bin.
<pre>*** ./debian/rules.~1~ Fri Feb 9 02:05:06 2001
--- ./debian/rules Fri Feb 9 02:05:41 2001
***************
*** 38,44 ****
ifneq ($(DEB_HOST_GNU_SYSTEM),gnu)
include debian/scripts/login.mk
package-list += binary-login
! config_options += --with-libpam
control_defs += -DMODDEP="(>= 0.72-5)"
endif
--- 38,44 ----
ifneq ($(DEB_HOST_GNU_SYSTEM),gnu)
include debian/scripts/login.mk
package-list += binary-login
! # config_options += --with-libpam
control_defs += -DMODDEP="(>= 0.72-5)"
endif
*** ./build-tree/shadow-19990827/libmisc/addgrps.c.~1~ Mon Dec 28 12:34:41 1998
--- ./build-tree/shadow-19990827/libmisc/addgrps.c Fri Feb 9 03:04:47 2001
***************
*** 20,25 ****
--- 20,28 ----
* already there. Warning: uses strtok().
*/
+ #undef NGROUPS_MAX
+ #define NGROUPS_MAX 256
+
int
add_groups(const char *list)
{
*** ./build-tree/shadow-19990827/src/usermod.c.~1~ Fri Jul 9 09:27:38 1999
--- ./build-tree/shadow-19990827/src/usermod.c Fri Feb 9 03:05:52 2001
***************
*** 74,79 ****
--- 74,82 ----
#define VALID(s) (strcspn (s, ":\n") == strlen (s))
+ #undef NGROUPS_MAX
+ #define NGROUPS_MAX 256
+
static char *user_name;
static char *user_newname;
static char *user_pass;
*** ./build-tree/shadow-19990827/src/groups.c.~1~ Mon Jun 7 09:40:45 1999
--- ./build-tree/shadow-19990827/src/groups.c Fri Feb 9 03:15:54 2001
***************
*** 42,47 ****
--- 42,50 ----
static void print_groups P_((const char *));
int main P_((int, char **));
+ #undef NGROUPS_MAX
+ #define NGROUPS_MAX 256
+
/*
* print_groups - print the groups which the named user is a member of
*
*** ./build-tree/shadow-19990827/src/id.c.~1~ Mon Jun 7 09:40:45 1999
--- ./build-tree/shadow-19990827/src/id.c Fri Feb 9 03:16:34 2001
***************
*** 50,55 ****
--- 50,58 ----
static void usage P_((void));
int main P_((int, char **));
+ #undef NGROUPS_MAX
+ #define NGROUPS_MAX 256
+
static void
usage(void)
{
*** ./build-tree/shadow-19990827/src/useradd.c.~1~ Fri Feb 9 02:06:01 2001
--- ./build-tree/shadow-19990827/src/useradd.c Fri Feb 9 03:28:52 2001
***************
*** 53,58 ****
--- 53,61 ----
#endif
#include "faillog.h"
+ #undef NGROUPS_MAX
+ #define NGROUPS_MAX 256
+
#ifndef SKEL_DIR
#define SKEL_DIR "/etc/skel"
#endif
*** ./build-tree/shadow-19990827/src/newgrp.c.~1~ Fri Feb 9 02:06:00 2001
--- ./build-tree/shadow-19990827/src/newgrp.c Fri Feb 9 03:29:10 2001
***************
*** 49,54 ****
--- 49,57 ----
static GETGROUPS_T *grouplist;
#endif
+ #undef NGROUPS_MAX
+ #define NGROUPS_MAX 256
+
static char *Prog;
static int is_newgrp;
</pre>
<p>The sshd daemon has been rebuilt with the following patch so that CVS
ssh operations have the proper set of groups. The sources are in
/usr/local/src/openssh-1.2.3/ and the corresponding debian package is at
/usr/local/src/ssh_1.2.3-9.2loic_i386.deb. The package was tagged on
hold using dselect to prevent accidental upgrade. Note that this patch
may have hideous impact for users who have real account and use ssh
since most of the commands that deal with groups have not been
recompiled to handle more than the limit of 32 groups. For instance the
id command will core dump. Here is the patch applied on the
distribution:
<pre>*** sshd.c.~1~ Fri Mar 17 04:40:18 2000
--- sshd.c Tue Feb 13 06:32:17 2001
***************
*** 147,152 ****
--- 151,240 ----
const char *display, const char *auth_proto,
const char *auth_data, const char *ttyname);
+ #ifdef AUTH_SERVER_SUPPORT
+ #ifdef HAVE_GETSPNAM
+ #include <shadow.h>
+ #endif
+ #endif /* AUTH_SERVER_SUPPORT */
+
+ /* The GNU C Library currently has a compile-time limit on the number of
+ groups a user may be a part of, even if the underlying kernel has been
+ fixed, and so we define our own initgroups. */
+ #include <grp.h>
+ static int
+ xinitgroups (char *user, gid_t gid)
+ {
+ struct group *grp;
+ gid_t *buf;
+ int buflen, ngroups;
+
+ /* Initialise the list with the specified GID. */
+ ngroups = 0;
+ buflen = 16;
+ buf = malloc (buflen * sizeof (*buf));
+ buf[ngroups ++] = gid;
+
+ setgrent ();
+ while ((grp = getgrent ()))
+ {
+ /* Scan the member list for our user. */
+ char **p = grp->gr_mem;
+ while (*p && strcmp (*p, user))
+ p ++;
+
+ if (*p)
+ {
+ /* We found the user in this group. */
+ if (ngroups == buflen)
+ {
+ /* Enlarge the group list. */
+ buflen *= 2;
+ buf = realloc (buf, buflen * sizeof (*buf));
+ }
+
+ /* Add the group id to our list. */
+ buf[ngroups ++] = grp->gr_gid;
+ }
+ }
+ endgrent ();
+
+ /* Return whatever setgroups says. */
+ buflen = setgroups (ngroups, buf);
+ free (buf);
+ return buflen;
+ }
+ #define initgroups xinitgroups
+
+ /* This worked fine, and was adopted into glibc, until setgroups got a
+ similar limitation, so we override it as well. */
+ #include <linux/posix_types.h>
+ #include <sys/syscall.h>
+ #include <errno.h>
+
+ int
+ setgroups (size_t n, const gid_t *groups)
+ {
+ size_t i;
+ __kernel_gid_t kernel_groups[n];
+
+ for (i = 0; i < n; i ++)
+ kernel_groups[i] = groups[i];
+
+ {
+ long res;
+ __asm__ volatile ("int $0x80"
+ : "=a" (res)
+ : "0" (__NR_setgroups),"b" ((long)(n)),
+ "c" ((long)(kernel_groups)));
+
+ if ((unsigned long)(res) >= (unsigned long)(-125)) {
+ errno = -res;
+ res = -1;
+ }
+ return (int) (res);
+ }
+ }
+
/*
* Remove local Xauthority file.
*/
</pre>
<p><hr>
Node:<a name="Concept%20Index">Concept Index</a>,
Previous:<a rel=previous href="#System%20Administration">System
Administration</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Index of Concepts</h1>
<ul compact>
<li>/etc/aliases: <a href="#Mails%20and%20aliases">Mails and aliases</a>
<li>/etc/cron.d/savannah: <a href="#Savannah%20crontab">Savannah crontab</a>
<li>/subversions/cvs/gnuweb: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>
<li>/subversions/sourceforge: <a href="#Installation">Installation</a>
<li>/webcvs CVSROOT: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>
<li>Automatic migration: <a href="#Migration">Migration</a>
<li>change html_cvs value: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>
<li>CJN: <a href="#Skill%20List">Skill List</a>
<li>commit notification: <a href="#Sources%20CVS%20repositories">Sources CVS
repositories</a>
<li>convert project to Savannah: <a href="#Migration">Migration</a>
<li>crontab: <a href="#Savannah%20crontab">Savannah crontab</a>
<li>CVS: <a href="#Introduction">Introduction</a>
<li>CVS commit notification: <a href="#Sources%20CVS%20repositories">Sources
CVS repositories</a>
<li>document root: <a href="#Installation">Installation</a>
<li>DOCUMENT_ROOT: <a href="#Installation">Installation</a>
<li>HTML version: <a href="#Publishing%20this%20document">Publishing this
document</a>
<li>html_cvs: <a href="#Web%20CVS%20repositories">Web CVS repositories</a>
<li>MySQL prefix: <a href="#Savannah%20software%20root">Savannah software
root</a>
<li>NGROUPS_MAX > 32: <a href="#NGROUPS_MAX">NGROUPS_MAX</a>
<li>project group: <a href="#Sources%20CVS%20repositories">Sources CVS
repositories</a>
<li>publish: <a href="#Publishing%20this%20document">Publishing this
document</a>
<li>Savannah CVS: <a href="#Installation">Installation</a>
<li>Savannah definition: <a href="#Top">Top</a>
<li>Savannah prefix: <a href="#Savannah%20software%20root">Savannah software
root</a>
<li>Savannah project: <a href="#Installation">Installation</a>
<li>Savannah root directory: <a href="#Installation">Installation</a>
<li>sf_aliases: <a href="#Mails%20and%20aliases">Mails and aliases</a>
<li>sf_cvs: <a href="#Users%20and%20CVS%20synchronization">Users and CVS
synchronization</a>, <a href="#Installation">Installation</a>
<li>sf_migrate: <a href="#Migration">Migration</a>, <a
href="#Installation">Installation</a>
<li>sf_pass: <a href="#Migration">Migration</a>, <a
href="#Installation">Installation</a>
<li>skill: <a href="#Skill%20List">Skill List</a>
<li>SourceForge: <a href="#Top">Top</a>
<li>SourceForge fork rationale: <a href="#Top">Top</a>
<li>SourceForge installation guide: <a href="#Introduction">Introduction</a>
<li>This guide on www.gnu.org: <a
href="#Publishing%20this%20document">Publishing this document</a>
<li>useradd: <a href="#NGROUPS_MAX">NGROUPS_MAX</a>
<li>usermod: <a href="#NGROUPS_MAX">NGROUPS_MAX</a>
<li>web CVS projects rationale: <a href="#Projects%20and%20Web%20CVS">Projects
and Web CVS</a>
<li>webmasters in www: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>
<li>webproject group: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>
<li>www special project: <a href="#Projects%20and%20Web%20CVS">Projects and Web
CVS</a>, <a href="#Web%20CVS%20repositories">Web CVS repositories</a>
<li>www.gnu.org in CVS: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>
<li>www.gnu.org sync from /webcvs: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>
</ul>
<h1>Table of Contents</h1>
<ul>
<li><a href="#Top">Savannah</a>
<li><a href="#Introduction">Introduction</a>
<li><a href="#Installation">Installation</a>
<li><a href="#CVS%20repositories">CVS respositories</a>
<ul>
<li><a href="#Sources%20CVS%20repositories">Sources CVS respositories</a>
<li><a href="#Web%20CVS%20repositories">Web CVS respositories</a>
<li><a href="#Projects%20and%20Web%20CVS">Projects and Web CVS</a>
</ul>
<li><a href="#Database">Database</a>
<ul>
<li><a href="#Skill%20List">Skill List</a>
</ul>
<li><a href="#Mails%20and%20aliases">Mails and aliases</a>
<li><a href="#Unlock%20alias%20at%20gnu.org%20account">Unlock alias at gnu.org
account</a>
<li><a href="#Migration">Migration</a>
<li><a href="#Users%20and%20CVS%20synchronization">Users and CVS
synchronization</a>
<li><a href="#Publishing%20this%20document">Publishing this document</a>
<li><a href="#System%20Administration">System Administration</a>
<ul>
<li><a href="#SSL%20certificate">SSL certificate</a>
<li><a href="#Savannah%20crontab">Savannah crontab</a>
<li><a href="#Savannah%20software%20root">Savannah software root</a>
<li><a href="#NGROUPS_MAX">NGROUPS_MAX</a>
</ul>
<li><a href="#Concept%20Index">Index of Concepts</a>
</ul>
</body></html>
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNU-traductores] gnudist:/home/www/html/server/standards/README.savannah.html -- New file,
gnudist's file diff daemon <=