I'm sorry to turn up in your support forum again, Mark. I've fought hard here to try to avoid that. The truth is it was our struggle with trying to configure my old server for mailman back in June and July that proved to be the straw that broke the camel's back with my old dedicated server hosting service. In early July I asked them about getting an updated server and software but the price they quoted was so darn high I decided to bail out on them and ended up choosing a hosting company that provided much more server for the $ plus the latest version of Debian Etch (rather than the 5 year old version of RedHat I was running) for the same price I'd been paying to my old hosting service. The BIG difference was I had to take full admin responsibility for my server setup and configuration; but I figured what the hell, I'm already doing 80% of that job anyway with very little support coming from my old host.
So, when my old server came up for renewal at the end of July, I went month-to-month on my lease with them and bought the new server to take its place. I struggled through server setup and the migration of all my existing sites from the old server in August and September. At the end of September with just 3 sites left to move I grabbed the last 3 sites, made my final backups, and pulled the plug on the old server on the weekend before it would have renewed for another month... jumping out the window (from what turned out to be the 12th floor) with my final backups under my arm. :-) During October, I struggled to get the server set up to support mailman for multiple accounts. That entailed installing and testing it for the current client and setting up the server to support virtual domain hosting under Apache2, postfix and mailman so that we can eventually support mailman for multiple domains on this server. Until you mentioned suEXEC in your message yesterday, I'd nearly forgotten that part of our June-July nightmare. When I checked this morning, I found that when Apache2 was installed on this server it's standard installation process did include suEXEC. However, under Debian's Apache2 setup, it's easy to disable suEXEC and restart Apache. As far as I know, nothing else on the server was relying on the presence of suEXEC and it certainly wasn't my intent to install that Apache feature to begin with. So, suEXEC has now been disabled. Now can we talk about the proper ownership of all the mailman files both IN /usr/local/mailman directory structure and in the UserAccount/mailman directory as well? Shouldn't all (or most of) these files be owned by mailman / mailman? Is that also true in the /archives/private/mylist directory? What about over in the /home/mylist/www directory? Who should own the mailman directory there? I have run bin/check_perms several times but it doesn't complain about any problems. Thanks! Or should I just put take a large dose of cyanide and go take a long nap instead? Thanks! -----Original Message----- From: Mark Sapiro [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2008 3:21 PM TGPlatt, WebMaster wrote: > >Could this be a group/owner-ship issue? Yes. It took me a while, but I finally connected you with our exchanges from last June/July :) <snip> --- There were undoubtedly problems on the old server because of SUExec issues which I told you at the time was incompatible with Mailman's security model since Mailman's CGI wrappers can't be SETGID under SUExec and that's the whole point of the wrappers in the first place. So ownership and permissions within Mailman have to be such that the SUExec user can read and write. But the qrunner processes also have to be able to read and write and they will run as the mailman user:group. Normally the owner doesn't matter because everything runs as group mailman, but that may not be the case here. <snip> >and when I check the files in that directory, they're owned by root as >a member of the group mailman. That should be OK because ArchRunner should be running as group mailman and the files should be group writable. <snip> >when I look at the qfiles/shunt directory in the 9/28 backup, >the oldest file there seems to be from 09-20-2008. So it looks to me >like it was only keeping those shunt files 5 or 6 days before discarding >them. If you are running Mailman 2.1.11, there is a cron that runs daily and by default it discards anything in qfiles/bad and qfiles/shunt older than 7 days. From Defaults.py # The length of time after which a qfiles/bad or qfiles/shunt file is # considered to be stale. Set to zero to disable culling of qfiles/bad and # qfiles/shunt entries. BAD_SHUNT_STALE_AFTER = days(7) # The pathname of a directory (searchable and writable by the Mailman cron # user) to which the culled qfiles/bad and qfiles/shunt entries will be # moved. Set to None to simply delete the culled entries. BAD_SHUNT_ARCHIVE_DIRECTORY = None <snip> So you still have permissions issues. You could start with bin/check_perms which should get them right except if the web server is still SUExec, the web interface may not work. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9