Re: Can unison better help with renamed hosts?

Thanks a lot Greg for these helpful details! Below more:

On 22.04.24 16:36, Greg Troxel wrote:
> "'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.

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 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.

Thanks a million for this pointer! I am wrapping unison in a small helper
script, so it should be fairly easy to configure UNISONLOCALHOSTNAME at
least for the local host. I'll check how well that suits my needs.


>> 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.

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.

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 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.

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?

All the best,

     Mario

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