Re: [Dovecot] doveadm + dsync merging

2012-01-06 Thread Timo Sirainen
On Thu, 2011-12-29 at 15:19 +0100, Pascal Volk wrote:
> >> b) Don't have the dsync prefix:
> >>
> >> dsync mirror -> doveadm mirror
> >> dsync backup -> doveadm backup
> >> dsync server -> doveadm dsync-server (could be hidden from the doveadm 
> >> commands list)

I did this now, with mirror -> sync.

> I'd prefer doveadm commands with the dsync prefix. (a)) Because:
> 
>   * doveadm already has other 'command groups' like mailbox, director …
>   * that's the way to avoid command clashes (w/o hiding anything)

There are already many mail related commands that don't have any prefix.
For example I think "doveadm import" and "doveadm backup" are quite
related. Also "dsync" is perhaps more about the internal implementation,
so in future it's possible that sync/backup works some other way..




Re: [Dovecot] doveadm + dsync merging

2011-12-30 Thread Jan-Frode Myklebust
On Thu, Dec 29, 2011 at 08:59:35PM +0100, Attila Nagy wrote:
> >
> Slightly different, but it would be good to have a persistently
> running daemon which could operate both in server and client mode.
> In server mode it would listen on a TCP socket. In client mode it
> would accept source and target information via a control socket. The
> target IP address and port would be the daemon's listening socket.
> 

Great idea! 

> 
> The next thing would be to follow dovecot logs and do a sync/async
> replication. :)

It's not too hard to do async already.. If you have last-login tracking in
the post-login scripts, you can use this to know which users to trigger
async backups for every X minute. 


  -jf


Re: [Dovecot] doveadm + dsync merging

2011-12-29 Thread Attila Nagy

Hi,

On 12/29/2011 01:35 PM, Timo Sirainen wrote:

doveadm already supports some nice things, such as being able to remotely 
launch a doveadm command via TCP socket. It also supports executing a command 
for all users or to some specific users using a wildcard. dsync could use these 
features, so I merged dsync and doveadm into same binary for v2.1.

I'll still install "dsync" symlink pointing to "doveadm", and running that way 
it should be fully backwards compatible with the old dsync binary and its parameters.

I'm mainly now wondering about the command naming for running dsync via 
doveadm. Any suggestions?

a) Use "doveadm dsync" prefix, and otherwise keep the names same:

dsync mirror ->  doveadm dsync mirror
dsync backup ->  doveadm dsync backup
dsync server ->  doveadm dsync server (for running dsync remotely via ssh/etc.)

b) Don't have the dsync prefix:

dsync mirror ->  doveadm mirror
dsync backup ->  doveadm backup
dsync server ->  doveadm dsync-server (could be hidden from the doveadm 
commands list)

c) Either a) or b), but rename "mirror" to "sync" or "dsync" or "replicate"?

d) Something else?

Slightly different, but it would be good to have a persistently running 
daemon which could operate both in server and client mode.
In server mode it would listen on a TCP socket. In client mode it would 
accept source and target information via a control socket. The target IP 
address and port would be the daemon's listening socket.


Something like this on the server side:
service dsync {
  process_limit = 8
  client_limit = 8
  inet_listener dsync {
port = 
  }

Then doveadm sync on the "client) could first connect to the local 
server (client), which then connects to the remote service on the 
server. Eg.:

doveadm sync [-C ] [-m ] [-u ] [-frRv]
  mirror  | [@]
where user@host should specify the remote user (mailbox user) and host 
should read like 1.1.1.1:1234 (IP address|hostname and port where the 
dsync service listens. Or a separate port option to allow easier parsing.


Having the client in a persistent setup would allow faster syncs for 
repeated invocations. It would be good to have a simple API to trigger 
the sync (a simple text protocol on a unix socket, or something) from 
outside programs, to avoid calling doveadm.


The next thing would be to follow dovecot logs and do a sync/async 
replication. :)


Re: [Dovecot] doveadm + dsync merging

2011-12-29 Thread Pascal Volk
On 12/29/2011 01:53 PM Patrick Ben Koetter wrote:
> * Timo Sirainen :
>> …
>> a) Use "doveadm dsync" prefix, and otherwise keep the names same:
>>
>> dsync mirror -> doveadm dsync mirror
>> dsync backup -> doveadm dsync backup
>> dsync server -> doveadm dsync server (for running dsync remotely via 
>> ssh/etc.)
>>
>> b) Don't have the dsync prefix:
>>
>> dsync mirror -> doveadm mirror
>> dsync backup -> doveadm backup
>> dsync server -> doveadm dsync-server (could be hidden from the doveadm 
>> commands list)
> 
> Calling the old "dsync" command (symlink) directly should keep the already
> established command structure.
> 
> Calling dsync features over doveadm should keep command structure as simple
> (not complex) as possible. I favour b) for that and rename 'mirror' to 'sync'.
> 
> 'sync' keeps in line with products such as rsync. People will immediately know
> what it does.

I'd prefer doveadm commands with the dsync prefix. (a)) Because:

  * doveadm already has other 'command groups' like mailbox, director …
  * that's the way to avoid command clashes (w/o hiding anything)

Renaming 'mirror' to 'sync' could be helpful …


Regards,
Pascal
-- 
The trapper recommends today: cafebabe.1136...@localdomain.org


Re: [Dovecot] doveadm + dsync merging

2011-12-29 Thread Patrick Ben Koetter
* Timo Sirainen :
> doveadm already supports some nice things, such as being able to remotely 
> launch a doveadm command via TCP socket. It also supports executing a command 
> for all users or to some specific users using a wildcard. dsync could use 
> these features, so I merged dsync and doveadm into same binary for v2.1.
> 
> I'll still install "dsync" symlink pointing to "doveadm", and running that 
> way it should be fully backwards compatible with the old dsync binary and its 
> parameters.
> 
> I'm mainly now wondering about the command naming for running dsync via 
> doveadm. Any suggestions?
> 
> a) Use "doveadm dsync" prefix, and otherwise keep the names same:
> 
> dsync mirror -> doveadm dsync mirror
> dsync backup -> doveadm dsync backup
> dsync server -> doveadm dsync server (for running dsync remotely via ssh/etc.)
> 
> b) Don't have the dsync prefix:
> 
> dsync mirror -> doveadm mirror
> dsync backup -> doveadm backup
> dsync server -> doveadm dsync-server (could be hidden from the doveadm 
> commands list)

Calling the old "dsync" command (symlink) directly should keep the already
established command structure.

Calling dsync features over doveadm should keep command structure as simple
(not complex) as possible. I favour b) for that and rename 'mirror' to 'sync'.

'sync' keeps in line with products such as rsync. People will immediately know
what it does.

p@rick

-- 
state of mind ()

http://www.state-of-mind.de

Franziskanerstraße 15  Telefon +49 89 3090 4664
81669 München  Telefax +49 89 3090 4666

Amtsgericht MünchenPartnerschaftsregister PR 563



[Dovecot] doveadm + dsync merging

2011-12-29 Thread Timo Sirainen
doveadm already supports some nice things, such as being able to remotely 
launch a doveadm command via TCP socket. It also supports executing a command 
for all users or to some specific users using a wildcard. dsync could use these 
features, so I merged dsync and doveadm into same binary for v2.1.

I'll still install "dsync" symlink pointing to "doveadm", and running that way 
it should be fully backwards compatible with the old dsync binary and its 
parameters.

I'm mainly now wondering about the command naming for running dsync via 
doveadm. Any suggestions?

a) Use "doveadm dsync" prefix, and otherwise keep the names same:

dsync mirror -> doveadm dsync mirror
dsync backup -> doveadm dsync backup
dsync server -> doveadm dsync server (for running dsync remotely via ssh/etc.)

b) Don't have the dsync prefix:

dsync mirror -> doveadm mirror
dsync backup -> doveadm backup
dsync server -> doveadm dsync-server (could be hidden from the doveadm commands 
list)

c) Either a) or b), but rename "mirror" to "sync" or "dsync" or "replicate"?

d) Something else?