Re: Can unison better help with renamed hosts?

Thanks Tõivo Leedjärv for joining in! Below more:

On 24.04.24 13:27, Tõivo Leedjärv wrote:
> On Tue, 23 Apr 2024 at 14:18, 'Mario Emmenlauer' via unison-users
> <[email protected]> wrote:
>>
>> 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's already some good discussion going on, but to take a step back:
> 
> - Unison doesn't know which host you mean, so it couldn't possibly
>    relate the expected name and actual name.

I may have created some confusion about this. For my specific problem,
and other people may see this differently, I only care what host name
unison detected. I can easily take responsibility that the login to
the remote host works, because these errors are well explained in the
unison (or ssh) error messages. But _after_ unison logged into the
remote host, it does some magic (explained by you below, I see) to
check if the detected host name and the expected host name match. This
part is a black box for me, and not easy to understand/debug.


> - Unison gets each host's name by gethostname(3), which can be
>    overridden by env var UNISONLOCALHOSTNAME on both server and client,
>    and also by pref "clientHostName" on client only.

Do I understand correctly that unison will call gethostname(3) on each
host, and use that for the names? That confuses me, because gethostname
on the remote machine should not change, depending on whether I'm inside
or outside the company network. The server always reports the same when
you call hostname, no?


> - There is a debug preference "showarchive" that will show the names
>    Unison has detected.

This is *super* helpful, and may be exactly what I'm looking for!!


> - While the hostname-based ID seems to mostly work well, it quickly
>    becomes frustrating when the name changes often (as is the case for
>    Mario) or permanently (as is the case for Greg).
> 
> How to improve?
> 
> - There was already a mention about uuid, but I'd make the suggestion
>    even simpler:
>      let the user provide the ID (on command line or in the profile) for
>      the server. Basically, adding a "serverName" preference which will
>      override all of the abovementioned mechanisms, just like there is
>      one already for the client. If you as a user then mess up and
>      connect to the wrong host, that's on you. But the wrong server will
>      likely not have the archive for this name, so most likely you'd get
>      the big warning.
> - Finally, there should be a way to rename the archives without having
>    to drag 'rootalias' or UNISONLOCALHOSTNAME around forever.
> 
> Together with the proposed solution, I'd also rename the
> "clientHostName" preference to just "clientName". Both the
> "clientName" and "serverName" can be completely arbitrary, so don't
> need to refer to the "host" part, even though they'd effectively
> override the hostname. This way, you could even have differently named
> "instances" on the same host. Can't see any purpose for that besides
> debugging, yet, but you never know.
Sounds good to me. I will also take a look into the sources some time
soon, maybe I can provide more input about this then.

All the best,

     Mario


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