[Mailman-Users] What happened to my archive? Why isn't the archive process running?

[TGPlatt, WebMaster]

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:mark at msapiro.net]
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.