Re: Can unison better help with renamed hosts?

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

Take this all with a grain of salt, as I have only dug in enough to
solve my problems.

> The only real downside I have found so far, is, that over the many years
> of usage, every now and then a remote host is found under a different
> name. Since I sync hundreds of GB of files I would like to avoid a re-
> creation of the archives.

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.

> I know there is "rootalias" to help. But this is actually quite hard
> for me to get working. I've repeatedly spent more than one hour on
> this option, and most recently could not get it to work at all.

However, I have a situation like this, and to my surprise it has
persisted.

Basically, I had a computer foo.example.com.   Then, I moved it to a
different physical place, and as part of that renamed it to
bar.example.com (because that made sense, ignoring unison).

However, the archives on both foo/bar and a remote system had
foo.example.com baked into them.  You can "head -2 .unison/ar*" to see.

So, I added to my environment on foo/bar:

  export UNISONLOCALHOSTNAME=foo.example.com

I had to do this in two places.  One is in my dotfiles, and the other is
in .ssh/environment.

Then, unison when asking 'what is the name to be used for archives"
comes up with foo.example.com, instead of the actual hostname
bar.example.com.

I actually invoke unison as using bar.example.com as the root on the
command line.  (I don't really use prf files.)

This may be the same as rootalias, but I thought I'd mention it.

> I guess my main problem is that I do not necessarily know the old and new
> host names that unison considers a host to have. As an example, a machine
> that I sync is known through various means:
>  - The local hostname on the machine is "bool", with our company domain name

do you mean " hostname(1) prints bool "?  I think hostnames should be
FQDN, but I also think it's best not rely on hostname for machines that
move around.

>  - The machine is known as "bool" through /etc/hosts on other machines
>  - The machine is known as "bool" through my .ssh/config with the local IP,
>    username and SSH port
>  - The machine is known as "bool" with domain name through my .ssh/config,
>    with the outside company IP, username and SSH port
>  - The machine is known via DNS on the internet through the company DNS
>    server

If the name bool is everywhere, then putting it in a prf or command-line
root seems fine.

I think it comes down to:

  there's a name in the prf, or as a root on the command line, and that
  is used to reach the host by calling ssh with it

  the host itself finds out its hostname, either from probably
  gethostname(3) or from UNISONLOCALHOSTNAME.  (I have no idea about
  Windows.)

> I successfully synced my laptop against this machine, from inside the
> company network. Later from home, it was virtually impossible for me to
> tell unison that the remote host is available under the external name.

I would suggest configuring ssh so that you can use the standard name
and have it use some kind of proxyjump and/or hostname args to get to
where it is.  Basically use ssh to remediate the bug of "the host is not
available under a stable name".  That may involve swapping ssh configs
based on your network environment.

I think it's asking for trouble to be changing the prefs file to
accomodate temporary name changes.

> I think it would be great if unison could print something like this, in
> the error message:
>     The remote host was known as //XXX//YYY/
>     and is now found as //PPP//QQQ/
>     If this is guaranteed to be the same host, you can set
>     rootalias = SOMETHING -> SOMEOTHERTHING
>
> Then it should be trivial to debug the problem, and correctly set
> "rootalias".

I am reluctant to add instructions by guessing.  If anything, I would
want to cache hostname so that each side can detect renames.  But I'd
really want to step back and think about the kinds of identities we are
using and why and make sure it's 100% right.  I want to consider the
possibilty that a fix involves taking away mechanisms rather than adding
them.

Overall, I think your problem is best solved by

  If a computer doesn't have a stable hostname, setting
  UNISONLOCALHOSTNAME so that it does.  This is set on one machine only
  and then seems quite reliable

  making each host that you sync to (vs from) reachable by the standard
  name, via ssh config, ssh controlmaster connection with options before
  running unison, vpn, whatever

Perhaps you can try that and see how it works and report back.  

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