I am running a few mailing lists with private archive on my machine. I see that /var/lib/mailman/archives/private/ contains two directories per list one named "listname" and the other one "listname.mbox".
Owned by wwwrun.mailman, permissions drwxrwsr-x
The listname directory contains one index.html owned by wwwrun.mailman while all other directories and text files are owned by mailman.mailman.
The listname.mbox directory contains a single file with the same name.
Now I noticed that at present such file is owned by me (lucio.staff) with permissions -rw-rw-r--
And I see in the log files some error messages like
Jun 16 07:02:26 2015 (3112) Uncaught runner exception: [Errno 13] Permission denied: '/var/lib/mailman/archives/private/fitsconv.mbox/fitsconv.mbox'
I suspect this may be due to the fact a while ago I created some soft links from my own ~/.mail directory e.g. fitsconv.mbox -> /var/lib/mailman/archives/private/fitsconv.mbox/fitsconv.mbox (the links are owned by me and have lrwxrwxrwx)
The idea was that I could, as administrator, access the entire sequence of messages of a list from my mail client (alpine), instead than with the web interface. Of course I'd just need read access, not write.
which are the correct permissions ?
apparently since the wrong permission were setup, archiving stopped to work. Is there a way to rebuild the archives from messages stored in personal folders (I am not sure I have all of them though !)
--
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
Do not like Firefox >=29 ? Get Pale Moon ! http://www.palemoon.org
On 06/16/2015 02:17 AM, Lucio Chiappetti wrote:
I am running a few mailing lists with private archive on my machine. I see that /var/lib/mailman/archives/private/ contains two directories per list one named "listname" and the other one "listname.mbox".
Owned by wwwrun.mailman, permissions drwxrwsr-x
This is good. owner doesn't actually mattetr for these. It is the 'mailman' group that is important.
The listname directory contains one index.html owned by wwwrun.mailman while all other directories and text files are owned by mailman.mailman.
That's OK, but they all should be world readable/searchable.
The listname.mbox directory contains a single file with the same name.
Now I noticed that at present such file is owned by me (lucio.staff) with permissions -rw-rw-r--
Again OK as long as its group is mailman.
And I see in the log files some error messages like
Jun 16 07:02:26 2015 (3112) Uncaught runner exception: [Errno 13] Permission denied: '/var/lib/mailman/archives/private/fitsconv.mbox/fitsconv.mbox'
This will not occur if the file is writable by the 'mailman' group.
I suspect this may be due to the fact a while ago I created some soft links from my own ~/.mail directory e.g. fitsconv.mbox -> /var/lib/mailman/archives/private/fitsconv.mbox/fitsconv.mbox (the links are owned by me and have lrwxrwxrwx)
Additional symlinks to the file are irrelevant unless you are writing to it (you shouldn't be) and changing its group.
The idea was that I could, as administrator, access the entire sequence of messages of a list from my mail client (alpine), instead than with the web interface. Of course I'd just need read access, not write.
- which are the correct permissions ?
See above. Also, see Mailman's bin/check_perms.
- apparently since the wrong permission were setup, archiving stopped to work. Is there a way to rebuild the archives from messages stored in personal folders (I am not sure I have all of them though !)
Just fix the permissions and run Mailman's bin/unshunt which will requeue the shunted messages for the archiver (it won't resend them to the list).
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Tue, 16 Jun 2015, Mark Sapiro wrote:
- apparently since the wrong permission were setup, archiving stopped to work. Is there a way to rebuild the archives from messages stored in personal folders (I am not sure I have all of them though !)
Just fix the permissions and run Mailman's bin/unshunt ...
GREAT ! Thanks a lot ! I recovered all the backlog !
I suspect this may be due to the fact a while ago I created some soft links from my own ~/.mail directory e.g. fitsconv.mbox -> /var/lib/mailman/archives/private/fitsconv.mbox/fitsconv.mbox (the links are owned by me and have lrwxrwxrwx)
Actually I had already reset the permissions for the archive folders (I simply enabled archive for a test list to see the fresh permission, and applied them to the old folders). This enabled archiving of new messages. But I was missing the "shunt" piece.
Additional symlinks to the file are irrelevant unless you are writing to it (you shouldn't be) and changing its group.
I cannot trace how they were (systematically for 3 lists) set to the wrong way. Now my alpine mail client enters the folders and sees them in READONLY mode (which is good), and refuses to delete messages (which is also good). If I enter a message flagged new (unread), it will set its flag to "read" ... maybe this is what mislead me ... but this is obviously an internal memory flag of the client. If I exit and re-enter the folder, I see the original status. Which for me is fine.
Going back to digest mode ...
On 06/16/2015 09:38 AM, Lucio Chiappetti wrote:
On Tue, 16 Jun 2015, Mark Sapiro wrote:
Just fix the permissions and run Mailman's bin/unshunt ...
GREAT ! Thanks a lot ! I recovered all the backlog !
Good!
I cannot trace how they were (systematically for 3 lists) set to the wrong way. Now my alpine mail client enters the folders and sees them in READONLY mode (which is good), and refuses to delete messages (which is also good). If I enter a message flagged new (unread), it will set its flag to "read" ... maybe this is what mislead me ... but this is obviously an internal memory flag of the client. If I exit and re-enter the folder, I see the original status. Which for me is fine.
Actually, the MUA will set a Status: header in the mbox to indicate the message has been read so that the 'read' status persists across sessions, but of course this requires the MUA to have permission to write the mailbox.
The safe thing is for 'you' to not have write permission on the mbox. If you did have in the past, this may be how the group was changed.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
The safe thing is for 'you' to not have write permission on the mbox. If you did have in the past, this may be how the group was changed.
Quite likely.
Basically, there are two ways to change the content of a file on Unix-like systems. One way is to write-lock (at least) the file, and open it read-write. Then do your edits, and close the file. Voila! the new contents are there, and the properties of the file (which are stored in the directory entry, not in the file) do not change.
The second doesn't require locking the file (although in the mail context you probably want to, since the MTA can add new messages while you are working with the file in your MUA, and in the simplest version of this strategy those new messages would be lost). You make a copy of the file under a temporary name, edit the copy, and then rename the file to the old name (usually also renaming the old file for backup). Under Unix semantics, the new file's directory entry gets *your* owner/ group/umask settings, and renaming just changes the name.
It turns out that on modern Unix systems ordinary users are not allowed to give arbitrary owner and group properties to a file, so if your editor or MUA uses the copy-edit-mv strategy, the file's ownership *will* change. Probably alpine uses this strategy.
participants (3)
-
Lucio Chiappetti -
Mark Sapiro -
Stephen J. Turnbull