Dear Jack and Eric,
Sorry for the delayed response. While looking practical,
rsync is bit complected. Because half of the users are depending only
in the main server (Roaming users). So we must implement directory
level sync (/home/vpopmail/domains/domainname/username). Also the ssh
keys or plain text password cannot be stored in both the servers.
Because the main server is serving for few more domains also.
So i shall search is there any fix in the fetchmail level. If
there is any known fixes or solutions in the fetchmail, please share
with me.
Thanks and Regards,
S.Senthilvel,
On Wed, Aug 12, 2009 at 11:37 AM, Eric Shubert<e...@shubes.net> wrote:
> Jake Vickers wrote:
>>
>> Eric Shubert wrote:
>>>
>>> Jake Vickers wrote:
>>>>
>>>> Eric Shubert wrote:
>>>>>
>>>>> Jake Vickers wrote:
>>>>>>
>>>>>> senthil vel wrote:
>>>>>>>
>>>>>>> Thanks Jake and Eric,
>>>>>>>
>>>>>>>
>>>>>>> Both the servers are QMT. The main server works very best
>>>>>>> in all aspects including spam fighting. If we are using rsync instead
>>>>>>> of fetchmail, is it enough to sync the
>>>>>>> /home/vpopmail/domains/domainname directory? Or we need to look
>>>>>>> something more?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I would sync the user's dir, and use the --delete option from rsync to
>>>>>> remove the messages from the initial server on the next sync once the
>>>>>> user
>>>>>> has them. So you would reverse sync them; initiate the sync on the remote
>>>>>> machine to the initial machine.
>>>>>>
>>>>>
>>>>> I don't believe this would work. rsync is a one-way deal. Only one side
>>>>> can be the 'master'. And it doesn't really matter which side it's run on,
>>>>> only the order that the source/destination are specified in the command is
>>>>> significant. Please correct me if I'm wrong on this.
>>>>
>>>> If you run rsync on the remote machine and use the --delete option, any
>>>> files that were deleted on the remote machine would be removed from the
>>>> initial machine. It's not a 2-way sync, but it will remove the files from
>>>> the other server this way after they've been downloaded by the user to keep
>>>> them from getting multiple copies.
>>>> So you would be making the remote machine the "master", and when the
>>>> users downloaded their mail those messages would be removed from the
>>>> "slave"
>>>> machine on the next sync (the "slave" being the main server and the
>>>> "master"
>>>> being the local one)
>>>> And you are correct as to the order as far as defining the source and
>>>> target. It would not matter what machine you ran it on. I would just do it
>>>> this way for readability and so that the remote machine is calling the main
>>>> - planning for failure points in the event the remote machine is not always
>>>> available (else, why even have a remote machine?)
>>>>
>>>
>>> That I understand. So how do the new messages get to the remote server if
>>> the remote server's the master?
>>>
>>
>> I thought he had said the remote server was using smtproutes to send
>> messages. Did I miss that?
>
> I think he meant outbound from the backend.
>
> Now that you have me actually thinking about this, I suppose you could do a
> pull-push rsync (run it two times back to back) from the remote side. This
> would only work if the remote users were using pop3 though, not imap. A bit
> heavier on the bandwidth than it'd need to be, but it should work.
>
> I still think the best solution is to fix fetchmail though. That shouldn't
> be too difficult to do.
>
> --
> -Eric 'shubes'
>
>
> ---------------------------------------------------------------------------------
> Qmailtoaster is sponsored by Vickers Consulting Group
> (www.vickersconsulting.com)
> Vickers Consulting Group offers Qmailtoaster support and installations.
> If you need professional help with your setup, contact them today!
> ---------------------------------------------------------------------------------
> Please visit qmailtoaster.com for the latest news, updates, and packages.
> To unsubscribe, e-mail:
> qmailtoaster-list-unsubscr...@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>
>
>
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
