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


Channel log from 19 March 2008   (all times are UTC)

00:00
<johnny>
vagrantc, ubuntu uses that too right?
00:00
<warren>
johnny, initramfs-tools is a much more modern and modular design
00:00
<vagrantc>
johnny: yeah. i think the first versions came from ubuntu
00:00
<johnny>
will fedora adopt it?
00:00
<warren>
initramfs-tools is easier to extend to do new things
00:00
no
00:00
<johnny>
how come?
00:00
<warren>
long story
00:00
<vagrantc>
heh
00:00
<johnny>
is it more technical? or political?
00:01
<warren>
largely technical i've come to realize
00:01
my first two implementations of NBD for example were rejected from mkinitrd
00:01
<johnny>
uhmm.. that storyw ould be very interesting to me :(
00:01
<warren>
and eventually they came up with an ingenious new alternative for NBD implementation
00:01
it is a LOT more work but it'll be awesome
00:01
<johnny>
and they don't like initramfs-tools because?
00:02
<warren>
mount -t squashfs 192.168.0.254:2000 -o nbd,ro /path/to/mountpoint
00:02
johnny, because mkinitrd does everything that they want and they are too busy to ever change the entire world.
00:02basanta has quit IRC
00:02
<johnny>
hmm.. initramfs-tools...
00:03
i have mkinitrd in portage, but not initramfs-tools
00:03
<warren>
what version of mkinitrd?
00:03
SuSE forked mkinitrd a long time ago
00:03* vagrantc wonders what the mkinitrd lineage in fedora is relative to debian's old mkinitrd
00:03subir has quit IRC
00:04basanta has joined #ltsp
00:04subir has joined #ltsp
00:04
<warren>
vagrantc, AFAIK mkinitrd has always been upstream at RHL -> Fedora
00:04
vagrantc, mkinitrd evolved to the latest kernel and glibc requirements as Red Hat and Fedora always had the newest first.
00:04
<vagrantc>
warren: before initramfs-tools, debian had a package named "mkinitrd" ... but it seemed very debian-specific ...
00:04
<warren>
(painful as it is...)
00:05
vagrantc, I see Debian copyrights in our mkinitrd
00:05
vagrantc, maybe Debian forked at some point too
00:05
<vagrantc>
heh
00:05* vagrantc looks forward to "mount -o nbd"
00:06
<cyberorg>
warren, we had all the features since september last year http://sourceforge.net/mailarchive/forum.php?forum_name=ltsp-developer&max_rows=25&style=ultimate&viewmonth=200709
00:07
<vagrantc>
cyberorg: nothing upstream, though.
00:07
<cyberorg>
vagrantc, because i haven't changed/added anything to upstream code, it is vanilla as it came :)
00:07
<warren>
cyberorg, I don't really care, I need to implement much of it from scratch to be the Fedora way anyway. =(
00:07
<johnny>
ok.. another n00b question then..
00:07
<warren>
cyberorg, you have remote sound, local devices working?
00:08
<cyberorg>
warren, yes
00:08
<johnny>
what makes mount -o bind work, and why do you want it?
00:08
err mount -o nbd*
00:08
<warren>
johnny, very clean way to use nbd
00:08
<johnny>
and what does it take?
00:08
<vagrantc>
johnny: then it's just like any other mount command
00:08
<warren>
johnny, almost exactly like you would use mount -o loop
00:08
<cyberorg>
i had sound working last year, worked on pulse this release
00:09
<johnny>
vagrantc, that makes me think of your ext2 nbd :)
00:09
now i might get it..
00:09
<cyberorg>
nothing extra i had to do, works out of box
00:09
<vagrantc>
johnny: as opposed to having to do: nbd-client ip.of.ser.ver PORT /dev/nbd0 ; mount /dev/nbd0 ...
00:09
<johnny>
so..so what does it take for that to work?
00:09
<vagrantc>
teach mount what -o nbd means
00:10
<johnny>
and it doesn't already know it because?
00:10
is it new?
00:10
<vagrantc>
it's vaporware
00:10
<warren>
vagrantc, the hard part is, how do you know if a /dev/nbd0 is already taken and to use the next one?
00:10
vagrantc, udev creates many nbdX devices when you load the module =(
00:11
<vagrantc>
warren: indeed.
00:11
having something figure that out would be nice ...
00:11
<johnny>
hmm.. can't you do it with fuse?
00:11
<vagrantc>
warren: speaking of which ... i remember you had a feature request along those lines ...
00:11
<johnny>
seems relatively trivial for fuse..
00:11
<vagrantc>
warren: a way to tell if a given nbd device is active ... was that it?
00:11
<warren>
vagrantc, anything that goes into upstream kernel wont be in our production LTSP versions until a year from now
00:12
<cyberorg>
warren, here are fedora packages from the same tarballs and spec suse packages are built http://download.opensuse.org/repositories/server:/ltsp/Fedora_8/repodata/
00:12
<warren>
johnny, yes but nbd was in upstream kernel since forever
00:12
johnny, and you really don't want to include fuse libraries and more stuff in initramfs
00:12
<vagrantc>
warren: a year from now will hopefully be early into the next release cycle for debian :)
00:12
<warren>
cyberorg, no fedora user is interested in packages from suse's build service.
00:13
cyberorg, and if we see users using packages not built by us they don't get support.
00:13
<cyberorg>
warren, we leave that to users, BS provides packages for all top distributions :)
00:13
there are some fedora packagers working on it too
00:13
<johnny>
hmm.. fun ideas forming
00:13
<warren>
like who?
00:13
<johnny>
but.. back to work
00:13
<daya>
vagrantc, hi
00:14
<warren>
vagrantc, hm, I need to learn about the error codes that are possible when opening a block device
00:14
<daya>
vagrantc, does ldm has problem with lenny
00:14
<cyberorg>
warren, search for some packages for fedora here http://software.opensuse.org/search
00:15
<warren>
cyberorg, seriously, I don't care about fedora packages from suse's build service.
00:15
<vagrantc>
daya: should be fixed as of today.
00:15
<warren>
cyberorg, if users want to use packages from there, it is their choice.
00:15
<daya>
vagrantc, But, X doesn't get started in client,
00:16
<vagrantc>
daya: what version of ldm do you have? a new package was uploaded within the last 24 hours.
00:16
<daya>
vagrantc, I have done it with ltsp-build-client, Do I need to install different ldm, than that comes with lenny
00:16
<cyberorg>
warren, they are there just to demonstrate that packages for all distro can be released simultaneously from the same place, little less work for everyone
00:16
the packages there are same in all distros
00:17
<daya>
vagrantc, in same lenny repo, or somewhere else
00:17
<vagrantc>
daya: either install the version of ldm from sid, or get the one from testing security updates.
00:17
<warren>
cyberorg, with a bunch of conditionals in the spec for different distros?
00:17
<cyberorg>
warren, yup, that is how it works
00:17
<vagrantc>
daya: security updates should be installed by default.
00:18
<warren>
cyberorg, why do you continue to push this idea to me when I told you I am not interested?
00:18
<vagrantc>
daya: how long ago did you build?
00:18
<daya>
vagrantc, 2:0.1~bzr20080308-1 LTSP display manager
00:18
<cyberorg>
if i know deb packaging i would have those in there too :)
00:18
<vagrantc>
daya: that one should work.
00:18
<daya>
vagrantc, But its not working, should I have to specify sth in lts.conf
00:18
<cyberorg>
warren, i am not pushing anything :) they are there in case anyone is interested, it is fine even if you are not
00:19
<vagrantc>
daya: the default is if there are *no* SCREEN_NN entries, it defaults to ldm.
00:19
daya: so if you have specified any SCREEN_* entries, it will just use those.
00:19
<cyberorg>
your distro my distro thing is quite old :|
00:20
<warren>
You are the one bringing it up.
00:20
<vagrantc>
daya: could you paste your lts.conf to the pastebot?
00:20
!pastebot
00:20
<ltspbot>
vagrantc: "pastebot" is The LTSP pastebot is at http://pastebot.ltsp.org. Please paste all text longer than a line or two to the pastebot, as it helps to reduce traffic in the channel. A link to the content will be pasted in the channel.
00:21
<cyberorg>
warren, please scroll up, haven't mentioned suse in the entire conversation there :), i am out
00:21* warren considers SuSE to be detestable leaches.
00:22
<warren>
http://wtogami.livejournal.com/11305.html
00:22
<ltsppbot>
"daya" pasted "debian:~# cat /opt/ltsp/i386/e" (14 lines) at http://pastebot.ltsp.org/477
00:22* vagrantc would like to keep the distro-bashing to a minimum.
00:22
<cyberorg>
yeah, we are all on the same side here
00:22
<daya>
vagrantc, I have not make any changes though
00:23
<vagrantc>
!version
00:23
<ltspbot>
vagrantc: The current (running) version of this Supybot is 0.83.1+darcs. The newest version available online is 0.83.3.
00:23
<vagrantc>
!versions
00:23
<ltspbot>
vagrantc: Error: "versions" is not a valid command.
00:23
<warren>
Sorry, bad mood, I shouldn't broadcast that mood here.
00:23
<vagrantc>
ltspbot: factoids search --values
00:23
<ltspbot>
vagrantc: 'ltsp', 'sbalneav', 'icewm', 'frappr', 'wiki', 'debian', 'edubuntu', 'dhcpd', 'greyscreen', 'ltsp42', 'localdev', 'localdev', 'localdev', 'localdev', 'checklist', 'muekow', 'bestltspdistro', 'serversize', 'wireless', 'sound', 'topics', 'integration', 'lts.conf', 'pastebot', 'bootfloppy', 'ltsp5', 'tarball', 'download', 'monkeys', 'ogra', 'nfs', 'nfsnotresp', 'js', 's', 'troubleshooting', (1 more message)
00:23
<vagrantc>
ltspbot: factoids search --values --help
00:23
<ltspbot>
vagrantc: (factoids search [<channel>] [--values] [--{regexp} <value>] [<glob> ...]) -- Searches the keyspace for keys matching <glob>. If --regexp is given, it associated value is taken as a regexp and matched against the keys. If --values is given, search the value space instead of the keyspace.
00:23
<vagrantc>
ltspbot: factoids search --values --regex ver
00:23
<ltspbot>
vagrantc: Error: 'ver' is not a valid regular expression.
00:24
<vagrantc>
ltspbot: factoids search --values --regex *ver*
00:24
<ltspbot>
vagrantc: 'ltsp', 'debian', 'dhcpd', 'ltsp42', 'bestltspdistro', 'serversize', 'bootfloppy', 'ltsp5', 'nfsnotresp', 'ubuntu', and 'version'
00:24
<vagrantc>
!version
00:24
<ltspbot>
vagrantc: The current (running) version of this Supybot is 0.83.1+darcs. The newest version available online is 0.83.3.
00:24
<vagrantc>
!debversion
00:24
<ltspbot>
vagrantc: Error: "debversion" is not a valid command.
00:24
<vagrantc>
!debversions
00:24
<ltspbot>
vagrantc: Error: "debversions" is not a valid command.
00:24
<vagrantc>
hrmpf.
00:24
<warren>
There's no way to test ltspbot like directly without flooding the channel?
00:24
<vagrantc>
warren: sorry.
00:25
<warren>
not a big deal, just wondering =)
00:25
<vagrantc>
you can private message it, but you have to tell it which channel with each command ...
00:25
ltspbot: factoids search --values --regex *dpkg*
00:25
<ltspbot>
vagrantc: "version" is to get version info on debian/ubuntu (please use the pastebot): dpkg -l 'ltsp*' | egrep ^ii ; dpkg --root=/opt/ltsp/i386 -l 'ltsp*' ldm | egrep ^ii
00:25
<vagrantc>
aha!
00:26
ltspbot: forget version
00:26
<ltspbot>
vagrantc: The operation succeeded.
00:26
<vagrantc>
!version
00:26
<ltspbot>
vagrantc: The current (running) version of this Supybot is 0.83.1+darcs. The newest version available online is 0.83.3.
00:27
<vagrantc>
ltspbot: learn ver as to get version info on debian/ubuntu (please use the pastebot): COLUMNS=200 dpkg -l 'ltsp*' | awk '/^ii/{print $2" "$3}' ; COLUMNS=200 dpkg --root=/opt/ltsp/i386 -l 'ltsp*' ldm | awk '/^ii/{print $2" "$3}'
00:27
<ltspbot>
vagrantc: Error: No closing quotation
00:27
<vagrantc>
hrmpf.
00:28
daya: could you run that command and paste to the pastebot ?
00:28
<warren>
too tired to think
00:28
good night
00:29tux_440volt has joined #ltsp
00:30
<vagrantc>
ltspbot: learn ver as to get version info on debian/ubuntu (please use the pastebot): COLUMNS=200 dpkg -l 'ltsp*' | awk '/^ii/{print $2 $3}' ; COLUMNS=200 dpkg --root=/opt/ltsp/i386 -l 'ltsp*' ldm | awk '/^ii/{print $2 $3}'
00:30
<ltspbot>
vagrantc: The operation succeeded.
00:30
<vagrantc>
!ver
00:30
<ltspbot>
vagrantc: "ver" is to get version info on debian/ubuntu (please use the pastebot): COLUMNS=200 dpkg -l 'ltsp*' | awk '/^ii/{print $2 $3}' ; COLUMNS=200 dpkg --root=/opt/ltsp/i386 -l 'ltsp*' ldm | awk '/^ii/{print $2 $3}'
00:30
<ltsppbot>
"daya" pasted "daya@debian:~$ COLUMNS=200 dpk" (6 lines) at http://pastebot.ltsp.org/478
00:30
<daya>
vagrantc, deb http://security.debian.org/debian-security lenny/updates main
00:30
vagrantc, just now I installed ldm from this repo,
00:31
vagrantc, again not working
00:31
<vagrantc>
daya: you don't have ldm installed
00:31
daya: needs to be installed in the chroot
00:31
<daya>
vagrantc, but dpkg shows it,
00:31
vagrantc, hmm, sorry I do it,
00:32
<vagrantc>
daya: dpkg --root=/opt/ltsp/i386 -l ldm
00:32* vagrantc wonders how to sneak " into ltspbot
00:33
<vagrantc>
daya: you may need to un-install gdm as well
00:33
daya: in the chroot
00:34
<daya>
vagrantc, gdm, thru chrooted env
00:34
vagrantc, no there is no gdm installed in chrooted env
00:34
<vagrantc>
daya: dpkg -l --root=/opt/ltsp/i386 '*dm'
00:34
daya: sdm-terminal ?
00:35
daya: if you have ltsp-client installed, you must have ldm, sdm-terminal, or one of the packages providing x-display-manager
00:35
(soon to change)
00:36
<ltsppbot>
"daya" pasted "daya@debian:~$ su - Password:" (13 lines) at http://pastebot.ltsp.org/479
00:36
<daya>
vagrantc, I have kdm, how does it get installed thouhg its not requierd
00:37warren_ has joined #ltsp
00:37
<warren_>
cyberorg, sorry, I went totally overboard there.
00:37
<vagrantc>
daya: it's because of the ltsp-client dependency on ltspfs, which conflicts with the ldm version in lenny.
00:37
<daya>
vagrantc, then Do I now remove kdm and xdm in chrooted env
00:37
<vagrantc>
daya: so instead of installing ldm, it installed the kdm, which provides x-display-manager
00:37
<warren_>
Just wanted to say that.
00:38* warren_ really going to sleep now.
00:38
<vagrantc>
daya: re-build it.
00:38
<ogra_cmpc>
yawn
00:38warren_ has quit IRC
00:38
<daya>
vagrantc, re-build ,doesn't it work by removing kdm and xdm
00:38* ogra_cmpc curses wednesdays
00:38
<ogra_cmpc>
morning
00:39
<vagrantc>
daya: mv /opt/ltsp/i386 /opt/ltsp/i386.broken ; ltsp-build-client ....
00:39
daya: kdm probably pulled in a lot of dependencies you don't want.
00:39
daya: but you can also just remove it... and if that works for you, good.
00:39
daya: i would recommend re-installing.
00:52
<ogra_cmpc>
vagrantc, your CHROOTEXEC fix is nice :)
00:55
<vagrantc>
ogra_cmpc: i'd still prefer to implement it as an chroot wrapper function/script ...
00:55
<ogra_cmpc>
yeah
00:55
<vagrantc>
ltsp_chroot == chroot $ROOT
00:55
<ogra_cmpc>
i was just impressed by the code
00:56
<vagrantc>
about the same typing, more readable
00:56the_plumber has joined #ltsp
00:56
<vagrantc>
ogra_cmpc: oh :)
00:56
it really handles chroot being in nearly whatever bizarre place the distro puts it
00:56
<ogra_cmpc>
(as much as i'm scared by the initramfs stuff yoyu did)
00:56
<vagrantc>
ogra_cmpc: oh, it's nice.
00:56
<the_plumber>
hello all,
00:57
<vagrantc>
ogra_cmpc: simpler code, handles more cases. what could go wrong? :)
00:58
<ogra_cmpc>
nothing, it just looks unclean, i think you can just link the file btw
00:58
<vagrantc>
ogra_cmpc: oh, you mean the create-ext2-image plugin?
00:58
<ogra_cmpc>
yeah
00:58
<vagrantc>
ogra_cmpc: i tried a symlink at first, and it didn't get included
00:59
i'm working on patches to nbd-client's initramfs-tools hooks so that they're be more re-useable.
00:59
they'll
00:59
<ogra_cmpc>
local-bottom is part of initramfs-tools, it has to be always there
00:59
<daya>
vagrantc, does reinstalling again install kdm and xdm
00:59
<vagrantc>
ogra_cmpc: it's not in sid's default initramfs-tools install
00:59
<ogra_cmpc>
woah
00:59
<vagrantc>
daya: shouldn't, if the security updates are in place, which is default.
01:00
<ogra_cmpc>
so debian broke it :P
01:00
<the_plumber>
i have an advantech pcm5825f sbc that i would like to use, i used etherboot and rpld to connect it to my network to install a base image on it. now, i change to a new kernel and it seems to have problems with lost interrupts when booting (it sends out dhcp requests, but the packets are malformed). has anyone had a problem with these before?
01:00
<vagrantc>
nah. probably does something smart like "only make this directory if there are any files in it"
01:00
<ogra_cmpc>
there are plenty of scripts relying on it being there iirc
01:00
(not inside initramfs-tools)
01:01
<vagrantc>
ogra_cmpc: on the local-bottom directory existing?
01:01
<ogra_cmpc>
on the local script as such
01:01
(which in turn wants local-bottom)
01:01
<daya>
vagrantc, ok
01:01
vagrantc, and can we expect ltsp in lenny without nfs
01:01
<vagrantc>
well, haven't had problems with it, and i've been booting my virtual sid machine daily
01:01
<the_plumber>
also, what is a good, cheap sbc that supports pxe booting (NOT RPLD)
01:01
<vagrantc>
daya: yes and no.
01:02
daya: it will have to go through sid first
01:02
<ogra_cmpc>
vagrantc, well, it will tear us further apart
01:02
<vagrantc>
daya: there are several bugs which break NBD+squashfs+unionfs support
01:02
daya: i'm working on NBD+ext2 for sid that should be more consistant.
01:03
ogra_cmpc: i think the existance of the directory isn't a big deal. if the directory exists (i.e. package foo installs local-bottom/foo) then it gets included. what is your real concern?
01:03
<daya>
vagrantc, ok
01:04
<vagrantc>
daya: http://bugs.debian.org/src:ltsp
01:05
<ogra_cmpc>
vagrantc, mainly that you cant just drop a link in place (which used to work, i'm pretty sure)
01:06
<vagrantc>
ogra_cmpc: if you can confirm it works in ubuntu's version, i'll report a bug on debian ...
01:06
ogra_cmpc: well, after reading the changelogs, to make sure it isn't intentional...
01:06
<ogra_cmpc>
i'll try with my next classmate initrAMFS CHANGE
01:06
mrm
01:07
<vagrantc>
symlinks are nice.
01:07
<ogra_cmpc>
yup
01:08
what about just reading $boot and pick the dir based on that ?
01:08
<vagrantc>
nothing mentioning links in recent changelog entries
01:08
<ogra_cmpc>
in the ltsp script
01:09
<vagrantc>
ogra_cmpc: i'm not sure i follow
01:09
<ogra_cmpc>
at the bottom each initramfs script has that line:
01:09
<daya>
vagrantc, its work on my system when I remove KDM in chrooted system
01:09
<ogra_cmpc>
run_scripts /scripts/classmate-bottom
01:10
lets use: run_scripts /scripts/$boot-bottom
01:10
<vagrantc>
daya: nice.
01:10
ogra_cmpc: ah. sounds good.
01:10
<ogra_cmpc>
or ${0}-bottom
01:11
<vagrantc>
ogra_cmpc: coculd even make it a variable, and execute different things based on all sorts of crazy ideas.
01:11
<ogra_cmpc>
so you will always use the scripts that are attached to the method
01:11
yeah
01:11
<vagrantc>
ogra_cmpc: right now, though, i'm just using the boot=local and nbd has a script in local-top
01:11
<ogra_cmpc>
wll, nbd isnt really a local method :)
01:12
<vagrantc>
ogra_cmpc: to the machine, it's a local block device.
01:12
<ogra_cmpc>
hmm
01:12
which wont work without net
01:13
<vagrantc>
it's really elegant, and relies upon my configure_networking patch :)
01:13
<ogra_cmpc>
i'm not complaining about that :)
01:13
but we should have a cleaner way in initramfs
01:14
<vagrantc>
i've got a patch to file to get the nbd server from dhcp ... let me finish it before i fall asleep :)
01:14
<ogra_cmpc>
a generic netboot function with the possibility to plug in different methods is somethng thats nonexistent yet
01:16the_plumber has quit IRC
01:18
<vagrantc>
yeah, i'd like to work on that.
01:19
<ogra_cmpc>
me too
01:19
four weeks to go for me and i'm free again
01:20
(and now actually in the right department to work on such stuff officially :) )
01:20tux_440volt has quit IRC
01:25tux_440volt has joined #ltsp
01:27tux_440volt has quit IRC
01:34spectra has quit IRC
01:34abadger1999 has quit IRC
01:38spectra has joined #ltsp
01:47
<vagrantc>
ok, now that i've uploaded 3 ldm packages with security fixes, filed a couple patches and bug reports for nbd-client's nbd-root handling, implemented basic nbd+ext2 support for debian, fixed (worked around?) a bug when TMP/TMPDIR is set ... and a few more things to boot ... i think i can go to sleep now and upload a new ltsp to debian tomorrow.
01:53
<daduke>
vagrantc: good night.
01:53
<vagrantc>
hmmmm....
01:54
hmmm... i should generalize create-ext2-image to create-*-image
01:54
<ogra_cmpc>
well
01:54
squashfs uses ltsp-update-image
01:54
<vagrantc>
right.
01:54
<ogra_cmpc>
can you hook that in ?
01:55
<vagrantc>
tricky.
01:55
more likely i want to pull out your updating of inetd and such
01:55
make that separate
01:55
ogra_cmpc: i'm mainly thinking of whatever filesystems are normally writeable and reasonably well supported ...
01:56
<ogra_cmpc>
rip apart as you like
01:56
<vagrantc>
ext2, ext3, if someone wants to suffer through reiserfs, it shouldn't be hard to let them
01:56
<ogra_cmpc>
just dont change the command name
01:56
its in all docs for ubuntu now
01:56
<vagrantc>
ogra_cmpc: yeah, i'll just split it out into functions or something
01:56
<ogra_cmpc>
thats fine
01:56
i just dont want to have to update docs if possible :)
01:56
<vagrantc>
ogra_cmpc: i do endeavor not to break existing behavior, you know :P
01:58
<ogra_cmpc>
as much as i hardcode for dedicated default cases, yes :)
02:14
<vagrantc>
one last commit, and hopefully i don't dream about computers.
02:14vagrantc has quit IRC
02:57
<Pascal_1>
bonjour
03:12ccherret1 has joined #ltsp
03:15monteslu has joined #ltsp
03:16ccherrett has quit IRC
04:04
<daduke>
Pascal_1: bonjour.
04:15
<Pascal_1>
bonjour daduke ;-)
04:16
<daduke>
Pascal_1: you will have to wait for vagrantc, he just left to get some sleep.
04:16
<Pascal_1>
hmm i know that
04:16
here its 10h15
04:17
thank for your help
04:17
i hope he will find the solution
04:17
<daduke>
Pascal_1: we always do ;)
04:18
or more precisely, he always does.
04:18
<Pascal_1>
hmm your english is even better thazn mine ;-)
04:18
than
04:20
<daduke>
well, I was working in an international research group for 5 years, and I had an American girlfriend, both things help...
04:40
<stgraber>
daduke: oh, you living in switzerland ? (checked your IP)
04:44
<daduke>
stgraber: Zurich, yes.
05:03Faithful has joined #ltsp
05:15mikkel has joined #ltsp
05:18deavid has joined #ltsp
06:04spectra has quit IRC
06:13ogra_cmpc_ has joined #ltsp
06:13ogra_cmpc has quit IRC
06:14ogra__ has quit IRC
06:14ogra__ has joined #ltsp
06:30Faithful has quit IRC
06:35basanta has quit IRC
06:52Guaraldo has joined #ltsp
07:03subir has quit IRC
07:07daya has quit IRC
07:10
<jhp>
Hi everyone.
07:10
Got some little question. Thanks for the info on local devices in rdp sessions though, works like a charm.
07:13mhterres has joined #ltsp
07:18
<jhp>
But the problem I have now is that keyboard setting don't seem to be consistend accross the thin clients.
07:19
What should I force where to make sure that windows configures a US.intl keyboard with dutch language settings?
07:19
<Pascal_1>
lts.conf ?
07:21
<ogra_cmpc_>
i guess you need to add the -k option to rdesktop through the RDP_OPTIONS lts.conf variable
07:22
ogra@ceron:~$ rdesktop 2>&1|grep key
07:22
-k: keyboard layout on server (en-us, de, sv, etc.)
07:22
-K: keep window manager key bindings
07:22
<jhp>
What I understood from our windows partners is that Windows Terminal Server scans what keyboard the thin client has.
07:22ogra_cmpc_ is now known as ogra_cmpc
07:23
<ogra_cmpc>
look at the Xkb variables for lts.conf you can set
07:23
usually in /opt/ltsp/i386/usr/share/doc/ltsp-client-core/examples/lts-parameters.txt.gz
07:24
<jhp>
I don't have a doc dir.
07:24
ltsp 4.2
07:24
<ogra_cmpc>
oh
07:24
old unsupported stuff ...
07:24
hmm
07:25
look at the wiki then
07:25
wiki.ltsp.org
07:25
there are the old docs
07:28
<Pascal_1>
may be i'm wrong... this not those parameters ? XkbSymbols
07:28
XkbModel
07:28
XkbLayout
07:32
<ogra_cmpc>
yeah
07:32slipttees has joined #ltsp
07:32
<ogra_cmpc>
capitalized though
07:33* ogra_cmpc never can remember them from the top of his head ... since two releases ubuntu configures that correctly so its something i dont touch anymore
07:33Guaraldo has quit IRC
07:34Guaraldo has joined #ltsp
07:34jammcq has quit IRC
07:35mnemoc has quit IRC
07:40mnemoc has joined #ltsp
07:42cliebow_ has joined #ltsp
07:42slipttees has quit IRC
07:42
<cliebow_>
!seen sbalneav
07:42
<ltspbot>
cliebow_: sbalneav was last seen in #ltsp 1 day, 19 hours, 22 minutes, and 56 seconds ago: <sbalneav> Ah, there he is
07:43slipttees has joined #ltsp
07:43
<ogra_cmpc>
cliebow_, he's here (by nick at least) :)
07:43
<cliebow_>
Scott..tie! Scott...tie Scott..tie!!! 8~)
07:44
miss the little devil...
07:53slipttees has quit IRC
07:53
<ogra_cmpc>
cliebow_, btw, did you see ? http://people.ubuntu.com/~ogra/ltsp-install-ubuntu.png
07:58
<cliebow_>
no..ill take a look 8~)
07:59cliebow3 has joined #ltsp
08:00
<cliebow3>
that looks Great!
08:06Pascal_1 has quit IRC
08:08
<ogra_cmpc>
yep
08:10chup has joined #ltsp
08:10chupa has quit IRC
08:26mccann has joined #ltsp
08:33cliebow3 has quit IRC
08:38prpplague has joined #ltsp
08:38prpplague has left #ltsp
08:41Pascal_1 has joined #ltsp
08:44tux_440volt has joined #ltsp
08:55vagrantc has joined #ltsp
08:58mikesh has quit IRC
09:03sutula has joined #ltsp
09:14Gadi has joined #ltsp
09:15Pascal_1 has quit IRC
09:17kyron has joined #ltsp
09:18
<kyron>
ahoy, I'm using LTSP5 based on the ubuntu package whcih makes it "à la LTSP4.2". I have a problem where the terminal stops accepting X connections from the server...the terminal _appears_ to be frozen but it isn't
09:19
<laga>
a la LTSP 4.2?
09:19
<kyron>
laga, yeah, system image dumped onto the server and added to my exportfs
09:20
laga, meaning that I am using the tarball images...
09:21
<laga>
why don't you just use the normal ubuntu stuff? wouldn't that make getting help a bit easier?
09:22
<kyron>
sigh....
09:22* laga shrugs
09:23
<kyron>
Anyone here proficient with X and the way LTSP plays with it...I have a feeling it has something to do with the .Xauthority and all...
09:23
<ogra_cmpc>
ltsp uses ssh to transport X
09:23
<kyron>
ogra_cmpc, iirc, not mandatory
09:23
<ogra_cmpc>
at least if you didnt force it to do otherwise
09:23
but we neither test nor support XDMCP anymore
09:24
recent versions of ldm have a mode for unencrypted X while not sending the passwords out in plain text like XDMCP does
09:24
<kyron>
ogra_cmpc, so everything _HAS_ to go through SSH O_o!?
09:24
<ogra_cmpc>
yes
09:24
for the password handshake at least
09:25
for the display you have the LDM_DIRECTX variable to switch off ssh for X itself
09:26
<kyron>
ogra_cmpc, refresh my memory, this implies that the _server_ runs LDM, as opposed to say, KDM...
09:26
<ogra_cmpc>
no
09:26
ldm runs client side
09:26
<kyron>
ok, just wanted to make sure
09:26
<ogra_cmpc>
its a graphical frontend to ssh
09:27
<kyron>
few..
09:27
well..all in all, that still doesn't explain why my station stops accepting X connections all of a sudden O_o...
09:28
<ogra_cmpc>
no idea, the tarballs are ancient and the X version is likely different from the version you got on your server ... such a setup has probs by design
09:28
<kyron>
ogra_cmpc, come to think of it, aren't you _still_ using XDMCP...only that it's tunneled through SSH?...
09:28
<ogra_cmpc>
no
09:29
ldm by default does : ssh -X user@server /etc/X11/Xsession
09:29
and in direct mode : ssh user@server DISPLAY=${DISPLAY} /etc/X11/Xsession
09:30
(not exactly, but you should get how it works by that)
09:31mccann has quit IRC
09:31
<ogra_cmpc>
the first one uses ssh's builtin X proxy ... the second points the display directly to the client screen
09:31
both use ssh for authentication
09:32
<kyron>
hrmpf...I thought XDMCP also described the protocol for remote displaying, not just the discovery and login management part...
09:33
ogra_cmpc, then both would still exert the problem I have at the moment since I am using an "old" version of X on the client side and a "new" version on the server side... bummers...this is locking down my server evolution until I get a decent MueCow image set up...
09:33
<ogra_cmpc>
well
09:34
thats the reason why ltsp5 has to be implemented by the distro
09:34
cross distro setup is gambling here
09:34
<kyron>
not there yet (/me pokes at dberkholz :P )
09:34
<ogra_cmpc>
the last week there was massive work going on
09:34* ogra_cmpc points at johnny
09:35tux_440volt has quit IRC
09:35
<kyron>
can't remember but, can I chroot into the nice _ancient_ images and do something like "apt-get update" or something?
09:35
<ogra_cmpc>
yes, but it might break
09:36
you need to do a dist-upgrade to a new release inside the chroot
09:36
<kyron>
ogra_cmpc, hence cp -a ltsp ltsp.bak ;)
09:36
ogra_cmpc, using aptitude is the right choice??
09:36
<ogra_cmpc>
general practice is that i recommend ubuntu users to not do that because we dont test it
09:37
(most of the features an ltsp chroot has are set up by the creation script, if you dist-upgrade they will be missing, so the general practice for ltsp chroots is to rebuild them in a new release)
09:37
thats why it doesnt get tested
09:37
<kyron>
ogra_cmpc, well...it's broken anyways and I am using a copy ;) ...the worst I have seen as of late is the keyboard layout disagreeing with the server ...and will most probably screw up completely the MueCow stuff such as kernel ;)
09:38
<ogra_cmpc>
no, that should work fine afterwards as well
09:38
but we disable some essential initscripts that will automatically be restored
09:38
which might or might not break booting for you
09:38
<kyron>
ogra_cmpc, like dhcpcd eth0 ;)
09:39
<ogra_cmpc>
we dont run dhcpd on clients
09:39
oh
09:39
dhcpcd
09:40
<kyron>
yeah, typo...oh well, seems I can't even run apt-get dist-upgrade...
09:40
<ogra_cmpc>
no, actually everything thats not needed on a client and takes up ressources some might expect writability in places that are not writable etc
09:40
<kyron>
what bugs the hell out of me is that the term works...and suddenly stops working :/
09:40
<ogra_cmpc>
you need a resolv.conf in the chroot ...
09:41
else it wont work
09:41
<kyron>
ogra_cmpc, totaly understandable. Is the cleanup done manually or automatically...
09:41
<ogra_cmpc>
by the plugins of ltsp-build-client
09:41
<kyron>
ogra_cmpc, /me slaps on head... now why didn't I think of that...it's not like I lack the "chrooting" experience with Gentoo ;)
09:41
<ogra_cmpc>
heh
09:42
and run apt-get update first to update the package lists
09:42
<kyron>
ogra_cmpc, ok, though so, can I ASSume it's in my chroot environment and should be able to run it after the dist-upgrade?
09:42* ogra_cmpc isnt even sure there is a sane sources.list in the tarballs
09:42
<kyron>
ogra_cmpc, hehe...would you happen to have one?
09:43
<ogra_cmpc>
not for such old releases
09:43
<kyron>
ogra_cmpc, think I need to bother with mounting proc and sys?
09:43
hehe
09:43
<ogra_cmpc>
which tarball is that actually ?
09:43
yeah, proc at least
09:43
sys might help, not sure its needed by any package
09:44
(you can upgarde ubuntu only release by release, not skip anything inbetween)
09:44
<kyron>
ogra_cmpc, here's a good start (LOL) `deb http://localhost:3142/ca.archive.ubuntu.com/ubuntu/ edgy main restricted`
09:44
ogra_cmpc, ubuntu_6.10_i386
09:44
<ogra_cmpc>
ouch
09:45abadger1999 has joined #ltsp
09:45
<ogra_cmpc>
well, you want 7.04 then (feisty)
09:46
<kyron>
ogra_cmpc, I want a working station ;)
09:47
ogra_cmpc, for the time being I have to log off the user (can still do that since kwin was _alteady_ running)...if I press CTRL-ALT-BKSPC, it kills X but X doesn't restart!...
09:47
<ogra_cmpc>
i mean thats what you need if you want to upgrade
09:47DonSilver has joined #ltsp
09:47
<kyron>
so what is the command used to start the X daemon nowadays^
09:47
<ogra_cmpc>
it gets started by a screen.d script
09:48
<kyron>
ogra_cmpc, will I actually have such a choice?
09:48
<ogra_cmpc>
in /usr/lib/ltsp in the chroot
09:48
<kyron>
ogra_cmpc, yeah, I figured so much, I am looki...thanks ;)
09:48
<ogra_cmpc>
might well be that its broken
09:49
nobody cared for XDMCP for a long time, i think its just the ltsp 4.2 script copied over and enhanced by two or three lines
09:49
(you look for the startx script)
09:49
<kyron>
got it ;)
09:51
<ogra_cmpc>
you might have more luck with the script from the latest upstream source, i think there were some fixes recently
09:51
<kyron>
ogra_cmpc, last question, I'm no buntu adept so I don't know if I can do the following: 1- find sources.list for edgy, copy it over to root 2- run apt-get update 3- run apt-get dist-upgrade
09:51
<ogra_cmpc>
http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/files
09:52
kyron, correct
09:52
<kyron>
ogra_cmpc, well...honnestly, if X starts and displays my server's login screen (which it did), I see no reason to change the x-startup-script
09:52
<ogra_cmpc>
you said it didnt respawn
09:53
<kyron>
ogra_cmpc, it didn't respawn but a manual launch works (weird)...
09:53
and no, I am not running out of RAM :/
09:53
unless it spikes crazyly and I don't see it happen (and I don't see any OOM messages in dmesg)
09:54
<ogra_cmpc>
how much do the clients have ?
09:54
<kyron>
192M
09:55
ogra_cmpc, bummers, would seem that the only way to build an LTSP client chroot is to have an ubuntu server already built...thats...unforutnate...
09:55
<ogra_cmpc>
hmm, heavy ff webpages could eat that wiht firefox2
09:55
<kyron>
hmm...well, ff wasn't started and, as stated, no OOM messages...
09:56
<ogra_cmpc>
but thats how the design is ... that way you dont have different X versions anywhere for example :)
09:56
<kyron>
(now...I ) _am_ ASSuming OOM messages always _do_ appear
09:56
<ogra_cmpc>
i doubt you could see OOM messages, terminals usually lock up if OOM kicks in
09:56
<kyron>
ogra_cmpc, lovely :P
09:57
<ogra_cmpc>
if you still have a working console its not OOM
09:57
<kyron>
ogra_cmpc, horrible...I'll have to install [k]ubuntu unde VMware and then copy over the resulting chroot... (unless you tell me they have some sort of crazy out of root links)
09:57
<vagrantc>
!tarball
09:57
<ltspbot>
vagrantc: "tarball" is http://wiki.ltsp.org/twiki/bin/view/Ltsp/Ltsp5TarballInstructions
09:57
<kyron>
ogra_cmpc, which is the case ;)
09:57
<ogra_cmpc>
vagrantc, well, thats what he uses
09:58
<vagrantc>
ltspbot: learn tarball as while the tarballs may work for you, most of the tarballs as of 2008-03-19 are extremely old and out of date.
09:58
<ltspbot>
vagrantc: The operation succeeded.
09:58
<vagrantc>
!tarball
09:58
<ltspbot>
vagrantc: "tarball" is (#1) http://wiki.ltsp.org/twiki/bin/view/Ltsp/Ltsp5TarballInstructions, or (#2) while the tarballs may work for you, most of the tarballs as of 2008-03-19 are extremely old and out of date.
09:58
<ogra_cmpc>
vagrantc, we should wipe that page, really at least until someone wants to take care for it
09:58
<vagrantc>
ogra_cmpc: probably.
09:59
<kyron>
vagrantc, that is the exact setup I have...btw...
10:02aboo0ood has joined #ltsp
10:04
<vagrantc>
kyron: i figured.
10:04* vagrantc can never remember account info for wiki.ltsp.org
10:05
<kyron>
vagrantc, neither can I
10:05
<vagrantc>
there's a number of pages we really should update...
10:06
ogra_cmpc: for all our calls to nbd-client, we should add the "-persist" option.
10:06
<kyron>
vagrantc, shouldn't making a "tarball" be as simple as someone making one from a fresh execution of `sudo ltsp-build-client` on an ubuntu machine?
10:06
I mean...how easier can it get..
10:06steph_ has joined #ltsp
10:07
<vagrantc>
kyron: and uploading it somewhere, and maintaining it
10:08
<steph_>
ogra_cmpc: you said once that you use virtualbox. Wich virtual machine are you testing? I'm trying to use hardy but have some problems.
10:08
<kyron>
vagrantc, "maintaining" <--is there anything to actually "maintain" other than updating the tarball when a "major" release of ubuntu comes around?
10:08
<vagrantc>
with the newer versions of ubuntu, they actually ship a squashfs image, which is a read-only filesystem.
10:08
kyron: i would *love* it if *you* maintained the tarballs. :)
10:09
<ogra_cmpc>
steph_, how do you mean "which virtual machine" ?
10:10
<vagrantc>
kyron: i.e. don't tell people how little work something is unless you're willing to do the work yourself.
10:10
<steph_>
ogra_cmpc: what I call a VM is the new virtual disk created with an OS like fedora or ubuntu or what else.
10:11
<ogra_cmpc>
well, a standard virtualbox disk
10:11
4gig
10:12
do you plan to test ltsp ?
10:12
<steph_>
It says that "this kernel requires the following features not present on the cpu. 0:6
10:12
yes
10:12
<kyron>
vagrantc, could you poke at me later, like 7ish EDT, I'll build a "recent" tarball under VMware and give you a link to download it...now, this is, of course, only if the `sudo apt-get install ltsp-server-standalone openssh-server` works and `sudo ltsp-build-clien` runs successfully ;)
10:12
<ogra_cmpc>
steph_, use the alternate CD then
10:12
<steph_>
why?
10:12
<ogra_cmpc>
http://people.ubuntu.com/~ogra/ltsp-install-ubuntu.png
10:12steph_ is now known as steph__
10:13
<vagrantc>
kyron: how long can you commit to maintaining the image?
10:13
<steph__>
thanks
10:13
<ogra_cmpc>
define two NICs
10:13
<vagrantc>
kyron: how long will you provide tech support for it?
10:13
<ogra_cmpc>
one for the internal net and one for NAT
10:13
<kyron>
as much support as there is for the present TARballs :P
10:13
<ogra_cmpc>
then it will set up everythign out of the box for you
10:14
<kyron>
I'd see it as a : it's here for your personal use and pleasure...
10:14
ogra_cmpc, hey, that's good to know, will help me skip some steps while installing the VMWare machine to get the tarballs out ;)
10:14
<ogra_cmpc>
kyron, note that ubuntu stopped using nfs (nearly) two releases ago
10:15
<kyron>
ogra_cmpc, I hate you
10:15
ok,...so there go all my aspirations of building a tarball...
10:15
<ogra_cmpc>
your kernel will be misconfigured if you dont have an nbd server with the image running on port 2000
10:15
<steph__>
Yeh I know for ltsp. I installed ubuntu in vbox, but when i reboot there is an error message. That's my problem (I google it, went to #vbox). I thought you had the same experience/problem.
10:16
<kyron>
really have to go, guess I'll pick up this coversation later on tonight...
10:16
<ogra_cmpc>
kyron, well, the nbd world is way easier ... the squashfs image we use is only 140M big
10:16
and oyu can drop it just in place
10:16
<vagrantc>
well, you'll need to update ... the ssh keys and half-dozen other things
10:16
<kyron>
ogra_cmpc, ok, easyer if I have NBD on my gentoo server
10:16
<ogra_cmpc>
vagrantc, right, indeed
10:17
i dont see the other half dozen things though
10:17mccann has joined #ltsp
10:17
<vagrantc>
ogra_cmpc: try it sometimes, make a list, and we'll figure out how to deal with them.
10:17
<tarzeau>
HELP
10:17
ankara:/var/log# runlevel
10:17
unknown
10:17
<vagrantc>
:)
10:17
<tarzeau>
why does ltsp clients have no runlevel?
10:17
<ogra_cmpc>
after release :)
10:17
<vagrantc>
ogra_cmpc: i'm sure it's > 1 thing.
10:17
<tarzeau>
doesn't it run /etc/rc2.d/S99autoexec.bat ?
10:17
<kyron>
LOL
10:18
well...bbl
10:18
<vagrantc>
ogra_cmpc: probably add support for your ltsp-image-shell or soemthing like that ...
10:18
<steph__>
ogra_cmpc: it says: "use an appropriate kernel for your CPU" ??? I don't understand this message 'cause I can install it outside vbox without problems :|
10:18
<ogra_cmpc>
vagrantc, yeah
10:19
steph__, did oyu select linux 2.6 in the settings for the VM
10:19* ogra_cmpc fires up his virtualbox on the classmate
10:19
<steph__>
yep
10:20
<ogra_cmpc>
i think i leqave everything else at default
10:20
256M ram
10:20
<vagrantc>
ogra_cmpc: do you think it would be possible to add support for ltsp-image-shell to handle different filesystems ? i.e. know if it can mount the image read-write (ext2) vs. having to unpack and rebuild the image?
10:20
<ogra_cmpc>
oh, and i usually turn down the graphics ram to 2M
10:20
that forces 800x600
10:21
<vagrantc>
800x600@24
10:21
<ogra_cmpc>
yeah
10:21
<vagrantc>
1M to force it at 16
10:21
<ogra_cmpc>
makes it easier to handle the VMs if they dont blow to a huge window
10:22
vagrantc, thats trivial i think (ext2/3 support)
10:22
i have played so much with images for all that classmate stuff, i can easily touch something up ...
10:22
<steph__>
*steph changed memory size to 2M. Still a CPU features missing.
10:23
<ogra_cmpc>
no idea what that is
10:23
<steph__>
Thanks anyway
10:23
<ogra_cmpc>
did you download tha amd64 CD ?
10:23
*the
10:23
<steph__>
hope not :))
10:23
<ogra_cmpc>
well, the iso should tell you :)
10:24
<warren>
ogra_cmpc, has intel ever objected to the amd64 name?
10:24
<ogra_cmpc>
who cares :)
10:27
<vagrantc>
ogra_cmpc: sounds like my patches to nbd-client's initramfs-tools are accepted
10:28
initramfs-tools scripts, that is
10:28
<ogra_cmpc>
yes
10:28
wouter asked me if i want to merge that from debian
10:28chup has quit IRC
10:28
<ogra_cmpc>
he's such a nice chap ... dropped by in #ubuntu-devel
10:29
<vagrantc>
yeah.
10:29
<ogra_cmpc>
to sad we have beta release day
10:29chup has joined #ltsp
10:29steph__ has left #ltsp
10:29steph__ has joined #ltsp
10:29
<vagrantc>
ogra_cmpc: i'm wondering when/how/where/who we should meet up with to discuss the generic network boot initramfs-tools scripts idea
10:31
ogra_cmpc: projects i see using something are ltsp, nbd, debian-live, fai(?)
10:31
ogra_cmpc: you know of any others?
10:31
<ogra_cmpc>
d-i
10:31
even though i'm not sure they use initramfs at all
10:31
<vagrantc>
d-i doesn't use initramfs-tools, as far as i know
10:31
<ogra_cmpc>
snap
10:31
<vagrantc>
although maybe they should
10:32
boot=d-i
10:32
:)
10:32
<ogra_cmpc>
hehe
10:32
thats similar to my classmate iamge
10:32
*image
10:33
for the installer it uses a special initramfs script ... but then i have a squashfs i can mount, d-i would need an extra system
10:33
(for the rootfs)
10:33
ah, no, wait
10:33
it doesnt need one
10:33
it brings its own iirc
10:35
<vagrantc>
yay. ltsp in lenny finally works!
10:35
i'd rather wish ldm would migrate to lenny ...
10:36
but at least it's something functional in lenny.
10:36
<warren>
Wrote: /home/warren/rpmbuild/RPMS/x86_64/窓際族-1.0-1.fc8.x86_64.rpm
10:36DonSilver has quit IRC
10:36
<warren>
Disturbing thing I learned today. Unicode character names for RPM packages are legal.
10:37
<vagrantc>
awesome.
10:38
<ogra_cmpc>
cool
10:38
<vagrantc>
i think debian is [a-z0-9][a-z0-9].*
10:38
oh wait ... nooo...
10:38
<ogra_cmpc>
nope
10:39
unless your dpkg differs from mine
10:39
<vagrantc>
i think debian is [a-z0-9][a-z0-9\-\.].*
10:39
<ogra_cmpc>
that looks right
10:42
<cyberorg>
<vagrantc> well, you'll need to update ... the ssh keys and half-dozen other things
10:42K_O-Gnom has joined #ltsp
10:42
<cyberorg>
vagrantc, just the ssh keys, i moved it to tftp server too, so that is not required any more, kiwi's netboot image takes care of getting it
10:43
<vagrantc>
cyberorg: cool.
10:43
cyberorg: where does it get the kernel from?
10:43
<cyberorg>
vagrantc, pxeboot
10:43
<ogra_cmpc>
vagrantc, i have an evil idea ....
10:43
<vagrantc>
cyberorg: ah, in debian we install the kernel and build the initramfs within the chroot, just like any other debian system.
10:44
<cyberorg>
initrd and kernel both, including lts.conf ssh_known_hosts and /etc/hosts
10:44
<ogra_cmpc>
how about copying the keys into the initramfs
10:44
<vagrantc>
cyberorg: so you actually need to copy that out.
10:44
ogra_cmpc: writing a custom script to re-build the initramfs ?
10:44
<ogra_cmpc>
no, just a hook that comes with the client scripts
10:45
that pulls in known_hosts
10:45
<cyberorg>
ogra_cmpc, i suggest add it to lts.conf ssh_known_hosts=/tftpboot/somefile
10:45
<vagrantc>
ogra_cmpc: might work. wouldn't allow you to use the same initrd across multiple networks, which we do at freegeek a lot.
10:45
<ogra_cmpc>
i'm not to happy with filling up the tftp server with files
10:46
<vagrantc>
ogra_cmpc: that's why i proposed generating a single tarball
10:46* cyberorg doesn't like people burning their CPU cycles rebuilding stuff to change configuration :)
10:46
<vagrantc>
ogra_cmpc: then it can support any arbitrary file
10:46
<ogra_cmpc>
well, show me some code :P
10:47
<vagrantc>
cyberorg: indeed. that's one of the huge things i didn't like about squashfs.
10:47
<ogra_cmpc>
cyberorg, you dont needc to rebuild anything if you change configuration ... only if you change things beyond configuration :)
10:47
like installing packages
10:47
or doing non standard stuff in the chroot
10:47
<vagrantc>
ogra_cmpc: yes, but that ltsp-update-sshkeys hook called from ifup/ifdown is borked since the switch to nbd
10:48
<ogra_cmpc>
yeah
10:48
<cyberorg>
vagrantc, yesterday i got that freedom from having to rebuild
10:48
<ogra_cmpc>
thanks for reminding, i'll drop it from hardy
10:48
<cyberorg>
http://dev.compiz-fusion.org/~cyberorg/2008/03/19/kiwi-ltsp-prebuilt-images/
10:48
<vagrantc>
ogra_cmpc: i think the idea is good, but maybe it should just update a file in tftpboot
10:48
<cyberorg>
ogra_cmpc, i don't know kiwi code well, let me look where it fetches config files
10:49
<ogra_cmpc>
vagrantc, yeah, if we have something in there
10:49
<vagrantc>
ogra_cmpc: how about this ... a single file in tftpboot that gives a list of files also in tftpboot, and possible a feature to say "this is a tarball and should just be unpacked in the chroot"
10:49
<ogra_cmpc>
what creates the tarball ?
10:49
<vagrantc>
i think that gives a lot of flexibility, without a ton of code.
10:50
ogra_cmpc: maybe one of the ltsp-update-* scripts
10:50
<ogra_cmpc>
ugly
10:50
that doesnt gain us much
10:50
<vagrantc>
it does gain us the ability to append new stuff.
10:51
<ogra_cmpc>
i'd like it more tansparently, but thats hard to write in a beutiful manner
10:51
<cyberorg>
see kiwi_ltsp_setup_sshkeys() it is the same function created by you(which is above it)
10:51
https://forgesvn1.novell.com/viewsvn/kiwi-ltsp/trunk/kiwi-ltsp/ltsp/suse-11.0/kiwi-ltsp-functions.sh?revision=129&view=markup
10:51
<ogra_cmpc>
i.e. divert bash in the chroot and have a wrapper that automatically updates the tarball on exit
10:53* warren doesn't like the idea of a tarball.
10:53
<warren>
Why don't we create tftpdir/$ARCH/config/
10:53
so it doesn't clutter the base arch dir
10:53
<ogra_cmpc>
that sounds at least saner than putting them in $tftproot
10:53
<vagrantc>
warren: sounds good.
10:54
<warren>
should we move lts.conf there too?
10:54
<ogra_cmpc>
yeah
10:54
do you pull it by tftp as well ?
10:54
<warren>
OK, I'm doing that for the Fedora-specific scripts now
10:54
<vagrantc>
warren: then is that a tree of files to be installed ... i.e. tftpdir/$ARCH/config/path/to/where/it/goes/foo ?
10:54
<warren>
ogra__, I pull lts.conf currently
10:54
<ogra_cmpc>
good
10:54
<cyberorg>
kiwi has config.<MAC> and config.default which lists various configurations, including config files to fetch
10:55
<vagrantc>
what will be tricky is getting a list of all the files and where they go from the initramfs
10:55
<warren>
we want to support ARBITRARY files with this?
10:55
<ogra_cmpc>
we need a config for the config then :)
10:55
<warren>
keep in mind that the latency of using tftp really sucks
10:55
more files you grab the slower the client boot
10:56
<ogra_cmpc>
warren, well, ssh_known_hosts would actually make sense
10:56
i dont see the need for other files atm
10:56
all usual stuff can be done through lts.conf
10:56
if not thats a bug we need to fix
10:57
vagrant obviously sees a bigger need here
10:57Pascal_1 has joined #ltsp
10:57
<Pascal_1>
hello
10:57
<cyberorg>
we can keep only the files that saves us from rebuilding
10:57
<vagrantc>
warren: exactly why i think a tarball is a simple approach
10:57
<warren>
btw, how does a client get xorg.conf files?
10:58
<Pascal_1>
vagrantc: did you find an explaination for my problem ?
10:58
<vagrantc>
one tarball, one download, keeps track of all the files to install into the chroot
10:58
<ogra_cmpc>
warren, it doesnt
10:58
<vagrantc>
Pascal_1: ldm doesn't handle pam logouts properly
10:58
<warren>
it doesn't?
10:58
<ogra_cmpc>
warren, it generates them on boot
10:58
<Pascal_1>
i made some test to find what is the problem. I activate root account in the chroot then in a console i look ldm.log during connection from thin client. 2 messages stranges : at the connection : expect saw : could not create dir /root/.ssh, and no xauth data, using fake authentication data for x11 forwarding. the same when i logout.may be it could help you .
10:58
<ogra_cmpc>
configure-x.sh
10:59
<Pascal_1>
vagrantc: is there a way to make it works ?
10:59* warren wonders why we have this XFCFG crap in screen.d
10:59
<vagrantc>
warren: distributing custom xorg.conf files would be a fine example
10:59
<ogra_cmpc>
(the ugliest piece of code we have ... as interim until configless X works)
10:59
<vagrantc>
Pascal_1: please file a bug on the ldm package
10:59
<warren>
vagrantc, ok, so custom xorg.conf distribution is something LTSP currently doesn't do at all?
10:59
<Pascal_1>
what is the way to do that ?
10:59
<vagrantc>
warren: not with squashfs NBD images
10:59
<ogra_cmpc>
warren, you can put custom X configs in the chroot
10:59
<vagrantc>
warren: i mean, it supports it, but every time you add one you have to rebuild the chroot
11:00
Pascal_1: http://www.debian.org/Bugs/Reporting
11:00
Pascal_1: please use reportbug
11:00
<ogra_cmpc>
its nothing i would encourage anyway apart from working around a bug that cant be fixed in a released version
11:00
<Pascal_1>
and i explain my problem or only your contatation ?
11:01
<ogra_cmpc>
which is not a common case
11:01
so i dont relly mind if you have to resquash for that one
11:01
<cyberorg>
see http://svn.berlios.de/wsvn/kiwi/kiwi-head/doc/kiwi.pdf page 21
11:01
<ogra_cmpc>
for ssh keys it makes perfect sense though
11:01
<vagrantc>
Pascal_1: please explain your problem as completely as possible
11:02* vagrantc doesn't really understand why a tarball is so objectionable
11:02
<ogra_cmpc>
and look before if there isnt already a bug in pam_mount about the same issue
11:02
vagrantc, because you again have to roll it with an extra command
11:03
<vagrantc>
ogra_cmpc: it's almost certainly a bug in ldm's handle of pam sessions ... doesn't seem the logout hooks kick it
11:03
<warren>
ogra_cmpc, +1
11:03
<vagrantc>
kick in
11:03
<cyberorg>
vagrantc, it is also a good idea, if there are more than few files to download
11:03
<Pascal_1>
vagrantc: do you think my log explain the situation ?
11:03
<vagrantc>
so, we either hard-code support for a few specific files in a few specific locations, and download them individually ...
11:03
<ogra_cmpc>
the amount of files we pull from initramfs should not get that big that we actually need a tarball
11:03
<vagrantc>
meaning each time we fine a new file to update, we have to add support in the code
11:04
<cyberorg>
leaving it flexible so the more files can be added
11:04
<ogra_cmpc>
we can have a generic list that gets read
11:04
line a debian .install file
11:04
you add your file and add it to that list
11:04
s/line/like/
11:04
<vagrantc>
ah .,.. so path/in/tftpboot path/installed/in/root
11:05
<ogra_cmpc>
right something like that
11:05
<vagrantc>
ok, sounds good...
11:05
<ogra_cmpc>
that gets included in initramfs
11:05
<vagrantc>
in the initramfs ?
11:05
<ogra_cmpc>
and tries to pull the files by parsing the first column
11:05
<vagrantc>
should be a list on the tftp server.
11:05
<ogra_cmpc>
nah, put it in the initramgfs
11:05
one file less to pull
11:05* vagrantc objects
11:06
<vagrantc>
ogra_cmpc: your complains about updating the tarball apply to having to regenerate the initramfs
11:06
<ogra_cmpc>
not if the list is there from the beginning
11:06
<vagrantc>
anything that *might* get updated should be easily editable
11:07
<ogra_cmpc>
i mean a permanent hook
11:07aboo0ood has quit IRC
11:07
<ogra_cmpc>
do you want to make that a user configurable feature ? i wouldnt
11:08
<vagrantc>
ogra_cmpc: then we disagree.
11:08Daggett has joined #ltsp
11:09
<warren>
having to regenerate the initramfs?
11:09
<ogra_cmpc>
no
11:09
exactly not
11:09
<vagrantc>
so ... the process i see that would concede to leave out support for tarballs ...
11:09
<ogra_cmpc>
having a predefined list *we* define for files that are allowed
11:10
<vagrantc>
the initramfs downloads a list of files and where to install them to ...
11:10
<ogra_cmpc>
right
11:10
<warren>
I might also point out the increased risk of grabbing ssh_known_hosts over the network without any authentication
11:10
completely defeats the purpose of it
11:10
<ogra_cmpc>
its the public key though
11:10
<warren>
you also don't want grabbing it to be unconditional
11:10
<vagrantc>
ogra_cmpc: ok, so you're not proposing to include the list of files and wherre to install them to in the initramfs itself?
11:11
warren: well, currently we grab ssh_known_hosts over the network without any authentication.
11:11
warren: i would *love* to see a way to do that securely.
11:11
<warren>
ogra_cmpc, if you want to man-in-the-middle attack you would need to add your rogue server to ssh_known_hosts
11:11
<ogra_cmpc>
well, nfs or nbd are easily restrictable
11:11
<warren>
vagrantc, if the client chroot is loaded onto flash of the thin client
11:11
<vagrantc>
barely restrictable.
11:11
<ogra_cmpc>
well, better than tftp
11:11
<vagrantc>
warren: yeah, that's like our most common use case :P
11:12
<warren>
that is a very real scenario that I'm looking toward
11:12
For this reason I think grabbing ssh_known_hosts in this manner is short sighted
11:12
<Pascal_1>
vagrantc: i'll do that tomorrow thanks
11:13
<vagrantc>
warren: well, if you're booting off of flash, you probably shouldn't download anything off the network anyways.
11:13
<ogra_cmpc>
warren, i was resistant to that iudea since ages ... vagrant brought it up ages ago ... but its actually not harder than grabbing the nbd image an look inside there or mount the nfs root
11:13
<vagrantc>
warren: so what's the issue?
11:14
warren: i'm discussing how we handle network booting ...
11:14Pascal_1 has quit IRC
11:14
<ogra_cmpc>
indeed it adda an additional security hole
11:14
*adds
11:15
s/hole/weakness/
11:15
<vagrantc>
it's probably just as easy to inject a false ssh_known_hosts into NFS or NBD as it is into TFTP
11:15Daggett has quit IRC
11:15
<warren>
easier to have something malicious in lts.conf
11:16
<ogra_cmpc>
right, but you add an additional access point
11:16
<cyberorg>
see 15) Import fixed configuration files in http://svn.berlios.de/wsvn/kiwi/kiwi-head/system/boot/netboot/suse-linuxrc
11:16
ogra_cmpc, that is the code
11:16
<ogra_cmpc>
currently only nbd or nfs are there to grab the file ... addin tftp gives you one more open door
11:17
<warren>
Also, I personally don't have a need to grab ssh_known_hosts
11:17
<ogra_cmpc>
its like using ubuntu and adding a rootpw :)
11:17
its not less safe, but you add one ability to gain root
11:18
(with a well known account name )
11:18ccherret1 is now known as ccherrett
11:18
<ogra_cmpc>
one more point a hacker can attack ...
11:19
<vagrantc>
warren: are you using ldm ?
11:19
<warren>
yes
11:19
<vagrantc>
is it possible that your server's ip address might change?
11:20
<warren>
I think we if are going to expand grabbing of stuff from the server
11:20
then we need to add some kind of authentication
11:20
<vagrantc>
we already mount the root filesystem over an unathenticated system
11:20
<warren>
which is not absolutely required
11:20abadger1999 has quit IRC
11:21
<ogra_cmpc>
with the current code it is
11:21
<warren>
ogra_cmpc's point about yet another weakness is valid
11:21
<vagrantc>
true, but one of the primary advantages of LTSP is actually not maintaining local state on the machines
11:21
<warren>
Let's not add yet more weaknesses to the design
11:21
<ogra_cmpc>
we dont have any other method than nfs v3 or nbd yet
11:21
<vagrantc>
and you're going to be hard pressed to actually find a way to securely boot over the network.
11:21
<warren>
If we're doing this, we do it right, so we can rely on the same mechanism for a flash-based thin client without redesigning it yet agai.
11:22
<ogra_cmpc>
so for the current situation oyu are bound to unauthenticated FSes
11:22
<warren>
example: download the tarball and gpg --verify it
11:22
<ogra_cmpc>
ugh
11:22* ogra_cmpc doesnt want to run gpg in initramfs
11:22abadger1999 has joined #ltsp
11:22
<warren>
oh
11:22
I don't tftp grab during initrd
11:22
it grabs after
11:22
<vagrantc>
until you can establish a secure boot mechanism, all talk of authentication and verification of authenticity is kind of moot.
11:23
<ogra_cmpc>
ah, we grab from initramfs to set up nbd swap early
11:23
that way your client reqs drop immensely
11:24
<vagrantc>
and nicely insecure.
11:24* warren gets back to working on more immediate problems...
11:24
<warren>
btw did we hear anything more from sbalneav regarding ldm and xauth?
11:24
he said he would work on it?
11:24
<vagrantc>
warren: he said he had it working, and that's the last i heard.
11:25
<warren>
no code?
11:25
<vagrantc>
:(
11:25
<warren>
working with directx?
11:25
<vagrantc>
yup
11:25
so i hear
11:25
which is kind of a painful state to be in, seeing as that feature is *badly* needed.
11:25
or at least, wanted.
11:26
<cyberorg>
he did paste 10 line script
11:27
<vagrantc>
cyberorg: oh?
11:27
<ogra_cmpc>
warren, you know that the first thing your sshd sends out on a connection attempt is the pub key, right ?
11:27
theoretically you just need to ask the server itself anyway
11:28
<vagrantc>
warren: i did look at the way /usr/bin/startx handles xauth ... (based on hints from the fedora bug report)
11:28
<cyberorg>
http://pastebot.ltsp.org/474?hl=on&store=on&submit=Format+it%21
11:29
<vagrantc>
hey, look at that.
11:29
<ogra_cmpc>
thats the paste from scottie :)
11:30
<vagrantc>
although, that requires fixing xauth handling somewhere else too
11:30
<ogra_cmpc>
and a sweet solution
11:31
where ?
11:31
if you create the Xauthority fron the screen.d script that should just work
11:31
<vagrantc>
well, without "-ac" if you don't comment out xauth, it doesn't work with ssh -X
11:31
that will work with LDM_DIRECTX=true, but not false
11:32
<ogra_cmpc>
you need to skip the script then
11:32
<vagrantc>
i guess i'll play with it
11:41ogra_cmpc is now known as ogra
12:04
<steph__>
ogra: just for your knowledge. Using VirtualBox with hardy (sever) needs kernel-image-2.6.24-12-386-di.
12:04
<ogra>
-di ???
12:04
i'm using virtualbox here
12:04
from the package
12:05
<steph__>
Someone in#vbox told me that (for server edition). http://packages.ubuntu.com/hardy/main/kernel-image-2.6.24-12-386-di
12:05
<ogra>
-di is debian-installer
12:06
nothing you should have on a normal system
12:06
<steph__>
hummm
12:12
<ogra>
kernel package for normal users are usually not called kernel-image but linux-image
12:12
dont install that on your system
12:17bobby_C has joined #ltsp
12:29tux_440volt has joined #ltsp
12:33maticue has joined #ltsp
12:35
<maticue>
hello, i have CentOS 3.4 with kernel 2.4.21. Can i use LTSP5's tarball for this distribution?
12:36
Sorry, CentOS 3.5 with kernel 2.4.21
13:09maticue_ has joined #ltsp
13:11maticue has quit IRC
13:15staffencasa has joined #ltsp
13:17steph__ has left #ltsp
13:20abadger1999 has quit IRC
13:24mikkel has quit IRC
13:25
<vagrantc>
maticue_: well, here's what i have to say about tarballs:
13:25
!tarball
13:25
<ltspbot>
vagrantc: "tarball" is (#1) http://wiki.ltsp.org/twiki/bin/view/Ltsp/Ltsp5TarballInstructions, or (#2) while the tarballs may work for you, most of the tarballs as of 2008-03-19 are extremely old and out of date.
13:26
<vagrantc>
maticue_: so, you might be able to get them to work, but i expect you'll have problems.
13:42maticue_ has quit IRC
13:43abadger1999 has joined #ltsp
13:48
<vagrantc>
hrm.
13:48
<mnemoc>
:)
13:48
<vagrantc>
i seem to have lost track of what i was doing :)
13:49
i think i just need to stop working on features and just release ltsp for debian today.
13:49
<mnemoc>
good choice
13:51indradg_ has quit IRC
13:52indradg_ has joined #ltsp
13:54
<warren>
cool
13:54
got bootchart to work with ltsp-client with readonly root
13:54
the picture tells me what's going on
13:58
<ogra>
warren, in ubuntu i just do apt-get install bootchart in the chroot and ltsp-update-kernels afterwards :)
13:59
<warren>
ogra, yeah, you don't have readonly root which complicated this
13:59
<ogra>
but the java app that generates the png after boot nearly kills the clients
13:59
in ubuntu it writes to /tmp
13:59
no need for a RW root
13:59
(as long as /tmp is writable)
14:00xcasex has joined #ltsp
14:01
<xcasex>
ahem. what's the /opt/ltsp/images/i386.img good for? :)
14:01
<warren>
ogra, the bind mount over /tmp makes it not work
14:01
ogra, you don't have that problem
14:01
<ogra>
xcasex, its your client rootfs
14:01
<xcasex>
is it now.
14:01
hehe >_<
14:02
<ogra>
warren, ah, right, we mount /tmp in a tmpfs directly
14:02
why do you bind it ?
14:02
<warren>
well, it is bind mounted to a tmpfs
14:02
but htat happens after initrd
14:02
so it made the tmp logs of bootchart get covered up
14:02
<ogra>
why dont you mount it as tmpfs first place
14:02
<warren>
same problem
14:02
<ogra>
instead of binding it then
14:03
<warren>
same problem
14:03
ANY mount is going to make anything in that dir disappear
14:03
the /tmp mount happens after init
14:03
<ogra>
ugh
14:03
thats bad indeed
14:07tux_440volt has quit IRC
14:07tux_440volt has joined #ltsp
14:08
<ogra>
our init inside the initramfs does the mounting for the virtual FSes and /tmp actually .... things get moved later
14:09
<warren>
Interesting... according to bootchart most of my thin client's bootup is waiting on ipcalc.
14:09
<ogra>
where do you use that ??
14:10
<warren>
that's during fedora's normal initscripts
14:10
<ogra>
drop it and replace with a thin client version ?
14:11
i wonder wht it thinks it needs to compute .... you should have all IP data you need from dhcp already
14:12
<warren>
I know
14:12
i'll figure that out later
14:12* warren fixes bootchart
14:13* ogra shakes his head http://en.opensuse.org/OpenSUSE_Weekly_News/14#LimeJeOS:_The_openSUSE_based_JeOS
14:15
<laga>
huh.. suse w/o bloat?
14:15
disclaimer: i haven't used suse in years ;)
14:15
<ogra>
Similar to Ubuntu JeOS but more powerful as it is built in the Build Service.
14:17
<warren>
ah, build service makes everything better apparently.
14:18
<ogra>
yeah
14:18
even stealing names :P
14:19
well, build service apparently makes it lime ...
14:23
<warren>
SuSE Fedora, from build service.
14:23
<ogra>
heh
14:23
no
14:23
fedora_orange
14:25
<johnny>
i don't even know what jeos is
14:25
<ogra>
"build service, better because it attaches fruit to software"
14:26
<johnny>
fruit?
14:26
<laga>
fruits attract bugs, right?
14:26
<johnny>
software fruit?
14:26* johnny thinks ogra needs to go get a snack
14:26
<ogra>
johnny, they call theirs LimeJeOS
14:26
<johnny>
i don't even know what JeOS
14:26
is
14:26
sorry, i just awoke, missed the word lime in that link
14:27
<ogra>
a minimal system for software appilances
14:27
<johnny>
ubuntu is lame anyways. who cares
14:27
jk :)
14:27
<ogra>
*appliances
14:27
<johnny>
aha.. we have gnap
14:27
<ogra>
used by many ISPs
14:27
<johnny>
but for quite some time
14:28
perhaps even before i first heard of ubuntu
14:29
which was like right when it came out :)
14:29Pascal_1 has joined #ltsp
14:29
<warren>
http://pastebot.ltsp.org/474?hl=on&store=on&submit=Format+it%21
14:29
what is foople?
14:30
<johnny>
you're a foople
14:30
hehe
14:30
that's a funny word
14:30
<warren>
oh
14:30
just the xauthority name
14:31
<ogra>
scotts favorite john doe variable name :)
14:32
<cliebow_>
hehe..where thew heck is he abyway?
14:32
<johnny>
he's been around
14:32
<cliebow_>
guess it is time to go home
14:32
<johnny>
he'll be back sooon i imagine
14:32
<cliebow_>
not for i day 27 hrs and 73 niutes
14:32
<johnny>
1 day 27 hours?
14:33
<cliebow_>
and 73 niutes
14:33
<johnny>
shouldn't that be 2 days 4 hours and 13 minutes :)
14:33
of i can add..
14:33
if*
14:33
<cliebow_>
not in this parallel universe
14:34
<ogra>
and why doesnt it show the seconds, damnit ?
14:34
:)
14:34
<cliebow_>
going to let the dogs out....
14:34
uh uhuh
14:35cliebow_ has quit IRC
14:38tux_440volt has quit IRC
14:39
<johnny>
OT: right now we have a nice way of telling people not to steal our books
14:39
been thinking about replacing it with something more like this :)
14:40
For him that stealeth a book from this library, let it change into a serpent in his hand and rend him. Let him be struck by palsy and all his members blasted. Let him languish in pain, crying aloud for mercy and let there be no surcease to his agony till he sink to dissolution. Let bookworms gnaw his entrails in token of the Worm that dieth not and when at last he goeth to his Final Punishment, let the flames of Hell consume him for ever a
14:40
nd aye.
14:40
<laga>
you seem to have a serious problem with book theft
14:41
<johnny>
not really :)
14:41
a bit here and there
14:58Pascal_1 has quit IRC
15:00
<vagrantc>
johnny: i recommend heads on stakes at the door, to give it that extra umpf.
15:03
<warren>
vagrantc, ogra: what do you folks use for a DNS server for the ltsp serving interface?
15:04Gadi has left #ltsp
15:07
<ogra>
none
15:07
luckily everything operates ip based in ltsp5
15:07
so there is no need to have one
15:08
<warren>
grr
15:08
yeah I would prefer to have none
15:08
<ogra>
what for do you need one ?
15:09
<warren>
ogra, our initscript assumes you have a DNS server
15:09
<ogra>
gah
15:10* vagrantc wonders how it handles when there's no network
15:10
<vagrantc>
warren: dnsmasq makes a nice small dns server
15:11
<warren>
vagrantc, yeah looking into using it
15:11
<vagrantc>
warren: if it just needs a server to talk to ... or does it actually need a valid dns reponse?
15:11
<warren>
vagrantc, any server
15:11
<vagrantc>
i guess dnsmasq is supposed to be able to handle DNS, DHCPD and TFTPD ...
15:11
<warren>
I hear it can do most of what we need for dhcpd
15:11
but I would have to learn how to configure it
15:11
<dberkholz>
it's easy
15:11
<vagrantc>
i used to use it as a default DHCP server
15:12
<warren>
dberkholz, got examples?
15:12
<mnemoc>
dnsmasq rules :)
15:12
<dberkholz>
johnny tells me he's got a fully working config of it for ltsp
15:12
<vagrantc>
but then i switched to dhcpd 3.x just to be consistant with what most others are using
15:12
<dberkholz>
i haven't tried it with tftp yet, just dhcp+dns
15:12
<vagrantc>
warren: there's examples in the ltsp sources
15:13
warren: server/doc/examples/dhcpd-dnsmasq
15:13
<warren>
http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/annotate/wtogami%40redhat.com-20080319180844-u8zkftjixz9osbpi?file_id=dhcpdk12linux.conf-20080129180034-aiosbwg7a1bwv42c-1
15:13
can it do the stuff like: if substring (option vendor-class-identifier, 0, 9) = "AAPLBSDPC"
15:13
?
15:14
<vagrantc>
warren: there's an example for etherboot and PXE in the example
15:14
warren: so presumably you can add that
15:15
<warren>
I'll try this a bit later today.
15:15
<johnny>
i did?
15:15
oh.. for dnsmasq
15:15
yes
15:16
you can sorta do that
15:16
<dberkholz>
vagrantc: well, if debian, gentoo and fedora all did dnsmasq, that would be pretty consistent =)
15:17
<warren>
I'll try it
15:17
might be less of a pain than bind
15:17
bind + dhcpd that is
15:17
<vagrantc>
dberkholz: sure. and then we'd have goot leverage to get bugs fixed if anything wasn't up to the task :)
15:17
<warren>
ah..
15:17
<johnny>
there is a slight problem when running dnsmasq on another server and making it pass the rootpath
15:18
<warren>
ipcalc doesn't need DNS
15:18
<dberkholz>
simon kelley's really good about fixing bugs and working with people
15:18
<warren>
you can put it in /etc/hosts and it is fine
15:18
<johnny>
but on the standalone variant it's fine
15:18
<dberkholz>
(the dnsmasq dev)
15:18
<johnny>
now if only he was on irc..
15:18
<warren>
I might want to do that anyway
15:19
<vagrantc>
i think supporting ISC dhcpd *might* be a good thing just based on the huge base of existing examples, though.
15:19
kind of like why perl never dies.
15:20
<warren>
masochism is another reason why perl never dies
15:22* ogra csant use dnsmasq in the default install
15:22
<ogra>
*cant
15:22
<xcasex>
hm. shouldnt it be /opt/ltsp/i386 that's exported by nfs and not /opt/ltsp?
15:23
<ogra>
xcasex, then multiarch would require to add a line per arch
15:23
nfs properly exports the subfolders with it
15:23
<xcasex>
this is for two t5700 thin clients :) so i wouldnt have to support more than that :)
15:24
but as it is, it uhm. well. it seems not to boot the .img file but rather some weird mix of / on the server
15:24
<ogra>
xcasex, you said you use ubuntu ... there nfs isnt used anyway
15:24
<xcasex>
debian sid :p
15:24
<ogra>
oh
15:24* vagrantc will not get distracted any further
15:24* vagrantc will not get distracted any further
15:24
<ogra>
well, there are variousbugs with squashfs in debian it seems, unless you use vagrantc's newest ext3 image stuff that might be broken
15:24* xcasex show vagrantc the shiny
15:25
<xcasex>
nah its squashfs i'm using.
15:25
<vagrantc>
xcasex: i'm preparing a new upload for debian *today*.
15:25
or else.
15:25
<xcasex>
vagrantc: excellence.
15:25
vagrantc: when cna i expect it ?
15:25
<vagrantc>
xcasex: the squashfs stuff is just plain broken, as far as i know.
15:25
<xcasex>
(if it works this kinda means i can roll it out on the 3k other thin clients on the deployment project)
15:26
vagrantc: ugh so i have to go ext3 in other words?
15:26
vagrantc: is there a writeup somewhere about it?
15:26
<vagrantc>
xcasex: NFS is tried and true
15:26
<xcasex>
cool.
15:26
<vagrantc>
xcasex: http://bugs.debian.org/src:ltsp
15:26
xcasex: 466467 documents the issues with squashfs and unionfs
15:26
well, references them, anyways
15:27slashdot1x has left #ltsp
15:27
<xcasex>
vagrantc: yeah reading it right now :)
15:28
vagrantc: but im very new to thin clients. should i see the servers mounts and what not. because as it stands right now i get the debian ldm on the thinclient and when dropping to a shell i get the hostname of the server and its userland and mounted filesystems.
15:29
and i might add, none of the added apps.
15:29
<vagrantc>
xcasex: if you're new to thin clients, i wouldn't be using sid :P
15:29
<warren>
Know any any command line tools that takes an IP address and subnet mask and can print out all IP addresses within that netmask?
15:29
<xcasex>
vagrantc: tssk. new to thinclients, old to debian :p
15:29
been using debian since it forked from sls :p
15:29* warren wants to loop all IP addresses to add an entry in /etc/hosts
15:29
<vagrantc>
xcasex: ldm logs into the server, install your applications on the server itself (*not* in the ltsp chroot).
15:29
<xcasex>
Oh.
15:29
hahaha then there we have it :D
15:30
so what's the ltsp chroot good for?
15:30
<vagrantc>
xcasex: absolutely nothing.
15:30
:P
15:30
<xcasex>
bahahaha
15:30
perky bastard ;D
15:30
<vagrantc>
perky question.
15:30
<xcasex>
vagrantc: are your nipples.. stiff?
15:30* warren very confused.
15:31
<vagrantc>
xcasex: all LTSP does is boot to X, launch ldm, and log into the server to start your desktop session.
15:31
xcasex: at least, that's the default mode of operation.
15:31
<xcasex>
good.
15:31
<vagrantc>
xcasex: you can of coure tweak it to do whatever you want, within the constraints of what you could do on a normal debian system.
15:32
<xcasex>
but. i wanted a chroot :(
15:32
<vagrantc>
just need to update debian/changelog, build the package, do a little testing, and hopefully upload.
15:32
xcasex: well, you have one.
15:33* vagrantc changes the colors of irssi to be painful to look at
15:33
<ogra>
hehe
15:33
<xcasex>
hehe
15:33
*echo*
15:51oh207 has quit IRC
15:51oh207 has joined #ltsp
15:56oh207 has quit IRC
15:56oh207 has joined #ltsp
15:59
<vagrantc>
otavio: you around? we're basically using the same ltsp-client-core initscripts as upstream ships ... but i'm not sure how to rename them (upstream has different names) and i don't want to maintain them in two places anymore ... is it ok to copy them from upstream in debian/rules ... which phase would it be ok to do that in?
15:59mhterres has quit IRC
16:00
<vagrantc>
otavio: i.e. [ -f client/initscripts/ltsp-core ] && cp client/initscripts/ltsp-core debian/ltsp-client-core.init ...
16:01
or i guess i could make a custom rule that does it ... debian/rules prepare-upload
16:03alienBOB has joined #ltsp
16:03
<vagrantc>
ogra: any thoughts on that stuff?
16:04K_O-Gnom has quit IRC
16:06
<ogra>
hmm, i havent thought about using the upstream scripts yet
16:06
currently i sitll use the old ones from my package
16:06
<vagrantc>
ogra: with my current debian branch, they're identical.
16:07alienBOB has left #ltsp
16:13
<otavio>
vagrantc: you could put it in configure step of cdbs
16:13
vagrantc: but make it to fail if it doesn't exist
16:13
<vagrantc>
otavio: we're not using cdbs
16:13
<otavio>
vagrantc: so you can always know what's happening
16:13
vagrantc: anyway, during configure looks to be the right place
16:14
configure: ...
16:15
<vagrantc>
otavio: hmmm... i'm leaning towards just another script to run when building the package from bzr ...
16:16
<otavio>
vagrantc: please make it to happen automaticaly and don't commit if it's unchange
16:17
<vagrantc>
otavio: i'll just upload today with what we have and put this off for another day.
16:17
<otavio>
vagrantc: i don't think it should be commited if it's unchanged and if it's igual to the upstream one, you could simple call dh_installinit and use it
16:17
dh_installinit scriptplace
16:17
<vagrantc>
otavio: and i guess we could patch it with dpatch if needed ...
16:17
<otavio>
vagrantc: yes, exactly
16:17
<vagrantc>
otavio: we need to rename it
16:18
well, i guess we could obsolete the old names, but i'd rather not
16:18
i think they're more appropriate names for debian
16:18
<otavio>
vagrantc: do that on clean then. Doing it on clean means that the .diff.gz will have it but it'll be copied from upstream if doesn't exist
16:18markvandenborre has joined #ltsp
16:18markvandenborre has left #ltsp
16:19
<vagrantc>
otavio: copy them into place during clean?
16:19
<otavio>
vagrantc: yes
16:19
vagrantc: this is how config.guess is handled
16:19
vagrantc: take a look at packages using autoconf for reference
16:20
vagrantc: or, readme.debian of autotool-dev package
16:20
<vagrantc>
otavio: eeyk. not more autotools :P
16:20
<otavio>
vagrantc: your problem is the same they've solved
16:21
vagrantc: please take a look on the readme and you'll get it
16:21
<vagrantc>
otavio: i'd like to get this upload out today... converting to autotools is a bigger project
16:21
<otavio>
vagrantc: you _WON'T_ convert it. I said that you're having the same problem and the solution they do works for you ;-)
16:21
vagrantc: got it?
16:21
<vagrantc>
otavio: ah.
16:22
<otavio>
hehe
16:22
<vagrantc>
otavio: install the autotools-dev package and look in /usr/share/doc/autotools-dev/README.Debian ?
16:22
<otavio>
vagrantc: you worries too much auto*
16:22
vagrantc: yey! finally!
16:22
hehehe
16:22
vagrantc: yes!
16:22
<ogra>
vagrantc, did i hear you say the bad word ?
16:23* otavio thinks ogra will say: fuck you otavio!
16:23
<otavio>
hehe
16:23* ogra is scared ...
16:23Faithful has joined #ltsp
16:23
<ogra>
i saw auto*
16:23
<vagrantc>
"once upon a time, our packages were simple and worked ... and then we tried autotools ... "
16:23
<ogra>
eeek, dont please
16:24
otavio, i wouldnt express myself that harsh :)
16:26
i fear stealing code from autofoo leaves pink glowing stains on your fingers ....
16:27K_O-Gnom has joined #ltsp
16:28slipttees has joined #ltsp
16:35
<otavio>
hehe
16:35
<vagrantc>
otavio: yay!
16:36
otavio: putting them in clean target works!
16:36* vagrantc was weary of maintaining in two places
16:40
<otavio>
yes, it does
16:40
i said, they have solved same problem you're trying to do
16:42
<vagrantc>
otavio: the clean target was what i was going to try ... but seeing that at least one other project is crazy enough to do it is nice. :)
16:42
now time to see if this stuff actually builds
16:42
<otavio>
vagrantc: how big is the divergence of Ubuntu versus Debian?
16:43
<vagrantc>
otavio: well, you'll have to get ogra to push the bzr branches ...
16:43
haven't seen them since gutsy :P
16:43
<loather-work>
same answer as suse vs. redhat. -- they use the same package manager, and that's about it
16:43
<ogra>
they didnt really change
16:43
<vagrantc>
otavio: ltspfs i think is only a diff of 1 or two lines :)
16:44
<ogra>
only the ldm version
16:44
<otavio>
ogra: it would be nice to reduce it
16:44
ogra: also because it's non-sense ;-)
16:45
<vagrantc>
it's hard to get a guage on the diff's automatically provided by ubuntu, because it's usually against an old version by the time it gets submitted
16:45
<ogra>
to not want epochs in your versions is nonsense ?
16:45
<otavio>
ogra: i'm not talking about those trivial divergences but bigger ones
16:46
ogra: obviously dependencies, and other minor things will diverts
16:46
<vagrantc>
otavio: it's been very difficult to support the NBD+squashfs+unionfs method that ubuntu uses, because squashfs and unionfs in debian unstable/testing has been broken so often
16:46
<otavio>
ogra: but code, itself, i see nonsense in diverting
16:46
<jhp>
Hi everyone, can I ask just one other question here? I have some keyboard problems I can't get my hands behind.
16:46
<ogra>
otavio, right
16:46
<otavio>
vagrantc: yes, that's one thing we need to improve .. indeed
16:47
<jhp>
I have a LTSP server version 4.2 that is sollely used to provision thin clients for W2K3 Terminal Servers.
16:47
<vagrantc>
otavio: but i've been working on NBD+ext[23] and just our regular tmpfs/bind mounts and it works fine.
16:47
<ogra>
get your kernel team to fix the modules
16:47
<otavio>
ogra: that's not kernel team fault but squashfs maintainer (me included) fault
16:47
<vagrantc>
otavio: wouter just marked a couple of my patches for nbd root as pending :)
16:48
<otavio>
vagrantc: wow! great
16:48
<vagrantc>
(within hours of submitting them, no less)
16:48
<ogra>
otavio, oh, we dont have such a thing ...
16:48
<jhp>
Works like a charm, but the question came to me that not every thin client (all same hardware and same software) is responding the same way to key's
16:49
<otavio>
ogra: yes, mainly because ubuntu merges the external modules source on kernel source for building
16:49
<jhp>
And especially things like e with e with a Accent Grave or ^ on it.
16:49
<otavio>
ogra: and this, obviously, has pros and cons
16:49
ogra: hehe, as usual
16:49
<johnny>
maybe we need #ltsp-devel..
16:49
<jhp>
I want to enable the deadkey function
16:49
<ogra>
otavio, i dont care why, i just know i dont have to care and if i have probs ands a module is involved -> kernel team :)
16:50
<jhp>
So that when someone presses a ' and then a e he will get the combination
16:50
<vagrantc>
otavio: when squashfs is working again, i'd like to try with aufs as well ...
16:50
<otavio>
ogra: yes, companies works better in this case ... people working fulltime to get those in good shape makes a big difference there.
16:50
vagrantc: aufs will be a nice plus on that
16:50
<jhp>
The keyboard are normal US keyboards.
16:50
<johnny>
aufs is actually available atm as an external kernel module
16:50
sadly neither will make it itno the mainline :(
16:51
but at least i can install it..
16:52deavid has quit IRC
16:59bobby_C has quit IRC
17:00mathesis has joined #ltsp
17:01captain_magnus has quit IRC
17:02captain_magnus has joined #ltsp
17:09slipttees has quit IRC
17:10Guaraldo has left #ltsp
17:17mathesis has quit IRC
17:21
<ogra>
vagrantc, oh, latest news, configure-x.sh doesnt work with latest dash
17:22
<otavio>
hehe
17:22
<ogra>
dash doesnt acccept unquoted escapes anymore
17:22
<vagrantc>
ogra: latest being ?
17:22
<ogra>
it just silently drops the backslash
17:22
0.5.4 here
17:23
i think the "fix" was added before though
17:23
<vagrantc>
0.5.4-8 in testing and unstable ...
17:23
0.5.3-7 in etch
17:24
<ogra>
debian/diff/0043-EXPAND-Fix-slash-treatment-in-expmeta.diff added in 0.5.4-6
17:25
try setting XSERVER
17:25
and check the xorg.conf
17:25
it results in Drivert"drivername"
17:26
since i'm in beta i'll just change the shebang, but that will need proper fixing
17:28
<vagrantc>
i think we should re-think how it's done anyways.
17:29
rm /etc/X11/xorg.conf and use /var/run/ltsp-xorg.conf if we need to autogenerate a file
17:29
<ogra>
well, i was hoping X would be ready in time for intrepid so we dont need it anymore
17:30
<vagrantc>
just using X.org's autodetection unless they've specified something that requires editing the config
17:30
so much faster.
17:30
<ogra>
right
17:30
and changing config options at runtime
17:31
as well as leaving input devices to hal
17:36K_O-Gnom has quit IRC
17:41
<xcasex>
ltsp + codafs == win?
17:48johnny_ has joined #ltsp
17:50
<vagrantc>
gah.
17:50
<johnny_>
GAH!
17:50
hi :)
17:50
<vagrantc>
ever since i upgraded virtualbox, it seems to be acutely aware of when i'm testing packages that are about to be released.
17:50
<johnny_>
:(
17:50
<vagrantc>
been having problems with tftp ... but only when i'm testing packages within minutes of a release.
17:53
<johnny_>
i finally set my client to autojoin ltsp on my laptop
17:53
#ltsp*
17:53
seems like i'm gonna be here for awhile
18:12
<vagrantc>
this is crazy.
18:12
tftp is just real.... ..... ... ..... .. slow... ... ....... .. ..
18:13
it hasn't even downloaded pxelinux.0 yet
18:19
<xcasex>
wwhat's the reasoning behind using ldm over gdm?
18:19
or any *dm?
18:20
<vagrantc>
xcasex: using XDMCP is an insecure protocol, for starters
18:20
<xcasex>
yes yes but beyond that?
18:21
<vagrantc>
xcasex: it also gives us a lot more flexibility to add hooks client-side
18:21
<xcasex>
ah.
18:21
but it gives me nightmares when tryin to find information regarding the addition of sessions to it :p
18:21
<ogra>
the ssh tunnel ldm establishes is used for many different things
18:21
<vagrantc>
xcasex: it gets them from ldminfod on the server
18:22
<xcasex>
which in turn gets it form?
18:22
*from
18:22
<ogra>
you just install any package thats providing x-session-manager
18:22
they will show up
18:22
<xcasex>
so it reads the xsession.d dir?
18:22
<ogra>
vagrantc, does the sid code already get it from the .desktop files ?
18:23
xcasex, nope
18:23
<xcasex>
hm
18:23
<ogra>
it asks update-alternatives
18:23
<xcasex>
aha!
18:23
nice solution :D
18:23
<ogra>
in the old code
18:24
new code parses .desktop files from /usr/share/xsessions/
18:25abadger1999 has quit IRC
18:25
<xcasex>
actually it isnt.
18:25
hehe
18:26
i have four sessions, ssh.desktop, gnome.desktop, enlightenment16.desktop and enli(..)17.desktop
18:26
neither of which show up on the ldm list
18:26
*session list chooser
18:26
<vagrantc>
hrm.
18:27
tftpd-hpa didn't configure itself to be started from inetd, or on it's own.
18:29
heh.
18:29
well, that's much better.
18:31
<xcasex>
not for me :(
18:32
<ogra>
xcasex, ldminfod is a trivial python script, you can easily adjust it
18:32
<mistik1>
hey fellas
18:34
<xcasex>
trivial yes, working no.
18:34
<ogra>
??
18:35
xcasex, you mean you get nothing on telnet localhost 9571 ?
18:36
<xcasex>
ogra yes i do, but ldm doesnt update.
18:36
<ogra>
how do you mean it doesnt update ?
18:36
<vagrantc>
"doesn't update" ??
18:37
<xcasex>
the session chooser list still only has "default" and "failsafe xterm" listead as choices.
18:37
<ogra>
what about the language chooser ?
18:37
<vagrantc>
xcasex: do you have any packages installed on your server that provide x-window-manager or x-session-manager ?
18:38
<xcasex>
yes.
18:38
entrance & gdm
18:38
<vagrantc>
gdm is a display manager
18:38
<ogra>
thats not a session manager
18:38
<vagrantc>
xcasex: ls -l /etc/alternatives/x-session-manager /etc/alternatives/x-window-manager
18:38
<xcasex>
window managers i have a few of.
18:39
gnome-session metacity.
18:39
<vagrantc>
xcasex: could you run /usr/sbin/ldminfod and paste the output to the pastebot ?
18:39
!pastebot
18:39
<ltspbot>
vagrantc: "pastebot" is The LTSP pastebot is at http://pastebot.ltsp.org. Please paste all text longer than a line or two to the pastebot, as it helps to reduce traffic in the channel. A link to the content will be pasted in the channel.
18:39
<xcasex>
http://pastie.caboo.se/168097
18:40
<mistik1>
have you guys heard of or seen a way to force an application/user or other to connect via one IP or another on a machine with multiple devices?
18:40
<xcasex>
t would be great if you could tell me what i've been doing wrong as well if you can do so off hand, since i'd like to be able to troubleshoot it later if it pops up :D
18:40
<ogra>
looks all fine
18:40
<mistik1>
outside of a static route based on destination
18:41
<xcasex>
mistik1: mac based dhcp ?
18:41
<vagrantc>
xcasex: well, it would be useful to know how you created it.
18:41
xcasex: are there any instructions you followed? did you do anything different than the instructions?
18:41
<xcasex>
vagrantc: apt-get installed ltsp-server-standalone and yes. i followed the ones on the debian wiki
18:41
<mistik1>
xcasex: not quite like that
18:42
maybe I should investigate vlans a bit more
18:42
<vagrantc>
xcasex: seeing as i do this sort of thing typically 5 times a day ... all i can say is that those instructions work for me.
18:42
<xcasex>
damnit :(
18:43
<vagrantc>
!debian
18:43
<ltspbot>
vagrantc: "debian" is is a GNU/Linux based operating system that makes an excellent LTSP server. You can find it at http://www.debian.org. for information about LTSP on debian see http://wiki.debian.org/LTSP
18:43
<ogra>
do you have an lts.conf file ?
18:43
<vagrantc>
xcasex: the howto from there?
18:43
<xcasex>
http://wiki.debian.org/LTSP/Howto but using SID
18:43
<vagrantc>
sure
18:45
don't know what to say, without more specific information.
18:47
<ogra>
did you create an lts.conf ? do you see the locale in the languge chooser ?
18:48
<xcasex>
ogra: yes. i did; and yes i do :)
18:48
vagrantc: i dont know what to say :)
18:49
<ogra>
hmm, thats inresting, you actually see the locale ? that indicates that the info generally gets through ... just not the session info
18:49* johnny_ thinks ogra needs to go to bed
18:50
<ogra>
johnny, still running beta tests and waiting for my classmate image upload to finish
18:50
<xcasex>
ogra: yes which means that there ought to be some way to figure out the bottleneck thief.
18:52
<ogra>
i wonder if the undrescore might be an issue in enlightenment_start
18:53abadger1999 has joined #ltsp
19:05JazZz99 has joined #ltsp
19:07JazZz99 has left #ltsp
19:24spectra has joined #ltsp
19:39spectra has quit IRC
19:41mccann has quit IRC
20:19
<vagrantc>
dput ltsp_5.0.40~bzr20080319-1_i386.changes
20:19
Uploading package to host ftp-master.debian.org
20:20
xcasex: would you like to try the new packages ?
20:22
oh, you're probably one of those patient people :)
20:24
sources.list: deb http://llama.freegeek.org/~vagrant/debian unstable/
20:25
ltsp-build-client --extra-mirror "http://llama.freegeek.org/~vagrant/debian unstable/" --accept-unsigned-packages
20:25
if anyone wants to give it a whirl ...
20:31* ogra applauds
20:32* vagrantc bows
20:34
<ogra>
:)
20:34
<vagrantc>
and while i was testing it, i made a kiesh that turned out most tasty.
20:34
<ogra>
yummy
20:39
<vagrantc>
well, i'd best do something other than sit on irc for days on end working on ltsp :)
20:40vagrantc has quit IRC
20:55abadger1999 has quit IRC
21:52MacIver has quit IRC
21:54johnny_ has quit IRC
22:26tux_440volt has joined #ltsp
22:37MacIver has joined #ltsp
23:00MacIver has quit IRC
23:15MacIver has joined #ltsp
23:25subir has joined #ltsp
23:42abadger1999 has joined #ltsp
23:48vagrantc has joined #ltsp
23:52basanta has joined #ltsp