doveadm-server protocol change?
Hi,
I'm doing quota checks from a remote machine (the real setup is a bit more complex, if necessary I can explain it in more detail, but I just extracted the bits that are easily reproduceable)
# nc backend1 24245
VERSION doveadm-server 1 0
PLAIN agrVMDvHgz0ya2HHzax5svwB2ZHS¹
+
heiko quota getBut since the backend is upgraded to 2.2.22 it's not possible anymore. The exuse in the log of the backend is:
dovecot: doveadm(149.1.1.1¹): Fatal: USER environment is missing and -u option not usedRunning the doveadm quota get -u heiko locally on the backend works as
expected. But using the the doveadm-server it doesn't.
# 2.2.22 (fe789d2): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.13 (7b14904) # OS: Linux 4.4.0-22-generic x86_64 Ubuntu 16.04 LTS … auth_cache_negative_ttl = 0 auth_cache_ttl = 0 auth_master_user_separator = * base_dir = /run/dovecot/ imap_metadata = yes lda_mailbox_autocreate = yes lda_mailbox_autosubscribe = yes login_log_format_elements = user=<%u> method=%m rip=%r lip=%l mpid=%e %c %k mail_attribute_dict = file:%h/dovecot-attributes mail_location = maildir:~:INBOX=/volumes/dovecot/inbox/%2.256Nn/%n:INDEX=/volumes/dovecot/cache/%2.256Nn/%n mail_plugins = quota mbox_md5 = all mmap_disable = yes namespace inbox { … passdb { args = /etc/dovecot/master-users driver = passwd-file master = yes } passdb { args = /etc/dovecot/dovecot-ldap.passdb.conf.ext driver = ldap } plugin { quota = maildir:User quota quota_grace = 10%% sieve = /volumes/dovecot/sieve/%2.256Nn/%n/.dovecot.sieve sieve_dir = /volumes/dovecot/sieve/%2.256Nn/%n } pop3_uidl_format = %v.%u protocols = " imap lmtp pop3" service auth { extra_groups = ssl-cert } service doveadm { inet_listener { port = 24245 } } service lmtp { inet_listener lmtp { port = 2525 } } ssl = required ssl_cert =
¹) It's changed :)
On May 30, 2016 at 6:17 PM Heiko Schlittermann hs@schlittermann.de wrote:
Hi,
I'm doing quota checks from a remote machine (the real setup is a bit more complex, if necessary I can explain it in more detail, but I just extracted the bits that are easily reproduceable)
# nc backend1 24245 VERSION doveadm-server 1 0 PLAIN agrVMDvHgz0ya2HHzax5svwB2ZHS¹ + heiko quota getBut since the backend is upgraded to 2.2.22 it's not possible anymore. The exuse in the log of the backend is:
dovecot: doveadm(149.1.1.1¹): Fatal: USER environment is missing and -u option not usedRunning the
doveadm quota get -u heikolocally on the backend works as expected. But using the the doveadm-server it doesn't.# 2.2.22 (fe789d2)
Hi! This has been fixed in 2.2.24. There was a bug in user passing. We also invite you to have a go at our HTTP based interface, see http://wiki.dovecot.org/Design/DoveadmProtocol/HTTP
Aki Tuomi
Hi Aki,
thank your for responding that fast.
aki.tuomi@dovecot.fi aki.tuomi@dovecot.fi (Mo 30 Mai 2016 17:49:53 CEST): …
Hi! This has been fixed in 2.2.24. There was a bug in user passing.
Ok, thus at least your answer saves me hours of debugging. We upgraded old Ubuntu Boxes (14.04/LTS) to 16.04 to get around some Dovecot limitations/problems. And now we got new ones :(
We did the upgrade to avoid self-built binaries and use the distro packages. Probably we're out of luck.
We also invite you to have a go at our HTTP based interface, see http://wiki.dovecot.org/Design/DoveadmProtocol/HTTP
Does the 2.2.22 HTTP API suffer from the same bug with user passing? Is the HTTP API useable in a Director/Backend configuration?
Our setup is about
[ mx ] ---> dovecot-protocol ---> [ director ] ----> [ backend ]
`---> [ backend ]
`-> [ backend ]The bug w/ user passing is in the backend? Or already in the directors?
Heiko
On May 30, 2016 at 9:54 PM Heiko Schlittermann hs@schlittermann.de wrote:
Hi Aki,
thank your for responding that fast.
aki.tuomi@dovecot.fi aki.tuomi@dovecot.fi (Mo 30 Mai 2016 17:49:53 CEST): …
Hi! This has been fixed in 2.2.24. There was a bug in user passing.
Ok, thus at least your answer saves me hours of debugging. We upgraded old Ubuntu Boxes (14.04/LTS) to 16.04 to get around some Dovecot limitations/problems. And now we got new ones :(
We did the upgrade to avoid self-built binaries and use the distro packages. Probably we're out of luck.
We also invite you to have a go at our HTTP based interface, see http://wiki.dovecot.org/Design/DoveadmProtocol/HTTP
Does the 2.2.22 HTTP API suffer from the same bug with user passing? Is the HTTP API useable in a Director/Backend configuration?
Our setup is about
[ mx ] ---> dovecot-protocol ---> [ director ] ----> [ backend ] `---> [ backend ] `-> [ backend ]The bug w/ user passing is in the backend? Or already in the directors?
Heiko
Hi!
You can get packages from http://xi.dovecot.fi/debian/, if it helps. The HTTP API should not suffer from the username problem.
Aki
Hi Aki,
aki.tuomi@dovecot.fi aki.tuomi@dovecot.fi (Mo 30 Mai 2016 20:57:58 CEST): …
You can get packages from http://xi.dovecot.fi/debian/, if it helps. The HTTP API should not suffer from the username problem.
Thank you. I just used ppa:patrickdk/production, but probably will try the xi.dovecot.fi packages.
With 2.2.24 it works as expected. Due to the project state I'll not try the HTTP API right now (as the MTA (Exim) already speaks successful with the directors (via a Perl extension in Exim).
Again, thank you for your instant help.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
Heiko Schlittermann hs@schlittermann.de (Mo 30 Mai 2016 21:18:09 CEST):
Hi Aki,
aki.tuomi@dovecot.fi aki.tuomi@dovecot.fi (Mo 30 Mai 2016 20:57:58 CEST): …
You can get packages from http://xi.dovecot.fi/debian/, if it helps. The HTTP API should not suffer from the username problem.
Thank you. I just used ppa:patrickdk/production, but probably will try the xi.dovecot.fi packages.
The question is, which of these locations is more trustworthy in the sense of 'production ready'?
-- Heiko
On May 30, 2016 at 10:26 PM Heiko Schlittermann hs@schlittermann.de wrote:
Heiko Schlittermann hs@schlittermann.de (Mo 30 Mai 2016 21:18:09 CEST):
Hi Aki,
aki.tuomi@dovecot.fi aki.tuomi@dovecot.fi (Mo 30 Mai 2016 20:57:58 CEST): …
You can get packages from http://xi.dovecot.fi/debian/, if it helps. The HTTP API should not suffer from the username problem.
Thank you. I just used ppa:patrickdk/production, but probably will try the xi.dovecot.fi packages.
The question is, which of these locations is more trustworthy in the sense of 'production ready'?
-- Heiko
I'd consider xi.dovecot.fi more reliable myself.
AKi
…
You can get packages from http://xi.dovecot.fi/debian/, if it helps. The HTTP API should not suffer from the username problem.
Thank you. I just used ppa:patrickdk/production, but probably will try the xi.dovecot.fi packages.
The question is, which of these locations is more trustworthy in the sense of 'production ready'?
Heiko
I'd consider xi.dovecot.fi more reliable myself.
AKi
Not having installed any of the two, I can say, as a Ubuntu user:
In ppa "/etc/init.d/dovecot" is a symlink to "/lib/init/upstart-job"
While xi packages places its own init script there.
Curiously, dpkg on installation seems not to unlink the existing one first, but overwrite it with the new contents, thereby destroying upstart -- This happened to me last year, I noticed early :)
Last checked in 2.2.22 xi package as seen from the contents, did that change?
Possible workaround: remove the stock init file link ahead of installation?
-- peter
Hi,
Peter Chiochetti pch@myzel.net (Di 31 Mai 2016 10:31:50 CEST):
Not having installed any of the two, I can say, as a Ubuntu user: In ppa "/etc/init.d/dovecot" is a symlink to "/lib/init/upstart-job"
The 2.2.24 on 16.04 installs both
/etc/init.d/dovecot
/lib/systemd/system/dovecot.serviceWhile xi packages places its own init script there.
The xi packages I didn't check yet.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
Those are my packages. I try to track each release, and bug fixed.
But since those are mine, I'm really concerned with stability as it
affects my enviroment. Mainly mdbox/maildir with gzip, at this present
time.
If someone lets me know of any issues, I will fix and adjust for it,
but I'm not doing full scale stability testing. It's just the straight
ubuntu package, with it swapped out for 2.2.24+fixes, and other
adjustments as needed.
I do consider them stable enough for other people to use, but again,
your at my mercy. (But these are what I use on my production systems so)
As far as the init scripts goes, it's the same as what the dovecot
packages as shipped by ubuntu for 16.04 does it. I have not looked
into it much myself yet, other than it functions. I only have one
16.04 dovecot system currently.
Quoting Heiko Schlittermann hs@schlittermann.de:
Hi,
Peter Chiochetti pch@myzel.net (Di 31 Mai 2016 10:31:50 CEST):
Not having installed any of the two, I can say, as a Ubuntu user: In ppa "/etc/init.d/dovecot" is a symlink to "/lib/init/upstart-job"
The 2.2.24 on 16.04 installs both
/etc/init.d/dovecot /lib/systemd/system/dovecot.serviceWhile xi packages places its own init script there.
The xi packages I didn't check yet.
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
Hi Patrick,
Patrick Domack patrickdk@patrickdk.com (Mi 01 Jun 2016 02:22:17 CEST):
Those are my packages. I try to track each release, and bug fixed. … I do consider them stable enough for other people to use, but again, your at my mercy. (But these are what I use on my production systems so)
Thank you for your response, we're using your packages now in a production ready environment I'll contact you in case of any issues.
(The environment uses a directors/backends setup.)
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
Op 30-5-2016 om 22:06 schreef aki.tuomi@dovecot.fi:
On May 30, 2016 at 10:26 PM Heiko Schlittermann hs@schlittermann.de wrote:
Heiko Schlittermann hs@schlittermann.de (Mo 30 Mai 2016 21:18:09 CEST):
Hi Aki,
You can get packages from http://xi.dovecot.fi/debian/, if it helps. The HTTP API should not suffer from the username problem. Thank you. I just used ppa:patrickdk/production, but probably will try
aki.tuomi@dovecot.fi aki.tuomi@dovecot.fi (Mo 30 Mai 2016 20:57:58 CEST): … the xi.dovecot.fi packages. The question is, which of these locations is more trustworthy in the sense of 'production ready'?
-- Heiko I'd consider xi.dovecot.fi more reliable myself.
The wiki should be pretty clear about this. Using Xi packages for production systems is a very bad idea, unless perhaps you carefully review and test it on another system before every update.
If the developers commit a horrible bug to the repositories, you're likely going to be one of the first to notice. Keep that in mind!
Regards,
Stephan.
Hi Stephan,
Stephan Bosch stephan@rename-it.nl (Mi 01 Jun 2016 13:02:24 CEST): … Thanks for the hint:
The wiki should be pretty clear about this. Using Xi packages for production systems is a very bad idea, unless perhaps you carefully review and test it on another system before every update.
I'm using the ppa http://ppa.launchpad.net/patrickdk/production/ubuntu and until now it works fine.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
On May 30, 2016 at 6:17 PM Heiko Schlittermann hs@schlittermann.de wrote:
Hi,
I'm doing quota checks from a remote machine (the real setup is a bit more complex, if necessary I can explain it in more detail, but I just extracted the bits that are easily reproduceable)
# nc backend1 24245 VERSION doveadm-server 1 0 PLAIN agrVMDvHgz0ya2HHzax5svwB2ZHS¹ + heiko quota getBut since the backend is upgraded to 2.2.22 it's not possible anymore. The exuse in the log of the backend is:
dovecot: doveadm(149.1.1.1¹): Fatal: USER environment is missing and -u option not usedRunning the
doveadm quota get -u heikolocally on the backend works as expected. But using the the doveadm-server it doesn't.# 2.2.22 (fe789d2)
Hi! This has been fixed in 2.2.24. There was a bug in user passing. We also invite you to have a go at our HTTP based interface, see http://wiki.dovecot.org/Design/DoveadmProtocol/HTTP
Aki Tuomi
participants (5)
-
aki.tuomi＠dovecot.fi
-
Heiko Schlittermann
-
Patrick Domack
-
Peter Chiochetti
-
Stephan Bosch