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


Channel log from 27 January 2020   (all times are UTC)

00:01GodFather has joined IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net)
00:15GodFather has left IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net, Ping timeout: 265 seconds)
00:44GodFather has joined IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net)
01:47GodFather has left IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net, Ping timeout: 268 seconds)
02:20GodFather has joined IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net)
06:01statler has joined IRC (statler!~Georg@p5B30E4C3.dip0.t-ipconnect.de)
06:35woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de)
07:01woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection)
07:41statler has left IRC (statler!~Georg@p5B30E4C3.dip0.t-ipconnect.de, Remote host closed the connection)
08:23pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, *.net *.split)
08:36pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
09:03woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de)
09:22statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
11:38section1 has joined IRC (section1!~section1@178.33.109.106)
11:51Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:20lucascastro has joined IRC (lucascastro!~lucascast@131.255.227.138)
12:23lucascastro has left IRC (lucascastro!~lucascast@131.255.227.138, Client Quit)
12:30shored has left IRC (shored!~shored@87-92-77-163.bb.dnainternet.fi, Read error: Connection reset by peer)
12:30shored has joined IRC (shored!~shored@87-92-77-163.bb.dnainternet.fi)
13:47eu^1128107124 has joined IRC (eu^1128107124!01806b7c@1.128.107.124)
13:47eu^1128107124 has left IRC (eu^1128107124!01806b7c@1.128.107.124, Remote host closed the connection)
14:13kvaps has joined IRC (kvaps!2e1c6842@wedos.wedos.net)
14:36eu^p4FFDCCE8dip0 has joined IRC (eu^p4FFDCCE8dip0!4ffdcce8@p4FFDCCE8.dip0.t-ipconnect.de)
14:41gdi2k_ has joined IRC (gdi2k_!~gdi2k@host86-185-148-176.range86-185.btcentralplus.com)
14:43gdi2k has left IRC (gdi2k!~gdi2k@host86-185-148-176.range86-185.btcentralplus.com, Quit: Leaving)
15:04
<alkisg>
kvaps: hello! I only pinged for IN_PLACE because it's time for the LTSP release that will go to Ubuntu 20.04; the next big LTSP release will be in Autumn. No hurry at all I don't think any Ubuntu users currently need IN_PLACE though...
15:26
<kvaps>
alkisg: I think don't until I write my new post on kubernetes.io, but for now nothing ready for that :)
15:27
Anyway I'll suggest using ltsp-cloud instead, due http boot and many fixes which I implemented there
15:27
<alkisg>
kvaps: btw, why don't you just run the ltsp image outside of docker? ltsp doesn't have any big dependencies...
15:28
It's strange to create an image that will clone itself instead of running mksquashfs outside of it...
15:30
In any case I'll leave it as it is for now; IMAGE_TO_RAM might work but I haven't tested it; the normal ltsp use and the boot partition do seem to work now
15:34
<kvaps>
Because I'm doing that by automatically way. The main approach is to provide LTSP to DevOps engineers a tool for simple preparing own network bootable OS on bare metal.
15:36
So you have this Dockerfile on your git, and any change on it will regenerate and run new ltsp-server able to boot new servers over network
15:40
<alkisg>
Gotcha. OK let's leave this in our .diff for now and we can merge in Autumn.
15:41
<kvaps>
Another use case is running LTSP-Server inside unprivileged LXC-Containers, eg. user can use some Proxmox and prepare unprivileged container with the LTSP there for the standard usage.
15:42
<alkisg>
But shadow then would be inside the image, no cleanup phase...
15:42
Wouldn't that be very insecure?
15:48
<kvaps>
I think the main case here is to prepare separated chroot inside /srv/ltsp/x86_64 directory and not using the root of already existing system
15:48
in this way the cleanup shouldn't impact on the main root
15:50
I know many people from our community who prefer chroot method for preparing minimalistic ltsp-client image, they don't want to put whole ltsp-server root inside it
15:51
mainly because of the size, they have no much RAM on their clients :)
16:00
> It's strange to create an image that will clone itself instead of running mksquashfs outside of it...The first version was preparing ltsp-image next to the main system using debootstrap and chroot https://kubernetes.io/blog/2018/10/02/building-a-network-bootable-server-farm-for-kubernetes-with-ltsp/ but I find multistaging docker build is much
16:00
more usable for this case, due the unavailability to passtrough /proc /sys and /dev into chroot environment in unprivileged container some software can't be simple installed. Much easier to use standard docker mechanisms for preparing the client image, and then use short hack to prepare ltsp-server with this image inside as well
16:11
<alkisg>
"I think the main case here is to prepare separated chroot inside /srv/ltsp/x86_64 directory and not using the root of already existing system" ==> well that's great, but in that case, they wouldn't need to run `ltsp image` inside the chroot, they'd run outside of it
16:13
Although, if they don't have users or ssh keys in the chroot, then it should be ok...
16:13
e.g. root password in shadow etc
16:14woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Remote host closed the connection)
16:14
<alkisg>
To maintain chroots, another way is to netboot a VM or a real client; this also works for different architectures, e.g. raspberries
16:14
But giving many options is a good thing :)
16:19
<kvaps>
I agree with you, I know that my use case of LTSP is little different, but I hope we could merge most of the features into single project in the end, I don't want to maintain the fork :)
16:21
The only thing is the name - historically LTSP means **terminal** project, but what I'm doing is something different, any way LTSP is good enough to fit any needs for preparing network booting environment.
16:31
So maybe I will prepare parent project, which will include LTSP as library for preparing server images, and few other things like DNS-, DHCP-servers and Kubernetes-operator for manage the deployment. In this way it will not confuse the future cloud users. :)
16:33eu^p4FFDCCE8dip0 has left IRC (eu^p4FFDCCE8dip0!4ffdcce8@p4FFDCCE8.dip0.t-ipconnect.de, Remote host closed the connection)
16:49mnevans has joined IRC (mnevans!8008b09d@zero.geol.umd.edu)
16:51
<mnevans>
Hello LTSP world. I just made a clean install of debian 10.2, now want to re-establish LTSP, v19. Have read the helpful information at https://ltsp.org/docs/installation/ , followed instructions for 2NIC and chrootless install.
16:52
Question: does the information from my former install, LTSP5, that was in /etc/ltsp/dhcpd.conf, now go into /etc/ltsp/ltsp.conf?
17:07
Whether or not I do that - I am not seeing DHCP or proxyDHCP offers being received by the clients. Or does the local area network information (NIC2) now go into /etc/dhcp/dhcpd.conf?
17:15
<kvaps>
Hi mnevans LTSP19 uses dnsmasq instead of isc-dhcp-server so configuration now in /etc/dnsmasq.d/ltsp-dnsmasq.conf
17:15
and managed by `ltsp dnsmasq` command
17:21
<mnevans>
kvaps, thank you. I made the command ltsp dnsmasq and see there's /etc/dnsmasq.conf, all commented out lines. It looks like I should put the local configuration into /etc/dnsmasq.d/*.conf, is that correct?
17:21
And point to it in /etc/dnsmasq.conf, as noted in that file?
17:22
<kvaps>
your dnsmasq.conf should already include /etc/dnsmasq.d/*.conf as well
17:22
<mnevans>
Better to make a copy of dnsmasq.conf and put it there as ltsp-dnsmasq.conf, then copy info from the old configuration file there?
17:22
... so it does! :)
17:23
<kvaps>
I guess better way is to add your configuration into separated file to avoid situation that /etc/dnsmasq.d/ltsp-dnsmasq.conf will be overriden by `ltsp dnsmasq` command
17:25
<mnevans>
Seems no dhcp offers are being sent for the clients to pick up. Does that suggest a misconfigured NIC?
17:31
I guess I should make /etc/dnsmasq.d/ltsp-local.conf and add the local info from my ltsp5 /etc/ltsp/dhcpd.conf into that? Just putting that dhcpd.conf file there and restarting dnsmasq gives errors on using that dhcpd.conf, for instance it doesn't like authoritative;
17:36
or a host stanza that defines some fixed IP addresses on the local network.
18:10kvaps has left IRC (kvaps!2e1c6842@wedos.wedos.net, Remote host closed the connection)
18:52mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Remote host closed the connection)
18:56statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
18:57mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
19:00section1 has left IRC (section1!~section1@178.33.109.106, Remote host closed the connection)
19:07
<alkisg>
mnevans: it's best to leave /etc/dnsmasq.conf and /etc/dnsmasq.d/ltsp-dnsmasq.conf to their autoconfigurated values, and use /etc/dnsmasq.d/local.conf, yes
19:07
First, start without any local.conf at all
19:08
Remember to put the internal NIC to IP=192.168.67.1
19:08
Once you have the clients boot from this, THEN add custom values
19:10woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de)
19:11
<mnevans>
Alkisg, thank you. Have done that. Internal NIC at 192.168.67.1.
19:11
# IP ranges to hand out, usually on the internal LTSP subnet of 2-NIC setupsdhcp-range=192.168.67.20,192.168.67.250,12h
19:11
<alkisg>
mnevans: and yet you don't see any dhcp requests from the clients?
19:11
<mnevans>
# port=0 disables the DNS service of dnsmasq#port=0
19:12
No - no requests.
19:12
<alkisg>
Can I see?
19:12
!vnc-edide
19:12
<ltspbot>
vnc-edide: To share your screen with me, open Epoptes → Help menu → Remote support → Host: srv1-dide.ioa.sch.gr, and click the Connect button
19:13
<mnevans>
I had the network settings 'shared to other computers', have now reset to 'manual'
19:14
still no client offers.
19:14
opening epoptes
19:16
Hmm... trying to open epoptes...
19:16
I think it is launched
19:22
<alkisg>
mnevans: how do you activate it now/
19:22
Where's the network manager icon?
19:22
No
19:22
<mnevans>
service networking restart
19:22
<alkisg>
You need to activate the connection, not restart networking
19:25
mnevans: your temporary files were a problem
19:25
dnsmasq reads ~ files too
19:25
<mnevans>
fixed! So problem was that network interface 1 was not up?
19:25
aha.
19:25
<alkisg>
Both of these
19:25
<mnevans>
client is booting
19:25
but trying nfs mount
19:26
<alkisg>
You haven't ran `ltsp nfs`
19:27
<mnevans>
I thought you went to nbd some time ago?
19:27
<alkisg>
No, ubuntu went to nbd before I joined ltsp,
19:27
and last summer we completely stopped using nbd
19:27
as it's become unstable
19:28
We're using squashfs files over nfs
19:28
No nbd
19:28
<mnevans>
OK
19:28
<alkisg>
But not old-style-nfs either
19:28
We don't use a chroot (although it's easy) by default
19:29
<mnevans>
Yep. OK - so I got confused, and didn't run the last part of the installation instructions.
19:29
So now I can add back the dhcpd.conf instructions into dnsmasq.d/ ?
19:29
But different syntax?
19:30
<alkisg>
Yes
19:30
<mnevans>
(from ltsp5)
19:30
<alkisg>
Btw, what instructions?
19:30
For hostname, it's best to use ltsp.conf
19:30
<mnevans>
https://ltsp.org/docs/installation/
19:30
<alkisg>
What dhcpd.conf instructions, I meant
19:31
<mnevans>
Ah. I wanted authoritative fixed ip addresses on the local network. Also I've got some non-clients on the local network.
19:31
<alkisg>
Oh sure, if you want to put static IPs, yeah use it
19:32
<mnevans>
so ltsp.conf goes in /etc/ltsp/ and it has same syntax as dhcpd.conf?
19:32
(dhcpd.conf from ltsp5)?
19:33
<alkisg>
ltsp.conf is like lts.conf
19:33
dhcpd.conf is a completely other thing, it handles the dhcp server, not ltsp
19:33
<mnevans>
Ah. I think I have the lts.conf from prior install. And ltsp.conf goes into the /etc/dnsmasq.d/ folder?
19:34
<alkisg>
No, ltsp.conf goes to /etc/ltsp/ltsp.conf
19:34
It mentions it in the end of the installation page
19:34
!ltsp.conf
19:34
<ltspbot>
ltsp.conf: Configuration file for LTSP: https://ltsp.org/man/ltsp.conf/
19:35
<mnevans>
So it does!
19:38
OK - this helps a lot! And if I want authoritative ip addresses, can I do that in ltsp.conf?
19:39
<alkisg>
While you may do that from ltsp.conf, it's best to do it from /etc/dnsmasq.d/local.conf
19:39
IP addresses should be handled by the DHCP server, not by LTSP
19:41
<mnevans>
OK - I will give this a try! Thank you!!
19:41
<alkisg>
np
19:45
<mnevans>
I am going to end the epoptes session. Thanks again. I love LTSP!
19:45
<alkisg>
I ended it a few minutes ago :)
19:45
Cheers
19:48book` has left IRC (book`!~book`@static.38.6.217.95.clients.your-server.de, Quit: Leaving)
19:49book` has joined IRC (book`!~book`@static.38.6.217.95.clients.your-server.de)
20:55mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Quit: Leaving)
21:16Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
21:39woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection)
21:45zama_ has joined IRC (zama_!~zama@unaffiliated/stryx/x-3871776)
21:45zama_ is now known as zama