[Csync2] ERROR from peer http0: Identification failed!

[Dennis Schafroth]

After being hit again, I looked more into it. 

Due to 

https://bugzilla.redhat.com/show_bug.cgi?id=648725 (or similar, because I am not running NM)

and that I was csync'ing my /etc/hosts around, the host file got messed. 

Still, I haven't figured out why ping resolved the hostname differently from csync2. 

cheers, 
Dennis

On 05/02/2011, at 23.23, Dennis Schafroth wrote:

> 
> Now I got really hit by it! However not saying your problem is the same... 
> 
> I managed to csync /etc/hosts with settings that pointed localhost interfaces to "wrong"  host. 
> 
> On bb host I had localhost pointing to ab, so none of the host would csync. 
> 
> But even long after fixing it, it still remember the wrong IP. arping, uname -n and nslookup was showing right result. 
> 
> but a ssh ab on bb, it would still ssh to it-self (bb). 
> 
> First after talking the interface down/up I got it to work again...
> 
> Sigh... maybe I am just too tired... My router also crashed hard today.. 
> 
> :-Dennis
> 
> On 05/02/2011, at 13.15, Alex Cartwright wrote:
> 
>> Yep, the output of 'uname -n' matches the config files on both machines. I do 
>> however realise there was a typo in my previous email; please replace "rrltd" 
>> with "example" within the csync.cfg file :)
>> 
>> It quite simply is not working; and makes little sense to me.
>> 
>> On Saturday 05 February 2011 12:04:43 Dennis Schafroth wrote:
>>> Hi,
>>> 
>>> I have been hit by this check a couple of times as well.
>>> 
>>> My check is whether the hostnames in the config file matches the "uname
>>> -n".
>>> 
>>> This has worked for me on fedora, opensuse and ubuntu boxes.
>>> 
>>> However being a Fedora guy for many years, how to set the hostname on
>>> non-fedora boxes is somewhat of a mystery to me.
>>> 
>>> I have been thinking about writing a patched to disable this check.
>>> 
>>> ;-Dennis
>>> 
>>> On 05/02/2011, at 12.38, Alex Cartwright wrote:
>>>>> Both then do a forward lookup of that hostname, and if that does not
>>>>> resolve to the respective remote ip address, that is rejected.
>>>>> 
>>>>> We do that to avoid accidentally syncing with the wrong peer
>>>>> and causing, ahum, major inconvenience.
>>>>> 
>>>>> Depending on your setup, forward lookup usually involves looking
>>>>> at /etc/hosts, so that's why this influences csync2 "authentication".
>>>> 
>>>> I'm still a little confused as to just what exactly it is checking. I'm
>>>> trying it on a smaller scale here using just 1 peer and lots of debug to
>>>> see what is going on, but none of it makes sense.
>>>> 
>>>> This is the output from "example.net":
>>>>  $ hostname; hostname -f
>>>>  example
>>>>  example.net
>>>>  $ grep -E "example|nas0" hosts
>>>>  77.xx.xx.xx    example.net example
>>>>  192.168.0.3     nas0.cluster nas0
>>>>  $ dig +noall +answer example nas0
>>>>  example.                  0       IN      A       77.xx.xx.xx
>>>>  nas0.                   0       IN      A       192.168.0.3
>>>>  $ less csync2.cfg
>>>>  # please see the REAMDE file how to configure csync2
>>>>  nossl * *;
>>>> 
>>>>  group standard {
>>>> 
>>>>      # Standard group that syncs up common configuration
>>>>      # that generally all our servers will be using.
>>>>      key /etc/csync2.key;
>>>>      auto none;
>>>> 
>>>>      host rrltd;
>>>>      host nas0;
>>>> 
>>>>      include /etc/csync2.cfg;
>>>>      include /etc/vim/vimrc;
>>>> 
>>>>  }
>>>> 
>>>> And from "nas0.cluster"
>>>> 
>>>>  $ hostname; hostname -f
>>>>  nas0
>>>>  nas0.cluster
>>>>  $ grep -E "example|nas0" hosts
>>>>  192.168.0.3     nas0.cluster nas0
>>>>  77.xx.xx.xx    example.net example
>>>>  $ dig +noall +answer example nas0
>>>>  example.                  0       IN      A       77.xx.xx.xx
>>>>  nas0.                   0       IN      A       192.168.0.3
>>>>  $ less csync2.cfg
>>>>  # please see the REAMDE file how to configure csync2
>>>>  nossl * *;
>>>> 
>>>>  group standard {
>>>> 
>>>>      # Standard group that syncs up common configuration
>>>>      # that generally all our servers will be using.
>>>>      key /etc/csync2.key;
>>>>      auto none;
>>>> 
>>>>      host rrltd;
>>>>      host nas0;
>>>> 
>>>>      include /etc/csync2.cfg;
>>>>      include /etc/vim/vimrc;
>>>> 
>>>>  }
>>>> 
>>>> So why on Earth does the following fail?
>>>> 
>>>> $ sudo csync2 -x -P nas0 -vvv /etc/vim/vimrc
>>>> My hostname is example.
>>>> Database-File: /var/lib/csync2/example.db
>>>> Config-File:   /etc/csync2.cfg
>>>> Match (+): /etc/vim/vimrc on /etc/vim/vimrc
>>>> Running check for /etc/vim/vimrc ...
>>>> SQL: SELECT filename from file where filename = '/etc/vim/vimrc'  ORDER
>>>> BY filename
>>>> SQL Query finished.
>>>> Match (+): /etc/vim/vimrc on /etc/vim/vimrc
>>>> Checking /etc/vim/vimrc.
>>>> SQL: SELECT checktxt FROM file WHERE filename = '/etc/vim/vimrc'
>>>> SQL Query finished.
>>>> SQL: SELECT peername FROM dirty GROUP BY peername ORDER BY random()
>>>> SQL Query finished.
>>>> SQL: SELECT filename, myname, force FROM dirty WHERE peername = 'nas0'
>>>> ORDER by filename ASC
>>>> SQL Query finished.
>>>> Connecting to host nas0 (PLAIN) ...
>>>> Local> CONFIG \n
>>>> Peer> OK (cmd_finished).\n
>>>> Local> HELLO example\n
>>>> Peer> Identification failed!\n
>>>> While syncing file /etc/vim/vimrc:
>>>> ERROR from peer nas0: Identification failed!
>>>> Local> BYE\n
>>>> Peer> OK (cu_later).\n
>>>> SQL: SELECT command, logfile FROM action GROUP BY command, logfile
>>>> SQL Query finished.
>>>> Finished with 1 errors.
>>>> 
>>>> 
>>>> It makes 100% no sense to me, everything matches up ... or at least I
>>>> think it does. Any help?
>>>> 
>>>> Regards
>>>> _______________________________________________
>>>> Csync2 mailing list
>>>> Csync2 at lists.linbit.com
>>>> http://lists.linbit.com/mailman/listinfo/csync2
>> 
> 
> _______________________________________________
> Csync2 mailing list
> Csync2 at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/csync2
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/csync2/attachments/20110210/a74caa6f/attachment-0001.htm>