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:

Conventions

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

frontend

The frontend2.savannah.gnu.org VM runs the Savannah website (PHP code and this wiki).

vcs hosts

The vcs0, vcs1, vcs2 VMs hold the source code (bzr, cvs, hg, git, svn) and webpages (cvs only) repositories, providing various access methods.

(The old GNU Arch repositories are still available for download.)

vcs - group member access (commits)

  • ssh: used for read/write access to the repositories by members of a group. 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 AuthorizedKeysCommand command defined in vcs0:/etc/ssh/sshd_config. The user must also be a member of the given group.

    The repositories' access methods are:

    • bzr: bzr branch bzr+ssh://<USER>@bzr.savannah.nongnu.org/<GROUP>/branch
    • cvs: cvs -d:ext:<USER>@cvs.savannah.nongnu.org:/sources/<GROUP> co <modulename>
    • git: git clone <USER>@git.savannah.gnu.org:/srv/git/<GROUP>.git
    • hg: hg clone ssh://<USER>@hg.savannah.gnu.org/<GROUP>
    • svn: svn co svn+ssh://<USER>@svn.savannah.gnu.org/<GROUP>/<modulename>
    • webcvs: cvs -d:ext:<USER>@cvs.savannah.nongnu.org:/web/<GROUP> co <GROUP>

vcs - public anonymous access (read-only)

  • rsync - read-only anonymous access to the raw repository files. Configuration in vcsN:/etc/rsync.conf, started with xinetd in vcsN:/etc/xinetd.d/rsync, where N is 0 for bzr, hg, svn, arch; 1 for cvs, webcvs; 2 for git.

    • bzr: rsync://bzr.savannah.gnu.org/bzr/<GROUP>
    • cvs: rsync://cvs.savannah.gnu.org/sources/<GROUP>
    • git: rsync://svn.savannah.gnu.org/git/<GROUP>
    • hg: rsync://hg.savannah.gnu.org/hg/<GROUP>
    • svn: rsync://svn.savannah.gnu.org/svn/<GROUP>
    • webcvs: rsync://web.cvs.savannah.gnu.org/web/<GROUP>
    • arch: rsync://arch.savannah.gnu.org/arch/<GROUP>

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

    • bzr: bzr branch bzr://bzr.savannah.nongnu.org/gnewsense/branch

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

    • cvs: cvs -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/<GROUP> co <modulename>
    • webcvs: cvs -d:pserver:anonymous@cvs.savannah.nongnu.org:/web/<GROUP> co <modulename>

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

    • git: git clone git://git.savannah.gnu.org/<GROUP>.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://svn.savannah.gnu.org/texinfo/trunk

vcs - web browsing

Source code repositories:

Webpages repositories:

download

The download.savannah.gnu.org hosts the following:

  • The 'downloads' (aka 'releases') for software hosted on GNU Sanannah.
  • The records from audio-video.gnu.org
  • The (old, obsolete) GNU Arch repositories

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

Configuration details:

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

    • web access: https://ftpmirror.gnu.org (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 software, as GNU packages are expected to put releases on ftp.gnu.org, as detailed in the GNU Maintainer Information.

  • Mirrored downloads/releases:

  • Savannah top-level download urls:

  • GNU audio-video host:

    • web access
    • http Apache conf: download0:/etc/apache2/sites-available/audio-video
    • https Apache conf: download0:/etc/apache2/sites-available/audio-video-ssl

  • 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://download.savannah.gnu.org/releases/<GROUP>/<FILE> LOCALFILE
    • Listing directory: rsync rsync://download.savannah.gnu.org/releases/<GROUP>/
    • 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>@download.savannah.gnu.org:/releases/<GROUP>/<FILE> LOCALFILE
    • Uploading a file (only to groups in which USER is a member, don't use -a): rsync -vhP LOCALFILE <USER>@download.savannah.gnu.org:/srv/download/<GROUP>/<FILE>

  • ssh access using SSH public keys registered in USER account ssh <USER>@download.savannah.gnu.org <COMMAND> where COMMAND is selected from limited set including

    • Removing a file (only from groups in which USER is a member): ssh <USER>@download.savannah.gnu.org rm /srv/download/<GROUP>/<FILE>
    • Removing an empty directory (only from groups in which USER is a member): ssh <USER>@download.savannah.gnu.org rmdir /srv/download/<GROUP>/<DIR>

  • scp access using SSH public keys registered in USER account

    • Download a file: scp <USER>@download.savannah.gnu.org:/srv/download/<GROUP>/<FILE> LOCALFILE
    • Upload a file (only to groups in which USER is a member): scp LOCALFILE <USER>@download.savannah.gnu.org:/srv/download/<GROUP>/<FILE>

  • sftp access (disabled in 2023-11-27)

    • was: sftp <USER>@download.savannah.gnu.org

internal

The internal0.savannah.gnu.org 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 groups, 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 fencepost.gnu.org users).
    • MySQL tcp connections are accepted only from savannah.gnu.org, savannah.nongnu.org, vcs.savannah.gnu.org, download.savannah.gnu.org (enforced with iptables rules).
    • MySQL configuration file: internal0:/etc/mysql/my.cnf

lists

lists.gnu.org handles the mailing lists for gnu.org, nongnu.org, libreplanet.org, 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 lists.gnu.org, lists.nongnu.org, lists.libreplanet.org and few other FSF-related sites.

  • One mailman installation handles all of the above domains (see message in savannah-users archive).

  • 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/lists.gnu.org-common
    • static html archives:
      • available from https://lists.gnu.org/archive/html
      • stored in lists:/arc/mharc-html.
      • search cgi with namazu2 package, using:
        • https://lists.gnu.org/archive/cgi-bin/namazu.cgi 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://lists.gnu.org/mbox/
    • To download full archive of one mailing list: rsync -avhP rsync://lists.gnu.org/mbox/bug-texinfo .

Spam handling is a whole subject in itself.

lists.gnu.org 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 ns1.gnu.org, and only answers queries from ns1.gnu.org (enforced with iptables rules).
    • More about DNS.

--moretowrite-- The mgt0.savannah.gnu.org 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).