Services hosted on GNU Savannah servers

The following is the list of various network services related to Savannah, organized by the VM they run on.

When restarting/reload/reboot a service or a VM, please check the following services are working as expected.

See also:


  • Host names
    • and point to the same IP address.
    • and likewise point to the same address.
  • File names
    • Filenames with server name are written as frontend0:/etc/apache2/foo.conf - meaning the file /etc/apache2/foo.conf on the frontend0 server (which is
    • Filenames without server name - the server is assumed to be deduced from the context.


The VM runs the Savannah website (PHP code).


The VM holds the source code (bzr,cvs,hg,git,svn) and webpages (cvs only) repositories, providing various access methods.

(The old GNU arch version control program and repositories are still present on the server, but perhaps no one is still using it. In any case, we very strongly not recommend using it for any new development, and we won't mention it further on this page. We hope to remove it completely in due course.)

vcs - project member access (commits)

  • ssh: used for read/write access to the repositories by members of a project. Before using ssh, the Savannah user must upload a public ssh key through the Savannah web interface. Upon attempted login, this user key is checked against the Savannah MySQL database, using the AuthorizedKeysExec command defined in vcs0:/etc/ssh/sshd_config. The user must also be a member of the given project.

    The repositories' access methods are:

    • bzr: bzr branch bzr+ssh://<USER><PROJECT>/branch
    • cvs: cvs -d:ext:<USER><PROJECT> co <modulename>
    • git: git clone <USER><PROJECT>.git
    • hg: hg clone ssh://<USER><PROJECT>
    • svn: svn co svn+ssh://<USER><PROJECT>/<modulename>
    • webcvs: cvs -d:ext:<USER><PROJECT> co <PROJECT>

vcs - public anonymous access (read-only)

  • rsync - read-only anonymous access to the raw repository files. configuration in vcs0:/etc/rsync.conf, started with xinetd in vcs0:/etc/xinetd.d/rsync.

    • bzr: rsync://<PROJECT>
    • cvs: rsync://<PROJECT>
    • git: rsync://<PROJECT>
    • hg: not defined.
    • svn: rsync://<PROJECT>
    • webcvs: rsync://<PROJECT>
  • bzr-daemon - read-only anonymous access to bzr repositories. configured with xinetd in vcs0:/etc/xinetd.d/bzr-hpss.

    • bzr: bzr branch bzr://
  • cvs-pserver - read-only anonymous access to cvs repositories. configured with xinetd in vcs0:/etc/xinetd.d/cvs.

    • cvs: cvs<PROJECT> co <modulename>
    • webcvs: cvs<PROJECT> co <modulename>
  • git-daemon - read-only anonymous access to git repositories. configured with xinetd in vcs0:/etc/xinetd.d/git.

    • git: git clone git://<PROJECT>.git
  • hg - not defined.

  • svn-daemon - read-only anonymous access to svn repositories. configured with xinetd in vcs0:/etc/xinetd.d/svn.

    • svn: svn co svn://

vcs - web browsing

Source code repositories:

Webpages repositories:


The hosts the following:

  • The 'downloads' (aka 'releases') for projects hosted on GNU Sanannah.
  • The content of
  • The (old, obsolete) GNU Arch repositories

See Mirmon for more information about the auto-redirection mentioned below.

Configuration details:

  • Mirror multiplexor for (The official server is managed by the FSF, and Savannah hackers have no access to it.)

    • web access: (this url auto-redirects).
    • Apache conf: download0:/etc/apache2/sites-available/download
    • uses Apache2::Geo::Mirror to redirect based on GeoIP.
  • Savannah-hosted downloads/releases: These are mostly intended for nongnu projects, as GNU projects are expected to put releases on, as detailed in the GNU Maintainer Information

  • Mirrored downloads/releases:

  • Savannah top-level download urls:

  • GNU audio-video host:

  • GNU Arch repositories:

  • rsync access

    • rsync start-up configuration file: download0:/etc/default/rsync. The configuration uses xinetd, and so all other options in this file are ignored. Instead, the parameters in download0:/etc/xinetd.d/rsync are used.
    • rsync configuration file: download0:/etc/rsyncd.conf. Available modules:
      • releases mapped to download0:/srv/download.
      • audio-video mapped to download0:/srv/audio-video.
    • Anonymous access using rsync protcol: rsync -avhP rsync://<PROJECT>/<FILE> LOCALFILE
    • Listing content of a directory: rsync rsync://<PROJECT>/
    • All Savannah members can access rsync services, using the ssh public key configured on Savannah website (see ssh section of VCS server, above).
    • Download a file using ssh public key + Savannah User: rsync -avhP <USER><PROJECT>/<FILE> LOCALFILE
    • Uploading a file (only to projects in which USER is a member): rsync -avhP LOCALFILE <USER><PROJECT>/<FILE>
  • sftp access

    • sftp <USER>


The VM runs the Savannah database (mysql).

  • Savannah database - mysql
    • Used in two contexts:
      1. The database for the Savannah PHP code (based on old SourceForge code base). These are the registered users on Savannah, registered projects, trackers (tasks, bugs, etc.), etc. Users upload their public ssh keys to Savannah web interface, and those are also stored in the database.
      2. All VMs which allow ssh access based on public ssh keys connect to the mysql database, and query the user's ssh key. Users' keys are not stored outside this database (with a few exceptions for Savannah hackers and users).
    • MySQL tcp connections are accepted only from,,, (enforced with iptables rules).
    • MySQL configuration file: internal0:/etc/mysql/my.cnf

lists handles the mailing lists for,,, and other FSF-related domains. (The FSF also uses other servers in some cases, for its mass mailings, etc.)

Configuration details:

  • DNS records: the server responds to,, and few other FSF-related sites.

  • One mailman installation handles all of the above domains (see here).

  • web access:

    • multiple configuration files in lists:/etc/apache2/sites-enabled configured to reply to different server names and ssl certificates.
    • all include the following file: lists:/etc/apache2/sites-available/
    • static html archives:
      • available from
      • stored in lists:/arc/mharc-html.
      • search cgi with namazu2 package, using:
        • pointing to
        • lists:/home/mharc/cgi-bin/namazu.cgi symlink to
        • lists:/usr/lib/cgi-bin/namazu.cgi.
    • GNU Mailman manages mailing list activities (subscriptions, moderation, etc.)
  • rsync access to mailing lists archives:

    • rsync daemon startup enabled in lists:/etc/default/rsync
    • rsync configuration in lists:/etc/rsyncd.conf:
      • Publishes module mbox, served from lists:/arc/mharc-mbox
    • To list available archives: rsync rsync://
    • To download full archive of one mailing list:
      rsync -avhP rsync:// .

Spam handling is a whole subject in itself: ListHelperAntiSpam. is administered by FSF admins, not by savannah hackers, though savannah hackers have non-root access to the machine. See ListServer for more about mailing-list management.

mgt - management

  • DNS server - bind
    • startup configuration file: internal0:/etc/default/bind9
    • bind configuration directory: internal0:/etc/bind/
    • The relevant configuration files are:
      • internal0:/etc/bind/named.conf which includes
      • internal0:/etc/bind/named.conf.local which includes
      • internal0:/etc/bind/master/savannah.{gnu,nongnu}.org which include:
      • internal0:/etc/bind/master/savannah.header - name servers and serial update timestamp
      • internal0:/etc/bind/master/savannah.footer - A and CNAME dns records for all Savannah VMs (e.g. dl / vcs / fe)
    • The server does not answer DNS queries directly. Instead, it propagates its DNS configuration to, and only answers queries from (enforced with iptables rules).
    • More about DNS: DNS.

--moretowrite-- The VM runs munin, and what else? Provides access point to get to all other sv hosts (in old days, hosts had unroutable 10.x addresses).