Facebook
Twitter
C
cuppett
Guest
There are a laundry list of things that haven't worked really well moving clients and domains. I thought I would post a list of the ones that have existed for some time as well as the new ones I found in 8.3.
My migration was from 8.3.0 to 8.3.0, CentOS 4.x -> CentOS 5.x
- MySQL tables lost the auto_increment attribute on the ids. A simple dump/restore of the original database on the original host cleared it up. Is that not what the migration thing does? *NEW*
- Permissions on /private of vhosts gets reset to default. So if you have g2data or something else in there as recommended, a quick chmod on the top will fix it. Existing.
- Mailman lists not moved correctly. A list of the same name gets created, and the users get added one by one and all of them get notifications (if they get added right). All settings are dropped. In addition, the archive doesn't move correctly in lots of cases, but some do. Existing. The workaround is to copy the /usr/lib/mailman/lists/<listname>/* files from the old host. In addition, if the archive gets dropped, copy all of /usr/lib/mailman/archives/private|public/<listname>[.mbox]. Once all the copying is done, if you just chown all the files to be owned by mailman, it will work fine.
- Multiple PostgreSQL databases for a domain is fickle. Maybe *NEW*. I had a situation where my first database got assigned the second user, but then the second database couldn't be added because it couldn't make the second user... it existed. The workaround is to get very familiar with postgresql and get your database dumps loaded, drop/create/assign the correct users and correct the problems in the PSA MySQL database. The tables of interest are accounts, db_users and data_bases.
- Everybody's Horde web-mail settings are lost. Signatures, contacts, PGP keys, etc. Existing. I've never had these migrate right. One time I restored the database for it, but I didn't this time around to post a workable solution.
My migration was from 8.3.0 to 8.3.0, CentOS 4.x -> CentOS 5.x
- MySQL tables lost the auto_increment attribute on the ids. A simple dump/restore of the original database on the original host cleared it up. Is that not what the migration thing does? *NEW*
- Permissions on /private of vhosts gets reset to default. So if you have g2data or something else in there as recommended, a quick chmod on the top will fix it. Existing.
- Mailman lists not moved correctly. A list of the same name gets created, and the users get added one by one and all of them get notifications (if they get added right). All settings are dropped. In addition, the archive doesn't move correctly in lots of cases, but some do. Existing. The workaround is to copy the /usr/lib/mailman/lists/<listname>/* files from the old host. In addition, if the archive gets dropped, copy all of /usr/lib/mailman/archives/private|public/<listname>[.mbox]. Once all the copying is done, if you just chown all the files to be owned by mailman, it will work fine.
- Multiple PostgreSQL databases for a domain is fickle. Maybe *NEW*. I had a situation where my first database got assigned the second user, but then the second database couldn't be added because it couldn't make the second user... it existed. The workaround is to get very familiar with postgresql and get your database dumps loaded, drop/create/assign the correct users and correct the problems in the PSA MySQL database. The tables of interest are accounts, db_users and data_bases.
- Everybody's Horde web-mail settings are lost. Signatures, contacts, PGP keys, etc. Existing. I've never had these migrate right. One time I restored the database for it, but I didn't this time around to post a workable solution.
