[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 


<html lang="en"><head>
<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>

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>


<p>This document is for Savannah administrators, not Savannah users.

<a href="http://savannah.gnu.org/";>Savannah</a> is a <a 
clone based on the
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.

<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 
<li><a href="#Migration">Migration</a>: 
<li><a href="#Users%20and%20CVS%20synchronization">Users and CVS 
<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><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>: 

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>


<p>Savannah currently provides the CVS frontend. Check the <a 
 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.

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>


<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 


<dd>Directory to run the backend scripts.

<dd>The SourceForge software and the <a 
web pages.

<dd>The document root of <a href="http://savannah.gnu.org/";>Savannah</a>
web pages.

<dd>Savannah specific backend scripts.


<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

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>

<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

<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>: 

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>

<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 
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}

<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.

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 
Up:<a rel=up href="#CVS%20repositories">CVS repositories</a>

<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 
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 
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 

Node:<a name="Projects%20and%20Web%20CVS">Projects and Web CVS</a>,
Previous:<a rel=previous href="#Web%20CVS%20repositories">Web CVS 
Up:<a rel=up href="#CVS%20repositories">CVS repositories</a>

<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.

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>


<p>Savannah uses MySQL and the <code>sourceforge</code> database. The root user 
a ~/.my.cnf file that defines the user/passwd. It is not necessary to
specify them on the command line.

<li><a href="#Skill%20List">Skill List</a>: 

Node:<a name="Skill%20List">Skill List</a>,
Previous:<a rel=previous href="#Database">Database</a>,
Up:<a rel=up href="#Database">Database</a>

<h2>Skill List</h2>

<p>The tables <code>people_skill</code> and <code>people_skill_level</code> are 
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
cvs commit -m 'Ignore proprietary software xxxx'

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>

<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:


<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.

Node:<a name="Unlock%20alias%20at%20gnu.org%20account">Unlock alias at gnu.org 
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>

<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

<pre>mysql -e "update user set user_name = 'desired' where user_name = 'fake'" 

Node:<a name="Migration">Migration</a>,
Next:<a rel=next href="#Users%20and%20CVS%20synchronization">Users and CVS 
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>


<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:

<li>sf_migrate -add project | mysql sourceforge

<li>sf_migrate -bind project | mysql sourceforge

<li>sf_migrate -mail project

<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.

<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.

<dd>Generate a Emacs-VM formated mail ready to send to all contributors
of the project that explains what has been done. 

<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])'

<p>When the user send the password crypted, set it using:

<pre>sf_pass --set thename cryptpass | mysql sourceforge

<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

Node:<a name="Users%20and%20CVS%20synchronization">Users and CVS 
Next:<a rel=next href="#Publishing%20this%20document">Publishing this 
Previous:<a rel=previous href="#Migration">Migration</a>,
Up:<a rel=up href="#Top">Top</a>

<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

<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.


<br><dt><code>Add new projects</code>
<dd>/subversions/cvs/software/project and 
directories are created.

<br><dt><code>Update existing projects</code>
<dd>Fixes projects that do not have a /subversions/cvs/gnuweb/software/project

<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

<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


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>

<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 
<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

<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.

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 
Up:<a rel=up href="#Top">Top</a>

<h1>System Administration</h1>

<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>: 

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 
Up:<a rel=up href="#System%20Administration">System Administration</a>

<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.

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>

<h2>Savannah crontab</h2>

<p>The Savannah crontab jobs are in /etc/cron.d/savannah. Every cron command
output is sent to address@hidden

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>

<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.

Node:<a name="NGROUPS_MAX">NGROUPS_MAX</a>,
Previous:<a rel=previous href="#Savannah%20software%20root">Savannah software 
Up:<a rel=up href="#System%20Administration">System Administration</a>


<p>The large number of groups a user can have (&gt;32) implies to modify
some basic programs (namely useradd and usermod).

<p>Gordon Matzigkeit &lt;address@hidden&gt; 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

<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="(&gt;= 0.72-5)"

--- 38,44 ----
  ifneq ($(DEB_HOST_GNU_SYSTEM),gnu)
    include debian/scripts/login.mk
    package-list += binary-login
! #  config_options += --with-libpam
    control_defs += -DMODDEP="(&gt;= 0.72-5)"

*** ./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
  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
*** ./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 ----
  #include "faillog.h"

+ #undef NGROUPS_MAX
+ #define NGROUPS_MAX 256
  #ifndef SKEL_DIR
  #define SKEL_DIR "/etc/skel"
*** ./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;

+ #undef NGROUPS_MAX
+ #define NGROUPS_MAX 256
  static char *Prog;
  static int is_newgrp;

<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

<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);

+ #include &lt;shadow.h&gt;
+ #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 &lt;grp.h&gt;
+ 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-&gt;gr_mem;
+       while (*p &amp;&amp; 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-&gt;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 &lt;linux/posix_types.h&gt;
+ #include &lt;sys/syscall.h&gt;
+ #include &lt;errno.h&gt;
+ int
+ setgroups (size_t n, const gid_t *groups)
+ {
+   size_t i;
+   __kernel_gid_t kernel_groups[n];
+   for (i = 0; i &lt; 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) &gt;= (unsigned long)(-125)) {
+       errno = -res;
+       res = -1;
+     }
+     return (int) (res);
+   }
+ }
   * Remove local Xauthority file.

Node:<a name="Concept%20Index">Concept Index</a>,
Previous:<a rel=previous href="#System%20Administration">System 
Up:<a rel=up href="#Top">Top</a>

<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 
<li>/subversions/sourceforge: <a href="#Installation">Installation</a>
<li>/webcvs CVSROOT: <a href="#Web%20CVS%20repositories">Web CVS 
<li>Automatic migration: <a href="#Migration">Migration</a>
<li>change html_cvs value: <a href="#Web%20CVS%20repositories">Web CVS 
<li>CJN: <a href="#Skill%20List">Skill List</a>
<li>commit notification: <a href="#Sources%20CVS%20repositories">Sources CVS 
<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 
<li>html_cvs: <a href="#Web%20CVS%20repositories">Web CVS repositories</a>
<li>MySQL prefix: <a href="#Savannah%20software%20root">Savannah software 
<li>NGROUPS_MAX &gt; 32: <a href="#NGROUPS_MAX">NGROUPS_MAX</a>
<li>project group: <a href="#Sources%20CVS%20repositories">Sources CVS 
<li>publish: <a href="#Publishing%20this%20document">Publishing this 
<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 
<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 
<li>sf_pass: <a href="#Migration">Migration</a>, <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 
<li>webproject group: <a href="#Web%20CVS%20repositories">Web CVS 
<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 
<li>www.gnu.org sync from /webcvs: <a href="#Web%20CVS%20repositories">Web CVS 

<h1>Table of Contents</h1>
<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>
<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>
<li><a href="#Database">Database</a>
<li><a href="#Skill%20List">Skill List</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 
<li><a href="#Migration">Migration</a>
<li><a href="#Users%20and%20CVS%20synchronization">Users and CVS 
<li><a href="#Publishing%20this%20document">Publishing this document</a>
<li><a href="#System%20Administration">System Administration</a>
<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>
<li><a href="#Concept%20Index">Index of Concepts</a>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]