[Savannah-cvs] [79] somewhat clarify lists:savannah_wrapper.pl execution, etc.

[karl]

Revision: 79
          http://svn.sv.gnu.org/viewvc/?view=rev&root=administration&revision=79
Author:   karl
Date:     2014-03-11 18:08:07 +0000 (Tue, 11 Mar 2014)
Log Message:
-----------
somewhat clarify lists:savannah_wrapper.pl execution, etc.

Modified Paths:
--------------
    trunk/sviki/MailSystem.mdwn

Modified: trunk/sviki/MailSystem.mdwn
===================================================================
--- trunk/sviki/MailSystem.mdwn 2014-03-07 08:06:18 UTC (rev 78)
+++ trunk/sviki/MailSystem.mdwn 2014-03-11 18:08:07 UTC (rev 79)
@@ -1,4 +1,5 @@
-The lists server is lists.gnu.org.
+The principal email server is lists.gnu.org, managed by FSF sysadmin.  
+Savannah does not have root access.
 
 Note: for an overview of how mail is sent from Savannah, please check
 [[InternalMailSystem]].
@@ -6,15 +7,15 @@
 Mailman
 -------
 
-There are no static Mailman aliases; instead, is looks at
-`/var/lib/mailman/lists/list_name/domains/` and check for files that
+There are no static Mailman aliases; instead, it looks at
+`/var/lib/mailman/lists/listname/domains/` and checks for files that
 represent the domain of the list, such as `gnu.org`, `nongnu.org`, and
 the like.
 
 ### Then, I don't really know:
 
 -   there is some Exim code to take those files into account
--   currently, there is a replication script that copies all the
+-   currently (?), there is a replication script that copies all the
     list+domains information to mp.gnu.org - to it's probably checked
     there. jag said "it runs on the 42 of every hour". We can also run
     it through `~/mailman-export`.
@@ -27,53 +28,36 @@
 ### They are located at 2 places:
 
 -   private archives are managed by Mailman:
-    /var/lib/mailman/archives/private/list\_name.mbox/list\_name.mbox
-    (use the `arch` command to manage them; look at the --wipe command)
--   public archives are managed by mharc: \~mharc/mboxes and
-    \~mharc/html (check [[ImportMailingListArchive]])
+    `/var/lib/mailman/archives/private/list_name.mbox/list_name.mbox`
+    (use mailman's `arch` command to manage them; look at the --wipe command)
+-   public archives are managed by mharc: `\~mharc/mbox` and
+    `\~mharc/html` (check [[ImportMailingListArchive]])
 
-Note: archives are currently not indexed by search engines, see
-robots.txt:
+Mailing list creation
+---------------------
 
-     User-agent: *
-     Disallow: /
+I (Sylvain) basically installed sv\_mailman on internal.sv.gnu.org,
+modified it to support mailman virtual hosts (and use the proper admin
+mail instead of address@hidden).  Then I wrote a fake
+`/usr/sbin/newlist` that connects to address@hidden via SSH and call
+an helper script there (`savannah\_wrapper.pl`).  This happens via a
+Savannah public key in address@hidden's `authorized\_keys` with a
+`command=` restriction.
 
-This is an effort from address@hidden to reduce the disk I/O on this
-already loaded machine. Spiders tend to put lists.gnu.org to its knees,
-unfortunately.
+There is also an empty `/usr/sbin/config_list` on internal that does
+nothing; we don't want what Savane currently does there.
 
-It is suggested to use mail archives mirroring services meanwhile. Once
-there is a more powerful machine, maybe web crawlers will be allowed
-again.
+The cron jobs related to sv\_mailman run on internal, file
+/etc/cron.d/sv. The script being run is named sv\_mailman.
 
-Work-arounds
+Valid sender
 ------------
 
-The mailing list setup contains a decent set of work-arounds. This is
-mainly due to the fact we do not have root access to the list server,
-and also because of inconsistent security paranoia.
+lists.gnu.org makes (used to make?) a series of checks that will reject
+mail from, say, address@hidden because this is apparently
+not a valid email. Email validation eventually falls-back against
+fencepost (Unix users and the shares `/com/mailer/aliases`).
 
-### Mailing list creation
-
-I basically installed sv\_mailman, modified it to support mailman
-virtual hosts (and use the proper admin mail instead of
address@hidden). Then I wrote a fake `/usr/sbin/newlist` that
-connects to address@hidden via SSH and call an helper script there
-(savannah\_wrapper.pl). address@hidden has a Savannah public key in
-its `authorized_keys` with a `command=` restriction. There is also am
-empty `/usr/sbin/config_list` that does nothing - but we don't really
-want what Savane currently does there.
-
-The cron job runs on the vcs-noshell host, file /etc/cron.d/sv. The
-script being run is named sv\_mailman.
-
-### Valid sender
-
-lists.gnu.org makes a series of checks that will reject mail from, say,
address@hidden because this is apparently not a valid
-e-mail. E-mail validation eventually falls-back against fencepost (Unix
-users and the shares /com/mailer/aliases).
-
 To bypass those checks, we added aliases at fencepost for Savannah users
 that need to send mail (gatekpr, libcrsync, Savane's INVALID.NOREPLY,
 etc.). See also [[ListServer]].