Re: Can unison better help with renamed hosts?

Tõivo Leedjärv <[email protected]> writes:

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

Letting people configure the server's hostname on the client does seems
useful for testing and debugging, but it adds complexity and unison is
already too complicated.

As I see it, the main path is that the server (remote root via ssh) asks
the OS for "hostname" and uses it.  For systems with stable hostnames,
this works fine, and I don't see a need to depart from this main path.
Rather, I suggest that people who want to run unison on a host fix their
unstable hostname problem, or set UNISONLOCALHOSTNAME.

We have one override mechanism, UNISONLOCALHOSTNAME.  I think that to
first order, the configuration for what name is used for a computer
should be on that computer.   That means a config file that unison
reads, more or less like the env var.

But, even though I think it unwise, people sync their entire homedirs,
and might be syncing .unison, which is not just unwise but likely
unsound.  And, with detachable disks, this raises even more complicated
issues of syncing to a disk where the computer it is plugged into is
just an appliance, not part of the identity.  I already regard my
desktop that way; the computer that I care about is the disk, and just
as I have some monitor attached at any given time, I have a
cpu/ram/ethernet attached to it also.

However, the spectre of people syncing .unison should not keep us from
adding such a feature.  Basically a "serverprefs" file that is read when
unison is a server, with "serverhostname" to override gethostname(3).
This is a config file instead of an env var.

Do we really have a problem that is not resolved by UNISONLOCALHOSTNAME,
once understood?

> - Finally, there should be a way to rename the archives without having
>   to drag 'rootalias' or UNISONLOCALHOSTNAME around forever.

https://urldefense.com/v3/__https://github.com/bcpierce00/unison/issues/1023__;!!IBzWLUs!QSL9ux3LZ1-qfC-oB1xcX3nnh8Ny1q6JR6px5QC2Zb1oiCsjqWRL84UHVaymxNI_vaFLPbAju8g9fJHrEw$ 

filed in the wiki page of things that make sense, but for which there is
no expectation that anyone will do it.

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

I would lean to keeping hostname, because this is about overriding the
gethostname(3) name.  Sure, it is arbitrary, but this all flows from
"generally, each computer has a name" and everything else is fixups.

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