IRC chat logs for #ltsp on irc.libera.chat (webchat)


Channel log from 4 August 2020   (all times are UTC)

05:08sutula has left IRC (sutula!~sutula@184.97.13.190, Ping timeout: 264 seconds)
05:09sutula has joined IRC (sutula!~sutula@184.97.13.190)
05:28woernie has joined IRC (woernie!~werner@p5dded9eb.dip0.t-ipconnect.de)
06:45RaphGro 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:18kvaps 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:24GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com)
13:51GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 264 seconds)
14:20woernie has left IRC (woernie!~werner@p5dded9eb.dip0.t-ipconnect.de, Remote host closed the connection)
14:23GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com)
15:52lucas_ is now known as lucascastro
15:56sutula has left IRC (sutula!~sutula@184.97.13.190, Read error: No route to host)
15:57sutula has joined IRC (sutula!~sutula@184.97.13.190)
15:59lucas_ has joined IRC (lucas_!~lucascast@177-185-139-222.dynamic.isotelco.net.br)
16:02lucascastro has left IRC (lucascastro!~lucascast@186.193.183.161.jupiter.com.br, Ping timeout: 264 seconds)
16:55woernie has joined IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de)
17:11woernie has left IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de, Ping timeout: 264 seconds)
17:16woernie has joined IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de)
17:21woernie has left IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de, Ping timeout: 246 seconds)
17:28woernie has joined IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de)
17:35woernie has left IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de, Ping timeout: 256 seconds)
18:06kvaps has left IRC (kvaps!2e1c6842@wedos.wedos.net, Remote host closed the connection)
18:06woernie has joined IRC (woernie!~werner@x4d03b0dd.dyn.telefonica.de)
18:07zama has left IRC (zama!~zama@unaffiliated/stryx/x-3871776, Ping timeout: 246 seconds)
18:07zama has joined IRC (zama!~zama@unaffiliated/stryx/x-3871776)
18:11woernie 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:22RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Quit: Please remember your own message. It'll be read as soon as possible.)
22:55yanu has left IRC (yanu!~yanu@178-118-202-177.access.telenet.be, *.net *.split)
22:55highvoltage has left IRC (highvoltage!~highvolta@ubuntu/member/highvoltage, *.net *.split)
22:57yanu has joined IRC (yanu!~yanu@178-118-202-177.access.telenet.be)
22:57highvoltage has joined IRC (highvoltage!~highvolta@ubuntu/member/highvoltage)
23:18sutula has left IRC (sutula!~sutula@184.97.13.190, Read error: Connection reset by peer)
23:18sutula has joined IRC (sutula!~sutula@184.97.13.190)