[Dovecot] DSYNC needs a lot more documentation
Started looking into the dsync utility and the doc are seriously incomplete. I can of course scour the internet looking for the missing information but that doesn't fix the problem with the docs. I might try to rewrite the docs myself once I figure it out.
On 21.8.2010, at 16.24, Marc Perkel wrote:
Started looking into the dsync utility and the doc are seriously incomplete. I can of course scour the internet looking for the missing information but that doesn't fix the problem with the docs. I might try to rewrite the docs myself once I figure it out.
Or you could mention some of the things you think are incomplete.
On 8/21/2010 9:16 AM, Timo Sirainen wrote:
On 21.8.2010, at 16.24, Marc Perkel wrote:
Started looking into the dsync utility and the doc are seriously incomplete. I can of course scour the internet looking for the missing information but that doesn't fix the problem with the docs. I might try to rewrite the docs myself once I figure it out. Or you could mention some of the things you think are incomplete.
Ok - when I type dsync at the command line it says:
usage: dsync [-C <alt char>] [-m <mailbox>] [-u <user>] [-frRv] mirror <local mail_location> | [<user>@]<host> | <remote dsync command>
However the man page mentions nothing about any remote commands. There is a reference to ssh in one example but there isn't any kind of overview as to how this all ties in. Does dsync pick up information from dovecot.conf or dovecot to know where the email is an what format it is in? Does dovecot need to be running on both ends? Does this run continuously once you start it or does it need to be run once a minute? The information in the man page isn't complete enough for me to even figure out what to ask.
When you write software you never have to learn it so you don't have the perspective of someone who never heard of it before and wondering "what is this?" I can probable figure it out if I read enough of the message from the dovecot lists but the docs should be complete enough so I don't have to do that unless I'm doing something very weird.
So - ServerA is running dovecot. On ServerB I want to have a live copy so that if the drives on ServerA die I can recover on ServerB? Does it do that?
I want to run dovecot on two servers so that if either server fails the other seamlessly takes over and when the other comes back up they resync as if nothing had happened. Is that possible? If so - how?
If it just does backups, how is it different than rsync?
Anyhow - just letting you know from the perspective of someone who knows nothing and exploring it for the first time. I wanted to say this before I learned anything more about it.
On 2010-08-21 12:51 PM, Marc Perkel marc@perkel.com wrote:
When you write software you never have to learn it so you don't have the perspective of someone who never heard of it before and wondering "what is this?"
Mark, is this another case of your absolute failure to even *try* to google the answer for yourself? You do know that man pages are not the only place (and quite often definitely not the best place) to find documentation for any given software?
http://www.lmgtfy.com/?q=dsync+dovecot+wiki
--
Best regards,
Charles
On Sat, Aug 21, 2010 at 11:00 AM, Charles Marcus CMarcus@media-brokers.com wrote:
On 2010-08-21 12:51 PM, Marc Perkel marc@perkel.com wrote:
When you write software you never have to learn it so you don't have the perspective of someone who never heard of it before and wondering "what is this?"
Mark, is this another case of your absolute failure to even *try* to google the answer for yourself? You do know that man pages are not the only place (and quite often definitely not the best place) to find documentation for any given software?
http://www.lmgtfy.com/?q=dsync+dovecot+wiki
--
Best regards,
Charles
Haha! That is an awesome link thanks!
On Aug 21, 2010, at 11:42 AM, Brandon Lamb wrote:
On Sat, Aug 21, 2010 at 11:00 AM, Charles Marcus CMarcus@media-brokers.com wrote:
On 2010-08-21 12:51 PM, Marc Perkel marc@perkel.com wrote:
When you write software you never have to learn it so you don't have the perspective of someone who never heard of it before and
wondering "what is this?"Mark, is this another case of your absolute failure to even *try* to google the answer for yourself? You do know that man pages are not
the only place (and quite often definitely not the best place) to find documentation for any given software?http://www.lmgtfy.com/?q=dsync+dovecot+wiki
--
Best regards,
Charles
Haha! That is an awesome link thanks!
Indeed!
On 8/21/2010 11:00 AM, Charles Marcus wrote:
On 2010-08-21 12:51 PM, Marc Perkelmarc@perkel.com wrote:
When you write software you never have to learn it so you don't have the perspective of someone who never heard of it before and wondering "what is this?" Mark, is this another case of your absolute failure to even *try* to google the answer for yourself? You do know that man pages are not the only place (and quite often definitely not the best place) to find documentation for any given software?
You are missing the point. When documentation is done right then you don't have to google it unless you are doing something tricky.
On 2010-08-21 3:56 PM, Marc Perkel marc@perkel.com wrote:
You are missing the point. When documentation is done right then you don't have to google it unless you are doing something tricky.
True - but 2.0 is brand new, so instead of posting to the list mostly a vague complaint with a vague offer of a future update to the docs, it would have been better to just not post until you had some updates to offer, or at a minimum, provide specific details of what you think is missing - Timo has always been very quick to remedy missing/incomplete documentation as far as I can see...
Besides - the wiki has the same incomplete information as the man page.
Point taken (I haven't installed 2.0 yet so can't look at the man page)...
--
Best regards,
Charles
On 8/21/2010 11:00 AM, Charles Marcus wrote:
On 2010-08-21 12:51 PM, Marc Perkelmarc@perkel.com wrote:
When you write software you never have to learn it so you don't have the perspective of someone who never heard of it before and wondering "what is this?" Mark, is this another case of your absolute failure to even *try* to google the answer for yourself? You do know that man pages are not the only place (and quite often definitely not the best place) to find documentation for any given software?
Besides - the wiki has the same incomplete information as the man page.
On 08/21/2010 09:58 PM Marc Perkel wrote:
Besides - the wiki has the same incomplete information as the man page.
Yeah, the wiki shows the manual page. ;-)
But now it's time to tell us, waht you are missing / what's incomplete. (see also MID:F559A442-1E7F-4D78-A674-15E2843A3C22@iki.fi)
Regards, Pascal
The trapper recommends today: 5e1f1e55.1023321@localdomain.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Aug 21, 2010 at 02:00:19PM -0400, Charles Marcus wrote:
On 2010-08-21 12:51 PM, Marc Perkel marc@perkel.com wrote:
When you write software you never have to learn it so you don't have the perspective of someone who never heard of it before and wondering "what is this?"
Mark, is this another case of your absolute failure to even *try* to google the answer for yourself?
Now, now. To be fair, Mark offered to take a stab at writing the doc himself. No need to be *that* unfriendly.
You do know that man pages are not theonly place (and quite often definitely not the best place) to find documentation for any given software?
As a statement of fact you are right. Still, it seems this is what we should strive for?
Thanks for the link!
Regards
- -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFMcfEMBcgs9XrR2kYRAs8pAJ9yEEoqrK339V1Q3KnMH+s2d+k4NACdGu+D lKIA/bvtajLL6ZfQ/NqR07g= =vxgq -----END PGP SIGNATURE-----
On Sat, 21 Aug 2010 09:51:12 -0700 Marc Perkel marc@perkel.com articulated:
When you write software you never have to learn it so you don't have the perspective of someone who never heard of it before and wondering "what is this?"
That has always been the problem when the instruction books is written by the products designer/creator, software or otherwise. This is why many commercial distributors hire outside consultants to write their instruction manuals.
I was briefly involved in that field as a part time adventure. Unfortunately, the powers that be all to often considered that including all possible scenarios would make the manual overly confusing to the novice user. Plus, as both IBM and Microsoft learned the hard way, nobody RTFM anyway.
-- Jerry ✌ Dovecot.user@seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
No problem is so formidable that you can't just walk away from it.
C. SchulzOn 8/22/2010 7:29 AM, Jerry wrote:
On Sat, 21 Aug 2010 09:51:12 -0700 Marc Perkelmarc@perkel.com articulated:
When you write software you never have to learn it so you don't have the perspective of someone who never heard of it before and wondering "what is this?" That has always been the problem when the instruction books is written by the products designer/creator, software or otherwise. This is why many commercial distributors hire outside consultants to write their instruction manuals.
I was briefly involved in that field as a part time adventure. Unfortunately, the powers that be all to often considered that including all possible scenarios would make the manual overly confusing to the novice user. Plus, as both IBM and Microsoft learned the hard way, nobody RTFM anyway.
I have always been of the opinion that colleges who teach technical writing should hook up with open source developers and have their students write the docs for the project and work with developers on feature requests and do tech support. It would be win/win because they would get a good education and open source software dovs would greatly improve.
I had the same problem when I was a commercial software developer. I never had to learn it so I knew too much to do the docs right. However since I was doing my own support I quickly realized that if there were questions the users had that weren't covered in the docs, I added them to the docs. Saved me a lot of support effort.
On Sat, 2010-08-21 at 09:51 -0700, Marc Perkel wrote:
Ok - when I type dsync at the command line it says:
usage: dsync [-C <alt char>] [-m <mailbox>] [-u <user>] [-frRv] mirror <local mail_location> | [<user>@]<host> | <remote dsync command>
However the man page mentions nothing about any remote commands.
I'm not really sure what more to write about it. It just needs to execute the dsync some way.
There is a reference to ssh in one example but there isn't any kind of overview as to how this all ties in. Does dsync pick up information from dovecot.conf or dovecot to know where the email is an what format it is in? Does dovecot need to be running on both ends?
I added text about these and some other stuff. See updated http://wiki2.dovecot.org/Tools/Dsync
Does this run continuously once you start it or does it need to be run once a minute?
It's not continuous.
So - ServerA is running dovecot. On ServerB I want to have a live copy so that if the drives on ServerA die I can recover on ServerB? Does it do that?
You can do that, yes.
I want to run dovecot on two servers so that if either server fails the other seamlessly takes over and when the other comes back up they resync as if nothing had happened. Is that possible? If so - how?
Yes, as long as you call dsync for all users often enough. There's no super easy way to do this yet, see my other recent emails about this in some thread with dsync subject..
If it just does backups, how is it different than rsync?
It's faster.
Timo, for dsync, it does not require to have dovecot running, but dsync does require that dovecot and shared libs and etc are installed in the destination ssh server right ?
When dsync are sync mailbox format, when an email are deleted, it only delete the other part from where it is sync, or it does transfer the full mailbox like rsync does ?
[]'sf.rique
On Mon, Aug 23, 2010 at 11:18 AM, Timo Sirainen tss@iki.fi wrote:
On Sat, 2010-08-21 at 09:51 -0700, Marc Perkel wrote:
Ok - when I type dsync at the command line it says:
usage: dsync [-C <alt char>] [-m <mailbox>] [-u <user>] [-frRv] mirror <local mail_location> | [<user>@]<host> | <remote dsync command>
However the man page mentions nothing about any remote commands.
I'm not really sure what more to write about it. It just needs to execute the dsync some way.
There is a reference to ssh in one example but there isn't any kind of overview as to how this all ties in. Does dsync pick up information from dovecot.conf or dovecot to know where the email is an what format it is in? Does dovecot need to be running on both ends?
I added text about these and some other stuff. See updated http://wiki2.dovecot.org/Tools/Dsync
Does this run continuously once you start it or does it need to be run once a minute?
It's not continuous.
So - ServerA is running dovecot. On ServerB I want to have a live copy so that if the drives on ServerA die I can recover on ServerB? Does it do that?
You can do that, yes.
I want to run dovecot on two servers so that if either server fails the other seamlessly takes over and when the other comes back up they resync as if nothing had happened. Is that possible? If so - how?
Yes, as long as you call dsync for all users often enough. There's no super easy way to do this yet, see my other recent emails about this in some thread with dsync subject..
If it just does backups, how is it different than rsync?
It's faster.
On 25.8.2010, at 20.41, Henrique Fernandes wrote:
Timo, for dsync, it does not require to have dovecot running, but dsync does require that dovecot and shared libs and etc are installed in the destination ssh server right ?
It needs to have dsync and usually doveconf installed and runnable. Usually that also means the shared libs, yes, but you can use configure --without-shared-libs to build the binaries without using shared libs.
When dsync are sync mailbox format, when an email are deleted, it only delete the other part from where it is sync, or it does transfer the full mailbox like rsync does ?
It does only minimal data transfer. It could do even less than it does now, but basically now it just sends a list of messages (not their contents) and then the other side figures out that some of the messages in the list are deleted.
participants (9)
-
Bradley Giesbrecht
-
Brandon Lamb
-
Charles Marcus
-
Henrique Fernandes
-
Jerry
-
Marc Perkel
-
Pascal Volk
-
Timo Sirainen
-
tomas＠tuxteam.de