dovecot - Aug 2013 - Dovecot Dsync

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

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 ?

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

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