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


Channel log from 16 April 2008   (all times are UTC)

00:07
<tarzeau>
15:04 < daduke> vagrantc: FYI, this is in order to provide the LTSP live CD also on ppc
00:07
15:10 < vagrantc> daduke: you mean a single CD that does both powerpc and i386 ?
00:08
15:11 < daduke> vagrantc: well I haven't tried that yet, but I saw something about multiarch boot.... so far it's 2 images.
00:08
16:45 < daduke> vagrantc: https://www.phys.ethz.ch/~daduke/imac_ltsp.jpg
00:08
20:01 < lns> daduke, that's a lot of daisy-chained power plugs there.. =p
00:21cpunches has joined #ltsp
00:25|Paradox| has quit IRC
00:30asac_ has joined #ltsp
00:33jonkke has joined #ltsp
00:42asac has quit IRC
00:42asac_ is now known as asac
00:47|Paradox| has joined #ltsp
01:05Paladine has left #ltsp
01:06BGomes has joined #ltsp
01:09deavid has joined #ltsp
01:09mikkel has joined #ltsp
01:19|Paradox| has quit IRC
01:20|Paradox| has joined #ltsp
01:37subir has joined #ltsp
02:01johnny has quit IRC
02:11viking-ice has quit IRC
02:11viking-ice has joined #ltsp
02:46viking-ice has quit IRC
02:47exodos has joined #ltsp
02:49ogra has quit IRC
02:49ogra has joined #ltsp
03:01
<exodos>
will digital camera work out of the box with current ltsp
03:01
?
03:04Pascal_1 has joined #ltsp
03:08Pascal_1 has quit IRC
03:41mikkel has quit IRC
03:45indradg has quit IRC
03:50
<jonkke>
ogra: is there way to disable printers for some users. i have working script to change default printer, but i would like to disable all other posibilities.
04:01
<tarzeau>
exodos: there's two sorts of cameras, those with special protocol and those that appear like mass storage. the latter i guess will just work
04:03
<ogra>
jonkke, ask me after the 24th again, i dont have much time for ltsp work atm (preparing a ubuntu release)
04:08
<jonkke>
ok
04:34Q-FUNK has joined #ltsp
04:34indradg has joined #ltsp
04:39subir has quit IRC
04:48Q-FUNK has quit IRC
04:57viking-ice has joined #ltsp
05:02FLOLO has joined #ltsp
05:37ghaleb has joined #ltsp
05:37
<ogra>
hey ghaleb
05:37
<ghaleb>
hello orga :)
05:37
thank you very much
05:37
<ogra>
btw if you say ogra instead of orga my client will highlight the msg ;)
05:38
<ghaleb>
:D sorry
05:38Q-FUNK has joined #ltsp
05:38
<ogra>
currently there is only the code in the bzr branch on the webpage ... and a slightly more modified aource package in ubuntu
05:38
neither has a bakend or works
05:39
Q-FUNK, congrats :)
05:39
<ghaleb>
I see .. when you will move it to lunchpad ?
05:39
<ogra>
after ubuntu release ...
05:40
i have a good bunch of other gui tools that need code publishing as well
05:40
<Q-FUNK>
ogra: it's not over yet ;)
05:40
<ogra>
(ubuntu releases on 24th, gimme a week to recover after that and i'll take care)
05:40
Q-FUNK, well, from an RM POV it is :)
05:40
RC is tomorrow :)
05:41
<ghaleb>
ogra, could you provide , it will be extremely helpful
05:41
<ogra>
indeed
05:42
<Q-FUNK>
http://ppa.launchpad.net/q-funk/ubuntu/pool/main/x/xserver-xorg-video-geode/xserver-xorg-video-geode_2.8.0-7ubuntu1.dsc
05:42
this is what Koolu needs to eliminate the need for a BIOS completely
05:42
Jordan at AMD pulled an all-nighter to put libddc support in
05:45viking-ice has quit IRC
05:45
<ogra>
ghaleb, http://people.ubuntu.com/~ogra/gtk-build-client/ http://people.ubuntu.com/~ogra/ltsp-image-shell/ and http://people.ubuntu.com/~ogra/ltspfs-hal-root.png ... there is a lot to do and not enough hands :)
05:46
Q-FUNK, hmm, if you trigger maddog we could get that in through mark :)
05:46
he just needs to poke him a bit :)
05:47
<Q-FUNK>
ogra: he's subscribed to the bug
05:47
<ghaleb>
ogra, thank you really .. but I don't see any source code .. are u showing ideas ?
05:47viking-ice has joined #ltsp
05:47
<exodos>
ogra: i'm willing to help with ltspfs hal integration, but first i need to read more about it
05:48
<ogra>
https://blueprints.launchpad.net/ubuntu/+spec/ltspfs-virtual-hal-devices
05:49
(not very detailed yet)
05:49
<ghaleb>
any ready things .. may help in some progress
05:50
<ogra>
not really, the main work the last 6 months went into splitting the sourcecode and make it ready for other distros so we didnt do much new stuff apart from bugfixes
05:51
<ghaleb>
I see .. I hope I was available at that time ;)
05:52
okay .. it will be great if we can open any SVN or sth to trace work
05:52
ogra, please, how took these shots ?
05:53
<ogra>
ghaleb, we use bzr not svn :)
05:53spectra has joined #ltsp
05:53
<ogra>
i took the shots while working on these things
05:54
<ghaleb>
really thank you, you made a vision , don't u have any project files to start with ?
05:54
<ogra>
for most of the stuff i will even have to dig a day to find the code again
05:54
<ghaleb>
please, it will be honer to start over your work
05:55
<ogra>
iÄll be happy to ive away some of it ... i sadly have the habit to start cool things and then run out of time to finsh them if they ar not on my work plan
05:56
and with the hardy release my paid time i can ivest into ltsp sadly dropped by 80%
05:56
<ghaleb>
hehe .. it's natural ... this is why I want to start very soon to take my full horse power earlier
05:57
all of these shots are for LTSP5, right ?
06:02
<ogra>
right
06:02
i dont do ltsp 4.x
06:02* ogra goes back to get some work done ...
06:04
<ghaleb>
ogra, thank you. could we be in contact ?
06:05Pascal_Debian has joined #ltsp
06:05
<ogra>
ogra@ubuntu.com is y mail address .... and iÄm here in that channel daily ... usually during european business hours
06:06
<ghaleb>
ogra, thank you, I will be in touch
06:06
I'm going now..
06:09ghaleb has quit IRC
06:12GodFather has quit IRC
06:13
<ogra>
"Dear Mr. Grawert,"
06:13
oh ghaleb ...
06:13
now i feel old
06:19viking-ice has quit IRC
06:22TelnetManta has quit IRC
06:24ltspbot` has joined #ltsp
06:24TelnetManta has quit IRC
06:24ltspbot has quit IRC
06:25viking-ice has joined #ltsp
06:28Pascal_Debian has left #ltsp
06:36plamengr has joined #ltsp
06:48johnny has joined #ltsp
06:57praveer_cool has joined #ltsp
06:58viking-ice_ has joined #ltsp
07:01
<cyberorg>
second day of using kiwi-ltsp to do openoffice training session :) http://dev.compiz-fusion.org/~cyberorg/2008/04/15/new-effects-plugin-in-compiz-fusion-git-packages/
07:02
solid as rock, all the clients ran for about 7 hours without any problems, all running openoffice
07:05
<ogra>
you run compiz on yur clients ?
07:06
<cyberorg>
ogra, nope, i should try that :)
07:06
my laptop runs compiz
07:06
<ogra>
it works (i had it working during gutsy development for a while but didnt bother to try it more)
07:06
not even slow
07:07
<cyberorg>
yeah, compiz is not slow :P
07:07
<ogra>
well, you would think it is if you shovel tons of GL data over the net
07:07
<cyberorg>
does configure-x.sh set up xorg.conf with all the options required to run compiz on intel clients?
07:07
<ogra>
but ltsp did cope quite well
07:07
nope
07:07cliebow has joined #ltsp
07:08
<cyberorg>
oh, so what do i need?
07:08
<ogra>
it only uses what X -configure drops out and modifies that
07:08
likely the bnary module for your graphics card (inless its intel) and a proper anually set up xorg.conf
07:08
*manually
07:09viking-ice has quit IRC
07:11
<cyberorg>
hmm, configure-x.sh sould do with some improvements to handle this
07:11
does xorg.conf need manual set up with intel too?
07:12
it should just need dir, composite and aiglx enabled
07:12
*dri
07:13
<ogra>
well, in ubuntu thats default for the xserver anyway, so i dont need it in xorg.conf
07:13
<johnny>
i think we're not going to use configure-x here
07:13
<ogra>
johnny, if you write something new, please make it distro independednt
07:14
<johnny>
no.. just using what xorg does
07:14
<ogra>
(i'm al for a rewrite of configure-x.sh)
07:14
<johnny>
ie: CONFIGURE_X=F
07:14
<cyberorg>
johnny, i thought about that too and use suse's default sax2, but then we miss out on all the lts.conf parameters we can set?
07:14
<ogra>
johnny, how do you handle the ton of lts.conf options users want to have ?
07:14
<johnny>
dberkholz thinks xorg should be fixed to figure it out :)
07:15
<cyberorg>
johnny, it figures out, but we want to override certain options
07:15
<ogra>
it wont figure out if users have 20 different terminals of whch only 5 boot fine and the rest needs overrides through lts.conf
07:15
<johnny>
well.. i left it in there, but Xorg -configure -novtswitch doesn't make virtualbox happy :)
07:15
it's just forced off in the init scripts for now
07:15
<ogra>
i generally agree with h here, but X is far from having the runtime option changes implemented yet
07:15
<cyberorg>
worksforme
07:16
<ogra>
s/h/him/
07:16
xorg.conf is i ay case needed for input configuration
07:16
*any
07:16
as long as we dont have hal on the clients at least ...
07:17
(which wil be used for input later)
07:17
<johnny>
my ltsp setup is totally broken atm :(
07:17
stupid initramfs
07:17
<ogra>
initramfs is da coolness :)
07:17
<johnny>
so i can't test that addition i want yet
07:17
<ogra>
you just need proper scripts to handle it :P
07:18
<johnny>
oh.. it worked before.with nfsroot
07:19
altho the busybox it uses dosn't support some the options we need for root-server
07:19
DEFAULT bzImage ro initrd=initramfs root=/dev/ram0 real_root=/dev/nfs nfsroot=192.168.2.4:/opt/ltsp/i386
07:19
<ogra>
well, add then then :)
07:20
*them
07:20
<johnny>
the mdadm patch we have for busybox needs to be be fixed to apply to anewer busybox
07:20tux_440volt has joined #ltsp
07:20
<johnny>
and that is somewhat beyond my abilities
07:20
<ogra>
ah, you use md for image handling ?
07:20
<johnny>
no
07:21
we use this initramfs for our livecd scripts
07:21
it just happens to have enough nfsroot support to mount our livecds from another machine
07:21
<ogra>
ah
07:22mikkel has joined #ltsp
07:22
<johnny>
i need to find out why the mdadm patches haven't been applied to upstream
07:29
!meta virtualbox
07:29
<ltspbot`>
johnny: Search for "virtualbox" returned approximately 2010000 results in 0.21 seconds.[]
07:29
<johnny>
oops..
07:29
wrong channel
07:33
ogra, so, where are official tarballs going to be hosted?
07:37viking-ice_ has quit IRC
07:40slidesinger has joined #ltsp
07:42deavidsedice has joined #ltsp
07:42viking-ice has joined #ltsp
07:43Pascal_Debian has joined #ltsp
07:44viking-ice has quit IRC
07:46tux_440volt has quit IRC
07:47viking-ice has joined #ltsp
07:54Pascal_Debian has quit IRC
07:59vagrantc has joined #ltsp
08:01deavidsedice has quit IRC
08:01Pascal_1 has joined #ltsp
08:03mhterres has joined #ltsp
08:03Pascal_Debian has joined #ltsp
08:07Pascal_1 has quit IRC
08:07Pascal_Debian has quit IRC
08:13loather-work has quit IRC
08:17loather-work has joined #ltsp
08:28Pascal has joined #ltsp
08:31Bengoa has joined #ltsp
08:35Pascal has quit IRC
08:35K_O-Gnom has joined #ltsp
08:36Gadi has joined #ltsp
08:36
<Q-FUNK>
ogra: well, the libDDC patch breaks other hardware.
08:36
Gadi: saw the list message about libDDC?
08:37
<Gadi>
yes - does this patch only work on hardy and after?
08:37
or can I test against gutsy?
08:38
<Q-FUNK>
hardy
08:38
it's against -geode
08:38
I have packages in my PPA
08:40
here, it freezes the thincan dead, on a unit with general software
08:43
<Gadi>
cool
08:47plamengr has left #ltsp
08:56BGomes has quit IRC
09:06Guaraldo has joined #ltsp
09:06elisboa has joined #ltsp
09:09bricode has joined #ltsp
09:25indradg has quit IRC
09:25
<Q-FUNK>
bricode: any luck with the test driver I uploaded to my PPA?
09:25FLOLO has left #ltsp
09:26
<bricode>
Q-FUNK: Haven't tried that specific one.
09:27
Q-FUNK: I tried a patch that Jordan gave to me yesterday with success against 2.8.0 tarball.
09:27
Q-FUNK: Success on DTRI/Insyde and FIC/Award
09:27
<Q-FUNK>
ok
09:27
<bricode>
Q-FUNK: Am testing same platforms on LTSP
09:27
<Q-FUNK>
here, it freezes our GSW hardware dead
09:27
<bricode>
Q-FUNK: Yeah, I saw that. Could it be a GPIO mapping difference?
09:28
<Q-FUNK>
the package I uploaded uses the current hardy packge, plus jordan's patch.
09:28
maybe
09:29
we haven't studied the patch yet
09:29
<exodos>
Q-FUNK: will you try to include this version in hardy?
09:29
if so I can help with testing
09:29
<Q-FUNK>
i just churned out a test package based on that patch and saw that it crashes our thincan
09:30
<bricode>
Q-FUNK: It uses an I2C bus which is GPIO pin dependent from what I gather.
09:30
<Q-FUNK>
exodos: it's in my PPA
09:30
bricode: that makes it completely hardware-dependent, then
09:31
exodos: we cannot upload into Hardy until it's verified to work on eveyr platform we can get our hands on.
09:32
but there are test packages built for Hardy in my PPA
09:33
https://launchpad.net/~q-funk/+archive
09:34
<warren>
On Debian/Ubuntu does jetpipe run on every client?
09:34
<johnny>
seems so
09:34
<warren>
that seems a bit wrong?
09:34
<johnny>
only a little bit
09:34* vagrantc attempts to confirm
09:34
<Q-FUNK>
ok. bbl
09:34
ciao! :)
09:34Q-FUNK has quit IRC
09:34
<johnny>
far down the list of my concerns atm
09:34
<ogra>
warren, if PRINTER_0_DEVICE is set to something, yes
09:34
<warren>
in lts.conf?
09:35
<ogra>
yep
09:35
<johnny>
ogra, i don't see that in the initscripts
09:35
<warren>
ok, so default it isn't run then.
09:35
<johnny>
maybe i missed it.
09:35
<ogra>
johnny, in the ltsp-client-setup initscript iirc
09:35
warren, correct
09:35
<vagrantc>
warren: it only runs if PRINTER_*_DEVICE is set
09:35
<ogra>
there was an attempt from scottie to start it by udev iirc
09:35
<warren>
ok just checking
09:35
<johnny>
oh. i see it
09:35
<vagrantc>
which is not set by default.
09:36
<ogra>
but no code, just an idea
09:36
<johnny>
uggh.. something happened to my virtualbox
09:36
<ogra>
which would be the right thing to do imho ...
09:36
<johnny>
keep getitng noip :(
09:36
<ogra>
together with a script that triggers the desktop side for autoconfig
09:36
<vagrantc>
actually, scotty re-wrote it in C
09:37
i've never really had printers to test with, though.
09:37
and printers are such obnoxious machines anyways...
09:38
<ogra>
wood wasters
09:38* cyberorg agrees
09:38
<johnny>
lol
09:38
<vagrantc>
ecological issues aside, they just seem to break so easily.
09:38
which i guess is an ecological issue in and of itself, but also a maintenance headache...
09:38
<ogra>
my usb printers over here all work fine
09:38
<johnny>
when i lived at home..
09:38
<ogra>
even the GDI one
09:38
<johnny>
guess who fixed the printers..
09:38
<cyberorg>
i am using hp dj 400 since last decade
09:38
<johnny>
my mom
09:38
<laga>
i fondly remember the incident where i just smashed a printer. felt very good.
09:39
<johnny>
i could never get the inkjet ones of the past to pull their pages
09:39
<cyberorg>
but i hate it
09:39
<johnny>
my mom always had to do it
09:39
<vagrantc>
anywhere where you see several hundred pages a day, week after week, is bound to have printer problems regularly.
09:39
<johnny>
luckily we have a nicer one here :)
09:39
<ogra>
i think i used a printer twice during the last year to print out a trainticket with barcode ...
09:39
<vagrantc>
heh
09:40
<johnny>
my gf uses the printer
09:40
as a public school teacher
09:40
she prints out lesson plans and stuff
09:40
worksheets
09:40
<ogra>
she should teach to not use it then ;)
09:40
<johnny>
so she can copy them
09:40TelnetManta has joined #ltsp
09:41
<johnny>
her school has like 5 computers or something
09:41
it's pretty limited
09:41
inner city schools have no money
09:41
<ogra>
use edubuntu and make html forms for tests :)
09:41
<johnny>
i'd like to take some of microsoft's money there
09:41
<ogra>
5 is fine just teach them how to line up properly as well *g*
09:41
<johnny>
yeah..
09:42
<vagrantc>
whoah, new lenny installs set the quiet flag by default!
09:42
<ogra>
nice
09:42K_O-Gnom has quit IRC
09:42mccann has joined #ltsp
09:43
<vagrantc>
"where's my gibberish!?!"
09:43
<ogra>
so its only one or two years to go until debian uses userspace splash :)
09:44
warren, does fedora use a splash by default ?
09:44
<vagrantc>
i had to do a clean install to try and figure out why i put xbase-clients as a dependency of ltsp-server-standalone ... becuase xbase-clients is now split into smaller packages
09:44
<warren>
ogra: when?
09:44
<ogra>
during boot
09:45
<warren>
when exactly?
09:45
<ogra>
vagrantc, hmm, any idea why they dont have proper transitional packages ?
09:45
<johnny>
so.. who here uses a distro other than the one they hack on..
09:45
<ogra>
warren, between grub and gdm indeed :)
09:45
johnny, i have a debian woddy server in the basement :)
09:45
<warren>
ogra: we have this crappy thing called rhgb that uses X to display a graphical progress meter with optional button to see the text flying by
09:46
ogra: we're soon ripping it out due to kernel mode setting
09:46
<ogra>
uh, weird
09:46
<warren>
(*fb has always been far too unreliable)
09:46
<ogra>
works just fine in ubuntu with usplash
09:46
<warren>
on many machines yes
09:47
but not all
09:47
our X developers want us to stop building all *fb modules
09:47
we ripped a few out during F9 cycle
09:47
<johnny>
uggh.. No IP.No IP.No IP.
09:47
:(
09:47
i think something went funky in my briding
09:47
<ogra>
isnt dropping fb bad for 2D accel in X on some cards ?
09:48
<vagrantc>
ogra: they do have transitional packages, but they're attempting to clean up the dependency trees before releasing
09:48
<warren>
I don't know the full story
09:48
<ogra>
i think matrox needs it for example
09:48
<warren>
AFAIK we haven't been loading any *fb module by default in a long time now
09:48
talking years
09:48
<Gadi>
I have only found usplash to crap out on Geode GX2
09:48
<vagrantc>
ogra: so it's not going to break, but it's just cleaner if we figure it out now.
09:48
<ogra>
vagrantc, tsk ... what for do they make transitional packages at all then :P
09:48
<Gadi>
usplash works fine, but it won't die
09:48
<ogra>
you could just add a provides
09:48
<Gadi>
:)
09:48
<vagrantc>
ogra: for upgrades
09:49
<ogra>
i know ...
09:49
<vagrantc>
ogra: it will technically be handled correctly even if i don't figure it out, but it would be nice to figure out what we actually want.
09:49
<ogra>
but since they are there anyway for this release its just sily to require to switch just now
09:49
<warren>
confirmed that cdpinger segfaults only on my via thin clients
09:50
<ogra>
i could understand it for next release if they want to drop the transitional package
09:50
but as long as thats there, who cares
09:50
<vagrantc>
well, it's not RC, and i don't think it will be RC.
09:50
<ogra>
ah
09:50
<vagrantc>
i care
09:50
:P
09:50
<ogra>
i thought it was
09:50
<vagrantc>
because i'd rather have the smallest dependencies that actually accomplish what i want.
09:51
<ogra>
vagrantc, all we wanted the dep for was to make sure xterm and Xsession are tere
09:51
<vagrantc>
and i've got some months to figure it out.
09:51
<ogra>
(xterm due to bein a hardcoded default in ldm atm)
09:51
<vagrantc>
the failsafe xterm ?
09:51
<ogra>
yeah
09:51
<vagrantc>
just to have *some* sort of session
09:52
<ogra>
to have a working fallback in any case
09:52
<vagrantc>
could just pick something like gnome | x-session-manager | x-window-manager
09:52
<ogra>
x11-common still has Xsession for me
09:52
<vagrantc>
yeah, same here.
09:53
<ogra>
that should be a dep of ltsp-server
09:53
the others rather -standalone
09:53
<vagrantc>
no.
09:53
ltsp-server just provides the root filesystem, nothing else.
09:53
<ogra>
no ?
09:53
hmm
09:53
<vagrantc>
that's my primary use case.
09:54
well, root filesystem, and enough to boot to the root filesystem
09:54
<ogra>
well, then indeed for me a -desktop dep would make most sense
09:54
<vagrantc>
tools to create, maintain and boot to the root filesystem ...
09:54
<ogra>
right
09:54
the core
09:55
<vagrantc>
-standalone is for a full-blown server
09:55
and now we can actually use recommends the way they were intended.
09:56indradg has joined #ltsp
09:59pscheie_ has quit IRC
10:01pscheie_ has joined #ltsp
10:07Pascal_1 has joined #ltsp
10:10
<Gadi>
has anyone here played with adding the "-persist" flag to nbd-client?
10:10
would this allow a client to continue upon server reboot?
10:10
(without rebooting the client)
10:11
<warren>
isn't that to write block changes to another nbd?
10:11* Gadi is unsure - it is not well documented
10:12
<Gadi>
appears in the usage on the man page, but there is no further explanation
10:13
<vagrantc>
Gadi: i actually asked the debian maintainer about that ... i forget what they said ... i can dig it up in an email.
10:13
Gadi: it's used in the nbdroot code that comes with newer versions of nbd-client
10:13
<cyberorg>
everything to do with filesystem and persist is about writing
10:14
<Gadi>
ah, ok
10:14
<cyberorg>
at least on kiwi we have persistent file system where users can store their work, for example in usb boot
10:15
<vagrantc>
"If you specify that option, then nbd-client will immediately try to
10:15
<Gadi>
from my few tests, it seems that rebooting the server leads to squashfs read errors on the client
10:15
<vagrantc>
reconnect the device upon disconnection. Future kernels will also block
10:15
reads and writes to or from the device until the client exits, so the
10:15
<Gadi>
so, the client needs to be restarted
10:15
<vagrantc>
-persist option will then even not lose some reads or writes. This
10:15
should improve reliability over temporary network failures."
10:15
<Gadi>
ah, then maybe with newer kernels, it would help?
10:15
s/newer/future/
10:16
<vagrantc>
newer than any that currently exist :)
10:16
<ogra>
Gadi, i was told in hardy it autoreconnects but didnt test that
10:16
<Gadi>
ah, ok
10:16
<ogra>
but i had some reports
10:16
<vagrantc>
the only thing i would fear is overly agreesive reconnects
10:16
<Gadi>
me, too
10:17
I wonder, since we use unionfs, whether we could add code to remove it from the union, and retry to establish a connection at some interrval and then add it back to the union
10:18
<ogra>
well, remove it from te union and replce it with what ?
10:19
its your filesystem ...
10:19
<Gadi>
well, the filesystem would freeze until it reconnects
10:19
but, at least it would reconnect on its own
10:19
better than having to reboot 100 terminals by hand
10:19
:)
10:20
<vagrantc>
i guess klausade does same neat tricks with wake-on-lan to reboot machines
10:20
<laga>
reboot-on-lan? scary
10:20
<Gadi>
if ur client support w-o-l
10:20
...and I dont think you can reboot with w-o-l
10:21
just boot
10:21* Gadi has been looking into SNMP for remote reboots and such
10:21
<Gadi>
but not too much as yet
10:22
<johnny>
hmm..
10:22
<vagrantc>
i get the impression klausade has them shutting machines down and turning them on on a schedule.
10:22
<Gadi>
anyway, it would be nice to obviate the need for remote reboots, tho
10:22
<vagrantc>
using wake-on-lan. but i didn't actually see it with my own eyes and network sniffers.
10:24
<johnny>
can somebody help me fix my vbox? :)
10:24
the problem isn't vbox prolly tho..
10:24
<ogra>
do you use the internal network between two VMs ?
10:24
works fine here that way
10:25
i havent tried other setups
10:25
<vagrantc>
hrm... maybe the shutdown was with ssh ...
10:25
<johnny>
i have it working with briding
10:25
bridging
10:25
or rather.. had it working
10:26
i see it discovering..
10:26
<ogra>
with tun/tap or real bridges ?
10:26
<johnny>
my server offers
10:27
oh noes
10:27
i found the problem i think
10:27
when i upgraded to the new openrc.. it killed my network config file
10:27
i prolly have an rcs backup tho
10:27
let's hope..
10:28
oops.. guess not..
10:36Pascal_Debian has joined #ltsp
10:39mccann has quit IRC
10:46
<vagrantc>
ogra: did you come up with anything decent regarding LDM_DIRECTX and local devices?
10:46
<warren>
vagrantc: oh that doesn't work currently?
10:48
<ogra>
vagrantc, nope, not yet https://bugs.launchpad.net/ubuntu/+source/ltspfs/+bug/218231
10:48
<vagrantc>
warren: the "-ac" fixes broke it
10:48
<ogra>
i fear that has to go into 8.04.1
10:49
<vagrantc>
hoping to do a new round of uploads into debian, wanted to see if i could address that issue
10:49
<warren>
I haven't even tried to get local devices working yet
10:49
<ogra>
i'm not sure i'll find time to even look deeper before release
10:49
i know what to do though
10:50
i mean, you do as well, we discussed it :)
10:50
<warren>
ogra: got a short description?
10:50
<ogra>
warren, ltspfsd sues an mcookie stored as xatom in your root win for auth
10:50
*uses
10:51
<vagrantc>
ogra: yeah, it's just trying to figure out how to do it elegantly.
10:51
<ogra>
warren, add/remove_fstab_entry dont know about the DISPLAY with LDM_DIRECTX .... ssh -X just creates a new X proxy on localhost:something
10:52
which isnt the display the cookie is stored on
10:52
<vagrantc>
ogra: actually, that's not quite it ...
10:52
<ogra>
so ltspfsd denies the mount because it doesnt get the cookie data in the end
10:52
<vagrantc>
ogra: it actually attempts to connect to the display, but it fails to do so.
10:53
<ogra>
well, not currently
10:53
<vagrantc>
ogra: yes, currently.
10:53
<ogra>
we default to ssh -X
10:53
which creates a new display in any case
10:53
(in add/remove)
10:53danthux has joined #ltsp
10:53
<vagrantc>
with ssh -X, it creates a proxy and attempts to connect to a proper DISPLAY, but the connection is refused due to incorrect xauth data or something.
10:54
<ogra>
its just that with ssh -X this proxy proxies the display of the socket connection
10:54
<vagrantc>
it's the same reason why without LDM_DIRECTX, if we set up xauth cookies and such, it fails to work.
10:54
<ogra>
(if there is -X used)
10:54danthux has left #ltsp
10:54
<vagrantc>
in any case, it's borked.
10:55
<ogra>
i think we mean the same but express it differnently
10:55Pascal_Debian has quit IRC
10:55
<warren>
wait
10:55
<vagrantc>
i'm not sure we mean the same thing...
10:55
<warren>
it currently works without LDM_DIRECTX?
10:55
<ogra>
we need check for LDM_DIRECTX in the add/remove scripts
10:55
yes, it works fine without
10:55
<vagrantc>
there's a difference between connecting to the wrong display, and attempting to connect to the right display but being refused.
10:55
<ogra>
add the DISPLAY to the ltspfsmounter call
10:56
in case its set
10:56
and drop -X from ssh
10:56
<cyberorg>
would italc work with ldm ssh?
10:56
<vagrantc>
extra credit for handling multiple LDMs on a single thin-client
10:56
<ogra>
cyberorg, in ubuntu it does
10:56
i think you need 1.7 at least for stgraber's ltsp fixes though
10:57
<cyberorg>
ogra, ok, any extra config required in chroot?
10:57
<ogra>
nope
10:57
you need italc-client in the sessions ...
10:57
<cyberorg>
ok, will test it out, we use the same ldm as you
10:57
<ogra>
and indeed set up the keys properly :)
10:57
<vagrantc>
ogra: almost seems like *_fstab_entry and rc.d/*delayed-mounter need to just source a vtN specific file in /var/run or something that ldm leaves behind.
10:58
<cyberorg>
k
10:58
<ogra>
vagrantc, we just need to add the display to the socketname in a better way
10:58
so in case LDM_DIRECTX is set we just grab it from there
10:58
<stgraber>
cyberorg: italc runs entirely on the server side so LTSP doesn't affect the way it works that much
10:58
<vagrantc>
ogra: sure...
10:59
<stgraber>
cyberorg: ideally ica (the client part) should run directly on the clients to save some bandwidth and CPU
10:59
<vagrantc>
that socket name is getting awfully long... :)
10:59
<ogra>
well, its two more digis
10:59
*digitd
10:59
grmblfjx
10:59
<cyberorg>
stgraber, ok, we are interested in getting it integrated with GUI ltsp manager we are planning for SOC
10:59
<vagrantc>
ogra: well, have have to add the ip address as well
11:00
ogra: or re-implement that in the ltspfs hooks
11:00
<ogra>
thats in the socketname already
11:00
<vagrantc>
that's the server's ip address
11:00
<ogra>
even half the display is in there
11:00
<vagrantc>
we need the client's ip address
11:00
<ogra>
oh, damned, right
11:00
indeed
11:00
<stgraber>
cyberorg: I have an improved version of iTalc in edubuntu-italc-devel's PPA which uses avahi to detect workstations, so it works with local (LTSP) and remote (LAN) workstations
11:00* ogra is to distracted by CD tests
11:01
<vagrantc>
i should have some real time to look at it next week or later this week
11:01
<cyberorg>
stgraber, do you know which one is on opensuse-edu?
11:01
<ogra>
for me it depends on my sideprojects
11:01
i have a lot to do for classmate still
11:02
if i have a gap i'll take a look, else it has to wait for after release
11:02
<stgraber>
cyberorg: no idea, last upstream is 1.0.7 and Ubuntu is using some kind of pre-1.0.8 (patched 1.0.7)
11:04
<cyberorg>
stgraber, "iTALC was updated to 1.0.7 and adapted to integrate better in openSUSE" from http://news.opensuse.org/2008/04/06/opensuse-education-10-rc2-for-opensuse-103-is-ready/
11:05
i'll check with kl_beiser what exactly he's put in
11:06
<stgraber>
cyberorg: if you have a link to the patch that's been applied, ping me. I have done some UI changes for Ubuntu but maybe there are some more I can steal from SuSE :)
11:06bricode has quit IRC
11:07
<cyberorg>
stgraber, you can get each and every patch and tarball that goes in suse here :) https://build.opensuse.org/
11:07Pascal_1 has quit IRC
11:08
<cyberorg>
https://build.opensuse.org/package/show?package=italc&project=Education%3Adesktop
11:10* stgraber wonders why rpm is in Ubuntu main ...
11:10
<jcastro>
lsb probably?
11:11exodos has quit IRC
11:11
<ogra>
at least its not installed anymore
11:11
we had it in the default install fo a while iirc
11:12Pascal_1 has joined #ltsp
11:12bricode has joined #ltsp
11:12
<Pascal_1>
hello
11:13
<stgraber>
cyberorg: do you see any patch except the amd64 one ?
11:13
<cyberorg>
stgraber, nope
11:13
see the .changes file that is the last changelog from lars
11:15
<stgraber>
ok, so that's clean upstream italc with a rc script and the amd64 patch
11:15
<cyberorg>
stgraber, where is your patch?
11:15
would you be upstreaming it?
11:16
<stgraber>
1.0.6 included 90% of our patches, the remaining can be found in our bzr branch, wait a sec I'll paste the url
11:17
cyberorg: http://bazaar.launchpad.net/~edubuntu-italc-devel/italc/italc-hardy/files/stgraber%40ubuntu.com-20080416070608-lp9z3la9er7862qt?file_id=patches-20071103174405-a8ykas0cli9l9ss1-1
11:17
cyberorg: 01 is identical to yours, 02 is our UI changes
11:17abadger1999 has quit IRC
11:17
<cyberorg>
stgraber, ok, that applies to 1.0.7 ?
11:18
<stgraber>
yes
11:18
<cyberorg>
ok, cool, i'll let lars know, any plan for upstreaming it?
11:21
<stgraber>
no, that's the changes Tobias doesn't want :)
11:21staffencasa has joined #ltsp
11:21
<stgraber>
he says his Windows users want all those login stuff and help bubble popping everywhere :)
11:21
<cyberorg>
ah :( it is pain to maintain patches that upstream doesn't want
11:22daduke has quit IRC
11:23
<stgraber>
I plan to move my execute window fix upstream soon as there is no point in having a multiline input field when you can only run one command at a time
11:23
and perhaps ask for a clean way to disable those domain login on Linux (there is currently no clean way to do it)
11:24
<cyberorg>
ok, cool, i know what i have to do next :) get italc-client running in ltsp image for next release
11:24
<stgraber>
stuff like the systray icon and help bubbles are easy to disable
11:25abadger1999 has joined #ltsp
11:26
<ogra>
stgraber, it could become an ifdef'ed patch :)
11:36|Paradox| has quit IRC
11:42bricode has quit IRC
11:57Pascal_Debian has joined #ltsp
12:02tux_440volt has joined #ltsp
12:13Pascal_Debian has quit IRC
12:13Pascal_1 has quit IRC
12:13mccann has joined #ltsp
12:19daduke has joined #ltsp
12:24praveer_cool has quit IRC
12:36ghaleb has joined #ltsp
12:36
<ghaleb>
hello, please, what is the best quick way to have a centralized authentication for 100 user ?
12:37tux_440volt has quit IRC
12:39
<johnny>
ldap probably..
12:40
<lns>
ghaleb, unless you're using multiple servers, I don't see a problem with /etc/passwd...
12:40
I've got single-site servers with 200+ users on it using normal passwd auth, no issues
12:41
<ghaleb>
lns, yes. multiple servers
12:41
I need to manage home directories as well
12:41
<lns>
ghaleb, then yes - ldap probably - google 'fds' or 'fedora directory server'... or if you have M$ AD/Domains, you can use SMB/Domain auth
12:42
Hardy supposedly will support easy Domain/AD auth OOTB
12:42
sorry..ubuntu only
12:42
<ghaleb>
well, I have tried LDAP.. but it caused lots of problems with PAM
12:42* lns keeps forgetting sometimes people use distros other than his
12:43
<ghaleb>
so, I'm trying to find quicker way
12:43deavid has quit IRC
12:44
<lns>
ghaleb, can't you simply point all servers to one server for auth, no matter what the method?
12:44
<johnny>
that is the proper way..
12:44
you can fix your pam issues
12:44
<ghaleb>
johnny, thank you .. but when time is limited .. I have to look around for quick way
12:44
<lns>
I agree, being someone who knows very little about LDAP, it's intimidating and difficult to set up
12:44
<ghaleb>
lns, exactly
12:44
<johnny>
i don't know much about ldap either
12:45
i just know that is what i would use
12:45
<lns>
ghaleb, the thing is, if you're doing an elaborate setup like multiple servers with single-auth setup (i know that's the wrong term), it's going to take a little more than "quick n dirty" as you want it
12:45
no matter what the method
12:46
<ghaleb>
lns, I'm looking for this point. can we refer to ONE authentication file ?
12:47
<lns>
ghaleb, i thought i read a long time ago that PAM can point to an alternate server for passwd auth, but i can't say for sure
12:47
<ghaleb>
johnny, have u make it .. using PAM I mean ?
12:48
<lns>
a google would confirm
12:49
<ghaleb>
lns, thank you .. I will.
12:52Pascal_1 has joined #ltsp
13:12toscalix has joined #ltsp
13:16ghaleb has quit IRC
13:16ghaleb has joined #ltsp
13:18deavid has joined #ltsp
13:19staffencasa has quit IRC
13:33Pascal_1 has quit IRC
13:33Pascal_1 has joined #ltsp
13:38Pascal_Debian has joined #ltsp
13:54Pascal_Debian has quit IRC
13:55viking-ice has quit IRC
13:56Pascal_1 has quit IRC
13:57mistik1_ has joined #ltsp
13:59mistik1 has quit IRC
13:59mistik1_ is now known as mistik1
13:59
<slidesinger>
but is mistik1 really here?
14:19
<lns>
Is anyone really "here" ? =)
14:26
<Egyptian[Home]>
no boss, just us ghosts
14:27toscalix_ has joined #ltsp
14:29ccherret1 has joined #ltsp
14:30ccherrett has quit IRC
14:31Q-FUNK has joined #ltsp
14:33efra has joined #ltsp
14:40Egyptian[Home] has quit IRC
14:40toscalix has quit IRC
14:42Egyptian[Home] has joined #ltsp
14:50viking-ice has joined #ltsp
14:50cliebow has quit IRC
14:52Q-FUNK has quit IRC
14:57Guaraldo has left #ltsp
15:03Q-FUNK has joined #ltsp
15:05IRCzito has joined #ltsp
15:05
<IRCzito>
warren: are you here?
15:07
I'm try understado Fedora initrd for LTSP, ad under init script exist this line "network --device eth0 --bootproto dhcp" but i dont found network (binary/script)
15:09
<warren>
IRCzito: all the commands in there are internal to nash library if there is no binary or script
15:09
IRCzito: that's done to keep the initrd size as small as possible
15:09Q-FUNK has quit IRC
15:09Q-FUN1 has joined #ltsp
15:10Q-FUN1 is now known as Q-FUNK
15:12TelnetManta has quit IRC
15:15
<IRCzito>
warren: how initrd get ip?
15:15
<warren>
IRCzito: in that case, DHCP
15:15
<IRCzito>
warren: ubuntu, use ipconfig, and i dont fount it on fedora
15:16
<warren>
IRCzito: different distros use every different things
15:16
IRCzito: initrd is special in that it is different from fedora distro itself, although it does link to library versions of various thinks like dhcp lib.
15:17
<IRCzito>
so Fedora initrd contain dhcp libs bult in?
15:18
Exists some doc about this process?
15:20
<warren>
IRCzito: unfortunately no
15:20
IRCzito: initrd images are not meant to be dissected manually. You are supposed to use mkinitrd to generate a different one. If mkinitrd can't do it then you need to edit it, then file a bug with a patch.
15:24
<IRCzito>
warren: tanks, I and Friends work in initrd for Slackware.
15:25
<warren>
IRCzito: then you should be looking at mkinitrd's source code
15:26
<IRCzito>
warren: but on slackware no have a way to use dhcp on default initrd :(
15:27ghaleb has quit IRC
15:30efra has left #ltsp
15:32toscalix_ has quit IRC
15:34
<warren>
IRCzito: then you have to figure out how other distros do it
15:35toscalix has joined #ltsp
15:36mikkel has quit IRC
15:40
<Q-FUNK>
heh
15:40
seems that leilo got the bridge to work :)
15:41
leio,
15:42
<leio>
now if it'd act as something more than a switch and allowed to restrict that WLAN a bit... ;p
15:43
<johnny>
?
15:45Guaraldo has joined #ltsp
15:47
<Q-FUNK>
leio: :)
15:52toscalix has quit IRC
15:59Bengoa has quit IRC
16:03J45p3r has joined #ltsp
16:04mhterres has quit IRC
16:17* vagrantc uploads ltsp 5.1.3 to debian
16:17
<vagrantc>
warren: haven't yet had an excuse to tag my own version :)
16:20
<Q-FUNK>
Gadi: new test package should be in my PPA now
16:22
<klausade>
vagrantc: hello (been up-north working). yes, we use wol on all clients that supports it, together with automatic shutdown after schoolhours.
16:22
<vagrantc>
klausade: up late working too, no? :)
16:25
<klausade>
vagrantc: kind of been working since monday evening, just left the plane and i'm home again. will not work long now.
16:25
<vagrantc>
klausade: how is the automatic shutdown implemented?
16:28
<klausade>
vagrantc: by using ssh in the chroot togheter with ssh-keys for root. then basically just "ssh root@client init 0" in a cronjob that start about 16:00 there is also some checks to see if there is actually someone logged in.
16:29
<vagrantc>
klausade: right, now i remember.
16:29
should probably set that up at freegeek.
16:30
<klausade>
vagrantc: the scipts run 16-23 shuting down unused clients, then after that they all are shutdown, most places.
16:31
<vagrantc>
klausade: how sophisticated are the shutdown checks?
16:31
klausade: er, knowing that a user is logged in
16:33
<klausade>
vagrantc: ssh root@thinclient "ps auxw |grep blowfish|grep -v grep|cut -d" " -f1|grep -q root||shutdown -h now"
16:33
vagrantc: thats what I use at home, i belive that ugly hack is also used elsewhere.
16:33
vagrantc: but hey, it works.
16:33
<vagrantc>
klausade: ah, these are diskless workstations??
16:34
<klausade>
vagrantc: nope, pure thin clients. for diskless we use "who" to check if it's in use or not.
16:35
<StevenR_>
klausade: what thin clients do you use?
16:35
<klausade>
StevenR_: hardware you mean?
16:35
<StevenR_>
yeah
16:36
<klausade>
StevenR_: probably at least 100 different types. wol support has been rather common on all devices produced the last years.
16:36
<warren>
vagrantc: ogra: i'm tagging ltsp-trunk in a few hours after I add more fedora-specific stuff
16:37
<StevenR_>
klausade: do they all just hook up via xdmcp?
16:37
<vagrantc>
warren: well, i have no intention of two uploads in one day :)
16:37
<warren>
vagrantc: I'm just doing the common courtesy notification
16:37
<vagrantc>
warren: yes, i know.
16:37
<klausade>
StevenR_: we have moved away from ltsp4.2 based xdmcp. we use the "new" ltsp5 stuff in debian.
16:38
<StevenR_>
klausade: what does that do?
16:38
<klausade>
warren: what do you mean?
16:38
<warren>
klausade: we try to avoid stepping on each other
16:38
vagrantc: configure_localdev() is in both ltsp-setup and ltsp-init-common
16:38
vagrantc: intentional?
16:38
<vagrantc>
klausade: apparently, the security fixes for ldm broke local devices with LDM_DIRECTX stuff ... so have to fix that before working on backports.
16:39
<warren>
vagrantc: different code though
16:39
<vagrantc>
warren: yes, it was intentional. though it may no longer be needed.
16:39
<klausade>
vagrantc: ok.
16:40
<vagrantc>
warren: in fact, that ltspfs from udev branch i posted will obsolete the need for it entirely.
16:41
<warren>
vagrantc: I think just do the udev branch already, since the current one doesn't work in fedora it doesn't bother me
16:41
vagrantc: the udev branch works for you?
16:42
(I assume =)
16:42
oh!
16:42
vagrantc: I need LOCALDEV in my lts.conf for it to attempt to work?
16:42
<vagrantc>
warren: i've gotten it working, yes. it could probably use a little optimization though
16:42Gadi has left #ltsp
16:43
<warren>
configure_localdev() {
16:43
boolean_is_true "$LOCALDEV" && mkdir -p /var/run/drives
16:43
}
16:43
I don't have /var/run/drives in my chroot either
16:43
why is it created during boot and not already existing btw?
16:43
<vagrantc>
warren: yes, but ltsp_config should set LOCALDEV for you
16:43
warren: well, i think it is now, and isn't needed anymore...
16:43
<warren>
it is now by what?
16:44
<vagrantc>
warren: i don't know... just works on debian even if i comment the code out.
16:44
warren: might be needed for ubuntu.
16:44
warren: we're having two conversations at once here.
16:45
warren: the mkdir -p /var/run/drives is no longer needed on debian.
16:45
<warren>
what was it for?
16:45
<vagrantc>
warren: ltsp_config should handle setting LOCALDEV for you.
16:45
warren: might still be needed on ubuntu.
16:45
warren: /var/run/drives is where the ltspfs devices are mounted.
16:45
<warren>
you are packaging /var/run/drives yourself?
16:46
vagrantc: I need to make sure it exists and writable right?
16:46* vagrantc thinks it should be in the /var/run/ltspfs/* namespace
16:46
<vagrantc>
warren: yes.
16:46
<warren>
yeah "drives" is a little ambiguous
16:47
<vagrantc>
one of these days, i'd like all of our /var/run stuff to move into appropriate subdirs for ldm, ltsp and ltspfs ... or just all ltsp.
16:48
<warren>
I have no /var/run/drives
16:48
I should probably create that
16:49otavio has quit IRC
16:50slidesinger has quit IRC
16:53Guaraldo has left #ltsp
16:56
<vagrantc>
never did figure out what to do with moving the debian+ubuntu+someothernondebiandistro init scripts
16:56
as far as where to move them to...
16:57
ugh.
16:58
upload to debian was rejected.
16:58
<warren>
vagrantc: so currently at least everyone is using /var/run/drives and it is broken without it?
16:58
<johnny>
thought about removing the that sound script from the root of the tree?
16:58
<vagrantc>
warren: if it doesn't exist, yes.
16:58
<johnny>
the init scripts still make it, but that would only work on union or aufs
16:59
i don't see how it would work with bind mounts
16:59
oh wait.. forgot..
16:59
it's all of /var/run
16:59
<warren>
johnny: I've asked on list on one or two occasions, we should build a list of cleanups like that require other distros to participate because it breaks them.
16:59
<johnny>
so duh.. it'd be fine
16:59
i'm willing to participate any time :)
16:59
<warren>
which initscripts?
16:59
mine don't because I didn't know I needed it
16:59
<johnny>
client/initscrpts
16:59
i worked off those
16:59
<warren>
I'm not using ltsp-setup*
17:00
<johnny>
that's why
17:00
<warren>
because it does a few things that I can't do
17:00
<johnny>
you should have gone over those files like i did
17:00
and picked out the parts you can do :)
17:00
they all work.. even if they don't
17:00
<warren>
it's been like October since I've last looked in there
17:00
<johnny>
as in.. the script completes even if i don't have everything there
17:00
altho i did end up adding jetpipe
17:00
for now
17:00
<warren>
ltsp-setup seems to handle jetpipe
17:02
<vagrantc>
warren: well, mkdir /var/run/drives has been in there for a couple years, i think.
17:03
<warren>
yeah, I missed that one part.
17:03
<johnny>
atm.. my initscripts are just copies of those
17:03
but with gentoo bits added in
17:03
<warren>
johnny: my plan is to implement only what i need then work on moving more things into ltsp-init-common
17:04
<johnny>
it was easier for me to use what already works.. and then strip it out as needed
17:17Q-FUNK has quit IRC
17:18twinprism has quit IRC
17:19* vagrantc re-uploaded 5.1.3 to debian
17:20
<ogra>
vagrantc, congrats
17:20
i think thats the first time you actually passed me wrt upstream version :)
17:20
<vagrantc>
hopefully this time it'll stick ... some recent change where it also has sha*sums in the .changes files that my version of debsign wasn't handling...
17:20
<ogra>
yeah, something changed very recently
17:21
we had probs as well today
17:21
<vagrantc>
i ended up running debsign that was installed in a sid chroot with a full path to it from outside of the chroot ... seemed to work :)
17:22
it was either that, or figure out how to make my gpg keys available in the chroot.
17:23
ogra: well, i've definitely had more recent ~bzr* versions
17:23
ogra: and on many occasions my debian version was more current than your ubuntu version
17:24
but now i've got an upstream version (not to be confused with an upstream release :)
17:24Egyptian[Home1 has joined #ltsp
17:25
<ogra>
yeah
17:26
i didnt deny anything of that :) but the version number somewhat make it "official" :)
17:26
<vagrantc>
indeed. :)
17:26
ogra: if you get me your bzr branches before your mirror sync, maybe we'll nearly be able to be in sync again :)
17:27GodFather has joined #ltsp
17:29
<ogra>
well, i'll probably dump what i have now anyway after release, all my fixes are in eth packaging anyway and have to move upstream
17:29
would be intresting to release with the same version end of the year :)
17:36Egyptian[Home] has quit IRC
17:36
<vagrantc>
would be good to work as close as possible towards that :)
17:37deavid has quit IRC
17:38
<ogra>
yeah, at least for the upstream version
17:38
<vagrantc>
5.1.3-1 on debian is the "forsaken architecture" upload.
17:38
just amd64, i386 and powerpc.
17:39
hrm.
17:39
at least, i thought so ... but ia64 is working hard on building it ...
17:40
<ogra>
oh
17:40
<vagrantc>
well, -2 will be for fixing that up :)
17:40
<warren>
yeah, amd64 is very forsaken =)
17:41
<vagrantc>
warren: well, forsaken in that i've dropped support for all other arches
17:41
so instead of 13...
17:41
<ogra>
all eleven :)
17:41
oh its 13 ?
17:41* ogra missed two :)
17:42
<vagrantc>
alpha, amd64, arm, armel, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390 and sparc ...
17:42
so i guess you just thought of arm* and mips*
17:42
not to mention hurd-i386, kfreebsd-i386 and kfreebsd-amd64
17:43
<ogra>
oh, hurd ...
17:43
there are still people keeping it up ?
17:43
<vagrantc>
i couldn't help but laugh every time i got an upload for one of those
17:43
<ogra>
i cant belive ts still around
17:43
<vagrantc>
although the bsds are actually not technically infeasible to do ltsp ... it just is kind of funny.
17:44
well, s390 is the first to figure out that i've told it not to build
17:45
<ogra>
evil you
17:45
all the poor mainframe users
17:47
<vagrantc>
although, based on the fact that it's attempting to build, i forsee having to make a -2 upload with the architectures delineated somewhere else.
17:47
in the source section or something
17:47* lns wants to run his LTSP env on his trusty C=64
17:50
<warren>
It is hard to tell people who insist that they want s390 LTSP servers.
17:50
"No, you don't know what you actually want."
17:51
<ogra>
vagrantc, where did you pt it ?
17:51
*put
17:51
<vagrantc>
ogra: just in the ltsp-client-core package
17:52
<ogra>
i mean where in the control file :)
17:52
(the arch list)
17:52
<vagrantc>
ogra: well, in the ltsp-client-core section of debian/control ...
17:53
ogra: switched Architecture: any to Architecture: amd64 i386 powerpc
17:53
<ogra>
dont you need brackets there ?
17:53
<vagrantc>
ogra: i'm thinking i should have added an Architecture: amd64 i386 powerpc ... up in the source section
17:53
<ogra>
[amd64] [i386] [powerpc]
17:54
<vagrantc>
don't think so.
17:56IRCzito has quit IRC
17:57
<vagrantc>
ogra: the amd64 build seems to have gone fine, and s390 and ia64 failed ... i'm guessing there's some way i could have done it so they didn't even bother to try...
17:57
<ogra>
the source section attempt sounds about right
17:58
<vagrantc>
i'll attempt to verify it for sure before the next upload.
18:01
i just hope it doesn't waste any time on the slower buildd's
18:02* ogra would so love to delay release for a week
18:02
<vagrantc>
24th?
18:02
<ogra>
yeah
18:02
and a ton of really extremely ugly classmate stuff ahead still
18:03
which indeed keeps me away from the real work, i.e. ltsp
18:04
<vagrantc>
good luck with that.
18:04* vagrantc runs off to do some errands
18:05
<ogra>
rather say good nerves ....
18:05ccherrett has joined #ltsp
18:05
<ogra>
i have seen a lot of crappy stuff but what i'm packaging atm is really the worst evah
18:08GodFather has quit IRC
18:10
<warren>
hey I actually see a ltspfsmounter process now
18:10
<ogra>
congrats
18:11
a mount as well ?
18:14
<warren>
vagrantc: huh, ltsp-setup doesn't use ltsp-init-common?
18:16ccherret1 has quit IRC
18:17mccann has quit IRC
18:17
<warren>
vagrantc: ogra: I'd like to use a few functions from ltsp-setup like configure_swap, configure_printer, configure_x, configure_serial_mouse but I don't want to copy it.
18:17petre has joined #ltsp
18:18
<warren>
vagrantc: ogra: but it appears you don't use ltsp-init-common at all?
18:18
<ogra>
what is ltsp-init-common ?
18:18twinprism has joined #ltsp
18:19
<warren>
ogra: moved functions that we share into it to reduce code duplication
18:19
oh, your ltsp-core script uses ltsp-init-common but not ltsp-setup
18:19
<ogra>
i still use the initscripts from gutsy here with some small changes here and there where it fixed bugs
18:20
i wont do the full switch to the new design before intrepid, hardy is very conservative
18:20
<warren>
I know
18:20
I just rather not copy code into a separate file
18:20
I'm wondering why vagrantc didn't switch ltsp-setup to use ltsp-init-common
18:22
<ogra>
just move the code ... and leave calls to it in the initscript
18:22
i think vagrant is on a "fs access reduction spree" atm
18:22
might be related :)
18:28
<warren>
vagrantc: btw, have you run your client with bootchart?
18:28
vagrantc: you might kill lower hanging fruit from that before fs access
18:29
<ogra>
we did a ton of bootchart sessions in dapper (~2 years ago) when we had our first speedup hackfest
18:30
i should do some again in intrepid
18:30
<warren>
http://people.redhat.com/wtogami/temp/bootchart-fedora-ltsp-client.png
18:31
I didn't do any optimization yet given that I'm still working on functionality
18:31
but this is from today when I pushed "fix bootchart with readonly root"
18:31
<ogra>
geez
18:31
21 secs o_O
18:32
<warren>
looks like I can cut out nash-hotplug, that isn't needed at all here.
18:32
<ogra>
oh, whats nash ?
18:32
<warren>
ogra: don't ask =(
18:32jammcq has joined #ltsp
18:32
<jammcq>
hey all
18:32
<warren>
jammcq: http://people.redhat.com/wtogami/temp/bootchart-fedora-ltsp-client.png chart pr0n
18:32
jammcq: (unoptimized fedora ltsp client boot)
18:33
<ogra>
http://people.ubuntu.com/~ogra/feisty-20070405-1.png
18:33
<warren>
wow, openvt is actually making a measurable difference in boot speed
18:33
<ogra>
thats from a year ago
18:33
<warren>
(I'm opening six bash shells just for debug)
18:33
<ogra>
gutsy is at 25sec
18:34* warren rips out hotplug just out of curiosity...
18:34
<ogra>
(bootcharting the same HW)
18:36
<vagrantc>
warren: well, i just followed your lead regarding functions ... figured you'd grab whatever functions you found useful.
18:36
<warren>
ah, it turns out nash-hotplug is only an accounting error
18:37
vagrantc: see my list post
18:37
<vagrantc>
warren: it's probably not a big deal to put functions that are only used by one or the other
18:37
<warren>
vagrantc: I want to 1) have ltsp-setup include ltsp-init-common 2) move a few functions into ltsp-init-common 3) make configure_x do both currently conflicting things
18:38
vagrantc: #3 was an error?
18:39
<vagrantc>
warren: originally, it was just in a single script, and ogra moved part of it to another script for speed reasons that i never really understood.
18:39* ogra doesnt understand the logic of 3
18:40
<ogra>
vagrantc, wrong
18:40
<warren>
ogra: they both have an implementation of configure_x() but it appears that you want to do both
18:40
<vagrantc>
ogra: someone moved it, and it was either you or scotty
18:40
<ogra>
it always were two scripts simply because we always needed thigs that were configured before the actual rest of initscripts is run
18:40
<warren>
I have issues with stuff in configure_x but I can fix it in a way that wont break you.
18:40
<vagrantc>
at any rate, i think any configuration belongs in the setup phase
18:41
<ogra>
initially -setup was the piece that did the bindmounts
18:41
<vagrantc>
warren: overall, i want to move to the /var/run/ltsp-xorg.conf direction anyways
18:41
<warren>
is there any objection to moving stuff from ltsp-setup into ltsp-init-common?
18:41
functions only of course
18:41
<ogra>
depends on the function
18:41
<vagrantc>
warren: i have no objection to moving them really.
18:42
warren: as long as some care is done to handle ones with identical names.
18:42
<warren>
vagrantc: and having ltsp-setup include ltsp-init-common? it currently doesn't
18:42
vagrantc: none have identical names except configure_x
18:42
<ogra>
vagrantc, you want swap as eraly as possible ... i would object moving that to the later script
18:42
<warren>
it seems like configure_x became conflicting only because of an error
18:42
ogra: nobody suggested moving it to a later script
18:42
<vagrantc>
ogra: we're not talking about moving where they get called from
18:43
<ogra>
oh, sorry .... "is there any objection to moving stuff from ltsp-setup into ltsp-init-common"
18:43
<warren>
vagrantc: so you're OK with me adding the include while I move things?
18:43
<vagrantc>
ogra: but i think the bzr logs will definitely support my memory that x configuration was moved from one script to another ... :)
18:43
<ogra>
i read the last as -init
18:43
vagrantc, i thought we talked about the initscripts
18:44
i moved the X config to the late script, when we moved away from debconf
18:44
<vagrantc>
i think you just did it ... but it's water under the bridge :)
18:45
warren: with the new screen-x-common stuff, copying onto /etc/X11/xorg.conf shouldn't even be necessary except in unusual cases.
18:45
as X_CONF is handled by the screen script itself
18:45
<warren>
vagrantc: ok
18:46
vagrantc: so we could simply delete that?
18:46
<vagrantc>
warren: i think so.
18:46
<warren>
vagrantc: should we keep the configure_x stuff in ltsp-init-common?
18:47
<vagrantc>
warren: you mean ltsp-core or ltsp-setup ... ?
18:47
<warren>
vagrantc: well, we just agreed to delete configure_x from ltsp-setup because it isn't needed anymore due to screen-x-common
18:48
vagrantc: but there's still the configure_x in ltsp-init-common
18:49ccherret1 has joined #ltsp
18:49ccherrett has quit IRC
18:50
<vagrantc>
heh. oh, i see. it's all messed up.
18:50
:)
18:51
<warren>
ltsp-setup:
18:51
. /lib/lsb/init-functions
18:51
. /usr/share/ltsp/ltsp_config
18:51
. /usr/share/ltsp/ltsp-common-functions
18:51
where should it include ltsp-init-common?
18:51
last?
18:52
<vagrantc>
ltsp-init-common sources ltsp_config and ltsp-common-functions at the top
18:52
<warren>
ok
18:52
so remove the last two
18:52
and add it
18:52
I'll do it now
18:52
<vagrantc>
warren: are you working on this, or should i do it?
18:53
<warren>
vagrantc: I already have pending changes so I might as well do it
18:53
<vagrantc>
warren: ok.
18:53
warren: just go ahead and make the changes and if i need to i'll fix it later.
18:53
<warren>
ok
18:54
<vagrantc>
warren: i just made an upload today and will be focusing on ltspfs and ldm and getting ltspfs working with LDM_DIRECTX
18:54TelnetManta has joined #ltsp
18:54
<warren>
vagrantc: great
18:55
<vagrantc>
although i'm hopping on a bus tomorrow ... but then i'll be somewhere for a whole week :)
18:55
and after that, i plan on being somewhere for months at a time. :)
18:56viking-ice has quit IRC
18:57viking-ice has joined #ltsp
18:58
<warren>
vagrantc: should I remove this now?
18:58
configure_localdev() {
18:58
boolean_is_true "$LOCALDEV" && mkdir -p /var/run/drives
18:58
}
18:58
vagrantc: actually "make install" on ltspfs should be creating whatever directory it needs
18:58
<ogra>
that should be done by whatever starts ltspfsd
18:59
<warren>
h
18:59
hm
18:59
not if you want to eliminate another fs access! =)
18:59
vagrantc: (i'm joining your crusade)
19:00
<ogra>
oh, wait
19:00
ROOT=/var/run/drives
19:00
...
19:00
# Invent $MOUNTPOINT
19:00
MOUNTPOINT=$ROOT/$LABEL
19:00
mkdir -p ${MOUNTPOINT}
19:00
from add_fstab_entry
19:00
that should suffice
19:00
drop it :)
19:01
<warren>
huh?
19:01
then why it wasn't it working for me until I created that directory?
19:02
<ogra>
it should work without unless ltspfsd has a check or something, if a device is plugged it should create te mountpoint with mkdir -p
19:03
gra@osiris:~/Devel/packages/ltspfs-0.5.0~bzr20080109$ grep drives src/*
19:03
ogra@osiris:~/Devel/packages/ltspfs-0.5.0~bzr20080109$
19:03
apparently not
19:03
<warren>
odd
19:04
this MOUNTPOINT is only for ltsp-client right?
19:04
(just checking)
19:04
<ogra>
do you need the full path ?
19:04
its only for that device
19:04
dynamically created
19:04
<warren>
I still don't know how ltspfs works much at all
19:05
I'll get back to this, I'm carving up ltsp-setup now
19:08
<ogra>
plug drive->trigger udev->exec add_fstab_entry (writes entry for device to /var/run/ltspfs_fstab)->trigger ltspfsmounter through tunnel in the session->ltspfsmounter calls back to the client and triggers the ltspfs mount between servers fuse and clients ltspfsd->triggers lbmount to move the mount o a proper place gvfs/gnome-vfs or kde's equivalent monitor ... done
19:08
thats the raw plot
19:09
(missing some auth stuff, cdpinger and delayed mounter though)
19:09
<warren>
I guess I need to read the ltspfs code deeply in order to understand it
19:09
I looked the least at it
19:10
<ogra>
well, ltspfs is just a autofs fuse hybrid thingie
19:10
that code actually didnt really change since ltsp 4.2 ... apart froma seurity fix
19:10
(ltspfs and ltspfsd)
19:11
<warren>
vagrantc: oh you'll find this interesting, ltsp-init-common has configure_localdev() different from ltsp-setup
19:11
vagrantc: you weren't running the common version before
19:11
<ogra>
the bg changes were the infrastructure and scripts around it
19:11slipttees has joined #ltsp
19:11
<ogra>
s/bg/ig/
19:11
grr
19:11
*big
19:12captain_magnus has quit IRC
19:12
<warren>
vagrantc: not sure if the code in ltsp-init-common is old or irrelevant
19:13
vagrantc: or actually the cause of it not working on fedora
19:14
<jammcq>
hey guys, i'm giving a talk on friday. what are some key points I should mention about the latest ltsp-5
19:14
?
19:14captain_magnus has joined #ltsp
19:14* jammcq feels very un-prepared to be talking about ltsp-5
19:15
<warren>
jammcq: for the first time ever we have a wide variety of distros working on upstreaming things and making things common
19:15
<jammcq>
yeah, that's huge
19:15
<ogra>
jammcq, in ubuntu it moved to the alternated CD (press f4 on the install screen to select an ltsp server)
19:15
<jammcq>
that'll fill about 60 seconds :)
19:16
<ogra>
beyond that there was only stabilization work done between gutsy/hardy
19:16
the upstream collaboration changes were surely the most noticeable change
19:16
<petre>
anything to be said about pulse-audio implementation?
19:16
<jammcq>
but, I'll have to wait for the translators to catch up, so it'll fill 2 minutes
19:16
I think the work on making it secure is a great thing to talk about
19:16
<ogra>
but indeed that didnt result in new nifty featurs
19:17
petre, thats darn old
19:17
<warren>
jammcq: fedora doesn't have it on any media, you currently need to install it with yum
19:17
<ogra>
we use it since over a year
19:17
<warren>
jammcq: I'm working on install media probably next month
19:17
<jammcq>
warren: these days, I consider network install to be the norm
19:17
<warren>
jammcq: point out our homepage if people want to learn how to do it on fedora
19:17
<ogra>
jammcq, really ?
19:17* petre agrees with jammcq
19:18
<warren>
jammcq: well, I want to support both network install and media
19:18
<petre>
yum is the way to go
19:18
<warren>
jammcq: http://k12linux.fedorahosted.org/
19:18
petre: not the entire world has good bandwidth
19:18
<jammcq>
ogra: for me, yeah
19:19
obviously, it's great to have something be part of the install procedure
19:19
but after the fact, I NEVER go back to the cdroms. I always do it with network
19:19
<ogra>
jammcq, you should tel that to the 10mio ppl ordering ubuntu shipit CDs :)
19:19
<petre>
warren, right you are; mailing someone a DVD with everything is still worthwhile
19:19
<ogra>
would save us a lot of money here :)
19:19
<jammcq>
ogra: cdroms are fine for base install
19:19
i'm talking about adding packages after the fact
19:19
<ogra>
ah
19:19
indeed
19:20
one CD is enough for everyone (tm) :)
19:20
<jammcq>
the fact that Fedora doesn't yet include LTSP on a cdrom image is not much of a problem
19:20
<ogra>
right
19:20
<jammcq>
although I'm hoping future versions of fedora do include it
19:21
<ogra>
its 250K of code only :)
19:21
<warren>
jammcq: we don't have a single image anymore
19:21
jammcq: normal for fedora is to have a specific image for what you want to do
19:21
jammcq: and we encourage our users to make new "spins"
19:21
jammcq: fedora desktop, fedora KDE, fedora developer, fedora electronic lab are some of the current ones
19:22captain_magnus has quit IRC
19:22
<petre>
warren, are you envisioning a fedora ltsp?
19:22
<warren>
petre: yes, we already talked about this.
19:22
petre: it is already possible, I just don't have time right now
19:22
<petre>
oh, right: k12linux
19:22
duh
19:22
<jammcq>
warren: are those single-cds ?
19:22
<warren>
jammcq: yes.
19:22
<jammcq>
awesome
19:23
in fact, Fantastic !!!!
19:23
<warren>
getting hard to fit everything on one CD these days though.
19:23
<jammcq>
heh, i'm sure
19:23
<warren>
jammcq: LTSP is looking to use a minimum of 1.1GB image
19:23
that's compressed
19:23
including all the usual edu desktop apps, productivity and the chroot
19:23
<jammcq>
ah
19:23
<warren>
jammcq: so USB or DVD only I'm afraid
19:24
<jammcq>
are you shipping a pre-built chroot? or building it
19:24
during install
19:24
<warren>
jammcq: if you want it installable from that image without network you need a pre-built chroot
19:24
<jammcq>
err, "planning on shipping"
19:24
oooh
19:24
<warren>
(that's why there's no way in hell it will fit on one CD)
19:24
<jammcq>
hey, just use the other side :)
19:25
<ogra>
why cant you build it at install time ?
19:25monteslu has quit IRC
19:26captain_magnus has joined #ltsp
19:26
<ogra>
one of ltsp5's puroses was to be able to build from the packages you have on your media anyway
19:26
<warren>
ogra: x86_64 server packages, i386 chroot?
19:26
<ogra>
oh, right
19:26
thats different
19:27
<warren>
the x86_64 server is almost devoid of i386 packages
19:27
<petre>
warren, if you're assuming x86_64 server, is it unsafe to also assume DVD drive?
19:27
<warren>
?
19:27
petre: btw, how's work on ltsp-server-initialize? =)
19:27
<petre>
so you don't have to cram everything into 650-700MB
19:27
CD
19:27
<warren>
petre: you could start by simply posting your ideas about ltsp-server-initialize to the list and get feedback from others
19:28
don't have to fix it at all at once
19:28
<ogra>
warren, we made a survey in edubuntu once, the majority of edubuntu users doesnt own a DVD writer ....
19:28
<warren>
petre: either i386 or x86_64 server is supported
19:28* petre blushes because he has nothing to show so far
19:28
<ogra>
if your focus is only US schools thats fine indeed
19:28
<warren>
ogra: install from USB stick is also an option
19:28
ogra: we encourage USB stick install, less waste
19:29
<ogra>
if the HW they have supports booting from usb
19:29
<warren>
true
19:29
<ogra>
which is rarely the case either
19:29
<warren>
but fedora really sucks on anything that old anyway
19:29
<petre>
cyberorg sent me a link to his equivalent of ltsp-server-initialize which I've been reading through
19:30
<ogra>
warren, edubuntu default as well, but its trivial to install xubuntu-desktop on it and have a low level server that eats way less ram
19:30
<warren>
petre: ok
19:31
<petre>
so, I'm chipping away at it, but I'm embarrassed at my lack of progress
19:32
time is hard to come by, should get better in a month
19:33
ogra, have you heard of anyone using Ice instead of xfce/gnome?
19:33
<vagrantc>
icewm is what's used at freegeek for guest logins
19:33
<warren>
petre: please just post about it on the list, point at what cyberorg told you
19:33
<petre>
several K12ltsp people used to use it for its lack of demands
19:34
<ogra>
petre, rarely ... xubuntu is so well integrated and uses not really more ressources, most ubuntu users with low level HW use just that and have all the nifty features a mdern desktop offers
19:34
<warren>
petre: I suspect a proper ltsp-server-initialize will need ideas from others, especially Eric Harrison, because it is HARD to make the script do only safe things.
19:34
<ogra>
i heard about someone using luxbuntiu with ltsp though
19:34
<warren>
petre: maybe the entire concept has to be redone
19:34
<ogra>
*fluxbuntu
19:35
<vagrantc>
xubuntu isn't a whole lot better than gnome, in my experience.
19:35
which is, admittedly brief.
19:35
<ogra>
well, it uses half the ram
19:35
<vagrantc>
wasn't with gutsy
19:35
<ogra>
while still offering the same functionallity
19:36
<vagrantc>
when we tried to switch freegeek to use gutsy, we did extensive resource comparisons of ubuntu and xubuntu, and xubunutu didn't really change much.
19:36
<ogra>
a gutsy desktop system in htop uses about 150M here, a gutsy xubuntu system lives fine with 80
19:37
(only teh desktop running indeed)
19:39
<petre>
my experience with xubuntu was similar to vagrantc's: not a whole lot better than gnome, but that was on dapper
19:40
<ogra>
vagrantc, expect a very light desktop in intrepid, canonical does so much in the mobile area now that we'll have something nice next release :)
19:40
<jammcq>
"intrepid" ?
19:40
<ogra>
i think in dapper there were even still the gnome libs installed etc
19:40
<jammcq>
is that the next one?
19:40
<ogra>
yep
19:40
<jammcq>
wow
19:40
<ogra>
ibex
19:40
<jammcq>
sounds cool
19:43
<warren>
vagrantc: ok, pushed the changed ltsp-setup
19:43
I'm still making more changes, but only after I get home in a few hours.
19:43
posting another question to the list now
19:44
<jammcq>
ogra: are the mailing lists working in LP now?
19:44
<ogra>
yup
19:44
i didnt test it though
19:44
<jammcq>
is there any migration tool to pull the list out of sourceforge?
19:44
<ogra>
but they are supposed to
19:45
lets ask #launchpad
19:46
<warren>
ogra: ah, ltspfs add_fstab_entry
19:46
ogra:
19:46
<petre>
why are lists moving from sf to lp?
19:46
<warren>
ROOT=/var/run/drives
19:46slipttees has quit IRC
19:46
<warren>
LABEL=${ID_FS_LABEL_SAFE}
19:46
MOUNTPOINT=$ROOT/$LABEL
19:46
mkdir -p ${MOUNTPOINT}
19:46
<ogra>
warren, right
19:46
<warren>
ogra: so it is indeed needed to create /var/run/drives
19:46
<ogra>
that should create /var/run/drives
19:46
<warren>
oh wait
19:46
duh
19:46
<ogra>
-p
19:46
:)
19:47
i suspect you need the path like with chroot
19:48
<petre>
warren, link for cyberorg's script sent to list..
19:48
<warren>
thx
19:49
OH
19:49
ogra: ltspfsd actually modifies /etc/fstab?
19:49
I think that's read-only on my client
19:49
hmm
19:49
<ogra>
no, it modifies its own fstab
19:49
/var/run/ltspfs_fstab
19:49
<warren>
oh
19:50
<ogra>
(/var/run being a tmpfs here)
19:50viking-ice has quit IRC
19:53
<warren>
vagrantc: posted to list
19:53
<ogra>
warren, do you have any contact to flash upstream people ?
19:53
<warren>
ogra: only the product manager, but they haven't been responding lately
19:53
(that kind of worries me)
19:53
<ogra>
apparently the acceleration they use is the cause for slowdowns over network
19:54
<warren>
what kind of acceleration?
19:54
ogra: recent flash versions began using opengl
19:54
<ogra>
the one you can en/disable in the context menu of flashplayer
19:54
<warren>
oh/
19:54
didn't know you could disable it
19:54
might want to put that into /etc/skel then
19:54
<ogra>
and apparently it works lots faster with accel disabled
19:54
you cant
19:54
<warren>
oh?
19:54
<ogra>
flash has no option for it
19:55
<warren>
the context menu options get written somewhere in $HOME
19:55
<ogra>
it accepts a config file in /etc/adobe now
19:55
mms.cfg
19:56
but it has no config option for accel at all
19:56
<warren>
ah
19:56
<ogra>
http://www.adobe.com/devnet/flashplayer/articles/flash_player_admin_guide/flash_player_admin_guide.pdf
19:57
tahats why asked if you have any closer contact
19:57
to trigger the adding of such an option :)
19:58
i think i have a businesscard from that product manager as well (and had a beer with him) ... he was at ubuntulive last year
19:58
<warren>
him?
19:58
<ogra>
but didnt keep contact
19:58
<warren>
I thought her.
19:58
<ogra>
oh, ok
19:58
then it was a different guy
19:59
might be he was acrobat
19:59
<warren>
... or no longer a guy...
19:59
<ogra>
heh
20:00
i would have to search the card, i know it was written on there ...
20:00
anyway, moot point
20:01
just remember it if your users complain about poor flash performance :)
20:01
<warren>
thanks for pointing out the admin guide
20:03mccann has joined #ltsp
20:04
<ogra>
warren, i think vagrant had worked on code to start cdpinger from udev (not sure it was him or scottie though)
20:04
so that could go away in this case
20:04
<warren>
ugh, I still have to figure out why cdpinger is segfaulting only on via
20:04
<ogra>
ah, no that was ltspfsd
20:05
but the same should be possible for CDs
20:05
s all we need is the mcookie
20:06
<warren>
vagrantc: OK, I'm tagging in about an hour or two.
20:06
mcookie came from upstream X
20:06
<ogra>
nope
20:06
<warren>
I mean, mcookie the binary
20:06
<ogra>
yeah, indeed
20:06
<warren>
upstream X is moving away from it it seems.
20:07
<ogra>
we could as well just md5sum the dmesg output or so
20:07
or a timestamp
20:07
<warren>
I really have to go to the gym now
20:07
bbl
20:07
<ogra>
its just a string
20:07
have fun :)
20:07
<warren>
ogra: mcookie=`dd if=/dev/urandom bs=16 count=1 2>/dev/null | hexdump -e \\"%08x\\"`
20:07
ogra: even better
20:08
although this is slower than mcookie binary ...
20:08
I have to ask if the mcookie binary is going away
20:08
<ogra>
as you like, it just has to be a unique hash ltspfsd can read from the rootwindow
20:08
<warren>
is the hash used for any security reason?
20:08
<ogra>
no matter how we create it ...
20:08
yeah
20:08jammcq has quit IRC
20:08
<warren>
then you really don't want to generate it from timestamp
20:09
<ogra>
ltspfsd will refuse connections without it
20:09
<warren>
we had the same problem with fixing xauth generation for ldm
20:09
<ogra>
you can use pwgen :)
20:09
it generates nice hashes
20:10
<warren>
oh
20:10
util-linux-ng-2.13.1-6.fc9.x86_64 contains mcookie
20:10
it probably wont go away then
20:10
<ogra>
ah, nice
20:10
<warren>
ldm should probably switch back then
20:11
OK, i'll brb
20:23
<vagrantc>
my work on starting cdpinger from udev lead to me working on using ltspfsd from udev as well.
20:23
well, actually, starting them from add_fstab_entry, technically.
20:23
have it working pretty well
20:23
<ogra>
well, cdpinger should just be started directly from a rule
20:24
(udev)
20:24* ogra is irritated ... why do i suddenly have a command history in my chroot
20:25
<ogra>
there is neither a ~/.bash_history nor a ~/.history file
20:25
<vagrantc>
ogra: i started it directly from a udev rule, but it actually worked better to start from add_fstab_entry
20:26
had to do things like "don't start unless LOCALDEV is defined" and such.
20:27
<ogra>
ah, right
20:27
that makes sense
20:29
<vagrantc>
launchpad is crazy ... warren just pushed a bunch of commits and i got 699 first, followed by 702, then 701, 700 703 ...
20:29
regarding the commit messages
20:34
<ogra>
wll, it doesnt process them right away it queues them up and processes every five mins or so
20:36
<vagrantc>
yeah, i figured something like that...
20:38
<ogra>
meh, either chroot or sudo is broken
20:39
ogra@ceron:~/livefs$ sudo chroot chroot-livecd/
20:39
root@ceron:/# ls home/
20:39
ogra
20:39
thats a clean chroot ...
20:39
i didnt create a user
20:39
(and no, /home isnt bind mounted)
20:50J45p3r has quit IRC
20:52Guaraldo has joined #ltsp
20:56ccherret1 is now known as ccherrett
20:58Guaraldo has quit IRC
20:58monteslu has joined #ltsp
21:05manuel_schulte has joined #ltsp
21:11
<warren>
ogra: what is pwd after chroot?
21:11
<ogra>
/
21:12
HOME is still set i guess but that was the case before as well
21:12
it (whatever causes that) didnt create a homedire before though
21:13
hmm
21:14
on a second attampt it doesnt do that anymore
21:18
warren, i think the name duplication was my fault ... i moved all the heavyweight stuff (starting aps etc) to the ltsp-client script to start it after the login manager by just splitting the original function into two halves
21:18
s/aps/apps/
21:19
origianlly all localdev handling was done in the -setup script
21:41MacIver has quit IRC
21:44MacIver has joined #ltsp
21:44petre has quit IRC
22:28vagrantc has quit IRC
23:12manuel_schulte has left #ltsp
23:51Egyptian[Home] has joined #ltsp