Hi! My apologies that this is a little disjointed (and betrays a lot of
ignorance on my part).
First, my goal: I want to upgrade our IMAP server (OS and cyrus version)
without the many many hours of downtime that moving all our mail spools
required last time, so what I'm hoping to do is turn the old server into a
one-node murder cluster (with the same host as front-end, back-end, and mupdate
server), and then join the new server to the cluster, migrate all the
mailboxes, and move the front-end and mupdate server to the new server. (Then
we'll be able to reinstall the old server and add it to the cluster, so going
forward it'll be a real cluster with multiple servers.)
I found a few discussions of doing this and it seemed like a reasonable
approach, but I'm having trouble getting ctl_mailbox -m to authenticate to
mupdate (on the same machine).
There are a bunch of things I'm a bit fuzzy on here, and I'm not sure which
one(s) is (are) relevant.
First of all, we've been relying on the historical default of virtdomains:
off; (our users have been configuring their mail clients with bare usernames
since antiquity); so I *think* the mupdate_realm I configure shouldn't matter.
But maybe mupdate doesn't ignore that even though end-user authentication does?
Secondly, I saw some discussion about mupdate requiring PLAIN auth, so *maybe*
sasl_mech_list: PLAIN is what I want. But some of our users depend on GSSAPI
and I think that would break. (Looking at our log, looks like *most* of our
authentications are PLAIN+TLS, but there's a fair amount of other mechanisms,
including GSSAPI+TLS.) If I understand things correctly, there's no way to
force PLAIN auth for mupdate and still allow other mechanisms for end-users, if
the front-end and the mupdate server are the same host; is that correct?
Running strace on /usr/sbin/cyrus ctl_mboxlist -m (with mupdate_server:
localhost) ends with stuff like this:
137159 socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 8
137159 connect(8, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = 0
137159 sendto(8, "<179>Sep 15 14:04:38 cyrus/ctl_mboxlist[137159]:
getaddrinfo(localhost) failed: Servname not supported for ai_socktype", 118,
MSG_NOSIGNAL, NULL, 0) = 118
137159 sendto(8, "<179>Sep 15 14:04:38 cyrus/ctl_mboxlist[137159]:
mupdate_connect failed: no auth status", 87, MSG_NOSIGNAL, NULL, 0) = 87
137159 write(2, "couldn't connect to mupdate server\n", 35) = 35
137159 exit_group(1) = ?
137159 +++ exited with 1 +++
so it looks to me like ctl_mboxlist is not even attempting to authenticate. (I
also tried with mupdate_server being the actual hostname of the machine, but I
don't have a trace of that, and unfortunately testing changes requires downtime
(at least while testing, since I don't yet have a populated mupdate
database), so I don't want to retry this during the workweek)
mupdatetest -m PLAIN to localhost *does* seem to work, and lets me authenticate
successfully. That hints that forcing PLAIN auth (which, again, I think would
break Kerberos for our users) might work; is that my only option?
And can anybody point me at a general guide for the sort of upgrade/migration
by starting with a single-server murder cluster that I'm trying to do? (I
thought I'd found one when I first started thinking about this migration, but
my google-fu is failing me now.)
Thanks, and apologies for the verbosity and disorganization!
Jay
PS — Most of our users are authenticating against credentials in SASL via
sasl_auxprop_plugin: sasldb . Our usernames are consistent across Kerberos and
sasldb. Years ago I tried to get rid of Kerberos authentication and tell
people to use their SASL passwords, but got some pushback. There might be less
by now.
------------------------------------------
Cyrus: Info
Permalink:
https://cyrus.topicbox.com/groups/info/T186bcddd95bbbfb3-M8998143c9ed2b4a109022954
Delivery options: https://cyrus.topicbox.com/groups/info/subscription
