Re: Problem with sync on an ARM Mac

I think the instructions provided by Stefan illustrate well that the
current options for hostname override can be a bit clumsy and
involved. Or, to put it in another way, it could be considered a
defect that an override is needed by regular users in a normal
scenario, as opposed to by power-users in highly specific scenarios.

On Fri, 3 May 2024 at 02:22, Stefan M. Moser <[email protected]> wrote:
>
> I think this part of the discussion relates to the discussions a few days ago regarding whether or not to introduce a serverHostName preference. If I understand you correctly, clientHostName is used for the name on the remote machine that is contacted by ssh. This is exactly NOT what I need, actually. The remote host has a stable name (otherwise I couldn't contact it with ssh anyway), but the local machine (i.e., the laptop) keeps changing name depending on which network I am on. I have been using UNISONLOCALHOSTNAME for decades already to fix the names on all machines once and for all. But the setup of this is rather annoying as can be seen from my lengthy desciption, so I would LOVE to use an option in the unison prf-file instead.

The clientHostName is only used for the archive name calculation
algorithm, on the client. It is not used for any networking. It works
exactly the same as UNISONLOCALHOSTNAME set on the client. It does not
impact the remote machine in any way. So yes, you cuold drop
UNISONLOCALHOSTNAME and have it in the prf-file as clientHostName
instead.

On Fri, 3 May 2024 at 02:33, Greg Troxel <[email protected]> wrote:
>
> "Stefan M. Moser" <[email protected]> writes:
>
> > I think this part of the discussion relates to the discussions a few
> > days ago regarding whether or not to introduce a serverHostName
> > preference.
>
> I see serverHostName as being
>
>   configured in the client (the machine that reads the profile and then
>   runs "ssh remote unison -server"
>
>   used to control the hostname used by the remote ssh

As per our previous discussion, I propose you shouldn't view it as
such. First, Unison doesn't really care about the hostname. It just*
uses the hostname value in the current algorithm because it's
convenient and automatic(!); but this comes with an assumption that
every machine has a stable hostname.

Second, there is nothing in particular requiring that the so-called
"hostname" is different on the two machines (in client and server
role), for the purpose of managing archive files.

Instead, a "key" could be used. It could be, but doesn't have to be,
the same between client and server. Either way, it is supplied by the
client. This could work as an optional override to the current
hostname-algorithm or potentially even replace it (assuming the "key"
could be produced automatically).

(*) I'm simplifying a bit. The hostname is also used for
pretty-printing in the UI to identify the remote end. This is purely
user-focused, does not impact the functionality in any way and does
not require a stable hostname. This can (and should) remain based on
the real hostname.

> I don't like this, because I think names for a host should be set on
> that host, and that setting them elsewhere is asking for trouble.   I am

Sure, but my proposal is not to set or use the hostname.

> starting to believe that the name should be set in the replica, and not
> really be a name.  But that's a huge change and there are likely
> unintended consequences.  I don't want to own those problems, so I'm
> merely observing that it might be a good idea.

I agree this is a huge change and I don't (at least currently) think
this is a good idea. I'm not going to go into the details as I think
it could lead to the discussion becoming off-topic again.

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