NixOS: services.{openiscsi, target}, boot.iscsi-initiator: init

[grahamc]

Motivation for this change

I'm deploying some machines using iscsi to host / and /nix, found these modules in #101015 via @ajs124. I took their work plus some additional patches they hadn't pushed, and fixed up the tests.

Includes #115584

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[ajs124]

I'm probably mostly complaining about my own code here and reviewing that is kind of awkward, but it's probably been long enough that I don't remember much of it.

[ajs124]

You might not want to do that. Or do you? Hm. Ah, I remember why I implemented this: The problem is that, normally you get the stage2Init from the initrd. The problem is, that you're probably network booting and if you deploy the system and reboot, you want the system that you deployed and not what the server that serves the initrd has.

Anyways, this is kind of weird for that reason and might confuse users, if they do want to start the system defined in the initrd.

[grahamc]

Hrm. Good point, I don't want this. My use case is actually where only /nix is on iscsi and an initrd is on the disk itself. I'll look at this further.

[ajs124]

There is no documentation for the contents of this file and the format is kind of strange. The parse is also handwritten in python. Not sure if that should be mentioned here, but this description isn't too helpful.

[grahamc]

How did you come up with the data in the test?

[ajs124]

I used targetcli and cut as much away from the config it generates as I could, without it breaking.

[ajs124]

This doesn't need to be set, does it? Why can this even be set? Shouldn't this conflict with https://github.com/NixOS/nixpkgs/pull/115590/files#diff-ac6c7fcd6eac914a135de918524bd345db855c25ac7563fe066cf2a550182544R126? Maybe not, because it's being set to the same value?

[grahamc]

I've pushed some WIP commits for password support, I'm marking this PR as WIP for now.

[grahamc]

This should probably support multiple targets.

[dnr]

Just a small user report: I was looking for a module to help set up iscsi and found this and tried it out. I rebased it on nixos-20.09.

I'm doing the simplest possible thing: starting an initiator for one remote volume, manually, not at boot time (so only using services.openiscsi). Everything worked fine for me.

If I may make the smallest nitpick: /etc/iscsi/initiatorname.iscsi is missing a trailing newline.

[ajs124]

good enough for me, I think

[breakds]

Just a small user report: I was looking for a module to help set up iscsi and found this and tried it out. I rebased it on nixos-20.09.

I'm doing the simplest possible thing: starting an initiator for one remote volume, manually, not at boot time (so only using services.openiscsi). Everything worked fine for me.

If I may make the smallest nitpick: /etc/iscsi/initiatorname.iscsi is missing a trailing newline.

Some questions here if you don't mind. I have a similar use case so I cherry-picked those modules to 20.09.

1. Is it true that I do not need the root-initiator on my client machine, if there is no requirement of mounting the remote disk at boot time?
2. When I add the following configuration to my NixOS configuration, I am getting bas-setting (i.e. it complains about the systemd unit file for iscsid.service).

    services.openiscsi = {
      enable = true;
      enableAutoLoginOut = true;
      discoverPortal = "10.77.1.119";
      name = "iqn.2021-05.org.linux-iscsi.initiatorhost:laborfactory";
    };

And the systemd status:

$ systemctl status iscsid.service
● iscsid.service
     Loaded: bad-setting (Reason: Unit iscsid.service has a bad unit file setting.)
     Active: inactive (dead)
TriggeredBy: ● iscsid.socket

Do you have any suggetions on how to debug?

My attempt so far was to locate the unit file by

$ systemctl show -p FragmentPath iscsid.service
FragmentPath=/nix/store/ly6smc6spj2qncrck9sb9kh8kmmwgcpi-unit-iscsid.service/iscsid.service

And the unit file looks like:

$ cat /nix/store/ly6smc6spj2qncrck9sb9kh8kmmwgcpi-unit-iscsid.service/iscsid.service
[Unit]

[Service]
Environment="LOCALE_ARCHIVE=/nix/store/20dyxqvd9rnwzdnpdzb8vnv8w3vwa8wx-glibc-locales-2.31-74/lib/locale/locale-archive"
Environment="PATH=/nix/store/vr96j3cxj75xsczl8pzrgsv1k57hcxyp-coreutils-8.31/bin:/nix/store/ax8vv1ds6l81jx8cmflx3fvcl9jdxd2w-findutils-4.7.0/bin:/nix/store/rxkghln0km9axapv94iz3pcsln6ricms-gnugrep-3.4/bin:/nix/store/gdr4s4xx41n8krk9carr8amvncy8x3p3-gnused-4.8/bin:/nix/store/zpzn7c5g58srji21flwqmxzbnaa8w29j-systemd-246.6/bin:/nix/store/vr96j3cxj75xsczl8pzrgsv1k57hcxyp-coreutils-8.31/sbin:/nix/store/ax8vv1ds6l81jx8cmflx3fvcl9jdxd2w-findutils-4.7.0/sbin:/nix/store/rxkghln0km9axapv94iz3pcsln6ricms-gnugrep-3.4/sbin:/nix/store/gdr4s4xx41n8krk9carr8amvncy8x3p3-gnused-4.8/sbin:/nix/store/zpzn7c5g58srji21flwqmxzbnaa8w29j-systemd-246.6/sbin"
Environment="TZDIR=/nix/store/9jp4dspz5s53wx3803f99ck8lyfri1jf-tzdata-2020c/share/zoneinfo"

Thanks!

---

Just FYI, when I ran the following command:

$ sudo iscsiadm --mode discoverydb --type sendtargets --portal 10.77.1.119 --discover
[sudo] password for breakds:
iscsiadm: iscsid is not running. Could not start it up automatically using the startup command in the /etc/iscsi/iscsid.conf iscsid.startup setting. Please check that the file exists or that your init scripts have started iscsid.
iscsiadm: can not connect to iSCSI daemon (111)!
iscsiadm: Cannot perform discovery. Initiatorname required.
iscsiadm: Could not perform SendTargets discovery: could not connect to iscsid

It complains about not being able to connect to iSCSI daemon, which I believe it means iscsid.service. However, it seems that iscsid.service does not run any command. I guess that is the part which confuses me the most. Do we expect to see anything running with in iscsid.service systemd service? Thanks in advance, and sorry about my unfamiliarity with iSCSI.