Content-Length: 20347 | pFad | http://lwn.net/Articles/702492/

Systemd programming, 30 months later [LWN.net]
|
|
Subscribe / Log in / New account

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

I use sshfs for all my home network filesystem needs and haven't noticed any issues with the filesystem hanging after an overnight suspend, so long as the network doesn't go down altogether. I did have to set some options to enable automatic reconnection (which can pause accesses for a few seconds), and I use a wrapper script ensure that the key is loaded into ssh-agent before the filesystem is mounted, but on the whole it's quite reliable.

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.


to post comments

Systemd programming, 30 months later

Posted Oct 10, 2016 17:39 UTC (Mon) by flussence (guest, #85566) [Link] (3 responses)

> Is it possible to (easily) configure NFS to perform the same task?
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)

> And then it hangs in D state for two minutes, not responding to Ctrl+C or Ctrl+\.

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)

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:

  1. Poke a hole in the firewall for UDP/TCP 2049.
  2. 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
  3. 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.
  4. Running rpcinfo now should show the portmapper, nfs and mountd services running.
  5. Edit /etc/exports and run exportfs -a. Take note of the other comments up-thread: a manual bind mount and fsid=0 setup is unnecessary. no_subtree_check isn'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]

> I had the impression all the RPC stuff was unnecessary with NFSv4.

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)

> Is it possible to (easily) configure NFS to perform the same task?
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)

> I think "mount -o soft" should still work

"-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)

> If you use -o soft and have bad latency on your network, you can get holes in files.
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]

soft,tcp would certainly be different than soft,udp but the same risks are there - just different probabilities and different patterns.. I suspect it would be harder to demonstrate a problem with tcp, but not impossible.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/702492/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy