dovecot - Jan 2011 - Finally upgrading from v1.0.15 to v1.2.16 -- advice please

It's long over due, but now I finally plan on upgrading from v1.0.15 to
v1.2.16 on our servers. Would appreciate any comments!

We have 7 servers, all running of the same GPFS filesystem. Both
maildirs and indexes are stored here. We use dovecot for POP/IMAP and
deliver. Currently we're using mysql as authentication source, but want
to move to using ldap instead.

Can we upgrade one server at a time, or do we need to upgrade all
servers at the same time ? http://wiki2.dovecot.org/Upgrading/1.1 says
"Index files have slightly changed as well. Upgrading to v1.1 should go
transparently, but moving back to v1.0 might again cause some errors."
which makes me think we can't have both versions running against the
same users ?

Also, if we upgrade only one server, should we switch to
"mmap_disable=no"
on this one, or keep running with "mmap_disable=yes" on all servers ?

"NFS users should now set mail_nfs_storage=yes and
mail_nfs_index=yes."
Does this apply to any shared/networked filesystems, and is this
relevant for GPFS ?

The sql queries we're doing now is:

	password_query = select U.Account as user,S.Password as password from Users U,
UserSession S where U.Account=S.Account and U.Account='%u'
	user_query = SELECT 3000 as uid, 3000 as gid, concat(concat('maildir:',
MailDir), concat(':INDEX=', replace(MailDir,
'/usr/local/atmail/users', '/usr/local/atmail/users/indexes')))
as mail, concat('maildir:storage=', UserQuota) as quota FROM Users WHERE
Account = '%u'

I plan on doing ldap bind() for authentication:

	hosts = maildb3.example.net:389
	auth_bind = yes
	ldap_version = 3
	base = ou=people,o=%d,o=ISP,o=example,c=net
	deref = never
	scope = onelevel
	user_filter = (&(objectClass=altiboxperson)(uid=%n))
	default_pass_scheme = SSHA

but the user_query is a challenge..  In LDAP we have:

	uid = janfrode, ou=people,o=domain1.net,o=ISP,o=example,c=net
	mail = janfrode at domain1.net
	mailMessageStore = /usr/local/atmail/users/j/a/janfrode at domain1.net
	mailQuota = 1000000
	domain = domain1.net
	userPassword = SSHA-string

So, outside of the user_attrs we need:

	mail_uid = 3000
	mail_gid = 3000

But I'm having a hard time understanding how I can use the ldap value
mail=/usr/local/atmail/users/j/a/janfrode at domain1.net to translate into 
dovecot's "mail" containing both "maildir:" and
"INDEX=".

Does the below look correct ?

	user_attrs =
mailMessageStore=mail=maildir:%$:INDEX=/usr/local/atmail/users/indexes/%1u/%1.1u/%u,
mailQuota=quota_rule=*:storage=%$

i.e. will it point dovecot at:

	mail = maildir:/usr/local/atmail/users/j/a/janfrode at
domain1.net:INDEX=/usr/local/atmail/users/indexes/j/a/janfrode at domain1.net
	quota_rule=*:storage=1000000



  -jf

On Mon, 2011-01-03 at 14:06 +0100, Jan-Frode Myklebust
wrote:
> It's long over due, but now I finally plan on upgrading from v1.0.15 to
> v1.2.16 on our servers. Would appreciate any comments!
> 
> We have 7 servers, all running of the same GPFS filesystem. Both
> maildirs and indexes are stored here. We use dovecot for POP/IMAP and
> deliver. Currently we're using mysql as authentication source, but want
> to move to using ldap instead.
> 
> Can we upgrade one server at a time, or do we need to upgrade all
> servers at the same time ?
You could have upgraded from v1.0 to v1.1 or v1.1 to v1.2 incrementally,
but v1.2's index changes haven't been backported to v1.0, so if v1.0
accesses indexes modified by v1.2 you'll probably get some errors.
> Also, if we upgrade only one server, should we switch to
"mmap_disable=no"
> on this one, or keep running with "mmap_disable=yes" on all
servers ?
Keep it as "yes" always.
> "NFS users should now set mail_nfs_storage=yes and
mail_nfs_index=yes."
> Does this apply to any shared/networked filesystems, and is this
> relevant for GPFS ?
Probably not. If it worked fine with v1.0 then you don't need these.
> Does the below look correct ?
> 
> 	user_attrs =
mailMessageStore=mail=maildir:%$:INDEX=/usr/local/atmail/users/indexes/%1u/%1.1u/%u,
mailQuota=quota_rule=*:storage=%$
> 
> i.e. will it point dovecot at:
> 
> 	mail = maildir:/usr/local/atmail/users/j/a/janfrode at
domain1.net:INDEX=/usr/local/atmail/users/indexes/j/a/janfrode at domain1.net
> 	quota_rule=*:storage=1000000
Yes. Although if the mail directory can be created by such a template,
you could do it without having the directory in ldap at all..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20110104/1d608ef3/attachment-0002.bin>

On Tue, Jan 04, 2011 at 11:35:42AM +0200, Timo Sirainen
wrote:
> 
> You could have upgraded from v1.0 to v1.1 or v1.1 to v1.2 incrementally,
> but v1.2's index changes haven't been backported to v1.0, so if
v1.0
> accesses indexes modified by v1.2 you'll probably get some errors.
> 
I think we'll just jump in with both feet, and upgrade them all to v1.2
at the same time. If, in worst case, we need to downgrade, do we need to
delete all indexes first, or will the errors resolve themselves ?

I just tested accessing the same mailbox over imap first against v1.2
then against v1.0.15, and didn't see any problems logged. But maybe that
was too light testing to reveal any problems..
> > Does the below look correct ?
> > 
> > 	user_attrs =
mailMessageStore=mail=maildir:%$:INDEX=/usr/local/atmail/users/indexes/%1u/%1.1u/%u,
mailQuota=quota_rule=*:storage=%$
> > 
> > i.e. will it point dovecot at:
> > 
> > 	mail = maildir:/usr/local/atmail/users/j/a/janfrode at
domain1.net:INDEX=/usr/local/atmail/users/indexes/j/a/janfrode at domain1.net
> > 	quota_rule=*:storage=1000000
> 
> Yes. Although if the mail directory can be created by such a template,
> you could do it without having the directory in ldap at all..
What would I then have on the left hand side of the expression instead
of ldap attribute ? Hmm, I think I'll stick with the ldap attribute, to
force us to keep the ldap data correct in case we ever want to replace
some parts of dovecot with something that doesn't allow such templating.


  -jf