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


Channel log from 2 November 2014   (all times are UTC)

00:29epoptes_user2 has left IRC (epoptes_user2!6dbe9d9d@gateway/web/freenode/ip.109.190.157.157, Ping timeout: 246 seconds)
02:00andygraybeal has joined IRC (andygraybeal!~andy@151.213.192.226)
02:04championofcyrodi has joined IRC (championofcyrodi!~Charles@va-67-233-88-88.dhcp.embarqhsd.net)
02:05
<championofcyrodi>
got the latest kernel installed w/ unionfs, did a test to make sure it works and was successful. scripted it: http://pastebin.com/ngqdar0i
02:06
also started looking through the ltsp code for k12linux, as you said alkisg, there is a lot of stuff I'm doing in there, and some stuff I'm not. But it's got a lot of good information.
02:08
vagrantc: That's a good point. However, I need to capture the logs for every client as a security requirement for my environment. I think I'd like to mount /var/log and /home via NFS, and anything else that needs write perms on tmpfs.
02:09
I think I'm going to start looking through the scripts to setup and configure the dhcp and tftpd services.
02:09
I've set them on manually so far, but looking to script it as well.
02:36
this is really cool... LTSP could be used to PXE boot servers for a cluster as well. I believe Mirantis is doing something like this using docker: http://docs.mirantis.com/openstack/fuel/fuel-5.0/operations.html#docker-containers-and-dockerctl
02:36
essentially to boot your own EC2 instance.
02:58
<vagrantc>
championofcyrodi: use a syslog host to capture logs...
02:59
yeah, i've often wondered about using LTSP for network booted servers...
02:59
in particular, a network of network booted LTSP servers
03:15
<championofcyrodi>
The Openstack Fuel+Mirantis server uses vlans to create several networks for cluster management. "PXE Linux" is the term for the bootp network it uses. While others are called "Storage", "Management"...
03:15
of course you can use separate network cards if you dont want VLANs, which is probably ideal anyway.
03:17
We're experimenting with CEPH block storage for volume management as well. (http://ceph.com/ceph-storage/block-storage/)
03:18
ideally you could create a cluster of old PCs, and provision them as LTSP hosts
03:20
vagrantc: thanks for the syslog host tip.
03:23
however, network block storage could be slow.... better to cache the chroot in RAM :)
03:43
<vagrantc>
i did implement a proof-of-concept feature to load the whole image into RAM on boot so that the server could go down and you could still function for fat clients...
03:44
presuming the homedirs were still accessible
03:44
given that the NBD image are usually compressed with squashfs, it's actually not too bad
03:49
<championofcyrodi>
I wonder if you could use torrent technology and have the client's share the ro volume that way.
03:49
then as long as 1 client is on, the fs is available.
03:49
more clients(seeds) ~ faster reads?
03:50
you would still need home folder storage if you wanted persistence.
04:27alkisg_web has joined IRC (alkisg_web!2ec6b63a@gateway/web/freenode/ip.46.198.182.58)
04:27* alkisg_web waves
04:27* vagrantc waves
04:28
<vagrantc>
championofcyrodi: yeah, something like that would be pretty cool.
04:29
<alkisg_web>
championofcyrodi: check xnbd, it does that, and it's something we do want to support in upstream ltsp
04:29
It can be used both for local caching and for ltsp server booting
04:30
<vagrantc>
i've long dreamed about an environment where you could actually power off the server and still boot new clients
04:30
though would only work well for unauthenticated environments
04:30
<alkisg_web>
Why? pam supports caching too ;)
04:32
championofcyrodi: btw, nbd does get cached in ram, and if you have lots of ram, all of it would be cached
04:32
(wrt speed, not for availability)
04:33
Phantomas: did we get epoptes 0.5.7 into jessie?
04:34
<vagrantc>
alkisg_web: distributing to the user password data to anyone who network boots has it's... risks :P
04:34
<alkisg_web>
vagrantc: ldap clients support caching, don't they?
04:35
ltsp server == ldap server, ltsp client == ldap client with kerberos caching and whatever,
04:35
this is supposed to be able to authenticate users offline for a while, isn't it?
04:35
<vagrantc>
alkisg_web: epoptes 0.5.7-1 has been in jessie for months
04:35
<alkisg_web>
Sorry, 0.5.8 then
04:36
<vagrantc>
apparently since December ... :)
04:36
<alkisg_web>
I pinged Phantomas about the new version we were talking... I just failed to remember it was 0.5.8 and not 0.5.7...
04:36
...and I wanted to see if he talked with you about it, etgc
04:37
<vagrantc>
nope
04:37
we maybe breifly talked about it, i can't recall
04:37
much too late now for anything but major bugfixes
04:37
<alkisg_web>
Yup, we talked about it maybe a month ago...
04:39
<vagrantc>
i could've just tried to push what was in bzr ... but didn't feel confident in it
04:39
since i mostly just maintain epoptes in debian because it's cool, i don't use it much myself
04:39
<alkisg_web>
I think he just wanted to hide the network benchmark, and make a release...
04:39
<vagrantc>
ah well, next release cycle :0
04:39
<alkisg_web>
Anyways, the deadline has passed now...
04:40
LDAP caching: https://wiki.debian.org/LDAP/NSS#Offline_caching_of_NSS_with_nscd
04:41
So, if we decide to use libpam_sshauth in ltsp 6, will it stack with nscd, so that it supports caching too?
04:47
<championofcyrodi>
you could use sssd to securely cache credentials on a local fat client's tmpfs. then it would persist at boot and be gone when the system loses power.
04:47
or probably nscd too
04:48
you would still need a server for ldap though
04:48
<alkisg_web>
But that server could go offline for a month, and still have cached logins... right?
04:50
<championofcyrodi>
yes, the service will cache ldap logins and still authenticate on a client if the server is down.
04:50
but if the client was diskless, and rebooted, it would lose the cache
04:50
<alkisg_web>
Sure, local disk would be needed for caching when the network's down...
04:51
What I would ideally want, is, to be able to go with my windows laptop to my ltsp-based school, netboot it once there, and then be able to boot it in my home and continue to work
04:52
The nbd cache, tmpfs cache etc, would be in C:\ltsp-persistent-cache
04:52
Debian's live package does support persistence in ntfs partitions
04:53
<championofcyrodi>
That is a really neat idea.
04:55
<alkisg_web>
Anyway, baby steps... replacing nbd-proxy in upstream ltsp, with support for xnbd client and server, would be the first step
04:56
And it would also make netbooting really really faster... utilize the new shiny ssd disks some clients have... make netbooting fast even on 100 mbps networks...
04:57
If you're thinking of using ltsp after all, and not a custom solution, then that could be a common goal where we could join forces
04:58
<championofcyrodi>
as long as I can cache to USB 3.0 stick I'm in.
04:59
<alkisg_web>
Sure
04:59
debian live autodetects the partition to cache in with its label, it sets it to something like PERSISTENCE
04:59
We could use that, and maybe also add support for a kernel command line like ltsp.cache=/dev/sda1 or ltsp.cache=UUID=xxxx
05:00
That partition can be anywhere, usb sticks, sd cards, sata disks...
05:01
<championofcyrodi>
we would want it to be configurable on a 'per-client' configuration?
05:01
like dhcp mac address scope and kernel command could pass from dhcp?
05:07
<alkisg_web>
Yes, kernel command line can be configurable, and it's desired some times
05:08
E.g. I'm imagining that in the future I'd want a "setup phase" for ltsp clients,
05:08
where in the server, i would enable the setup mode from a GUI, and it would pass ltsp.cache=auto+create to the clients,
05:09
and it would generate unique machine IDs etc for kerberus, before joining them to the "domain" of ltsp... anyways those plans are too far in the future
05:09
In the simple case, a client might want ltsp.cache=/dev/sda1, and another might want /dev/sda2, if LABEL/UUIDs aren't used
05:10
Kernel command line options will also be merge-able with ltspd (the daemon that will replace lts.conf) options, which can be sent on a per-client basis too
05:23
<championofcyrodi>
weird. the 3.17 kernel i compiled in my 64 bit VM, (which works inside the vm) causes the pxe client to flash random colors and old ascii characters all over the screen in a pattern. like different colored foreground and background colors too... which is where it stops. Right when you choose the pxelinux.cfg/default label... you don't see the "......." downloading or anything.
05:25
but when i use the 2.6.32 kernel that ships, i see it loading from the tftpd server with '........' and then continues to the initramfs
05:26
<vagrantc>
big changes in framebuffer support between 2.6 and 3.x
05:26
<championofcyrodi>
the client is intel centrino core 2 duo mobile (64 bit), while the server i compiled it on is just vmware 64 bit.
05:27
huh... but shouldn't i see the dots which indicate that it's being downloaded from the tftp server? (the kernel and the initramfs)
05:38
<alkisg_web>
the downloading .... part is from pxelinux, and it checks if "quiet" is in the kernel cmdline or not
05:38alkisg_web has left IRC (alkisg_web!2ec6b63a@gateway/web/freenode/ip.46.198.182.58, Quit: Page closed)
05:48cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
05:50
<championofcyrodi>
well, now that i have that kernel compile & install script.... i'm trying 2.6.36.4 with unionfs. Perhaps that will work better.
05:50
(since it is closer to the version 2.6.32 that centos uses anyway)
06:32vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
07:42
<championofcyrodi>
sweet. 2.6.36.4 works well w/ centos 6.6
07:42
and the client boot's with the kernel supporting unionfs!
07:42
boots*
09:54work_alkisg is now known as alkisg
10:32alkisg has left IRC (alkisg!~alkisg@194.63.234.224, Quit: Leaving.)
10:36work_alkisg has joined IRC (work_alkisg!~alkisg@194.63.234.224)
10:52work_alkisg is now known as alkisg
10:57andygraybeal has left IRC (andygraybeal!~andy@151.213.192.226, Remote host closed the connection)
11:16championofcyrodi has left IRC (championofcyrodi!~Charles@va-67-233-88-88.dhcp.embarqhsd.net, Quit: Leaving.)
11:21andygraybeal has joined IRC (andygraybeal!~andy@151.213.192.226)
11:21alkisg has left IRC (alkisg!~alkisg@194.63.234.224, Quit: Leaving.)
11:26work_alkisg has joined IRC (work_alkisg!~alkisg@194.63.234.224)
11:27khildin has joined IRC (khildin!~khildin@ip-213-49-86-27.dsl.scarlet.be)
12:21NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es, Ping timeout: 244 seconds)
12:23NeonLicht has joined IRC (NeonLicht!~NeonLicht@darwin.ugr.es)
12:48Phantomas has left IRC (Phantomas!~phantomas@ubuntu/member/phantomas, Read error: Connection reset by peer)
12:59Phantomas has joined IRC (Phantomas!~phantomas@ubuntu/member/phantomas)
14:06telex has joined IRC (telex!~telex@freeshell.de)
14:32alkisg has joined IRC (alkisg!~Thunderbi@ubuntu/member/alkisg)
15:44freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Read error: No route to host)
15:51freedomrun has joined IRC (freedomrun!~quassel@unaffiliated/freedomrun)
16:22consultores has joined IRC (consultores!be47a1f9@gateway/web/freenode/ip.190.71.161.249)
16:42khildin has left IRC (khildin!~khildin@ip-213-49-86-27.dsl.scarlet.be, Ping timeout: 258 seconds)
16:54minetreu has joined IRC (minetreu!5886b0b1@gateway/web/freenode/ip.88.134.176.177)
17:03minetreu has left IRC (minetreu!5886b0b1@gateway/web/freenode/ip.88.134.176.177, Ping timeout: 246 seconds)
17:04Phantomas has left IRC (Phantomas!~phantomas@ubuntu/member/phantomas, Remote host closed the connection)
17:06minetreu has joined IRC (minetreu!5886b0b1@gateway/web/freenode/session)
17:06
<minetreu>
hello
17:08
<alkisg>
Hi
17:11consultores has left IRC (consultores!be47a1f9@gateway/web/freenode/ip.190.71.161.249, Ping timeout: 246 seconds)
17:12
<minetreu>
i am in hostel in Trier-Germany, i hab a nice day in Luxemburg-City, how are you?
17:15
<alkisg>
Haha, fine, I'm in Japan and 3 beautiful women are massaging me
17:16yanu has left IRC (yanu!~yanu@178-117-230-250.access.telenet.be, *.net *.split)
17:16bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, *.net *.split)
17:19
<minetreu>
i bet so :) actually i was on a walk with two dutch girls, both nice but one of them real amazing.
17:19yanu has joined IRC (yanu!~yanu@178-117-230-250.access.telenet.be)
17:19bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132)
17:24alkisg has left IRC (alkisg!~Thunderbi@ubuntu/member/alkisg, Remote host closed the connection)
17:24alkisg has joined IRC (alkisg!~Thunderbi@ubuntu/member/alkisg)
17:28minetreu has left IRC (minetreu!5886b0b1@gateway/web/freenode/session, Changing host)
17:28minetreu has joined IRC (minetreu!5886b0b1@gateway/web/freenode/ip.88.134.176.177)
17:29khildin has joined IRC (khildin!~khildin@ip-213-49-86-27.dsl.scarlet.be)
17:32minetreu has left IRC (minetreu!5886b0b1@gateway/web/freenode/ip.88.134.176.177, Ping timeout: 246 seconds)
18:15mealstrom has left IRC (mealstrom!~Thunderbi@46.63.63.163, Remote host closed the connection)
18:16mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.63.163)
18:30championofcyrodi has joined IRC (championofcyrodi!~Charles@va-67-233-88-88.dhcp.embarqhsd.net)
19:15
<championofcyrodi>
man... so close.
19:15
client nfs is not getting port response from server rpc :\ going in circles checking to make sure portmapper/rpcbind is running, etc.
19:18yanu has left IRC (yanu!~yanu@178-117-230-250.access.telenet.be, Ping timeout: 256 seconds)
19:19khildin has left IRC (khildin!~khildin@ip-213-49-86-27.dsl.scarlet.be, Ping timeout: 264 seconds)
19:19yanu has joined IRC (yanu!~yanu@178-117-230-250.access.telenet.be)
19:24alkisg has left IRC (alkisg!~Thunderbi@ubuntu/member/alkisg, Quit: alkisg)
19:42vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
19:42vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
20:11
<muppis>
!win-loader
20:11
<ltsp>
I do not know about 'win-loader', but I do know about these similar topics: 'win32-loader', 'win98-loader'
20:11
<muppis>
!win32-loader
20:11
<ltsp>
win32-loader: win32-loader.exe adds a "PXE - Network boot" option to the Windows boot manager. It's developed for Debian and it uses http://ipxe.org for the network booting. Download it from http://ftp.debian.org/debian/tools/win32-loader/stable. More info at http://goo.gl/FPD7Zv
20:15
<championofcyrodi>
whats the difference between 'rpcbind' and 'portmapper' and 'portreserve'? in context of pxelinux and NFSd.
20:16
i've determined i can use rpcinfo and get information about what ports are listening for service calls.
20:17
and i've seen a mix of mountd, nfsd ports, sometimes showing, sometimes not.... but consistently the client fails the rpc calls for nfs. however, i can mount the share with mount.nfs using server->lan interface (192.168.1.1)
20:18
somewhere i read that 'portmapper' might not be running on the proper interface? but i'm not sure, because the distro says portmapper is not installed, but when i install it with yum, yum responds that 'rpcbind' is already installed..
20:19
it's probably something simple i didn't configure with dhcp,nfs... and i'm over thinking it because of the custom kernel
20:38
<vagrantc>
is there another dhcp server on the network with the clients?
20:38
it might be trying to connect to whatever's handing out DHCP rather than your LTSP server
20:39
championofcyrodi: also, you want to mount NFS with "-o ro,nolock" which requires fewer services
20:41
championofcyrodi: also, you want to mount NFS with "-o ro,nolock" which requires fewer services
20:41
oops
20:41
it's been so many years since i've had to troubleshoot anything at that level
20:46
<championofcyrodi>
its just another laptop bridged with the ethernet adapter on the server. Only protocol i have enabled on my host is the vmware bridge
20:46
get the same error with 2 vms on vmnet too
20:47
so it's def server/client config. i'll try some of your NFS tips. thanks!
21:22championofcyrodi has left IRC (championofcyrodi!~Charles@va-67-233-88-88.dhcp.embarqhsd.net, Quit: Leaving.)
22:21telex has left IRC (telex!~telex@freeshell.de, Remote host closed the connection)
22:22telex has joined IRC (telex!~telex@freeshell.de)
22:52freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Remote host closed the connection)