IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 4 August 2020 (all times are UTC)
| 05:08 | sutula has left IRC (sutula!~sutula@184.97.13.190, Ping timeout: 264 seconds) | |
| 05:09 | sutula has joined IRC (sutula!~sutula@184.97.13.190) | |
| 05:28 | woernie has joined IRC (woernie!~werner@p5dded9eb.dip0.t-ipconnect.de) | |
| 06:45 | RaphGro has joined IRC (RaphGro!~raphgro@fedora/raphgro) | |
| 08:49 | <Vercas> alkisg: Sorry for late reply. Other users can type. Only guest cannot type.
| |
| 08:50 | <alkisg> Vercas: ok, not enough info to say more...
| |
| 08:51 | <Vercas> I'll try more tonight.
| |
| 08:53 | <alkisg> I.e. I do not know which parts you tried, and your participation in the chat here is too asynchronous, it doesn't help... I think you need to describe all your problem from scratch next time...
| |
| 08:53 | <Vercas> I understand. Tonight I'll document exactly what I'm doing and what happens.
| |
| 08:54 | <alkisg> Which timezone are you in?
| |
| 08:54 | <Vercas> BST
| |
| 08:54 | I'm in the UK.
| |
| 08:54 | <alkisg> OK, I'm in UTC+3, close enough...
| |
| 10:18 | kvaps has joined IRC (kvaps!2e1c6842@wedos.wedos.net) | |
| 10:36 | <alkisg> Hey kvaps, thanks for the PR, I'll merge it soonish, the next time I'll work on the ltsp code
| |
| 10:38 | <kvaps> OK, I just wanted to inform that I working on new project which should simplify kubernetes deployment based on LTSP
| |
| 10:38 | github.com/kvaps/kubefarm
| |
| 10:39 | alkisg: haven't you face with this issue? http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014298.html
| |
| 10:40 | <alkisg> kvaps: we're using routers as the dhcp servers, so we only use the proxydhcp part of dnsmasq...
| |
| 10:40 | All other dnsmasq settings are ignored for us
| |
| 10:41 | Only the next-server and boot-filename are processed
| |
| 10:41 | <kvaps> alkisg: I see, ok
| |
| 11:09 | <Vercas> alkisg: Got a small question for you: why is NFS preferred over NBD for the squashfs image?
| |
| 11:10 | <alkisg> Vercas: a lot more stable, and a bit faster
| |
| 11:10 | <Vercas> Really? That doesn't sound good for NBD.
| |
| 11:10 | <alkisg> NBD was almost fine 10 years ago; in the last 5 years it started having a lot of instabilities,
| |
| 11:11 | <Vercas> Hm.
| |
| 11:11 | <alkisg> we reported 5 or so of them, and some were addressed, but not all of them...
| |
| 11:11 | and nbd was never able to reconnect after disconnections,
| |
| 11:11 | <Vercas> I don't suppose iSCSI fares any better here, right?
| |
| 11:11 | <alkisg> while now with nfs, the clients may ever survive a *server* reboot
| |
| 11:11 | <Vercas> Wait, really?
| |
| 11:11 | <alkisg> There are no downsides to nfs that I know of, to try to select a different protocol...
| |
| 11:12 | Well, apart from rbd, for clustering
| |
| 11:12 | <Vercas> The downside to NFS is the requirement of NFSv3.
| |
| 11:12 | Which is a security nightmare. :(
| |
| 11:12 | If it worked with NFSv4 I'd be a happy doe. But it doesn't.
| |
| 11:13 | <alkisg> Vercas: the image is read only, nfs3 is less insecure than nbd
| |
| 11:13 | You don't have to use nfs3 for /home; you can use sshfs or nfs4 for /home
| |
| 11:13 | <Vercas> Yes but the services you need to make NFSv3 work are a security issue.
| |
| 11:13 | <alkisg> How so?
| |
| 11:14 | Why is nfs a security issue and nbd isn't?
| |
| 11:14 | <Vercas> They do stuff like binding on all interfaces.
| |
| 11:14 | Not saying that NBD isn't.
| |
| 11:14 | I'm saying that NFSv3 is, and NFSv4 isn't.
| |
| 11:14 | <alkisg> I thought we were comparing nbd to nfs...
| |
| 11:14 | initramfs-tools do not support nfs4
| |
| 11:14 | <Vercas> Yeah, I'm painfully aware.
| |
| 11:15 | I've been netbooting clients from NFSv3 before I found LTSP.
| |
| 11:15 | <alkisg> I don't see why nfs4 is more secure than nfs3
| |
| 11:15 | for read only root, that is
| |
| 11:15 | <Vercas> It's not the security of LTSP that is affected.
| |
| 11:15 | But the security of the server.
| |
| 11:15 | <alkisg> isn't the same server running?
| |
| 11:15 | <Vercas> Things like rpcinfo/rpcbind listening on all interfaces.
| |
| 11:16 | <alkisg> And with nfs4 they're not?
| |
| 11:16 | <Vercas> Nope.
| |
| 11:16 | NFSv4 does not need those.
| |
| 11:16 | <alkisg> So, I do `apt install nfs-kernel-server` in debian and I get both nfs3 and nfs4,
| |
| 11:16 | <Vercas> Indeed.
| |
| 11:16 | You can then mask the RPC service.
| |
| 11:16 | <alkisg> and that's a security issue, and to make it more secure, I'd stop some services and disable nfs3?
| |
| 11:16 | <Vercas> And you can use NFSv4 just fine.
| |
| 11:17 | Pretty much, yes.
| |
| 11:17 | NFSv4 is a standalone protocol.
| |
| 11:17 | <alkisg> I thought nfs4 needed a lot more services than nfs3, but I haven't looked into it
| |
| 11:17 | <Vercas> It doesn't need the dumpster fire that is rpcinfo, mountd, lockd...
| |
| 11:17 | <alkisg> Btw if you want really really secure booting, you can hook up wireguard in initramfs-tools
| |
| 11:18 | And only allow access to wireguard-authenticated clients
| |
| 11:18 | <Vercas> It's not an issue for me, I've written (loads of) firewall rules to protect my server.
| |
| 11:18 | But other people won't know this.
| |
| 11:18 | (note: I'm a Linux network driver developer, I know a bit about this)
| |
| 11:19 | <alkisg> Thank you for the info then; I only minimally saw the nfs code when I reported a big buffering performance issue with nfs upstream,
| |
| 11:19 | it helped bump the performance from 200 mbps to 1000 mbps; so now it became faster than nbd,
| |
| 11:20 | <Vercas> NFSv4 is also going to be faster than NFSv3, especially after connection failures.
| |
| 11:20 | <alkisg> but, I'm not aware of any open security holes with nfs3
| |
| 11:20 | <Vercas> As I said, the security holes are in the services like rpcbind, lockd, and mountd.
| |
| 11:20 | rpcbind in particular is quite bad.
| |
| 11:20 | <alkisg> If people keep their server updated, isn't it good enough? Most people don't have public IPs in their servers...
| |
| 11:21 | <Vercas> If their servers are 100% internal then there is no problem.
| |
| 11:21 | <alkisg> Are there currently known open security holes?
| |
| 11:21 | <Vercas> Yes - the whole thing is a security hole.
| |
| 11:21 | By design.
| |
| 11:21 | It lets you list a great deal of services running on the server.
| |
| 11:21 | <alkisg> So if I expose a read-only nfs3 server on the internet, I'll get hacked? I haven't heard of that...
| |
| 11:22 | <Vercas> It won't get hacked automatically, but someone who's targetting the server will have a much easier time figuring out what's running on the server.
| |
| 11:22 | You might be unlucky enough to get targetted by a good bot.
| |
| 11:22 | Like I was.
| |
| 11:22 | I've lost a server to an automatic bot like that.
| |
| 11:22 | <alkisg> They got in via nfs/rcp/etc, or by the other service that you were running?
| |
| 11:23 | <Vercas> I don't even know what software it exploited but it took me months to realize.
| |
| 11:23 | It didn't get root access, so the attacker just gave up and started mining crypto on it.
| |
| 11:24 | * alkisg checks https://www.cvedetails.com/vulnerability-list/vendor_id-1783/NFS.html | |
| 11:25 | <Vercas> alkisg: If you can contact any server with NFSv3 now, just run the command `rpcinfo <hostname>` and look at the man page for more options.
| |
| 11:25 | There is a lot of info.
| |
| 11:26 | It's absurd really.
| |
| 11:26 | <alkisg> Vercas: sure, but that's not too significant
| |
| 11:26 | It's not a security hole by itself
| |
| 11:26 | I could just as easily run a port scan...
| |
| 11:26 | <Vercas> I think you're not seeing the forest for the trees here.
| |
| 11:26 | <alkisg> For example, have you seen ldminfod?
| |
| 11:27 | <Vercas> I don't think I have.
| |
| 11:27 | <alkisg> This one is showing a whole lot more info, and it's ltsp-specific, and noone even mentioned it ever...
| |
| 11:27 | * Vercas googles that. | |
| 11:27 | <alkisg> It's a service that's running in ltsp5 servers
| |
| 11:28 | So if you ever had an ltsp5 server, you exposed all that info (and it did have holes too...)
| |
| 11:28 | <Vercas> Well, let's not go into the "what about" rabbit hole. :(
| |
| 11:28 | The gist of this conversation is: if something can be done to use NFSv4 instead of NFSv3, it really should be done.
| |
| 11:28 | For security *and* speed.
| |
| 11:29 | <alkisg> This isn't an issue for ltsp though, it's an issue for initramfs-tools. Dracut already supports nfs4, and the kernel too can be compiled with built-in nfs4 support.
| |
| 11:29 | <Vercas> Yeah, initramfs-tools's lack of NFSv4 is maddening.
| |
| 11:29 | And the error it gives is incredibly dumb.
| |
| 11:30 | It says "permission denied".
| |
| 11:30 | <alkisg> There's a debian bug about this, you could try commenting there
| |
| 11:30 | As maks (the debian maintainer) is responsible on what goes in initramfs-tools or not
| |
| 11:30 | <Vercas> I've complained about it to the Ubuntu devs last year and they didn't care.
| |
| 11:31 | <alkisg> Each bug should be reported to the respective code base
| |
| 11:31 | <Vercas> Fair enough.
| |
| 11:31 | <alkisg> initramfs-tools upstream is in debian
| |
| 11:31 | <Vercas> Jesus Christ that's been reported in 2007 and we still don't have NFSv4 support.
| |
| 11:32 | <alkisg> Arguments + necessary work, are the keys to it... :)
| |
| 11:33 | <Vercas> What's worse, in my opinion, is that we don't have extended attributes in NFSv4.
| |
| 11:34 | Someone on the mailing list provided an initramfs-tools hook for NFSv4 that might work. I'll give that a go - I'd *really* like this to work so I can remove NFSv3 support and sleep well at night.
| |
| 11:35 | <alkisg> Vercas: btw doesn't nfs4 use similar rpc services like rpc.gssd and rpc.idmapd?
| |
| 11:36 | <Vercas> Those are optional.
| |
| 11:36 | <alkisg> OK
| |
| 11:36 | <Vercas> rpcbind and mountd are mandatory for NFSv3. :(
| |
| 13:24 | GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com) | |
| 13:51 | GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 264 seconds) | |
| 14:20 | woernie has left IRC (woernie!~werner@p5dded9eb.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 14:23 | GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com) | |
| 15:52 | lucas_ is now known as lucascastro | |
| 15:56 | sutula has left IRC (sutula!~sutula@184.97.13.190, Read error: No route to host) | |
| 15:57 | sutula has joined IRC (sutula!~sutula@184.97.13.190) | |
| 15:59 | lucas_ has joined IRC (lucas_!~lucascast@177-185-139-222.dynamic.isotelco.net.br) | |
| 16:02 | lucascastro has left IRC (lucascastro!~lucascast@186.193.183.161.jupiter.com.br, Ping timeout: 264 seconds) | |
| 16:55 | woernie has joined IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de) | |
| 17:11 | woernie has left IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de, Ping timeout: 264 seconds) | |
| 17:16 | woernie has joined IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de) | |
| 17:21 | woernie has left IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de, Ping timeout: 246 seconds) | |
| 17:28 | woernie has joined IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de) | |
| 17:35 | woernie has left IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de, Ping timeout: 256 seconds) | |
| 18:06 | kvaps has left IRC (kvaps!2e1c6842@wedos.wedos.net, Remote host closed the connection) | |
| 18:06 | woernie has joined IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de) | |
| 18:07 | zama has left IRC (zama!~zama@unaffiliated/stryx/x-3871776, Ping timeout: 246 seconds) | |
| 18:07 | zama has joined IRC (zama!~zama@unaffiliated/stryx/x-3871776) | |
| 18:11 | woernie has left IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de, Ping timeout: 240 seconds) | |
| 18:37 | <Vercas> alkisg: When I run `ltsp initrd` what initramfs-tools hooks does it actually run?
| |
| 18:37 | Trying to make that nfsv4 hook from the mailing list work.
| |
| 18:48 | <alkisg> Vercas: none, ltsp initrd only generates the additional ltsp.img initrd that contains the ltsp code and the passwd/group files
| |
| 18:49 | The initrd.img that ltsp uses is the stock one (except for squashfs as a dependency)
| |
| 18:49 | <Vercas> So ltsp.img is the one mounting the root filesystem?
| |
| 18:50 | <alkisg> No, the stock initrd.img has code from the initramfs-tools project that mounts the root filesystem
| |
| 18:50 | <Vercas> Hmmmmmm.
| |
| 18:50 | <alkisg> The ltsp.img has an init-bottom hook that does the loop-mount of the squashfs image, but that's after the root file system is mounted
| |
| 18:50 | <Vercas> I see.
| |
| 18:50 | <alkisg> So if you mount nfs4, ltsp will just use it without problems
| |
| 19:22 | RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Quit: Please remember your own message. It'll be read as soon as possible.) | |
| 22:55 | yanu has left IRC (yanu!~yanu@178-118-202-177.access.telenet.be, *.net *.split) | |
| 22:55 | highvoltage has left IRC (highvoltage!~highvolta@ubuntu/member/highvoltage, *.net *.split) | |
| 22:57 | yanu has joined IRC (yanu!~yanu@178-118-202-177.access.telenet.be) | |
| 22:57 | highvoltage has joined IRC (highvoltage!~highvolta@ubuntu/member/highvoltage) | |
| 23:18 | sutula has left IRC (sutula!~sutula@184.97.13.190, Read error: Connection reset by peer) | |
| 23:18 | sutula has joined IRC (sutula!~sutula@184.97.13.190) | |