2.2.14rc1 - dsync in backup mode still changes source permissions
Hi,
It seems we are still able to reproduce this: http://www.dovecot.org/list/dovecot/2014-May/096367.html
However... there's no longer any error-messages. It just silently changes permissions on some dovecot files in the source maildir. (most often dovecot-uidlist)
We're running dsync as root, with hardwired userdb values for other reasons. So it has the OS permissions to change source. But still, running in "backup" shouldn't change source ever, should it?
The command line is of this format - running on destination-host:
# dsync -R -o mail_home=/users/user/maildir backup ssh -c arcfour -o StrictHostKeyChecking=no -i /root/.ssh/id-rsa-dsync source-host "dsync -o mail_home=/users/user/maildir"
/Peter
On 10 Oct 2014, at 11:05, Peter Mogensen apm@one.com wrote:
It seems we are still able to reproduce this: http://www.dovecot.org/list/dovecot/2014-May/096367.html
However... there's no longer any error-messages. It just silently changes permissions on some dovecot files in the source maildir. (most often dovecot-uidlist)
We're running dsync as root, with hardwired userdb values for other reasons. So it has the OS permissions to change source. But still, running in "backup" shouldn't change source ever, should it?
It's not doing any changes to mailbox contents, but it's still updating the index/uidlist files as part of its normal operation.
The command line is of this format - running on destination-host:
# dsync -R -o mail_home=/users/user/maildir backup ssh -c arcfour -o StrictHostKeyChecking=no -i /root/.ssh/id-rsa-dsync source-host "dsync -o mail_home=/users/user/maildir"
You should use -u user@domain parameter in both sides so it drops root privileges.
On 11 Oct 2014, at 00:52, Timo Sirainen tss@iki.fi wrote:
On 10 Oct 2014, at 11:05, Peter Mogensen apm@one.com wrote:
It seems we are still able to reproduce this: http://www.dovecot.org/list/dovecot/2014-May/096367.html
However... there's no longer any error-messages. It just silently changes permissions on some dovecot files in the source maildir. (most often dovecot-uidlist)
We're running dsync as root, with hardwired userdb values for other reasons. So it has the OS permissions to change source. But still, running in "backup" shouldn't change source ever, should it?
It's not doing any changes to mailbox contents, but it's still updating the index/uidlist files as part of its normal operation.
The command line is of this format - running on destination-host:
# dsync -R -o mail_home=/users/user/maildir backup ssh -c arcfour -o StrictHostKeyChecking=no -i /root/.ssh/id-rsa-dsync source-host "dsync -o mail_home=/users/user/maildir"
You should use -u user@domain parameter in both sides so it drops root privileges.
Oh, and reading the linked mail more closely, if the maildir S=sizes have problems then Dovecot attempts to fix them. It's the same as if you attempted to read the mails via any method. doveadm backup doesn't attempt to read the whole source maildir without any modifications, although it could, but that could cause performance problems.
Anyway, if you have broken S=sizes, you could try setting maildir_broken_filename_sizes=yes.
On 2014-10-10 23:52, Timo Sirainen wrote:
It's not doing any changes to mailbox contents, but it's still updating the index/uidlist files as part of its normal operation.
I doesn't actually seem to change content of the files. Only permissoins. But given that the docs says (or rather "said") explicitly:
"No changes are ever done to the source location."
I would expect operations on the "source" to be strictly read only - including permissions.
Is the documentation intentionally changed to not make that promise anymore?
# dsync -R -o mail_home=/users/user/maildir backup ssh -c arcfour -o StrictHostKeyChecking=no -i /root/.ssh/id-rsa-dsync source-host "dsync -o mail_home=/users/user/maildir"
You should use -u user@domain parameter in both sides so it drops root privileges.
Yes... but the problem here is that the current userdb has accounts which can be activated/de-activated and de-activating an account makes the userdb act as it doesn't exist. ... which makes dsync skip it.
I realize that's a broken userdb, but the possible work-around was to not do userdb lookups with dsync.
/Peter
On 2014-10-11 08:51, Peter Mogensen wrote:
....the docs says (or rather "said") explicitly:
"No changes are ever done to the source location." ...
Is the documentation intentionally changed to not make that promise anymore?
I also notice that the "-o" for overriding userdb settings has been removed from the documentation.
Is that intentionally?
/Peter
participants (2)
-
Peter Mogensen
-
Timo Sirainen