|00:36||lroca has joined IRC (firstname.lastname@example.org)|
|00:50||lucascastro has left IRC (email@example.com, Remote host closed the connection)|
|02:21||ABIX_Adamj has joined IRC (ABIX_Adamj!~quassel@2a01:7c8:aab0:3d9:5054:ff:fed3:602b)|
|02:21||bcg_ has joined IRC (firstname.lastname@example.org)|
|02:25||bitchecker_ has joined IRC (email@example.com)|
|02:25||sutula_ has joined IRC (firstname.lastname@example.org)|
|02:26||bcg has left IRC (email@example.com, *.net *.split)|
|02:26||ogra_ has left IRC (firstname.lastname@example.org, *.net *.split)|
|02:26||sutula has left IRC (email@example.com, *.net *.split)|
|02:26||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, *.net *.split)|
|02:26||ABIX_Adamj_ has left IRC (ABIX_Adamj_firstname.lastname@example.org, *.net *.split)|
|02:26||Natureshadow has left IRC (Natureshadow!~Naturesha@commu.teckids.org, *.net *.split)|
|02:26||bitchecker has left IRC (email@example.com, *.net *.split)|
|02:27||ogra_ has joined IRC (firstname.lastname@example.org)|
|02:38||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
|02:44||lroca has left IRC (email@example.com, Quit: lroca)|
|09:25||ricotz has joined IRC (ricotz!~ricotz@p5B2A8BA6.dip0.t-ipconnect.de)|
|09:25||ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)|
|10:35||Statler has joined IRC (Statler!~Georg@p5489737D.dip0.t-ipconnect.de)|
|11:30||ogra_ has left IRC (firstname.lastname@example.org, Ping timeout: 240 seconds)|
|11:30||ogra_ has joined IRC (email@example.com)|
|12:19||adrianor1 has joined IRC (firstname.lastname@example.org)|
|12:23||adrianorg has left IRC (email@example.com, Ping timeout: 256 seconds)|
|12:54||adrianor1 is now known as adrianorg|
|13:18||Hyperbyte has left IRC (Hyperbytefirstname.lastname@example.org, Quit: leaving)|
|13:18||Hyperbyte has joined IRC (Hyperbyteemail@example.com)|
|14:07||Natureshadow has joined IRC (Natureshadow!~Naturesha@commu.teckids.org)|
|16:29||lucascastro has joined IRC (firstname.lastname@example.org)|
|17:08||sutula_ is now known as sutula|
|17:11||spectra has left IRC (spectra!~spectra@debian/developer/spectra, Quit: ZNC - http://znc.sourceforge.net)|
|17:34||spectra has joined IRC (spectra!~spectra@debian/developer/spectra)|
|18:42||Statler has left IRC (Statler!~Georg@p5489737D.dip0.t-ipconnect.de, Remote host closed the connection)|
|19:19||TheProf has joined IRC (TheProf!~TheProf@184.108.40.206)|
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.
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.
Is this the right way to test thin clients or another way? I am a volunteer and not at the school often.
I get the 'dhcpd: DHCPDISCOVER from 08:00:27:95:45:c5 via enp5s0' and 'dhcpd: 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.'
You need to put virtualbox in bridged mode
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)
Adapter type: Intel PRO/MT Desktop. Promiscuous Mode: Allow All. Cable Connected is checked.
TheProf: and what does the client show when it fails to boot?
alkisg, The virtual client shows: client MAC ADDR: <the virtual MAC> GUID <some long string> PXE-E51: No DHCP or proxyDHCP offer were received.
PXE-M0F:Exiting Intel PXE ROM.
FATAL: Could not read from boot medium! System halted.
TheProf: ah,dhcpd, not dnsmasq?
Dunno then, I'm not using isc-dhcp
Yes it says DHCP or proxyDHCP
It's strange how it works in person, but not virtually
OK perhaps someone else has experience with the isc-dhcp. A different question in the meantime please:
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.
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
sure, arrange your dhcp so that it only replies to pxeclients, not to all clients
They won't even get an ip that way
(or, use nat only on ltsp clients)
|20:08||lucascastro has left IRC (email@example.com, Remote host closed the connection)|
Responding to PXE clients is exactly what I need.
ltsp-config dnsmasq gives an example for dnsmasq
I don't know about isc-dhcp
OK I will search.
Those are the 2 necessary vendor classes for ltsp clents
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?
TheProf: it's just so much easier when you use the defaults, i.e. ltsp-manager/dnsmasq etc
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
alkisg, I was basing my installation on top of Ubuntu, which has isc-dhcp as default it seems.
The server has taken a long time to configure and set up so I'm hesitate to redo it to get dnsmasq
|20:36||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|
Question: what is the nbi.img that LTSP's DHCP hands out?
an old legacy format
i thought we entirely removed support in recent versions
vagrantc, Hello. Not sure. It's in my setup which was newly installed in 2017 but perhaps using older steps
i guess we haven't completetly removed it
(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:59||adrianor1 has joined IRC (firstname.lastname@example.org)|
|21:01||adrianorg has left IRC (email@example.com, Ping timeout: 240 seconds)|
vagrantc: most (99%?) of the locales in rhel7 are standard en_US.utf8 style, but there are few exceptions.
bcg_: curious to see the "locale -a" output as all supported locales in Debian do not trigger the issue
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
i suspect that's not upstream
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|
nor the issue with nb_NO.UTF_8 either
|21:49||adrianor1 is now known as adrianorg|
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
TheProf: i would be very surprised if the nbi.img is used at all in your setup
TheProf: unless you're manually installing etherboot firmware into the network cards of your clients
or booting from etherboot floppies or cdroms or something
vagrantc, I haven't done that for 10 years at least.
It is just in the default .conf file
TheProf: modern setups just use pxelinux which downloads the kernel/initrd directly
it's there for legacy reasons, but i don't think it will have any effect on your laptop users unplugging clients
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'
TheProf: if it makes you feel better, just remove that part from your dhcpd.conf
maybe we removed it from the dnsmasq configuration, since dnsmasq is largely recommended over dhcpd these days
we should just purge nbi.img from ltsp and be done with it. :)
you can switch from etherboot to ipxe in most cases for anything that needed it
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
All my thick clients boot PXE natively so no issue with removing nbi on that end.
TheProf: dnsmasq won't solve your problem, but i do find the configuration easier to edit
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
or have DHCP not hand out addresses at all for clients it doesn't know
Yes, alkisg said it is possible to "arrange your dhcp so that it only replies to pxeclients, not to all clients"
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
Specifically to use dhcp-vendorclass=pxe,PXEClient
and dhcp-vendorclass=ltsp,"Linux ipconfig" are the 2 necessary vendor classes for ltsp clents
yeah, that would handle the vast majority of cases
Yes it sounds excellent but I have no idea how to do this :)
i forget if it's possible to whitelist in the firewall by mac address
Trying to search online and it's messy
yeah, if you only hand out addresses based on the vendorclass, that would also probably block most people
again, they could spoof the vendorclass .... but the vast majority of people wouldn't even know where to start because "internet is broken"
Right. Slightest barrier to entry will stop them
looks like mac address based filtering is possible on the firewall
so, you have several options ... i think restricting dhcp based on the vendorclass is the easiest to set up
mac address filtering at the firewall would be more secure, but requires maintaining a list of whitelisted mac addresses
vagrantc, Right. I'll start with the vendorclass and then the MAC address filtering
if the vendorclass works, i wouldn't bother with the rest
i'm guessing the magic will be something like dhcp-range=192.168.67.20,192.168.67.250,8h
i'm guessing the magic will be something like dhcp-range=tag:pxe,192.168.67.20,192.168.67.250,8h
let me try this again
Is that for isc-dhcp or dnsmasq?
and then use IPAPPEND= in update-kernels.conf so it doesn't get another ip address from the initrd
same basic premise should work for isc-dhcp
vagrantc, OK I am doing my best to figure it out. Currently the IPAPPEND=3 line in update-kernels.conf is commented out.
haven't tested it, but one would hope it works
vagrantc, thank you for the paste - I'm looking at it now.
isc-dhcpd might be fussy about which options can go inside the "if" block
vagrantc, This is my current, working one: https://paste.debian.net/1003816/
yeah, so, basically move everything into the "if" clause
set IPAPPEND=3 in update-kernels.conf ... sudo /usr/share/ltsp/update-kernels
TheProf: are you using chroots or just building from the server image (e.g. ltsp-pnp style)
It was the default for over a decade so I got used to it :)
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.
It fails half-way through the PXE boot - the LTSP server sees the requests but doesn't hand out the LTSP image.
Strangly, if I'm on-site, the real thin client boots
Thanks for all the help!
|23:04||TheProf has left IRC (TheProf!~TheProf@220.127.116.11)|
|23:30||ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)|
|23:39||zama has left IRC (zama!~zama@unaffiliated/stryx/x-3871776, Ping timeout: 264 seconds)|
|23:57||Natureshadow has left IRC (Natureshadow!~Naturesha@commu.teckids.org, Read error: Connection reset by peer)|