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


Channel log from 18 February 2012   (all times are UTC)

00:00
<alkisg1>
vagrantc: cool, but I think filing a bug to initramfs-tools is the way to go
00:00
<uskerine>
vagrantc, what about accessing the server from windows, what can be used for that?
00:01alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Disconnected by services)
00:01alkisg1 is now known as alkisg
00:01
<vagrantc>
uskerine: vnc, nx, rdesktop ...
00:01
er, RDP and xfreerdp
00:02
er, xrdp
00:02
<alkisg>
:)
00:02
<vagrantc>
not too familiar with the windows side of things
00:02
<uskerine>
no i mean
00:02
which client should i use as "thin client" in windows?
00:02
<alkisg>
x2go
00:02
<uskerine>
for example, for XDMCP i used Xmin
00:02
for example, for XDMCP i used Xming
00:03
ok
00:03
is LTSP it faster or slower than XDMCP?
00:03
in a LAN environment I mean
00:03
with no network bandwidth issues
00:03
<vagrantc>
no idea what xming is
00:03
<alkisg>
An x server for windows
00:04
uskerine: fat clients == faster screen updates than thin clients == xdmcp when ldm_directx=true
00:04
<vagrantc>
uskerine: LTSP can be configured to use XDMCP (though i wouldn't recommend it) ... you're comparing apples to oranges.
00:05
uskerine: LTSP is not a protocol, it is a mechanism for booting thin clients (and recently fat clients) off the network.
00:05
<uskerine>
i see
00:05
i see
00:05
so basically it opens ssh connections, tunnels the X11 stuff
00:05
and runs the whole session
00:05
<vagrantc>
it is the thin client operating system, which can use any protocols that your software supports.
00:05
<uskerine>
ok o
00:05
understood
00:05
<vagrantc>
uskerine: that's the default behavior
00:06
default is to make an SSH connection to the server and tunnel X traffic through it.
00:06
but it also supports many other options...
00:06
<uskerine>
ok
00:08* alkisg pumpkin goes to bed :)
00:09
<uskerine>
i will look to the page alkisg gave me, probably i will try first with thin client before going to the alpha release
00:09
and the fat client
00:09
but i like the idea of the fat client
00:09
<alkisg>
uskerine: personally I wouldn't bother with thin clients if I had such good clients like the ones you're planning to get, but whatever suits you :)
00:09
'night all
00:09
<highvoltage>
night alkisg
00:09alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
00:10
<uskerine>
i did not decide which thin client to buy yet
00:10
actually any recommendation for really cheap ones would be welcomed
00:13
<vagrantc>
anything that's not ancient will probably work well as a fat client these days...
00:13adrianorg has joined IRC (adrianorg!~adrianorg@187.115.107.166)
00:14
<uskerine>
understood
00:23
<vagrantc>
filed bug against initramfs-tools with patch ... back to readying this upload...
00:24monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 255 seconds)
00:35monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net)
00:41
<vagrantc>
huh. i don't have the huge /var/cache/apt/ problem when using NBD...
00:42
switching back and forth between NBD and NFS is now trivially easy...
00:42
this is goooood.
00:53rthomson has left IRC (rthomson!~rthomson@mars.pet.ubc.ca, Quit: Reached EOW)
00:56muppis has left IRC (muppis!muppis@viuhka.fi, Read error: Operation timed out)
00:57muppis has joined IRC (muppis!muppis@viuhka.fi)
00:58hughessd has left IRC (hughessd!~steve@173-164-117-109-Oregon.hfc.comcastbusiness.net, Quit: gone for some reason)
01:23bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 244 seconds)
01:58shamino has joined IRC (shamino!shamino@hilla.kapsi.fi)
02:03darkpixel_ has left IRC (darkpixel_!~darkpixel@65.100.44.217, *.net *.split)
02:03veloutin has left IRC (veloutin!~veloutin@modemcable121.135-59-74.mc.videotron.ca, *.net *.split)
02:03klausade has left IRC (klausade!~klaus@cm-84.215.157.180.getinternet.no, *.net *.split)
02:03shamino_ has left IRC (shamino_!shamino@hilla.kapsi.fi, *.net *.split)
02:07
<vagrantc>
if the screen.d/kiosk or kioskSession did a little more, we could make the ltsp-build-client plugin so much simpler.
02:12darkpixel_ has joined IRC (darkpixel_!~darkpixel@65.100.44.217)
02:31adrianorg has left IRC (adrianorg!~adrianorg@187.115.107.166, Ping timeout: 255 seconds)
02:43adrianorg has joined IRC (adrianorg!~adrianorg@187.115.105.16)
02:47risca has left IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca, Quit: Lämnar)
02:48risca has joined IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca)
02:55freedomrun has left IRC (freedomrun!~quassel@89.142.254.248, Remote host closed the connection)
03:10alexqwesa_ has left IRC (alexqwesa_!~alex@109.172.15.11, Quit: Хана X'ам !!!)
03:17
<vagrantc>
wow, metacity pulls inn an extra 773MB of disk space ... gotta find something else to use for kiosk mode.
03:19
i wonder if we could use evilwm from ldm...
03:33
aewm kind of works, although window decorations still happen, but you can lock it down to not start much.
03:50
i guess i could install metacity without recommends... that's somewhat reasonable
04:05adrianorg has left IRC (adrianorg!~adrianorg@187.115.105.16, Ping timeout: 248 seconds)
04:15* vagrantc wonders how getltscfg handles multiple SCREEN_08 entries
04:15
<vagrantc>
the last one wins?
04:16
presuming it processes it in top-to-bottom order...
04:17
stgraber: i'd like to do some considerable re-writing of the kiosk stuff ... do you think that will be too invasive for you?
04:19
<stgraber>
vagrantc: well, last I checked it wasn't really working, so I guess that could go as bugfix ;)
04:19
<vagrantc>
i think we could move more of it into the screen.d script and kioskSession at runtime, which would turn the ltsp-build-client plugins intto simply package selection
04:19
i seem to have it basically working for debian now, only slightly modified from what ubuntu has.
04:19
just pushed the commit
04:20
!seen gadi
04:20
<ltsp>
vagrantc: gadi was last seen in #ltsp 6 weeks, 3 days, 12 hours, 41 minutes, and 24 seconds ago: <Gadi> :)
04:20
<vagrantc>
eesh
04:20
gadi, we expect you to read all that backscroll!
04:21
i'd really like to get an idea of why gadi made so many layers with the kiosk stuff
04:22
i.e. we could create the user at runtime and populate the homedir at runtime (if not already present) ...
04:59risca has joined IRC (risca!~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net)
05:35
<vagrantc>
hrm.
05:36
something in LTSP still assumes squafs with NBD...
05:36
or i haven't restarted nbd-server
05:46staffencasa has left IRC (staffencasa!~staffenca@128-193-148-241.oregonstate.edu, Ping timeout: 244 seconds)
05:50Parker955 is now known as Parker955_Away
05:52
<vagrantc>
hrm... it's getting a weird negotiated size error...
05:52
maybe it's because it's a sparse file...
05:56alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net)
06:13freedomrun has joined IRC (freedomrun!~quassel@89.142.254.248)
06:28
<vagrantc>
ok, got that sorted out... wasn't using nbdroot=:ltsp_${CHROOT}
06:34komunista has joined IRC (komunista!~slavko@adsl-195-098-015-242.dynamic.nextra.sk)
06:48alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
07:01loather-work has joined IRC (loather-work!~khudson@wsip-98-175-250-115.sd.sd.cox.net)
07:27killermike has joined IRC (killermike!~killermik@2.26.100.159)
07:49
<vagrantc>
well, no Debian ltsp upload just yet, but did some needed cleanup
07:52
the bug in initramfs-tools 0.100 triggered some other odd behavior ... 00-kernel-env figured we must be on an NFS server even when using NBD, and other weirdnesses that didn't actually do much harm, from what i could see.
08:02
<alkisg>
We could make a sanity check in 00-check-sanity if you're worried about it...
08:08
!learn epoptes-fat-clients as To launch epoptes from a fat client, follow this documentation page: http://www.epoptes.org/documentation/fat-clients
08:08
<ltsp>
alkisg: The operation succeeded.
08:13loather-work has left IRC (loather-work!~khudson@wsip-98-175-250-115.sd.sd.cox.net, Quit: This computer has gone to sleep)
08:24
<vagrantc>
alkisg: i figured we could cache /proc/cmdline somehow, even stick in in a variable.
08:25
alkisg: basically do what we do for net-*.conf
08:25
though hopefully this bug will get fixed and it doesn't really matter... it mostly works without it, anyways, just a few quirks.
08:25
<alkisg>
Right... but since it's only a temporary workaround for some bug, I think I'd prefer to mount -t proc proc /proc instead, so that the changes are gathered in a single file (init-ltsp)
08:26
<vagrantc>
might even not bother with the workaround
08:27
yeah, that might be simpler.
08:27
<alkisg>
vagrantc: currently for nfs you're using aufs, not bindmounts, right?
08:27
Does that work ok? Did you try overlayfs?
08:27
<vagrantc>
alkisg: don't have overlayfs in debian yet, but aufs seems to work fine on both NFS and NBD-based setups.
08:28
<alkisg>
Very nice... so if we find a way to do the cow mounting from init-ltsp itself, then we won't need anything at all in the initramfs
08:28
<vagrantc>
that'll be awfully messy.
08:28
<alkisg>
Why?
08:28
<vagrantc>
try mounting your own root out from under yourself.
08:28
<alkisg>
In the future, we'll only need cow over /run
08:29
Not over /
08:29
(and /etc, in our case :D)
08:29
<vagrantc>
that presumes everything writeable ends up in /run
08:29
<alkisg>
But I think that we can do it now too
08:29
<vagrantc>
i don't see why the push to get everything outside of the initramfs...
08:29
<alkisg>
First make all the mounts to some system other than root, e.g. in one of the tmpfs's and then pivotroot to that
08:30
<vagrantc>
it doesn't really seem to make the code much better than running from init-bottom ...
08:30
i guess it's in theory easier to make cross-distro?
08:31
<alkisg>
I think so, but it also makes the code simpler, if we had nothing initramfs-related
08:32
<vagrantc>
i don't see how the code is really any simpler, it's just the same code in a different place.
08:32
<alkisg>
Having less and specific hook points == simplicity
08:32
<vagrantc>
sure
08:33
<alkisg>
I remember myself 2 years ago when I couldn't discriminate between initramfs scripts and initscripts :)
08:33
<vagrantc>
though during this transition, it seems *way* more complicated :)
08:34
<alkisg>
It'd be much easier for me to help with the code if it all was being started from 1 or 2 hook points
08:34
<vagrantc>
it seems like init-ltsp.d and ltsp_config.d have a lot of overlapping potential.
08:34
<alkisg>
Even later on I had to put debug echo's in ltsp_config to see how many times it gets called on boot (by ltsp-client-setup, but ltsp-client-core etc)
08:34
<vagrantc>
and i really want to simplify the kiosk stuff so all the ltsp-build-client plugin handles is installing the appropriate packages.
08:35
and do most of the configuration at run-time...
08:35
<alkisg>
I think ltsp_config and ltsp_config.d are a mess now, no cleanly specified functionalit
08:35
That'd be great
08:35
Even user creation
08:36
<vagrantc>
right
08:36
<knipwim>
speaking of cross-distro, my goal is to port the initramfstools scripts to dracut
08:36
<vagrantc>
right now, with the shared uid/gid space, users on the system could edit the kiosk user's files...
08:36
<knipwim>
dracut is the initramfs creation tool from fedora, but also used by gentoo
08:37
<vagrantc>
knipwim: we're moving most of our functionality out of initramfs-tools lately, so that sshould be easier, i hope.
08:37
dracut is also available in debian
08:38
<knipwim>
let me see if i understand correctly:
08:38
<vagrantc>
but default is to use initramfs-tools
08:38
<knipwim>
the bindmount/aufs functionality is going to init-ltsp
08:38* vagrantc isn't convinced about that part
08:38
<knipwim>
and init-ltsp resides in the initramfs?
08:38
<alkisg>
knipwim: no, it was just an idea
08:39
knipwim: we're using a custom init now as a kernel parameter
08:39
<vagrantc>
knipwim: init-ltsp replaces /sbin/init for early execution of some parts
08:39* alkisg leaves the explanation to vagrantc :)
08:40
<vagrantc>
knipwim: and then hands it off to the real /sbin/init when it's done ... hopefully that will work ok for you?
08:40
<knipwim>
trying to wrap my head around it, what the actual boot process looks like
08:40
<vagrantc>
knipwim: currently the initramfs just handles mounting the root filesystem, setting it up for writeability somehow, and then handing it off to /sbin/init-ltsp, which runs some hooks in /usr/share/ltsp/init-ltsp.d
08:41
<knipwim>
like boot, load initramfs, start init-ltsp from that, which load the initramfs scripts, and then go to /sbin/init
08:41
?
08:41
<vagrantc>
that's a basic overview, yes.
08:41
<alkisg>
Er, no?
08:41
<vagrantc>
knipwim: actually, initramfs-scripts was renamed to init-ltsp
08:41
if that's what you're referring to as initramfs-scripts ...
08:42
<knipwim>
yes
08:42
<alkisg>
It's boot => initramfs => non-ltsp scripts mounting root => an ltsp script doing the cow thing => end of initramfs, we go to the real system, but not to the real init, to /sbin/init-ltsp instead,
08:42
...so the previous initramfs scripts now run on the real system, not in the initramfs
08:42
<vagrantc>
right.
08:43
<knipwim>
ah, alkisg, that explains a lot
08:43
i thought the init-ltsp scripts were running in the initramfs
08:43
makes sense too
08:43
<alkisg>
You can do that too, we even have code for it, but we don't use it
08:43
<vagrantc>
that's the change alkisg made in the last few days.
08:44
<knipwim>
i saw the different options in init-bottom/ltsp
08:44
it might be easier to implement than i tought
08:45
just have to get the bind mounting or aufs in dracut
08:45
<vagrantc>
i've pretty much abandoned bind mounting at this point...
08:45
too hard to keep track of all the bits and pieces that need writeability
08:45
i sure hope it is stable.
08:46
<knipwim>
aufs would also be my prefered choice
08:47
it's a bit of a hassle to include it in the initramfs
08:47
since gentoo doesn't include it in the kernel
08:47
<alkisg>
You can do it from the real system if you put it over the few different root dirs like /usr, /etc, /bin
08:48
3 cows instead of 1...
08:48
Maybe it can be done with pivot root too, dunno
08:48
(with 1 cow)
08:50
<vagrantc>
knipwim: maybe you could consider building from source? :)
08:51
alkisg: i've switched back and forth between NBD and NFS and it's relatively easy now!
08:52
<alkisg>
(basically we only write in /var and /etc, right? so 2 cows...)
08:52
vagrantc: what do you need for it, except change the kernel parameters?
08:52
<knipwim>
vagrantc: yeah, something like that, there is a aufs package so i can build the kernel, install the module package, and build the initramfs after that
08:52
just written an aufs dracut module :)
08:52
<vagrantc>
pretty much just have to: rm ${chroot}/etc/ltsp/update-kernels.conf && ltsp-chroot /usr/share/ltsp/update-kernels && ltsp-update-kernels
08:53
knipwim: although i guess upstream is moving towards overlayfs?
08:53
pretty similar, overall
08:54
<alkisg>
vagrantc: err why do you have to run ltsp-update-kernels?
08:54
<vagrantc>
alkisg: on ubuntu, you'd probably have to tweak the BOOTPROMPT_OPTS rather than removing them, but still pretty easy
08:54
alkisg: to push the pxelinux.cfg changes to the tftp dirs
08:54
<alkisg>
Ah, ok, but if it's just to switch temporarily, you can manually edit pxelinux.cfg/default, no?
08:54
Without updating kernels...
08:55
<vagrantc>
alkisg: sure
08:55
<alkisg>
OK, so the same initramfs can boot both of them, that was the idea. Nice
08:55
<vagrantc>
alkisg: but i've burned myself by doing "temporary" changes that then become the default, and then get switched back unexpectedly
08:55
<alkisg>
We should fix ltsp-update-kernels to not do that :)
08:55
<vagrantc>
so i prefer to know all the steps to change back and forth.
08:56
<alkisg>
There's no point in calling update-initramfs just to make a pxelinux.cfg change
08:56
<vagrantc>
alkisg: then it would fail to update when you need it to.
08:56
alkisg: it doesn't call update-initramfs
08:56
<alkisg>
Ah, it doesn't? OK, good enough, I guess...
08:57
Why does the chroot need to know about the kernel parameters we're using?
08:57
(theoretically, not as we do it now)
08:57
<vagrantc>
because it's building the pxelinux configuration, and we get the version of pxelinux that's "compatible" with the version we're booting.
08:58
also makes cross-architecture stuff easier.
08:58
i.e. each architecture is responsible for setting up it's own booting configuration.
08:59
<alkisg>
Hmmm I don't like it...
08:59
The chroot can't know if the server uses nfs or nbd
08:59
<vagrantc>
also, in theory, it could obviate the need for ltsp-update-kernels, if tftp were pointed directly at the chroot's boot files..
08:59
alkisg: it's a communication issue either way.
09:00
alkisg: either the chroot needs to know something about the server, or the server needs to generate arbitrary configurations for a chroot that it may not understand.
09:00
the server's job is to server up files, the chroot's job is to prepare those files for a particular arch/distro/release
09:01
<alkisg>
OK, but I'm not talking about building the initramfs, but only about the kernel command line
09:01
<vagrantc>
which varies by release...
09:01
<alkisg>
But not all of it
09:01
<vagrantc>
and i freuqently host multiple releases on a single server...
09:02
<alkisg>
So I think the chroot should only have 1 configuration file with the *additional* kernel parameters it wants
09:02
And leave everything else up to the server
09:02
<vagrantc>
in addition to what?
09:02
<alkisg>
So no chroot involved to update pxelinux.cfg/deafult
09:03
<vagrantc>
you're assuming a homogenous chroot environment ... what if the parameters are incompatible?
09:03
<alkisg>
Let's see... which of those belong to the server, and which to the chroot?
09:03
append ro initrd=initrd.img root=/dev/nbd0 init=/sbin/init-ltsp nbdroot=:ltsp_i386 quiet splash plymouth:force-splash vt.handoff=7
09:03
Even if all of that belongs in the chroot, why does the server need to update it then?
09:03
Previously, we had the port stuff, ok, which was a problem
09:04
But we solved that problem by suggesting the IANA assigned port for nbd
09:04
The nfs path shouldn't be a responsibility of the chroot
09:04
<vagrantc>
in order to change between NFS and NBD?
09:04
<alkisg>
That's still a server responsibility
09:04
The chroot doesn't need to know about it
09:05
<vagrantc>
but the server needs too know what the client can support, and vice-versa.
09:05
<alkisg>
OK then the chroot can have a static configuration file to inform the server what it supports
09:06
E.g. nfsroot=$NBSROOT, nbdroot=$NBDROOT, and the server can replace the knows variables or strip the unknown ones, etc
09:06
<vagrantc>
and maybe one chroot neeeds a particular version of pxelinux, and another chroot needs an entirely different bootloader...
09:06markit has left IRC (markit!~marco@88-149-177-66.staticnet.ngi.it, )
09:06
<alkisg>
We don't have support for serving multiple pxelinux.0 versions
09:06
<vagrantc>
and i could host an ubuntu, fedora, gentoo chroot all on the same server.
09:06
<alkisg>
So that would still be a server thing, to provide a menu for the possible pxelinux.0 of the clients
09:06
<vagrantc>
alkisg: sure we do... each chroot ships it's own copy of pxelinux
09:06
<alkisg>
*of the chroots
09:06VectorX has joined IRC (VectorX!knight@unaffiliated/vectorx)
09:06VectorX has left IRC (VectorX!knight@unaffiliated/vectorx)
09:07
<alkisg>
vagrantc: but our dhcpd.conf only points to one
09:07
<vagrantc>
sure
09:07
<alkisg>
So there's no point in "update-kernels" to run inside the chroot, it doesn't help with that
09:07
<vagrantc>
admittedly, i usually ship one outside of ltsp entirely.
09:08
<alkisg>
While, server-side, one could write the code to handle even multiple pxelinuxes
09:08
So my main question remains, why do we need to run code inside the chroot to update the kernel command line...
09:08
<vagrantc>
the other task update-kernels does is prepare the nbi.img files, which aren't really used much anymore, and the obscure arches probably don't work.
09:08
<alkisg>
Right
09:09
<vagrantc>
so that i can sleep :)
09:09
<alkisg>
Hehe
09:09
'night vagrantc :)
09:09
<vagrantc>
alkisg: also ran it inside the chroot so that the chroot was something you could easily drop on another server, and it was "ready to go" essentially ...
09:10
<alkisg>
I don't think that helps anywhere...
09:10
The "other server" would again read the chroot desired command line from the configuration file
09:10
<vagrantc>
powerpc needs to ship yaboot, which isn't available on i386, for example.
09:11
and the server would need to know how to parse the yaboot configuration
09:11
<alkisg>
Still, the server side script copies that
09:11
It's just a matter of where you put the code, it's not like we can run binaries in a mac chroot anyway
09:11
<vagrantc>
(well, you can with arm, but that's another story)
09:12
<alkisg>
The best thing that would come out of moving the scripts server-side, is that the server would be able to provide pxelinux etc menus
09:12
So, multiple chroots => automatic boot menus
09:12
<vagrantc>
right, that would be a good thing.
09:13
well, it's not like any distros are in freeze any time soon, right?
09:13
<alkisg>
:D
09:13
Nah, there are more significant things to do first
09:13
Like being able to install ltsp-client to a normal pc
09:13
The pxelinux menus should go in a separate package, not in the ltsp code tree
09:14
E.g. in pxelinux itself
09:14
<vagrantc>
it has gotten klunky, i'll admit. at the time i changed it, it seemed like i had good reasons (the most attractive being the chroot's /boot being served up from tftp directly and always being current)
09:14
<alkisg>
That's just the kernel again, not the configuration
09:14
<vagrantc>
i really hate having to run ltsp-update-kernels after doing a kernel update in the chroot ... it just seems like busywork.
09:15
<alkisg>
So without --secure in tftpd-hpa, and with the pxelinux-menus package, one could still serve the /boot directly from the chroot
09:15
<vagrantc>
but i haven't gotten it together well enough to make that viable.
09:15
by using symlinks?
09:15
those annoying security defaults, though... meh.
09:15
<alkisg>
One way to do it, ye
09:15
s
09:15* alkisg really thinks that dnsmasq is more suitable for ltsp
09:16
<alkisg>
At some point I'd like to convince you and stgraber to switch to it by default
09:16
<vagrantc>
like you say, there are some larger things to tackle first
09:16
alkisg: does it help any that i've done all my ltsp development using dnsmasq for the last few months?
09:16
<alkisg>
Hehe :D
09:16
Really, why dhcpd3 and tftpd-hpa then?
09:16
<vagrantc>
i like dnsmasq, i've just stuck with all the others due to historic inertia
09:17
<alkisg>
Large setups have big sysadmins that get annoyed by the ltsp dhcp override
09:17
Small setups have routers as the dhcp servers, where dnsmasq can do proxydhcp
09:17
<vagrantc>
i don't do the override.
09:17
<alkisg>
(or can work with 2 nics in the same time)
09:17
Let's try it for the next releases
09:17
<vagrantc>
i don't default the override, i always thought that was crazy.
09:18
<alkisg>
The ltsp-server.postinst could install dnsmasq, and create an appropriate configuration file,
09:18
i.e. if it detects dhcpd, only use it as tftp server,
09:19
if it detects no dns, use it as dns too for the clients,
09:19
if it doesn't detect dhcpd, use it as a dhcpd too
09:19
If it detects a single nic, with external dhcpd, use proxy, etc etc
09:19
<vagrantc>
sounds good to me.
09:19
<alkisg>
Out of the box for most cases
09:19
OK, we'll tackle it in the future
09:20
<vagrantc>
although i'm always very conservative about autoconfiguration
09:20
<alkisg>
We'll make it behave well :)
09:21* vagrantc still hasn't invested the time to make ltsp-update-image behave well
09:21
<vagrantc>
although i gutted some pointless calls recently...
09:21
<alkisg>
The major problem there is still the kernel command line etc, isn't it?
09:21
<vagrantc>
yeah.
09:21
<alkisg>
I think to properly solve it, we need to create a pxelinux-menus package
09:22
And depend on that
09:22
<vagrantc>
recommend...
09:22
<alkisg>
And hope other packages can start using it too, maybe even put it in the pxelinux package
09:23risca has left IRC (risca!~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net, Ping timeout: 248 seconds)
09:23
<vagrantc>
although with the new switch-over, ltsp-update-image isn't nearly as much of a takeover your system sort of thing as it used to be.
09:23* vagrantc is still tempted to ship /etc/ltsp/ltsp-update-image.conf with "exit 0"
09:23
<alkisg>
Haha
09:24
Just put a big warning inside an "if ltsp-update-image detects that we're using nfs..."
09:24
<vagrantc>
but there's not really a good way to detect if you're using nfs
09:25
i might want to use both NFS and NBD from the same chroot, depending on what i'm doing.
09:25
i.e. test new features from NFS, release using NBD for the speed improvements.
09:26
<alkisg>
We should be able to detect what the chroot used last time
09:26
<vagrantc>
i think that's a very reasonable use-case... and forcing the updated plxelinux.cfg each run is problematic
09:26
<alkisg>
I.e. if it had nbdroot= in its kernel command line or not
09:26
<vagrantc>
what about concurrently?
09:26
i don't think there is a meaningful "last time"
09:26
<alkisg>
If you need multiple pxelinux menu entries for the same chroot, you should have multiple entries in its configuration
09:27
You'd e.g. ship with nfs as the default entry
09:27veloutin has joined IRC (veloutin!~veloutin@modemcable121.135-59-74.mc.videotron.ca)
09:27
<vagrantc>
now that would be cool, to generate your choice...
09:27
i.e. if it supports both, allow selecting either at boot
09:27
<alkisg>
Then, on the first time the user runs ltsp-update-image for that chroot, you'd ask him about generating a new entry or not
09:27
<vagrantc>
we're way closer to being able to do that
09:27
<alkisg>
And if so, it'd generate 2 menu entries
09:28
And it wouldn't need to ask again on later calls
09:28
<vagrantc>
anyways, i need to break this habit of staying up way too late...
09:28
<alkisg>
:)
09:28
'night again
09:28
<vagrantc>
heh
09:28
maybe i can push 5.3.1 on monday...
09:28* vagrantc still hasn't tested on squeeze
09:29* alkisg will have pushed the changes for bootable ltsp-client by then
09:31
<alkisg>
OK, let's try installing ltsp-client in a xubuntu vm...
09:35vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Ping timeout: 252 seconds)
09:37alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 252 seconds)
09:41alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
09:41adrianorg has joined IRC (adrianorg!~adrianorg@187.115.105.16)
09:43risca has joined IRC (risca!~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net)
09:56risca has left IRC (risca!~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net, Quit: Lämnar)
09:57uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out)
09:58uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net)
10:26uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out)
10:27uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net)
10:47uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out)
10:48uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net)
10:53bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
11:09uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out)
11:10uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net)
11:53uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out)
11:54freedomrun_ has joined IRC (freedomrun_!~quassel@89.142.254.248)
11:54uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net)
11:54freedomrun_ has left IRC (freedomrun_!~quassel@89.142.254.248, Read error: Connection reset by peer)
11:55freedomrun has left IRC (freedomrun!~quassel@89.142.254.248, Ping timeout: 276 seconds)
12:23monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Read error: Operation timed out)
12:35monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net)
13:00alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 252 seconds)
13:08alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
13:10khildin has joined IRC (khildin!~khildin@ip-80-236-222-61.dsl.scarlet.be)
13:30Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71)
13:49staffencasa has joined IRC (staffencasa!~staffenca@128-193-148-241.oregonstate.edu)
13:49monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Read error: Operation timed out)
13:50monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net)
14:00komunista has left IRC (komunista!~slavko@adsl-195-098-015-242.dynamic.nextra.sk, Quit: Leaving.)
14:12staffencasa has left IRC (staffencasa!~staffenca@128-193-148-241.oregonstate.edu, Ping timeout: 240 seconds)
14:38bakytn has joined IRC (bakytn!~bakytn@80.72.176.101)
14:44bakytn has left IRC (bakytn!~bakytn@80.72.176.101, )
14:44bakytn has joined IRC (bakytn!~bakytn@80.72.176.101)
15:02mistik1 has left IRC (mistik1!mistik1@unaffiliated/mistik1, Ping timeout: 260 seconds)
15:02mistik1_ has joined IRC (mistik1_!mistik1@184.170.1.113)
15:02mistik1_ has joined IRC (mistik1_!mistik1@unaffiliated/mistik1)
15:02mistik1_ is now known as mistik1
15:05Parker955_Away is now known as Parker955
15:10zamba has left IRC (zamba!marius@flage.org, Ping timeout: 272 seconds)
15:14bakytn has left IRC (bakytn!~bakytn@80.72.176.101, )
15:21markit has joined IRC (markit!~marco@88-149-177-66.staticnet.ngi.it)
15:24zamba has joined IRC (zamba!marius@flage.org)
15:40* alkisg just installed lubuntu 12.04 in vbox, then installed ltsp-client on top of it, exported the result to the ltsp server, and booted a fat client using that chroot!
15:43
<markit>
alkisg: I don't understand fully.. but seems good news :)
15:44
alkisg: btw, 12.04 is feature freeze... are you still in time for ltsp "improved version"?
15:44
<alkisg>
markit: it means that when we get to support that, you'll be able to maintain fat chroots using virtualbox
15:44
<markit>
or kvm? :9
15:44
<alkisg>
Sure, or real clients
15:44
<markit>
or none of the above, if the server does not support decent virtualization?
15:44
<alkisg>
You'll be able e.g. to install ubuntu in a powerpc, install any proprietary drivers that you need, use the software center to install programs, and then copy the result to the ltsp server
15:45* markit orrifies when reads "proprietary" ;P
15:45
<alkisg>
Hehe... there are devices that _only_ have proprietary drivers though :)
15:46
<markit>
btw, today the server frooze, all clients were running, and at teh end of teh hour all childred logged out... but some was unable and I discovered the server was frozen
15:46
alkisg: I don't buy them then :)
15:46
btw, performances will be the same, only much easier to mantein for "no tecnicians" if I understand correctly
15:47
<alkisg>
I'm afraid that this functionality won't make it for 12.04
15:47
Yes, performance will be the same
15:47
No virtualization needed on the server
15:48
<markit>
urgh, not for 12.04, that is a bad news :( so 12.04 will have almost the current ltsp I'm used to?
15:48
(with some new bug, of course ;P)
15:48
<alkisg>
Hehe, and lots of bug fixes too
15:48
LTSP 5.3 has many changes
15:48
<markit>
great, thank very very much for your work
15:49
btw, do you have a list handy of ports that have to be kept open among (fat/thin) clients and the server?
15:49
I'd like to pur more restrictive rules in the firewall (shorewall) but without compromise functionality ;)
15:50
<alkisg>
You really need a firewall in your internal network? Or are you using a single nic setup?
15:50
<markit>
so I need to know that traffic let flow and in what direction connection are estabilished
15:50
I don't really need
15:50
and single nick is something I've yet to look at
15:51
I prefer dual nic, but as you told me time ago, you are not always in the better (ideal) condition, so better be prepared
15:52
<alkisg>
you need ssh, tftp, dhcp, dns, nbd, ldminfod and some others that I don't remember. Better check your firewall for which ports are trying to get accessed.
15:56
<markit>
alkisg: sure, I asked just in case sch-script already did this
15:57
<alkisg>
Nope, we don't care about security :)
15:57
<markit>
I love that man ;P
15:57
now I'm in troubles with a joomla problem, see you later and happy hacking :)))
15:58
<alkisg>
bb
16:08uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out)
16:18freedomrun has joined IRC (freedomrun!~quassel@89.143.187.23)
16:21adrianorg has left IRC (adrianorg!~adrianorg@187.115.105.16, Ping timeout: 252 seconds)
16:29komunista has joined IRC (komunista!~slavko@adsl-195-098-015-242.dynamic.nextra.sk)
16:49killermike has left IRC (killermike!~killermik@2.26.100.159, Remote host closed the connection)
16:50killermike has joined IRC (killermike!~killermik@2.26.100.159)
17:00ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 265 seconds)
17:27markit has left IRC (markit!~marco@88-149-177-66.staticnet.ngi.it, )
17:34ltsp` has joined IRC (ltsp`!ltspbot@middelkoop.cc)
17:35sunson_ has joined IRC (sunson_!~suraj@li290-74.members.linode.com)
17:36alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg)
17:36Kevin`_ has joined IRC (Kevin`_!~kevin@router.kwzs.be)
17:37ltsp has left IRC (ltsp!ltspbot@middelkoop.cc, Ping timeout: 240 seconds)
17:37Kevin` has left IRC (Kevin`!~kevin@router.kwzs.be, Ping timeout: 240 seconds)
17:37alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 240 seconds)
17:37Lumiere has left IRC (Lumiere!~jstraw@unaffiliated/jstraw, Ping timeout: 240 seconds)
17:37Hyperbyte has left IRC (Hyperbyte!jan@middelkoop.cc, Ping timeout: 240 seconds)
17:37sunson has left IRC (sunson!~suraj@li290-74.members.linode.com, Ping timeout: 240 seconds)
17:37Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Ping timeout: 240 seconds)
17:37gentgeen__ has left IRC (gentgeen__!~kevin@c-98-236-71-64.hsd1.pa.comcast.net, Ping timeout: 240 seconds)
17:37sutula has left IRC (sutula!sutula@nat/hp/x-oiokfitkauoygjwn, Ping timeout: 240 seconds)
17:37khildin has left IRC (khildin!~khildin@ip-80-236-222-61.dsl.scarlet.be, Ping timeout: 240 seconds)
17:37SmallR2002 has left IRC (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net, Ping timeout: 240 seconds)
17:37gentgeen__ has joined IRC (gentgeen__!~kevin@c-98-236-71-64.hsd1.pa.comcast.net)
17:37alkisg1 is now known as alkisg
17:37Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71)
17:37SmallR2002 has joined IRC (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net)
17:38sutula has joined IRC (sutula!sutula@nat/hp/x-ficyrhegrxvmfakb)
17:38khildin has joined IRC (khildin!~khildin@ip-80-236-222-61.dsl.scarlet.be)
17:38Lumiere has joined IRC (Lumiere!~jstraw@unaffiliated/jstraw)
17:49r0cketeer has joined IRC (r0cketeer!~r0cketeer@189.194.242.97)
17:50
<r0cketeer>
what kind of server computer do i need for a classroom about 12 computers?
17:50
<alkisg>
How much RAM on the clients?
17:51
<r0cketeer>
512MB
17:51
<alkisg>
A normal PC would do just fine, some dual or quad core with about 3 gb ram
17:51
You'd probably want to run some localapps for better efficiency
17:52
Gigabit networking is also strongly suggested
17:53
<r0cketeer>
ok, so what do you think about the cost of the infraestructure between LTSP and each computer running EDUbuntu?
17:54
is cheapper LTSP?
17:54
<alkisg>
You can't run edubuntu efficiently with 512 mb ram clients
17:54
So you'd have to buy new ones, so ltsp will be cheaper, yes
17:55
And it's also easier to manage after you learn a few things about it
17:55
<r0cketeer>
All right, I'm trying to implement EDUBuntu in poor child schools here in Mexico, and Iḿ trying to know wich topology fits better
17:56
thank you very much
17:59
<alkisg>
r0cketeer: is it just for 1 school, or for many?
17:59* alkisg has put ltsp in about 250 greek schools, with 12 pcs per class and 1 server...
18:04
<alkisg>
r0cketeer: (replying to pm) yes, ltsp is very flexible, it supports thin clients, fat clients, localapps etc
18:07
<r0cketeer>
18:07
<alkisg>
r0cketeer: start one installation, and whenever you have questions, you can come back in the channel and ask
18:07
No need to take it all in now
18:08Parker955 is now known as Parker955_Away
18:10
<r0cketeer>
great, Probably we will be back for sure, to share experience about it. Next week we start our first class about it with child rescue for familiar violence
18:10
so wish us luck
18:10
We think that we will change they reallity about life with ths distro
18:11
<alkisg>
Don't worry children learn fast
18:11
Good luck!
18:12
<r0cketeer>
Thank you very much alkisg, see you around!
18:13uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net)
18:15r0cketeer has left IRC (r0cketeer!~r0cketeer@189.194.242.97, Quit: Saliendo)
18:23freedomrun has left IRC (freedomrun!~quassel@89.143.187.23, Remote host closed the connection)
18:25freedomrun has joined IRC (freedomrun!~quassel@89.143.187.23)
18:39uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out)
18:40uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net)
18:58uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out)
19:29||cw has left IRC (||cw!~chris@phpgroupware/cw, Read error: Connection reset by peer)
19:29||cw has joined IRC (||cw!~chris@gateway.wilsonmfg.com)
19:30||cw has joined IRC (||cw!~chris@phpgroupware/cw)
19:38risca has joined IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca)
19:46Hyperbyte has joined IRC (Hyperbyte!jan@middelkoop.cc)
20:16alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
20:24alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
20:31alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
20:34staffencasa has joined IRC (staffencasa!~staffenca@128-193-148-241.oregonstate.edu)
20:43adrianorg has joined IRC (adrianorg!~adrianorg@187.115.105.16)
21:05khildin has left IRC (khildin!~khildin@ip-80-236-222-61.dsl.scarlet.be, Quit: I'm gone, bye bye)
21:08mistik1_ has joined IRC (mistik1_!mistik1@unaffiliated/mistik1)
21:09mistik1 has left IRC (mistik1!mistik1@unaffiliated/mistik1, Remote host closed the connection)
21:09mistik1_ is now known as mistik1
21:10uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net)
21:12alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
21:19alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
21:20killermike has left IRC (killermike!~killermik@2.26.100.159, Remote host closed the connection)
21:20vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net)
21:29alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
21:37uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out)
21:37uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net)
22:00vagrantc has left IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net, Ping timeout: 240 seconds)
22:04uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out)
22:05uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net)
22:05vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net)
22:09bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 244 seconds)
22:20Parker955_Away is now known as Parker955
22:23uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out)
22:23uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net)
22:45uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out)
22:46Parker955 is now known as Parker955_Away
22:47alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
23:20vagrantc has left IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net, Quit: leaving)
23:28vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net)
23:33komunista has left IRC (komunista!~slavko@adsl-195-098-015-242.dynamic.nextra.sk, Quit: Leaving.)