[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-cvs] [367] Make an attempt to update hostnames and URLs for cu
|
From: |
bob |
|
Subject: |
[Savannah-cvs] [367] Make an attempt to update hostnames and URLs for current systems. |
|
Date: |
Sat, 2 Feb 2019 03:33:53 -0500 (EST) |
Revision: 367
http://svn.savannah.gnu.org/viewvc/?view=rev&root=administration&revision=367
Author: rwp
Date: 2019-02-02 03:33:53 -0500 (Sat, 02 Feb 2019)
Log Message:
-----------
Make an attempt to update hostnames and URLs for current systems.
Update roles to the new servers they moved to. Update hostnames
everywhere I found them. Update URLs as I found them. Remove a few
obsolete parts.
Modified Paths:
--------------
trunk/sviki/DNS.mdwn
trunk/sviki/FrontEnd.mdwn
trunk/sviki/FrontEndDevelopmentSite.mdwn
trunk/sviki/FrontEndSetup.mdwn
trunk/sviki/Git.mdwn
trunk/sviki/HowToAdminThisWiki.mdwn
trunk/sviki/ListServer.mdwn
trunk/sviki/MailSystem.mdwn
trunk/sviki/MailingListsInternals.mdwn
trunk/sviki/Mirmon.mdwn
trunk/sviki/NonGnuToGnuSysadmin.mdwn
trunk/sviki/RenamingAccounts.mdwn
trunk/sviki/RenamingProjectGroup.mdwn
trunk/sviki/SavaneTasks.mdwn
trunk/sviki/SavannahArchitecture.mdwn
trunk/sviki/SavannahDatabaseSchema.mdwn
trunk/sviki/SavannahInternals.mdwn
trunk/sviki/SavannahServices.mdwn
trunk/sviki/ShellAccess.mdwn
trunk/sviki/SqlQueries.mdwn
trunk/sviki/SvN.mdwn
trunk/sviki/UserAuthentication.mdwn
trunk/sviki/https.mdwn
Modified: trunk/sviki/DNS.mdwn
===================================================================
--- trunk/sviki/DNS.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/DNS.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -68,4 +68,4 @@
> seen that done like that before. But I can see they were trying to
> use one list instead of four. That seems admirable.
-See also the 'internal' section in [[SavannahServices]] for more details.
+See also the 'internal0' section in [[SavannahServices]] for more details.
Modified: trunk/sviki/FrontEnd.mdwn
===================================================================
--- trunk/sviki/FrontEnd.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/FrontEnd.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -7,7 +7,7 @@
Some of the content is configurable, using text files that are stored in
the webcvs repository for `administration`.
<http://web.cvs.savannah.gnu.org/viewvc/administration/content/?root=administration>
-The live CVS checkout is at `frontend:/etc/savane/content`.
+The live CVS checkout is at `frontend0:/etc/savane/content`.
After committing changes in either of those repositories, to make the
changes live, it is necessary to log in to frontend and manually `git
Modified: trunk/sviki/FrontEndDevelopmentSite.mdwn
===================================================================
--- trunk/sviki/FrontEndDevelopmentSite.mdwn 2019-02-02 07:05:34 UTC (rev
366)
+++ trunk/sviki/FrontEndDevelopmentSite.mdwn 2019-02-02 08:33:53 UTC (rev
367)
@@ -17,17 +17,16 @@
-------------------------
Add a new DNS CNAME record, currently done on
-`internal.sv.gnu.org` (not on `internal0` - it is not yet
-the active DNS server).
+`mgt0.savannah.gnu.org`
See general DNS instructions in [[DNS]].
A wildcard subdomain CNAME record was added to
-`internal:/etc/bind/master/savannah.footer`:
+`mgt0:/etc/bind/master/savannah.footer`:
*.frontend0 CNAME frontend0
-The DNS setup on `internal` ensures that for every subdomain
+The DNS setup on `mgt0` ensures that for every subdomain
(e.g. `jsmith.frontend0`) the hostname will be included in all four
possibilities:
Modified: trunk/sviki/FrontEndSetup.mdwn
===================================================================
--- trunk/sviki/FrontEndSetup.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/FrontEndSetup.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -13,13 +13,13 @@
Further reading about savannah's server:
* [[SavannahArchitecture]] - overview of the current ('old') setup
- (i.e. vcs, mgt, frontend, internal, vcs, download).
+ (i.e. vcs0, mgt0, frontend0, internal0, download0).
* [[SavannahServices]] - services/daemons available on savannah's hosts.
* [[SavannahInternals]] - Savannah's inner-workings.
* [[SavannahHosts]] - Configuration of the new servers
(i.e. mgt0, vcs0, frontend0, internal0, download0).
-Further reading about savannah's frontend:
+Further reading about savannah's web frontend:
* [[RunningSavaneLocally]] - Running savannah's php code locally.
* [[SavaneInABox]] - pre-configured Savane virtual machine.
@@ -31,8 +31,7 @@
-------------------
Savannah's web frontend (i.e. <https://savannah.gnu.org>)) is written in PHP.
-It uses a MySQL database running on `internal0` (for the new servers)
-or `internal` (for the existing servers).
+It uses a MySQL database running on `internal0`.
The code repository is called 'savane', available at
<http://git.savannah.gnu.org/cgit/administration/savane.git> and
Modified: trunk/sviki/Git.mdwn
===================================================================
--- trunk/sviki/Git.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/Git.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -57,8 +57,8 @@
Creating an additional repository - automation script
-----------------------------------------------------
-A script to automate the above steps is available in
-`vcs:~root/bin/gnu-sv-add-git-sub-repository.sh` and also in
+A script to automate the above steps is available in the
+old `vcs:/root/bin/gnu-sv-add-git-sub-repository.sh` and also in
`fencepost:~agn/gnu-sv-scripts/gnu-sv-add-git-sub-repository.sh`.
The script takes two parameters: the existing project name (e.g. `lwip`)
Modified: trunk/sviki/HowToAdminThisWiki.mdwn
===================================================================
--- trunk/sviki/HowToAdminThisWiki.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/HowToAdminThisWiki.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -122,8 +122,8 @@
### On VCS
-The repository is in `vcs:/srv/svn/administration`. A post-commit hook
-`vcs:/srv/svn/administration/hooks/post-commit.d/sv-ikiwiki-refresh-2`
+The repository is in `vcs0:/srv/svn/administration`. A post-commit hook
+`vcs0:/srv/svn/administration/hooks/post-commit.d/sv-ikiwiki-refresh-2`
will be executed after a new SVN commit. The script simply triggers
an update on `frontend0`:
@@ -329,7 +329,7 @@
Wiki configuration - current VMs
--------------------------------
-In the file `frontend:~sviki/ikiwiki.setup`. At present, we are using
+In the file `frontend0:~sviki/ikiwiki.setup`. At present, we are using
the default (quite minimal) configuration, with no extra plugins.
That file is in RCS, for simplest version control. Anyone in the
@@ -338,7 +338,7 @@
logins, but Savannah users do not, for obvious security reasons.)
The web server configuration bits are in
-`frontend:/etc/apache2/sites-available/sv.inc`.
+`frontend0:/etc/apache2/sites-available/sv.inc`.
How it works - current VMs
@@ -365,12 +365,12 @@
0. A post-commit hook on vcs which ssh's back to frontend to do the
refresh. This is in
-`vcs:/srv/svn/administration/hooks/post-commit.d/sv_ikiwiki_refresh`.
+`vcs0:/srv/svn/administration/hooks/post-commit.d/sv_ikiwiki_refresh`.
0. A pseudo-user `sviki` on vcs, frontend, and mgt, with its own ssh key
to allow communication (in `/etc/ssh/authorized_keys/sviki`).
-0. An empty directory `vcs:/srv/svn/.ssh` because ... it's a long story.
+0. An empty directory `vcs0:/srv/svn/.ssh` because ... it's a long story.
ssh unconditionally tries to create the user's `~/.ssh` directory, even
when (as here) it will not be used for anything. On vcs, the
post-commit is running as the user who did the commit, which is to say,
@@ -402,7 +402,7 @@
So we had these HTML files. We used Pandoc
<http://johnmacfarlane.net/pandoc> to do the basic conversion to
Markdown, plus some custom Perl massaging to eliminate the Wayback
-boilerplate, etc. That script is in `frontend:~sviki/wayback-trans`,
+boilerplate, etc. That script is in `frontend0:~sviki/wayback-trans`,
along with the original HTML files. The Zope wiki pages that contained
spaces in the names are probably broken links now, by the way.
@@ -474,7 +474,7 @@
<https://savannah.gnu.org/maintenance/recentchanges/> now, made from the
svn log.
-Try a commit from our checked-out repository, then on frontend:
+Try a commit from our checked-out repository, then on frontend0:
ikiwiki --setup ikiwiki.setup --refresh
@@ -481,7 +481,7 @@
Looks ok. Create user `sviki`, uid/gid 902, with generated `id_rsa`,
and set up post-commit stuff on vcs, as described above.
-Edit `frontend:/etc/default/iptables-rules` to allow incoming ssh from
+Edit `frontend0:/etc/default/iptables-rules` to allow incoming ssh from
vcs. (and from all other Savannah hosts while we're at it.)
Don't bother trying to start zope anymore:
Modified: trunk/sviki/ListServer.mdwn
===================================================================
--- trunk/sviki/ListServer.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/ListServer.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -59,7 +59,7 @@
infra/maintenance/ml.pl -a yourlogin -g project -l listname | mysql savane
Well, the pipe doesn't actually work. You have to run ml.pl on vcs,
-save the sqlcmd that is output, and then, on internal, run:
+save the sqlcmd that is output, and then, on mgt0, run:
echo "sqlcmd" | mysql savane
Modified: trunk/sviki/MailSystem.mdwn
===================================================================
--- trunk/sviki/MailSystem.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/MailSystem.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -66,9 +66,6 @@
How mails are sent from within Savannah
---------------------------------------
-The `internal` vserver handles email stuff for Savannah.
-All other systems delegate sending mail to `internal`.
-
A Savane cron job creates alias tables: `/etc/aliases` and
`/etc/email-addresses`. This is used to map Unix user accounts to an
outgoing email, based on the `email' field in the user's Savane
@@ -93,16 +90,16 @@
delivery.
If there is an error in sending the PHP and Apache combination should
-log an error to the frontend:/var/log/apache2/error.log file.
+log an error to the frontend0:/var/log/apache2/error.log file.
All of the mail status should be logged to
-`frontend:/var/log/mail.*`. When a message is sent you should see
+`frontend0:/var/log/mail.*`. When a message is sent you should see
the transaction logged there.
Logs are rotated. If you are looking back into the past you will need
to look through the various dated log files to find the transaction, e.g.:
- frontend:/var/log# ls -lhog mail.*
+ frontend0:/var/log# ls -lhog mail.*
-rw-r----- 1 0 May 8 06:25 mail.err
-rw-r----- 1 1.3K May 7 06:25 mail.err-20160507.gz
-rw-r----- 1 1.7K May 7 06:31 mail.err-20160508
Modified: trunk/sviki/MailingListsInternals.mdwn
===================================================================
--- trunk/sviki/MailingListsInternals.mdwn 2019-02-02 07:05:34 UTC (rev
366)
+++ trunk/sviki/MailingListsInternals.mdwn 2019-02-02 08:33:53 UTC (rev
367)
@@ -131,7 +131,7 @@
---------------
The mailing list cronjob runs on `mgt0` (in the old setup
-before the 2017 migration to newer VM, the script was on `internal` -
+before the 2017 migration to newer VM, the script was on the `oldinternal` -
outdated wiki pages might still refer to it there).
In `mgt0:/etc/cron.d/savane`:
Modified: trunk/sviki/Mirmon.mdwn
===================================================================
--- trunk/sviki/Mirmon.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/Mirmon.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -61,22 +61,22 @@
- The actual redirection is done in the web server, specifically the
module `Apache2::Geo::Mirror->auto_redirect`,
- which takes the list of GNU mirrors from the file
- `dl:/usr/local/share/GeoIP/gnu-mirror-list.txt`,
-- which is automatically created by `dl:/root/bin/mirrors-gnu.sh`
+ `download0:/usr/local/share/GeoIP/gnu-mirror-list.txt`,
+- which is automatically created by `download0:/root/bin/mirrors-gnu.sh`
from the current mirmon state and the http-only list of mirrors in
- `dl:/usr/local/share/GeoIP/gnu-download.txt`,
-- which in turn is updated nightly by a `dl:/etc/cron.d/mirmon` cron entry
- which runs `dl:/root/bin/gnu-mirmon.pl`.
+ `download0:/usr/local/share/GeoIP/gnu-download.txt`,
+- which in turn is updated nightly by a `download0:/etc/cron.d/mirmon` cron
entry
+ which runs `download0:/root/bin/gnu-mirmon.pl`.
The mirmon state and redirection lists are updated hourly for both
multiplexors (gnu, nongnu), each of which has its own script,
-`dl:/root/bin/mirrors-{gnu,nongnu}.sh`, run via `mirmon` cron
+`download0:/root/bin/mirrors-{gnu,nongnu}.sh`, run via `mirmon` cron
entries. Likewise the "allgnu" mirmon is run hourly. The geo location
-data is updated monthly via `dl:/etc/cron.d/maxmind`, stored in
-`dl:/usr/local/share/GeoIP`.
+data is updated monthly via `download0:/etc/cron.d/maxmind`, stored in
+`download0:/usr/local/share/GeoIP`.
A special thing about allgnu: because we want to check rsync urls, we
need at least mirmon version 1.39 (ca.2009), which is newer than what
the OS version on dl provides. So the current mirmon is in
-`dl:/usr/local/share/mirmon` (just unpacking the tarball suffices) and
+`download0:/usr/local/share/mirmon` (just unpacking the tarball suffices) and
the allgnu mirmon job uses that, instead of the OS mirmon.
Modified: trunk/sviki/NonGnuToGnuSysadmin.mdwn
===================================================================
--- trunk/sviki/NonGnuToGnuSysadmin.mdwn 2019-02-02 07:05:34 UTC (rev
366)
+++ trunk/sviki/NonGnuToGnuSysadmin.mdwn 2019-02-02 08:33:53 UTC (rev
367)
@@ -25,7 +25,7 @@
ordinarily shouldn't use it.
- Launch a curl to update www.gnu.org/software/PROJECT -- the
- appropriate command from mgt:/root/administration/curl.txt.
+ appropriate command from mgt0:/opt/administration/curl.txt.
This will also automatically create a redirection from
www.nongnu.org/PROJECT to www.gnu.org/software/PROJECT. It works via
Modified: trunk/sviki/RenamingAccounts.mdwn
===================================================================
--- trunk/sviki/RenamingAccounts.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/RenamingAccounts.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -14,9 +14,9 @@
(http://lists.gnu.org/archive/html/savannah-hackers/2016-05/msg00043.html):
There are four mysql commands listed in rename_user.sh
- (that is, mgt:/opt/administration/maintenance/rename_user.sh).
+ (that is, mgt0:/opt/administration/maintenance/rename_user.sh).
- Just run them by hand on internal, don't try to run the script; the
+ Just run them by hand on mgt0, don't try to run the script; the
whole vserver setup as used in that script is from a past incarnation.
Note that if a user doesn't belong to any groups and never previously
Modified: trunk/sviki/RenamingProjectGroup.mdwn
===================================================================
--- trunk/sviki/RenamingProjectGroup.mdwn 2019-02-02 07:05:34 UTC (rev
366)
+++ trunk/sviki/RenamingProjectGroup.mdwn 2019-02-02 08:33:53 UTC (rev
367)
@@ -57,7 +57,7 @@
mv html/$old html/$new
- rename in Savannah database if attached to a Savannah project (using
- internal.in.sv.gnu.org for this is preferred):
+ internal0.savannah.gnu.org for this is preferred):
> UPDATE savane.mail\_group\_list SET list\_name='NEW' WHERE
> list\_name='OLD';
Modified: trunk/sviki/SavaneTasks.mdwn
===================================================================
--- trunk/sviki/SavaneTasks.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/SavaneTasks.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -91,7 +91,7 @@
interface, such as detect suspect users and IP addresses, and ban users
or unban IP addresses):
- mysql savane # on internal subhost
+ mysql savane # on mgt0 subhost
-- Show all content posted by user #67738
mysql> SELECT "bugs_p", summary,details FROM bugs WHERE
submitted_by=67738
Modified: trunk/sviki/SavannahArchitecture.mdwn
===================================================================
--- trunk/sviki/SavannahArchitecture.mdwn 2019-02-02 07:05:34 UTC (rev
366)
+++ trunk/sviki/SavannahArchitecture.mdwn 2019-02-02 08:33:53 UTC (rev
367)
@@ -30,35 +30,36 @@
<https://savannah.gnu.org/bzr/?group=administration>
contains step-by-step notes about the system setup.
-Xen architecture
-----------------
+Xen/KVM architecture
+--------------------
-Savannah operates with five critical Xen domU's:
+Savannah operates with five critical Xen/KVM VMs.
-- mgt.savannah.gnu.org (140.186.70.74)
-- internal.savannah.gnu.org (140.186.70.75)
-- frontend.savannah.gnu.org (140.186.70.70, 140.186.70.71)
-- vcs.savannah.gnu.org (140.186.70.72)
-- download.savannah.gnu.org (140.186.70.73)
+- mgt0.savannah.gnu.org
+- internal0.savannah.gnu.org
+- frontend0.savannah.gnu.org
+- vcs0.savannah.gnu.org
+- download0.savannah.gnu.org
-mgt.savannah.gnu.org
---------------------
+mgt0.savannah.gnu.org
+---------------------
-This is the management domU, where maintenance scripts can be run and
-software can be built for the other four domU's.
+This is the management VM, where maintenance scripts can be run and
+software can be built for the other four VMs. Also 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 domU for
+Savannah hackers may maintain individual user accounts on this VM for
running/creating/maintaining maintenance scripts and for other
administrative functions.
-From the mgt domU, the other domU's are accessible via ssh.
+From the mgt VM, the other VM's are accessible via ssh.
-- ssh address@hidden
-- ssh address@hidden
-- ssh address@hidden
-- ssh address@hidden
+- ssh address@hidden
+- ssh address@hidden
+- ssh address@hidden
+- ssh address@hidden
SSH keys may be synced to the savannah virtual machines using the
/root/maintenance/authorized\_keys\_replicate.sh script, which copies
@@ -70,21 +71,20 @@
management vm on the other vm's without actually being in the mgt vm's
authorized\_keys file.
-internal.savannah.gnu.org
--------------------------
+internal0.savannah.gnu.org
+--------------------------
-The internal domU runs mysql as well as bind (for the
-*.savannah.gnu.org/*.savannah.nongnu.org domains)
+The internal0 VM runs mysql.
-frontend.savannah.gnu.org
--------------------------
+frontend0.savannah.gnu.org
+--------------------------
-The frontend domU runs the web server instances for Savannah.
+The frontend VM runs the web server instances for Savannah.
The frontend Savane repository pulls from administration/savane.git
-vcs.savannah.gnu.org
---------------------
+vcs0.savannah.gnu.org
+---------------------
This is the version control system virtual machine. It runs
cvs/git/bzr/etc as well as webservers for repository viewing.
@@ -95,10 +95,10 @@
Users themselves are authenticated in `/etc/nsswitch.conf` with a
`mysql` module (`libnss-mysql`), also directly against the mysql
-database on internal.
+database on internal0.
-download.savannah.gnu.org
--------------------------
+download0.savannah.gnu.org
+--------------------------
This is the "download" vm, it runs a webserver and stores the released
packages from Savannah.
Modified: trunk/sviki/SavannahDatabaseSchema.mdwn
===================================================================
--- trunk/sviki/SavannahDatabaseSchema.mdwn 2019-02-02 07:05:34 UTC (rev
366)
+++ trunk/sviki/SavannahDatabaseSchema.mdwn 2019-02-02 08:33:53 UTC (rev
367)
@@ -7,10 +7,10 @@
## Overview
-* The MySQL database server runs on `internal.sv.gnu.org`, and is
+* The MySQL database server runs on `internal0.savannah.gnu.org`, and is
accessible from other VMs (e.g. `vcs`, `frontend`, `download`, etc.).
* file reference in on this page refer to the
-
[administration/savane.git](http://git.savannah.gnu.org/cgit/administration/savane.git)
+
[administration/savane.git](https://git.savannah.gnu.org/cgit/administration/savane.git)
source code repository.
## Tables creation scripts
Modified: trunk/sviki/SavannahInternals.mdwn
===================================================================
--- trunk/sviki/SavannahInternals.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/SavannahInternals.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -83,7 +83,7 @@
calls a cgi script on `www.gnu.org` to request a website update.
6. A cron job on `www.gnu.org` regularly checks for update requests,
and `cvs updates` the requested repositories.
-7. A cron job on `internal` regularly query the database for mailing list
+7. A cron job on `mgt0` regularly query the database for mailing list
updates. It then creates the mailing lists on `lists.gnu.org`.
This is done because `lists.gnu.org` is managed by the FSF, not Savannah.
8. Publishing a new tarball release for GNU packages is performed by an
@@ -294,9 +294,9 @@
are done by the script). New mailing lists are added as new records in the
tables. Change requests to mailing lists are done by changing the
`status` field (see source code for possible values).
-* A cron job on `internal` reads the changes in the `mail_group_list` and
+* A cron job on `mgt0` reads the changes in the `mail_group_list` and
executes the necessary changes on `lists.gnu.org`. See "cron jobs on
- internal" section below.
+ mgt" section below.
### MySQL Database
@@ -304,8 +304,12 @@
### Cron job on vcs
-Stored in `vcs:/etc/cron.d/sv`:
+Some cron jobs may still be running on the old vcs VM still in use and
+accessible as `vcs`. The intent is to have everything moved off of
+there eventually.
+Stored in `vcs0:/etc/cron.d/sv`:
+
# remake user list for outgoing mail.
*/10 * * * * root nice -n 11 sv_aliases --cron && sed -e '/#
Savannah include start/,/# Savannah include end/s/\([^:]\+\): .*/\1:
address@hidden/' /etc/email-addresses -e 's,This is /etc/email-addresses,DO NOT
EDIT - GENERATED FROM email-addresses.,' > /etc/email-addresses_SENDER
@@ -319,15 +323,15 @@
35,05 * * * * root nice -n 11 sv_groups --cron --only-cvs
--only-homepage --only-svn --only-git --only-hg --only-bzr
*
[/backend/mail/sv_aliases.in](http://git.savannah.gnu.org/cgit/administration/savane.git/tree/backend/mail/sv_aliases.in)
- (installed in `vcs:/usr/local/bin/sv_aliases`) - This script prepares an
+ (installed in `vcs0:/usr/local/bin/sv_aliases`) - This script prepares an
`alias`-type file for for exim4 mail server, used when sending commit
updates to mailing lists.
* The script queries the MySQL database, extracting user names and
emails for all savannah users. Additionally, emails for 'squads'
(per-project mailing groups) are queried. The results are saved in
- `vcs:/etc/email-addresses`.
- * `vcs:/etc/email-addresses` is symlinked to the standard
- `vcs:/etc/exim4/email-addresses` file. Example:
+ `vcs0:/etc/email-addresses`.
+ * `vcs0:/etc/email-addresses` is symlinked to the standard
+ `vcs0:/etc/exim4/email-addresses` file. Example:
agn: address@hidden
karl: address@hidden
@@ -335,7 +339,7 @@
* The `sed` command in the cronjob file replaces each user's email
with address@hidden, and saves the results in
- `vcs:/etc/email-addresses_SENDER`. Example:
+ `vcs0:/etc/email-addresses_SENDER`. Example:
agn: address@hidden
karl: address@hidden
@@ -344,10 +348,10 @@
in an exim4 config file?
* `refresh-project-list.sh` - this script updates the
- `vcs:/srv/git/project-list` file which is used by gitweb CGI application.
- * FIXME: file is `vcs:/usr/src/infra/git/refresh-project-list.sh`, and
+ `vcs0:/srv/git/project-list` file which is used by gitweb CGI application.
+ * FIXME: file is `vcs0:/usr/src/infra/git/refresh-project-list.sh`, and
is not in the `savane` repository. Add it?
- * gitweb configuration file is `vcs:/etc/gitweb.conf`.
+ * gitweb configuration file is `vcs0:/etc/gitweb.conf`.
* Implemetation detail: the script does not re-generate the
`project-list` from scratch. Instead, it scans `/srv/git` for new git
repositories, and only adds them to the file if they aren't already
@@ -369,11 +373,11 @@
in the *owner* field when viewing the gitweb page of the project
(example: <http://git.savannah.gnu.org/gitweb/?p=coreutils.git>).
-* `sv_cgit.pl` - this script updates the `vcs:/srv/git/cgitrepos` file
+* `sv_cgit.pl` - this script updates the `vcs0:/srv/git/cgitrepos` file
which is used by the cgit CGI application.
- * FIXME: file is `vcs:/usr/src/infra/git/sv_cgit.pl` and is not in the
+ * FIXME: file is `vcs0:/usr/src/infra/git/sv_cgit.pl` and is not in the
`savane` repository. Add it?
- * cgit configuration file is `vcs:/etc/cgitrc`.
+ * cgit configuration file is `vcs0:/etc/cgitrc`.
* Implementation detail: the script reads the `/srv/git/project-list`
file (generated by `refresh-project-list.sh`, above), and for each
mentioned project, writes an entry in `cgitrepos`. Example:
@@ -391,7 +395,7 @@
* `generate_log_accum.pl` - This script updates the CVS hooks in savannah
repositories.
- * FIXME: file is `vcs:/usr/src/infra/cvs/generate_log_accum.pl` and
+ * FIXME: file is `vcs0:/usr/src/infra/cvs/generate_log_accum.pl` and
is not in the `savane` repository. Add it?
* The script queries the database (`groups` table) for project using
cvs repositories, and projects using homepages (which use the cvsweb
@@ -430,7 +434,7 @@
* The script queries the `groups` table, and creates the needed
repositories.
Example: For project `XXX`, if `groups.use_git=1`, it look for
- `vcs:/srv/git/XXX.git`. If it doesn't exist, create it with
+ `vcs0:/srv/git/XXX.git`. If it doesn't exist, create it with
`git init` and additional savannah-specific configurations (e.g.
permissions, hooks, xattrs).
* Repository initialization and configuration is delegated to the
@@ -457,8 +461,12 @@
### Cron jobs on download
-stored in `download:/etc/cron.d/sv`:
+Some cron jobs may still be running on the old download VM still in
+use but now accessible as `olddownload`. The intent is to have
+everything moved off of there eventually.
+stored in `download0:/etc/cron.d/sv`:
+
*/30 * * * * root sv_groups --cron --only-download --only-arch
* `sv_groups` - This script creates new repositories for projects in the
@@ -466,7 +474,7 @@
### Cron jobs on frontend
-* `frontend:/etc/cron.d/sv_export` [non-functional] - contains the
+* `frontend0:/etc/cron.d/sv_export` [non-functional] - contains the
following commands:
# XML data export
@@ -482,7 +490,7 @@
is an old feature which exports project data into XML.
FIXME: remove this?
-* `frontend:/etc/cron.daily/sv_list_groups` [unfinished] - an attempt to
+* `frontend0:/etc/cron.daily/sv_list_groups` [unfinished] - an attempt to
publish an authoritative list of active projects hosted on GNU Savannah.
The script contains the following code:
@@ -497,9 +505,9 @@
FIXME: complete this nice feature, and expose it with apache
configuration. Also possibly with JSON data, and more fields.
-### Cron jobs on internal
+### Cron jobs on mgt0
-stored in `internal:/etc/cron.d/sv`:
+stored in `mgt0:/etc/cron.d/sv`:
# Assign uidNumber and gidNumber inthe database (and rebuild cache for
# libnss-mysql-bg). 7211 was the latest group created by the old
@@ -540,10 +548,10 @@
* The `index.php` code sets the `mail_group_list.status` field to the
requested new status, and the `sv_mailman` script executes the
changes and updates the database.
- * `sv_mailman` calls `internal:/usr/sbin/newlist`. The `newlist`
+ * `sv_mailman` calls `mgt0:/usr/sbin/newlist`. The `newlist`
script is a stub which delegates the call to `lists.gnu.org` using
SSH. See [[MailSystem]] for more details.
- The gist of `internal:/usr/sbin/newlist` is:
+ The gist of `mgt0:/usr/sbin/newlist` is:
#!/bin/bash
list_full_name=$1
Modified: trunk/sviki/SavannahServices.mdwn
===================================================================
--- trunk/sviki/SavannahServices.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/SavannahServices.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -17,42 +17,33 @@
- Host names
- `X.gnu.org` and `X.nongnu.org` point to the same IP address.
- - `X.savannah.gnu.org` and `X.sv.gnu.org` likewise point to the same
+ - `X.savannah.gnu.org` and `X.savannah.gnu.org` likewise point to the same
address.
- - `dl` => `dl.sv.gnu.org` => `download.savannah.gnu.org`
- - `vcs` => `vcs.sv.gnu.org` => `vcs.savannah.gnu.org`
- - `fe` => `fe.sv.gnu.org` => `frontend.savannah.gnu.org`
- - `int` => `int.sv.gnu.org` => `internal.savannah.gnu.org`
- File names
- - Filenames with server name are written as `dl:/etc/apache2/foo.conf` -
- meaning the file `/etc/apache2/foo.conf` on the `dl` server (which is
- `dl.sv.gnu.org`).
+ - 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
+ `frontend0.savannah.gnu.org`).
- Filenames without server name - the server is assumed to be deduced from
the context.
## frontend
-The `frontend.sv.gnu.org` VM runs the Savannah website (PHP code).
+The `frontend0.savannah.gnu.org` VM runs the Savannah website (PHP code).
-- Main page: <http://savannah.gnu.org> and <http://savannah.nongnu.org>
+- Main page: <https://savannah.gnu.org> and <https://savannah.nongnu.org>
-- SSL access: <https://savannah.gnu.org> and <https://savannah.nongnu.org>
- using the ssl certificate in `frontend:/etc/ssl/private/2014/`. Much
- more info on our certificates at
-
<https://lists.gnu.org/mailman/private/savannah-hackers-private/2015-March/002940.html>.
-
- Apache local setup in `/etc/apache2/sites-available/` is under RCS
and has a ChangeLog.
-- PHP code runs defined in `frontend:/etc/apache2/sites-available/sv.inc`,
- stored in `frontend:/var/www/savane/frontend/php/`.
+- PHP code runs defined in `frontend0:/etc/apache2/sites-available/sv.inc`,
+ stored in `frontend0:/var/www/savane/frontend/php/`.
-- PHP source code: <http://savannah.gnu.org/projects/administration>
+- PHP source code: <https://savannah.gnu.org/projects/administration>
-## vcs
+## vcs0
-The `vcs.sv.gnu.org` VM holds the source code (bzr,cvs,hg,git,svn) and
+The `vcs0.savannah.gnu.org` 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
@@ -69,14 +60,14 @@
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
- `vcs:/etc/ssh/sshd_config`. The user must also be a member of the
+ `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>@bzr.savannah.nongnu.org/<PROJECT>/branch`
- cvs: `cvs -d:ext:<USER>@cvs.savannah.nongnu.org:/sources/<PROJECT> co
<modulename>`
- - git: `git clone <USER>@git.sv.gnu.org:/srv/git/<PROJECT>.git`
- - hg: `hg clone ssh://<USER>@hg.sv.gnu.org/<PROJECT>`
+ - git: `git clone <USER>@git.savannah.gnu.org:/srv/git/<PROJECT>.git`
+ - hg: `hg clone ssh://<USER>@hg.savannah.gnu.org/<PROJECT>`
- svn: `svn co
svn+ssh://<USER>@svn.savannah.gnu.org/<PROJECT>/<modulename>`
- webcvs: `cvs -d:ext:<USER>@cvs.savannah.nongnu.org:/web/<PROJECT> co
<PROJECT>`
@@ -83,8 +74,8 @@
### vcs - public anonymous access (read-only)
- rsync - read-only anonymous access to the raw repository files.
- configuration in `vcs:/etc/rsync.conf`, started with `xinetd` in
- `vcs:/etc/xinetd.d/rsync`.
+ configuration in `vcs0:/etc/rsync.conf`, started with `xinetd` in
+ `vcs0:/etc/xinetd.d/rsync`.
- bzr: `rsync://bzr.savannah.gnu.org/bzr/<PROJECT>`
- cvs: `rsync://cvs.savannah.gnu.org/sources/<PROJECT>`
- git: `rsync://svn.savannah.gnu.org/git/<PROJECT>`
@@ -93,22 +84,22 @@
- webcvs: `rsync://web.cvs.savannah.gnu.org/web/<PROJECT>`
- bzr-daemon - read-only anonymous access to bzr repositories.
- configured with `xinetd` in `vcs:/etc/xinetd.d/bzr-hpss`.
+ 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 `vcs:/etc/xinetd.d/cvs`.
+ configured with `xinetd` in `vcs0:/etc/xinetd.d/cvs`.
- cvs: `cvs -d:pserver:address@hidden:/sources/<PROJECT> co <modulename>`
- webcvs: `cvs -d:pserver:address@hidden:/web/<PROJECT> co <modulename>`
- git-daemon - read-only anonymous access to git repositories.
- configured with `xinetd` in `vcs:/etc/xinetd.d/git`.
+ configured with `xinetd` in `vcs0:/etc/xinetd.d/git`.
- git: `git clone git://git.savannah.gnu.org/<PROJECT>.git`
- hg - not defined.
- svn-daemon - read-only anonymous access to svn repositories.
- configured with `xinetd` in `vcs:/etc/xinetd.d/svn`.
+ configured with `xinetd` in `vcs0:/etc/xinetd.d/svn`.
- svn: `svn co svn://svn.savannah.gnu.org/texinfo/trunk`
### vcs - web browsing
@@ -116,26 +107,26 @@
Source code repositories:
- bzr
- - Apache config file: `vcs:/etc/apache2/sites-available/bzr`
- - static welcome page: <http://bzr.savannah.gnu.org/>
- - bzr cgi Viewer: <http://bzr.savannah.gnu.org/lh/>
+ - Apache config file: `vcs0:/etc/apache2/sites-available/bzr`
+ - static welcome page: <https://bzr.savannah.gnu.org/>
+ - bzr cgi Viewer: <https://bzr.savannah.gnu.org/lh/>
- cvs (the cvs source code repositories, not webpages)
- - Apache config file: `vcs:/etc/apache2/sites-available/cvs`
- - static welcome page: <http://cvs.savannah.gnu.org/>
- - ViewVC cgi: <http://cvs.savannah.gnu.org/viewvc/>
+ - Apache config file: `vcs0:/etc/apache2/sites-available/cvs`
+ - static welcome page: <https://cvs.savannah.gnu.org/>
+ - ViewVC cgi: <https://cvs.savannah.gnu.org/viewvc/>
- git
- - Apache config file: `vcs:/etc/apache2/sites-available/git`
- - static welcome page: <http://git.savannah.gnu.org/>
- - cgit viewer: <http://git.savannah.gnu.org/cgit/>
- - WebGit viwer: <http://git.savannah.gnu.org/gitweb/>
+ - Apache config file: `vcs0:/etc/apache2/sites-available/git`
+ - static welcome page: <https://git.savannah.gnu.org/>
+ - cgit viewer: <https://git.savannah.gnu.org/cgit/>
+ - WebGit viwer: <https://git.savannah.gnu.org/gitweb/>
- hg
- - Apache config file: `vcs:/etc/apache2/sites-available/hg`
- - static welcome page: <http://hg.savannah.gnu.org/>
- - hgweb Viewer: <http://hg.savannah.gnu.org/hgweb/>
+ - Apache config file: `vcs0:/etc/apache2/sites-available/hg`
+ - static welcome page: <https://hg.savannah.gnu.org/>
+ - hgweb Viewer: <https://hg.savannah.gnu.org/hgweb/>
- svn
- - Apache config file: `vcs:/etc/apache2/sites-available/svn`
- - static welcome page: <http://svn.savannah.gnu.org/>
- - ViewVC cgi: <http://svn.savannah.gnu.org/viewvc/>
+ - Apache config file: `vcs0:/etc/apache2/sites-available/svn`
+ - static welcome page: <https://svn.savannah.gnu.org/>
+ - ViewVC cgi: <https://svn.savannah.gnu.org/viewvc/>
Webpages repositories:
@@ -142,22 +133,22 @@
- webcvs (the cvs webpages repositories, propagated to `www.gnu.org`
and `www.nongnu.org`; not source code)
- Apache config file: same as `cvs` (above)
- - static welcome page: <http://web.cvs.savannah.gnu.org/>
- - ViewVC: <http://web.cvs.savannah.gnu.org/viewvc/>
+ - static welcome page: <https://web.cvs.savannah.gnu.org/>
+ - ViewVC: <https://web.cvs.savannah.gnu.org/viewvc/>
- WebGit (experimental):
- - Apache config file: `vcs:/etc/apache2/sites-available/webgit`
- - static welcome page: <http://web.git.savannah.gnu.org/>
- - cgit viewer: <http://web.git.savannah.gnu.org/cgit/>
- - WebGit viwer: <http://web.git.savannah.gnu.org/gitweb/>
+ - Apache config file: `vcs0:/etc/apache2/sites-available/webgit`
+ - static welcome page: <https://web.git.savannah.gnu.org/>
+ - cgit viewer: <https://web.git.savannah.gnu.org/cgit/>
+ - WebGit viwer: <https://web.git.savannah.gnu.org/gitweb/>
## download
-The `dl.sv.gnu.org` hosts the following:
+The `download.savannah.gnu.org` hosts the following:
* The 'downloads' (aka 'releases') for projects hosted on GNU Sanannah.
-* The content of <http://audio-video.gnu.org>
+* The content of <https://audio-video.gnu.org>
* The (old, obsolete) GNU Arch repositories
See [[Mirmon]] for more information about the auto-redirection mentioned
@@ -168,8 +159,8 @@
- 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: <http://ftpmirror.gnu.org> (this url auto-redirects).
- - Apache conf: `dl:/etc/apache2/sites-available/download`
+ - 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:
@@ -177,78 +168,61 @@
projects are expected to put releases on `ftp.gnu.org`, as detailed in
the GNU Maintainer Information
<https://www.gnu.org/prep/maintain/html_node/Automated-FTP-Uploads.html>.
- - web access: <http://download.savannah.gnu.org/releases/>,
- - Apache conf: `dl:/etc/apache2/sites-available/download`
- - disk location: `dl:/srv/download/`
+ - web access: <https://download.savannah.gnu.org/releases/>,
+ - Apache conf: `download0:/etc/apache2/sites-available/download`
+ - disk location: `download0:/srv/download/`
- Mirrored downloads/releases:
- - web access: <http://download.savannah.gnu.org/releases-redirect/>
- - Apache conf: `dl:/etc/apache2/sites-available/download`
+ - web access: <https://download.savannah.gnu.org/releases-redirect/>
+ - Apache conf: `download0:/etc/apache2/sites-available/download`
- Uses `Apache2::Geo::Mirror` to redirect based on GeoIP.
- Savannah top-level download urls:
- (These are not especially useful for end-users.)
- - <http://download-mirror.savannah.gnu.org>
- - Apache conf: `dl:/etc/apache2/sites-available/download`
+ - <https://download-mirror.savannah.gnu.org>
+ - Apache conf: `download0:/etc/apache2/sites-available/download`
- GNU audio-video host:
- - web access: <http://audio-video.gnu.org>, <https://audio-video.gnu.org>
- - http Apache conf: `dl:/etc/apache2/sites-available/audio-video`
- - https Apache conf: `dl:/etc/apache2/sites-available/audio-video-ssl`
+ - web access: <https://audio-video.gnu.org>, <https://audio-video.gnu.org>
+ - http Apache conf: `download0:/etc/apache2/sites-available/audio-video`
+ - https Apache conf:
`download0:/etc/apache2/sites-available/audio-video-ssl`
- GNU Arch repositories:
- GNU Arch repositories are obsolete and should not be used.
- - web access: <http://arch.gnu.org>, <http://arch.sv.gnu.org/>,
- <http://arch.sv.nongnu.org/>.
- - Apache conf: `dl:/etc/apache2/sites-available/arch`
- - static welcome page: `dl:/var/www/arch`
- - disk location: `dl:/srv/arch`
+ - web access: <https://arch.gnu.org>, <https://arch.savannah.gnu.org/>,
+ <https://arch.savannah.nongnu.org/>.
+ - Apache conf: `download0:/etc/apache2/sites-available/arch`
+ - static welcome page: `download0:/var/www/arch`
+ - disk location: `download0:/srv/arch`
- rsync access
- - rsync start-up configuration file: `dl:/etc/default/rsync`. The
+ - 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 `dl:/etc/xinetd.d/rsync` are used.
- - rsync configuration file: `dl:/etc/rsyncd.conf`.
+ ignored. Instead, the parameters in `download0:/etc/xinetd.d/rsync` are
used.
+ - rsync configuration file: `download0:/etc/rsyncd.conf`.
Available modules:
- - `releases` mapped to `dl:/srv/download`.
- - `audio-video` mapped to `dl:/srv/audio-video`.
+ - `releases` mapped to `download0:/srv/download`.
+ - `audio-video` mapped to `download0:/srv/audio-video`.
- Anonymous access using rsync protcol:
- `rsync -avhP rsync://dl.sv.gnu.org/releases/<PROJECT>/<FILE> LOCALFILE`
+ `rsync -avhP rsync://download.savannah.gnu.org/releases/<PROJECT>/<FILE>
LOCALFILE`
- Listing content of a directory:
- `rsync rsync://dl.sv.gnu.org/releases/<PROJECT>/`
+ `rsync rsync://download.savannah.gnu.org/releases/<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>@dl.sv.gnu.org:/releases/<PROJECT>/<FILE> LOCALFILE`
+ `rsync -avhP <USER>@download.savannah.gnu.org:/releases/<PROJECT>/<FILE>
LOCALFILE`
- Uploading a file (only to projects in which USER is a member):
- `rsync -avhP LOCALFILE
<USER>@dl.sv.gnu.org/srv/download/<PROJECT>/<FILE>`
+ `rsync -avhP LOCALFILE
<USER>@download.savannah.gnu.org/srv/download/<PROJECT>/<FILE>`
- sftp access
- - `sftp <USER>@dl.sv.gnu.org`
+ - `sftp <USER>@download.savannah.gnu.org`
## internal
-The `internal.sv.gnu.org` VM runs the Savannah database (mysql),
-and dns (bind) for Savannah VMs.
+The `internal0.savannah.gnu.org` VM runs the Savannah database (mysql).
-* DNS server - `bind`
- * startup configuration file: `int:/etc/default/bind9`
- * bind configuration directory: `int:/etc/bind/`
- * The relevant configuration files are:
- * `int:/etc/bind/named.conf` which includes
- * `int:/etc/bind/named.conf.local` which includes
- * `int:/etc/bind/master/savannah.{gnu,nongnu}.org` which include:
- * `int:/etc/bind/master/savannah.header` - name servers and
- serial update timestamp
- * `int:/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: [[DNS]].
-
* Savannah database - `mysql`
* Used in two contexts:
1. The database for the Savannah PHP code (based on old SourceForge
@@ -260,10 +234,10 @@
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 `sv.gnu.org`,
- `sv.nongnu.org`, `vcs.sv.gnu.org`, `dl.sv.gnu.org` (enforced with
+ * 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: `int:/etc/mysql/my.cnf`
+ * MySQL configuration file: `internal0:/etc/mysql/my.cnf`
## lists
@@ -277,7 +251,7 @@
`lists.libreplanet.org` and few other FSF-related sites.
* One mailman installation handles all of the above domains (see
-
[here](http://lists.gnu.org/archive/html/savannah-users/2015-09/msg00009.html)).
+
[here](https://lists.gnu.org/archive/html/savannah-users/2015-09/msg00009.html)).
* web access:
- multiple configuration files in `lists:/etc/apache2/sites-enabled`
@@ -285,13 +259,13 @@
- all include the following file:
`lists:/etc/apache2/sites-available/lists.gnu.org-common`
- static html archives:
- - available from <http://lists.gnu.org/archive/html>
+ - available from <https://lists.gnu.org/archive/html>
- stored in `lists:/arc/mharc-html`.
- search cgi with `namazu2` package, using:
- - `http://lists.gnu.org/archive/cgi-bin/namazu.cgi` pointing to
+ - `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](http://www.gnu.org/software/mailman/) manages mailing list
+ - [GNU Mailman](https://www.gnu.org/software/mailman/) manages mailing list
activities (subscriptions, moderation, etc.)
- http alias <https://lists.gnu.org/mailman/> points to
`lists:/var/lib/mailman/cgi-bin/`.
@@ -314,8 +288,24 @@
## 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: [[DNS]].
+
--moretowrite--
-The `mgt.sv.gnu.org` VM runs munin, and what else? Provides access
+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).
Modified: trunk/sviki/ShellAccess.mdwn
===================================================================
--- trunk/sviki/ShellAccess.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/ShellAccess.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -5,7 +5,7 @@
arbitrary commands is far too large an attack vector. We do use the
Unix login mechanism and [[SshAccess]] but only certain commands can be
run to do, e.g., vc operations. (Validation is done against databases
-on internal.)
+on internal0.)
Savane distributes `sv_membersh`, a simple Perl script, that loads
another Perl script in /etc for configuration. Using a Perl script as a
@@ -40,19 +40,15 @@
have that already, see
<http://www.gnu.org/software/README.accounts.html>. After that, an
existing savannah worker can enable your access to savannah. (By adding
-the key to `mgt:/root/.ssh/authorized_keys` (in the right section,
-please) and running `mgt:/root/bin/push-root-authkeys`. See comments in
-those files.)
+the key to `mgt0:/root/.ssh/authorized_keys` (in the right section,
+please). See comments in those files.)
You may find it convenient to automatically proxy ssh through fencepost,
along these lines:
- Host *.savannah.gnu.org
+ Host *.savannah.gnu.org *.sv.gnu.org
User root
ProxyCommand ssh -W %h:%p fencepost.gnu.org
- Host *.sv.gnu.org
- User root
- ProxyCommand ssh -W %h:%p fencepost.gnu.org
Beware of unintentionally trying to do normal vc checkouts as root as a
result, though. Understand what you're doing. [[SavannahArchitecture]]
@@ -59,7 +55,7 @@
lists the various hosts.
FYI, you can also log in to lists.gnu.org (as user list) from
address@hidden; see [[ListServer]] for tasks that this is
address@hidden; see [[ListServer]] for tasks that this is
needed for.
@@ -74,7 +70,7 @@
0. Set up a normal account in the web interface to avoid someone later
claiming the name. But this should not be used for other purposes.
-0. On internal, get the assigned uid:
+0. On internal0, get the assigned uid:
mysql -u root -p
select uidnumber from savane.user where user_name='luca';
@@ -83,18 +79,18 @@
This number is different from the user_id field which shows up in the
savannah profile as the "Id:" <https://savannah.gnu.org/users/luca>.
-0. On mgt, add the obvious passwd entry using that uid. It's not
+0. On mgt0, add the obvious passwd entry using that uid. It's not
technically necessary that the uid's match, but it seems cleaner to
avoid possible conflicts.
-0. In Luca's case, the only need was for access to download.sv.gnu.org,
-for audio-video maintenance. So the account on mgt can't log in. On
-dl, copy in the new passwd entry, make the shell `/bin/bash`, make the
+0. In Luca's case, the only need was for access to download0.savannah.gnu.org,
+for audio-video maintenance. So the account on mgt0 can't log in. On
+download0, copy in the new passwd entry, make the shell `/bin/bash`, make the
`/etc/shadow` entry.
-0. On dl, add luca to savannahroot in /etc/group. This allows sudo.
+0. On download0, add luca to savannahroot in /etc/group. This allows sudo.
-0. On dl, create `/etc/ssh/authorized_keys/luca` with his pub keys.
+0. On download0, create `/etc/ssh/authorized_keys/luca` with his pub keys.
This lets him log in.
@@ -105,3 +101,11 @@
checkout paths and other things fail. I (Karl) am not going to explain
all that here. If you don't know what I'm talking about or can't figure
it out, don't create such an account :).
+
+Note from Bob <rwp>: Having a local account on vcs0 or download0 of
+the same name as your Savannah account name will conflict with normal
+use of that account for vcs and download activities. Therefore two of
+us, rwp and agn, have rwplocal and agnlocal accounts with different
+names in order to avoid the name collision conflict. The advice
+further above to create an identical account name and uid probably
+works for audio-video because which isn't a Savannah service.
Modified: trunk/sviki/SqlQueries.mdwn
===================================================================
--- trunk/sviki/SqlQueries.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/SqlQueries.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -15,7 +15,7 @@
with the forum_id column in news_bytes. Set display type of news
comments to flat or replies-to-comments will not be displayed.
-On the internal host, in /root/bin are some scripts:
+On the mgt0 host, in /opt/administration/bin are some scripts:
forum-remove-by-id, items-list-by-id, items-remove-by-id
The first silently removes all forum posts for ids listed on the cmdline.
The second lists all posts in all trackers, plus forum posts, for the given id,
Modified: trunk/sviki/SvN.mdwn
===================================================================
--- trunk/sviki/SvN.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/SvN.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -6,7 +6,7 @@
- <http://svn.sv.gnu.org/svn/PROJECT> - slow readonly access for people
who can't talk their admin into allowing outgoing SVN access
- <http://svn.sv.gnu.org/viewvc/?root=PROJECT>
-- `vcs:/srv/svn/PROJECT` - actual host location, for admins
+- `vcs0:/srv/svn/PROJECT` - actual host location, for admins
Documentation
-------------
@@ -26,7 +26,7 @@
For users: please submit a support request, including the project name
and the email address to send commits to.
-For admins: there is a script `vcs:/usr/local/bin/svn-commit-email` to
+For admins: there is a script `vcs0:/usr/local/bin/svn-commit-email` to
create the (boilerplate) post-commit hook.
SVK
Modified: trunk/sviki/UserAuthentication.mdwn
===================================================================
--- trunk/sviki/UserAuthentication.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/UserAuthentication.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -8,7 +8,7 @@
3. Users can upload ssh public keys using the web interface at:
<https://savannah.gnu.org/my/admin/editsshkeys.php>
4. ssh public keys are stored in the MySQL database server on
- `internal.sv.gnu.org` (see [[SavannahServices]]).
+ `internal0.savannah.gnu.org` (see [[SavannahServices]]).
User information can be viewed by anyone on the Savannah web site.
Example for user 'agn': <https://sv.gnu.org/users/agn/>
@@ -15,7 +15,7 @@
### Database access
-On `internal.sv.gnu.org`, the following sql commands can be used to examine
+On `internal0.savannah.gnu.org`, the following sql commands can be used to
examine
user accounts:
$ echo "select
@@ -53,12 +53,12 @@
In Savannah systems, there is a Unix user for *each* Savannah
registered user:
- vcs:~# getent passwd agn
+ vcs0:~# getent passwd agn
agn:x:131035:1003:Assaf Gordon:/srv:/usr/local/bin/sv_membersh
and a unix group for *each* Savannah registered project:
- vcs:~# getent group datamash
+ vcs0:~# getent group datamash
datamash:x:77800:agn
Access control is based on Unix group membership.
@@ -71,13 +71,13 @@
The git repository on `vcs.sv.gnu.org` is group-owned by `gawk` group:
- vcs:~# ls -ld /srv/git/gawk.git/
+ vcs0:~# ls -ld /srv/git/gawk.git/
drwxrwsr-x 8 root gawk 4096 Nov 4 01:23 /srv/git/gawk.git/
The members of the `gawk` group are allowed to push code updates to the `gawk`
repository:
- vcs:~# getent group gawk
+ vcs0:~# getent group gawk
gawk:x:6731:ajschorr,arnold,eliz,jkahrs,scldad,wb8tyw
@@ -108,7 +108,7 @@
### nsswitch and libnss-mysql
-The files `dl:/etc/nsswitch.conf` and `vcs:/etc/nsswitch.conf` contain the
+The files `download0:/etc/nsswitch.conf` and `vcs0:/etc/nsswitch.conf` contain
the
following configuration:
...
@@ -124,12 +124,12 @@
section then look it up in mysql. That is what allows libc to find
users in the mysql database.
- download:~# getent passwd agn
+ download0:~# getent passwd agn
agn:x:131035:1003:Assaf Gordon:/srv:/usr/local/bin/sv_membersh
The sql statements (to extract information from the mysql database on
-`internal`) are defined in `dl:/etc/libnss-mysql.cfg` and
-`vcs:/etc/libnss-mysql.cfg`.
+`internal0`) are defined in `download0:/etc/libnss-mysql.cfg` and
+`vcs0:/etc/libnss-mysql.cfg`.
### uidNumber
@@ -149,12 +149,12 @@
Search for `sv_assign_uid_gid` in [[SavannahInternals]] to see
how it is called (but note that the page is out-dated: the script now
-runs as a cron job on `mgt0`, not `internal`).
+runs as a cron job on `mgt0`, not `internal0`).
### ssh authentication
-The file `/etc/ssh/sshd_config` on `dl:` and `vcs:` servers have the line:
+The file `/etc/ssh/sshd_config` on `download0:` and `vcs0:` servers have the
line:
...
AuthorizedKeysExec /usr/local/bin/sv_get_authorized_keys
...
@@ -191,18 +191,18 @@
Manually invoking `sv_get_authorized_keys` looks like:
- vcs:~# /usr/local/bin/sv_get_authorized_keys agn
+ vcs0:~# /usr/local/bin/sv_get_authorized_keys agn
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAvs [...]
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ [...]
To validate the user's keys on `vcs`, use the following script:
- vcs:~# ~/bin/check-user-pubkeys.sh agn
+ vcs0:~# ~/bin/check-user-pubkeys.sh agn
address@hidden 2048 fe:61:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
/tmp/pubkey.check.9WvGnA/key.00 (RSA)
address@hidden 2048 87:21:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
/tmp/pubkey.check.9WvGnA/key.01 (RSA)
address@hidden 2048 3d:00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
/tmp/pubkey.check.9WvGnA/key.02 (RSA)
- vcs:~# ~/bin/check-user-pubkeys.sh someuser
+ vcs0:~# ~/bin/check-user-pubkeys.sh someuser
address@hidden 4096 6b:36:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
/tmp/pubkey.check.DmNCzP/key.00 (RSA)
address@hidden 4096 0b:c3:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
/tmp/pubkey.check.DmNCzP/key.01 (RSA)
Invalid key: /tmp/pubkey.check.DmNCzP/key.02
@@ -213,31 +213,19 @@
### mgt and root access
-`mgt.sv.gnu.org` is the management server (see [[SavannahArchitecture]] for
+`mgt0.savannah.gnu.org` is the management server (see [[SavannahArchitecture]]
for
more details).
-root access to `mgt` (and from there to `dl`/`vcs`/`dl`/`fe` servers) is
-controlled by `mgt:/root/.ssh/authorized_keys`. This file is updated
+root access to `mgt0` (and from there to the other Savannah servers) is
+controlled by `mgt0:/root/.ssh/authorized_keys`. This file is updated
**manually** by existing Savannah administrators, adding ssh public keys
of authorized savannah hackers.
-ssh access to address@hidden,vcs,dl,int,fe}` is only possible from
-`fencepost` (and other internal FSF machines to which no one outside the
-FSF has access).
+ssh access to `mgt0` is only possible from `fencepost` (and other
+internal FSF machines to which no one outside the FSF has access).
+ssh access to vcs0 and download0 is open to all as required by their
+respective functions.
-A script `mgt:/root/bin/push-root-authkeys` copies the file
-`mgt:/root/.ssh/authorized_keys` to `mgt:/root/.ssh/vm_authorized_keys`,
-and also to `{dl,fe,vcs,int}:/etc/ssh/authorized_keys/root`.
-(History: the script
-`mgt:/root/maintenance/authorized_keys_replicate.sh`, et al., was a
-previous method of doing that same job, no longer used.)
-
-The files `{dl,fe,vcs,int}:/etc/ssh/sshd_config` have:
-
- AuthorizedKeysFile /etc/ssh/authorized_keys/%u
-
-which enables root login based on the propagated `authorized_keys` file.
-
### fencepost
`fencepost.gnu.org` is the general-purpose server for GNU hackers (for more
Modified: trunk/sviki/https.mdwn
===================================================================
--- trunk/sviki/https.mdwn 2019-02-02 07:05:34 UTC (rev 366)
+++ trunk/sviki/https.mdwn 2019-02-02 08:33:53 UTC (rev 367)
@@ -13,7 +13,7 @@
* [[SavannahHosts]] - Configuration of the new servers
(i.e. mgt0, vcs0, frontend0, internal0, download0).
-Further reading about Savannah's frontend:
+Further reading about Savannah's web UI:
* [[FrontEnd]] - Notes about the current frontend setup (git,cvs).
* [[FrontEndDevelopmentSite]] - Setting up development sites for savannah.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Savannah-cvs] [367] Make an attempt to update hostnames and URLs for current systems.,
bob <=