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.