Re: Problem with sync on an ARM Mac

Maybe on the first run of unison, the current hostname (perhaps editable
before saving) could be written to a file 'unisonlocalhostname' together
with the other archive files, and therafter taken from there. Should be as
stable as the archive.

On Fri, 3 May 2024 at 15:00, Tõivo Leedjärv <[email protected]> wrote:

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

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