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


Channel log from 16 November 2019   (all times are UTC)

01:14
<eddyTV>
alkisg: since root-path isn't really being used (there's just a comment in the dnsmasq conf file that sets it to the bogus value "ipxe-menu-item"), any reason we can't use it as the IP address of the server if it's set?
01:16
address of the NFS server, that is... I edited my ltsp.ipxe file to use nfsroot=${root-path}:/srv/ltsp (instead of ${srv}/) and it works!
01:17georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Ping timeout: 276 seconds)
01:18georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
01:23
<eddyTV>
Oh... it looks like root-path is already being used to specify the default iPXE menu choice if it's set... darn.
01:38
OK, another idea... since RFC4578 says: "All compliant PXE clients MUST include a request for DHCP options 128 through 135 in all DHCP and PXE packets. The format and contents of these options are NOT defined by the PXE specification." how about if LTSP19 defines option 128 as the server used for nfsroot server if present?
01:46
Like this: isset ${128:string} && set nfs ${128:string} || set nfs ${srv}
01:47
then, in the dnsmasq file, you just need to do something like: dhcp-option=tag:LTSP,128,"192.168.168.168"
01:48georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Ping timeout: 240 seconds)
01:48georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
01:49
<eddyTV>
(this also makes me wonder if LTSP19 shouldn't be using another of the implementation-specific PXE DHCP options for the "menu option" choice instead of root-path...)
03:19
<alkisg>
eddyTV: the main restriction there is that proxydhcp clients do not even receive root-path at all
03:19
So, the ltsp-dnsmasq.conf file was based on those restrictions, and the advice is "change ltsp.ipxe, not ltsp-dnsmasq.conf, so that it works in both cases"
03:20
So you can just edit ltsp.ipxe and change the nfsroot= line, from ${srv} to your specific IP
03:21
proxydhcp clients also do not receive any other boot options like the ones you mentioned; they only receive the server and boot filename
03:23
(and I really don't want to include code in upstream ltsp that would make things different for real vs proxy dhcp; it would be too complicated for users)
03:23jgee has left IRC (jgee!~jgee@190.159.118.121, Remote host closed the connection)
03:32
<alkisg>
One way to do what you want while keeping your ltsp.ipxe dynamic, and not "manually modified", is to put a POST_IPXE_NFS_SERVER="sed ... -i /srv/tftp/ltsp/ltsp.ipxe" command
03:34jgee has joined IRC (jgee!~jgee@190.159.118.121)
03:37
<alkisg>
This could work; note \1 isn't part of the ip: POST_IPXE_NFS_SERVER="sed 's/\(nfsroot=\)\${srv}/\1x.x.x.x/g' -i /srv/tftp/ltsp/ltsp.ipxe"
05:35kjackal has joined IRC (kjackal!~quassel@64.141.80.140)
05:55kjackal has left IRC (kjackal!~quassel@64.141.80.140, Remote host closed the connection)
07:53statler has joined IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de)
10:22adm^ltsp01 has joined IRC (adm^ltsp01!25f71ea4@37-247-30-164.customers.ownit.se)
10:22adm^ltsp01 is now known as enoch728
10:23
<enoch728>
hi, anyone else with issues while booting LTSP with PXE to mount NFS from server to clients_
10:23
?
10:23eu^195128893revs has joined IRC (eu^195128893revs!5d0880c3@195.128.8.93.rev.sfr.net)
10:23
<enoch728>
It seems like I have reached some kind of limit
10:24
I have increased ulimit and maxconn, but no change
10:24
anything else I could increase?
10:24
The server runs on VMware, and the changes are made in the Guest OS. I am starting to think that it might be due to VMware...
10:25
Any ideas are greatly appriciated
10:33
<alkisg>
Run journalctl -fe on both servers, virtual and real, while the problem happens, and check for error messages
10:34
<enoch728>
thanks, will do
10:37enoch728 has left IRC (enoch728!25f71ea4@37-247-30-164.customers.ownit.se, Remote host closed the connection)
10:38enoch8473 has joined IRC (enoch8473!25f71ea4@37-247-30-164.customers.ownit.se)
10:39
<enoch8473>
is this something to worryabout: nov 15 19:14:44 ltsp01 dnsmasq-tftp[903]: error 0 TFTP Aborted received from 192.168.2.35
10:39
??
10:39
<alkisg>
no
10:44
<enoch8473>
after setting the maxconn, would I need to reboot the server to set those values, or reimage ltsp?
10:44
pr should it be effective immediately?
10:44
<alkisg>
Which maxconn did you set and where?
10:46
<enoch8473>
#TCP limitsnet.ipv4.tcp_max_syn_backlog = 100000net.core.somaxconn = 100000net.core.netdev_max_backlog = 100000
10:47
in /etc/sysctl.conf
10:47
<alkisg>
I don't think it's a tcp limit; maybe an nfs or file system limit
10:47
<enoch8473>
hmm
11:06
I found this command, I din't know if it's saying you anything alkisg? https://pastebin.com/1ui8SVHw
11:06
<alkisg>
So nothing in journalctl -fe when you boot the 15th client?
11:09
<enoch8473>
I'm not at the location now and I'm only having 10 clients in epotes, I had 12 yesterday
11:09
maybe a restrat of epotes may help btw
11:09
will try
11:09
restart*
11:10
nope still only 10
11:10
but no, I couldn't find any logs out of the ordinary other than the tftp stuff
11:18enoch8473 has left IRC (enoch8473!25f71ea4@37-247-30-164.customers.ownit.se, Ping timeout: 260 seconds)
11:20eu^195128893revs has left IRC (eu^195128893revs!5d0880c3@195.128.8.93.rev.sfr.net, Remote host closed the connection)
11:41enochfreenode has joined IRC (enochfreenode!25f71ea4@37-247-30-164.customers.ownit.se)
11:41
<enochfreenode>
alkisgsorry my vpn died
11:41
anyway, increased the number of threads in nfs: https://lists.ubuntu.com/archives/edubuntu-users/2007-September/002213.html
11:41
it was 8, now it's 128
11:41
I will go to the office today and see if it worked
11:43
well, now I found this: https://www.raspberrypi.org/forums/viewtopic.php?t=216621
11:43* enochfreenode is reading
11:47
<enochfreenode>
will try the latest fix, let's hope it's working
11:47
https://www.raspberrypi.org/forums/viewtopic.php?p=1386161&sid=b4a546a6e394ced9adb2b23e6ae2ff1d#p1386161
12:03enochfreenode has left IRC (enochfreenode!25f71ea4@37-247-30-164.customers.ownit.se, Remote host closed the connection)
13:40shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer)
13:40shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi)
14:10
<eddyTV>
alkisg: thanks for the explanation. It makes sense now why you want to adjust ltsp.ipxe instead of ltsp-dnsmasq.conf. Thanks for pointing out the POST_IPXE option... that worked perfectly.
14:16
I'm running in to another problem now... I've created an image, and set the password for the root user and my own user in the container where I run ltsp initrd. But after the client boots, when I try to login, for root I get "User root can't auth via pamltsp" and mine I get "read: connection reset by peer" / ".Login incorrect."
14:38
<alkisg>
eddyTV: go to http://irclogs.ltsp.org/ , view source, and check your last sentence
14:38
It's full of invalid unicode chars, [0011]ltsp initrd[0011] etc
14:38
What are those, due to matrix?
14:39
eddyTV: to preserve the root password, you need the PWMERGE options
14:39
Or, you can use a POST_INIT command to dynamically set a root password, without even having one in the chroot
14:40
man ltsp.conf => search for POST_INIT_SET_ROOT_HASH
14:41
<uumas>
alkisg: eddyTV doesn't seem to be a Matrix user and those are invalid in Matrix too.
14:42
<eddyTV>
I'm guessing it's my client. It's supposed to be "monospaced"... according to https://modern.ircdocs.horse/formatting.html, ASCII 0x11: This formatting character works as a toggle. It enables monospace’d text (e.g. monospace text).
14:42
<alkisg>
Which client?
14:42
I don't think IRC supports formatting
14:43
<eddyTV>
Textual. I didn't realize monospace wasn't well-implemented. I'll avoid it.
15:11
Hrmmm... still no joy after adding POST_INIT_SET_ROOT_HASH in the [clients] section of my ltsp.conf (and re-running "ltsp initrd" of course) ... still get "can't auth via pamltsp".
15:12kjackal has joined IRC (kjackal!~quassel@64.141.80.140)
15:13
<alkisg>
eddyTV: PM me that POST_INIT_SET line
15:13
Did you use the $(cat) trick, to avoid escaping problems?
15:14
<eddyTV>
Yes... I copied the example and just changed the hash
15:15
<alkisg>
eddyTV: hmm, if you used `man ltsp.conf`, it might have invalid string chars there
15:15
sed ´s|^ ==> should use '
15:16
Something wrong in ronn conversion of md to man there
15:17
<eddyTV>
Good catch.
15:17
It works now.
15:17
Didn't even notice that. :)
15:20
<alkisg>
Currently I support [init/] or [init/mac-address] sections, to run code
15:20
I should change those to [pre_init*] and [post_init*]; it would make it so much easier to run code like that hash, without $(cat) or any tricks
15:22
<eddyTV>
That sounds good to me, although I thought the heredoc trick was a good one to avoid escaping $
15:22
Speaking of man pages, I noticed that whatever is doing the conversion from .md to HTML is converting "--" into em-dashes... https://ltsp.github.io/man/ltsp-image/
15:23
So it shows up as "–cleanup" instead of "--cleanup"
15:25
<alkisg>
Ouch
15:25
I'll have a look
15:39kjackal has left IRC (kjackal!~quassel@64.141.80.140, Ping timeout: 265 seconds)
15:40kjackal has joined IRC (kjackal!~quassel@64.141.80.139)
15:40shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer)
15:40shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi)
15:47kjackal has left IRC (kjackal!~quassel@64.141.80.139, Ping timeout: 265 seconds)
17:05
<eddyTV>
Any recommendations on generating and then preserving /etc/ssh/ssh_host_rsa_key for each client?
18:00eddyTV has left IRC (eddyTV!~eddyTV@2601:402:4500:4670:1d91:964:85ca:368e, Ping timeout: 276 seconds)
18:04eddyTV has joined IRC (eddyTV!~eddyTV@2601:402:4500:4670:a9d7:f850:f4f0:688a)
18:06
<alkisg>
eddyTV: well you can put them in /etc/ltsp/* and copy or symlink them via a POST_INIT* command
18:08
To generate some of them, just delete those files and run dpkg-reconfigure openssh-server, then preserve the result...
18:08
In general though it's not very wise to have private keys sent via public images...
18:10
<eddyTV>
Right. That's why I was wondering what others were doing. In general, for my personal use case I'm not concerned about doing it that way, but was curious what the "better" way to do it is.
18:10
<alkisg>
For example, epoptes-client connects to the server securely. It's the server that has the private key
18:11
Or, sshfs is secure; again, the server has the private key; the client gets the user password to connect ;etc
18:11
So the idea is to keep the private things on the server
18:13
<eddyTV>
Gotcha. That makes sense. An example of dealing with ssh hosts keys via sshfs would be a good wiki page.
18:14
<alkisg>
You can't have trusted sshfs before login
18:14
It's the user password that puts trust to the client
18:14
<eddyTV>
Hmmm. I see what you mean.
18:19
On an unrelated topic, I still can't login as a non-root user on a client. I've added a "PASSWORDS_1=test/dGVzdAo" to ltsp.conf and I can see "pamltsp=dGVzdAo" in /etc/shadow on the client (when I login as root), but I can't login as user "test" (I get ".Login incorrect.")
18:20
<alkisg>
echo dGVzdAo | base64 -d
18:20
<eddyTV>
(oops, missed the = at the end of that base64 wehn O copy/pasted)
18:20
<alkisg>
base64: invalid input
18:20
ah ok
18:21
eddyTV: and ssh test@server, with pass=test, works?
18:22
<eddyTV>
Doesn't work via ssh either
18:23
<alkisg>
Then how would ltsp ssh to the server?
18:23
LTSP relies on ssh for authentication
18:23
If you tell it to use user=test, pass=test, those are supposed to map to an existing account
18:23
<eddyTV>
I must be missing something then. I want "test" to be a local user?
18:24
<alkisg>
Ah, then you don't want sshfs
18:24
And no ssh authentication
18:24
That appears as pamltsp= in shadow, without an entry there
18:24
PASSWORDS_USER="test/"
18:25
And obviously it would only work with nfs or local /home
18:25
<eddyTV>
Right. Will autologin still be able to work?
18:25
<alkisg>
Sure
18:31
<uumas>
alkisg: I was thinking, I could create a chroot for the client image but not install the ltsp package as I'll be using ldap auth + nfs homedirs anyway, right?
18:32
<alkisg>
uumas, er, you need ltsp to prepare the client for netbooting, working around all the netbooting issues, parsing and executing ltsp.conf parametesr,
18:32
but, you'll get it anyway from the server ... so....
18:32
(the client code goes to the client via ltsp.img initrd)
18:32
<uumas>
so... maybe?
18:33
<alkisg>
You do not need to install the ltsp package in the chroot, but you'll get the ltsp code from the server, and it'll work, unless you're missing e.g. the squashfs or overlay modules in the initramfs, in which case you can put them in /etc/modules
18:33
But why you don't want it?
18:33
It'll just save you RAM
18:35
I spend days and days to make it so light that it can be installed even in a plain `debootstrap` chroot without any significant dependencies
18:36
And, if it's loaded from within the squashfs, it saves RAM, as opposed to getting copied from the server
18:37
<uumas>
Well, I was just thinking, would that make it not necessary to disable the 54-pam config?
18:37
Or would that still get loaded from the server?
18:37
<alkisg>
The second :)
18:38
If you didn't have ltsp, you wouldn't have netbooting
18:38
<uumas>
So no real benefit there. Ok.
18:38
<alkisg>
No overlay, no squashfs mounting, nothing
18:38
I should put a real option to avoid 54-pam...
18:38
in ltsp.conf
19:08
<eddyTV>
Is the output from the script generated from ltsp.conf logged anywhere?
19:08
(when it gets run on client boot)
19:13
<alkisg>
Only the important parts, go to /run/ltsp/debug.log
19:21
<eddyTV>
Cool. Out of curiosity, what's the deal with disabling flow control? (looks like I forgot to put ethtool in my chroot...)
19:21
<alkisg>
!flow
19:21
<ltspbot>
I do not know about 'flow', but I do know about these similar topics: 'flow-control'
19:21
<ltsp`>
I do not know about 'flow', but I do know about these similar topics: 'flow-control'
19:22
<alkisg>
!flow-control
19:22
<ltspbot>
flow-control: https://help.ubuntu.com/community/UbuntuLTSP/FlowControl
19:22
<ltsp`>
flow-control: https://help.ubuntu.com/community/UbuntuLTSP/FlowControl
19:23
<eddyTV>
So it's only an issue with mixed-speed networks?
19:24
<alkisg>
Yes, even for one client or one intermediate switch
19:35
<uumas>
What's the deal with there being ltsp` and ltspbot
19:41
<alkisg>
Old server, new server
19:41
Old will be deprecated when the domain transfer is complete
19:48
<eddyTV>
Is there a "supported" way to add options to ltsp.ipxe's kernel cmdline, or should I add a sed line to modify the cmdline_ltsp definition?
19:49
(I want to add "quiet splash" to show a splash screen instead of all the kernel stuff)
20:50statler has left IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de, Remote host closed the connection)
20:56kjackal has joined IRC (kjackal!~quassel@64.141.80.140)
21:03jinnjus has joined IRC (jinnjus!~jinnjus@24.244.23.74)
21:27jinnjus has left IRC (jinnjus!~jinnjus@24.244.23.74, Read error: Connection reset by peer)
22:09kjackal has left IRC (kjackal!~quassel@64.141.80.140, Remote host closed the connection)
22:23kjackal has joined IRC (kjackal!~quassel@64.141.80.140)