I've now completed my cutover to the new server, and have answered
some of my own questions
Following on from my question on enabling squatter on my new install...
I have upgraded from Cyrus 2.3.7 on a CentOS 5 server to 2.4.17. on
a new CentOS 7 server. I've not yet migrated the users (only 6 x
users). They are both VMs on the same host, and at migration point I
can simply bring up the new server with the drive from the old Cyrus
VM that has the Cyrus partition on it, so new Cyrus will be able to
'see' the mailboxes without having to do rsync or anything like that.
I've tested the new Cyrus server and it all appears to be
functioning - listening on correct ports / sockets, delivering mail
etc.
So my questions:
1. Is 2.4.17 compatible with the mailboxes transferred from the old
Cyrus 2.3.7 server?
I rsync'ed the entire partition structure across from the 2.3.7 server
to the 2.4.17 server, along with the /var/lib/imap folder, and started
cyrus-imapd - to see if it would work. The service started, and
immediately started running through all of the mailboxes, updating
indexes, e.g.:
squatter[10495]: Index upgrade: user.simon.Saved Emails (9 -> 12)
I was then able to log in to IMAP and everything was there, so I'm
assuming we're all good.
2. Assuming it is? Once the new Cyrus can see the mailboxes, will a
reconstruct be needed to have new Cyrus able to see the full mailbox
structure? If so with what flags to rebuild out all sub-mailboxes?
Will it retain 'seen' / replied flags and ACLs?
I ran a basic reconstruct, but it did not appear to have needed it.
All flags and ACLs appear to be fine.
3. Do I need to do anything with the contents of /var/lib/imap/ on
the old server for retention on the new server?
I rsync'ed it across and started the new server with the old mailbox
databases, and it appears to be OK.
4. Will I need to rebuild quotas once new Cyrus can see the mailboxes?
I had to rebuild a couple of the quotas that were appearing wrong.
5. What is the best way to migrate sieve scripts? These are NOT on
the drive to be moved to the new server, so will need to be migrated
manually from /var/lib/imap/sieve etc... As a test I did a manual
copy to the new server of a sieve script, set permissions and soft
links, and it appears to work - is that the best way?
Sieve scripts came over with the /var/lib/imap folder, and apart from
it now listening on 4190 instead of 2000 (which had me for a few
minutes) all is not working fine with sieve.
Thanks in anticipation of assistance :)
Simon.
--
Simon Wilson
Only one issue that I am having with the new 2.4.17 install.
I use unixhierarchysep: 1 and have a couple of users with a "." in
their name, e.g. deb.tony. The cyrus folder on the partition for them
is deb^tony, although they appear in cyradm etc as deb.tony.
They auth OK to the system through Horde, which authenticates them to
LDAP and IMAP. Log entry showing the Horde server logging them in:
imap[28530]: login: emp06.simonandkate.lan [192.168.1.230] deb.tony
PLAIN+TLS User logged in SESSIONID=<emp07-28530-1501054728-1>
Then I get a log entry with them as deb^tony:
imap[28530]: USAGE deb^tony user: 0.006688 sys: 0.004995
But nslcd triggers errors every 10 to 15 minutes:
Jul 26 13:11:53 emp07 nslcd[922]: [c5eb19] <passwd="deb^tony"> request
denied by validnames option
Jul 26 13:11:53 emp07 nslcd[922]: [fb6a0e] <group/member="deb^tony">
request denied by validnames option
IMAP is the only thing I know on the system that uses "deb^tony", so I
was wondering why I'm getting the errors?
The user can logon ok (always through Horde's IMAP connection), use,
send emails ok...
I changed the validnames regex in nslcd to accept a ^ but I assume
that's just hiding the problem, not fixing it. There is nothing in my
LDAP logs that indicates any failure.
Any thoughts?
Simon
--
Simon Wilson
M: 0400 12 11 16
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
