[BALUG-Admin] BALUG lists ... blank body with command in Subject: header, ...

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):

> Yes, well, from what I see of the files and such, looks like
> originally the files in
> /etc/mailman/en/
> match those in
> /usr/share/mailman/en/
> And looks like the bits editable in web GUI default to
> (after a restart of mailman)
> using those in
> /usr/share/mailman/en/
[...]

You know, I really should have included a disclaimer of 'I deal with
these file locations so seldom that I really cannot consistently
remember them, and please reconfirm anything I say about what files to
edit for what purpos.'

It doesn't help that Mailman uses symplinks for a number of things
criss-crossing between /var/lib/mailman locations and /usr/share/mailman
(I think) ones.

> And per FHS, etc., the above typically wouldn't be editable (/usr
> filesystem may be mounted read-only....

Well, it's hardly the only offender.  I discovered this when I did the
research that produced
http://linuxmafia.com/faq/Admin/linuxmafia.com-backup.html , and
[re-]discovered that Apache httpd's cgi-bin directory is in
/usr/lib/cgi-bin/

I likewise keep /usr normally mounted ro, and likewise use the apt hooks
to autoremount it for package operations -- but live with the fact that 
I need to also manually remount /usr to fiddle with cgi-bin scripts.

SpamAssassin's rulesets and scoring settings in /usr/share/spamassassin
are another example (and I guess I should add that directory to my
backup list).

I'll admit to getting a bit disenchanted with many of the more-recent
additions to FHS (specifically /media and /srv).  I've read the
rationales, and I don't agree that /media is justified in addition to
/mnt.  I am now grudgingly reconsidering my reflexive opposition to
/srv, because there's a good case that CGI-BIN scripts should be there
rather than anywhere in /usr, including the '/usr may be ro' one.
Therefore, SpamAssassin rulesets and scoring settings arguably are
better there, too.

Any time someone says 'Oh, let's solve this problem by putting it in a
new directory off /', I get cranky and conservative-minded, though.
Which is why I think /sys is regrettable -- even though I've heard how
we haplessly fell into the need for that on Linux systems.
(Essentially, the kernel people made such a dog's breakfast out of /dev
that they had to make a new tree to start over.  Nice going, guys.) 


I actually wanted to consult you on /boot being a separate filesystem.
I've done that since forever, but am acutely aware that the original
rationale no longer applies, that of old BIOSes being unable to branch
from int 13h to disc cylinder locations 1024 and over.  

So, is there a 2017 reason for still having /boot separate?  I can think
of scenarios, like you have most of the system on md mirrored partitions 
but want your bootloader to be able to run from a pair of ext2 ones on
both drives, _or_ you have most of the system encrypted.  Are there
reasons I'm missing?

> I suppose too, I ought set up some user in group (or with access to group)
> list, so that many of the list related commands can be run fine with
> less-than-root privileges - a not otherwise privileged user but also in
> group list would seem optimal - as group list seems to have the permissions
> to do the needed, but would generally lack permissions to muck with stuff it
> ought not (e.g. files owned by list by not writable by group list).
> At least on Debian, of what I've seen so far, looks like all the normally
> needed actions to manage mailman lists, are controlled/accessed via the
> list group.

Makes sense.  FWIW, when I need to muck about with Mailman's files I
_generally_ just su to list.  Most particularly, it's really important
to be user 'list' if you regenerate a pipermail archive using
/var/lib/mailman/bin/arch .  Otherwise, if you make the mistake of doing
it as root, the ownership of the generated Web archive is wrong and
you'll get 403 errors until you figure that out and fix it.

One ends up running /var/lib/mailman/bin/arch in one of the following
situations:

1.  Something needs to be redacted, either spam or (say) someone's
    private telephone number.  If you must do this, you start by 
    editing cumulative mbox file 
    /var/lib/mailman/archives/private/example.mbox/example.mbox 
    (say, using mutt).  Do this as user 'list'.  Ideally, you will
    not delete an entire message except one at the very end of the
    mbox, because doing so causes the pipermail Web archive
    entries to get renumbered URLs.  All other things being 
    equal, we want content's URLs to remain constant so people
    can permalink it.

    Once you have edited the mbox, you do this and cross your fingers:
    cd /var/lib/mailman/
    bin/arch --wipe -q example archives/private/example.mbox/example.mbox

    A really vexing problem sometimes arises:  /var/lib/mailman/bin/arch
    evinces broken behaviour if it encounters the string 'From '
    flush-left in a message it's parsing.  It mistakenly thinks that's
    an envelope 'From ' delimiting the beginning of a new message.

    The fix is to, yes, go back to the mbox file, find the damned line,
    prefix a '>' to that flush-left word (and do likewise with any other
    such cases), then re-run the arch command, to try again.

    The syptom of the problem is:  You look in the first and last 
    months of the Web archive using your Web browser, and any 
    fragmentary messages will stand out.

2.  Combining two mbox files.  This is really exactly the same as 
    case 1, except here you have to give up on keeping archive 
    URLs of individual messages constant.

    For example, a couple of years ago, I re-found the primordial 
    mbox file for the main SVLUG mailing list, in the days it ran 
    on majordomo before there was such a thing as GNU Mailman.

    I experimentally cat'ed that to the existing cumulative Mailman
    mbox (keeping backup copies), re-ran arch, dealt with the 
    irksome 'From ' problem a few times, and reached success -- 
    whereby SVLUG now has a Mailman archive older than Mailman 
    is (I think).