Re: Conversion/Migration
On Tue, 28 Jan 2003, John A. Tamplin wrote: Rob Siemborski wrote: This really shouldn't be necessary. admins can authorize as any user (e.g. login as user cyrus with the password for them, but get rights as rjs3). Most SASL mechanisms allow this, though the regular imap LOGIN command does not. As far as I know, UW imap-utils mbxcvt can only do login (with or without TLS, so perhaps you could do client certificates and external authentication to get around it). For my purposes, it was easier just to hack saslauthd temporarily. UW imap-utils will do plain, cram-md5, login and gss. Actually, all the utils are now combined into one utility (mailutil). I modified mailutil to do proxy login (as described by Rob above) so that I can run conversion/migration while the new server is accepting new mail. -- Igor
Re: Conversion/Migration
Peter Lawler wrote: OK, thanks to those who replied. I've gone this far: http://batleth.sapienti-sat.org/projects/mb2md/ It's a pretty neato script, although I haven't tested the version released yesterday. It converts just as we want. Now, the trick after the conversion that the new files are in, say ~/Maildir/new/, so that they need to get moved into the cyrus store for the user. That's no problem. However I've got stuck at the next bit. OK, I can work out that the messages in the INBOX are individually numbered (eg, 52., 53., 54.). So, the converted mail files need to be renamed, one would guess. Can someone suggest the best method for renaming these files? Is the order of numbering of the files important (eg, datestamping), or is it irrelevant. Next thing is that only occasionally have I been able to rebuild the cyrus DB to have these converted messages appear in the INBOX. It was late last night, so I can't recall ALL the details. However, I do suspect that it *MAY* have something to do with the naming of the files mentioned above. Additionally, it *COULD* have something to do with the cyrus commands I'm issuing to try and rebuild the cyrus DB. Thirdly, when (on only two occasions, mind you) the converted messages did pop up, they are being displayed as 'read'. How can I set their status to 'unread'. I did suspect that *MAYBE* the fullstop (period) at the end of the filename might be the clue, but since I didn't manage to get the messages appearing again, I could work it out. Any comments, suggestions, flames, greatly appreciated. I think you would be much better off going through IMAP rather than trying to put the files in there correctly and then reconstructing it. You won't be able to maintain seen state (or any other flags for that matter) unless you build all the cyrus files correctly during the conversion. If you use mbxcvt from UW imap-utils, it will preserve the flags as part of the transfer. The only catch is you will have to be able to authenticate as the user when you convert. What I did was a temporary hack to saslauthd which allowed a backdoor password to work for all accounts and hacked mbxcvt to accept the password on the command line (no user accounts on this machine to watch ps). A wrapper script went through all the accounts to transfer (one by one) and updated the database used by perdition (imap/pop proxy) to show the account was being used and killed all active sessions. It then converted each mailbox using the hacked mbxcvt, connected as the admin account to set the quota, and connected as the user to set the subscription list. When the account was moved, update the perdition database so new connections go to the new server (and LMTP deliveries via proxy) and go to the next one. If you don't need to do the transfer while everything is up, obviously you don't have to fool with the database for the proxies. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: Conversion/Migration
On Tue, 28 Jan 2003, John Alton Tamplin wrote: able to authenticate as the user when you convert. What I did was a temporary hack to saslauthd which allowed a backdoor password to work for all accounts and hacked mbxcvt to accept the password on the command line (no user accounts on this machine to watch ps). A wrapper script This really shouldn't be necessary. admins can authorize as any user (e.g. login as user cyrus with the password for them, but get rights as rjs3). Most SASL mechanisms allow this, though the regular imap LOGIN command does not. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Conversion/Migration
Rob Siemborski wrote: This really shouldn't be necessary. admins can authorize as any user (e.g. login as user cyrus with the password for them, but get rights as rjs3). Most SASL mechanisms allow this, though the regular imap LOGIN command does not. As far as I know, UW imap-utils mbxcvt can only do login (with or without TLS, so perhaps you could do client certificates and external authentication to get around it). For my purposes, it was easier just to hack saslauthd temporarily. -- John A. Tamplin Unix Systems Administrator
Conversion/Migration
Hi! I am aware this question has been asked several times before, so please go easy on me. I'm wishing to move people off BSD popper over to a Cyrus system I've set up. Unfortunately, being school holidays, they've gone and got their current mailboxes jammed with stuff that is (no doubt) so damned important I'd be hung, drawn and quartered if the little blighters lost it. I've done some digging in the archives, and it seems the 'best' way recommended to do this is with the UOW mailutil program. I've run what I seem to think the command required is, but I get : Read-only POP3 access not available I was trying to 'copy' as a test, as I don't want to go destroying data untul such time as I'm confident I've got it right. Now, there's a couple of points I wish to ask. 1. I *assume* that this is POPPER throwing this error. So, one quiet night if I cut over to CYRUS, disable external access to the POP server, then enable read only access it'll convert files. If so, what's the easiest way to do this inside cyrus's config file? 2. Does this work 'globally', or will each user need to have it run in their account? From what I can make out of the source, I could set up the POP daemon read only, then feed it user names (ie, not prompting for passwords), and 'do it' that way, then mailutil will (hopefully :-) pass the user back into Cyrus IMAP. 3. Point 2 brings up the matter creating the User's INBOX folder and feeding the mail in as appropriate. I'd assume that this feeding into IMAP would need to be done as the cyrus admin user (for permission reasons). Therefore, step 2 would also need to be done as the cyrus admin. Therefore, is it possible to set up Cyrus POP to be read only if the cyrus admin user connects (no, I don't intend to leave this feature enabled). Any thoughts appreciated. Cheers, Pete.
