Postfix 2.4 to 2.5: smtp(d)_tls_session_cache_database

10 msg	header check question
12 msg	verify parameters
4 msg	Configure postfix in big env
2 msg	envelope sender '<>' via uucp gets rewrit...
2 msg	Spam filtering only for specific email accounts

Postfix 2.4 to 2.5: smtp(d)_tls_session_cache_d...
\ Stefan Foerster (9 May 2008)
. \ Victor Duchovni (9 May 2008)
. \ (Wietse Venema) (9 May 2008)

15 msg	Question about 'standards' WRT BATV and SAV
7 msg	my solution to fight backscatter email
2 msg	AUTO: Joe Grastara is out of the office (return...
12 msg	Q about sender_dependent_relayhost_maps inbound...
16 msg	Milter Suggestions
9 msg	Transport table and postmap
3 msg	Archiving e-mail?
8 msg	Error 550: unable to relay
1 msg	FW: new subject
13 msg	TLS handshake error
6 msg	Seperating SMTP and POP/IMAP services
3 msg	Test 2
1 msg	Testing
12 msg	[Fwd: ldap users & aliases config]

Subject:	Postfix 2.4 to 2.5: smtp(d)_tls_session_cache_database
Group:	Postfix-users
From:	Stefan Foerster
Date:	9 May 2008

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