On Fri, Sep 28, 2018, at 2:42 PM, Andrew Lutomirski wrote:
There's a request for the nvme-cli package to generate a unique
name
to use when connecting to NVMe-over-fabrics targets:
https://bugzilla.redhat.com/show_bug.cgi?id=1633814
I'm wondering what the right approach is. For the various Atomic
variants, ISTM it's not very nice for the package to generate files in
/etc in a postinstall script.
Regarding nomenclature, going forward you probably want to be
saying "CoreOS-like" instead of Atomic. See also
https://pagure.io/Fedora-Council/tickets/issue/208
Now, it's possible to write files in `/etc` in `%post` - but they're
*server side* defaults.
And this gets to a much more important point - rpm-ostree or
CoreOS style systems are just one instance of building "images"
server side. Doing a `podman build` or mkosi or tons of other
image delivery formats will also trip up on things like this.
So one approach then is generally of "image-based" delivery mechanisms.
(Of course, rpm-ostree is fairly unique in being a hybrid)
Anyways, all of that aside: the correct thing is to have a
systemd service - those always run client side.
Maybe /etc/machine-id could just be symlinked to /etc/nvme/hostnqn.
Or maybe the user should be responsible for setting it up themselves.
Or maybe installing nvme-cli could create an NQN but uninstalling
could leave it there?
Or perhaps better, if /etc/nvme/hostnqn is ENOENT, then default to
/etc/machine-id.
For sending unique IDs over the network, there was also discussion
recently of generating a hashed value for privacy, I forget in what context though.