Postfix 2.4 to 2.5: smtp(d)_tls_session_cache_database

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Postfix 2.4 to 2.5: smtp(d)_tls_session_cache_database

Stefan Förster-4
The tlsmgr(8) documentation states:

> With  Postfix version 2.5 and later, the tlsmgr(8) no longer uses root
> privileges when opening cache files. These files should now be stored under the
> Postfix-owned data_directory.  As a migration aid, an attempt to open a cache
> file under a non-Postfix directory is redirected to the Postfix- owned
> data_directory, and a warning is logged.

Right now on our servers, we have:

# postconf -n | grep tls.*cache_database
smtp_tls_session_cache_database = btree:/var/spool/postfix/smtp_scache
smtpd_tls_session_cache_database = btree:/var/spool/postfix/smtpd_scache

If we do want to upgrade from Postfix 2.4 to 2.5, can we (and I'm only
talking about tlsmgr(8) changes) simply follow a procedure like:

1. postfix drain
2. install the new version
3. change the above parameters to use $data_directory
4. copy the cache to the new location
5. [ Perform other needed changes unrelated to tlsmgr(8) ]
6. postfix start

If the above is not a viable way to perform an upgrade, as far as
tlsmgr(8) is concerned, can anyone give me some hints on a better
strategy?

We tested the above several times, and as long as the version of the
database libraries didn't change, we couldn't DETECT any problems so
far. But since we lack intimate knowledge in this area, I'd like to
get some feedback - we could always discard the old databases and
let tlsmgr(8) create new, empty files.


Thanks in advance
Stefan
Reply | Threaded
Open this post in threaded view
|

Re: Postfix 2.4 to 2.5: smtp(d)_tls_session_cache_database

Victor Duchovni
On Fri, May 09, 2008 at 08:43:46AM +0200, Stefan Foerster wrote:

> If we do want to upgrade from Postfix 2.4 to 2.5, can we (and I'm only
> talking about tlsmgr(8) changes) simply follow a procedure like:
>
> 1. postfix drain

Don't do that. Just stop Postfix with "postfix stop".

> 2. install the new version
> 3. change the above parameters to use $data_directory
> 4. copy the cache to the new location

Just start with a fresh cache. Don't copy it.

> 5. [ Perform other needed changes unrelated to tlsmgr(8) ]
> 6. postfix start
>
> If the above is not a viable way to perform an upgrade, as far as
> tlsmgr(8) is concerned, can anyone give me some hints on a better
> strategy?
>
> We tested the above several times, and as long as the version of the
> database libraries didn't change, we couldn't DETECT any problems so
> far. But since we lack intimate knowledge in this area, I'd like to
> get some feedback - we could always discard the old databases and
> let tlsmgr(8) create new, empty files.

Simpler to just drop the cache. The tlsmgr always clears that cache on
restart anyway, so copying it is a waste of effort.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: Postfix 2.4 to 2.5: smtp(d)_tls_session_cache_database

Wietse Venema
In reply to this post by Stefan Förster-4
Stefan Foerster:

> If we do want to upgrade from Postfix 2.4 to 2.5, can we (and I'm only
> talking about tlsmgr(8) changes) simply follow a procedure like:
>
> 1. postfix drain
> 2. install the new version
> 3. change the above parameters to use $data_directory
> 4. copy the cache to the new location
> 5. [ Perform other needed changes unrelated to tlsmgr(8) ]
> 6. postfix start
>
> If the above is not a viable way to perform an upgrade, as far as
> tlsmgr(8) is concerned, can anyone give me some hints on a better
> strategy?

tlsmgr(8) always throws away the TLS session cache on restart.

        Wietse