Got a problem with majordomo that just started happening. For my
scenario please assume Dan Liston's excellent "assumptions" (below).
These all hold true for my site, except that majordomo.cf lives in
/usr/local/majordomo.
System: Redhat 9. Sendmail ver 8.12.9
Majordomo is running fine, has been for several years. Until then
upgrade to Redhat9. Suddenly my moderated lists turn down
moderator-initiated unsubscription requests with the following line in
/usr/local/majordomo/Log (names changed to protect the innocent):
Jun 19 13:29:05 hostname majordomo[20406] {moderator-name <moderator@foo.bar.com>} who listname
Jun 19 13:30:05 hostname majordomo[20419] {moderator-name <moderator@foo.bar.com>} approve PASSWORD unsubscribe listname someone@somewhere.com
Jun 19 13:30:06 hostname majordomo[20419] {moderator-name <moderator@foo.bar.com>} ABORT chown(19, 666, "/usr/local/majordomo/lists/listname.new"): Operation not permitted
Jun 19 13:31:35 hostname majordomo[20430] {moderator-name <moderator@foo.bar.com>} who listname
Jun 19 13:32:35 hostname majordomo[20438] {moderator-name <moderator@foo.bar.com>} approve PASSWORD unsubscribe listname someone@somewhere.com
Jun 19 13:32:35 hostname majordomo[20438] {moderator-name <moderator@foo.bar.com>} ABORT chown(19, 666, "/usr/local/majordomo/lists/listname.new"): Operation not permitted
Jun 20 09:25:31 hostname majordomo[22524] {moderator-name <moderator@foo.bar.com>} who listname
Jun 20 09:26:36 hostname majordomo[22532] {moderator-name <moderator@foo.bar.com>} approve PASSWORD unsubscribe listname someone@somewhere.com
Jun 20 09:26:36 hostname majordomo[22532] {moderator-name <moderator@foo.bar.com>} ABORT chown(19, 666, "/usr/local/majordomo/lists/listname.new"): Operation not permitted
In this case "listname" is a valid majordomo list, which is moderated. The moderator knows the correct password for the list. The address
they're trying to remove exists in the list.
The list directory (/usr/local/majordomo/lists) is owned by user (#19)
"majordomo" and group (#666) "majordomo" and has the following privs:
drwxr-xr-x 3 majordomo majordomo 8192 Jun 23 14:19
/usr/local/majordomo/lists
Majordomo's /etc/passwd entry looks like this:
majordomo:*:19:19:Major Domo,,,,:/usr/local/majordomo:/bin/csh
Yet when majordomo tries to unsubscribe them, apparently it fails in
creating the temp file (listname.new)? Any ideas as to what's going
on? Thanks for any ideas! --michael
p.s. And am I the only one who feels that Majordomo 1.94.5 is adrift
with no one working on it? Dan Liston posted to the developer's list
some time ago asking if it was time to "rebundle" majordomo's
distribution, complete with all of the security fixes/patches. No one
replied. Yet I would love to see a new distro, complete with all of the
requisite security patches (or at the very least a LIST of the necessary
patches one must apply to the 1.94.5 distribution.)
Assumptions:
======================================
Majordomo version 1.94.5
Sendmail version 8.8 (or higher)
You have root permission on the server
to create users,
modify the aliases file, and
rebuild the aliases database.
You have created a
majordomo user and
majordomo group.
The majordomo $HOME directory is
/usr/local/majordomo and this is owned by
user majordomo and
group majordomo.
The smrsh directory (if used) is
/etc/smrsh and holds a
link owned by root to
/usr/local/majordomo/wrapper.mytld
There are no group or world "writable" directories in the path
to /usr/local/majordomo, including / (root).
Sendmail "trusts" majordomo. You have a Tmajordomo line in
sendmail.cf and submit.cf or these files use the
/etc/mail/trusted-users file.
Sendmail only recognizes one "/etc/aliases" file.
Others are allowed but outside the scope of this note.
Sendmail uses the "always_add_domain" feature.
The majordomo config file is /etc/majordomo.cf
The majordomo.cf variables are defined statically. No
$whereami = "`/bin/dnsdomainname`";
it should be
$whereami = "myhost.mydomain.tld";
You already have a working list that utilizes resend.
eg. wrapper resend -l <listname> <listname>-outgoing
Your aliases file contains
nobody: /dev/null ordomo
Follow-Ups:
|
|
