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


Channel log from 26 September 2021   (all times are UTC)

02:44vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100b, Quit: leaving)
09:02ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
12:04lucascastro has left IRC (lucascastro!~lucascast@177-185-130-122.dynamic.isotelco.net.br, Ping timeout: 252 seconds)
12:05woernie has joined IRC (woernie!~werner@2001:9e8:e25c:2a00:acd7:3003:a217:1742)
12:09woernie has left IRC (woernie!~werner@2001:9e8:e25c:2a00:acd7:3003:a217:1742, Client Quit)
14:29superdad has joined IRC (superdad!~wrender@cpe7824af7d7910-cmf0f249403bc0.cpe.net.cable.rogers.com)
14:37
<superdad>
hi, so here is what we are looking to do: in an air-gapped environment, I have a bunch of servers with no hard disks. Some virtual machines that do have hard disks. I want to ipxe boot ubuntu 20.04 (minimal version with no gui if possible) into memory. I'm open to using NFS for initial boot, but we need it so that if our NFS server goes offline, the servers filesystem and OS still runs fine out of memory. Right
14:37
on what value LTSP adds, is the server portion needed?, how I would install that in an airgapped. I think we would want to use the chroot like this: https://github.com/ltsp/ltsp/wiki/chroots but I'm confused on how that would be able to load the entire filesystem into ram. When I tested it it seemed to be dependant on the NFS server being up at all times.
14:37fottsia[m] has joined IRC (fottsia[m]!~fottsiama@2001:470:69fc:105::48bb)
14:45
<alkisg>
You need to install ltsp to create the additional initrd, ltsp.img, that contains the netbooting code
14:45
so "some" server is needed
14:47
Then that same ltsp.img can netboot any image
14:48
No nfs server is needed if you use IMAGE_TO_RAM ltsp.conf parametr
14:49
Then plain http can be used
14:50
<superdad>
OK. We have a SAN that does NFS/HTTP. And dedicated hardware that does DHCP/DNS/TFTP
14:51
So the IMAGE_TO_RAM would allow booting over HTTP, and then if the HTTP/NFS SAN goes down the servers are all running in memory filesystem?
14:54
<alkisg>
Yes
14:54
You can do that either with nfs or http
14:54
It will load the initial image, then keep it in ram
14:55
<superdad>
ok. fantastic
14:55
I'm just setting up a test vm for ltsp right now.
15:04
So I need all of these on the server from the LTSP PPA? apt install --install-recommends ltsp ltsp-binaries dnsmasq nfs-kernel-server openssh-server squashfs-tools ethtool net-tools epoptes
15:19
<alkisg>
No, probably just ltsp, binaries and squashfs-tools
15:19
<superdad>
Ok. THanks. I'm just looking at where to put the IMAGE_TO_RAM setting now
15:19
<alkisg>
!ltsp.conf
15:19
<ltspbot>
ltsp.conf: Configuration file for LTSP: https://ltsp.org/man/ltsp.conf/
15:20
<superdad>
Thanks, just put it in client section
15:21
So I used debootstrap to go to /srv/ltsp/focal
15:21
So then I can just run "ltsp image focal"
15:21
and ltsp ipxe, and then ltsp initrd?
15:21
<alkisg>
chroot focal apt install ltsp
15:22
At a minimum, you need the squashfs module
15:22
It's not there in debootstrap, it's there in cloud images and cds
15:22
ltsp installs it
15:22
<superdad>
I did all of the commands here: https://github.com/ltsp/ltsp/wiki/chroots Except for the xfce4 , since we don't want gui
15:23
So in my chroot at /srv/ltsp/focal I did : apt install --install-recommends ltsp
15:23
<alkisg>
No
15:23
Ah ok
15:23
But no servers needed inside the chroot, ok
15:24
<superdad>
Right no, ltsp server components you mean?
15:24
Just the ltsp client package?
15:24
<alkisg>
Yes, no dnsmasq, no ssh-server etc
15:24
Yes, just a tiny client package is enough
15:24
And livecd/client images don't even need that at all
15:25
You can also just manually put the squashfs module in the initramfs if you prefer, but ltsp does that automatically, so why bother
15:25
<superdad>
yup. my chroot /srv/ltsp/focal is just minbase, with the ltsp, linux-generic, initramfs-tools
15:25
<alkisg>
You did install a kernel in the chroot, right?
15:25
OK
15:25
Sounds good
15:25
<superdad>
So now I do ltsp image focal?
15:25
<alkisg>
So now it should be bootable over nfs or http, with IMAGE_TO_RAM support
15:25
<superdad>
To generate the image?
15:26
<alkisg>
Yes
15:26
<superdad>
ok, and then ltsp ipxe to generate the ipxe files?
15:26
<alkisg>
Then, since you don't want the ltsp server to also be proxydhcp, you'll need to configure your main dhcp server
15:26
(or do you? want the ltsp server to be proxydhcp, which is easier?)
15:27
LTSP needs two initrds, the main and the extra ltsp.img, where the magic happens
15:27
<superdad>
hmmm. good question
15:27
<alkisg>
So the usual server configuration now needs a couple of extra directives
15:27
<superdad>
I don't think we would want to proxy through this
15:27
<alkisg>
Do you know what a proxydhcp is? The name is a bit misleading
15:27
It just provides the boot filename, it doesn't proxy the requests elsewhere...
15:28
If you're in test mode, just install dnsmasq and put the client in an internal subnet for now
15:28
It'll make your test faster
15:28
<superdad>
oh, no i don't know what it does. I just don't want to mess with dhcp on the network and have the infra guys kill me
15:28
<alkisg>
So, ltsp server ip = 192.168.67.1, ltsp client = internal subnet, install dnsmasq, and run `ltsp dnsmasq` and `ltsp ipxe`, and it will work
15:29
E.g. if your ltsp server is a VM, you can put 2 NICs on it, an internet-facing one, and an internal one
15:29
<superdad>
hmmm
15:30
Ok. So you are saying I need to add another nic to my ubuntu ltsp server?
15:30
<alkisg>
There are many many methods
15:30
I don't know your setup. In SOME cases, that MIGHT be faster
15:30
If you provide more information, I can help better
15:30
E.g. "is your ltsp server a VM"?
15:30
Do your clients already have ipxe on them?
15:30
<superdad>
Well, i'm just at my home test setup right now
15:31
Not at the office
15:31
<alkisg>
Are the clients a VM? etc etc
15:31
So you have a typical home router, right? Then just go for proxy mode
15:31
<superdad>
Ya, So I have a dhcp/tftp server already setup. With dhcp option to point to the
15:31
<alkisg>
I.e. the default, just install dnsmasq and run ltsp ipxe
15:31
Where do you have the dhcp server?
15:31
On the ltsp server?
15:31
<superdad>
So I already have a full ipxe boot environment chain loading the ipxe working fine...
15:31
no. on a seperate server
15:32
<alkisg>
isc-dhcp or dnsmasq?
15:32
<superdad>
dnsmasq on my router which is just an asus ac68u with merlin firmware
15:33
<alkisg>
Do you have access to a dnsmasq.conf?
15:33
<superdad>
Ya, on my router I can edit DNSmasq. I already had to do that to setup my ipxe boot
15:33
<alkisg>
Yes but not to send the second ltsp.img
15:34
<superdad>
oh. One sec, let me send you what I have on my router
15:34
dhcp-boot=undionly.kpxe,ubuntu-server,192.168.1.142
15:34
<alkisg>
Here's what a typical "external dnsmasq" looks like: https://github.com/ltsp/ltsp/discussions/529#discussioncomment-1336771
15:35
Nah, read mine instead :)
15:35
It contains support for bios, uefi, rpi, everything and the kitchen sink
15:35
<superdad>
Then on my ubuntu-server at 192.168.1.142, I have the undionly-kpxe file that I am chainloading
15:35
<alkisg>
And it loads the second ltsp.img as well
15:35
OK so at the end of the day you need to make the client load ltsp.ipxe, the ipxe script at /srv/tftp/ltsp/ltsp.ipxe
15:35
<superdad>
Ok. Interesting
15:35
<alkisg>
If you do that, you're good to go
15:36
<superdad>
The only problem is, in my production environment I have Infoblox DHCP/TFTP that I need to work with
15:36
<alkisg>
If you disable the boot options in your router, then ltsp dnsmasq takes care of that for you, via the proxydhcp protocol
15:36
That link that I sent you is for infoblox
15:36
Give it a read; back in 20'...
15:36
<superdad>
ok. great ok
15:38
I'm a little confused on what exact options I need right now on my router's dhcp
15:39
<alkisg>
Then disable all boot options and let ltsp take care of netbooting
15:39
By using proxydhcp
15:40
Or read that file/link, it should work immediately
15:40
<superdad>
I'm just looking through it now. Would be good to have my home test setup similar to the infoblox at office, so that I can learn how it works
15:51
be back shortly. Thanks for all the help so far!
15:59
so to keep things simple. If I run "ltsp dnsmasq"
15:59
Then what do I setup on my router's dnsmasq to properly ipxe boot these images?
16:00KeerthiS[m] has left IRC (KeerthiS[m]!~keerthiva@2001:470:69fc:105::e344, Quit: You have been kicked for being idle)
16:01
<alkisg>
You need to remove all dhcp-boot and pxe-service directives
16:02
I.e. all netbooting related ones
16:02
No boot filename, nothing
16:24
<superdad>
How would the servers know where to ipxe boot from then?
16:27
<alkisg>
Client requests IP, router sends IP, ltsp server sends boot filename (=proxy)
16:27
That's the meaning of proxydhcp
16:28
<superdad>
ahh, ok. so the proxydhcp is responds to the initial dhcp request?
16:28
<alkisg>
Yes
16:28
<superdad>
nat
16:28
neat
16:30
Is it possible to boot this stuff using my own TFTP, and HTTP server though?
16:30
Without using the ltsp server ?
16:31
<alkisg>
Yes, read the initial link that I sent you
16:31
You'd just copy ltsp.img in that case, the additional netbooting code that needs to be injected
16:32
<superdad>
Sorry what link was that?
16:32
<alkisg>
I think you should first try the easiest way to do it, THEN move on to all the restrictiions and harder ways. Now you lack some knowledge and you don't see how to more easily do your end goal
16:32
The one with ltsp discussions and dnsmasq.conf for infoblox (or any other external dnsmasq)
16:34
<superdad>
Ok. I'll go ahead and try the easy way then
16:36
So I removed the boot entries from the dnsmasq config on my router
16:36
And then pxe booted a test virtualbox vm
16:36
And I can see "focal.img and focal" as the menu options
16:37
But when I select one it just says "could not select: Exect format error"
16:37
and Could not boot image: Exect format error
16:40
<alkisg>
This either means "bad ipxe, with no bzimage support, e.g. from qemu/virtualbox", or "32bit client trying to boot a 64bit image"
16:41
<superdad>
I think maybe for this reason, I had to chain load ipxe before to get it working
16:42
<alkisg>
If you describe your setup better, we'll help you more easily.
16:42
For virtualbox, use ipxe.iso, it's better/faster
16:42
<superdad>
In my home test environment I just have windows 10 with Virtualbox 6.1
16:43
At work. vsphere, esxi, and also Cisco UCS hosts
16:43
<alkisg>
At home, yeah download ipxe.iso and boot from that one
16:47
<superdad>
Just boot it from the virtual cd drive?
16:49
ok. that worked thanks
16:50
It seems to hang at NFS over TCP not avaialble from 192.168.1.226 (my ltsp server)
16:52
says right before that error. /init: line 235: dhclient: not found
16:53
Just tryint to re-go through these steps: https://github.com/ltsp/ltsp/wiki/chroots
16:56
<alkisg>
The default steps need an nfs server
16:56
While then you can move on and download the image over http
16:58
<superdad>
hmmm. I thought I enabled the nfs server
16:58
I ran "ltsp nfs"
16:58
<alkisg>
apt install nfs-server; ltsp nfs
16:58
And was it succeful?
16:59
<superdad>
ya, says nfs server was already installed
17:00
maybe i caused a problem when I ran debootstrap with --varient=minbase ?
17:00
I just re-did that without minbase
17:01
worked now!
17:03
Strange, I can't seem to login with the root passwd I set in the chroot
17:05
But everything else seems to boot the os correctly
17:05
<alkisg>
ltsp has a cleanup phase
17:05
It erases sensitive things like passwords
17:05
!hash
17:05
<ltspbot>
I do not know about 'hash', but I do know about these similar topics: 'LDM_PASSWORD_HASH', 'ROOT_PASSWORD_HASH'
17:06
<superdad>
ahhh, that explains it thanks!
17:06
<alkisg>
!ROOT_PASSWORD_HASH
17:06
<ltspbot>
ROOT_PASSWORD_HASH: To be able to login as root in vt1, with password "qwer1234", put this in lts.conf: INIT_COMMAND_ROOT_HASH="sed 's!^root:[^:]*:!root:\$6\$p2LdWE6j\$PDd1TUzGvvIkj9SE8wbw1gA/MD66tHHlStqi1.qyv860oK47UnKcafSKqGp7cbgZUPlgyPv6giCVyCSCdJt1b0:!' -i /etc/shadow"
17:06
<alkisg>
Wait this needs fixing
17:07
!forget ROOT_PASSWORD_HASH
17:07
<ltspbot>
The operation succeeded.
17:07
<alkisg>
!learn ROOT_PASSWORD_HASH as To be able to login as root in vt1, read the last example in https://ltsp.org/man/ltsp.conf/
17:07
<ltspbot>
The operation succeeded.
17:12
<superdad>
hmm. I added that, can't seem to login still with qwer1234
17:13vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100b)
17:15stappers has joined IRC (stappers!~stappers@gpm.stappers.nl)
17:20
<superdad>
think I was missing running: ltsp initrd after modifying /etc/ltsp/ltsp.conf
17:22
hmmm. still can't set the root password for some reason
17:26
<alkisg>
Maybe the help page is wrong, try to set your own hash
17:28
<vagrantc>
yeah, remembering to run "ltsp initrd" has often been my pitfall lately :)
17:34
<superdad>
Ok. Ya, alkisg, looks like the documentation has a mistake
17:34
I can do a pull request to fix it?
17:35
So my diskless server booted great, see everything running in ram
17:36
<alkisg>
Sure you can do a PR
17:36
<superdad>
I'll have to try and think of how this will integrate at work with infoblox, and nfsserver
17:42* alkisg waves to vagrantc
17:43
<alkisg>
Although in this case its' the man page that's wrong
17:43
I think it maps to a different password, not to qwer1234
17:46* vagrantc waves back at alkisg
18:46
<superdad>
oh. in that case ignore my pull request
18:47
So now that I have this booting using the ltsp server. How would I go about booting this over HTTP at the office?
18:50
so would want the infoblox to initiate the ipxe boot, and then it would go to an Dell EMC based nfs server.
18:51
Also, any way to install ltsp offline/air gapped?
19:02
<alkisg>
superdad: you can install any debian package by running `apt install package --print-uris`; it will give you a list of .deb package URLs; then you can download them from elsewhere, and put them in /var/cache/apt/archives
19:03
I didn't understand the http/nfs question though; if it's an nfs server, why do you want http?
19:03
<superdad>
Ok. I think I can use apt-mirror to create offline
19:03
Sorry, one one setup, I have an NFS server avail, on another I can only do over HTTP
19:05
<alkisg>
For http-only, you'd need to read this PR: https://github.com/ltsp/ltsp/issues/75
19:05
kvaps there has similar needs to yours; the PR wasn't merged, I postponed it in order to implement it more cleanly, but you can still use it
19:06
<superdad>
Just taking a look
19:06
<alkisg>
So, the reason I proposed LTSP is that you can inject code in the initramfs. You now have a way to add a "wget" call in the appropriate place, without even remastering an iso or a squashfs
19:06
It's very very flexible
19:07
You put your code in ltsp, it then puts it in ltsp.img and it gets to the client as the additional initrd
19:07
So even if the cloud images don't have netbooting code, you can use ltsp to netboot them
19:07
<superdad>
Well, I don't think I need to use the cloud images
19:07
<alkisg>
You don't :)
19:08
(if I understood your use case correctly :))
19:08
<superdad>
So how would i go about serving the image files, off of our custom http server
19:08
And ipxe booting those using the Infoblox
19:08
<alkisg>
Read the PR, its' the exact use case
19:09
An http in dnsmasq and a wget in ltsp.img is all that's needed
19:09
wget is already available in the initrd, it's an applet of "busybox"
19:10
<superdad>
But this is doing it on the ltsp server?
19:10
<alkisg>
wget can target any IP
19:10
The only reason that you'll have an "ltsp server" is to run ltsp initrd and create ltsp.img
19:10
It won't be serving anything...
19:11
(and maybe ltsp image, if you want to maintain the chroots on the ltsp server)
19:11
<superdad>
Ok. Right. Yes, I think we only want to maintain the chroots, which will probably be automated with jenkins
19:12
Just trying to get my head around the steps
19:14
So we already have our own undionly.kpxe and snponly.efi that goes to an ipxe boot file over http. And it gets the menu for CentOS 7, CoreOS and other operating systems.
19:15
Is it possible for me to take the ipxe code from /srv/tftp/ltsp/ltsp.ipxe that is booting the images, and adapt that into our menu?
19:25
<vagrantc>
alkisg: did you have troubles with multiple initrds with pxelinux ? i know you switched to ipxe eventually
19:26
the syntax apparently accepts them as initrd first.img,second.img ... and it seems to work ... but not hugely reliably
19:32
<superdad>
@alkisg. I think I answered my question. I just tested setting up my routers/dnsmasq, and my own custom http server/nfs server. And then chainloaded this in: https://pastebin.com/vsBSN0a5
19:32
works like charm!
19:33
So ya, I see the ltsp.img initrd is doing the heavy lifting.
19:36
<vagrantc>
alkisg: as in ... sometimes the initrd just isn't read at all ...
19:42
<alkisg>
Back, reading...
19:42
> Is it possible for me to take the ipxe code from /srv/tftp/ltsp/ltsp.ipxe that is booting the images, and adapt that into our menu? ==> sure, once you see how ltsp works, you can reproduce it elsewhere
19:43
> did you have troubles with multiple initrds with pxelinux ? i know you switched to ipxe eventually ==> no the main issue was uefi support (pxelinux had many issues there), and configuration abilities (ipxe has a scripting language)
19:43
> as in ... sometimes the initrd just isn't read at all ... ==> vagrantc : nah I didn't have any issues with initrd not getting read
19:44
Where are you seeing this, BIOS, UEFI, PC, uboot... ?
19:47
Aaah you meant if I had problems with pxelinux itself, not with ipxe
19:47
I haven't tested multiple initrds in pxelinux a lot, as I stopped using it when it failed to boot with many uefi scenarios
19:47
<vagrantc>
alkisg: yes ... in this case i'm trying to load ltsp from syslinux for ... reasons
19:48
<alkisg>
I wouldn't mind having an `ltsp syslinux` applet :)
19:48
<vagrantc>
mostly for BIOS clients (for uefi, we're just using ipxe) ... and mostly tested using virtual machines using qemu+ipxe
19:48
<alkisg>
There are few cases where ipxe doesn't work with the internal PXE stack, while syslinux does work; in those cases currently we're chainloading ipxe.pxe over undionly.kpxe
19:49
<vagrantc>
but the real-world deployment would be on real hardware, of course :)
19:49
i wonder if the answer will be to switch to ipxe for all cases ... which is maybe doable
19:49
<alkisg>
Note that the ipxe that is included in vbox is missing a lot of features, so if you go qemu > ipxe > pxeilnux, it might break due to the ipxe code...
19:49
<vagrantc>
was trying to keep old-style LTSP environments concurrent with new-style ones and minimizing the differences
19:50
<alkisg>
They limit things to reduce the size so that it's embeddable in ROMs
19:50
<vagrantc>
i haven't touched virtualbox in over a decade :)
19:50* alkisg did that too for a few months, then completely dropped old-style ltsp
19:51
<vagrantc>
basically trying to maintain 3 or 4 concurrent LTSP generations in one environment :/
19:51
<alkisg>
I mean, I do know this is a problem with vbox, so maybe it's a similar problem with qemu too, but I haven't tested qemu a lot so I don't know for sure
19:51
Hehe, 3-4 generations would be ... 10+ years! :D
19:52
<vagrantc>
oh, this goes all the way back :)
19:52
it's "fun" trying to figure out how to do this well
19:52
<alkisg>
What was the first name again?
19:52
<vagrantc>
?
19:53
<alkisg>
lessdisk or something?
19:53
The one you were using before ltsp
19:53
<vagrantc>
hah, yeah, lessdisks was my earlier project ... this doesn't go *that* far back
19:53
<alkisg>
(and developing)
19:54
<vagrantc>
i stopped working on lessdisks ~2005, when i switched to working on ltsp
19:57
<alkisg>
Last weekend at the sea for this ...summer :) A wonderful but also tiring day; going to bed early, good night all!
19:58* vagrantc waves
20:56ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:40
<superdad>
Thanks for all the help @alkisg. So great to have all this stuff loading into memory with ltsp.