[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNU-traductores] old-gnudist:/home/www/html/server/standards/README.sav
|
From: |
old-gnudist's file diff daemon |
|
Subject: |
[GNU-traductores] old-gnudist:/home/www/html/server/standards/README.savannah.html -- New file |
|
Date: |
Tue, 15 Jan 2002 06:29:24 -0800 (PST) |
This is an automated report from old-gnudist.
This appears to be a new file or has only recently been added to
the list of monitored files:
81 -rw-rw-r-- 1 webcvs www 81228 Jan 9 04:10
/home/www/html/server/standards/README.savannah.html
Contents:
<html lang="en">
<head>
<title>`Savannah'</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name=description content="`Savannah'">
<meta name=generator content="makeinfo 4.0b">
<link href="http://texinfo.org/"; rel=generator-home>
</head>
<body>
<p><hr>
Node:<a name="Top">Top</a>,
Next:<a rel=next href="#Introduction">Introduction</a>
<br>
<h1>Savannah</h1>
<p>This document (<a href="#Publishing%20this%20document">Publishing this
document</a>) is for Savannah administrators, not Savannah users.
<a href="http://savannah.gnu.org/";>Savannah</a> is a <a
href="http://www.sourceforge.net";>SourceForge</a>
clone based on the
<a
href="http://download.sourceforge.net/alexandria/SF2_0.tar.gz";>SourceForge-2.0</a>
software. It is dedicated to Free Software 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
<a
href="http://savannah.gnu.org/cgi-bin/viewcvs/savannah/savannah/ChangeLog";>ChangeLog</a>
explains the modifications made to the original code.
<ul>
<li><a href="#Introduction">Introduction</a>:
<li><a href="#Installation">Installation</a>:
<li><a href="#Savannah%20Administrator">Savannah Administrator</a>:
<li><a href="#Download%20area">Download area</a>:
<li><a href="#CVS%20repositories">CVS repositories</a>:
<li><a href="#Database">Database</a>:
<li><a href="#Account%20Management">Account Management</a>:
<li><a href="#Mailman">Mailman</a>:
<li><a href="#Mails%20and%20aliases">Mails and aliases</a>:
<li><a href="#Unlock%20alias%20at%20gnu.org%20account">Unlock alias at gnu.org
account</a>:
<li><a href="#Users%20and%20CVS%20synchronization">Users and CVS
synchronization</a>:
<li><a href="#Publishing%20this%20document">Publishing this document</a>:
<li><a href="#System%20Administration">System Administration</a>:
<li><a href="#Concept%20Index">Concept Index</a>:
<p>--- The Detailed Node Listing ---
<p>CVS repositories
</p><li><a href="#Import%20repositories">Import repositories</a>:
<li><a href="#Sources%20CVS%20repositories">Sources CVS repositories</a>:
<li><a href="#Getting%20email%20from%20CVS">Getting email from CVS</a>:
<li><a href="#Source%20CVS%20tarbals">Source CVS tarbals</a>:
<li><a href="#Web%20CVS%20repositories">Web CVS repositories</a>:
<li><a href="#Web%20CVS%20Symbolic%20links">Web CVS Symbolic links</a>:
<li><a href="#Sync%20of%20www.gnu.org%20on%20commit">Sync of www.gnu.org on
commit</a>:
<li><a href="#Web%20CVS%20and%20Projects">Web CVS and Projects</a>:
<p>Getting email from CVS
</p><li><a href="#Set%20up%20a%20mailing%20list">Set up a mailing list</a>:
<li><a href="#Set%20up%20syncmail">Set up syncmail</a>:
<li><a href="#Configure%20CVS%20to%20use%20syncmail">Configure CVS to use
syncmail</a>:
<li><a href="#Read%20email!">Read email!</a>:
<p>Database
</p><li><a href="#Remote%20Access">Remote Access</a>:
<li><a href="#XML%20Dump">XML Dump</a>:
<li><a href="#Database%20Backups">Database Backups</a>:
<li><a href="#Skill%20List">Skill List</a>:
<p>System Administration
</p><li><a href="#SSL%20certificate">SSL certificate</a>:
<li><a href="#Web%20Usage%20Statistics">Web Usage Statistics</a>:
<li><a href="#Savannah%20crontab">Savannah crontab</a>:
<li><a href="#Savannah%20logs">Savannah logs</a>:
<li><a href="#Savannah%20software%20root">Savannah software root</a>:
<li><a href="#NGROUPS_MAX">NGROUPS_MAX</a>:
<li><a href="#cron">cron</a>:
<li><a href="#lsh%20and%20ssh">lsh and ssh</a>:
<li><a href="#Booting%20with%20grub%20and%20not%20lilo">Booting with grub and
not lilo</a>:
<li><a href="#Emergency%20situation">Emergency situation</a>:
<li><a href="#Linux%20configuration">Linux configuration</a>:
<li><a href="#IDE%20Disk%20tweaking">IDE Disk tweaking</a>:
</ul>
<p><hr>
Node:<a name="Introduction">Introduction</a>,
Next:<a rel=next href="#Installation">Installation</a>,
Previous:<a rel=previous href="#Top">Top</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Introduction</h1>
<p>Savannah currently provides the CVS frontend. Check the <a
href="http://savannah.gnu.org/docs/savannah-plan.html";>Development Plan</a> for
information on the future.
<p>Setting up Savannah is not an easy task because it has to integrate existing
habits and projects without breaking anything. However, the <a
href="http://www.zoy.org/~guillaum/SF/";>SourceForge Installation Guide</a> by
<a href="mailto:address@hidden";>Guillaume Morin</a> helps a lot
understanding the software.
<p><hr>
Node:<a name="Installation">Installation</a>,
Next:<a rel=next href="#Savannah%20Administrator">Savannah Administrator</a>,
Previous:<a rel=previous href="#Introduction">Introduction</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Installation</h1>
<p>Savannah is installed on the machine subversions.gnu.org. The root
of the installation is in /subversions/sourceforge. All the software
that is not system wide and is needed to run Savannah is installed in
this directory. The structure of this directory is similar to FHS-2.1.
In the following table the path names are relative to the installation
root. All directories covered by the <a
href="http://www.zoy.org/~guillaum/SF/";>SourceForge Installation Guide</a> are
omitted.
<dl>
<br><dt><code>tmp</code>
<dd>Directory to run the backend scripts.
<br><dt><code>src/savannah</code>
<dd>The SourceForge software and the <a
href="http://savannah.gnu.org/";>Savannah</a>
web pages.
<br><dt><code>src/savannah/www</code>
<dd>The document root of <a href="http://savannah.gnu.org/";>Savannah</a>
web pages.
<br><dt><code>src/savannah/gnuscripts</code>
<dd>Savannah specific backend scripts.
</dl>
<p>The whole Savannah software is <a
href="http://savannah.gnu.org/cvs/?group_id=11";>available from CVS</a> and is
managed by the <a
href="http://savannah.gnu.org/projects/savannah/";>Savannah</a> project.
<p>In order to install changes commmited in the savannah project CVS tree,
proceed as follows:
<pre>login subversions
su -
export CVS_RSH=ssh
cd /subversions/sourceforge/src/savannah
cvs -q -z3 update
</pre>
<p><hr>
Node:<a name="Savannah%20Administrator">Savannah Administrator</a>,
Next:<a rel=next href="#Download%20area">Download area</a>,
Previous:<a rel=previous href="#Installation">Installation</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Savannah Administrator</h1>
<p>At a given time only one person can be in charge of approving or
rejecting projects submitted to Savannah. The /admin/ interface is not
fit for concurrent access. The user assigned to this task is the one in
charge. It is his responsibility to find someone else before leaving :-)
People currently (Dec 2001) playing this role are
<a href="mailto:address@hidden";>Jaime E. Villate</a>, <a
href="mailto:address@hidden";>Guillaume Morin</a> and <a
href="mailto:address@hidden";>Loic Dachary</a>.
<p>The task
<a
href="https://savannah.gnu.org/pm/task.php?func=detailtask&project_task_id=54&group_id=11&group_project_id=30";>current
administrator</a>
is assigned to the person currently in charge of approving the projects
submitted to Savannah.
<p>The password of the <code>admin</code> user is known by
<a href="mailto:address@hidden";>Loic Dachary</a>, <a
href="mailto:address@hidden";>Guillaume Morin</a>, <a
href="mailto:address@hidden";>Hugo Gayosso</a> and
<a href="mailto:address@hidden";>Jaime E. Villate</a>.
<p><hr>
Node:<a name="Download%20area">Download area</a>,
Next:<a rel=next href="#CVS%20repositories">CVS repositories</a>,
Previous:<a rel=previous href="#Savannah%20Administrator">Savannah
Administrator</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Download area</h1>
<p>Each project registered on Savannah that is not part of the GNU
project is granted a publicly available file download area at
<pre>http://freesoftware.fsf.org/download/projectname/
</pre>
<p>Each project member can upload files to this directorly by using scp or
rsync over ssh to the following location:
<pre>freesoftware.fsf.org:/upload/projectname/
</pre>
<p>Sample commands for doing this are:
<pre>#
# Copy an entire tree verbatim, that may imply to remove files on
# freesoftware.fsf.org.
#
rsync --delete -av --rsh=ssh . freesoftware.fsf.org:/upload/projectname
#
# Copy a single file with scp
#
scp -q file.tar.gz freesoftware.fsf.org:/upload/projectname
#
# Copy a single file with rsync over ssh
#
rsync --rsh=ssh file.tar.gz freesoftware.fsf.org:/upload/projectname
</pre>
<p>A reminder is included in the <code>Project Admin</code> page of each
project.
<p><hr>
Node:<a name="CVS%20repositories">CVS repositories</a>,
Next:<a rel=next href="#Database">Database</a>,
Previous:<a rel=previous href="#Download%20area">Download area</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>CVS repositories</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 /cvsroot and the
web repository is in /webcvs.
<ul>
<li><a href="#Import%20repositories">Import repositories</a>:
<li><a href="#Sources%20CVS%20repositories">Sources CVS repositories</a>:
<li><a href="#Getting%20email%20from%20CVS">Getting email from CVS</a>:
<li><a href="#Source%20CVS%20tarbals">Source CVS tarbals</a>:
<li><a href="#Web%20CVS%20repositories">Web CVS repositories</a>:
<li><a href="#Web%20CVS%20Symbolic%20links">Web CVS Symbolic links</a>:
<li><a href="#Sync%20of%20www.gnu.org%20on%20commit">Sync of www.gnu.org on
commit</a>:
<li><a href="#Web%20CVS%20and%20Projects">Web CVS and Projects</a>:
</ul>
<p><hr>
Node:<a name="Import%20repositories">Import repositories</a>,
Next:<a rel=next href="#Sources%20CVS%20repositories">Sources CVS
repositories</a>,
Previous:<a rel=previous href="#CVS%20repositories">CVS repositories</a>,
Up:<a rel=up href="#CVS%20repositories">CVS repositories</a>
<br>
<h2>Import repositories</h2>
<p>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 address@hidden, 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.
<p><hr>
Node:<a name="Sources%20CVS%20repositories">Sources CVS repositories</a>,
Next:<a rel=next href="#Getting%20email%20from%20CVS">Getting email from
CVS</a>,
Previous:<a rel=previous href="#Import%20repositories">Import repositories</a>,
Up:<a rel=up href="#CVS%20repositories">CVS repositories</a>
<br>
<h2>Sources CVS repositories</h2>
<p>When a project has a license that is not <code>website</code> 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.
<p>The group <code>project</code> is created to grant write access to the
repository
to all the members of the project.
<p>When a Savannah project is assigned the <code>website</code> license, it only
has a portion of the webcvs repository and no source CVS repository.
<p>If the <code>html_cvs</code> field for a given Savannah project is empty, it
is not associated with a part of the webcvs repository.
<p>A project member may add commit notification by doing the following:
(replace <code>project</code> with the name of the project and
<code>user</code> by
the Savannah login name).
<pre>cvs -d address@hidden:/cvsroot/project co CVSROOT
In CVSROOT/commitinfo
^project /usr/local/bin/commit_prep -T project -r
In CVSROOT/loginfo
^project /usr/local/bin/log_accum -T project -C -m address@hidden -s %{sVv}
</pre>
<p>The email address must exist, it will not be automatically generated.
<p>For compatibility with the cvs setup before Savannah was introduced,
/subversions/cvs/common contains symbolic links to the corresponding
Savannah directory. Developers are encourage to stop using this
historical setup.
<p>The /cvs symbolic link points to /subversions/cvs/common so that people
already using it to access their repositories can continue to do so. Before
Savannah existed a pserver access was available and Savannah continues to
maintain it for these projects, updating the CVSROOT/passwd files with
user/password pairs that are in the Savannah database.
<p><hr>
Node:<a name="Getting%20email%20from%20CVS">Getting email from CVS</a>,
Next:<a rel=next href="#Source%20CVS%20tarbals">Source CVS tarbals</a>,
Previous:<a rel=previous href="#Sources%20CVS%20repositories">Sources CVS
repositories</a>,
Up:<a rel=up href="#CVS%20repositories">CVS repositories</a>
<br>
<h2>Getting email from CVS</h2>
<p>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.
<p>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.
<p><code>Clearly, we need more email</code>.
<ul>
<li><a href="#Set%20up%20a%20mailing%20list">Set up a mailing list</a>:
<li><a href="#Set%20up%20syncmail">Set up syncmail</a>:
<li><a href="#Configure%20CVS%20to%20use%20syncmail">Configure CVS to use
syncmail</a>:
<li><a href="#Read%20email!">Read email!</a>:
</ul>
<p><hr>
Node:<a name="Set%20up%20a%20mailing%20list">Set up a mailing list</a>,
Next:<a rel=next href="#Set%20up%20syncmail">Set up syncmail</a>,
Previous:<a rel=previous href="#Getting%20email%20from%20CVS">Getting email
from CVS</a>,
Up:<a rel=up href="#Getting%20email%20from%20CVS">Getting email from CVS</a>
<br>
<h3>Set up a mailing list</h3>
<p>If you haven't already created a mailing list to handle messages sent
by CVS, follow these instructions to do so.
<p>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 <code>Project Admin</code> page, the to the <code>Edit Public Info</code>
page. Make sure the "Use Mailing Lists:" checkbox is on, and click
"Update." Now go back to your "Project Page."
<p>Go to the <code>Mailing Lists</code> page and click through to the
<code>Admin</code> page. Select <code>Add Mailing List</code> to get a really
easy-to-use form that asks you only <code>two questions</code>:
<dl>
<dt><code>What do you want to name your list?</code>
<dd>
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
<code>myproject-commits</code>, or <code>myproject-checkins</code>?" You can
choose other names, but those are well-recognized by active Free
Software developers.
<br><dt><code>Should I let just anyone subscribe?</code>
<dd>
"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.
</dl>
<p>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.
<p><hr>
Node:<a name="Set%20up%20syncmail">Set up syncmail</a>,
Next:<a rel=next href="#Configure%20CVS%20to%20use%20syncmail">Configure CVS to
use syncmail</a>,
Previous:<a rel=previous href="#Set%20up%20a%20mailing%20list">Set up a mailing
list</a>,
Up:<a rel=up href="#Getting%20email%20from%20CVS">Getting email from CVS</a>
<br>
<h3>Set up syncmail</h3>
<p><code>syncmail</code> is a <a href="http://www.python.org/";>Python</a>
script written by Barry Warsaw to send mail to the
<code>python-checkins</code> list long ago, before the Python development
tree moved to SourceForge. It's undergone a bit of evolution, but
essentially does one thing: send email based on CVS activity. It
takes a little bit of information from CVS and generates messages that
include useful information, such as the actual changes that happened
to the modified files. It shoves all this into email that gets sent
to an email address passed on the command line. For projects with
enough developers that <code>syncmail</code> becomes interesting, this will
typically be a mailing list.
<p>For your project, this will be
<code>address@hidden</code> or
<code>address@hidden</code>, depending on the name
you chose in the first part of these instructions.
<p>To install <code>syncmail</code>, you need a working copy of the
<code>CVSROOT</code> directory from your CVS repository.
Check it out just like you did for your project modules, but with the module
name "CVSROOT".
<p>Now, get the latest version of <code>syncmail</code>. The canonical copy is
in the repository for the
<a href="http://www.list.org/";>GNU Mailman</a> mailing list manager (the one
you're using for the checkins list you set up earlier).
Get it from Savannah:
<a
href="https://savannah.gnu.org/syncmail";>https://savannah.gnu.org/syncmail</a>
<p>Save the most recent revision to your working copy of your project's
<code>CVSROOT</code> directory. Use <code>chmod +x</code>
to set the executable bit for all users, and then add the file to your
project: <code>cvs add syncmail</code>; <code>cvs commit syncmail</code>. You
probably want to mention in your comment message where the file came
from and the revision number you picked up.
<p>Now just edit the "checkoutlist" file in the CVSROOT. Just add "syncmail" to
the bottom of the file. Save it and checkin. Now syncmail will be
automatically
checked out whenever necessary.
<p><hr>
Node:<a name="Configure%20CVS%20to%20use%20syncmail">Configure CVS to use
syncmail</a>,
Next:<a rel=next href="#Read%20email!">Read email!</a>,
Previous:<a rel=previous href="#Set%20up%20syncmail">Set up syncmail</a>,
Up:<a rel=up href="#Getting%20email%20from%20CVS">Getting email from CVS</a>
<br>
<h3>Configure CVS to use syncmail</h3>
<p>Now that you've spent the better part of a day (or night) reading
these instructions, and a few minutes following them, you have just a
tiny bit more to do to get CVS to put <code>syncmail</code> to work.
<p><code>After</code> you've handled the checkout a working copy of
<code>syncmail</code>
into the repository, you need to modify your <code>CVSROOT/loginfo</code> file
to tell CVS to invoke
<code>syncmail</code> for all the interesting events CVS is willing to tell
us about.
<p>If you have not modified the <code>CVSROOT/loginfo</code> file from the
stock file provided by
Savannah (which is very useful, as the comments include
documentation), what you need to do is very simple: just add stuff to
the end. Here's some example stuff to get you started:
<pre>CVSROOT $CVSROOT/CVSROOT/syncmail %{sVv} address@hidden
DEFAULT $CVSROOT/CVSROOT/syncmail %{sVv} address@hidden
</pre>
<p>This will cause email to be sent to two different places, with which
depending on what files in the repository are affected. For
administrative files in the <code>CVSROOT</code>
directory, email will be sent to <code>address@hidden</code>; you
should probably list all your project administrators here. For all
other files, email will be sent to your mailing list (remember to
change the list name to match <code>your</code> mailing list!).
<p>If you have several sub-products for which you want different checkin
lists, you can change the "DEFAULT" label to match the subtree that
you want to go to each list, with a separate line for each distinct
prefix. For example, if your project includes the products "one" and
"two", you could use the following:
<pre>CVSROOT $CVSROOT/CVSROOT/syncmail %{sVv} address@hidden
one/ $CVSROOT/CVSROOT/syncmail %{sVv} address@hidden
+two/ $CVSROOT/CVSROOT/syncmail %{sVv} address@hidden
</pre>
<p>You can still have a "DEFAULT" line that gets used for any additional
subprojects.
<p>If you do <code>not</code> have a stock <code>CVSROOT/loginfo</code> file,
then you can probably figure out what
you need to do to combine the information above with your existing
changes. You might not have even needed any of these instructions!
<p>Check in your changes to <code>CVSROOT/loginfo</code>
and check in some other change in your working directories to test your
new configuration.
<p><hr>
Node:<a name="Read%20email!">Read email!</a>,
Previous:<a rel=previous
href="#Configure%20CVS%20to%20use%20syncmail">Configure CVS to use syncmail</a>,
Up:<a rel=up href="#Getting%20email%20from%20CVS">Getting email from CVS</a>
<br>
<h3>Read email!</h3>
<p>Now for the real test. If you have started a successful Free Software
project, you will not be able to catch up with your email. If you can
keep up with it and still have time to hack, you need to make your
project more attractive to others, so you can get more developers
checking in more changes. Then you'll always have more email than you
know what to do with!
<p><hr>
Node:<a name="Source%20CVS%20tarbals">Source CVS tarbals</a>,
Next:<a rel=next href="#Web%20CVS%20repositories">Web CVS repositories</a>,
Previous:<a rel=previous href="#Getting%20email%20from%20CVS">Getting email
from CVS</a>,
Up:<a rel=up href="#CVS%20repositories">CVS repositories</a>
<br>
<h2>Source CVS tarbals</h2>
<p>The sf_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.
<p><hr>
Node:<a name="Web%20CVS%20repositories">Web CVS repositories</a>,
Next:<a rel=next href="#Web%20CVS%20Symbolic%20links">Web CVS Symbolic
links</a>,
Previous:<a rel=previous href="#Source%20CVS%20tarbals">Source CVS tarbals</a>,
Up:<a rel=up href="#CVS%20repositories">CVS repositories</a>
<br>
<h2>Web CVS repositories</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
/webcvs/<code>html_cvs</code>. By default the <code>html_cvs</code> field has
the
value <code>/software/project/</code> 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.
<p>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.
<p>When a Savannah project is assigned the <code>website</code> license, it only
has a portion of the webcvs repository and no source CVS repository.
<p>If the <code>html_cvs</code> field for a given Savannah project is empty, it
is not associated with a part of the webcvs repository.
<p>The group <code>webproject</code> is created to grant write access to the
repository
to all the members of the project.
<p>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 <code>html_cvs</code> field), a chgrp -R webproject is done
on this repository to grant the members of the project a write access
to this portion of the web repository and only this one.
<p>The <code>www</code> project in Savannah is treated in a special way. All the
members of the <code>www</code> project have access to the whole repository
in /webcvs. It means that they are always included in every
<code>webproject</code>
created. However, the non-gnu projects and not included and webmasters may
not modify them if they are not a member of the group.
<p><hr>
Node:<a name="Web%20CVS%20Symbolic%20links">Web CVS Symbolic links</a>,
Next:<a rel=next href="#Sync%20of%20www.gnu.org%20on%20commit">Sync of
www.gnu.org on commit</a>,
Previous:<a rel=previous href="#Web%20CVS%20repositories">Web CVS
repositories</a>,
Up:<a rel=up href="#CVS%20repositories">CVS repositories</a>
<br>
<h2>Web CVS Symbolic links</h2>
<p>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.
<p>The special file <code>.symlinks</code> contains a list of file name pairs,
one per line. For instance:
<pre>foo.html index.html
bar.html other.html
</pre>
<p>is a valid <code>.symlinks</code> file. Every night a script reads all the
<code>.symlinks</code> files, prepend a <code>ln -s</code> in front of each line
and execute them. Well, in reality it's not that simple but you get
the idea. The <code>.symlinks</code> file can only be used to control the
symbolic link in the directory where they are.
<p><hr>
Node:<a name="Sync%20of%20www.gnu.org%20on%20commit">Sync of www.gnu.org on
commit</a>,
Next:<a rel=next href="#Web%20CVS%20and%20Projects">Web CVS and Projects</a>,
Previous:<a rel=previous href="#Web%20CVS%20Symbolic%20links">Web CVS Symbolic
links</a>,
Up:<a rel=up href="#CVS%20repositories">CVS repositories</a>
<br>
<h2>Sync of www.gnu.org on commit</h2>
<p>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.
<p>The /subversions/sourceforge/src/savannah/gnuscripts/sf_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.
<p>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.
<p>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.
<p>There are three cases to take in account:
<ul>
<li>commit that modify the top level directory files:
cd topdir ; cvs update -l
<li>commit that adds a new directory:
cd topdir ; cvs update 'new directory'
<li>commit that modify files in a subdirectory:
cd topdir/subdirectory ; cvs update -l
</ul>
<p>In order to prevent security compromision the directory name is quoted.
<p>The traces of all the updates are kept in /var/log/sf_sync_www.log.
<p><hr>
Node:<a name="Web%20CVS%20and%20Projects">Web CVS and Projects</a>,
Previous:<a rel=previous href="#Sync%20of%20www.gnu.org%20on%20commit">Sync of
www.gnu.org on commit</a>,
Up:<a rel=up href="#CVS%20repositories">CVS repositories</a>
<br>
<h2>Web CVS and Projects</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 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.
<p>The sf_www script generates the map that is published at
<a href="http://www.gnu.org/server/standards/www2savannah.html";>www.gnu.org to
Savannah</a>. It writes the file in
/subversions/sourceforge/src/server/standards
and commits it. The server/standards directory is a read-write checkout of
the www.gnu.org web CVS. The sf_www script is run once a day by the
crontab.
<p>A more webmaster oriented documentation explains the
<a href="http://www.gnu.org/server/standards/README.html";>organisation</a> of
the
www.gnu.org CVS tree and the rationale of its usage.
<p><hr>
Node:<a name="Database">Database</a>,
Next:<a rel=next href="#Account%20Management">Account Management</a>,
Previous:<a rel=previous href="#CVS%20repositories">CVS repositories</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Database</h1>
<p>Savannah uses MySQL and the <code>sourceforge</code> database. The root user
has
a ~/.my.cnf file that defines the user/passwd. It is not necessary to
specify them on the command line.
<ul>
<li><a href="#Remote%20Access">Remote Access</a>:
<li><a href="#XML%20Dump">XML Dump</a>:
<li><a href="#Database%20Backups">Database Backups</a>:
<li><a href="#Skill%20List">Skill List</a>:
</ul>
<p><hr>
Node:<a name="Remote%20Access">Remote Access</a>,
Next:<a rel=next href="#XML%20Dump">XML Dump</a>,
Previous:<a rel=previous href="#Database">Database</a>,
Up:<a rel=up href="#Database">Database</a>
<br>
<h2>Remote Access</h2>
<p>A read-only access to the <code>sourceforge</code> database is granted
to the following machines:
<dl>
<br><dt><code>fr.fsf.org</code>
<dd>with the user name france and the password is known by
<a href="mailto:address@hidden";>Loic Dachary</a>.
</dl>
<p><hr>
Node:<a name="XML%20Dump">XML Dump</a>,
Next:<a rel=next href="#Database%20Backups">Database Backups</a>,
Previous:<a rel=previous href="#Remote%20Access">Remote Access</a>,
Up:<a rel=up href="#Database">Database</a>
<br>
<h2>XML Dump</h2>
<p>The <code>sf_xml</code> script builds daily an XML dump of the public
information
from the Savannah database into the <code>savannah.gnu.org/savannah.xml</code>
file.
<p>In addition a dump containing information that users may not want to
publish to the public such as email and ssh public keys is built in
<code>/subversions/sourceforge/dumps/savannah.xml</code>. The command line
<pre>sf_xml --private
</pre>
<p>is used to generate this dump.
<p>A set of XSLT files can be written in the /subversions/sourceforge/dumps
directory to build custom files from the <code>savannah.xml</code> file that
is located in the same directory. This is used, for instance, for
account creation information files. If an XSLT file is created
(<code>a.xsl</code> for instance) the <code>Makefile</code> must be updated to
add the
<code>a.txt</code> file in the list of dependencies of the <code>all</code>
goal.
For instance:
<pre>all: accounts-fsffr.txt accounts.txt myown.txt
</pre>
<p>The generation of both savannah.xml files and the XSLT processing is
run daily from the crontab.
<p><hr>
Node:<a name="Database%20Backups">Database Backups</a>,
Next:<a rel=next href="#Skill%20List">Skill List</a>,
Previous:<a rel=previous href="#XML%20Dump">XML Dump</a>,
Up:<a rel=up href="#Database">Database</a>
<br>
<h2>Database Backups</h2>
<p>The MySQL database named <code>sourceforge</code> that holds all the
information used by Savannah is dumped daily. 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 /subversions/sourceforge/dumps/logrotate.conf. The
<code>sf_backup</code> script takes care of all this and is called from the
crontab.
<p><hr>
Node:<a name="Skill%20List">Skill List</a>,
Previous:<a rel=previous href="#Database%20Backups">Database Backups</a>,
Up:<a rel=up href="#Database">Database</a>
<br>
<h2>Skill List</h2>
<p>The tables <code>people_skill</code> and <code>people_skill_level</code> are
loaded
from the skill database maintained by CJN (http://cjn.sourceforge.net/).
The script /subversions/sourceforge/src/savannah/gnuscripts/sf_skill
loads the XML skill files from CJN and replace the content of the
tables in the sourceforge database.
<p>If some proprietary software shows on the skill list, add it to the
%ignore table in the sf_skill script and re-run it.
<pre>cd /subversions/sourceforge/src/savannah/gnuscripts
edit sf_skill
sf_skill
cvs commit -m 'Ignore proprietary software xxxx'
</pre>
<p><hr>
Node:<a name="Account%20Management">Account Management</a>,
Next:<a rel=next href="#Mailman">Mailman</a>,
Previous:<a rel=previous href="#Database">Database</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Account Management</h1>
<p>It is convenient to use Savannah to manage accounts on a machine that is
completly unrelated to Savannah itself. For instance, the project
<a href="http://savannah.gnu.org/projects/fsffr/";>fsffr</a> lists all the
users who should have an account on the <code>france.fsfeurope.org</code>
machine.
<p>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.
<p>A guide to install the <code>savannahusers</code> script on the target
machine is available in the <a
href="http://www.gnu.org/server/source/savannahusers.html";>savannahusers manual
page</a>. This chapter deals with the necessary
actions on the savannah.gnu.org machine, not on the target machine.
<p>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 (<a href="#XML%20Dump">XML Dump</a>).
<p>The access to the user information is restricted and has to be done
in the following way:
<pre>rsync --rsh=ssh address@hidden: .
</pre>
<p>The user <code>xmlbase</code> on savannah.gnu.org is only used for this
purpose. The ssh public key of the user doing the <code>rsync</code> on the
remote machine must be registered in the <code>authorized_keys</code> file of
the <code>xmlbase</code>. 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 :
<pre>command="rsync
--server --sender . /subversions/sourceforge/dumps/savannah.xml"
1024 35 1325...
</pre>
<p>Two files may be accessed in this way:
<dl>
<dt><code>savannah.xml</code>
<dd>the content of savannah.xml is not documented but should be reasonably
self-explanatory.
<br><dt><code>accounts.txt</code>
<dd>contains a block of lines describing the account of every user registered
on Savannah. Here is an example with long lines truncated:
<pre>loic
Loic Dachary
address@hidden
1024 35 14482406825620879676223610524821306708503540742800...
rodolphe
Rodolphe Quiedeville
address@hidden
1024 35 13773675641076158303518150007131532895996406770957...
1024 35 13392800240284295490871092259529193810644583890958...
</pre>
<p>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 <code>authorized_keys</code> file.
</dl>
<p>It is possible to generate files specific to a given target machine.
For instance the <code>account-fsffr.txt</code> file is a
selection of the users that are members of the
<a href="http://savannah.gnu.org/projects/fsffr/";>fsffr</a> projects. The
<code>Makefile</code> in the dumps directory is responsible for the creation of
these files. It uses XSLT to select the relevant informations from the
<code>savannah.xml</code> dump.
<p>Send all questions and requests to address@hidden or
to <a href="https://savannah.gnu.org/support/?group_id=11";>support requests</a>.
<p><hr>
Node:<a name="Mailman">Mailman</a>,
Next:<a rel=next href="#Mails%20and%20aliases">Mails and aliases</a>,
Previous:<a rel=previous href="#Account%20Management">Account Management</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Mailman</h1>
<h2>Current setup</h2>
<p>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.
<p>Some details regarding the setup of Mailman can be found in the
sysadmin.texi file at http://savannah.gnu.org/projects/sysadmin/.
<h2>Binding existing mailing lists</h2>
<p>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.
<h2>Adding a mailing list</h2>
<p>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 sf_xml script). A cronjob on
fencepost.gnu.org will read that dump and find which lists must be
created. It will launch the <code>newlist</code> binary and update the alias
file.
<h2>Mailing lists for GNU packages</h2>
<p>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).
<p>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).
<h2>Mailing lists for non-GNU packages</h2>
<p>The mailing lists of the Savannah projects that are not part of the
GNU project are hosted under the domain freesoftware.fsf.org. This
domain and the corresponding mailman installation are installed on
the fencepost.gnu.org machine.
<p>Mailman was installed in <code>/com/mailer/freesoftware</code>.
<p><hr>
Node:<a name="Mails%20and%20aliases">Mails and aliases</a>,
Next:<a rel=next href="#Unlock%20alias%20at%20gnu.org%20account">Unlock alias
at gnu.org account</a>,
Previous:<a rel=previous href="#Mailman">Mailman</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Mails and aliases</h1>
<p>Savannah will try to send mail to users under various circumstances (bug
reports notification, account creation etc.). In some cases it will use
the real mail address of the user, in others it will use
address@hidden In order for the address@hidden address
to work properly for outgoing mails, the /etc/email-addresses file is updated
automatically every 5 minutes with the following command:
<pre>sf_aliases
</pre>
<p>The address@hidden can <code>never</code> be used to recieve mail for
the good reason that savannah.gnu.org does not listen on the SMTP port.
<p><hr>
Node:<a name="Unlock%20alias%20at%20gnu.org%20account">Unlock alias at gnu.org
account</a>,
Next:<a rel=next href="#Users%20and%20CVS%20synchronization">Users and CVS
synchronization</a>,
Previous:<a rel=previous href="#Mails%20and%20aliases">Mails and aliases</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Unlock alias at gnu.org account</h1>
<p>People who have a simple alias address@hidden but no account on Kerberos
cannot create an account on Savannah. When they ask to unlock the
account name on address@hidden, tell them to create an account
using a fake username and to send this username to address@hidden
When receiving that user name substitute the fake login name by the desired
one:
<pre>mysql -e "update user set user_name = 'desired' where user_name = 'fake'"
sourceforge
</pre>
<p><hr>
Node:<a name="Users%20and%20CVS%20synchronization">Users and CVS
synchronization</a>,
Next:<a rel=next href="#Publishing%20this%20document">Publishing this
document</a>,
Previous:<a rel=previous href="#Unlock%20alias%20at%20gnu.org%20account">Unlock
alias at gnu.org account</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Users and CVS synchronization</h1>
<p>Must be root to run this script and make sur you export CVS_RSH=ssh.
You are advised to run it in /subversions/sourceforge/tmp, although it
is not mandatory.
<p>It is run from the crontab and the output is logged in /var/log/sf_cvs.log.
<p>The <code>sf_cvs</code> perl 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 which is unlikely).
<p>It performs the following tasks, in this order.
<dl>
<br><dt><code>Add new projects</code>
<dd>/cvsroot/project and /webcvs/software/project (or /webcvs/non-gnu/project)
directories are created.
<br><dt><code>Update existing projects</code>
<dd>Fixes projects that do not have a /webcvs/software/project
directory or a directory with wrong permissions.
<br><dt><code>Add missing users</code>
<dd>Create users (in /etc/passwd) that are bound to at least one project in
Savannah.
<br><dt><code>Remove users</code>
<dd>Remove users not bound to any project in Savannah
If user belongs to groups not managed by Savannah, just redefine
its group list.
<br><dt><code>Update existing users</code>
<dd>Modify the system files if they are not in sync with the Savannah
database.
<br><dt><code>Update the groups of anoncvs</code>
<dd>The list of groups (projects) to which anoncvs belongs is restricted
by the public/non public status of a project.
<br><dt><code>Update the CVS password file</code>
<dd>Update the /cvs/CVSROOT/passwd file to reflect the
passwd and users bound to projects in Savannah.
<br><dt><code>Create download area for non-GNU projects</code>
<dd>A directory is created at /upload/projectname, only if the project
is not part of the GNU project.
<br><dt><code>Update cvs-pserver.conf</code>
<dd>Update the list of all possible pserver roots.
</dl>
<p><hr>
Node:<a name="Publishing%20this%20document">Publishing this document</a>,
Next:<a rel=next href="#System%20Administration">System Administration</a>,
Previous:<a rel=previous href="#Users%20and%20CVS%20synchronization">Users and
CVS synchronization</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Publishing this document</h1>
<p>The HTML version of this document is published in two places:
<a href="http://savannah.gnu.org/savannah.html";>Savannah Administration
Guide</a> and
<a href="http://www.gnu.org/server/standards/README.savannah.html";>Savannah
Administration Guide</a>. The source is stored in the
<code>subversions.gnu.org:/cvsroot/savannah</code> CVS repository, in the
<code>$Source: /webcvs/server/standards/README.savannah.html,v $</code> 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/sourceforge/src/gnudocs directory
and then issue a
<pre>make publish
</pre>
<p>The <code>publish</code> goal assumes that the Savannah document root is in
../savannah/www and a read-write checkout of the www.gnu.org/server/standards
directory is in ../server/standards. It will format the document to
HTML and commit the changes to the repository.
<p><hr>
Node:<a name="System%20Administration">System Administration</a>,
Next:<a rel=next href="#Concept%20Index">Concept Index</a>,
Previous:<a rel=previous href="#Publishing%20this%20document">Publishing this
document</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>System Administration</h1>
<ul>
<li><a href="#SSL%20certificate">SSL certificate</a>:
<li><a href="#Web%20Usage%20Statistics">Web Usage Statistics</a>:
<li><a href="#Savannah%20crontab">Savannah crontab</a>:
<li><a href="#Savannah%20logs">Savannah logs</a>:
<li><a href="#Savannah%20software%20root">Savannah software root</a>:
<li><a href="#NGROUPS_MAX">NGROUPS_MAX</a>:
<li><a href="#cron">cron</a>:
<li><a href="#lsh%20and%20ssh">lsh and ssh</a>:
<li><a href="#Booting%20with%20grub%20and%20not%20lilo">Booting with grub and
not lilo</a>:
<li><a href="#Emergency%20situation">Emergency situation</a>:
<li><a href="#Linux%20configuration">Linux configuration</a>:
<li><a href="#IDE%20Disk%20tweaking">IDE Disk tweaking</a>:
</ul>
<p><hr>
Node:<a name="SSL%20certificate">SSL certificate</a>,
Next:<a rel=next href="#Web%20Usage%20Statistics">Web Usage Statistics</a>,
Previous:<a rel=previous href="#System%20Administration">System
Administration</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>SSL certificate</h2>
<p>The SSL certificate for savannah.gnu.org was generated in /etc/apache-ssl/.
Check the README file for a log of the command. There has been a lot of
discussions regarding the root certificate for GNU, the use of a PKI. At
some point the savannah certificate will be generated using a proper
root certificate.
<p><hr>
Node:<a name="Web%20Usage%20Statistics">Web Usage Statistics</a>,
Next:<a rel=next href="#Savannah%20crontab">Savannah crontab</a>,
Previous:<a rel=previous href="#SSL%20certificate">SSL certificate</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>Web Usage Statistics</h2>
<p>Statistics for savannah.gnu.org web usage are generated using webalizer.
The <code>sf_stat</code> script does the job on a daily basis (called from the
crontab) using the <code>webalizer.conf</code> in the
/subversions/sourceforge/src/savannah/www/webalizer directory and moving
the generated report in the same directory.
<p>The <code>sf_stat</code> script is also called before rotating logs, as
specified
in the <code>/etc/apache-ssl/cron.conf</code> script.
<p><hr>
Node:<a name="Savannah%20crontab">Savannah crontab</a>,
Next:<a rel=next href="#Savannah%20logs">Savannah logs</a>,
Previous:<a rel=previous href="#Web%20Usage%20Statistics">Web Usage
Statistics</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>Savannah crontab</h2>
<p>The Savannah crontab jobs are in /etc/cron.d/savannah. Every cron command
output is sent to address@hidden
<pre>PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:/subversions/sourceforge/bin:/usr/local/mysql/bin
address@hidden
#
# Build /etc/aliases,
# http://savannah.gnu.org/savannah.html#Mails%20and%20aliases
#
*/5 * * * * root sf_aliases
#
# Build www map,
# http://savannah.gnu.org/savannah.html#Web%20CVS%20and%20Projects
#
10 4 * * * root sf_www
#
# Sync projects with CVS related system files,
# http://savannah.gnu.org/savannah.html#Users%20and%20CVS%20synchronization
#
17 * * * * root cd /subversions/sourceforge/tmp ; sf_cvs | ( date ; sh
-x ) >> /var/log/sf_cvs.log 2>&1
#
# Daily backups of the Savannah database,
# http://savannah.gnu.org/savannah.html#Database%20Backups
#
7 5 * * * root sf_backup
#
# Daily XML dump of Savannah public information
# http://savannah.gnu.org/savannah.html#XML%20Dump
#
7 6 * * * root sf_xml >
/subversions/sourceforge/src/savannah/www/savannah.xml
14 6 * * * root sf_xml --private >
/subversions/sourceforge/dumps/savannah.xml
30 6 * * * root make -s -C /subversions/sourceforge/dumps all
0 */1 * * * root sf_xml --list >
/subversions/sourceforge/dumps/list.xml
#
# Daily web server statistics
# http://savannah.gnu.org/savannah.html#Web%20Usage%20Statistics
#
7 7 * * * root sf_stat
</pre>
<p><hr>
Node:<a name="Savannah%20logs">Savannah logs</a>,
Next:<a rel=next href="#Savannah%20software%20root">Savannah software root</a>,
Previous:<a rel=previous href="#Savannah%20crontab">Savannah crontab</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>Savannah logs</h2>
<p>The logs of the Savannah scripts are in <code>/var/log</code>. They are
rotated by the <code>/etc/logrotate.d/savannah</code> configuration file of
logrotate.
<dl>
<br><dt><code>/var/log/sf_cvs.log</code>
<dd>Modification of the the system files from the mysql database information
so that CVS, upload etc can work properly.
<br><dt><code>/var/log/sf_sync_www.log</code>
<dd>Loginfo and update information generated by the sf_sync_www program.
This file <code>must</code> be read-write for everyone.
<br><dt><code>/var/log/apache-ssl/access.log</code>
<dd>savannah.gnu.org web server logs.
</dl>
<p><hr>
Node:<a name="Savannah%20software%20root">Savannah software root</a>,
Next:<a rel=next href="#NGROUPS_MAX">NGROUPS_MAX</a>,
Previous:<a rel=previous href="#Savannah%20logs">Savannah logs</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>Savannah software root</h2>
<p>All software that is not system wide but only used for the purpose of
Savannah must be installed in the prefix /subversions/sourceforge.
<p>The MySQL installation is an exception that must be fixed. It is installed
with the /usr/local/mysql prefix. It was not installed from the debian
package because I (address@hidden) was not able to fix the MySQL-3.23
package to make it work on potato. Now that the machine runs woody, this
historical hack should be removed.
<p><hr>
Node:<a name="NGROUPS_MAX">NGROUPS_MAX</a>,
Next:<a rel=next href="#cron">cron</a>,
Previous:<a rel=previous href="#Savannah%20software%20root">Savannah software
root</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>NGROUPS_MAX</h2>
<p>The large number of groups a user can have (>32) implies to modify
some basic programs (namely useradd and usermod).
<p>The cvs-1.11.1p1 executable was patched and the patches are available
at cvs-1.11.1p1-2001-12-11.patch.
<p>Here is the patch applied to /usr/local/src/shadow-19990827. The
modified usermod and useradd have been installed in
/subversions/sourceforge/bin.
<pre>*** ./debian/rules.~1~ Fri Feb 9 02:05:06 2001
--- ./debian/rules Fri Feb 9 02:05:41 2001
***************
*** 38,44 ****
ifneq ($(DEB_HOST_GNU_SYSTEM),gnu)
include debian/scripts/login.mk
package-list += binary-login
! config_options += --with-libpam
control_defs += -DMODDEP="(>= 0.72-5)"
endif
--- 38,44 ----
ifneq ($(DEB_HOST_GNU_SYSTEM),gnu)
include debian/scripts/login.mk
package-list += binary-login
! # config_options += --with-libpam
control_defs += -DMODDEP="(>= 0.72-5)"
endif
*** ./build-tree/shadow-19990827/libmisc/addgrps.c.~1~ Mon Dec 28 12:34:41 1998
--- ./build-tree/shadow-19990827/libmisc/addgrps.c Fri Feb 9 03:04:47 2001
***************
*** 20,25 ****
--- 20,28 ----
* already there. Warning: uses strtok().
*/
+ #undef NGROUPS_MAX
+ #define NGROUPS_MAX 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;
</pre>
<p>The sshd daemon has been rebuilt with the following patch so that CVS
ssh operations have the proper set of groups. The sources are in
/usr/local/src/openssh-1.2.3/ and the corresponding debian package is at
/usr/local/src/ssh_1.2.3-9.2loic_i386.deb. The package was tagged on
hold using dselect to prevent accidental upgrade. Note that this patch
may have hideous impact for users who have real account and use ssh
since most of the commands that deal with groups have not been
recompiled to handle more than the limit of 32 groups. For instance the
id command will core dump. Here is the patch applied on the
distribution:
<pre>*** sshd.c.~1~ Fri Mar 17 04:40:18 2000
--- sshd.c Tue Feb 13 06:32:17 2001
***************
*** 147,152 ****
--- 151,240 ----
const char *display, const char *auth_proto,
const char *auth_data, const char *ttyname);
+ #ifdef AUTH_SERVER_SUPPORT
+ #ifdef HAVE_GETSPNAM
+ #include <shadow.h>
+ #endif
+ #endif /* AUTH_SERVER_SUPPORT */
+
+ /* The GNU C Library currently has a compile-time limit on the number of
+ groups a user may be a part of, even if the underlying kernel has been
+ fixed, and so we define our own initgroups. */
+ #include <grp.h>
+ static int
+ xinitgroups (char *user, gid_t gid)
+ {
+ struct group *grp;
+ gid_t *buf;
+ int buflen, ngroups;
+
+ /* Initialise the list with the specified GID. */
+ ngroups = 0;
+ buflen = 16;
+ buf = malloc (buflen * sizeof (*buf));
+ buf[ngroups ++] = gid;
+
+ setgrent ();
+ while ((grp = getgrent ()))
+ {
+ /* Scan the member list for our user. */
+ char **p = grp->gr_mem;
+ while (*p && strcmp (*p, user))
+ p ++;
+
+ if (*p)
+ {
+ /* We found the user in this group. */
+ if (ngroups == buflen)
+ {
+ /* Enlarge the group list. */
+ buflen *= 2;
+ buf = realloc (buf, buflen * sizeof (*buf));
+ }
+
+ /* Add the group id to our list. */
+ buf[ngroups ++] = grp->gr_gid;
+ }
+ }
+ endgrent ();
+
+ /* Return whatever setgroups says. */
+ buflen = setgroups (ngroups, buf);
+ free (buf);
+ return buflen;
+ }
+ #define initgroups xinitgroups
+
+ /* This worked fine, and was adopted into glibc, until setgroups got a
+ similar limitation, so we override it as well. */
+ #include <linux/posix_types.h>
+ #include <sys/syscall.h>
+ #include <errno.h>
+
+ int
+ setgroups (size_t n, const gid_t *groups)
+ {
+ size_t i;
+ __kernel_gid_t kernel_groups[n];
+
+ for (i = 0; i < n; i ++)
+ kernel_groups[i] = groups[i];
+
+ {
+ long res;
+ __asm__ volatile ("int $0x80"
+ : "=a" (res)
+ : "0" (__NR_setgroups),"b" ((long)(n)),
+ "c" ((long)(kernel_groups)));
+
+ if ((unsigned long)(res) >= (unsigned long)(-125)) {
+ errno = -res;
+ res = -1;
+ }
+ return (int) (res);
+ }
+ }
+
/*
* Remove local Xauthority file.
*/
</pre>
<p><hr>
Node:<a name="cron">cron</a>,
Next:<a rel=next href="#lsh%20and%20ssh">lsh and ssh</a>,
Previous:<a rel=previous href="#NGROUPS_MAX">NGROUPS_MAX</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>cron</h2>
<p>The cron daemon was recompiled from <code>/usr/local/src/cron-3.0pl1/</code>
with
the following patch applied, to fix the NGROUPS_MAX limit.
<pre>*** 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 ----
</pre>
<p><hr>
Node:<a name="lsh%20and%20ssh">lsh and ssh</a>,
Next:<a rel=next href="#Booting%20with%20grub%20and%20not%20lilo">Booting with
grub and not lilo</a>,
Previous:<a rel=previous href="#cron">cron</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>lsh and ssh</h2>
<p>The <code>ssh</code> service is bound to
<a href="http://www.net.lut.ac.uk/psst/";>lsh</a> with a fallback to
<code>ssh</code>
for protocol version 1. The startup of <code>lsh</code> is done with the
<code>/etc/init.d/lsh</code> script.
<p>The version of <code>lsh</code> installed is <code>1.2.1</code> compiled in
<code>/usr/local/src/lsh-1.2.1</code>. It includes a patch for dealing
with the NGROUPS_MAX problem described in another chapter.
<p>An entropy initialization bug was fixed with the following patch:
<pre>Index: lshd.c
===================================================================
RCS file: /lysator/cvsroot//nisse/lsh/src/lshd.c,v
retrieving revision 1.112.2.1
diff -u -a -r1.112.2.1 lshd.c
--- lshd.c 2001/04/17 21:42:16 1.112.2.1
+++ lshd.c 2001/04/25 18:32:47
@ -480,9 +480,6 @
else
argp_error(state, "All user authentication methods disabled.");
- /* Start background poll */
- RANDOM_POLL_BACKGROUND(self->random->poller);
-
break;
}
case 'p':
@ -751,6 +748,13 @
return EXIT_FAILURE;
}
+ /* NOTE: We have to do this *after* forking into the background,
+ * because otherwise we won't be able to waitpid() on the background
+ * process. */
+
+ /* Start background poll */
+ RANDOM_POLL_BACKGROUND(options->random->poller);
+
{
/* Commands to be invoked on the connection */
struct object_list *connection_hooks;
</pre>
<p>A patch to gracefully handle utf8 errors in passwords was applied:
<pre>diff -u -r1.31 server_userauth.c
--- server_userauth.c 2001/02/25 22:38:20 1.31
+++ server_userauth.c 2001/06/25 12:26:57
@ -343,9 +343,12 @
connection->dispatch[SSH_MSG_USERAUTH_REQUEST] =
make_userauth_handler(self->methods, self->services,
c, e,
+ /* Use the connection's exception handler as
+ * parent, in order to get reasonable
+ * handling of EXC_PROTOCOL. */
make_exc_userauth_handler(connection,
self->advertised_methods,
- AUTH_ATTEMPTS, e,
+ AUTH_ATTEMPTS,
connection->e,
HANDLER_CONTEXT));
}
</pre>
<p>The error message issued by lsh when encountering this error was:
<pre>Unhandled exception of type 0x1000: Invalid utf8 in password.
</pre>
<p>A dsa internal error bug was fixed with the following patch:
<pre>diff -u -a -r1.26 dsa.c
--- dsa.c 2001/02/08 16:33:01 1.26
+++ dsa.c 2001/07/15 16:18:15
@ -525,7 +525,8 @
break;
default:
- fatal("do_dsa_sign: Internal error.");
+ fatal("do_dsa_sign: Internal error, unexpected algorithm %a.\n",
+ algorithm);
}
mpz_clear(r);
mpz_clear(s);
</pre>
<p>The error message issued by lsh when encountering this error was:
<pre>do_dsa_sign: Internal error.
</pre>
<p>It seems that werror("...%a...") couldn't handle the atom 0, which is
used to represent any algorithm not present in lsh's list in atoms.in.
It was fixed with the following patch:
<pre>--- src/werror.c 2001/07/04 18:37:56 1.61
+++ src/werror.c 2001/09/12 07:23:51
@ -429,11 +429,11 @
case 'a':
{
int atom = va_arg(args, int);
-
- assert(atom);
- werror_write(get_atom_length(atom), get_atom_name(atom));
-
+ if (atom)
+ werror_write(get_atom_length(atom), get_atom_name(atom));
+ else
+ werror_write(9, "<unknown>");
break;
}
case 's':
</pre>
<p>The error message issued by lsh when encountering this error was:
<pre>do_exc_connection_handler: Raising exception locking connection.
(type 1048577), using handler installed by handshake.c:355: do_handshake
</pre>
<p>This shows that "ssh-dss" is selected as the host algorithm to use,
which is identified internally by lsh(d) as the integer ATOM_SSH_DSS.
However, when that integer has been passed all the way down to
dh_make_server_msg and do_dsa_sign, that value has been replaced by
zero.
It was fixed with the following patch:
<pre>--- src/server_keyexchange.c 2001/02/25 22:38:20 1.47
+++ src/server_keyexchange.c 2001/09/19 11:24:19
@ -135,9 +135,8 @
{
hostkey_algorithm = ATOM_SSH_DSS_KLUDGE_LOCAL;
}
- else
#endif
- dh->hostkey_algorithm = hostkey_algorithm;
+ dh->hostkey_algorithm = hostkey_algorithm;
dh->algorithms = algorithms;
</pre>
<p>The error message issued by lsh when encountering this error was:
<pre>Client version: SSH-1.99-2.0.13 (non-commercial) Server version:
SSH-1.99-lshd_1.2.1 lsh - a free ssh
Selected keyexchange algorithm: diffie-hellman-group1-sha1 with hostkey
algorithm: ssh-dss
</pre>
<p>The people involved in this installation are
<a href="mailto:address@hidden";>Niels Moller</a> (author of lsh),
<a href="mailto:address@hidden";>Gordon Matzigkeit</a> (author of the NGROUPS_MAX
patch) and <a href="mailto:address@hidden";>Loic Dachary</a> who did the
installation.
<p>Should a problem occur with this version of lsh, one has to send a bug
report to <a href="mailto:address@hidden";>address@hidden</a>Niels Moller
including the
relevant <code>/var/log/syslog</code> lines (tagged with lshd) and a stack
trace of the core, if available. To get the stack trace do the following:
<pre>$ gdb /usr/local/sbin/lshd /core
gdb> bt
</pre>
<p>With the appropriate information Niels is usually able to provide a patch
within very short delays.
<p><hr>
Node:<a name="Booting%20with%20grub%20and%20not%20lilo">Booting with grub and
not lilo</a>,
Next:<a rel=next href="#Emergency%20situation">Emergency situation</a>,
Previous:<a rel=previous href="#lsh%20and%20ssh">lsh and ssh</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>Booting with grub and not lilo</h2>
<p>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.
<p>To access it
<p>mount /dev/hdb2 /rescue
edit /rescue/boot/grub/menu.lst
umount /rescue
<p><hr>
Node:<a name="Emergency%20situation">Emergency situation</a>,
Next:<a rel=next href="#Linux%20configuration">Linux configuration</a>,
Previous:<a rel=previous
href="#Booting%20with%20grub%20and%20not%20lilo">Booting with grub and not
lilo</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>Emergency situation</h2>
<p>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/).
<p>A full Debian installation was done on <code>/dev/hdb2</code> 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.
<p>When booting on the emergency partition, the file systems of the regular
installation are mounted under the <code>/subversions.gnu.org/</code> directory.
<p>The grub menu file (menu.lst) is located on this partition, as explained
above.
<p><hr>
Node:<a name="Linux%20configuration">Linux configuration</a>,
Next:<a rel=next href="#IDE%20Disk%20tweaking">IDE Disk tweaking</a>,
Previous:<a rel=previous href="#Emergency%20situation">Emergency situation</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>Linux configuration</h2>
<p>The kernel was rebuilt in
<code>/usr/src/kernel-source-2.2.19pre17-2.2.19pre17</code>
and installed from <code>/usr/src/kernel-image-2.2.19pre17_512_i386.deb</code>.
It was recompiled with the following patch applied to raise the maximum
number of groups per process to 512.
<pre>*** 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 */
</pre>
<p><hr>
Node:<a name="IDE%20Disk%20tweaking">IDE Disk tweaking</a>,
Previous:<a rel=previous href="#Linux%20configuration">Linux configuration</a>,
Up:<a rel=up href="#System%20Administration">System Administration</a>
<br>
<h2>IDE Disk tweaking</h2>
<p>The configuration of the IDE disks are done in
<code>/etc/init.d/hdparm</code>.
That boosts the transfert rate from 4.4Mb/s to 23.4Mb/s.
<pre> 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
</pre>
<p><hr>
Node:<a name="Concept%20Index">Concept Index</a>,
Previous:<a rel=previous href="#System%20Administration">System
Administration</a>,
Up:<a rel=up href="#Top">Top</a>
<br>
<h1>Index of Concepts</h1>
<ul compact>
<li>.symlinks: <a href="#Web%20CVS%20Symbolic%20links">Web CVS Symbolic
links</a>
<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>/etc/group: <a href="#Users%20and%20CVS%20synchronization">Users and CVS
synchronization</a>
<li>/etc/passwd: <a href="#Users%20and%20CVS%20synchronization">Users and CVS
synchronization</a>
<li>/subversions/sourceforge: <a href="#Installation">Installation</a>
<li>/webcvs: <a href="#Web%20CVS%20repositories">Web CVS repositories</a>
<li>/webcvs CVSROOT: <a href="#Sync%20of%20www.gnu.org%20on%20commit">Sync of
www.gnu.org on commit</a>
<li>access to accounts.txt: <a href="#Account%20Management">Account
Management</a>
<li>access to savannah.xml: <a href="#Account%20Management">Account
Management</a>
<li>Account Management with Savannah: <a href="#Account%20Management">Account
Management</a>
<li>accounts.txt access: <a href="#Account%20Management">Account Management</a>
<li>authorized_keys: <a href="#Account%20Management">Account Management</a>
<li>backups of the database: <a href="#Database%20Backups">Database Backups</a>
<li>booting: <a href="#Booting%20with%20grub%20and%20not%20lilo">Booting with
grub and not lilo</a>
<li>change html_cvs value: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>
<li>CJN: <a href="#Skill%20List">Skill List</a>
<li>commit notification: <a href="#Sources%20CVS%20repositories">Sources CVS
repositories</a>
<li>corrupted kernel or file system: <a href="#Emergency%20situation">Emergency
situation</a>
<li>crash recovery: <a href="#Emergency%20situation">Emergency situation</a>
<li>crontab: <a href="#Savannah%20crontab">Savannah crontab</a>
<li>CVS: <a href="#Introduction">Introduction</a>
<li>CVS and symbolic links: <a href="#Web%20CVS%20Symbolic%20links">Web CVS
Symbolic links</a>
<li>CVS commit notification: <a href="#Sources%20CVS%20repositories">Sources
CVS repositories</a>
<li>CVS tarbals: <a href="#Source%20CVS%20tarbals">Source CVS tarbals</a>
<li>disable Web CVS repository: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>, <a href="#Sources%20CVS%20repositories">Sources CVS
repositories</a>
<li>distributing tarbals: <a href="#Download%20area">Download area</a>
<li>document root: <a href="#Installation">Installation</a>
<li>DOCUMENT_ROOT: <a href="#Installation">Installation</a>
<li>Dump in XML: <a href="#XML%20Dump">XML Dump</a>
<li>emergency situation: <a href="#Emergency%20situation">Emergency
situation</a>
<li>fsffr accounts example: <a href="#Account%20Management">Account
Management</a>
<li>group file update: <a href="#Users%20and%20CVS%20synchronization">Users and
CVS synchronization</a>
<li>grub: <a href="#Booting%20with%20grub%20and%20not%20lilo">Booting with grub
and not lilo</a>
<li>hdparm: <a href="#IDE%20Disk%20tweaking">IDE Disk tweaking</a>
<li>HTML version: <a href="#Publishing%20this%20document">Publishing this
document</a>
<li>html_cvs: <a href="#Web%20CVS%20repositories">Web CVS repositories</a>
<li>IDE disks performance: <a href="#IDE%20Disk%20tweaking">IDE Disk
tweaking</a>
<li>kernel patch NGROUPS_MAX: <a href="#Linux%20configuration">Linux
configuration</a>
<li>lilo is not installed: <a
href="#Booting%20with%20grub%20and%20not%20lilo">Booting with grub and not
lilo</a>
<li>Linux patch NGROUPS_MAX: <a href="#Linux%20configuration">Linux
configuration</a>
<li>machine crash: <a href="#Emergency%20situation">Emergency situation</a>
<li>Makefile for XSLT files: <a href="#XML%20Dump">XML Dump</a>
<li>MySQL prefix: <a href="#Savannah%20software%20root">Savannah software
root</a>
<li>NGROUPS_MAX > 32: <a href="#NGROUPS_MAX">NGROUPS_MAX</a>
<li>NGROUPS_MAX Linux patch: <a href="#Linux%20configuration">Linux
configuration</a>
<li>non-gnu projects web pages: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>
<li>passwd file update: <a href="#Users%20and%20CVS%20synchronization">Users
and CVS synchronization</a>
<li>powercycle machine: <a href="#Emergency%20situation">Emergency situation</a>
<li>project group: <a href="#Sources%20CVS%20repositories">Sources CVS
repositories</a>
<li>publish: <a href="#Publishing%20this%20document">Publishing this
document</a>
<li>publishing tarbals: <a href="#Download%20area">Download area</a>
<li>remote boot: <a href="#Emergency%20situation">Emergency situation</a>
<li>Savannah CVS: <a href="#Installation">Installation</a>
<li>Savannah definition: <a href="#Top">Top</a>
<li>Savannah prefix: <a href="#Savannah%20software%20root">Savannah software
root</a>
<li>Savannah project: <a href="#Installation">Installation</a>
<li>Savannah root directory: <a href="#Installation">Installation</a>
<li>savannah.xml access: <a href="#Account%20Management">Account Management</a>
<li>sf_aliases: <a href="#Mails%20and%20aliases">Mails and aliases</a>, <a
href="#Installation">Installation</a>
<li>sf_backup: <a href="#Database%20Backups">Database Backups</a>, <a
href="#Source%20CVS%20tarbals">Source CVS tarbals</a>, <a
href="#Installation">Installation</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="#Installation">Installation</a>
<li>sf_non-gnu2gnu.sh: <a href="#Installation">Installation</a>
<li>sf_pass: <a href="#Installation">Installation</a>
<li>sf_skill: <a href="#Installation">Installation</a>
<li>sf_stat: <a href="#Web%20Usage%20Statistics">Web Usage Statistics</a>, <a
href="#Installation">Installation</a>
<li>sf_sync_www: <a href="#Sync%20of%20www.gnu.org%20on%20commit">Sync of
www.gnu.org on commit</a>, <a href="#Installation">Installation</a>
<li>sf_www: <a href="#Web%20CVS%20and%20Projects">Web CVS and Projects</a>, <a
href="#Installation">Installation</a>
<li>sf_xml: <a href="#Installation">Installation</a>
<li>skill: <a href="#Skill%20List">Skill List</a>
<li>SourceForge: <a href="#Top">Top</a>
<li>SourceForge fork rationale: <a href="#Top">Top</a>
<li>SourceForge installation guide: <a href="#Introduction">Introduction</a>
<li>statistics savannah.gnu.org: <a href="#Web%20Usage%20Statistics">Web Usage
Statistics</a>
<li>symbolic links: <a href="#Web%20CVS%20Symbolic%20links">Web CVS Symbolic
links</a>
<li>sync of www.gnu.org sync from /webcvs: <a
href="#Sync%20of%20www.gnu.org%20on%20commit">Sync of www.gnu.org on commit</a>
<li>tarbals upload: <a href="#Download%20area">Download area</a>
<li>This guide on www.gnu.org: <a
href="#Publishing%20this%20document">Publishing this document</a>
<li>uploading tarbals: <a href="#Download%20area">Download area</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="#Web%20CVS%20and%20Projects">Web CVS
and Projects</a>
<li>web pages for non-gnu projects: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>
<li>Web statistics: <a href="#Web%20Usage%20Statistics">Web Usage Statistics</a>
<li>webalizer.conf: <a href="#Web%20Usage%20Statistics">Web Usage Statistics</a>
<li>webmaster documentation: <a href="#Web%20CVS%20and%20Projects">Web CVS and
Projects</a>
<li>webmasters in www: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>
<li>webproject group: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>
<li>website license: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>, <a href="#Sources%20CVS%20repositories">Sources CVS
repositories</a>
<li>www special project: <a href="#Web%20CVS%20and%20Projects">Web CVS and
Projects</a>, <a href="#Web%20CVS%20repositories">Web CVS repositories</a>
<li>www.gnu.org in CVS: <a href="#Web%20CVS%20repositories">Web CVS
repositories</a>
<li>www.gnu.org sync from /webcvs: <a
href="#Sync%20of%20www.gnu.org%20on%20commit">Sync of www.gnu.org on commit</a>
<li>XML Dump: <a href="#XML%20Dump">XML Dump</a>
<li>xmlbase user: <a href="#Account%20Management">Account Management</a>
<li>XSLT files: <a href="#XML%20Dump">XML Dump</a>
</ul>
<h1>Table of Contents</h1>
<ul>
<li><a href="#Top">Savannah</a>
<li><a href="#Introduction">Introduction</a>
<li><a href="#Installation">Installation</a>
<li><a href="#Savannah%20Administrator">Savannah Administrator</a>
<li><a href="#Download%20area">Download area</a>
<li><a href="#CVS%20repositories">CVS repositories</a>
<ul>
<li><a href="#Import%20repositories">Import repositories</a>
<li><a href="#Sources%20CVS%20repositories">Sources CVS repositories</a>
<li><a href="#Getting%20email%20from%20CVS">Getting email from CVS</a>
<ul>
<li><a href="#Set%20up%20a%20mailing%20list">Set up a mailing list</a>
<li><a href="#Set%20up%20syncmail">Set up syncmail</a>
<li><a href="#Configure%20CVS%20to%20use%20syncmail">Configure CVS to use
syncmail</a>
<li><a href="#Read%20email!">Read email!</a>
</ul>
<li><a href="#Source%20CVS%20tarbals">Source CVS tarbals</a>
<li><a href="#Web%20CVS%20repositories">Web CVS repositories</a>
<li><a href="#Web%20CVS%20Symbolic%20links">Web CVS Symbolic links</a>
<li><a href="#Sync%20of%20www.gnu.org%20on%20commit">Sync of www.gnu.org on
commit</a>
<li><a href="#Web%20CVS%20and%20Projects">Web CVS and Projects</a>
</ul>
<li><a href="#Database">Database</a>
<ul>
<li><a href="#Remote%20Access">Remote Access</a>
<li><a href="#XML%20Dump">XML Dump</a>
<li><a href="#Database%20Backups">Database Backups</a>
<li><a href="#Skill%20List">Skill List</a>
</ul>
<li><a href="#Account%20Management">Account Management</a>
<li><a href="#Mailman">Mailman</a>
<ul>
<li><a href="#Mailman">Current setup</a>
<li><a href="#Mailman">Binding existing mailing lists</a>
<li><a href="#Mailman">Adding a mailing list</a>
<li><a href="#Mailman">Mailing lists for GNU packages</a>
<li><a href="#Mailman">Mailing lists for non-GNU packages</a>
</ul>
<li><a href="#Mails%20and%20aliases">Mails and aliases</a>
<li><a href="#Unlock%20alias%20at%20gnu.org%20account">Unlock alias at gnu.org
account</a>
<li><a href="#Users%20and%20CVS%20synchronization">Users and CVS
synchronization</a>
<li><a href="#Publishing%20this%20document">Publishing this document</a>
<li><a href="#System%20Administration">System Administration</a>
<ul>
<li><a href="#SSL%20certificate">SSL certificate</a>
<li><a href="#Web%20Usage%20Statistics">Web Usage Statistics</a>
<li><a href="#Savannah%20crontab">Savannah crontab</a>
<li><a href="#Savannah%20logs">Savannah logs</a>
<li><a href="#Savannah%20software%20root">Savannah software root</a>
<li><a href="#NGROUPS_MAX">NGROUPS_MAX</a>
<li><a href="#cron">cron</a>
<li><a href="#lsh%20and%20ssh">lsh and ssh</a>
<li><a href="#Booting%20with%20grub%20and%20not%20lilo">Booting with grub and
not lilo</a>
<li><a href="#Emergency%20situation">Emergency situation</a>
<li><a href="#Linux%20configuration">Linux configuration</a>
<li><a href="#IDE%20Disk%20tweaking">IDE Disk tweaking</a>
</ul>
<li><a href="#Concept%20Index">Index of Concepts</a>
</ul>
</body></html>
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNU-traductores] old-gnudist:/home/www/html/server/standards/README.savannah.html -- New file,
old-gnudist's file diff daemon <=