Bug 202357 - Upgrade breaks TLS enabled configs
Upgrade breaks TLS enabled configs
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: postfix (Show other bugs)
4.4
All Linux
high Severity urgent
: ---
: ---
Assigned To: Thomas Woerner
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-13 12:28 EDT by Graham Leggett
Modified: 2007-11-16 20:14 EST (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2007-0268
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-01 13:31:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed specfile patch (870 bytes, patch)
2006-08-18 14:27 EDT, Jeff Layton
no flags Details | Diff

  None (edit)
Description Graham Leggett 2006-08-13 12:28:54 EDT
After letting up2date upgrade postfix to postfix-2.2.10-1.RHEL4.2, TLS protected
mail delivery suddenly stops working with the following error message:

Aug 13 11:16:32 chandler postfix/smtp[10344]: warning: connect #1 to subsystem p
: No such file or directory
Aug 13 11:16:32 chandler postfix/smtp[10345]: warning: connect to private/tlsmgr
: No such file or directory
Aug 13 11:16:32 chandler postfix/smtp[10345]: warning: problem talking to server
 private/tlsmgr: No such file or directory
Aug 13 11:16:32 chandler postfix/smtp[10345]: warning: no entropy for TLS key ge
neration: disabling TLS support
Aug 13 11:16:32 chandler postfix/smtp[10346]: initializing the client-side TLS e
ngine
Aug 13 11:16:32 chandler postfix/smtp[10346]: warning: connect to private/tlsmgr
: No such file or directory

Mail delivery remains broken until the following command is run:

postfix upgrade-configuration

After this command is run and postfix restarted, mail delivery of TLS protected
connections continues normally.

More detail here:

http://www.thisishull.net/archive/index.php/t-99632.html
Comment 2 Jeff Layton 2006-08-18 14:27:59 EDT
Created attachment 134464 [details]
proposed specfile patch

Ok, it looks like this likely came about when we rebased the package, so I
don't think this is a bug in the actual program, per-se, but more a packaging
problem.

The specfile has this in the %post section:

# upgrade configuration files if necessary
sh %{postfix_config_dir}/post-install \
	config_directory=%{postfix_config_dir} \
	daemon_directory=%{postfix_daemon_dir} \
	command_directory=%{postfix_command_dir} \
	mail_owner=%{postfix_user} \
	setgid_group=%{maildrop_group} \
	manpage_directory=%{_mandir} \
	sample_directory=%{postfix_sample_dir} \
	readme_directory=%{postfix_readme_dir} \
	upgrade-package

While not spelled out explicitly in the readme files per-se, the PACKAGE_README
file seems to indicate that this command is deprecated as of version 2.1. The
attached patch changes this to run postfix set-permissions
upgrade-configuration (which sort of looks like the correct way to do this in
new versions).

Does this look reasonable? We may want to make a similar change in Fedora as
well...
Comment 3 Jeff Layton 2006-08-18 14:41:40 EDT
Hmm, actually, I may be wrong here. postfix upgrade-configuration... eventually
runs post-install, with similar args to what we're doing now. So it's not clear
to me that this patch will make any difference.

Graham, can you confirm whether you had actually tried restarting postfix before
running upgrade-configuration, and that the errors still continued?

I need to narrow down whether this problem was actually solved by running
postfix upgrade-configuration here, or whether the restart is what actually did it.
Comment 5 Graham Leggett 2006-08-20 11:52:14 EDT
As I recall I did try restarting postfix - it contains an annoying misfeature in
that it negatively caches failures, meaning the only way to get mail flowing
again after a failure that has been corrected is to restart.

Restarting didn't make a difference, I only found the solution after hunting it
down with Google.

A second server in the secure mail cluster was also upgraded via up2date, and it
too stopped delivering mail to others in the cluster, implying that a restart
did occur during the upgrade. Running postfix upgrade-configuration and a manual
restart fixed that one.
Comment 6 Jay Turner 2006-08-20 21:52:39 EDT
QE ack for 4.5.
Comment 7 Thomas Woerner 2006-09-01 11:24:48 EDT
What have you configured for 2.1, what needs to be chnaged from 2.1 to 2.2?

Can you please post the 2.1 config and the changes to the new config after
postfix upgrade-configuration?
Comment 10 Jan Lieskovsky 2007-02-16 05:19:53 EST
New pkgs(postfix-2.2.10-1.1.el4.*): 

Have tested TLS support in postfix as root and as normal user "testuser"
and it works in both cases - when email client uses "TLS, if available"
or "TLS" for secure connection:

1, First add TLS support to postfix:
   a, telnet localhost 25 =>
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 s390x-4as.z900.redhat.com ESMTP Postfix
EHLO s390x-4as.z900.redhat.com
250-s390x-4as.z900.redhat.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS   (<- TLS support added )
250 8BITMIME

2, Configure email client to use TLS:
   a, e.g in Mozilla - create new Email account,and click "View settings for 
   this account" link and in "SMTP Server:" dialog window check either
   "TLS, if available" checkbox or "TLS" checkbox for "Use secure connection:" 
   option

3, Successful TLS usage can be viewed in /var/log/mailog: 
. . .
Feb 16 04:43:08 s390x-4as postfix/smtpd[6554]: TLS connection established from
localhost.localdomain[127.0.0.1]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256
bits)
Feb 16 04:43:08 s390x-4as postfix/smtpd[6554]: E117A3C53E:
client=localhost.localdomain[127.0.0.1]
Feb 16 04:43:08 s390x-4as postfix/cleanup[6562]: E117A3C53E:
message-id=<45D57CAC.1060401@s390x-4as>
Feb 16 04:43:08 s390x-4as postfix/qmgr[6273]: E117A3C53E:
from=<testuser@s390x-4as.z900.redhat.com>, size=770, nrcpt=1 (queue active)
Feb 16 04:43:08 s390x-4as postfix/smtpd[6554]: disconnect from
localhost.localdomain[127.0.0.1]
Feb 16 04:43:14 s390x-4as postfix/smtp[6563]: E117A3C53E:
to=<jlieskov@redhat.com>, relay=int-mx1.corp.redhat.com[172.16.52.254], delay=6,
status=sent (250 2.0.0 l1G9hl3G021144 Message accepted for delivery)
Feb 16 04:43:14 s390x-4as postfix/qmgr[6273]: E117A3C53E: removed
. . . 
   
Didn't reproduce the "TLS malfunction" on old packages, just verified the
possible "TLS" support by new postfix packages -> leaving this one in ON_QA. 
Comment 13 Red Hat Bugzilla 2007-05-01 13:31:20 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0268.html

Note You need to log in before you can comment on or make changes to this bug.