Re: Can unison better help with renamed hosts?

"'Mario Emmenlauer' via unison-users" <[email protected]>
writes:

>> I would suggest that it won't probably take all that long, compared
>> to accomodating it forever.  But it would be good to have data on how
>> long it was.
>
> It indeed is not super long! I'd say it takes on average 1 to 2 hours.
> But since its also quite a strain on the disks, and it seems avoidable
> if only I where able to configure the options correctly, I'd like to
> give it some consideration.

I had the impresssion you changed the name once, in which case
recreating makes sense.  But I think you are changing the name
frequently.

> Well, I do agree that stable host names would be one way out of this!
> However, this is where the cat bites its tail: I am unable to identify
> the host name that unison considers! It just tells me that the host name
> changed, and I am as baffled as I can be. The only way how I could
> currently debug this, seems to be, to run unison in vanilla mode
> (without archives) and check what string is stored in the newly created
> archive.

I believe that unison (on each side) calls gethostname, unless
UNISONLOCALHOSTNAME is defined.

You should be able to test that theory by calling unison with two roots
on the command line, using test dirs, seeing what archive files appear,
and using head -2.

> And this is where my feature request comes in: it would be super helpful
> if this (known) string would be part of the error message. That would
> make life quite a bit simpler, and would help a lot in debugging this
> complex network naming topic.

I am not opposed to putting more *data* in the error message.  What I
don't want to do is to assume that the code knows what the human intends
and give hints that might help if that assumption is right, and do who
knows what if the assumption is wrong.  This is part of a general bias
against hints/suggestions, rather than clear documentation and code that
does what it should in the first place.

It's also possible we should revisit the entire concept of of how roots
are named, with respect to hostnames.  One might name them with some
uuid stored in .unison -- but people sync their homedirs.  I don't think
it's ok to sync .unison (or have it in NFS between machines), but I
don't sync my homedir so that's avoided, I haven't dug into the problems
created by syncing/sharing .unison.

I am not the least bit sure that rootalias is the right thing, for a
machine an unstable hostname.   The real issue is that for a given
machine, one wants the same name to be used always, and
UNISONLOCALHOSTNAME does that.   rootalias seems to need to be
configured for pairs of "wrongname intendedname", for every possible
value of wrongname.   So I would see rootalias as being appropriate for
some other situation, perhaps moving an archive's pathname.

Your situation might be a special case where you have only two names.

> Can you explain what you mean by "guessing"? I assume that unison does
> know the host name it expects (from the archive), and does know the host
> name it actually found instead (the one it would put into a new archive,
> if this where a first time sync). So I was under the (naiive) impression
> that unison holds all the information I would need, if only it was
> displayed :( Or am I on the wrong track here?

There is certainly information about what is expected, and it's a bit
complicated since it starts from the hostname given on the initiator and
then the self-described hostname of the target.  Arguably, it's a
semi-error if those two don't match, but unison has been ok with that.

My guessing comment was entirely about the suggestion to tell the user
what to do, to solve the problem that they might or might not have,
compared to some other thing that is actually what is wrong, that
neither of us have yet anticipated.

I think it comes down to

  1) If you run unison on a computer that has an unstable hostname, you
  need to set UNISONLOCALHOSTNAME on it.   This can be resolved by not
  actually changing the "gethostname(3)" hostname, e.g. by telling the
  DHCP client not to accept the server's suggestion.

  2) If you want to use a script that calls unison with roots, or a prf
  with roots, and the remote side does not have a stable name *by which
  it can be reached*, then you are going to have problems.  My advice is
  to resolve this by configuring ssh to reach the host by its standard
  name, dynamically depending on the network  situation.

I think these issues are independent.

It would be great if you looked at the code to check my impressions and
figure out where to improve logging.   src/os.ml has

  let localCanonicalHostName =
    try System.getenv "UNISONLOCALHOSTNAME"
    with Not_found -> Unix.gethostname()

Similarly you should be able to search for the text of the error message
you are seeing and find that.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].