[Mailman-Users] check_perms -f not working

[Mark Sapiro]

Noah wrote:
>
>I run check_perms with the -f switch and the program runs the program 
>claims it found 100 problems and asks to run the program again.  Next 
>time I run it 100 problems are still found.  So I did some research to 
>figure out what the problems are.
>
>$ sudo ./check_perms -f
>/var/lib/mailman/cron bad group (has: root, expected list) (fixing)
>/var/lib/mailman/Mailman bad group (has: root, expected list) (fixing)
>/var/lib/mailman/mail bad group (has: root, expected list) (fixing)
>/var/lib/mailman/icons bad group (has: root, expected list) (fixing)
>/var/lib/mailman/bin bad group (has: root, expected list) (fixing)
>/var/lib/mailman/templates bad group (has: root, expected list) (fixing)
>/var/lib/mailman/cgi-bin bad group (has: root, expected list) (fixing)
>/var/lib/mailman/scripts bad group (has: root, expected list) (fixing)
>/var/lib/mailman/logs bad group (has: root, expected list) (fixing)
>/var/lib/mailman/pythonlib bad group (has: root, expected list) (fixing)
>
>in some cases there are links to another directory.  Does this seem normal?
>
>$ ls -l /var/lib/mailman/cron
>lrwxrwxrwx 1 root root 21 Mar  8 02:20 /var/lib/mailman/cron -> 
>/usr/lib/mailman/cron


This is because you have installed some vendors packaged Mailman that
sets prefix to /var/lib/mailman but then symlinks all the immutable
directories in /var/lib/mailman/ to the corresponding
/usr/lib/mailman/ directory, and maybe /var/lib/mailman/logs to
/var/log/mailman.

This is "normal" for your package, but it confuses check_perms because
check_perms sees the group of the link which is actually irrelevant
and then "fixes" the group of the target which is what counts. So,
check_perms has done its job, but the next time it is run, it still
sees the bad group on the link and complains again. You can ignore
these complaints.


>/var/lib/mailman/archives/private/<list-name>/2004-April/index.html bad 
>group (has: mailman, expected list) (fixing)
>
>in some cases there are links to another file.  Does this seem normal?
>
># ls -l /var/lib/mailman/archives/private/<list-name>/2004-April/index.html
>lrwxrwxrwx 1 mailman mailman 11 Jul 30  2010 
>/var/lib/mailman/archives/private/<list-name>/2004-April/index.html -> 
>thread.html


No. This symlink is normal, but normally in your case the
/var/lib/mailman/ directory and all subordinate directories are group
'list' and SETGID so everything in that hierarchy is group 'list'.

It appears that maybe you ported archives from another installation
whose Mailman group was 'mailman' and not 'list'. Now you have all
these symlinks from index.html to thread.html with the wrong group,
and it is difficult at best to change the owner:group of an existing
symlink. You can ignore the complaint from check_perms and leave
things as they are, or you could create a shell script to go through
the archives/private hierarchy and remove all the
archives/private/<list-name>/<period>/index.html -> thread.html
symlinks and recreate them which should give them group 'list' because
the archives/private/<list-name>/<period>/ directories are SETGID, or
if you are sure that all your <list-name>.mbox files are complete and
don't have unescaped "From " lines, you could run something like

#!/bin/sh
for list in `bin/list_lists --bare`; do
    bin/arch --wipe $list
done

to rebuild the HTML archives for all lists.


>also I am getting the following error when visiting the archives page 
>for certain lists.  What is a good way to fix this issue?
>
>--- snip ---
>
>Forbidden
>
>You don't have permission to access /pipermail/<list-name>/ on this server.
>
>--- snip ---
>
># ls -ld *
>drwxrws--- 109 www-data list 4096 Jan 27  2011 private
>drwxrwsr-x   2 mailman  list 4096 Jan 27  2011 public
># ls -ld <mail-list>.mbox/
>drwxrwsr-x 2 80 list 4096 Oct  6  2008 <mail-list>.mbox/


Assuming your web server runs CGI processes as user www-data, the above
owner:group and permissions are correct. The problem may be that in
your apache config, the directory /var/lib/mailman/archives/public is
not Option +FollowSymlinks. The other possibility is the web server
runs CGIs as some other user in which case that user needs to own
/var/lib/mailman/archives/private or /var/lib/mailman/archives/private
needs to be o+x.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan