Savannah
********

This document (*Note Publishing this document::) is for Savannah
administrators, not Savannah users. It describes the GNU Savannah
software and takes the subversions installation as example.

   Savannah is a SourceForge clone based on the SourceForge-2.0
software. It is dedicated to Free Software projects.

   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 can be seen as a waste of time.  Anyway, Jaime E. Villate
<villate@gnu.org> and Mathieu Roy <yeupou@gnu.org> are trying to do
improve configurability because the original SourceForge software is no
longer maintained as Free Software. The whole Savannah software is
available from CVS and is managed by the Savannah project. The ChangeLog
explains the modifications made to the original code.

   The GNU Savannah Project, started by Loic Dachary <loic@gnu.org> in
2000, has two major focuses:
   * Enhancing the GNU Savannah software if possible (portability,
     swiftness, design, simplicity...)

   * Hosting Free Software using GNU Savannah on subversions.gnu.org,
     at savannah.gnu.org (for GNU Projects) and savannah.nongnu.org
     (for non-GNU Projects)

Introduction
************

Savannah currently provides a CVS frontend, web space management thru
CVS, HTTP download area, bug tracking and mailing lists.

   It is pretty tricky to find an unequivocal way to call the people
that deal with Savannah. Savannah Admin describes the people who manage
the server (We). Savannah User describes the people who use it,
obviously this includes Project Admins who manage a project hosted by
Savannah and Project Members who participate in a project hosted by
Savannah.

   Setting up Savannah is not an easy task because it has to integrate
existing habits and projects without breaking anything. However, the
SourceForge Installation Guide by Guillaume Morin helps a lot
understanding the software.

Installation
************

A Typical Installation
======================

First, you need to get a copy of Savannah. See
`http://savannah.gnu.org/cvs/?group=savannah'. The Savannah CVS has
several modules. The base module is `savannah'

     # anonymous access
     cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/savannah login
     cvs -z3 -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/savannah co savannah

   Then, you can configure it. There are two configuration files. The
first one is called `/etc/savannah/local.inc.pl', coded in Perl, the
second is `/etc/savannah/local.inc', in PHP, used by the PHP Engine.
The second is generated by reading the first, so it does not make sense
to modify the second.

   To create `/etc/savannah/local.inc.pl', you must use the script
`sv_update_conf'. This is how you should proceed:

     cd where_savannah_was_downloaded
     ./configure
     make
     make conf

   At this point, you should manually edit this file, especially if you
want extra features such as kerberos (described below), webalizer
(described below). After editing `/etc/savannah/local.inc.pl', you must
run `sv_update_conf'. Proceed as follows:

     # pwd == where_savannah_was_downloaded
     # Edit the file with the extensible One
     emacs /etc/savannah/local.inc.pl
     make update-conf

   `sv_update_conf' also created log and crontab entries. We'll explain
this later.

   Finish the installation by copying the savannah scripts (with sv_
prefix) typing:

     make install

   The scripts will be installed in `bindir' (check the Makefile for
the actual value of bindir).

   Finally, you need to edit your Apache configuration. Add something
like the following (assuming that your configuration file
(`local.inc.pl') is in `/etc/savannah'):

   Make sure the env_module is being used by Apache; i.e. in the
configuration file there should appear a line such as:

       LoadModule env_module /usr/lib/apache/1.3/mod_env.so

   You can either use a virtual domain for the Savannah package at your
server, or you can install it in a subdirectory of your home page. If
you are going to install it on the virtual server "projects.my.net" on
a server with IP address 192.168.62.11, you should write the following
in Apache's configuration file:

        NameVirtualHost 192.168.62.11
       <VirtualHost 192.168.62.11>
       ServerName projects.my.net
       DocumentRoot /home/products/savannah/frontend/php
       ServerAdmin your.name@my.net
     
       <IfModule mod_env.c>
           SetEnv SV_LOCAL_INC_PREFIX /etc/savannah
       </IfModule>
     
       <Location /users>
           SetHandler application/x-httpd-php
       </Location>
     
       <Location /projects>
           SetHandler application/x-httpd-php
       </Location>
       </VirtualHost>

   If you are going to install it in a subdirectory called savannah, the
following should be enough:

        <IfModule mod_env.c>
           SetEnv SV_LOCAL_INC_PREFIX /etc/savannah
       </IfModule>
     
       <Location /savannah/users>
           SetHandler application/x-httpd-php
       </Location>
     
       <Location /savannah/projects>
           SetHandler application/x-httpd-php
       </Location>

   Read `INSTALL.verbose' for more details, especially about Apache 2.x

Subversions Installation
========================

Savannah is installed on the machine subversions.gnu.org. The root of
the installation is in /subversions/savannah. 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 SourceForge Installation Guide are
omitted.

`/etc/savannah'
     Savannah configuration files such as `local.inc.pl' and
     `local.inc'.

`tmp'
     Directory to run the backend scripts.

`src/savannah'
     The Savannah software and the Savannah web pages.

`src/savannah/frontend/php'
     The document root of the Savannah web pages.

`src/savannah/gnuscripts'
     Savannah specific backend scripts.


   The following is relevant for the Apache configuration files
(warning: this is a incomplete list!):

      # Port
     Port 80
     
     ##  SSL Support
     Listen savannah.gnu.org:80
     Listen savannah.gnu.org:443
     Listen subversions.gnu.org:80
     Listen 199.232.41.4:80
     Listen 199.232.41.4:443
     
     # VirtualHost
     NameVirtualHost 199.232.41.3:80
     NameVirtualHost 199.232.41.3:443
     NameVirtualHost 199.232.41.4:80
     NameVirtualHost 199.232.41.4:443
     
     <VirtualHost 199.232.41.3:80>
       ServerName savannah.gnu.org
       SetEnv SV_LOCAL_INC_PREFIX /etc/savannah/gnu-conf
       SSLDisable
     </VirtualHost>
     
     <VirtualHost 199.232.41.3:443>
       ServerName savannah.gnu.org
       SetEnv SV_LOCAL_INC_PREFIX /etc/savannah/gnu-conf
       SSLCertificateFile /etc/apache-ssl/apache.pem
     </VirtualHost>
     
     
     <VirtualHost 199.232.41.4:80>
       ServerName savannah.nongnu.org
       SetEnv SV_LOCAL_INC_PREFIX /etc/savannah/nongnu-conf
       SSLDisable
     </VirtualHost>
     
     <VirtualHost 199.232.41.4:443>
       ServerName savannah.nongnu.org
       SetEnv SV_LOCAL_INC_PREFIX /etc/savannah/nongnu-conf
       SSLCertificateFile /etc/apache-ssl/savannah.nongnu.org.pem
     </VirtualHost>
     
     <VirtualHost 199.232.41.4:80>
       ServerName freesoftware.fsf.org
       Redirect / http://savannah.nongnu.org/
       SSLDisable
     </VirtualHost>
     
     <VirtualHost 199.232.41.4:80>
       ServerName nongnu.org
       Redirect / http://savannah.nongnu.org/
       SSLDisable
     </VirtualHost>
     
     SetEnv SV_LOCAL_INC_PREFIX /etc/savannah/gnu-conf
     
     # Forbid script execution in the download area
     <Location /download>
       AllowOverride None
       AddType text/html  phtml pht php php3 phps php3p
       AddType application/x-java-archive jar
     </Location>

   All of the Savannah software is available from CVS and is managed by
the Savannah project.

   In the root user's home, symlinks exist to the savannah
installation. `~/sv_subversions' points to
`/subversions/savannah/src/savannah'.

Database
********

Setting up the Database
=======================

GNU Savannah uses MySQL. We plan to make it support PostgreSQL in the
future.  The database may be called `savannah'. On subversions, for
historical reasons, its name is `sourceforge'.

   You may create a `~/.my.cnf' for the root user to define the
user/passwd. This is not mandatory but it saves typing them on the
command line and allows cron jobs to be run. Example of this file

     [client]
     user=mysql_user
     password=hey_this_is_supposed_to_be_secret

   To create your database, you must have previously created a basic
configuration. See the previous chapter. In the following ways, you can
create and initialize the whole database:

     make database
     make database-structure
     make database-initvalues

   You can take a look at `savannah/db/mysql', each table is described
here and in the READMEs.

Remote Access
=============

A read-only access to the `sourceforge' database on subversions is
granted to the following machines:

`fr.fsf.org'
     with user name france and the password is known by Loic Dachary
     <loic@gnu.org>.


XML Dump
========

The `sv_xml' script builds daily an XML dump of the public information
from the Savannah database into a filled called savannah.xml.

   In addition a dump containing information that users may not want to
publish to the public such as their email address and ssh public keys
is built in `/subversions/savannah/dumps/savannah.xml'. The command line

     sv_xml --private

   is used to generate this dump.

   The directory where those files are stored is defined in
`local.inc.pl'. It's the `sys_miscdir'.

   A set of XSLT files can be written in the /subversions/savannah/dumps
(in the case of subversions - replace this by your `sys_miscdir')
directory to build custom files from the `savannah.xml' file that is
located in the same directory. This is used, for instance, for account
creation information files. If an XSLT file is created (`a.xsl' for
instance) the `Makefile' must be updated to add the `a.txt' file in the
list of dependencies of the `all' goal.  For instance:

     all: accounts-fsffr.txt accounts.txt myown.txt

   The generation of both savannah.xml files and the XSLT processing is
run daily from crontab.

Database Backups
================

The MySQL database (named `sourceforge' on subversions) that holds all
the information used by you Savannah installation is dumped daily.

   For subversions, see http://savannah.gnu.org/projects/sysadmin/ to
find out where the dumps are stored. The dumps are compressed and
rotated daily with a maximum of 30, as described in `logrotate.conf'.
The `sv_backup' script takes care of all this and is called from the
crontab.

   Normally, it's stored in the `sys_miscdir' defined in the
configuration file `local.inc.pl'.

Group Types Table
=================

We recently (Aug 2002) changed the usage of the group_type table. If
you have a old savannah installation, drop the old table and create the
new one by using the files `savannah/db/mysql/table_group_type*'.

   The new group_type usage is described in a whole chapter. See below.

Skill List
==========

The tables `people_skill' and `people_skill_level' are loaded from the
skill database maintained by CJN (http://cjn.sourceforge.net/).  The
script `sv_skill' loads the XML skill files from CJN and replace the
content of the tables in the savannah database.

   You can remove some softwares you do not to be shown on the list:
add them to the %ignore table in the sv_skill script and re-run it.

   In the case of subversion, we do not want to see proprietary
softwares.

     cd /subversions/savannah/src/savannah/gnuscripts
     edit sv_skill
     sv_skill
     cvs commit -m 'Ignore proprietary software xxxx'

Savannah Administrator
**********************

How it works in general
=======================

At a given time only one person can be in charge of approving or
rejecting projects submitted to the Savannah installation. The /admin/
interface is not fit for concurrent access.

   You must create an admin user. Go to the web interface and register
an user (should be #101).  Then, execute the following mysql command:

     mysql -u user -ppassword -e "insert into user_group (user_id,group_id,admin_flags) values (101,1,'A')" dbname

   You can give the admin rights to others users by adapting this
command.

How it works on subversions
===========================

Since at a given time only one person can be in charge of approving or
rejecting projects submitted to the Savannah installation, the user
assigned to this task is the one in charge. It is his responsibility to
find someone else before leaving :-)

   People currently (May 2003) playing this role are Loic Dachary
<loic@gnu.org>, Jaime E. Villate <villate@gnu.org>, Mathieu Roy
<yeupou@gnu.org> and Rudy Gevaert <rudy@gnu.org>.

   The tasks submission moderation and bug dispatching are assigned to
the person currently in charge of approving the projects submitted to
Savannah.

   The password of the `admin' user is known by Loic Dachary
<loic@gnu.org>, Guillaume Morin <gmorin@gnu.org>, Hugo Gayosso
<hgayosso@gnu.org>, Jaime E. Villate <villate@gnu.org>, Mathieu Roy
<yeupou@gnu.org> and Rudy Gevaert <rudy@gnu.org>.

Group Types
***********

Understand Group Types
======================

Something new we introduced recently (Aug 2002) in Savannah is group
type. While, with the original SF code, group type was things like
`Foundries' or `Project', things really differents, now it just define
thing that can be exactly the same: projects.

   It defines what features a group can use (as cvs, mailing-list) and
how (mailing-list default address, viewcvs base url, cvsroot directory,
base host).

   After creating an admin account, you must login and create at least
one group type. Choose `Group Type Editing' in the menu.

   While people will register project, they will be asked to tell which
type of project their project should be.

GNU and non-GNU on subversions
==============================

On Savannah, we host GNU and non-GNU project. We consider them as group
type and so every definitions related to them are stored in group_type
table.

   The base host is different. While GNU project have savannah.gnu.org
as base host, non-GNU have savannah.nongnu.org.

   Configuration files for GNU are in `/etc/savannah/gnu-conf' and the
ones for non-GNU are in `/etc/savannah/nongnu-conf'.

   Content files for GNU are in `/etc/savannah/gnu-content' and the
ones for non-GNU are in `/etc/savannah/nongnu-content'.

   Configuration files directly in `/etc/savannah' are symlinks to
`/etc/savannah/gnu-conf' since savannah.gnu.org is the default virtual
server.

   Apache conf must be edited to reflect this. For example, we should
have something like the following for each virtual server.

   We also have a special group type called www.gnu.org which is about
www.gnu.org webmastering. On this one, the homepage dir is not guessed
(group type option). It permits to set this dir with a name different
than the group name. For instance, the HTML cvs directory of
japanesegnui is /japan.

     <Location thisdomain>
         SetEnv SV_LOCAL_INC_PREFIX /etc/savannah
     </Location>

Site Specific Content
*********************

One more time how it works in general
=====================================

You can change content of your Savannah installation. For instance, the
footer of everypage.

   Data is partially separated for the PHP Engine. The default content
is in `etc/site-specific-content'. But you can choose the directory you
want and, as you may guess if you've read the previous chapter, choose
different content for each group type.

One more time how it works on subversions
=========================================

Since we always want to manage content via CVS, the site specific
content is in two cvs module called `gnu-content' and `nongnu-content'
created following the example of `savannah/etc/site-specific-content'.

Download area
*************

Here, we describe the subversion case. We recommand you to only accept
secured transfert protocols. Do you need more informations?

   Each project registered on Savannah that is not part of the GNU
project is granted a publicly available file download area at

     http://savannah.nongnu.org/download/projectname/

   Each project member can upload files to this directorly by using scp
or rsync over ssh to the following location:

     savannah.nongnu.org:/upload/projectname/

   Sample commands for doing this are:

     #
     # Copy an entire tree verbatim, that may imply to remove files on
     # savannah.nongnu.org.
     #
     rsync --delete -av --rsh=ssh . savannah.nongnu.org:/upload/projectname
     #
     # Copy a single file with scp
     #
     scp -q file.tar.gz savannah.nongnu.org:/upload/projectname
     #
     # Copy a single file with rsync over ssh
     #
     rsync --rsh=ssh file.tar.gz savannah.nongnu.org:/upload/projectname

   A reminder is included in the `Project Admin' page of each project.

CVS repositories
****************

Here, we describe the example of subversions.

   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 /cvsroot and the
web repository is in /webcvs. This values are defined by `Group Type'.

Importing repositories
======================

Existing projects that migrate to Savannah may want their CVS
repository to be transfered to subversions. Time is essential for such
an operation since the project contributors want to work on the new
repository on subversions and stop using the old. When the author asks
cvs-hackers@gnu.org, ask him to send the tarbal by mail or send a URL
from which it can be downloaded.  Make an appointement with him and
guarantee that the repository will be untared on subversions with 24
hours maximum. The project contributor must first create a project on
subversions. When you have the tarbal untar it at /cvsroot/project.
Make sure it does not contain a CVSROOT that would override the
existing CVSROOT. If it does manualy copy the history and val-tags
files only. Make sure the imported repository is untared under
/cvsroot/project/project and does not polute the root of the repository.

Source of the CVS repositories
==============================

When a project has a license that is not `website' a source repository
is created under /cvsroot/project with a private CVSROOT that only
contains anoncvs. The developers of the project have write access to
the CVSROOT directory.

   This will change soon.

   The group `project' is created to grant write access to the
repository to all the members of the project.

   When a Savannah project is assigned the `website' license, it only
has a portion of the webcvs repository and no source CVS repository.

   If the `html_cvs' field for a given Savannah project is empty, it is
not associated with a part of the webcvs repository.

   For compatibility with the cvs setup before Savannah was introduced,
/subversions/cvs/common contains symbolic links to the corresponding
Savannah directory. Developers are encourage to stop using this
historical setup.

   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.

Getting email from CVS
======================

In any large project, keeping track of changes is difficult.  CVS does
a reasonable job of allowing source changes to be controlled and
managed, but does not provide tools to make it easier to work with a
changing code base.  The hardest part of working on a dynamic project
with many changing modules is knowing when changes occur, and what
those changes are.

   Software developers often are heavy email users, spending huge
amounts of time working with their email software.  Free software
developers are among the most serious email addicts out there, sorting
through hundreds of emails a day, since this is often the only way to
stay in touch with users and fellow developers.

   A project member may add e-mail notification of any commits to the
repository by doing the following: (replace `project' with the name of
the project and `user' by the Savannah login name).

     cvs -d user@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 project-commit@gnu.org -s %{sVv}

   The email address must exist, it will not be automatically generated.

Source CVS tarbals
==================

The sv_backup script builds tarbals for each repository in the /cvsroot
directory. Those tarbals are stored in the
/subversions/cvs/software.backups directory and linked with the
savannah.gnu.org:/cvs.backups URL. The tarbals are generated daily, if
at least one file in the repository is more recent than the tarbal.

Web CVS repositories
====================

When a project has an `html_cvs' field that is not empty in the `group'
table, a web repository is created in /webcvs/`html_cvs'. By default
the `html_cvs' field has the value `/software/project/' but it may be
edited by the Savannah administrators at the savannah.gnu.org/admin/
URL. Project members may not change this value. See the gnujobs and gdb
projects for examples.

   If a project is tagged as non-gnu (gnu field in table groups set to
N) it is given a space in the /non-gnu/project directory instead.

   When a Savannah project is assigned the `website' license, it only
has a portion of the webcvs repository and no source CVS repository.

   If the `html_cvs' field for a given Savannah project is empty, it is
not associated with a part of the webcvs repository.

   The group `webproject' is created to grant write access to the
repository to all the members of the project.

   All the www.gnu.org web was imported in /webcvs (early 2001).  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 `html_cvs' 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.

   The `www' project in Savannah is treated in a special way. All the
members of the `www' project have access to the whole repository in
/webcvs. It means that they are always included in every `webproject'
created. However, the non-gnu projects and not included and webmasters
may not modify them if they are not a member of the group.

Web CVS Symbolic links
======================

Since CVS is not able to handle symbolic links, a simple mechanism has
been implemented on the machine hosting the www.gnu.org to allow
webmasters to control the symbolic link from the CVS tree.

   The special file `.symlinks' contains a list of file name pairs, one
per line. For instance:

     foo.html index.html
     bar.html other.html

   is a valid `.symlinks' file. Every night a script reads all the
`.symlinks' files, prepend a `ln -s' in front of each line and execute
them. Well, in reality it's not that simple but you get the idea. The
`.symlinks' file can only be used to control the symbolic link in the
directory where they are.

Sync of www.gnu.org on commit
=============================

The /webcvs/CVSROOT/loginfo file contains a trigger 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.

   The /subversions/savannah/src/savannah/gnuscripts/sv_www_sync.c
program was derived from the /usr/local/bin/webcvs.c program (now
obsolete). It is called on each commit to keep the www.gnu.org web site
in sync with the CVS repository.

   The idea is to runs a cvs update -l (to prevent recursion) in the
directory where the commit was done. Since the command will be called
once for each directory where a commit did some action there is no need
for recursion.

   The %{s} argument given in the loginfo file is a single argument that
lists the directory and all the files involved. As a special case if the
directory was added the file list is replaced by '- New directory'. This
is lame since adding the files -, New and directory will produce the
same effect, but it's unlikely.

   There are three cases to take in account:

   * commit that modify the top level directory files: cd topdir ; cvs
     update -l

   * commit that adds a new directory: cd topdir ; cvs update 'new
     directory'

   * commit that modify files in a subdirectory: cd topdir/subdirectory
     ; cvs update -l


   In order to prevent security compromision the directory name is
quoted.

   The traces of all the updates are kept in /var/log/sv_sync_www.log.

Web CVS and Projects
====================

The special project `www' 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 `bravegw' Savannah project only give
write access to the /webcvs/brave-gnu-world part of the repository.

   A project bound to a specific subdirectory will grant 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.

   The sv_www script generates the map that is published at www.gnu.org
to Savannah. It writes the file in
/subversions/savannah/src/server/standards and commits it. The
server/standards directory is a read-write checkout of the www.gnu.org
web CVS. The sv_www script is run once a day by the crontab.

   A more webmaster oriented documentation explains the organisation of
the www.gnu.org CVS tree and the rationale of its usage.

Set up a mailing list
*********************

If you haven't already created a mailing list to handle messages sent
by CVS, follow these instructions to do so.

   To get started, surf to your project's "Project Page."  If the
"Public Areas" section of the page doesn't list "Mailing Lists," click
over to the `Project Admin' page, the to the `Edit Public Info' page.
Make sure the "Use Mailing Lists:" checkbox is on, and click "Update."
Now go back to your "Project Page."

   Go to the `Mailing Lists' page and click through to the `Admin'
page.  Select `Add Mailing List' to get a really easy-to-use form that
asks you only `two questions':

`What do you want to name your list?'
     Since all Savannah list names start with the Unix name of your
     project and a hyphen, you don't even have to worry about that part!
     You just decide on the hard part: "Do I call it
     `myproject-commits', or `myproject-checkins'?"  You can choose
     other names, but those are well-recognized by active Free Software
     developers.

`Should I let just anyone subscribe?'
     "Yes" will already be checked for you, so leave it that way.  You
     want your users to be able to subscribe so they'll know when
     you've fixed the bug they reported, because they want to try out
     the changes as soon as they're in.


   Ok, so you really only had to decide one thing - that's even better.
Now, click the "Add This List" button, and wait for your list to be
created.

Account Management
******************

It is convenient to use Savannah to manage accounts on a machine that is
completly unrelated to Savannah itself. For instance, the project fsffr
lists all the users who should have an account on the
`france.fsfeurope.org' machine.

   A cron job on the remote machine can fetch the list of users from
Savannah and update the password files accordingly. Adding a user to
the machine can then be done by adding the user as a developer of the
project.

   A guide to install the `savannahusers' script on the target machine
is available in the savannahusers manual page. This chapter deals with
the necessary actions on the savannah.gnu.org machine, not on the
target machine.

   In order for remote machines to take advantage of Savannah for
account management, a list of all Savannah users is dumped daily, both
in XML format and text format (*Note XML Dump::).

   The access to the user information is restricted and has to be done
in the following way:

     rsync --rsh=ssh xmlbase@savannah.gnu.org: .

   The user `xmlbase' on savannah.gnu.org is only used for this
purpose. The ssh public key of the user doing the `rsync' on the remote
machine must be registered in the `authorized_keys' file of the
`xmlbase'. He will only be allowed to access a single file.  You don't
need to give the command you want to execute, indeed this information
is already in the authorized_key :

     command="rsync
              --server --sender . /subversions/savannah/dumps/savannah.xml"
             1024 35 1325...

   Two files may be accessed in this way:

`savannah.xml'
     the content of savannah.xml is not documented but should be
     reasonably self-explanatory.

`accounts.txt'
     contains a block of lines describing the account of every user
     registered on Savannah. Here is an example with long lines
     truncated:

          loic
          Loic Dachary
          loic@gnu.org
          1024 35 14482406825620879676223610524821306708503540742800...
          
          rodolphe
          Rodolphe Quiedeville
          rq@lolix.org
          1024 35 13773675641076158303518150007131532895996406770957...
          1024 35 13392800240284295490871092259529193810644583890958...

     Each account block is separted by an empty line. The first line is
     the uniq user name. The second line is the full name of the user.
     The third line is the e-mail address of the user. The next lines
     are the content of the `authorized_keys' file.


   It is possible to generate files specific to a given target machine.
For instance the `account-fsffr.txt' file is a selection of the users
that are members of the fsffr projects. The `Makefile' in the dumps
directory is responsible for the creation of these files. It uses XSLT
to select the relevant informations from the `savannah.xml' dump.

Remove a user
=============

It is rarely needed to remove a user. Inactive accounts on Savannah do
not hurt (neither in space nor in performance). When it appears to be
necessary to remove a user account, the administrator should proceed as
follows:
   * Go to the administration page of each project to which the user is
     bound and remove it.

   * mysql -e "delete from user where user_name = 'username'"
     sourceforge

   See Savannah Elisp to get shortcuts, under GNU Emacs, to perform
this kind of tasks.

   Send all questions and requests to savannah-hackers@gnu.org or to
support requests.

Mailman
*******

Current setup
=============

Savannah features a way to link a project with its mailing lists. They
are handled by Mailman on fencepost. The purpose of this section is to
explain the link between savannah and Mailman.

   Some details regarding the setup of Mailman can be found in the
sysadmin.texi file at http://savannah.gnu.org/projects/sysadmin/.

Binding existing mailing lists
==============================

Before Savannah was available, some mailing lists have been created.
Some of the GNU packages have been migrated on savannah since then.
From the list adminsitration page on each Savannah project, it is
possible to to make the link between these packages and their mailing
lists (the file is savannah.gnu.org/www/mail/admin/index.php). The
administrator of the Savannah project has to fill aform with the name of
its mailing lists and the admin password of the list.

Adding a mailing list
=====================

When a Savannah project administrator chooses to add a mailing list for
his(her) project, an entry is added to the Savannah database. This
information will be dumped by (by the sv_xml script). A cronjob on
fencepost.gnu.org will read that dump and find which lists must be
created. It will launch the `newlist' binary and update the alias file.

Mailing lists for GNU packages
==============================

This cronjob that creates mailing lists can be found in
gnuscripts/Mailman/mailing_lists_create.pl in the CVS tree (see
http://savannah.gnu.org/projects/savannah/ for get the source tree).

   The parameters needed to bind an existing mailing list to a Savannah
project (list name and password) are checked by a CGI script installed
on fencepost.gnu.org. The related files are in the gnuscripts/Mailman
directory of the Savannah sources (see
http://savannah.gnu.org/projects/savannah/ for get them). They can be
installed on fencepost via a Makefile (details are in sysadmin.texi).

Mailing lists for non-GNU packages
==================================

The mailing lists of the Savannah projects that are not part of the GNU
project are hosted under the domain savannah.nongnu.org. This domain
and the corresponding mailman installation are installed on the
fencepost.gnu.org machine.

   Mailman was installed in `/com/mailer/freesoftware'.

...Managed by Group Type
========================

Once more, the Group Type configuration is important for mailing-list
configurations.

Mails and aliases
*****************

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
user@savannah.gnu.org. In order for the user@savannah.gnu.org address
to work properly for outgoing mails, the /etc/email-addresses file is
updated automatically every 5 minutes with the following command:

     sv_aliases

   The user@savannah.gnu.org can `never' be used to recieve mail for
the good reason that savannah.gnu.org does not listen on the SMTP port.

Unlock alias at gnu.org account
*******************************

People who have a simple alias name@gnu.org but no account on Kerberos
cannot create an account on Savannah. When they ask to unlock the
account name on savannah-hackers@gnu.org, tell them to create an account
using a fake username and to send this username to
savannah-hackers@gnu.org.  When receiving that user name substitute the
fake login name by the desired one:

     mysql -e "update user set user_name = 'desired' where user_name = 'fake'" sourceforge

Users and CVS synchronization
*****************************

Must be root to run this script and make sur you export CVS_RSH=ssh.
You are advised to run it in /subversions/savannah/tmp, although it is
not mandatory.

   It is run from the crontab and the output is logged in
/var/log/sv_cvs.log.

   The `sv_cvs' perl script generates a shell script that will
synchronize the system files with the state of the Savannah database
(sourceforge).

   This script only generates lines if something needs to be done. When
the resulting script is executed, another run `must not' display any
action (unless the database was modified in the meantime which is
unlikely).

   It performs the following tasks, in this order.

`Add new projects'
     /cvsroot/project and /webcvs/software/project (or
     /webcvs/non-gnu/project) directories are created.

`Update existing projects'
     Fixes projects that do not have a /webcvs/software/project
     directory or a directory with wrong permissions.

`Add missing users'
     Create users (in /etc/passwd)  that are bound to at least one
     project in Savannah.

`Remove users'
     Remove users not bound to any project in Savannah If user belongs
     to groups not managed by Savannah, just redefine its group list.

`Update existing users'
     Modify the system files if they are not in sync with the Savannah
     database.

`Update the groups of anoncvs'
     The list of groups (projects) to which anoncvs belongs is
     restricted by the public/non public status of a project.

`Update the CVS password file'
     Update the /cvs/CVSROOT/passwd file to reflect the passwd and
     users bound to projects in Savannah.

`Create download area for non-GNU projects'
     A directory is created at /upload/projectname, only if the project
     is not part of the GNU project.

`Update cvs-pserver.conf'
     Update the list of all possible pserver roots.


Publishing this document
************************

The HTML version of this document is published in two places: Savannah
Administration Guide and Savannah Administration Guide. The source is
stored in the `subversions.gnu.org:/cvsroot/savannah' CVS repository,
in the `$Source: /cvs/savane/savane/doc/admin/savannah.texi,v $' file
(and/or subversions.gnu.org:/cvs co gnudocs repository ? - FIXME).  To
facilitate the publication process you can edit it in the
subversions.gnu.org:/subversions/savannah/src/gnudocs directory and
then issue a

     make publish

   The `publish' goal assumes that the Savannah document root is in
../savannah/frontend/php 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.

System Administration
*********************

SSL certificate
===============

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.

Project registration discarding
===============================

Project registration that are disapproved with the PHP interface are
marked with D in the SQL database.

   To remove a project registration completely, sv_register_discard is
used, specifying the project unix name as argument. It will ask you to
give a comment, an explanation about the discard.

     sv_register_discard project_unix_name

   Additionally, you can use -user and -comment options:

     sv_register_discard project_unix_name --user="yp" --comment="this project does not fit to our policy"

   With no argument given, sv_register_discard will search any project
marked as D and will ask you for a comment for each project
registration discarded.

   So, if needed, savannah-hackers can check the reason why a project
has been discarded since it is logged in
/var/log/sv_register_discard.log

Kerberos Support
================

At subversions.gnu.org, Kerberos is supported for some GNU accounts.
Users can use Kerberos to work with CVS and to log in the Savannah PHP
frontend.

   We use phpkrb5 available at
`http://savannah.nongnu.org/files/?group=phpkrb5'. A Debian package was
build for subversions.gnu.org and PHP4, using checkinstall, and is
available at the same URL, called `phpkrb5-1.2.0-savannah1'.

   To install phpkrb5, read the phpkrb5 README (even if you install it
via the Debian package).

Web Usage Statistics
====================

Statistics for savannah.gnu.org web usage are generated using webalizer.
This is almost entirely managed independantly from Savannah: webalizer
is install via an official Debian package.

   The configuration is `/etc/webalizer.conf'. The report is generated
in /subversions/sourceforge/src/savannah/frontend/php.

   We found more interesting to let users choose features they want to
use, webalizer must be installed via the normal way: packaged. On
subversions.gnu.org, webalizer has been installed via apt-get.

   In `/etc/savannah/local.inc.pl', Savannah is configured to use
webalizer.

   If for a reason of another all the logs need to be regenerated, try:

     cd /var/log/apache-ssl
     for log in `ls --sort=t -r access*`; do echo "parse $log" && webalizer -q -c /etc/webalizer.conf $log; done

   Exactly the same goes for mrtg.

Savannah crontab
================

The Savannah crontab jobs are in /etc/cron.d/savannah. Every cron
command output is sent to savannah-hackers@gnu.org.

     PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:/subversions/savannah/bin:/usr/local/mysql/bin
     MAILTO=savannah-hackers@gnu.org
     #
     # Build /etc/aliases,
     #/savannah.html#Mails%20and%20aliases
     #
     */5 * * * *	root	sv_aliases
     #
     # Build www map,
     #/savannah.html#Web%20CVS%20and%20Projects
     #
     10 4 * * *	root	sv_www
     #
     # Sync projects with CVS related system files,
     #/savannah.html#Users%20and%20CVS%20synchronization
     #
     17 * * * *	root	cd /subversions/savannah/tmp ; sv_cvs | ( date ; sh -x ) >> /var/log/sv_cvs.log 2>&1
     #
     # Daily backups of the Savannah database,
     #/savannah.html#Database%20Backups
     #
     7 5 * * *	root	sv_backup
     #
     # Daily XML dump of Savannah public information
     #/savannah.html#XML%20Dump
     #
     7 6 * * *	root	sv_xml > /subversions/savannah/src/savannah/frontend/php/savannah.xml
     14 6 * * *	root	sv_xml --private > /subversions/savannah/dumps/savannah.xml
     30 6 * * *	root	make -s -C /subversions/savannah/dumps all
     0 */1 * * *	root	sv_xml --list > /subversions/savannah/dumps/list.xml
     #
     # Daily web server statistics: It remains here for the memory.
     # As explained in
     #/savannah.html#Web%20Usage%20Statistics
     # it's now useless and shouldn't be used.
     #
     #7 7 * * *	root	sv_stat

Savannah logs
=============

The logs of the Savannah scripts are in `/var/log'. They are rotated by
the `/etc/logrotate.d/savannah' configuration file of logrotate.

`/var/log/sv_cvs.log'
     Modification of the the system files from the mysql database
     information so that CVS, upload etc can work properly.

`/var/log/sv_sync_www.log'
     Loginfo and update information generated by the sv_sync_www
     program.  This file `must' be read-write for everyone.

`sv_register_discard.log'
     Project registration deletion.

`/var/log/apache-ssl/access.log'
     savannah.gnu.org web server logs. SSL connection generate big logs
     so we rotate them on a daily basis.


Savannah software root
======================

All software that is not system wide but only used for the purpose of
Savannah must be installed in the prefix /subversions/savannah.

NGROUPS_MAX
===========

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

   The cvs-1.11.1p1 executable was patched and the patches are available
at cvs-1.11.1p1-2001-12-11.patch.

   Here is the patch applied to /usr/local/src/shadow-19990827. The
modified usermod and useradd have been installed in
/subversions/savannah/bin.

     *** ./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 512
     +
       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 512
     +
       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 512
     +
       /*
        * 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 512
     +
       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 512
     +
       #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 512
     +
       static char *Prog;
       static int is_newgrp;

   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:

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

cvs
===

The cron daemon was recompiled from `/usr/local/src/cvs-1.11.1p1/' with
the following patches applied.

   * `/usr/local/src/cvs-1.11.1p1-2001-12-11.patch' for NGROUPS_MAX

   * `/usr/local/src/cvs-1.11.1p1-cvsroot.patch' for -allow-root-file.
     It prevents the multiplcation of -allow-root arguments for
     anonymous cvs.


cron
====

The cron daemon was recompiled from `/usr/local/src/cron-3.0pl1/' with
the following patch applied, to fix the NGROUPS_MAX limit.

     *** do_command.c.~1~	Tue Jun 12 06:35:48 2001
     --- do_command.c	Tue Jun 12 06:25:48 2001
     ***************
     *** 30,35 ****
     --- 30,112 ----
       # include <syslog.h>
       #endif
     
     + /* 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);
     +   }
     + }
     
       static void		child_process __P((entry *, user *)),
       			do_univ __P((user *));
     ***************
     *** 240,246 ****
       		 */
       		setgid(e->gid);
       # if defined(BSD) || defined(POSIX)
     ! 		initgroups(env_get("LOGNAME", e->envp), e->gid);
       # endif
       		setuid(e->uid);		/* we aren't root after this... */
       		chdir(env_get("HOME", e->envp));
     --- 317,323 ----
       		 */
       		setgid(e->gid);
       # if defined(BSD) || defined(POSIX)
     ! 		xinitgroups(env_get("LOGNAME", e->envp), e->gid);
       # endif
       		setuid(e->uid);		/* we aren't root after this... */
       		chdir(env_get("HOME", e->envp));
     *** cron.c.~1~	Tue Jun 12 06:35:35 2001
     --- cron.c	Tue Jun 12 06:17:13 2001
     ***************
     *** 25,35 ****
     
       #include "cron.h"
       #include <signal.h>
     - #if SYS_TIME_H
     - # include <sys/time.h>
     - #else
       # include <time.h>
     - #endif
     
     
       static	void	usage __P((void)),
     --- 25,31 ----

pserver cvs and lock files
==========================

The CVS pserver make heavy use of the temporary directory. Loic Dachary
<loic@gnu.org> solved this problem by using a ramdisk.

   In `/etc/fstab', was added:
     -              /mnt/ramfs    ramfs   defaults                   0      0

   `/etc/xinet.d' was modified:
     service cvspserver
     {
             socket_type     = stream
             protocol        = tcp
             wait            = no
             user            = root
             server          = /usr/bin/cvs
             bind            = 199.232.41.2
     #       disable         = yes
             instances       = 20
             server_args      = -T /mnt/ramfs --allow-root-file /etc/cvs-pserver.cvsr
     oots -f pserver
     }

sftp
====

The `sftp' is provided to Savannah project members and is implemented
in the following way to ensure security.

   * /usr/local/bin/cvssh accepts the command /usr/lib/sftp-server and
     runs /usr/local/bin/savannah-sftp instead.

   * /usr/local/bin/savannah-sftp is a root set user id bit binary that
     chroot to /upload and runs /usr/lib/savannah-sftp-server (which is
     really /upload/usr/lib/savannah-sftp-server).

   * /usr/lib/savannah-sftp-server changes the id of the process to the
     id of the user that originally requested to run sftp-server and
     runs /usr/lib/sftp-server


   The sources of savannah-sftp-server and savannah-sftp are located in
/usr/local/bin.

   The files added to /upload are the following:

     lib:
     total 2136
     -rwxr-xr-x    1 root     root        90210 Jul 12 11:41 ld-linux.so.2
     -rwxr-xr-x    1 root     root      1153784 Jul 12 11:41 libc.so.6
     -rw-r--r--    1 root     root       771088 Jul 12 11:40 libcrypto.so.0.9.6
     -rw-r--r--    1 root     root         8008 Jul 12 11:41 libdl.so.2
     -rw-r--r--    1 root     root        69472 Jul 12 11:40 libnsl.so.1
     -rw-r--r--    1 root     root         7600 Jul 12 11:39 libutil.so.1
     -rw-r--r--    1 root     root        54632 Jul 12 11:39 libz.so.1
     
     usr:
     total 4
     drwxr-xr-x    2 root     root         4096 Jul 12 12:07 lib
     
     usr/lib:
     total 40
     -rwxr-xr-x    1 root     root        14433 Jul 12 12:08 savannah-sftp-server
     -rwxr-xr-x    1 root     root        23848 Jul 12 11:20 sftp-server

lsh and ssh
===========

The `ssh' service is bound to lsh with a fallback to `ssh' for protocol
version 1. The startup of `lsh' is done with the `/etc/init.d/lsh'
script.

   The version of `lsh' installed is `1.4' compiled in
`/usr/local/src/lsh-1.4'. It includes a patch for dealing with the
NGROUPS_MAX problem described in another chapter. The patch was
activated with the following:

     --- config.h.in.~1~     Thu May 16 17:38:54 2002
     +++ config.h.in Wed Jun  5 08:01:13 2002
     @@ -1,5 +1,7 @@
      /* config.h.in.  Generated from configure.ac by autoheader.  */
     
     +#define INITGROUPS_WORKAROUND 1
     +
      /* Define to one of `_getb67', `GETB67', `getb67' for Cray-2 and Cray-YMP
         systems. This function is required for `alloca.c' support on those systems.
         */

   The people involved in this installation are Niels Moller
<nisse@lysator.liu.se> (author of lsh), Gordon Matzigkeit
<gord@fig.org> (author of the NGROUPS_MAX patch) and Loic Dachary
<loic@gnu.org> who did the installation.

   Should a problem occur with this version of lsh, one has to send a
bug report to <nisse@lysator.liu.se>Niels Moller including the relevant
`/var/log/syslog' lines (tagged with lshd) and a stack trace of the
core, if available. To get the stack trace do the following:

     $ gdb /usr/local/sbin/lshd /core
     gdb> bt

   With the appropriate information Niels is usually able to provide a
patch within very short delays.

Booting with grub and not lilo
==============================

The menu.lst used by grub is installed at (/dev/hdb2)/boot/grub/menu.lst
or, in grub jargon, hd(1,1)/boot/grub/menu.lst.

   To access it

   mount /dev/hdb2 /rescue edit /rescue/boot/grub/menu.lst umount
/rescue

Emergency situation
===================

The service-entrance.gnu.org machine has two serial lines going to
savannah.gnu.org. One that allows to see the console, the other that
allows to power cycle the machine. More information on this subject may
be found in sysadmin.texi (http://savannah.gnu.org/projects/sysadmin/).

   A full Debian installation was done on `/dev/hdb2' and can be used
if the installation is so corrupted that even a single boot will not
work. This emergency installation is labeled as such in the grub menu.

   When booting on the emergency partition, the file systems of the
regular installation are mounted under the `/subversions.gnu.org/'
directory.

   The grub menu file (menu.lst) is located on this partition, as
explained above.

Linux configuration
===================

The kernel was rebuilt in
`/usr/src/kernel-source-2.2.19pre17-2.2.19pre17' and installed from
`/usr/src/kernel-image-2.2.19pre17_512_i386.deb'.  It was recompiled
with the following patch applied to raise the maximum number of groups
per process to 512.

     *** include/asm-i386/param.h.~1~	Tue Aug  1 11:08:17 1995
     --- include/asm-i386/param.h	Sat May 26 15:44:10 2001
     ***************
     *** 8,14 ****
       #define EXEC_PAGESIZE	4096
     
       #ifndef NGROUPS
     ! #define NGROUPS		32
       #endif
     
       #ifndef NOGROUP
     --- 8,14 ----
       #define EXEC_PAGESIZE	4096
     
       #ifndef NGROUPS
     ! #define NGROUPS		512
       #endif
     
       #ifndef NOGROUP
     *** include/linux/limits.h.~1~	Tue Dec  2 16:44:40 1997
     --- include/linux/limits.h	Sat May 26 13:47:52 2001
     ***************
     *** 3,9 ****
     
       #define NR_OPEN		1024
     
     ! #define NGROUPS_MAX       32	/* supplemental group IDs are available */
       #define ARG_MAX       131072	/* # bytes of args + environ for exec() */
       #define CHILD_MAX        999    /* no limit :-) */
       #define OPEN_MAX         256	/* # open files a process may have */
     --- 3,9 ----
     
       #define NR_OPEN		1024
     
     ! #define NGROUPS_MAX      512	/* supplemental group IDs are available */
       #define ARG_MAX       131072	/* # bytes of args + environ for exec() */
       #define CHILD_MAX        999    /* no limit :-) */
       #define OPEN_MAX         256	/* # open files a process may have */

IDE Disk tweaking
=================

The configuration of the IDE disks are done in `/etc/init.d/hdparm'.
That boosts the transfert rate from 4.4Mb/s to 23.4Mb/s.

     	hdparm -k 0 -d 1 -c 3 -m 16 -a 16 -u 1 -X66 /dev/hda
     	hdparm -k 0 -d 1 -c 3 -m 16 -a 16 -u 1 -X66 /dev/hdb
     	hdparm -k 0 -d 1 -c 3 -m 16 -a 16 -u 1 -X66 /dev/hdc

Savannah themes
===============

The theme system is simpler than the SourceForge original one : HTML
code isnt redifined, the only differencies between themes are CSS file
and images.

   To create, add a theme, a new CSS file, taking as template
savannah.css, should be aded in www/css with a filename that would be
the theme name (as  new_theme.css).

   Also, the set of images should be added in
www/images/new_theme.theme/* . To get the classical images with
transparent background, just copy the files in
www/images/transparent.themes. It is recommanded to add a
non-transparent background to images since only decent www browser
support well PNG transparency (ie, today, the 19 april 2002, only
Konqueror and Mozilla support it).

   Basically, it works by setting a cookie called SV_THEME (and
eventually a SV_THEME_RANDOM) cookies. See www/include/theme2.php

Savannah elisp
==============

The file `savannah.el' can be used to get shortcuts to frequently
moderation-related commands.

   You should add this file to your GNU Emacs elisp path and add the
following to your `.emacs'

         (require `savannah)
     ;;       or
          (autoload 'savannah "/home/vrac/savannah/gnuscripts/savannah.el")

   There are many functions that insert canned answers for project
moderation purpose. It's usefull for gnus or VM users. Every functions
begin with sv. So you just have to type sv-[TAB] to get a list of
commands available.

             # The license stuff is missing in the tarball
             # It uses open in the name
             # There's confusion between commercial and proprietary
             M-x sv-[TAB]
             M-x sv-no-license
             M-x sv-use-open-in-name
             M-x sv-confusion-commercial-and-proprietary
             M-x sv-end-message

   Additionally, there are canned bash commands available. They begin
with sv-term. You need to run them in a shell/eshell. For instance:

             # Logging in
             M-x eshell
             $ ssh root@sv.gnu.org
             [...]
     
             # I want the list of projects waiting for approval.
             M-x sv-term-project-pending-list
             [RET]
     
             # This project cannot be hosted here
             # This function will remove the project from the database
             # and add a log message using sv_register_discard
             M-x sv-term-project-registration-discard
             [RET]
     
             # A user need to be renamed
             M-x sv-term-user-rename
     
             # A user need to be removed
             M-x sv-term-user-remove

   You're welcome to add/enhance this script. Keep in mind it should
make use of prexisting non-elisp scripts as possible and try to conform
to a coherent syntax (sv-use if a project use something and it's not ok,
sv-no if something is missing, sv-term for terminal-related stuff,
sv-term-user of for user-related stuff et caetera)

Index of Concepts
*****************

.symlinks:
          See ``Web CVS Symbolic links''.
/etc/aliases:
          See ``Mails and aliases''.
/etc/cron.d/savannah:
          See ``Savannah crontab''.
/etc/group:
          See ``Users and CVS synchronization''.
/etc/passwd:
          See ``Users and CVS synchronization''.
/subversions/savannah:
          See ``Subversions Installation''.
/webcvs:
          See ``Web CVS repositories''.
/webcvs CVSROOT:
          See ``Sync of www.gnu.org on commit''.
access to accounts.txt:
          See ``Account Management''.
access to savannah.xml:
          See ``Account Management''.
Account Management with Savannah:
          See ``Account Management''.
accounts.txt access:
          See ``Account Management''.
authorized_keys:
          See ``Account Management''.
backups of the database:
          See ``Database Backups''.
booting:
          See ``Booting with grub and not lilo''.
change html_cvs value:
          See ``Web CVS repositories''.
CJN:
          See ``Skill List''.
commit notification:
          See ``Getting email from CVS''.
corrupted kernel or file system:
          See ``Emergency situation''.
crash recovery:
          See ``Emergency situation''.
crontab:
          See ``Savannah crontab''.
CVS:
          See ``Introduction''.
CVS and symbolic links:
          See ``Web CVS Symbolic links''.
CVS commit notification:
          See ``Getting email from CVS''.
CVS tarbals:
          See ``Source CVS tarbals''.
disable Web CVS repository <1>:
          See ``Web CVS repositories''.
disable Web CVS repository:
          See ``Source of the CVS repositories''.
distributing tarbals:
          See ``Download area''.
document root:
          See ``Subversions Installation''.
DOCUMENT_ROOT:
          See ``Subversions Installation''.
Dump in XML:
          See ``XML Dump''.
emergency situation:
          See ``Emergency situation''.
fsffr accounts example:
          See ``Account Management''.
group file update:
          See ``Users and CVS synchronization''.
grub:
          See ``Booting with grub and not lilo''.
hdparm:
          See ``IDE Disk tweaking''.
HTML version:
          See ``Publishing this document''.
html_cvs:
          See ``Web CVS repositories''.
IDE disks performance:
          See ``IDE Disk tweaking''.
kernel patch NGROUPS_MAX:
          See ``Linux configuration''.
lilo is not installed:
          See ``Booting with grub and not lilo''.
Linux patch NGROUPS_MAX:
          See ``Linux configuration''.
machine crash:
          See ``Emergency situation''.
Makefile for XSLT files:
          See ``XML Dump''.
NGROUPS_MAX > 32:
          See ``NGROUPS_MAX''.
NGROUPS_MAX Linux patch:
          See ``Linux configuration''.
non-gnu projects web pages:
          See ``Web CVS repositories''.
passwd file update:
          See ``Users and CVS synchronization''.
powercycle machine:
          See ``Emergency situation''.
project group:
          See ``Source of the CVS repositories''.
publish:
          See ``Publishing this document''.
publishing tarbals:
          See ``Download area''.
remote boot:
          See ``Emergency situation''.
Savannah CVS:
          See ``Subversions Installation''.
Savannah definition:
          See ``Savannah''.
Savannah prefix:
          See ``Savannah software root''.
Savannah project:
          See ``Subversions Installation''.
Savannah root directory:
          See ``Subversions Installation''.
Savannah User? Savannah Admin? Project Member? Project Admin:
          See ``Introduction''.
savannah.xml access:
          See ``Account Management''.
skill:
          See ``Skill List''.
SourceForge:
          See ``Savannah''.
SourceForge fork rationale:
          See ``Savannah''.
SourceForge installation guide:
          See ``Introduction''.
statistics savannah.gnu.org:
          See ``Web Usage Statistics''.
sv_aliases <1>:
          See ``Mails and aliases''.
sv_aliases:
          See ``Subversions Installation''.
sv_backup <1>:
          See ``Source CVS tarbals''.
sv_backup <2>:
          See ``Database Backups''.
sv_backup:
          See ``Subversions Installation''.
sv_cvs <1>:
          See ``Users and CVS synchronization''.
sv_cvs:
          See ``Subversions Installation''.
sv_export_db:
          See ``Subversions Installation''.
sv_migrate:
          See ``Subversions Installation''.
sv_non-gnu2gnu.sh:
          See ``Subversions Installation''.
sv_pass:
          See ``Subversions Installation''.
sv_register_discard:
          See ``Subversions Installation''.
sv_skill:
          See ``Subversions Installation''.
sv_stat <1>:
          See ``Web Usage Statistics''.
sv_stat:
          See ``Subversions Installation''.
sv_sync_www <1>:
          See ``Sync of www.gnu.org on commit''.
sv_sync_www:
          See ``Subversions Installation''.
sv_www <1>:
          See ``Web CVS and Projects''.
sv_www:
          See ``Subversions Installation''.
sv_xml:
          See ``Subversions Installation''.
symbolic links:
          See ``Web CVS Symbolic links''.
sync of www.gnu.org sync from /webcvs:
          See ``Sync of www.gnu.org on commit''.
tarbals upload:
          See ``Download area''.
This guide on www.gnu.org:
          See ``Publishing this document''.
uploading tarbals:
          See ``Download area''.
useradd:
          See ``NGROUPS_MAX''.
usermod:
          See ``NGROUPS_MAX''.
web CVS projects rationale:
          See ``Web CVS and Projects''.
web pages for non-gnu projects:
          See ``Web CVS repositories''.
Web statistics:
          See ``Web Usage Statistics''.
webalizer.conf:
          See ``Web Usage Statistics''.
webmaster documentation:
          See ``Web CVS and Projects''.
webmasters in www:
          See ``Web CVS repositories''.
webproject group:
          See ``Web CVS repositories''.
website license <1>:
          See ``Web CVS repositories''.
website license:
          See ``Source of the CVS repositories''.
www special project <1>:
          See ``Web CVS and Projects''.
www special project:
          See ``Web CVS repositories''.
www.gnu.org in CVS:
          See ``Web CVS repositories''.
www.gnu.org sync from /webcvs:
          See ``Sync of www.gnu.org on commit''.
XML Dump:
          See ``XML Dump''.
xmlbase user:
          See ``Account Management''.
XSLT files:
          See ``XML Dump''.

...Short Contents...

...Table of Contents...
