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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
