[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-cvs] [79] somewhat clarify lists:savannah_wrapper.pl execution
From: |
karl |
Subject: |
[Savannah-cvs] [79] somewhat clarify lists:savannah_wrapper.pl execution, etc. |
Date: |
Tue, 11 Mar 2014 18:08:15 +0000 |
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]].
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Savannah-cvs] [79] somewhat clarify lists:savannah_wrapper.pl execution, etc.,
karl <=