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


Channel log from 6 January 2018   (all times are UTC)

00:36lroca has joined IRC (lroca!~lroca@ool-18bfd59d.dyn.optonline.net)
00:50lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection)
02:21ABIX_Adamj has joined IRC (ABIX_Adamj!~quassel@2a01:7c8:aab0:3d9:5054:ff:fed3:602b)
02:21bcg_ has joined IRC (bcg_!b@dsl-tkubng11-54f942-246.dhcp.inet.fi)
02:25bitchecker_ has joined IRC (bitchecker_!~bitchecke@31.131.20.132)
02:25sutula_ has joined IRC (sutula_!~sutula@207-118-152-40.dyn.centurytel.net)
02:26bcg has left IRC (bcg!b@dsl-tkubng11-54f942-246.dhcp.inet.fi, *.net *.split)
02:26ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, *.net *.split)
02:26sutula has left IRC (sutula!~sutula@207-118-152-40.dyn.centurytel.net, *.net *.split)
02:26alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, *.net *.split)
02:26ABIX_Adamj_ has left IRC (ABIX_Adamj_!~quassel@abix-vps.abix.info.pl, *.net *.split)
02:26Natureshadow has left IRC (Natureshadow!~Naturesha@commu.teckids.org, *.net *.split)
02:26bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, *.net *.split)
02:27ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
02:38alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
02:44lroca has left IRC (lroca!~lroca@ool-18bfd59d.dyn.optonline.net, Quit: lroca)
09:25ricotz has joined IRC (ricotz!~ricotz@p5B2A8BA6.dip0.t-ipconnect.de)
09:25ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
10:35Statler has joined IRC (Statler!~Georg@p5489737D.dip0.t-ipconnect.de)
11:30ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 240 seconds)
11:30ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
12:19adrianor1 has joined IRC (adrianor1!~adrianorg@179.187.29.28.dynamic.adsl.gvt.net.br)
12:23adrianorg has left IRC (adrianorg!~adrianorg@186.213.156.243, Ping timeout: 256 seconds)
12:54adrianor1 is now known as adrianorg
13:18Hyperbyte has left IRC (Hyperbyte!jan@middelkoop.cc, Quit: leaving)
13:18Hyperbyte has joined IRC (Hyperbyte!jan@middelkoop.cc)
14:07Natureshadow has joined IRC (Natureshadow!~Naturesha@commu.teckids.org)
16:29lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14)
17:08sutula_ is now known as sutula
17:11spectra has left IRC (spectra!~spectra@debian/developer/spectra, Quit: ZNC - http://znc.sourceforge.net)
17:34spectra has joined IRC (spectra!~spectra@debian/developer/spectra)
18:42Statler has left IRC (Statler!~Georg@p5489737D.dip0.t-ipconnect.de, Remote host closed the connection)
19:19TheProf has joined IRC (TheProf!~TheProf@162.222.82.228)
19:21
<TheProf>
Hello! I hope everyone is doing very well today. I have an LTSP server (Ubuntu with Mate desktop) running very well. I need to be able to do remote diagnosing and it was recommended I install virtualbox on the server.
19:21
That way I can connect via X2Go and then run a virtual machine that PXE boots to the server. I was able to do all that, but for some reason it doesn't serve the image.
19:22
Is this the right way to test thin clients or another way? I am a volunteer and not at the school often.
19:23
I get the 'dhcpd[1410]: DHCPDISCOVER from 08:00:27:95:45:c5 via enp5s0' and 'dhcpd[1410]: DHCPOFFER on 192.168.67.62 to 08:00:27:95:45:c5 via enp5s0' in syslog but then it just stops and gets a fatal 'could not read from the boot medium! System halted.'
19:23
Thank you.
19:32
<alkisg>
You need to put virtualbox in bridged mode
19:32
Not NAT
19:48
<TheProf>
alkisg, Hello. I have it currently set to that I believe. Network Settings -> Attached to: Bridged Adapter. Name: enp5s0 which is my LTSP NIC (this is a 2-nic server)
19:48
Adapter type: Intel PRO/MT Desktop. Promiscuous Mode: Allow All. Cable Connected is checked.
19:50
<alkisg>
TheProf: and what does the client show when it fails to boot?
19:52
<TheProf>
alkisg, The virtual client shows: client MAC ADDR: <the virtual MAC> GUID <some long string> PXE-E51: No DHCP or proxyDHCP offer were received.
19:52
PXE-M0F:Exiting Intel PXE ROM.
19:53
FATAL: Could not read from boot medium! System halted.
19:53
<alkisg>
TheProf: ah,dhcpd, not dnsmasq?
19:53
<TheProf>
That's it.
19:53
<alkisg>
Dunno then, I'm not using isc-dhcp
19:53
<TheProf>
Yes it says DHCP or proxyDHCP
19:54
It's strange how it works in person, but not virtually
19:57
OK perhaps someone else has experience with the isc-dhcp. A different question in the meantime please:
19:58
I am running thick clients, and with the 2-NIC system I had to set up the Internet access through the LTSP server as per usual. It works fine, except people are now able to plug in their own laptops into the LTSP port in the wall and get online.
19:59
Is there a way to prevent this, but still allow the thick clients Internet access? This is only a problem with thick clients - thin client setup didn't allow this
20:07
<alkisg>
sure, arrange your dhcp so that it only replies to pxeclients, not to all clients
20:07
They won't even get an ip that way
20:08
(or, use nat only on ltsp clients)
20:08lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection)
20:08
<TheProf>
Responding to PXE clients is exactly what I need.
20:08
<alkisg>
ltsp-config dnsmasq gives an example for dnsmasq
20:09
I don't know about isc-dhcp
20:09
<TheProf>
OK I will search.
20:10
<alkisg>
dhcp-vendorclass=pxe,PXEClient
20:10
dhcp-vendorclass=ltsp,"Linux ipconfig"
20:10
Those are the 2 necessary vendor classes for ltsp clents
20:10
*clients
20:11
<TheProf>
alkisg, I'm not familiar with any of this so I'm trying to learn. I'm guessing you specify the specific vendor it replies to in the config file?
20:25
<alkisg>
TheProf: it's just so much easier when you use the defaults, i.e. ltsp-manager/dnsmasq etc
20:25
!ltsp-manager
20:25
<ltsp>
ltsp-manager: LTSP Manager is a GUI tool that makes LTSP maintenance easy. It's the recommended way to install LTSP in common setups. More info: http://wiki.ltsp.org/wiki/Ltsp-manager
20:26
<TheProf>
alkisg, I was basing my installation on top of Ubuntu, which has isc-dhcp as default it seems.
20:27
The server has taken a long time to configure and set up so I'm hesitate to redo it to get dnsmasq
20:36vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
20:44
<TheProf>
Question: what is the nbi.img that LTSP's DHCP hands out?
20:45
<vagrantc>
an old legacy format
20:45
i thought we entirely removed support in recent versions
20:46
<TheProf>
vagrantc, Hello. Not sure. It's in my setup which was newly installed in 2017 but perhaps using older steps
20:48
<vagrantc>
i guess we haven't completetly removed it
20:51
<alkisg>
(10:26:38 μμ) TheProf: alkisg, I was basing my installation on top of Ubuntu, which has isc-dhcp as default it seems. ==> both the ltsp-manager and ltsp-pnp wiki pages recommend ubuntu with dnsmasq
20:59adrianor1 has joined IRC (adrianor1!~adrianorg@177.18.96.112)
21:01adrianorg has left IRC (adrianorg!~adrianorg@179.187.29.28.dynamic.adsl.gvt.net.br, Ping timeout: 240 seconds)
21:06
<bcg_>
vagrantc: most (99%?) of the locales in rhel7 are standard en_US.utf8 style, but there are few exceptions.
21:09
<vagrantc>
bcg_: curious to see the "locale -a" output as all supported locales in Debian do not trigger the issue
21:12
bcg_: but really, i just need to test that your patch doesn't break on Debian... and probably apply the same to other parts of the code
21:15
<alkisg>
vagrantc: termbin.com/ea1a
21:45
<vagrantc>
weird
21:46
i suspect that's not upstream
21:46
notably, i don't see any UTF-8 in that output
21:47* vagrantc suspects bcg_ 's problem has nothing to do with the "locale -a" output
21:49
<vagrantc>
nor the issue with nb_NO.UTF_8 either
21:49adrianor1 is now known as adrianorg
21:53
<TheProf>
vagrantc: Sorry for the communication gap there. Is the nbi.img part of the LTSP image? I'm trying to increase my LTSP security setup so that people can't just unplug a thick client and plug in their laptops and get Internet access (which is what they are doing now). I'm trying to limit it to vendor-class and the default dhcpd.conf in /etc/ltsp/dhcpd.conf says if not a PXEClient, hand out nbi.img
21:54
<vagrantc>
TheProf: i would be very surprised if the nbi.img is used at all in your setup
21:54
TheProf: unless you're manually installing etherboot firmware into the network cards of your clients
21:54
or booting from etherboot floppies or cdroms or something
21:55
<TheProf>
vagrantc, I haven't done that for 10 years at least.
21:55
It is just in the default .conf file
21:55
<vagrantc>
TheProf: modern setups just use pxelinux which downloads the kernel/initrd directly
21:56
it's there for legacy reasons, but i don't think it will have any effect on your laptop users unplugging clients
21:56
<TheProf>
OK. I was following the logic of the .conf file that if it is vendor = PXEClient, handout 'filename /ltsp/amd64/pxelinux.0' and 'else, nbi.img'
21:56
<vagrantc>
TheProf: if it makes you feel better, just remove that part from your dhcpd.conf
21:57
maybe we removed it from the dnsmasq configuration, since dnsmasq is largely recommended over dhcpd these days
21:58
we should just purge nbi.img from ltsp and be done with it. :)
21:59
you can switch from etherboot to ipxe in most cases for anything that needed it
22:00
<TheProf>
vagrantc, yes alkisg said the same thing about dnsmasq. I am using a Ubuntu-Mate ISO so I believe isc-dhcp is the default. This issue of people unplugging thick clients and jacking in their own laptops is becoming a major issues so I'm wondering if I need to switch over to dnsmasq
22:00
All my thick clients boot PXE natively so no issue with removing nbi on that end.
22:00
<vagrantc>
TheProf: dnsmasq won't solve your problem, but i do find the configuration easier to edit
22:01
TheProf: basically, you'll need to set up DHCP to hand out specific addresses for specific clients, and then configure your firewalling to only forward for thos IP addresses
22:01
or have DHCP not hand out addresses at all for clients it doesn't know
22:02
<TheProf>
Yes, alkisg said it is possible to "arrange your dhcp so that it only replies to pxeclients, not to all clients"
22:03
<vagrantc>
if they're sophisticated, they could check a client's ip address and manually configure that ip address ... but i'm guessing most people won't get that far
22:03
<TheProf>
Specifically to use dhcp-vendorclass=pxe,PXEClient
22:03
and dhcp-vendorclass=ltsp,"Linux ipconfig" are the 2 necessary vendor classes for ltsp clents
22:04
<vagrantc>
yeah, that would handle the vast majority of cases
22:04
<TheProf>
Yes it sounds excellent but I have no idea how to do this :)
22:04
<vagrantc>
i forget if it's possible to whitelist in the firewall by mac address
22:04
<TheProf>
Trying to search online and it's messy
22:05
<vagrantc>
yeah, if you only hand out addresses based on the vendorclass, that would also probably block most people
22:05
again, they could spoof the vendorclass .... but the vast majority of people wouldn't even know where to start because "internet is broken"
22:06
<TheProf>
Right. Slightest barrier to entry will stop them
22:07
<vagrantc>
looks like mac address based filtering is possible on the firewall
22:07
so, you have several options ... i think restricting dhcp based on the vendorclass is the easiest to set up
22:08
mac address filtering at the firewall would be more secure, but requires maintaining a list of whitelisted mac addresses
22:09
<TheProf>
vagrantc, Right. I'll start with the vendorclass and then the MAC address filtering
22:10
<vagrantc>
if the vendorclass works, i wouldn't bother with the rest
22:10
<TheProf>
Right.
22:16
<vagrantc>
i'm guessing the magic will be something like dhcp-range=192.168.67.20,192.168.67.250,8h
22:16
er
22:16
i'm guessing the magic will be something like dhcp-range=tag:pxe,192.168.67.20,192.168.67.250,8h
22:17
dhcp-range=192.168.67.20,192.168.67.250,8h
22:17
gah
22:17
dhcp-vendorclass=pxe,PXEClient
22:17
let me try this again
22:17
dhcp-range=tag:pxe,192.168.67.20,192.168.67.250,8h
22:17
dhcp-vendorclass=pxe,PXEClient
22:18
<TheProf>
Is that for isc-dhcp or dnsmasq?
22:18
<vagrantc>
and then use IPAPPEND= in update-kernels.conf so it doesn't get another ip address from the initrd
22:18
that's dnsmasq
22:18
same basic premise should work for isc-dhcp
22:21
<TheProf>
vagrantc, OK I am doing my best to figure it out. Currently the IPAPPEND=3 line in update-kernels.conf is commented out.
22:21
<vagrantc>
https://paste.debian.net/1003814/
22:21
for dhcpd.conf
22:21
haven't tested it, but one would hope it works
22:22
<TheProf>
vagrantc, thank you for the paste - I'm looking at it now.
22:23
<vagrantc>
isc-dhcpd might be fussy about which options can go inside the "if" block
22:25
<TheProf>
vagrantc, This is my current, working one: https://paste.debian.net/1003816/
22:27
<vagrantc>
yeah, so, basically move everything into the "if" clause
22:28
set IPAPPEND=3 in update-kernels.conf ... sudo /usr/share/ltsp/update-kernels
22:30
TheProf: are you using chroots or just building from the server image (e.g. ltsp-pnp style)
22:30
<TheProf>
vagrantc, chroots.
22:30
It was the default for over a decade so I got used to it :)
22:30
<vagrantc>
sure
22:33
<TheProf>
On a related note, I was trying to use virtualbox to allow me to test thin/thick client boot-ups without being on-site. So I would X2Go into the server, run Virtual box, and then have a virtual client PXE boot.
22:33
It fails half-way through the PXE boot - the LTSP server sees the requests but doesn't hand out the LTSP image.
22:33
Strangly, if I'm on-site, the real thin client boots
23:03
Thanks for all the help!
23:04TheProf has left IRC (TheProf!~TheProf@162.222.82.228)
23:30ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
23:39zama has left IRC (zama!~zama@unaffiliated/stryx/x-3871776, Ping timeout: 264 seconds)
23:57Natureshadow has left IRC (Natureshadow!~Naturesha@commu.teckids.org, Read error: Connection reset by peer)