> Check_perms fails to find it, and it's turning into a major problem. Doublecheck your version of check_perms; the code is there, and it works, in 2.0.5. Are you running check_perms from the installed bin/ directory as the instructions and about a billion posts on this list say? > What (exactly) writes and rewrites the config.db file and what are the actual > permissions it's supposed to have? It should be owned by the user who writes it (which might be a lot of places). It should be group mailman, because the directory that it's in should be group mailman, and have the "group-id bit" set so that other file creations in that directory are also done by group mailman, and also because all the programs that write it are themselves sgid-mailman. In the case where you're updating things from the web page, the web server run the CGI program, probably in your case as user "nobody"; the CGI program validates the group it has been run as, and then sets its GID to mailman before continuing. That means all files it creates will be group mailman. check_perms should be finding all this; you need to find out what's going wrong with check_perms. > From ealier reference it sounded as though > it should be owned by nobody (since the webserver > modifies/creates/backs-up/etc) and the group should be mailman. Ok - I can deal > with this - but after manually setting the ownership to be just that - this is > what I get after waiting a while and checking again: > > [root@unica mailman]# ls -lR lists/|grep config.db > -rw-rw---- 1 nobody mailman 9759 May 9 14:14 config.db > -rw-rw---- 1 nobody mailman 9759 May 9 14:14 config.db.last > -rw-rw---- 1 nobody mailman 16876 May 9 15:27 config.db > -rw-rw---- 1 nobody mailman 16876 May 9 15:26 config.db.last > -rw-rw---- 1 nobody mailman 2865 May 3 04:03 config.db > -rw-rw---- 1 nobody mailman 2865 May 3 04:03 config.db.last > -rw-rw---- 1 nobody mailman 3775 May 9 12:00 config.db > -rw-rw---- 1 nobody mailman 3775 May 8 17:00 config.db.last > -rw-rw---- 1 nobody mailman 5123 May 9 14:08 config.db > -rw-rw---- 1 nobody mailman 5123 May 9 14:08 config.db.last > -rw-rw---- 1 nobody mailman 3149 May 9 12:00 config.db > -rw-rw---- 1 nobody mailman 3149 May 8 17:00 config.db.last > > [root@unica mailman]# ls -lR lists/|grep config.db > -rw-rw---- 1 mailman mail 9759 May 9 17:00 config.db > -rw-rw---- 1 nobody mailman 9759 May 9 14:14 config.db.last > -rw-rw---- 1 mailman mail 16876 May 9 17:00 config.db > -rw-rw---- 1 nobody mailman 16876 May 9 15:27 config.db.last > -rw-rw---- 1 nobody mailman 2865 May 3 04:03 config.db > -rw-rw---- 1 nobody mailman 2865 May 3 04:03 config.db.last > -rw-rw---- 1 mailman mail 3775 May 9 17:00 config.db > -rw-rw---- 1 nobody mailman 3775 May 9 12:00 config.db.last > -rw-rw---- 1 mailman mail 5123 May 9 17:00 config.db > -rw-rw---- 1 nobody mailman 5123 May 9 14:08 config.db.last > -rw-rw---- 1 mailman mail 3149 May 9 17:00 config.db > -rw-rw---- 1 nobody mailman 3149 May 9 12:00 config.db.last > > As you can see - the ones that get modified have their permissions changed to > 'mailman:mail' and I've seen further changes where it becomes 'nobody:mail' and > then mailman starts spitting errors out right and left and the lists just queue > up messages and don't do anything anymore. Could someone please explain in > detail exactly how it's /supposed/ to happen in a good situation? > > <EOL> > Tib > > > ------------------------------------------------------ > Mailman-Users maillist - [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/mailman-users ------------------------------------------------------ Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
