Savannah architecture
Documentation places
- This wiki
- The administration 'infra' repository, with system installation notes and maintenance script: http://bzr.savannah.gnu.org/lh/administration/
(All the live code is in the administration
repository; the savane,
savane-cleanup, and other repositories are idle.)
Global architecture
See also the rest of the GnuArchitecture.
Savannah is located in Quincy near Boston, MA, at Global Naps. The hardware was donated to the FSF by HP, and the bandwidth is provided by the FSF.
Savannah was setup and is maintained by the Savannah Hackers.
The Bazaar repository contains step-by-step notes about the system setup.
Xen/KVM architecture
Savannah operates with five groups of critical Xen/KVM VMs.
- mgt?.savannah.gnu.org
- internal?.savannah.gnu.org
- frontend?.savannah.gnu.org
- vcs?.savannah.gnu.org
- download?.savannah.gnu.org
Where ? is a digit.
For mgt, internal, frontend, download, two VMs exist, one of them ('current') provides Savannah services and the other ('previous') was used before OS upgrade on the 'current', and will likely become 'current' after the next OS upgrade. The 'current' VM can be accessed without the digit, like download.savannah.gnu.org.
For vcs, different VMs provide different services, for example, vcs1 runs CVS.
mgt?.savannah.gnu.org
These are the management VMs, where maintenance scripts can be run and software can be built for the other four VMs. As of 2025-05, mgt1 is the primary management VM, its /root/ChangeLog is used to record changes in all Savannah VMs. mgt0 still runs bind (for the .savannah.gnu.org/.savannah.nongnu.org domains).
Scripts may be found in the /root/maintenance directory.
Savannah hackers may maintain individual user accounts on this VM for running/creating/maintaining maintenance scripts and for other administrative functions.
From the mgt VM, the other VMs are accessible via SSH.
- ssh root@download?
- ssh root@vcs?
- ssh root@frontend?
- ssh root@internal?
SSH keys may be synced to the savannah virtual machines using the /root/maintenance/authorized_keys_replicate.sh script, which copies the /root/.ssh/vm_authorized_keys file to the other virtual machines.
The /root/.ssh/authorized_keys file should be meant to control access to only the management vm, and /root/.ssh/vm_authorized_keys for the other virtual machines. This allows us to include key's from the management vm on the other vm's without actually being in the mgt vm's authorized_keys file.
internal.savannah.gnu.org
The internal VM runs MariaDB.
frontend.savannah.gnu.org
The frontend VM runs the web server for Savannah.
The frontend Savane repository pulls from administration/savane.git
vcs?.savannah.gnu.org
These are the version control system virtual machines:
- vcs1 runs CVS
- vcs2 runs Git
- vcs3 provides RSYNC acess to Git
- vcs0 runs other systems: bzr, svn, hg, arch
Before 2025-06, they run webservers for repository viewing as well.
These machines allow SSH from everywhere since that
is part of VCS access, and have a custom sshd_config directive
AuthorizedKeysCommand
to look up SSH keys in the mysql database.
Users are authenticated in /etc/nsswitch.conf
with a
mysql
module (libnss-mysql
), also directly against the
database on internal.
download.savannah.gnu.org
This is the "download" VM, it runs a webserver and stores the released packages from Savannah.
Like for VCS hosts, the users have SSH access to this for uploading the releases.
High load
If a DomU is experiencing heavy load, running these commands will dump some basic system state for possible post mortems:
d=`date +%F.%T`; cd /tmp; top>top-$d & ps auxww>ps-$d & lsof>lsof-$d &
netstat --numeric-hosts>netstat-$d &
We have often seen high loads due to vc browsers being hit too hard.
Testing Savannah VMs
Frontend serves not just Savannah but also some other virtual sites. For testing check this list.
- https://savannah.gnu.org/
- https://savannah.gnu.org/maintenance/FrontPage/
See also SavannahServices for list of publically accessible services.
Misc
Suggested Debian mirror: http://debian.csail.mit.edu/debian/
Initial setup of the previous hardware: http://fsffrance.org/news/article2001-05-28-01.en.html
2 sets of files are replicated from/to Savannah:
- syncaliases@syncaliases.savannah.gnu.org (a.k.a. from Dom0): the GNU mail system replicates these @gnu.org aliases from Savannah
- nongnulogcopy@nongnulogcopy.savannah.gnu.org (a.k.a. vcs-noshell): nongnu.org logs are synchronized to Savannah for processing (WIP)