Adam Gibson wrote:
> Adam Gibson wrote:
>
>> One thing I noticed after the latest yum update of sendmail from the
>> previous update is that alternatives is broken for /etc/pam.d/smtp for
>> the sendmail package. <<snip>>
> So basically it boils down to alternatives with the newer sendmail
> updates do not do anything with /etc/pam.d/smtp anymore(It is part of
> the packages itself and not a symlink). The problem I had is that the
> old symlink was in the way when sendmail was updated.
My take, judging from previous comments you've posted, Adam, is that you run
the Red Hat 9 version of sendmail? There are 3 packages available in updates
for RH9:
1) sendmail-8.12.8-9.90.i386.rpm (Release 9/17/03 by RH,
vulnerable)
2) sendmail-8.12.11-4.24.1.legacy.i386.rpm (Released 3/23/06 by FL)
3) sendmail-8.12.11-4.24.3.legacy.i386.rpm (Released yesterday by FL)
The original Sendmail (8.11.6 for RH7.3, 8.12.8 for RH9 and 8.12.10 for FC1)
did not create any kind of alternatives for /etc/pam.d/smtp nor for
/usr/lib/sendmail. They were just plain files, packaged as part of the rpm.
However, the first updated packages for RH9 and FC1 *did* create alternatives
for both of those files, and perhaps also for the sendmail.8 man-page.
This created problems for many of our users. Although in the process of
updating from 8.12.8 to 8.12.11-4.24.1.legacy, the alternatives system would
(during the run of the POST-INSTALL scriptlet) create /etc/pam.d/smtp and
/usr/lib/sendmail as symlinks to files in /etc/mta, later in the rpm update
process (when uninstalling 8.12.8) those symbolic links would be erased,
because /etc/pam.d/smtp and /usr/lib/sendmail were packaged files in the
former rpm.
This ended up then with many users that depended on /etc/pam.d/smtp (for SMTP
AUTH to work correctly) with broken sendmail packages; similarly with users
who needed /usr/lib/sendmail to point to the MTA program.
To fix this bug in RH9's sendmail-8.12.11-4.24.1.legacy (similarly in
FC1's), we elected to revert the alternatives behavior to what it had
been in sendmail-8.12.8. The various scenarios might be, then:
a) User is using 8.12.8, elects to upgrade directly to 8.12.11-4.24.3.
No problem. Alternatives system the same, so /etc/pam.d/smtp and
/usr/lib/sendmail files are upgraded unless changed by the end user,
in which case /etc/pam.d/smtp.rpmnew is created.
b) User is using 8.12.8, has upgraded to 8.12.11-4.24.1. Uh oh, smtp auth
is no longer working or /usr/lib/sendmail gone. User reverts to
8.12.8, sendmail works again. User then upgrades to 8.12.11-4.24.3.
Works okay; alternative system the same.
c) User is using 8.12.8, upgraded to 8.12.11-4.24.1. Same problems as
(b). User either fixes this by hand (by making a symlink /etc/pam.d/
smtp -> smtp.sendmail &c) or fixes this using the "alternatives
--config mta" command, as suggested by Marc in
<http://tinyurl.com/jdwko>. If user does either of these two things, a
later upgrade to sendmail-8.12.11-4.24.3 will break /etc/pam.d/smtp,
causing it to point to a non-existent /etc/pam.d/smtp.sendmail, and
create /etc/pam.d/smtp.rpmnew. This one, I think, would have been your
scenario, Adam. You have provided a good workaround for this.
d) User using 8.12.8, upgraded to 8.12.11-4.24.1, finds it doesn't work,
then upgrades to 8.12.11.4.24.3 without making any config changes.
This, too, works okay, because at the end of installing 8.12.11-4.24.1,
the user never ended up with /etc/pam.d/smtp nor /usr/lib/sendmail in
the first place. So a subsequent upgrade to 8.12.11-4.24.3 will in-
stall those files as new.
In 3 out of 4 scenarios (perhaps there are more?), upgrading to our most
recently-released package works, at least for RH9. I believe there would be
similar scenarios for RH7.3 and FC1. Otherwise, as in (c) above, the user
needs to employ a workaround if needing /etc/pam.d/smtp or /usr/lib/sendmail.
> I wonder if other MTAs expect /etc/pam.d/smtp to still be a symlink. If
> you do an alternatives for postfix or some other mta will it overwrite
> /etc/pam.d/smtp? If so that could be a problem if you switch back.
I checked the most recent postfix package for RH9, and it appears that the
alternatives is correctly configured. However, for FC1's postfix, it does not
appear to be correctly configured, so this could be an issue for FC1 users who
switch from sendmail to postfix. As this is not a security issue per se, it
is not likely to be fixed.
None of these alternatives system issues should affect FC2 or FC3 users, as
Fedora Legacy's updates used the same alternatives configuration as were
previously used for FC2 and FC3, so the upgrade should "just work."
Hope this helps explain the situation, Adam. It was a mess, and we did the
best we knew to fix it. Sorry for the trouble it has caused.
Warm regards,
David Eisenstein
--
fedora-legacy-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-legacy-list
