doveadm backup 2.2.23 ignores -u, but reads USER environment?
Hi,
during a migration (cyrus -> dovecot) we ran into trouble¹ using 'doveadm
backup'
with 2.2.9. So I built 2.2.22 and 2.2.23, but they expose quite different
behaviour.
2.2.22 seems to work at least partially, but 2.2.23 complains about a
non existing user (root?).
The command I'm running is:
doveadm -o pop3_uidl_format=%v.%u \
-o imapc_master_user=cyrus -o imapc_password=* -o imapc_host=* \
-o mail_fsync=never \
-o imapc_ssl_verify=no -o imapc_ssl=imaps -o imapc_port=993 \
backup -f -u heiko -R imapc:
Using 2.2.9 or 2.2.22 it works, using 2.2.23 "-u …" is ignored and I've to pass
the user via the USER environment.
But according to the manpage of doveadm-sync
-u user/mask
Run the command only for the given user. It's also possible to use
'*' and '?' wildcards (e.g. -u *@example.org). When neither the -A
option, nor the -F file option, nor the -u user was specified, the
command will be executed with the environment of the currently
logged in user.
Interestingly enough -u 'heiko*' works fine, even with USER=root.
So the environment doesn't seem to override -u … always.
Maybe an important side note: the user 'heiko' doesn't exist as a local
system user, he is known via LDAP only.
And for e.g. 'doveadm quota -u heiko' it works as expected, even with
2.2.23.
¹) solved meanwhile by using -o mail_plugins=
as the quota plugin seems to crash 'doveadm backup'
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 -
signature.asc
Description: Digital signature
Re: Kernel panic in dovecot-ee-lmtp on Debian 8
Op 4/25/2016 om 8:28 PM schreef Michael Slusarz: > Fixed -- Publicly accessible link to commit: > > https://github.com/dovecot/pigeonhole/commit/a95b0579b89c13fb3ee5700e76cbe6a4a3e898e0 > Oh, oops. :) >> On April 25, 2016 at 10:46 AM Stephan Bosch wrote: >> >> >> >> >> Op 25-4-2016 om 18:01 schreef Timo Sirainen: >>> On 25 Apr 2016, at 13:48, Tobi wrote: Hi list I just realized that that I don not receive all mails in my mailbox (running dovecot-ee 2.2.23.1-1 on Debian 8). On my frontend servers (running postfix) the queue fills up with mails that cannot be delivered via lmtp to my backend servers. The error message on the frontend is "lost connection with backend while sending data" When I checked the logs on the backend server I found upon every delivery attempt kernel panics Apr 25 12:33:36 mbox1 dovecot: lmtp(REDACTED): Panic: epoll_ctl(del, 18) failed: Bad file descriptor Apr 25 12:33:36 mbox1 dovecot: lmtp(REDACTED): Error: Raw backtrace: >>> Can you get a core dump and gdb backtrace? See >>> http://dovecot.org/bugreport.html#coredumps >>> /usr/lib/dovecot/libdovecot-sieve.so.0(program_client_run+0xe8) [0x7faa17d3b308] -> /usr/lib/dovecot/modules/sieve/lib90_sieve_extprograms_plugin.so(+0x45b8) [0x7faa15d855b8] -> /usr/lib/dovecot/libdovecot-sieve.so.0(sieve_interpreter_continue+0x7c) [0x7faa17cfa2ac] -> the weird thing is that this is not concerning all incoming mails. From time to time the frontends can deliver messages to my backends. I just tested it with a mail from work. It arrived via a frontend that has other mails in queue that could not be delivered so far. Does anyone have an idea where I could look for the root cause of this panic messages? >>> Looks like somehow caused by sieve extprograms. >> Probably this bug: >> >> https://git.dovecot.net/pigeonhole/core/commit/a95b0579b89c13fb3ee5700e76cbe6a4a3e898e0 >> >> Fixed for upcoming release. >> >> Regards, >> >> Stephan.
Re: Kernel panic in dovecot-ee-lmtp on Debian 8
Fixed -- Publicly accessible link to commit: https://github.com/dovecot/pigeonhole/commit/a95b0579b89c13fb3ee5700e76cbe6a4a3e898e0 > On April 25, 2016 at 10:46 AM Stephan Bosch wrote: > > > > > Op 25-4-2016 om 18:01 schreef Timo Sirainen: > > On 25 Apr 2016, at 13:48, Tobi wrote: > >> Hi list > >> > >> I just realized that that I don not receive all mails in my mailbox > >> (running dovecot-ee 2.2.23.1-1 on Debian 8). On my frontend servers > >> (running postfix) the queue fills up with mails that cannot be delivered > >> via lmtp to my backend servers. The error message on the frontend is > >> "lost connection with backend while sending data" > >> When I checked the logs on the backend server I found upon every > >> delivery attempt kernel panics > >> > >> Apr 25 12:33:36 mbox1 dovecot: lmtp(REDACTED): Panic: epoll_ctl(del, 18) > >> failed: Bad file descriptor > >> Apr 25 12:33:36 mbox1 dovecot: lmtp(REDACTED): Error: Raw backtrace: > > Can you get a core dump and gdb backtrace? See > > http://dovecot.org/bugreport.html#coredumps > > > >> /usr/lib/dovecot/libdovecot-sieve.so.0(program_client_run+0xe8) > >> [0x7faa17d3b308] -> > >> /usr/lib/dovecot/modules/sieve/lib90_sieve_extprograms_plugin.so(+0x45b8) > >> [0x7faa15d855b8] > >> -> > >> /usr/lib/dovecot/libdovecot-sieve.so.0(sieve_interpreter_continue+0x7c) > >> [0x7faa17cfa2ac] -> > >> > >> the weird thing is that this is not concerning all incoming mails. From > >> time to time the frontends can deliver messages to my backends. I just > >> tested it with a mail from work. It arrived via a frontend that has > >> other mails in queue that could not be delivered so far. > >> > >> Does anyone have an idea where I could look for the root cause of this > >> panic messages? > > Looks like somehow caused by sieve extprograms. > > Probably this bug: > > https://git.dovecot.net/pigeonhole/core/commit/a95b0579b89c13fb3ee5700e76cbe6a4a3e898e0 > > Fixed for upcoming release. > > Regards, > > Stephan.
Re: Kernel panic in dovecot-ee-lmtp on Debian 8
Op 25-4-2016 om 18:01 schreef Timo Sirainen: On 25 Apr 2016, at 13:48, Tobi wrote: Hi list I just realized that that I don not receive all mails in my mailbox (running dovecot-ee 2.2.23.1-1 on Debian 8). On my frontend servers (running postfix) the queue fills up with mails that cannot be delivered via lmtp to my backend servers. The error message on the frontend is "lost connection with backend while sending data" When I checked the logs on the backend server I found upon every delivery attempt kernel panics Apr 25 12:33:36 mbox1 dovecot: lmtp(REDACTED): Panic: epoll_ctl(del, 18) failed: Bad file descriptor Apr 25 12:33:36 mbox1 dovecot: lmtp(REDACTED): Error: Raw backtrace: Can you get a core dump and gdb backtrace? See http://dovecot.org/bugreport.html#coredumps /usr/lib/dovecot/libdovecot-sieve.so.0(program_client_run+0xe8) [0x7faa17d3b308] -> /usr/lib/dovecot/modules/sieve/lib90_sieve_extprograms_plugin.so(+0x45b8) [0x7faa15d855b8] -> /usr/lib/dovecot/libdovecot-sieve.so.0(sieve_interpreter_continue+0x7c) [0x7faa17cfa2ac] -> the weird thing is that this is not concerning all incoming mails. From time to time the frontends can deliver messages to my backends. I just tested it with a mail from work. It arrived via a frontend that has other mails in queue that could not be delivered so far. Does anyone have an idea where I could look for the root cause of this panic messages? Looks like somehow caused by sieve extprograms. Probably this bug: https://git.dovecot.net/pigeonhole/core/commit/a95b0579b89c13fb3ee5700e76cbe6a4a3e898e0 Fixed for upcoming release. Regards, Stephan.
Re: Kernel panic in dovecot-ee-lmtp on Debian 8
On 25 Apr 2016, at 13:48, Tobi wrote: > > Hi list > > I just realized that that I don not receive all mails in my mailbox > (running dovecot-ee 2.2.23.1-1 on Debian 8). On my frontend servers > (running postfix) the queue fills up with mails that cannot be delivered > via lmtp to my backend servers. The error message on the frontend is > "lost connection with backend while sending data" > When I checked the logs on the backend server I found upon every > delivery attempt kernel panics > > Apr 25 12:33:36 mbox1 dovecot: lmtp(REDACTED): Panic: epoll_ctl(del, 18) > failed: Bad file descriptor > Apr 25 12:33:36 mbox1 dovecot: lmtp(REDACTED): Error: Raw backtrace: Can you get a core dump and gdb backtrace? See http://dovecot.org/bugreport.html#coredumps > /usr/lib/dovecot/libdovecot-sieve.so.0(program_client_run+0xe8) > [0x7faa17d3b308] -> > /usr/lib/dovecot/modules/sieve/lib90_sieve_extprograms_plugin.so(+0x45b8) > [0x7faa15d855b8] > -> > /usr/lib/dovecot/libdovecot-sieve.so.0(sieve_interpreter_continue+0x7c) > [0x7faa17cfa2ac] -> > > the weird thing is that this is not concerning all incoming mails. From > time to time the frontends can deliver messages to my backends. I just > tested it with a mail from work. It arrived via a frontend that has > other mails in queue that could not be delivered so far. > > Does anyone have an idea where I could look for the root cause of this > panic messages? Looks like somehow caused by sieve extprograms.
Re: IX Out of Order?
Oops. Turned off package composer for maintenance, but didn't turn it back on. It is building now. Op 25-4-2016 om 14:47 schreef Harald Leithner: Hi, It seams that ix.dovecot.fi has not build a new version since 2016-04-19 20:03 regards,
IX Out of Order?
Hi, It seams that ix.dovecot.fi has not build a new version since 2016-04-19 20:03 regards, -- Harald Leithner ITronic Wiedner Hauptstraße 120/5.1, 1050 Wien, Austria Tel: +43-1-545 0 604 Mobil: +43-699-123 78 4 78 Mail: leith...@itronic.at | itronic.at
Kernel panic in dovecot-ee-lmtp on Debian 8
Hi list I just realized that that I don not receive all mails in my mailbox (running dovecot-ee 2.2.23.1-1 on Debian 8). On my frontend servers (running postfix) the queue fills up with mails that cannot be delivered via lmtp to my backend servers. The error message on the frontend is "lost connection with backend while sending data" When I checked the logs on the backend server I found upon every delivery attempt kernel panics Apr 25 12:33:36 mbox1 dovecot: lmtp(REDACTED): Panic: epoll_ctl(del, 18) failed: Bad file descriptor Apr 25 12:33:36 mbox1 dovecot: lmtp(REDACTED): Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0x85dee) [0x7faa19225dee] -> /usr/lib/dovecot/libdovecot.so.0(+0x85edc) [0x7faa19225edc] -> /usr/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7faa191ca5be] -> /usr/lib/dovecot/libdovecot.so.0(+0x9afc1) [0x7faa1923afc1] -> /usr/lib/dovecot/libdovecot.so.0(+0x994af) [0x7faa192394af] -> /usr/lib/dovecot/libdovecot.so.0(+0xa5eda) [0x7faa19245eda] -> /usr/lib/dovecot/libdovecot.so.0(+0xa4566) [0x7faa19244566] -> /usr/lib/dovecot/libdovecot.so.0(o_stream_destroy+0xe) [0x7faa192446ee] -> /usr/lib/dovecot/libdovecot-sieve.so.0(+0x7e44b) [0x7faa17d3a44b] -> /usr/lib/dovecot/libdovecot-sieve.so.0(+0x7ea14) [0x7faa17d3aa14] -> /usr/lib/dovecot/libdovecot.so.0(+0xa6d88) [0x7faa19246d88] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x4c) [0x7faa19239c6c] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x101) [0x7faa1923b0d1] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x25) [0x7faa19239cf5] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x7faa19239e98] -> /usr/lib/dovecot/libdovecot-sieve.so.0(program_client_run+0xe8) [0x7faa17d3b308] -> /usr/lib/dovecot/modules/sieve/lib90_sieve_extprograms_plugin.so(+0x45b8) [0x7faa15d855b8] -> /usr/lib/dovecot/libdovecot-sieve.so.0(sieve_interpreter_continue+0x7c) [0x7faa17cfa2ac] -> /usr/lib/dovecot/libdovecot-sieve.so.0(sieve_interpreter_run+0x2b) [0x7faa17cfa4cb] -> /usr/lib/dovecot/libdovecot-sieve.so.0(+0x519e0) [0x7faa17d0d9e0] -> /usr/lib/dovecot/libdovecot-sieve.so.0(sieve_execute+0x47) [0x7faa17d0e567] -> /usr/lib/dovecot/modules/lib90_sieve_plugin.so(+0x3b6b) [0x7faa17f73b6b] -> /usr/lib/dovecot/libdovecot-lda.so.0(mail_deliver+0x49) [0x7faa197e5849] -> dovecot/lmtp() [0x4064b3] -> dovecot/lmtp() [0x406cb4] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x4c) [0x7faa19239c6c] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x101) [0x7faa1923b0d1] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x25) [0x7faa19239cf5] Apr 25 12:33:36 mbox1 dovecot: lmtp(REDACTED): Fatal: master: service(lmtp): child 32081 killed with signal 6 (core dumps disabled) the weird thing is that this is not concerning all incoming mails. From time to time the frontends can deliver messages to my backends. I just tested it with a mail from work. It arrived via a frontend that has other mails in queue that could not be delivered so far. Does anyone have an idea where I could look for the root cause of this panic messages? Thanks a lot tobi
Re: Setting up replication?
On 22/04/16 20:17, Knute Johnson wrote:
> On 4/21/2016 17:53, Edgar Pettijohn wrote:
>>
>> http://wiki.dovecot.org/MboxLocking
>
> Thanks Edgar, I hadn't seen that page before. I've tried every
> combination of locking but still get the same errors.
>
> I would love to see somebody's config files that has this working on a
> Ubuntu server.
>
> Thanks,
>
Hi Knute,
here are my dovecot config's. It seems to be somehow sometimes for me. I
am not expert of dovecot just started few weeks ago. I have been playing
around and I am not sure what makes mine to work.
I have 2 similar configured servers. Config's are not identical. I had
problem with notification "Error:
open(/var/run/dovecot/replication-notify-fifo) failed: Permission
denied." Still not working perfectly. Replication worked when I used
that users UID in "service aggregator" and "unix_listener
replication-notify." Then the other user was failing
I am using only imap part and haven't test other protocols if they work
or not. The other protocols like pop and sieve came by default. I didn't
bother to remove them.
#doveadm sync -A remote:u15dove2 command will sync things but I still
have some problems. Hopefully this might get you to correct track.
One more thing. I copied root's ssh keys as authorized_keys so I can ssh
-lroot other machine without password and visa verse.
So sorry no perfect solution yet avail
Linux u15dove1 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC
2015 x86_64 x86_64 x86_64 GNU/Linux
root@u15dove1:/etc/dovecot# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=15.10
DISTRIB_CODENAME=wily
DISTRIB_DESCRIPTION="Ubuntu 15.10"
u15dove1 doveconf:
root@u15dove1:/etc/dovecot# doveconf -n
# 2.2.18: /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.8 (0c4ae064f307+)
# OS: Linux 4.2.0-16-generic x86_64 Ubuntu 15.10
auth_mechanisms = plain login
dsync_remote_cmd = ssh -l%{login} %{host} doveadm dsync-server -u%u
first_valid_uid = 1000
last_valid_uid = 2000
mail_location = maildir:~/Maildir
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date index ihave duplicate
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
driver = pam
}
plugin {
mail_replica = remote:root@u15dove2
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
}
protocols = imap pop3 sieve
service aggregator {
fifo_listener replication-notify-fifo {
user = postfix
}
unix_listener replication-notify {
user = postfix
}
}
service auth {
unix_listener /var/spool/postfix/private/dovecot-auth {
group = postfix
mode = 0660
user = postfix
}
}
service replicator {
process_min_avail = 1
unix_listener replicator-doveadm {
mode = 0666
}
}
ssl_cert = was automatically rejected:%n%r
}
protocol imap {
imap_client_workarounds = delay-newmail
mail_max_userip_connections = 10
mail_plugins = " notify replication"
}
protocol pop3 {
mail_max_userip_connections = 10
pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
}
u15dove2 config:
root@u15dove2:/etc/dovecot# doveconf -n
# 2.2.18: /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.8 (0c4ae064f307+)
# OS: Linux 4.2.0-16-generic x86_64 Ubuntu 15.10
auth_mechanisms = plain login
dsync_remote_cmd = ssh -l%{login} %{host} doveadm dsync-server -u%u
first_valid_uid = 1000
last_valid_uid = 2000
mail_location = maildir:~/Maildir
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date index ihave duplicate
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
driver = pam
}
plugin {
mail_replica = remote:root@u15dove1
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
}
protocols = imap pop3 sieve
service aggregator {
fifo_listener replication-notify-fifo {
user = root
}
unix_listener replication-notify {
user = root
}
}
service auth {
unix_listener /var/spool/postfix/private/dovecot-auth {
group = postfix
mode = 0660
user = postfix
}
}
service replicator {
process_min_avail = 1
unix_listener replicator-doveadm {
mode = 0666
}
}
ssl_cert = was automatically rejected:%n%r
}
protocol imap {
imap_client_workarounds = delay-newmail
mail_m
Re: push-notification plugin and imap-metadata permissions
On 23.04.2016 10:01, giova...@giovannisfois.net wrote: > > > On 2016-04-22 09:07 PM, Timo Sirainen wrote: >> On 22 Apr 2016, at 15:17, Giovanni S. Fois >> wrote: >>> In order to tell if a mailbox is enabled to send out the notification, the >>> plugin >>> looks out for the following mailbox metadata key: >>> /private/vendor/vendor.dovecot/pvt/server/vendor/vendor.dovecot/http-notify >>> >>> If the key is set then everything is OK and the notification is sent, >>> otherwise the >>> action is skipped. >>> >>> If I try to setup the metadata key by hand (telnet as the user over the >>> imap port): >>> setmetadata INBOX >>> (/private/vendor/vendor.dovecot/pvt/server/vendor/vendor.dovecot/http-notify >>> "user=myu...@mydomain.com") >>> >>> I get the error message: "Internal mailbox attributes cannot be accessed" >> Server metadata is set with: >> >> a SETMETADATA "" (/private/vendor/vendor.dovecot/http-notify >> "user=myu...@mydomain.com") >> >> Which should internally map into the INBOX's >> /private/vendor/vendor.dovecot/pvt/server/vendor/vendor.dovecot/http-notify. >> > > I am sorry, but this is not working. > As you suggested I have launched the imap commands: > > a setmetadata "" (/private/vendor/vendor.dovecot/http-notify > "user=myu...@mydomain.com") > b getmetadata "" "/private/vendor/vendor.dovecot/http-notify" > c getmetadata "INBOX" > "/private/vendor/vendor.dovecot/pvt/server/vendor/vendor.dovecot/http-notify" > > the 'b' command returns a sort of json with the correct result > the 'c' command returns NIL After command "a", I think you should have gotten the push notification. The getmetadata imap command is not supposed to be able to access the path with /pvr/server/ in it. It is used for internal mapping only. Since command "b" returned the data, I would say the metadata is correctly set. br, Teemu Huovila > > By the way, hardcoding the key as > "/private/vendor/vendor.dovecot/http-notify" and recompiling the plugin > has the effect to bring the system on the expected course. > > Thank you again for your time and kind support. > > Have a good weekend, > Giovanni
Re: Moving to as new server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 24 Apr 2016, Jerry wrote: I will shortly have to replace the OS on my machine. For various reasons, I will not be able to use a program like “imapsync” to transfer my documents to a new server. All of the mail folders on my present PC are stored under “/var/mail/vmail”. If I copied all of the folders under “vmail” and moved them to the new PC, would Dovecot be able to access them normally? Dovecot would not be running while I moved the files. if the access permissions and Dovecot config keeps the same, there should be no problem. - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEVAwUBVx3HMHz1H7kL/d9rAQJzfwf+NHI7/dDP7PY5091RuihDW+fLj0by6gqk OfuG+N+DHBq3gmuuFKKWm0IsbAwHCjz+oOQQjNuYOXJqk0meLLXzlDbihlZlXMRk wmBa+Fm7Cseuo6Pp+ALYUAbZRoV4gprYfy99+H3cmA9ycjjgR8wO0K+rYS2nivGH fb3xF9YVl3hnZtLGTFzMgTFTmGQF0uPrWgylmLaAMY5XFUx9nt4DwTzrOvIRvfzl 5qAbJYNpDPQoFRUd7tqEyn+UpTIFFqbgPZbSNY/2SkTom5crzhhpDkx1kBxwYhnS ryEazZTO3c1YhgkAZH4Ab7kypAcXRbqWzU56DRvWwnLvpnAysyCaUQ== =Glxy -END PGP SIGNATURE-
