Migrate users

[Paul van der Vlis]

Op 26-07-17 om 12:34 schreef Simon Wilson:
> 
> 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?

So far I know is nslcd something from Samba:
https://wiki.samba.org/index.php/Nslcd

With regards,
Paul van der Vlis


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/