Systemd programming, 30 months later
Systemd programming, 30 months later
Posted Oct 3, 2016 21:40 UTC (Mon) by nybble41 (subscriber, #55106)In reply to: Systemd programming, 30 months later by flussence
Parent article: Systemd programming, 30 months later
Is it possible to (easily) configure NFS to perform the same task? I don't want to trust the client or the network, so ID mapping, server-side authentication and access controls are hard requirements, along with built-in end-to-end encryption. If I'd need to tunnel NFS over SSH (or another VPN) to get the encryption then I might as well just keep using sshfs, which provides all that with almost no administrative overhead.
Systemd programming, 30 months later
Posted Oct 10, 2016 17:39 UTC (Mon)
by flussence (guest, #85566)
[Link] (3 responses)
Posted Oct 10, 2016 17:39 UTC (Mon) by flussence (guest, #85566) [Link] (3 responses)
Possible? In theory.
Easy? I've just wasted a weekend navigating a maze of outdated docs and 404-ing websites trying to get NFS to do anything and *once again* gave up in frustration. That includes reading nfsd(8), nfsd(7), nfs(5), and the linux-nfs/README file - which makes it sound like this is all abandonware.
Right out of the starting gate, trying the simplest possible thing that should work according to its own documentation, NFS fails to be sane: I run "rpc.nfsd -d -N 3". And then it hangs in D state for two minutes, not responding to Ctrl+C or Ctrl+\. No errors on the terminal, no errors in dmesg. pstree and ss show that it's running afterwards but drops all incoming connections.
What a horrid practical joke. I'll stick with running sshfs as root+allow_other.
Systemd programming, 30 months later
Posted Oct 11, 2016 9:26 UTC (Tue)
by neilbrown (subscriber, #359)
[Link] (2 responses)
Posted Oct 11, 2016 9:26 UTC (Tue) by neilbrown (subscriber, #359) [Link] (2 responses)
You didn't have rpcbind running. Had you been using the upstream systemd unit files....
(Still, it shouldn't hang. I've reported this and proposed a solution, but no forward progress yet).
Systemd programming, 30 months later
Posted Oct 11, 2016 20:40 UTC (Tue)
by flussence (guest, #85566)
[Link] (1 responses)
Posted Oct 11, 2016 20:40 UTC (Tue) by flussence (guest, #85566) [Link] (1 responses)
Looks like I was holding the manual upside down all along. I had the impression all the RPC stuff was unnecessary with NFSv4.
But thanks, that gave me enough of a push in the right direction to finally get it working. For the benefit of others, here's everything I ended up doing:
- Poke a hole in the firewall for UDP/TCP 2049.
- These two RPC things were the magic pixie dust I was missing (excerpt from pstree -a):
├─runsv rpcbind │ └─rpcbind -f └─runsv rpc.mountd └─rpc.mountd -N 3 -F - Start the in-kernel nfsd *after* those, using rpc.nfsd -H ${bind_addr} -N 3 $(nproc). This will return immediately provided rpcbind is running, and afterwards /proc/fs/nfsd/ should have become mounted. Stopping the server is done with rpc.nfsd 0 if needed.
- Running
rpcinfonow should show the portmapper, nfs and mountd services running. - Edit /etc/exports and run exportfs -a. Take note of the other comments up-thread: a manual bind mount and
fsid=0setup is unnecessary.no_subtree_checkisn't needed either, but I put it in to avoid loud warning messages.
That, surprisingly, is all it needed. autofs's NFS autodetection depends on the showmount command which doesn't speak NFSv4, so I gave up on that route.
Systemd programming, 30 months later
Posted Oct 11, 2016 21:55 UTC (Tue)
by neilbrown (subscriber, #359)
[Link]
Posted Oct 11, 2016 21:55 UTC (Tue) by neilbrown (subscriber, #359) [Link]
rpcbind isn't technically necessary, but there is kernel bug since v4.3 (commit 4b0ab51db32) which introduces a long timeout when starting nfsd without rpcbind running, even if you only request NFSv4. I hadn't properly noticed that you were requesting v4-only - sorry. rpc.nfsd tries to register with rpcbind even for v4, but if it fails (which currently means if it times out) it proceeds anyway.
rpc.mountd is needed, not for the RPC services it provides but for other lookup services it provides directly to the kernel. If you ask rpc.mountd to not support v2 or v3 (-N 2 -N 3) then it won't register with rpcbind at all and wont serve any rpc requests.
Systemd programming, 30 months later
Posted Oct 10, 2016 19:04 UTC (Mon)
by Darkstar (guest, #28767)
[Link] (3 responses)
Posted Oct 10, 2016 19:04 UTC (Mon) by Darkstar (guest, #28767) [Link] (3 responses)
I think "mount -o soft" should still work (at least with NFSv3). That *should* handle disconnects (although I'm not sure about reconnects). But then again I do mostly enterprise-level stuff where NFSv3 and v4 are pretty easy and rock-solid (we run large virtualization farms with very big customers over NFSv3 and v4 ). But there we usually have separate VLANs without the need for encryption, for example.
Systemd programming, 30 months later
Posted Oct 11, 2016 9:30 UTC (Tue)
by neilbrown (subscriber, #359)
[Link] (2 responses)
Posted Oct 11, 2016 9:30 UTC (Tue) by neilbrown (subscriber, #359) [Link] (2 responses)
"-o soft" never worked for any useful definition of "worked" - i.e. one where you could trust that you data was safe. I once heard NFS described as Nulls Frequently Substituted. If you use -o soft and have bad latency on your network, you can get holes in files.
autofs is by far the best solution to handle disconnects well.
Systemd programming, 30 months later
Posted Oct 11, 2016 16:12 UTC (Tue)
by Darkstar (guest, #28767)
[Link] (1 responses)
Posted Oct 11, 2016 16:12 UTC (Tue) by Darkstar (guest, #28767) [Link] (1 responses)
I think this only applies to "-o soft,udp" but not "-o soft,tcp". But then again it's been years and you might be correct. I agree that autofs is probably the better option
Systemd programming, 30 months later
Posted Oct 11, 2016 21:45 UTC (Tue)
by neilbrown (subscriber, #359)
[Link]
Posted Oct 11, 2016 21:45 UTC (Tue) by neilbrown (subscriber, #359) [Link]