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:17 | georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Ping timeout: 276 seconds) | |
01:18 | georgeneophytou 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:48 | georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Ping timeout: 240 seconds) | |
01:48 | georgeneophytou 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:23 | jgee 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:34 | jgee 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:35 | kjackal has joined IRC (kjackal!~quassel@64.141.80.140) | |
05:55 | kjackal has left IRC (kjackal!~quassel@64.141.80.140, Remote host closed the connection) | |
07:53 | statler has joined IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de) | |
10:22 | adm^ltsp01 has joined IRC (adm^ltsp01!25f71ea4@37-247-30-164.customers.ownit.se) | |
10:22 | adm^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:23 | eu^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:37 | enoch728 has left IRC (enoch728!25f71ea4@37-247-30-164.customers.ownit.se, Remote host closed the connection) | |
10:38 | enoch8473 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:18 | enoch8473 has left IRC (enoch8473!25f71ea4@37-247-30-164.customers.ownit.se, Ping timeout: 260 seconds) | |
11:20 | eu^195128893revs has left IRC (eu^195128893revs!5d0880c3@195.128.8.93.rev.sfr.net, Remote host closed the connection) | |
11:41 | enochfreenode 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:03 | enochfreenode has left IRC (enochfreenode!25f71ea4@37-247-30-164.customers.ownit.se, Remote host closed the connection) | |
13:40 | shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer) | |
13:40 | shored 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:12 | kjackal 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:39 | kjackal has left IRC (kjackal!~quassel@64.141.80.140, Ping timeout: 265 seconds) | |
15:40 | kjackal has joined IRC (kjackal!~quassel@64.141.80.139) | |
15:40 | shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer) | |
15:40 | shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi) | |
15:47 | kjackal 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:00 | eddyTV has left IRC (eddyTV!~eddyTV@2601:402:4500:4670:1d91:964:85ca:368e, Ping timeout: 276 seconds) | |
18:04 | eddyTV 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:50 | statler has left IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de, Remote host closed the connection) | |
20:56 | kjackal has joined IRC (kjackal!~quassel@64.141.80.140) | |
21:03 | jinnjus has joined IRC (jinnjus!~jinnjus@24.244.23.74) | |
21:27 | jinnjus has left IRC (jinnjus!~jinnjus@24.244.23.74, Read error: Connection reset by peer) | |
22:09 | kjackal has left IRC (kjackal!~quassel@64.141.80.140, Remote host closed the connection) | |
22:23 | kjackal has joined IRC (kjackal!~quassel@64.141.80.140) | |