|00:05||jgalt has joined IRC (jgalt!47697af2@gateway/web/freenode/ip.22.214.171.124)|
just installed ltsp on debianant clientsv
get as far as pxe loading pxe linux.... then display "connection refused" ad infintium
how may the problem be found?
|00:47||AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-bxrvrbfheyfsltie, Quit: Connection closed for inactivity)|
|00:58||cstk421 has joined IRC (firstname.lastname@example.org)|
jgalt: probably need to configure NFS in /etc/exports or /etc/exports.d/
"ltsp-config nfs" might work.
what does it need configured to?
to allow mounting the LTSP root filesystem
unless you've configured your LTSP to use NBD or AOE instead of NFS, but NFS is the default on Debian
vagrantc: ok, also after the install name resolution quit. any ideas on that?
jgalt: after running ltsp-build-client ??
jgalt: also, is this debian jessie, which was released yesterday?
for new installations, i'd definitely recommend going with jessie
yes, the host has been running jessie amd64 for about 4 months
the build client step built the chroot for i386 as instructed.
clients come up under pxe boot and show pxelinuxas having loaded then pretty much immediately show "connection reffused"
so yes, likely name resolution died sometime after running ltsp-build-client
the server can't do name resolution, or the clients?
but not totally sure. the process asked for reboot and when I did that and logged in again it couldn't find (resolve) google.com, yahoo.com, or sparkfun.com but would ping ip addresses on mylan and the internet just fine.
|01:18||Dsys has left IRC (Dsys!466ada6e@gateway/web/freenode/ip.126.96.36.199, Ping timeout: 246 seconds)|
hard to imagine ltsp-build-cleint doing anything that would cause that problem...
ok, name resolution now works. started working again after "apt-get remove resolvconf" and reboot. seems the resolvconf program was getting in the way.
|01:23||MarconM has joined IRC (MarconM!~Marcelo@unaffiliated/marconm)|
now to get the clients to netboot...... without "connection reffused"
|01:24||MarconM has left IRC (MarconM!~Marcelo@unaffiliated/marconm, Read error: Connection reset by peer)|
I tried ltsp-config nfs and that does basicly nothing except output the help for ltsp-config
|01:25||MarconM has joined IRC (MarconM!~Marcelo@unaffiliated/marconm)|
ok, i guess i didn't get support into jessie for that ... gah.
jgalt: step 4
vagrantc: followed those steps exactly, only difference being that I had to use dnsmasq because there is already a dhcp server running on the local lan and certain other users of this network would engage upon a witch hunt if I messed with that dhcpserver.
|01:31||* vagrantc nods|
my guess is then it's trying to connect to your router rather than the LTSP server.
unfortunately isc-dhcpd aparently won't do proxy-dhcp. I would have rather used the isc tools
jgalt: you'll need to add nfsroot=ip.of.ltsp.server:/opt/ltsp/i386 to /opt/ltsp/i386/etc/ltsp/update-kernels.conf to CMDLINE_NFS="root=/dev/nfs ip=dhcp boot=nfs"
what is trying to connect to my router? do you mean the net-boot client is trying to connect to my router? the net-boot client displays the proper addresses for the tftp server
oh, also you can use IPAPPEND=3
then it won't make a second request ... might obviate the need to mess with specifying the ip address explicitly
|01:34||MarconM has left IRC (MarconM!~Marcelo@unaffiliated/marconm, Read error: Connection reset by peer)|
|01:35||MarconM has joined IRC (MarconM!~Marcelo@unaffiliated/marconm)|
once you've edited update-kernels.conf, you'll need to run: ltsp-chroot /usr/share/ltsp/update-kernels
and then: ltsp-updatekernels
or rather: ltsp-update-kernels
in this case does it not need to make a second request? first request to get an ip address, then second request to get tftp server info?
the first updates /opt/ltsp/i386/boot with the new values, the second copies the stuff from /opt/ltsp/i386/boot to your tftp dir.
well, it's an NFS, NBD or AOE server that the second request is looking for
but yes, IPAPPEND=3 re-uses the first DHCP request
there are typically two DHCP requests made, one for PXE boot, and one from the booted initramfs.
second request of the pxe bootloader or second request of pxe linux?
pxelinux re-uses the PXE stack
1. PXE makes a DHCP request, downloads pxelinux, which downloads it's configuration files
ah, ok. may need to rebootthis box to try.
2. pxelinux downloads kernel and initrd and executes them
3. running initrd makes a DHCP request to find out it's root filesystem server
4. initrd attempts to mount the root filesystem and execute init
ok, on a differen't but slightly related topic how is ltsp much different than setting up a bunch of diskless netbooting x-terms?
it's a specific implementation of diskless netbooting x-terms.
ah, ok. so all software runs on the ltsp host and you are left with just an x-term display on your desk, correct?
that's an option.
unforunately, there are a lot of confusing namespace clashes here, though.
how can I tell or control what runs where?
well, i'm having a hard time with the terms you're using... x-term can mean about half a dozen different but related things
maybe i should just describe the typical LTSP use cases...
oh, sorry x11 display
hope that's clearer
thin client: connects to the LTSP server and runs all applications on the LTSP server
fat client: boots off of LTSP server, authenticates against the LTSP server, but runs applications on the client hardware
thin client with localapps: runs most applications on LTSP server, but some applications on client hardware
fat client with remoteapps: runs most applications on client hardware, but some applications on the LTSP server
x11 display is also prone to great confusion :)
|01:49||* vagrantc prefers to talk in terms of LTSP servers and LTSP clients|
ok, so after following the debian instructions referenced I end up with......? thin client?
LTSP by default uses LDM to connect to the server, which is effectively a GUI frontend to "ssh -X", although you can just use ssh for the authentication phase and use plain X11 traffic afterwards.
ok, probably what I wanted as I'm using a core2 duo to get some more life out of a bunch of p3's around the house. they are really snappy running as remote x displays.
with the performance vs. security tradeoffs, of course
the available ram is almost more important than CPU for fat vs. thin clients
thin clients can squeak by with 128-256mb of ram, for a fat client you'll probably want at least 1GB ... more is better, of course.
|01:53||cstk421 has left IRC (email@example.com, Read error: Connection reset by peer)|
(which doesn't seem particularly thin to someone who first started doing thin clients with 8MB of ram and servers with 256MB ...)
well some of those would be hurting to have 512MB of ram. more likely 128 or 256.
|01:54||cstk421 has joined IRC (cstk421!~cstk421@173-14-40-58-Michigan.hfc.comcastbusiness.net)|
if you can, look at how much power they draw ... i didn't do comparisons on pIII generation stuff, but P-4 vs. Pentium D vs. core2 systems was shocking.
pentium D barely performed better than a P-4, but drew 50% more power than either the p-4 or the core2
biggest thing is that the core2 will take about 4x the ram.
the p3's are crawling even running xp. this should be a nice upgrade for my housemates.
....and a good way to get them running linux.
...just set them to netboot their boxen as thin clients.
and if they complain too much, I can't be accused of removing windows from their prescious computers..... just reset the boot sequence and they are back to working as blisful snails.
|02:23||cstk421_ has joined IRC (firstname.lastname@example.org)|
|02:24||cstk421 has left IRC (cstk421!~cstk421@173-14-40-58-Michigan.hfc.comcastbusiness.net, Ping timeout: 245 seconds)|
|02:24||cstk421 has joined IRC (email@example.com)|
|02:25||jgalt has left IRC (jgalt!47697af2@gateway/web/freenode/ip.188.8.131.52, Ping timeout: 246 seconds)|
|02:26||cstk421__ has joined IRC (firstname.lastname@example.org)|
|02:27||MarconM has left IRC (MarconM!~Marcelo@unaffiliated/marconm, Quit: Leaving)|
|02:28||cstk421_ has left IRC (email@example.com, Ping timeout: 245 seconds)|
|02:28||cstk421_ has joined IRC (cstk421_!~cstk421@173-14-40-58-Michigan.hfc.comcastbusiness.net)|
|02:29||cstk421 has left IRC (firstname.lastname@example.org, Ping timeout: 250 seconds)|
|03:02||cstk421 has joined IRC (email@example.com)|
|03:04||cstk421_ has left IRC (cstk421_!~cstk421@173-14-40-58-Michigan.hfc.comcastbusiness.net, Ping timeout: 252 seconds)|
|03:21||cstk421 has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|03:21||cstk421 has joined IRC (email@example.com)|
|03:30||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)|
|03:39||Eric___ has joined IRC (Eric___firstname.lastname@example.org)|
|03:39||Eric___ is now known as jgalt|
|03:46||map7 has joined IRC (email@example.com)|
opt/ltsp/i386/etc/ltsp/update-kernels.conf : http://paste.debian.net/169225/
still having trouble after a chat with vagrantc earlier today getting clients to boot
IPAPPEND=3 seems tonot quite do it.
clients still sho a connection refused message.
|04:15||jgalt has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|04:23||jgalt has joined IRC (email@example.com)|
any idea as to what's wrong and why the client connection to the server is refused?
|04:28||cstk421 has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|04:32||jgalt has left IRC (email@example.com, Remote host closed the connection)|
|04:43||jgalt has joined IRC (firstname.lastname@example.org)|
jgalt: if you are getting connection refused after loading pxelinux it mostly means that the server where nfs/nbd/aoe images are is not available for the client machine
vsuojane1: I'm a bit confused.... how is it "not available for the client machine"?
if you could first troubleshoot the network and dhcp setup you are able better resolve is there something -- what is wrong in the ltsp server
the client is netloading pxelinux from the same server
yes, how the client connection to the server is refused ?
pxelinux is downloaded with the dhcp client (the dhcp boot parametere are conffigured in the local dhcp or proxy dhcp)
the client when told to pxe boot finds the network dhcp server running on the router and gets assigned 192.168.1.4 with a /24 netmask
oh sorry pxelinux is loaded -- not downloaded
the dhcp server on the router that does that is unable to give info about the tftp server so the dnsmasq server running on the ltsp box works as a dhcp proxy and fills in that info.
ok.. you have dnsmasq configured on the ltsp server.
I can see the pxe boot client display the proper info for ip address dhcp server, gateway, netmask, tftp server, everything right
yes dnsmasq is configured on the ltspserver and seems to be working as it should.
pxelinux loads noproblem
then it displays, "connection refused" ad infintium
that's where it'sstuck
couldn't use isc-dhcp because there's already a dhcp server running on the network which I can't touch.
....but that part seems to work.
vsuojane1: any ideas?
it doesn't get the connection to the client root system, thats the issue
yes, I'm aware. but why is the question.
and /opt/ltsp *(ro,no_root_squash,async,no_subtree_check)
do you have this on your ltsp server nfs exports ?
yes, you can look at pastebin think posted it.
sec I'll paste again
|05:19||ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)|
can you mount the nfs exports from the server ? are you able to test the mount from different mahcine on the same network ?
|05:32||work_alkisg is now known as alkisg|
jgalt: what's your pxelinux.cfg/default like?
alkisg: can you give a full path? looking at syslog it looks like that file may be missing but is that the same file?.... what's the path where it should be?
(or amd64, if appropriate)
vsuojane1: how would I mount the nfsmounts on another machine.... or on the ltsp server iself?
check alkisg thing first
Check nfs is useful too, both of those troubleshooting actions are
yes. but i would check first that pxe configs
jgalt: the server's ip didn't make it into that file
append ro initrd=initrd.img-3.16.0-4-586 init=/sbin/init-ltsp quiet root=/dev/nfs ip=dhcp boot=nfs nfsroot=192.168.1.3:/opt/ltsp/i386
jgalt: try changing it to this ^
Then reboot client
Or, change ipappend 2 to ipappend 3
One of them
hmmm. ipappend 2. is it reusing the dhcp or getting new from the default/authorative dhcp ?
ipappend 2 tells the client to use the same NIC as the one in PXE
Nothing more, it doesn't tell it to reuse the IP or the same server
(like ipappend 3 does)
should I not change /etc/ltsp/update-kernels.conf instead asit says to?
For the troubleshooting part, no
Later on to make it permanent, yes
brb - gotta reboot this box so I can test the client.
|05:50||jgalt has left IRC (email@example.com, Remote host closed the connection)|
|06:11||jgalt has joined IRC (firstname.lastname@example.org)|
changed all the ipappend 2 statements to ipappend 3 and it works.... now how to make it stay that way....
You need to run update-kernels inside the chroot
Try: ltsp-chroot -m /usr/share/ltsp/update-kernels
Then check if ipappend 3 made it to /opt/ltsp/i386/boot/pxelinux.cfg/ltsp
yes it did
OK then whenever your run `ltsp-update-kernels` now, it'll work as you want it to
....but we seem to have 2 files escentially the same.... updating /etc/ltsp/update-kernels is what seems to have made it work
...also what does ltsp-update-kernels do?
/etc/ltsp/update-kernels.conf in the chroot, right?
update-kernels in the chroot updates <chroot>/boot/pxelinux.cfg
|06:29||stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, Quit: leaving)|
ltsp-update-kernels outside of it copies it to tftp
man ltsp-update-kernels will tell you more
|06:30||stgraber has joined IRC (email@example.com)|
ok, thanks. so what do I need to do now to keep this maintained and up to date?
Nothing, just apt-get update, dist-upgrade etc
|06:31||stgraber has left IRC (firstname.lastname@example.org, Changing host)|
|06:31||stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber)|
so the ltsp chroot.... why the chroot for ltsp?
You need a server and a template client
The chroot is the template client
You could use a VM for that instead, but people here preferred chroots
Personally I prefer reusing the server installation
ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
I would reuse the server install but the server is amd64 and the clients are 32bit p3 boxen.
Install i386 on the server then
It even saves RAM
hmm,so why does or should anyone run a 64bit linux install
Because they don't care about netbooted clients
You can a bit more speed in math applications, and waste a little ram, it's a tradeoff
In this case, i386 suits you better
yes, but does 64bit hardware/os get you something? if so what?
Also some don't know that with i386-pae kernels you can access more than 4gb ram
(09:36:40 πμ) alkisg: You can a bit more speed in math applications, and waste a little ram, it's a tradeoff
now at the riskof committing heresy can this same basic setup be used to netboot a client to M$ windows?
How do you netboot windows usually?
(because there are many methods, all of them officially unsupported, to see if the one you use can also be offered by a linux server)
I havn't really tried. just thinking a menu that gave a choice of os to netboot would be kinda nice.
The menu is the easy part, the hard part is that windows officially don't support netbooting
So people find workarounds with iscsi disks or VMs
ah,ok got that.
You can offer iscsi disks from linux, that's the easy part, google for it, it's not very related to ltsp except that you can reuse some dnsmasq settings
yes,more curious than anything else.
But if your PCs already have disks, I don't see why you would bother
LTSP has support for windows remote desktop, but that doesn't suit you either
another interesting related project I may tackle would be getting some old mac G4's (power pc architecture) to netboot and serve as thinclients as well. any thoughts there?
prettymuch just invoke ppc in the create step?
You need qemu to run ppc code under and amd64 processor
rdp could work if one had a windows vm running somewhere.
Yes but it's slow
Kids will complain about not being able to play games
why would I be running ppc code under amd64? it should run native on the mac g4's
Then you'd need to install ltsp-server on the mac
In order to be able to run ltsp-build-client to generate the chroot
And then transfer the chroot to your main ltsp server, if you want to
even if I was using the g4's as thin clients?
The question is: how will you *create* the ppc chroot?
Not what will you do when it's ready
When it's ready, sure, you can use it to boot g4's as thin clients against an i386 server
ah, thought it just downloaded those files precompiled.
No, it executes code
So you need a ppc processor, either an emulated one (qemu) or a real one
hmm,when I did that step it went and downloaded a bunch of stuff for the chroot
It downloads packages and then executes them
It's like `apt-get install program`
That downloads program.deb _and_ executes it
ah,ok - needs to execute enough of it to configure packages.
That's why some .deb files are arch-specific
|06:55||uXus has left IRC (uXus!~uXus@184.108.40.206, Quit: ail bi bek)|
I'd expect them to be arch specific as they generally contain compiled binaries but I hadn't thought about the config scripts/binaries they contain/
the reality is that packages are more than just an archive- just realized that
|06:57||uXus has joined IRC (uXus!~uXus@220.127.116.11)|
|07:09||telex has left IRC (email@example.com, Remote host closed the connection)|
|07:10||telex has joined IRC (firstname.lastname@example.org)|
|07:14||khildin has joined IRC (email@example.com)|
alkisg: Thanks bunches for the help. 'bout to callit a night here in the pacific time zone.
You're welcome jgalt
yea, always nice on both sides when stuff finally works
|07:25||jgalt has left IRC (firstname.lastname@example.org)|
|07:25||syrius has left IRC (email@example.com, Ping timeout: 264 seconds)|
|07:25||syrius has joined IRC (firstname.lastname@example.org)|
|07:29||map7_ has joined IRC (email@example.com)|
|07:52||vsuojane1 has left IRC (firstname.lastname@example.org, Quit: leaving)|
|07:57||khildin has left IRC (email@example.com, Ping timeout: 264 seconds)|
|08:07||map7_ has left IRC (firstname.lastname@example.org, Ping timeout: 248 seconds)|
|08:08||map7_ has joined IRC (email@example.com)|
|08:19||map7_ has left IRC (firstname.lastname@example.org, Ping timeout: 264 seconds)|
|08:37||khildin has joined IRC (email@example.com)|
|08:57||vsuojanen has joined IRC (firstname.lastname@example.org)|
|09:18||muppis_ has left IRC (email@example.com, Ping timeout: 256 seconds)|
|09:19||muppis has joined IRC (firstname.lastname@example.org)|
|09:42||alkisg is now known as work_alkisg|
|09:43||work_alkisg is now known as alkisg|
|10:21||map7_ has joined IRC (email@example.com)|
|10:48||map7_ has left IRC (firstname.lastname@example.org, Ping timeout: 252 seconds)|
|11:19||Faith has joined IRC (Faith!~paty@unaffiliated/faith)|
|11:58||andygraybeal has left IRC (email@example.com, Read error: Connection reset by peer)|
|12:09||yanu has joined IRC (firstname.lastname@example.org)|
|12:09||yanu_ has left IRC (yanu_!~yanu@d1F05B2CD.access.telenet.be, Read error: Connection reset by peer)|
|14:25||khildin has left IRC (email@example.com, Ping timeout: 256 seconds)|
|14:43||khildin has joined IRC (firstname.lastname@example.org)|
|15:08||telex has left IRC (email@example.com, Remote host closed the connection)|
|15:10||telex has joined IRC (firstname.lastname@example.org)|
|15:10||bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Read error: Connection reset by peer)|
|15:11||bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy)|
|15:38||bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Ping timeout: 256 seconds)|
|16:25||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|
|16:35||Uzzi has joined IRC (Uzzi!5528630e@gateway/web/freenode/ip.18.104.22.168)|
|17:19||Uzzi has left IRC (Uzzi!5528630e@gateway/web/freenode/ip.22.214.171.124, Ping timeout: 246 seconds)|
|17:40||khildin has left IRC (email@example.com, Ping timeout: 265 seconds)|
|17:53||bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy)|
|17:55||khildin has joined IRC (firstname.lastname@example.org)|
|19:06||khildin has left IRC (email@example.com, Quit: I'm gone, bye bye)|
|19:37||telex has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|19:38||telex has joined IRC (email@example.com)|
|20:14||AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-vnmllosnljseqojp)|
|20:58||Faith has left IRC (Faith!~paty@unaffiliated/faith, Quit: Saindo)|
|21:59||ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)|
|23:27||AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-vnmllosnljseqojp, Quit: Connection closed for inactivity)|