[Savannah-cvs] [120] no need for repeated "GNU" Savannah, other clarifications

[karl]

Revision: 120
          
http://svn.sv.gnu.org/viewvc/?view=rev&root=administration&revision=120
Author:   karl
Date:     2014-11-29 00:01:22 +0000 (Sat, 29 Nov 2014)
Log Message:
-----------
no need for repeated "GNU" Savannah, other clarifications

Modified Paths:
--------------
    trunk/sviki/ListHelperAntiSpam.mdwn
    trunk/sviki/SavannahServices.mdwn
    trunk/sviki/UserAuthentication.mdwn

Modified: trunk/sviki/ListHelperAntiSpam.mdwn
===================================================================
--- trunk/sviki/ListHelperAntiSpam.mdwn 2014-11-28 01:18:33 UTC (rev 119)
+++ trunk/sviki/ListHelperAntiSpam.mdwn 2014-11-29 00:01:22 UTC (rev 120)
@@ -1,3 +1,6 @@
+Antispam with listhelper
+========================
+
 If you're using a mailman list on lists.gnu.org for your project(\*),
 it's possible to configure mailman to automatically delete most spam.
 This is done by default for lists created through Savannah. The system

Modified: trunk/sviki/SavannahServices.mdwn
===================================================================
--- trunk/sviki/SavannahServices.mdwn   2014-11-28 01:18:33 UTC (rev 119)
+++ trunk/sviki/SavannahServices.mdwn   2014-11-29 00:01:22 UTC (rev 120)
@@ -1,4 +1,4 @@
-# Services hosted on Savannah servers
+# Services hosted on GNU Savannah servers
 
 The following is the list of Savannah's public servers, organized by the
 VM they run on.
@@ -14,15 +14,16 @@
 ## Conventions
 
 - Host names
-    - `X.gnu.org` and `X.nongnu.org` point to the same IP.
-    - `X.savannah.gnu.org` and `X.sv.gnu.org` point to the same IP.
+    - `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
+       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/xxx.conf` -
-      meaning the file `/etc/apache2/xxx.conf` on the `dl` server (which is
+    - 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 without server name - the server is assumed to be deduced from
       the context.
@@ -34,13 +35,12 @@
 - Main page: <http://savannah.gnu.org> and <http://savannah.nongnu.org>
 
 - SSL access: <https://savannah.gnu.org> and <https://savannah.nongnu.org>
-  using the SSL certificate in `frontend:/etc/ssl/private/2014/`.
+  using the ssl certificate in `frontend:/etc/ssl/private/2014/`.
 
 - PHP code runs defined in `frontend:/etc/apache2/sites-available/sv.inc`,
   stored in `frontend:/var/www/savane/frontend/php/`.
 
-- PHP source code available in
-  <http://savannah.gnu.org/projects/administration>.
+- PHP source code: <http://savannah.gnu.org/projects/administration>
 
 
 ## vcs
@@ -59,7 +59,7 @@
 
 - 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
+    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
@@ -210,10 +210,10 @@
       `rsync -avhP rsync://dl.sv.gnu.org/releases/<PROJECT>/<FILE>  LOCALFILE`
     - Listing content of a directory:
       `rsync rsync://dl.sv.gnu.org/releases/<PROJECT>/`
-    - All GNU Savannah members can access RSYNC services, using the SSH public
-      key configured on GNU Savannah website (see SSH section of VCS server,
+    - 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 + GNU Savannah User:
+    - Download a file using ssh Public KEY + Savannah User:
       `rsync -avhP <USER>@dl.sv.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>`
@@ -224,8 +224,8 @@
 
 ## internal
 
-The `internal.sv.gnu.org` VM runs the GNU Savannah database (mysql),
-and dns (bind) for GNU Savannah VMs.
+The `internal.sv.gnu.org` VM runs the Savannah database (mysql),
+and dns (bind) for Savannah VMs.
 
 * DNS server - `bind`
     * startup configuration file: `int:/etc/default/bind9`
@@ -237,32 +237,33 @@
         * `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 GNU Savannah VMs (e.g. `dl` / `vcs` / `fe`)
+          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).
     * Information about updating DNS is here: [[DNS]].
 
-* GNU Savannah Database - `mysql`
+* Savannah Database - `mysql`
     * Used in two contexts:
-        1. The database for the GNU Savannah PHP code (based on old SourceForge
+        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 GNU Savannah web interface,
+           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
+        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 some exceptions for Savannah
            administrators, and `fencepost.gnu.org` users).
-    * MySQL TCP connections are accepted only from `sv.gnu.org`,
+    * MySQL tcp connections are accepted only from `sv.gnu.org`,
       `sv.nongnu.org`, `vcs.sv.gnu.org`, `dl.sv.gnu.org` (enforced with
       `iptables` rules).
     * MySQL configuration file: `int:/etc/mysql/my.cnf`
 
 ## lists
 
-`lists.gnu.org` handles the mailing lists for GNU, non-gnu, and few other
-FSF-related servers.
+`lists.gnu.org` handles the mailing lists for gnu.org, nongnu.org, and
+other FSF-related domains.  (The FSF also uses other servers in some
+cases, for its mass mailings, etc.)
 
 Configuration details:
 
@@ -271,29 +272,33 @@
 
 * web access:
     - multiple configuration files in `lists:/etc/apache2/sites-enabled`
-      configured to reply to different server names and SSL certificates.
+      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 <http://lists.gnu.org/archive/html>
         - stored in `lists:/arc/mharc-html`.
-        - search cgi with `namaze2` package, using:
+        - search cgi with `namazu2` package, using:
             - `http://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/) manage mailing list
+    - [GNU Mailman](http://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/`.
-        - Available mailing lists: <https://lists.gnu.org/mailman/listinfo>
+        - Long list of all public mailing lists:
+          <https://lists.gnu.org/mailman/listinfo>
+
 * 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 entire archive of a mailing list:  
+    - 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: [[ListHelperAntiSpam]].
+
 ## mgt - management
 
 --moretowrite--

Modified: trunk/sviki/UserAuthentication.mdwn
===================================================================
--- trunk/sviki/UserAuthentication.mdwn 2014-11-28 01:18:33 UTC (rev 119)
+++ trunk/sviki/UserAuthentication.mdwn 2014-11-29 00:01:22 UTC (rev 120)
@@ -2,16 +2,15 @@
 
 ### User account creation
 
-1. Any person can register a GNU Savannah user account using the web interface
-   at <https://savannah.gnu.org/account/register.php> .
-2. These user accounts are used across all GNU Savannah systems.
-3. Users can upload SSH public keys using the web interface at:
+1. Anyone can register a Savannah user account using the web interface:
+   <https://savannah.gnu.org/account/register.php>
+2. These user accounts are used across all Savannah systems.
+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]] for details about the MySQL
-   configuration.
+4. ssh public keys are stored in the MySQL database server on
+   `internal.sv.gnu.org` (see [[SavannahServices]]).
 
-Users' information is can be viewed on the GNU Savannah web site.
+User information is can be viewed on the Savannah web site.
 Example for user 'agn': <https://sv.gnu.org/users/agn/> .
 
 ### Database access
@@ -39,13 +38,13 @@
 
 ### User/group accounts
 
-In GNU Savannah systems, there is a unix user for *each* GNU Savannah
+In Savannah systems, there is a unix user for *each* Savannah
 registered user:
 
      vcs:~# getent passwd agn
      agn:x:131035:1003:Assaf Gordon:/srv:/usr/local/bin/sv_membersh
 
-and a unix group for *each* GNU Savannah registered project:
+and a unix group for *each* Savannah registered project:
 
     vcs:~# getent group datamash
     datamash:x:77800:agn
@@ -58,7 +57,7 @@
 members as of Nov. 2014
 (<http://sv.gnu.org/project/memberlist.php?group=gawk>).
 
-The GIT repository on `vcs.sv.gnu.org` is group-owned by `gawk` group:
+The git repository on `vcs.sv.gnu.org` is group-owned by `gawk` group:
 
     vcs:~# ls -ld /srv/git/gawk.git/
     drwxrwsr-x 8 root gawk 4096 Nov  4 01:23 /srv/git/gawk.git/
@@ -104,18 +103,16 @@
      download:~# getent passwd agn
      agn:x:131035:1003:Assaf Gordon:/srv:/usr/local/bin/sv_membersh
 
-(Notice the `uidNumber` from the mysql database is the user's Unix
+(Notice the `uidNumber` from the mysql database is the user's unix
 uid.)
 
-The SQL statements (to extract information from the mysql database on
+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`.
 
-### SSH authentication
+### ssh authentication
 
-The file `/etc/ssh/sshd_config` on `dl:` and `vcs:` servers contains the
-following statement:
-
+The file `/etc/ssh/sshd_config` on `dl:` and `vcs:` servers have the line:
     ...
     AuthorizedKeysExec      /usr/local/bin/sv_get_authorized_keys
     ...
@@ -130,16 +127,16 @@
 > using a differently named option `AuthorizedKeysCommand`.  
 > This option (and not `AuthorizedKeysExec`) is available in most OpenSSH
 > installations.  
-> If GNU Savannah servers are ever upgraded, these configuration files should 
be
+> If Savannah servers are ever upgraded, these configuration files should be
 > updated from `AuthorizedKeysExec` to `AuthorizedKeysCommand`.
 
-When users login to Savannah servers using SSH, they specify the user account:
+When users login to Savannah servers using ssh, they specify the user account:
 
     git clone address@hidden:/srv/git/datamash.git
 
 The user is therefore known, and OpenSSH needs to find the user's public keys.
-The `/usr/local/bin/sv_get_authorized_keys` perl script simply queries
-the SSH public keys of the user (splitting them by `###` delimiter):
+The `/usr/local/bin/sv_get_authorized_keys` Perl script simply queries
+the ssh public keys of the user (splitting them by `###` delimiter):
 
     ...
     my ($authorized_keys) = $dbd->selectrow_array(q[
@@ -163,37 +160,39 @@
 
 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
-**manually** by existing GNU Savannah administrators, adding SSH public keys
+**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`.
-(TODO: and few other FSF/GNU servers/VPN?)
+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).
 
 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`.
-(TODO: is the script `mgt:/root/maintenance/authorized_keys_replicate.sh`
-mentioned in [[SavannahArchitecture]] still in use?).
+(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` contain the following
-statement:
+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.
+which enables root login based on the propagated `authorized_keys` file.
 
 ### fencepost
 
 `fencepost.gnu.org` is general-purpose server for GNU hackers (for more
 information: <https://www.gnu.org/software/README.accounts.html>).
 
-It is not directly managed by GNU Savannah.
+It is managed by FSF sysadmin, and not managed by Savannah people in any
+way whatsoever.
 
-Users on `fencepost.gnu.org` use the same username as GNU Savannah accounts,
-and public SSH keys are copied (manually) from GNU Savannah database (i.e.
-users requesting access to `fencepost` must already setup accounts on GNU
-Savannah with SSH public keys). Other than that - user management on
-`fencepost` is separate from the rest of GNU Savannah servers.
+Users on `fencepost.gnu.org` conventionally use the same username as
+Savannah accounts, and public ssh keys are copied (manually) from
+Savannah database (i.e.  users requesting access to `fencepost` should
+setup accounts on Savannah with ssh public keys). Other than that - user
+management on `fencepost` is separate from the rest of Savannah servers.
 
 Each user on `fencepost` has a home directory with `~/.ssh/authorized_keys`
 files, enabling ssh access: