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).