How should the nvme-cli package generate its host "NQN"?

[Andrew Lutomirski]

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.  And it also seems like it might be
surprising for a remove-and-reinstall of nvme-cli to generate a whole
new NQN.

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?

Is there any guidance for how to handle this?

Debian has "purge" for things like this, but I don't think Fedora has
any equivalent.

--Andy

[Tom Hughes]

On 28/09/2018 19:42, Andrew Lutomirski wrote:

>  Debian has "purge" for things like this, but I don't
> think Fedora has
>  any equivalent. 
Doesn't generating in %post and owning it as %ghost in the
files list achieve much the same result of removing it when
the package is removed?

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Rex Dieter]

Tom Hughes wrote:

>  On 28/09/2018 19:42, Andrew Lutomirski wrote:
>  
> > Debian has "purge" for things like this, but I don't think Fedora has
> > any equivalent.
>  
>  Doesn't generating in %post and owning it as %ghost in the
>  files list achieve much the same result of removing it when
>  the package is removed? 
I concur, the above approach also means the file will be 'owned' properly as 
far as rpm is concerned.

-- Rex

[Florian Weimer]

* Andrew Lutomirski:

>  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 
How many bits can the NQN have?  Is it long enough that random
generation of IDs is feasible?

>  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.  And it also seems like it might be
>  surprising for a remove-and-reinstall of nvme-cli to generate a whole
>  new NQN. 
You could have a separate nvme-filesystem package which generates and
owns the file (via %ghost).

Thanks,
Florian

[Colin Walters]

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.

[Tomasz Torcz]

On Fri, Sep 28, 2018 at 11:42:58AM -0700, 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.  And it also seems like it might be
>  surprising for a remove-and-reinstall of nvme-cli to generate a whole
>  new NQN. 
  So this is similar to /etc/iscsi/initiatorname.iscsi. This one is
generated in %post by using iscsi-iname binary:
https://src.fedoraproject.org/rpms/iscsi-initiator-utils/blob/master/f/is...

 But I wouldn't use this method verbatim! iscsi-iname generates different ID on
every invocation, which is not nice.

 The way proposed in BZ use very similar mechanism for NVMoF, invoking
nvme gen-hostnqn. Which has the same problem: every invocation gives
random, non-persistent ID. Again, not nice.

  I propose changing the mechanism of generating the name to give
persistent, machine-specific result.  The best way would be to
patch nvme gen-hostqn to use sd_id128_get_machine_app_specific()
function. This way generated hostqn will be tied to machine-id.

  After this change, stable hostqn could be generated at any moment:
during boot, during package installation, from udev-rule, etc…

  At the moment nvme gen-hostqn is not idempotent. Proposed change
would make the issue of unique name easier.

-- 
Tomasz Torcz               "Never underestimate the bandwidth of a station
xmpp: zdzichubg(a)chrome.pl    wagon filled with backup tapes." -- Jim Gray

[Zbigniew Jędrzejewski-Szmek]

On Sat, Sep 29, 2018 at 01:10:32PM +0200, Tomasz Torcz wrote:
>  On Fri, Sep 28, 2018 at 11:42:58AM -0700, 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.  And it also seems like it might be
>  > surprising for a remove-and-reinstall of nvme-cli to generate a whole
>  > new NQN.
>  
>    So this is similar to /etc/iscsi/initiatorname.iscsi. This one is
>  generated in %post by using iscsi-iname binary:
>
> https://src.fedoraproject.org/rpms/iscsi-initiator-utils/blob/master/f/is...
>  
>   But I wouldn't use this method verbatim! iscsi-iname generates different ID on
>  every invocation, which is not nice.
>  
>   The way proposed in BZ use very similar mechanism for NVMoF, invoking
>  nvme gen-hostnqn. Which has the same problem: every invocation gives
>  random, non-persistent ID. Again, not nice.
>  
>    I propose changing the mechanism of generating the name to give
>  persistent, machine-specific result.  The best way would be to
>  patch nvme gen-hostqn to use sd_id128_get_machine_app_specific()
>  function. This way generated hostqn will be tied to machine-id. 
Yes, please use
sd_id128_get_machine_app_specific() — it is designed
specifically for such purposes.

>    After this change, stable hostqn could be generated at any moment:
>  during boot, during package installation, from udev-rule, etc… 
To underline this:
the id that is generated is stable, so there is
no need to actually store it.

Zbyszek