Re: [Dovecot] Dovecot Dsync
On 27/08/2013 09:54, Ben wrote: On 23/08/2013 13:08, Ed W wrote: Hi I'm on an Ubuntu LTS release so the dovecot came from their release. I'd prefer to stay that way unless I really have to... Everyone is entitled to their own opinions, but IMHO this kind of attitude is a huge detriment to most software projects. I see very little reason to take such policies personally... 1) I use virtualisation (especially lightweight virtualisation such as vservers) so that each service is in its own container. Now if I have no interest in some container and want to let it rot (ie as per LTS), then I can just do so. 2) I use a fast moving rolling distro (gentoo in my case, Arch is probably a good choice also) so that I have the option to stay up to date when I want to The end result is you can be as up to date as you want, or let things rot, as you please. Unfortunately if you want to use a very old bit of software, then you also get to keep all it's bugs... Sorry. Good luck! Hope this inspires you to try a different route! Ed W Whilst to some degree I appreciate where you're coming from and agree with you to a certain extent, I would caution that following the bleeding edge, always running the latest versions is not without risk or bugs either ! OK, but virtualisation also helps you mitigate this: - I setup my containers so that I have at least two mount points, one for the operating system and any data broken out into it's own mount. - This makes it quite simple to duplicate the container and spin up a test version pointing if required at the live data - Now you can run a test upgrade on the test container. If it works either swap them around or upgrade the original Additionally: - My choice of distro (gentoo) makes it fairly simple to build binary packages of the software I'm using. - I then use these binary packages on all my containers, additionally with guided profiles which control which packages and which options we deploy. - It's fairly simple to roll back most packages to the previous binary version if a problem is detected (logging of package changes is built-in) So it's quite low risk to use such a rolling distro in general. Note, I can't speak for other distros, but gentoo stable is fairly conservative and shouldn't be a problem for an experienced admin to keep up to date. It has the option to unmask bleeding edge packages where necessary and this can be useful to hit specific version numbers of software. It's also pretty trivial to keep a private repo of customised packages (ebuilds) with either personal patches or to pin certain versions of software. (So for example if you run, say, Dovecot with a few custom patches, then it's fairly trivial to drop these patches in a directory and now you can use the package manager to follow stable builds, but your custom patches will be rolled in for you with each update - can be very handy for some requirements) I don't have the same experience with RPM/DEB so I can't say that all the same is easy to do, but the key thing is the use of containers/virtualisation to assist with testing and upgrades. Even worst case you have to do a whole OS upgrade, at least if you can do that in a test container while the live remains running, is a big advantage Good luck Ed W
Re: [Dovecot] Dovecot Dsync
Hi I'm on an Ubuntu LTS release so the dovecot came from their release. I'd prefer to stay that way unless I really have to... Everyone is entitled to their own opinions, but IMHO this kind of attitude is a huge detriment to most software projects. I see very little reason to take such policies personally... 1) I use virtualisation (especially lightweight virtualisation such as vservers) so that each service is in its own container. Now if I have no interest in some container and want to let it rot (ie as per LTS), then I can just do so. 2) I use a fast moving rolling distro (gentoo in my case, Arch is probably a good choice also) so that I have the option to stay up to date when I want to The end result is you can be as up to date as you want, or let things rot, as you please. Unfortunately if you want to use a very old bit of software, then you also get to keep all it's bugs... Sorry. Good luck! Hope this inspires you to try a different route! Ed W
Re: [Dovecot] Dovecot Dsync
On 08/20/2013 11:57 AM, Ben wrote:
Hi,
Sorry to bump it, but I've yet to receive even one reply to my
question the other day about Dsync ? Everyone else seems to have been
receiving replies to their questions and so I'm feeling a little
lonely out in the cold.
I can't believe nobody on-list uses Dsync ?
Ben
Maybe everyone is waiting for someone smarter than themselves to answer
this.. :-)
So.. hoping I read and understood your email correctly ...
The first thing you tried failed because only root can change
permissions, except for using the setuid bit which is probably not what
you want here.
The second might have failed because of:
userdb {
args = username_format=%u /etc/dovecot/users
driver = passwd-file
}
dsync is using userdb and not authdb because it's not checking a
password here. Can it be that its-virtmail doesn't have permission to
read /etc/dovecot/users ?
Re: [Dovecot] Dovecot Dsync
Am 20.08.2013 17:57, schrieb Ben: Hi, Sorry to bump it, but I've yet to receive even one reply to my question the other day about Dsync ? Everyone else seems to have been receiving replies to their questions and so I'm feeling a little lonely out in the cold. I can't believe nobody on-list uses Dsync ? Ben perhaps many people are on holidays in summer, however seems in your orig post you used 2.0.19 version there were a lot of updates perhaps first update 2.1.17 or 2.2.5 then retry also seems you have some permission problems failed: Permission denied (euid=1002(its_scripts) egid=1002(its_scripts) missing +r perm: /var/run/dovecot/auth-userdb, dir owned by 0:0 mode=0755) Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] Dovecot Dsync
On 08/20/2013 12:16 PM, Gedalya wrote: only root can change permissions, Sorry I meant only root can change his own userid :-)
Re: [Dovecot] Dovecot Dsync
Maybe everyone is waiting for someone smarter than themselves to answer
this.. :-)
Maybe... but at the same time, there's a risk of me abandoning Dsync for
rsync or something else that I know I could have implemented by now with
far less frustration ! However I'm keen to learn how to utilise the
power within Dsync ;-)
So.. hoping I read and understood your email correctly ...
Hoping that email wasn't too confusing ;-(
The first thing you tried failed because only root can change
permissions, except for using the setuid bit which is probably not what
you want here.
The second might have failed because of:
userdb {
args = username_format=%u /etc/dovecot/users
driver = passwd-file
}
dsync is using userdb and not authdb because it's not checking a
password here. Can it be that its-virtmail doesn't have permission to
read /etc/dovecot/users ?
hmmm ... its chmod 640 root:dovecot on the primary server and the same
on the backup box. Do I need to mess around with permissions on both or
just the backup box ?
I was under the impression that Dsync was just a more modern version of
a doveadm tool that went by a similar name and hence assumed it would
use dovecot permissions.
But then again, who knows... I was getting very confused at the end of a
long day trying to make it work !
Re: [Dovecot] Dovecot Dsync
perhaps many people are on holidays in summer, however seems in your orig post you used 2.0.19 version there were a lot of updates perhaps first update 2.1.17 or 2.2.5 then retry True true... although from my point of view its hard not to be tempted to use rsync or something else that I know. But as I said to a previous respondent, I'm keen to get to know (and hopefully love) my new dovecot install ! I'm on an Ubuntu LTS release so the dovecot came from their release. I'd prefer to stay that way unless I really have to...especially if the only reason for doing so is to fix Dsync. 2.0.19 seems to otherwise working ok ! Maybe I'll have a look through the release notes on a rainy day ! also seems you have some permission problems failed: Permission denied (euid=1002(its_scripts) egid=1002(its_scripts) missing +r perm: /var/run/dovecot/auth-userdb, dir owned by 0:0 mode=0755) Hmmm... I think I tried that at some point, I think that was when the problem might have morphed into ... dsync(its-virtmail): Error: user t...@somewhere.example.com: Initialization failed: mail_location not set and autodetection failed: Mail storage autodetection failed with home=/srv/mail/example.com/test dsync(its-virtmail): Fatal: User init failed dsync-local(t...@somewhere.example.com): Error: read() from worker server failed: EOF But I'll give it another go tomorrow.
Re: [Dovecot] Dovecot dsync mail replication issues
Hello Reuben, I'm having a very similar setup. The 2 main differences: all my users are virtual and the 2nd server is on a different continent (high latency sync). Unfortunately the dsync is not working for the moment. Timo is in the process of redesigning it. So once it is release will know about it. drwx-- 5 lyn lyn 4096 Apr 30 19:32 .INBOX_7a86a62d465a974fb92f3b258734 First question: why is this random named directory being created in the origin Maildir? Shouldn't the replication be more or less read-only in the origin Maildir? - the number it is not random, but rather it is the GUID of the folder on the other server. To get rid of this annoying problem you need to clean your source of all these newly created folders, rsync your folders in between the 2 machines, run dsync again (this time it will not mess up with your folder structure) Second question: If I re-attempt a doveadm sync a second time I get this error: tornado Maildir # doveadm sync -u lyn remote:r...@dustbowl.reub.net dsync-local(lyn): Error: Can't rename mailbox INBOX_7a86a62d465a974fb92f3b258734 to INBOX: Target mailbox already exists dsync-local(lyn): Error: Can't rename mailbox INBOX to INBOX_eb15f30ea563be4b70322bd68bb1: Renaming INBOX isn't supported. tornado Maildir # It's not clear if the second attempt has failed or succeeded, and it's a bit odd that it errors out on a directory that the dovecot sync process itself has created. do the fix at Q1 and you will not run into this... it is not a permission problem but rather a meta-info problem. The setup will run fine as long as you only update 1 server and the other one is backup. The current release does not handle well the master-master model (you'll endup with emails like the folders above: duplicated, with GUID appended to them etc etc)... Wish Timo good luck and inspiration! Best regards, Andrei
Re: [Dovecot] Dovecot dsync mail replication issues
On Mon, 2012-04-30 at 12:25 -0400, Michescu Andrei wrote: tornado Maildir # doveadm sync -u lyn remote:r...@dustbowl.reub.net dsync-local(lyn): Error: Can't rename mailbox INBOX_7a86a62d465a974fb92f3b258734 to INBOX: Target mailbox already exists The setup will run fine as long as you only update 1 server and the other one is backup. The current release does not handle well the master-master model (you'll endup with emails like the folders above: duplicated, with GUID appended to them etc etc)... It does work, as long as you get the initial configuration to work properly without adding the _GUIDs. The _GUIDs shouldn't be added if you do the initial replication to the other side (to nonexistent Maildir!) via dsync. I guess some plugins might also break this. Unfortunately the dsync is not working for the moment. Timo is in the process of redesigning it. So once it is release will know about it. But yeah, the redesign is supposed to make all of this a lot easier and more reliable. :) The new code can almost do the basics now, but still needs some time.. I'm giving a talk about it in 3 weeks though, so I'm planning on it being at least somewhat usable by then. :)
