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:
- 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 the one you refer to is the standard one for CentOS, every man to their own 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