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


1) which are the correct permissions ?


2) 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 >) ? Get Pale Moon ! http://www.palemoon.org

Search Discussions

  • Mark Sapiro at Jun 16, 2015 at 4:19 pm

    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.

    1) which are the correct permissions ?



    See above. Also, see Mailman's bin/check_perms.



    2) 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
  • Lucio Chiappetti at Jun 16, 2015 at 4:38 pm

    On Tue, 16 Jun 2015, Mark Sapiro wrote:


    2) 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 ...
  • Mark Sapiro at Jun 16, 2015 at 4:57 pm

    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
  • Stephen J. Turnbull at Jun 17, 2015 at 7:37 am
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedJun 16, '15 at 9:17a
activeJun 17, '15 at 7:37a
posts5
users3
websitelist.org

People

Translate

site design / logo © 2021 Grokbase