I apologize for posting your entire message in my reply, but I will
be inserting comments throughout.
Michael Regoli wrote:
> 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.
Unless you host mailing lists, or yours is hosted, I recommend putting
majordomo.cf in /etc or at least creating a link there to the one in
/usr/local/majordomo. The perl scripts all seem to want to use this
location by default, or at least as a alternate option to the $ENV
for majordomo.
>
> System: Redhat 9. Sendmail ver 8.12.9
You know that sendmail 8.12.x has some configuration issues we have
not been used to with previous versions? There is now the sendmail
message submission program (smmsp) that must be dealt with to allow
for majordomo lists. Group memberships, file ownerships, and another
configuration that must "trust" majordomo.
>
> 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):
Does the moderator also have local access to the majordomo/sendmail
server, or does all the work happen via email commands?
>
> 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.
Considering this was all working for a long time before the OS upgrade
which included a sendmail upgrade, you may want to focus on that area.
What is the relationship between majordomo and the new smmsp? What
new security requirements have been introduced or are now more strictly
enforced? Maybe you just need to add the majordomo user to the smmsp
group.
>
> 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
You have a "slight" conflict of information here. The passwd entry for
majordomo states it's group membership to be 19 rather than 666. I use
91:91 on my redhat system, just to stay matched up with the RPM. Is it
possible that you have two entries for majordomo in the /etc/group file?
Side note: csh is probably not the best choice of shells for majordomo.
>
> 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.)
I think the most work was done on majordomo between '92 and '93. The
.5 release added some cool and needed features, but still has some Y2k
compatibility issues with digest and archive. Those of us that still
like to tinker, do not own majordomo or have any right to release code
that has not been approved for distribution by the owner.
There is a majordomo II project that appears to be active, and even though
the code is _STILL_ in alpha release after more than 3.5 years, claims have
been made by many users that it outperforms majordomo 1.9x considerably.
Dan Liston
Follow-Ups:
References:
|
|
