IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 27 January 2020 (all times are UTC)
| 00:01 | GodFather has joined IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net) | |
| 00:15 | GodFather has left IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net, Ping timeout: 265 seconds) | |
| 00:44 | GodFather has joined IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net) | |
| 01:47 | GodFather has left IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net, Ping timeout: 268 seconds) | |
| 02:20 | GodFather has joined IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net) | |
| 06:01 | statler has joined IRC (statler!~Georg@p5B30E4C3.dip0.t-ipconnect.de) | |
| 06:35 | woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de) | |
| 07:01 | woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 07:41 | statler has left IRC (statler!~Georg@p5B30E4C3.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 08:23 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, *.net *.split) | |
| 08:36 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |
| 09:03 | woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de) | |
| 09:22 | statler has joined IRC (statler!~Georg@gwrz.lohn24.de) | |
| 11:38 | section1 has joined IRC (section1!~section1@178.33.109.106) | |
| 11:51 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:20 | lucascastro has joined IRC (lucascastro!~lucascast@131.255.227.138) | |
| 12:23 | lucascastro has left IRC (lucascastro!~lucascast@131.255.227.138, Client Quit) | |
| 12:30 | shored has left IRC (shored!~shored@87-92-77-163.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 12:30 | shored has joined IRC (shored!~shored@87-92-77-163.bb.dnainternet.fi) | |
| 13:47 | eu^1128107124 has joined IRC (eu^1128107124!01806b7c@1.128.107.124) | |
| 13:47 | eu^1128107124 has left IRC (eu^1128107124!01806b7c@1.128.107.124, Remote host closed the connection) | |
| 14:13 | kvaps has joined IRC (kvaps!2e1c6842@wedos.wedos.net) | |
| 14:36 | eu^p4FFDCCE8dip0 has joined IRC (eu^p4FFDCCE8dip0!4ffdcce8@p4FFDCCE8.dip0.t-ipconnect.de) | |
| 14:41 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@host86-185-148-176.range86-185.btcentralplus.com) | |
| 14:43 | gdi2k 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:14 | woernie 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:33 | eu^p4FFDCCE8dip0 has left IRC (eu^p4FFDCCE8dip0!4ffdcce8@p4FFDCCE8.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 16:49 | mnevans 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:10 | kvaps has left IRC (kvaps!2e1c6842@wedos.wedos.net, Remote host closed the connection) | |
| 18:52 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Remote host closed the connection) | |
| 18:56 | statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection) | |
| 18:57 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 19:00 | section1 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:10 | woernie 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:48 | book` has left IRC (book`!~book`@static.38.6.217.95.clients.your-server.de, Quit: Leaving) | |
| 19:49 | book` has joined IRC (book`!~book`@static.38.6.217.95.clients.your-server.de) | |
| 20:55 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Quit: Leaving) | |
| 21:16 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 21:39 | woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 21:45 | zama_ has joined IRC (zama_!~zama@unaffiliated/stryx/x-3871776) | |
| 21:45 | zama_ is now known as zama | |