Created attachment 1487881 [details] nvme.spec/debian: Auto generate host nqn as part of install https://github.com/linux-nvme/nvme-cli commit c1aa2a05e12bb81da3a34b044a5847ac093bb096 (the below portion would create /etc/nvme/hostnqn on installation. diff --git a/nvme.spec.in b/nvme.spec.in index a471877..36c3b21 100644 --- a/nvme.spec.in +++ b/nvme.spec.in @@ -33,6 +33,23 @@ make install DESTDIR=%{buildroot} PREFIX=/usr %clean rm -rf $RPM_BUILD_ROOT +%post +if [ $1 = 1 ]; then # 1 : This package is being installed for the first time + if [ ! -f /etc/nvme/hostnqn ]; then + install -D /dev/null /etc/nvme/hostnqn + echo $(nvme gen-hostnqn) > /etc/nvme/hostnqn + fi +fi + +%preun +if [ "$1" = "remove" ]; then + if [ -d /etc/nvme ]; then + rm -f /etc/nvme/hostnqn + if [ ! -n "`ls -A /etc/nvme`" ]; then + rm -rf /etc/nvme + fi + fi +fi
I'm not convinced that this is the right approach, especially when you take into account Silverblue, Atomic, ostree, etc. What exactly is the NQN needed for? I'm wondering why this change is needed at all. All the docs I found on brief inspection are vague at best. Is the idea that, if you run a software NVMe-over-fabrics target, you need an NQN? If so, can NQN creation be part of the daemon configuration process instead of being part of the nvme-cli installation process? + if [ ! -n "`ls -A /etc/nvme`" ]; then + rm -rf /etc/nvme + fi Are you trying to achieve this: rmdir /etc/nvme || true
Hi Andy, (In reply to Andy Lutomirski from comment #1) > I'm not convinced that this is the right approach, especially when you take > into account Silverblue, Atomic, ostree, etc. > > What exactly is the NQN needed for? I'm wondering why this change is needed > at all. All the docs I found on brief inspection are vague at best. Is the > idea that, if you run a software NVMe-over-fabrics target, you need an NQN? It is not just for NVMe over Fabrics, NVMe Qualified Names (NQNs) are used to uniquely describe a host or NVM subsystem for purposes of identification and authentication. And this would be persistent across reboots. (cc'ing Keith in case he has some input) > If so, can NQN creation be part of the daemon configuration process instead > of being part of the nvme-cli installation process? I was following the upstream nvme-cli, I am not sure where else to create it. > > > + if [ ! -n "`ls -A /etc/nvme`" ]; then > + rm -rf /etc/nvme > + fi > > Are you trying to achieve this: > > rmdir /etc/nvme || true Ok, just took that from the upstream nvme-cli tree. Thanks.
(In reply to David Milburn from comment #2) > Hi Andy, > > (In reply to Andy Lutomirski from comment #1) > > I'm not convinced that this is the right approach, especially when you take > > into account Silverblue, Atomic, ostree, etc. > > > > What exactly is the NQN needed for? I'm wondering why this change is needed > > at all. All the docs I found on brief inspection are vague at best. Is the > > idea that, if you run a software NVMe-over-fabrics target, you need an NQN? > > It is not just for NVMe over Fabrics, NVMe Qualified Names (NQNs) are used > to uniquely describe a host or NVM subsystem for purposes of identification > and authentication. And this would be persistent across reboots. Concretely, what action would I as a user or admin (or what action would the system implicitly take) that actually uses the NQN? > > (cc'ing Keith in case he has some input) > > > If so, can NQN creation be part of the daemon configuration process instead > > of being part of the nvme-cli installation process? > > I was following the upstream nvme-cli, I am not sure where else to create it. > > > > > > > + if [ ! -n "`ls -A /etc/nvme`" ]; then > > + rm -rf /etc/nvme > > + fi > > > > Are you trying to achieve this: > > > > rmdir /etc/nvme || true > > Ok, just took that from the upstream nvme-cli tree. Thanks.
Hi, (In reply to Andy Lutomirski from comment #3) > (In reply to David Milburn from comment #2) > > Hi Andy, > > > > (In reply to Andy Lutomirski from comment #1) > > > I'm not convinced that this is the right approach, especially when you take > > > into account Silverblue, Atomic, ostree, etc. > > > > > > What exactly is the NQN needed for? I'm wondering why this change is needed > > > at all. All the docs I found on brief inspection are vague at best. Is the > > > idea that, if you run a software NVMe-over-fabrics target, you need an NQN? > > > > It is not just for NVMe over Fabrics, NVMe Qualified Names (NQNs) are used > > to uniquely describe a host or NVM subsystem for purposes of identification > > and authentication. And this would be persistent across reboots. > > Concretely, what action would I as a user or admin (or what action would the > system implicitly take) that actually uses the NQN? It is used in discovery and connect over fabrics. nvme discover -t rdma -a 172.31.2.3 -s 1023 --hostnqn=<hostnqn> nvme connect - t rdma -n <subsystem-name> -a 172.31.2.3 -s 1023 --hostnqn=<hostnqn> For non-fabrics, I thought you could you it within a NVMe subsystem, but I realize I don't have a good use case, sorry if I misspoke. Thanks. > > > > > (cc'ing Keith in case he has some input) > > > > > If so, can NQN creation be part of the daemon configuration process instead > > > of being part of the nvme-cli installation process? > > > > I was following the upstream nvme-cli, I am not sure where else to create it. > > > > > > > > > > > + if [ ! -n "`ls -A /etc/nvme`" ]; then > > > + rm -rf /etc/nvme > > > + fi > > > > > > Are you trying to achieve this: > > > > > > rmdir /etc/nvme || true > > > > Ok, just took that from the upstream nvme-cli tree. Thanks.
(In reply to David Milburn from comment #4) > Hi, > > (In reply to Andy Lutomirski from comment #3) > > (In reply to David Milburn from comment #2) > > > Hi Andy, > > > > > > (In reply to Andy Lutomirski from comment #1) > > > > I'm not convinced that this is the right approach, especially when you take > > > > into account Silverblue, Atomic, ostree, etc. > > > > > > > > What exactly is the NQN needed for? I'm wondering why this change is needed > > > > at all. All the docs I found on brief inspection are vague at best. Is the > > > > idea that, if you run a software NVMe-over-fabrics target, you need an NQN? > > > > > > It is not just for NVMe over Fabrics, NVMe Qualified Names (NQNs) are used > > > to uniquely describe a host or NVM subsystem for purposes of identification > > > and authentication. And this would be persistent across reboots. > > > > Concretely, what action would I as a user or admin (or what action would the > > system implicitly take) that actually uses the NQN? > > It is used in discovery and connect over fabrics. > > nvme discover -t rdma -a 172.31.2.3 -s 1023 --hostnqn=<hostnqn> > nvme connect - t rdma -n <subsystem-name> -a 172.31.2.3 -s 1023 > --hostnqn=<hostnqn> > > For non-fabrics, I thought you could you it within a NVMe subsystem, but I > realize I don't have a good use case, sorry if I misspoke. Thanks. Hmm. I wonder if we can derive the NQN from machine-id. Let me ask on the Fedora list. I suspect that the nvme-cli package should at least start owning the /etc/nvme directory.
nvme-cli now owns /etc/nvme. I suppose I should go try to make the upstream change to autogenerate the NQN, too, since no one has beat me to it yet.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.