migrating/cloning 2.2 > 2.3?
I have 2.2 installation on Centos 7, and, I'm trying to setup a new server, and, 'clone' existing setup: Dovecot/Postfix/Mysql
on new Centos 7 installed from RPM 2.3.4.1 (3c0b8769e)
I then copied/overwrote from old to new /etc/dovecot/*.conf (but not conf.d files), created self certs in place of old server certs
and, started Dovecot
is that totally dumb, and, how should I do this, or ?
upon starting dovecot and, trying to access mailbox from K9 client I see in the log [1]:
what's my best way forward with this ?
I also see this in postfix log:
Mar 3 03:15:02 geko postfix/pipe[28482]: 302494188091: to=<postmaster@sbt.net.au>, orig_to=<root>, relay=dovecot, delay=0.22, delays=0/0.01/0/0.21, dsn=2.0.0, status=sent (delivered via dovecot service (lda(postmaster@sbt.net.au,)Error: net_connect_unix(/var/run/dovecot/stats-writer) failed: Permission))
[1] Mar 03 11:29:42 master: Info: Dovecot v2.3.4.1 (3c0b8769e) starting up for pop3, imap, sieve (core dumps disabled) Mar 03 11:30:09 config: Warning: please set ssl_dh=</etc/dovecot/dh.pem Mar 03 11:30:09 config: Warning: You can generate it with: dd if=/var/lib/dovecot/ssl-parameters.dat bs=1 skip=88 | openssl dhparam -inform der > /etc/dovecot/dh.pem Mar 03 11:30:12 auth-worker(32307): Warning: sqlpool(mysql): Query failed, retrying: Unknown column 'mailbox.enableimaptls' in 'where clause' Mar 03 11:30:12 auth-worker(32307): Error: sql(voytek@sbt.net.au,110.175.246.167,<jZs3viWDz7xur/an>): User query failed: Unknown column 'mailbox.enableimaptls' in 'where clause' Mar 03 11:30:12 imap: Error: Internal auth failure (auth connected 0 msecs ago, handshake 0 msecs ago, request took 0 msecs, client-pid=32301 client-id=1) Mar 03 11:30:12 imap-login: Info: Internal login failure (pid=32301 id=1): user=<voytek@sbt.net.au>, method=PLAIN, rip=110.175.246.167, lip=103.106.168.106, mpid=32310, TLS, session=<jZs3viWDz7xur/an> Mar 03 11:30:12 auth-worker(32307): Warning: sqlpool(mysql): Query failed, retrying: Unknown column 'mailbox.enableimaptls' in 'where clause' Mar 03 11:30:12 auth-worker(32307): Error: sql(voytek@sbt.net.au,110.175.246.167,<xBk6viWDzrRur/an>): User query failed: Unknown column 'mailbox.enableimaptls' in 'where clause' Mar 03 11:30:12 imap: Error: Internal auth failure (auth connected 0 msecs ago, handshake 0 msecs ago, request took 0 msecs, client-pid=32304 client-id=1) Mar 03 11:30:12 imap-login: Info: Internal login failure (pid=32304 id=1): user=<voytek@sbt.net.au>, method=PLAIN, rip=110.175.246.167, lip=103.106.168.106, mpid=32311, TLS, session=<xBk6viWDzrRur/an>
-- Voytek
11:30:12 auth-worker(32307): Warning: sqlpool(mysql): Query failed, retrying: Unknown column 'mailbox.enableimaptls' in 'where clause' Mar 03 11:30:12 auth-worker(32307): Error: sql(voytek@sbt.net.au,110.175.246.167,<xBk6viWDzrRur/an>): User query failed: Unknown column 'mailbox.enableimaptls' in 'where clause'
I've found a page with SQL table mods that seems to have fixed some of my issues, after modifying SQL, I can log in
Mar 03 16:23:34 master: Info: Dovecot v2.3.4.1 (3c0b8769e) starting up for pop3, imap, sieve (core dumps disabled) Mar 03 16:23:56 config: Warning: please set ssl_dh=</etc/dovecot/dh.pem Mar 03 16:23:56 config: Warning: You can generate it with: dd if=/var/lib/doveco t/ssl-parameters.dat bs=1 skip=88 | openssl dhparam -inform der > /etc/dovecot/d h.pem Mar 03 16:23:57 imap-login: Info: Login: user=<voytek@sbt.net.au>, method=PLAIN, rip=110.175.246.167, lip=103.106.168.106, mpid=2757, TLS, session=<283B2CmDccdu r/an>
I'll do the dh.pem next
//these are SQL mods I've done
ALTER TABLE mailbox ADD COLUMN enableimaptls TINYINT(1) NOT NULL DEFAULT 1; ALTER TABLE mailbox ADD INDEX (enableimaptls); ALTER TABLE mailbox ADD COLUMN enablepop3tls TINYINT(1) NOT NULL DEFAULT 1; ALTER TABLE mailbox ADD INDEX (enablepop3tls); ALTER TABLE mailbox ADD COLUMN enablesievetls TINYINT(1) NOT NULL DEFAULT 1; ALTER TABLE mailbox ADD INDEX (enablesievetls);//
-- Voytek
On Sun, 3 Mar 2019 at 08:29, Voytek Eymont via dovecot <dovecot@dovecot.org> wrote:
11:30:12 auth-worker(32307): Warning: sqlpool(mysql): Query failed, retrying: Unknown column 'mailbox.enableimaptls' in 'where clause' Mar 03 11:30:12 auth-worker(32307): Error: sql(voytek@sbt.net.au,110.175.246.167,<xBk6viWDzrRur/an>): User query failed: Unknown column 'mailbox.enableimaptls' in 'where clause'
I've found a page with SQL table mods that seems to have fixed some of my issues, after modifying SQL, I can log in
Mar 03 16:23:34 master: Info: Dovecot v2.3.4.1 (3c0b8769e) starting up for pop3, imap, sieve (core dumps disabled) Mar 03 16:23:56 config: Warning: please set ssl_dh=</etc/dovecot/dh.pem Mar 03 16:23:56 config: Warning: You can generate it with: dd if=/var/lib/doveco t/ssl-parameters.dat bs=1 skip=88 | openssl dhparam -inform der > /etc/dovecot/d h.pem Mar 03 16:23:57 imap-login: Info: Login: user=<voytek@sbt.net.au>, method=PLAIN, rip=110.175.246.167, lip=103.106.168.106, mpid=2757, TLS, session=<283B2CmDccdu r/an>
I'll do the dh.pem next
//these are SQL mods I've done
ALTER TABLE mailbox ADD COLUMN enableimaptls TINYINT(1) NOT NULL DEFAULT 1; ALTER TABLE mailbox ADD INDEX (enableimaptls); ALTER TABLE mailbox ADD COLUMN enablepop3tls TINYINT(1) NOT NULL DEFAULT 1; ALTER TABLE mailbox ADD INDEX (enablepop3tls); ALTER TABLE mailbox ADD COLUMN enablesievetls TINYINT(1) NOT NULL DEFAULT 1; ALTER TABLE mailbox ADD INDEX (enablesievetls);//
-- Voytek
What you did is quite practical. All you have to do is: the one you refer to is the standard one for CentOS, every man to their own
- Make sure the static files named in the configs are moved to the destination server
- All account names used in Dovecot config are adjusted or created in the destination server and the permissions/access levels are right
- Dump mysql database and import the dump in the destination server I have done the same before, and just made sure that I went through all the files in /etc/dovecot/ with a toothcomb. I've missed one or two things depending on the level of distraction/concentration (which is normal), but it always ends up working, especially if the migration is about the same domain names. That is how it's supposed to work with virtual users I suppose. Regarding your MySQL issues, you'll notice that we all have different MySQL schemas out here, Unless
when it comes to virtual users :)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)
participants (2)
-
Odhiambo Washington
-
Voytek Eymont