[Mailman-Users] permission problems with new install...

Have you tried the check_perms script yet? You should find it in the ~mailman/bin directory.

--
Richard Ellerbrock
richarde at eskom.co.za
I'm setting up a new Mailman server to replace an old one, and I'm running into the
"Bug in Mailman 2.0..." message when I try to go to the initial admin page, or even the
base listinfo.cgi page.

It appears that there is a permission problem with perms on the config.db file and/or the
lock directory. As far as I can tell the cgi-bin is working for other sites, but this one
still has problems. I can't see any differences in perm between my functional server and
this new one. I will attach the traceback below. The machine is running Solaris 2.6,
patched current.

When calling <site>.edu/cgi-bin/listinfo.cgi/test3
I wind up with the attached traceback.

Any suggestions?

-Demian


Jan 04 03:14:16 2001 admin(6878): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
admin(6878): [----- Mailman Version: 2.0 -----]
admin(6878): [----- Traceback ------]
admin(6878): Traceback (most recent call last):
admin(6878): File "/home/mailman/scripts/driver", line 96, in run_main
admin(6878): main()
admin(6878): File "/home/mailman/Mailman/Cgi/listinfo.py", line 42, in main
admin(6878): mlist = MailList.MailList(listname, lock=0)
admin(6878): File "/home/mailman/Mailman/MailList.py", line 79, in __init__
admin(6878): self.Load()
admin(6878): File "/home/mailman/Mailman/MailList.py", line 891, in Load
admin(6878): dict, e = self.__load(dbfile)
admin(6878): File "/home/mailman/Mailman/MailList.py", line 868, in __load
admin(6878): fp = open(dbfile)
admin(6878): IOError: [Errno 13] Permission denied:
'/export/space/mailman/lists/test3/config.db'
admin(6878): [----- Python Information -----]
admin(6878): sys.version = 2.0 (#1, Dec 6 2000, 22:04:56)
[GCC 2.8.1]
admin(6878): sys.executable = /usr/local/bin/python
admin(6878): sys.prefix = /usr/local
admin(6878): sys.exec_prefix= /usr/local
admin(6878): sys.path = /usr/local
admin(6878): sys.platform = sunos5
admin(6878): [----- Environment Variables -----]
admin(6878): DOCUMENT_ROOT: /export/space/mailman
admin(6878): HTTP_ACCEPT_ENCODING: gzip
admin(6878): HTTP_PRAGMA: no-cache
admin(6878): SERVER_PORT: 80
admin(6878): PATH_TRANSLATED: /export/space/mailman/test3
admin(6878): SERVER_SOFTWARE: Apache/1.3.14
admin(6878): HTTP_ACCEPT_LANGUAGE: en
admin(6878): REMOTE_PORT: 2984
admin(6878): HTTP_CONNECTION: Keep-Alive
admin(6878): HTTP_USER_AGENT: Mozilla/4.74 [en] (Windows NT 5.0; U)
admin(6878): HTTP_ACCEPT_CHARSET: iso-8859-1,*,utf-8
admin(6878): HTTP_ACCEPT: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
image/png, */*
admin(6878): REQUEST_URI: /cgi-bin/listinfo.cgi/test3
admin(6878): QUERY_STRING:
admin(6878): SCRIPT_FILENAME: /export/space/mailman/cgi-bin/listinfo.cgi
admin(6878): PATH_INFO: /test3
admin(6878): REQUEST_METHOD: GET
admin(6878): SCRIPT_NAME: /cgi-bin/listinfo.cgi
admin(6878): SERVER_ADMIN: webmaster at csbs.utah.edu
admin(6878): GATEWAY_INTERFACE: CGI/1.1
admin(6878): PYTHONPATH: /home/mailman
admin(6878): HTTP_COOKIE: SITESERVER=ID=0d32b49f441ad4d07be8d46527013a72
admin(6878): TZ: US/Mountain
admin(6878): SERVER_PROTOCOL: HTTP/1.0

Excellent! Someone else has the same problem I have. I can't offer any help,
but I can say that I've run into this problem too on two of my virtual servers
and maybe now we can track down what we have in common. My installations
are on virtual servers in chrooted environments. Can you offer some details
on the differences between your working installation and your non-working
one?

Like you, I've already installed Mailman and have successfully created working
installations. For some reason, though, my virtual installations always need
to have the permissions changed to be fairly permiscuous in order to get
things to work. I've checked the UID and GID of my working vs. non-working
installations; both match. The permissions of my working vs. non-working
installations match as well.

Dave Klingler

Hi Brian.
Well, like I've said I've done a careful comparison to figure out what's
happening. Permissions between working and non-working installations are
*exactly* alike, which points to a UID or GID problem, but then the UID and
GID are set alike as well. That fact says that UID or GID are being reset
along the way, a detail I've looked for by using strace and following the
process step by step. I haven't figured out what's happening yet, but
maybe soon...

Like I said, this is Mailman working in chrooted virtual machines, which is
a strange animal for some reason.

Thanks!
Dave Klingler

At some point today, I said

After much hand-wringing, chmoding, chowning, trussing, and
re-compiling I still could not get beyond this simple little
problem.

Alas, when double-checking my double-checks I stumbled across a
nosuid flag in the vfstab.

Silly me.

As a thanks to all for the other recommendations I offer a
bit of paraphrased advice from my sage friend Ockham:

"What can be done with fewer assumptions is done in vain with more.
That is, in explaining any phenomenon, use no more explanatory
concepts than are absolutely necessary."

Ockham's Razor

-demian