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


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

00:23monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 255 seconds)
00:35monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net)
00:50alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net)
00:53adrianorg__ is now known as adrianorg
01:42Parker955 is now known as Parker955_Away
01:59freedomrun has left IRC (freedomrun!~quassel@89.143.183.103, Ping timeout: 260 seconds)
02:19adrianorg has left IRC (adrianorg!~adrianorg@187.115.107.166, Ping timeout: 240 seconds)
03:56loather has joined IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net)
04:26staffencasa has left IRC (staffencasa!~staffenca@128-193-149-96.oregonstate.edu, Ping timeout: 244 seconds)
04:41alexqwesa has left IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net, Quit: Хана X'ам !!!)
04:57vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
05:06killermike has joined IRC (killermike!~killermik@2.26.91.173)
05:09loather has left IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net, Quit: This computer has gone to sleep)
05:14freedomrun has joined IRC (freedomrun!~quassel@89.143.183.103)
05:34loather-work has joined IRC (loather-work!~khudson@wsip-98-175-250-115.sd.sd.cox.net)
05:50risca has joined IRC (risca!~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net)
05:52
<risca>
I have 1 server and multiple fat clients. What is the best way to list all connected (up) clients?
05:54
ATM, I am only interrested in when clients go online.
06:32risca has left IRC (risca!~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net, Quit: Lämnar)
06:36alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
06:50Lumiere has left IRC (Lumiere!~jstraw@unaffiliated/jstraw, Ping timeout: 240 seconds)
07:02Lumiere has joined IRC (Lumiere!~jstraw@unaffiliated/jstraw)
07:08prem has joined IRC (prem!~prem@180.149.48.229)
07:08
<prem>
hi
07:08
i had setup a ltsp server on debian squeeze.,
07:09
on booting through PXE in a client machine.,its showing till the ltsp login page only
07:14
<knipwim>
alkisg: must feel good, closing all those bugs :)
07:15
<alkisg>
knipwim: hehe just a bit... I'd prefer it if someone else did it actually :D
07:25
<prem>
in the server it shows " disconnect requested"
07:25
from nbd-server
07:26
is there a speicification for image size..?because its only 231MB
07:26killermike has left IRC (killermike!~killermik@2.26.91.173, Remote host closed the connection)
07:29alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg)
07:30alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 245 seconds)
07:46Q-FUNK has joined IRC (Q-FUNK!~q-funk@ubuntu/member/q-funk)
07:46
<Q-FUNK>
alkisg1: thanks for adding | dnsmasq
07:46
alkisg1: https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/934014
07:47
this might also be of interest
07:50alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
07:51alkisg1 has left IRC (alkisg1!~alkisg@ubuntu/member/alkisg, Ping timeout: 248 seconds)
08:03
<Q-FUNK>
alkisg: thanks for adding | dnsmasq
08:03
alkisg: https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/934014
08:05
<alkisg>
Q-FUNK: I don't have access to packaging branches, but I did ask stgraber to do the change as I'm using dnsmasq too :)
08:06
<Q-FUNK>
alkisg: ah, ok
08:06
stgraber: thanks for adding | dnsmasq. btw, we have a legacy Depends left: https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/934014
08:07
alkisg: you don't? why not? aren't you a dev?
08:07
<alkisg>
Q-FUNK: upstream ltsp dev != distro maintainer
08:07
Packaging is a per-distro task, not in upstream brances
08:09
<Q-FUNK>
alkisg: you have an ubuntu IRC cloak, too.
08:09
<alkisg>
Q-FUNK: ubuntu member != ubuntu ltsp package maintainer :) There are hundeds of ubuntu members, but only one ubuntu ltsp maintainer
08:10
<Q-FUNK>
alkisg: ok. should this be fixed? :)
08:10
<alkisg>
I think so, try to ping stgraber later on when he's online
08:11
<Q-FUNK>
alkisg: I mean about granting you access to the ubuntu bzr branch for the packages
08:11
<alkisg>
Ah :)
08:12
<Q-FUNK>
alkisg: nowadays, both stgraber and ogra_ have a milions of other ubuntu tasks on their hands, so LTSP is low-priority for them.
08:13
<alkisg>
I'm not sure... First, I only use lts releases, so I'm not the proper person to be testing ltsp on each release
08:13
So "co-maintainer", maybe, but with my phd and all I don't think I could be the primary maintainer...
08:15
<muppis>
As I get this divorce-sh* off my hands, I've planned get my hands on LTSP.
08:19
<Q-FUNK>
heck, I might as well as to be added myself, since I could easily do those dependency changes myself
08:25loather-work has left IRC (loather-work!~khudson@wsip-98-175-250-115.sd.sd.cox.net, Quit: This computer has gone to sleep)
08:26prem has left IRC (prem!~prem@180.149.48.229, Remote host closed the connection)
08:32prem has joined IRC (prem!~prem@180.149.48.229)
08:32alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net)
08:38
<alkisg>
Q-FUNK: what's the current status on https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/241307 ?
08:39
Should I mark it as invalid for ltsp? There's another bug for the etherboot images... https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/487826
08:43VectorX has joined IRC (VectorX!~knight@unaffiliated/vectorx)
08:43
<VectorX>
guys, so similar to "office automation" if i want to implement a LTSP solution -printers etc, what would you call that
08:44
like for an advertisement, to get projects
08:47Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71)
08:53
<Hyperbyte>
VectorX, I have no idea what you're talking about. Could be just me though.
08:54
<Q-FUNK>
241307 was "resolved" the day the archive migrated to 686-optimized built, which had the side-effect of killing support for plain old 586-based CPU.
08:55
<VectorX>
Hyperbyte say you offer a service for say businneses where you go and provide an LTSO solutions, to them you are just putting in place some computers with a os on a network, so how would you sell this service, what exactly are you offering
08:56
so if i go to a business and say I offer LTSP solutions, that doesnt mean anything to them
08:57
<Q-FUNK>
Bug #487826 could indeed be fixed by using wraplinux.
08:59
<Hyperbyte>
VectorX, terminal server/client?
08:59
<alkisg>
Q-FUNK: do you think my suggestion at https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/487826/comments/12 is reasonable?
09:00
<Hyperbyte>
VectorX, or, you could be really hip and use the term "cloud computing", nobody knows what that means exactly anyways.
09:00
<VectorX>
hmm
09:00
<Q-FUNK>
alkisg: not feasible, unfortunately, since PXE is implemented as a hardware-specific binary blob.
09:00
<VectorX>
alkisg any ideas about my query
09:01
<alkisg>
Q-FUNK: I'm not asking anyone to change the pxe rom
09:01khildin has joined IRC (khildin!~khildin@ip166-155-209-87.adsl2.static.versatel.nl)
09:01
<VectorX>
"cost effective office computer solutions"
09:01
<alkisg>
I'm suggesting to use a custom .nbi server-side
09:01
VectorX: sorry I didn't read your question, I'm occupied with some bug reports...
09:02
<VectorX>
alkisg ok sorry to disturb you, please continue with that
09:02
<Q-FUNK>
alkisg: you'd just make nbi load up some generic PXE support and have that chainload whatever the PXE config is offering?
09:02
<alkisg>
Q-FUNK: yes, chainloading ipxe
09:02
It would add a 2-5 sec delay but it would allow us to completely remove the unmaintained .nbi support from ltsp
09:03
<Q-FUNK>
alkisg: same problem. there's no such thing as a generic PXE implementation. it needs to know something about the hardware it runs on.
09:03
<alkisg>
...and since it would only be 1 file to ship, you could host it in your site
09:03
Q-FUNK: there's a generic "all-drivers" bundle of ipxe
09:03
ipxe == gpxe == etherboot
09:03
So it surely runs on etherboot clients
09:04
<Q-FUNK>
all driver source, yes, but a one-size-fits-all binary? that, I'd like to see.
09:04
<alkisg>
Q-FUNK: that has been supported in etherboot since more than 4 years
09:05
There are even debian packages for it nowadays
09:05
<Q-FUNK>
package name?
09:05
<alkisg>
ls -l /boot/ipxe.lkrn
09:05
-rw-r--r-- 1 root root 323551 Φεβ 10 19:54 /boot/ipxe.lkrn
09:05
ipxe
09:06
ii ipxe 1.0.0+git-3.55f6c88-0ubuntu1 PXE boot firmware
09:06
<Q-FUNK>
wow. pretty neat. lemme try this on a couple of hosts. just a sec.
09:07
<alkisg>
Q-FUNK: So to get that bug moving towards a solution, I'm thinking of marking it as invalid for ltsp, mentioning that we're thinking of completely dropping support for .nbi images, and anyone that has such clients can download "link to the file that one prepares with mkelflinux"
09:16
<Q-FUNK>
alkisg: or just ship that ipxe blob by standard
09:17
<alkisg>
It's not a good practice to include binary blobs in packages though...
09:20
...and we'd have to update the binary blob from time to time, and I don't think anyone would be interested in doing that as part of ltsp (ubuntu) maintainance
09:20
<vagrantc>
(why not simply depend on ipxe?)
09:20
<alkisg>
vagrantc: depend on ipxe, mkelflinux etc on build time... wouldn't building a separate package be much saner?
09:21
Package "etherboot-support" that ships that single file
09:21
Then ltsp-update-image can copy it if it finds it in a standard path
09:25dobber has joined IRC (dobber!~dobber@213.169.45.222)
09:25
<alkisg>
OK, down to 19 bugs in LTSP, 20 in ltsp (Ubuntu), good enough for now :)
09:26
I hope that helps in focusing on bugs we want to try and solve
09:27
vagrantc: I'm thinking of going through ltsp-docs, but since I'm not a native english speaker, someone would have to proofread what I write... should I do it, or better not to even try it?
09:28zubatac has joined IRC (zubatac!~zubatac@193.204.83.167)
09:29
<Q-FUNK>
that's my idea as well. depend on ipxe and on whatever tool is needed to generate a usable nbi.img
09:29
not at build time, but at install time. this way, whichever version of ipxe happens to be in the repo gets used.
09:30
however, it doesn't yet resolve the issue of which tool can be used to generate coreboot AND bios -friendly nbi.img
09:31
in principle, I'd say wraplinux, but one can never be sure.
09:32
<alkisg>
Q-FUNK: there's no binary ipxe package that contains the blob in the format you need, afaik, so you can't do that at install time
09:33
Unless you can use ipxe.lkrn directly within an .nbi image, no idea there
09:34
If so, sure, we could just check if ipxe.lkrn is available in its standard location, and recommend the ipxe package
09:34zubatac has left IRC (zubatac!~zubatac@193.204.83.167, Quit: Sto andando via)
09:34zubatac has joined IRC (zubatac!~zubatac@193.204.83.167)
09:34
<alkisg>
Try first to get it working manually, and if it does, mention it in the bug report so that we try to automate it
09:35bobby_C has joined IRC (bobby_C!~bobby@chello080108221029.1.13.vie.surfer.at)
09:36zubatac has left IRC (zubatac!~zubatac@193.204.83.167)
09:37
<vagrantc>
well, tomorrow i hopefully get ltsp 5.3.x uploaded to debian... and an ldm update.
09:38
<VectorX>
fingers crossed
09:39freedomrun has left IRC (freedomrun!~quassel@89.143.183.103, Remote host closed the connection)
09:41vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Ping timeout: 245 seconds)
09:43Q-FUNK has left IRC (Q-FUNK!~q-funk@ubuntu/member/q-funk, Quit: Leaving.)
09:44bobby_C has left IRC (bobby_C!~bobby@chello080108221029.1.13.vie.surfer.at, Read error: Operation timed out)
09:45bobby_C has joined IRC (bobby_C!~bobby@chello080108221029.1.13.vie.surfer.at)
10:03ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood)
10:04ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
10:15leio has left IRC (leio!~leio@gentoo/developer/leio, Ping timeout: 265 seconds)
10:16leio has joined IRC (leio!~leio@gentoo/developer/leio)
10:25Stefan544 has joined IRC (Stefan544!~Stefan544@109-124-164-50.customer.t3.se)
10:38freedomrun has joined IRC (freedomrun!~quassel@BSN-142-162-34.dial-up.dsl.siol.net)
10:59alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
11:22mistik1 has left IRC (mistik1!~mistik1@unaffiliated/mistik1, Ping timeout: 272 seconds)
11:23mistik1 has joined IRC (mistik1!~mistik1@unaffiliated/mistik1)
11:23artista_frustrad has joined IRC (artista_frustrad!~fernando@200.247.43.2)
11:40bobby_C has left IRC (bobby_C!~bobby@chello080108221029.1.13.vie.surfer.at, Remote host closed the connection)
11:42bobby_C has joined IRC (bobby_C!~bobby@chello080108221029.1.13.vie.surfer.at)
11:53ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood)
11:55ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
12:00VectorX has left IRC (VectorX!~knight@unaffiliated/vectorx, Ping timeout: 255 seconds)
12:02gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
12:02
<gvy>
hi!
12:13ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood)
12:14ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
12:15bobby_C has left IRC (bobby_C!~bobby@chello080108221029.1.13.vie.surfer.at, Read error: Connection reset by peer)
12:18bobby_C has joined IRC (bobby_C!~bobby@chello080108221029.1.13.vie.surfer.at)
12:21alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
12:23monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Read error: Operation timed out)
12:23freedomrun_ has joined IRC (freedomrun_!~quassel@BSN-142-162-34.dial-up.dsl.siol.net)
12:24freedomrun has left IRC (freedomrun!~quassel@BSN-142-162-34.dial-up.dsl.siol.net, Ping timeout: 265 seconds)
12:32komunista has joined IRC (komunista!~slavko@adsl-195-098-015-242.dynamic.nextra.sk)
12:35monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net)
12:36prem has left IRC (prem!~prem@180.149.48.229, Remote host closed the connection)
12:41bengoa has joined IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9)
12:58Parker955_Away is now known as Parker955
13:00bobby_C has left IRC (bobby_C!~bobby@chello080108221029.1.13.vie.surfer.at, Ping timeout: 240 seconds)
13:00mistik1 has left IRC (mistik1!~mistik1@unaffiliated/mistik1, Read error: Operation timed out)
13:03mistik1 has joined IRC (mistik1!mistik1@unaffiliated/mistik1)
13:05Parker955 is now known as Parker955_Away
13:05freedomrun_ has left IRC (freedomrun_!~quassel@BSN-142-162-34.dial-up.dsl.siol.net, Remote host closed the connection)
13:10komunista has left IRC (komunista!~slavko@adsl-195-098-015-242.dynamic.nextra.sk, Ping timeout: 252 seconds)
13:17VectorX has joined IRC (VectorX!~knight@unaffiliated/vectorx)
13:27khildin has left IRC (khildin!~khildin@ip166-155-209-87.adsl2.static.versatel.nl, Quit: I'm gone, bye bye)
13:42ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood)
13:42andygraybeal has left IRC (andygraybeal!~andy.gray@obsidian.casanueva.com, Ping timeout: 245 seconds)
13:44ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
13:45brunolambert has joined IRC (brunolambert!bruno@nat/revolutionlinux/x-lriwumglaxolpxym)
13:49staffencasa has joined IRC (staffencasa!~staffenca@128-193-149-96.oregonstate.edu)
13:50
<mgariepy>
good morning everyone
13:52bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
13:53
<alkisg>
Good morning
13:54
Precise, intel server, intel client, Unity not working... ideas?
13:54* alkisg tries unity-2d...
13:54
<mgariepy>
unity on a thin client ?
13:54
or on a fat client ?
13:55
<alkisg>
Thin
13:55
I think I never saw unity working on thin clients so far - although I haven't tried it much... is it supposed to be working?
13:56
<mgariepy>
the 2d is working but it takes quite a lot of bandwith
13:57
<alkisg>
So the best option is to install gnome-shell and use the classic session?
13:58
...shouldn't we at least default to ubuntu-2d then?
13:58
Yup ubuntu-2d works
13:59
Or... could we run the window manager locally?
14:10staffencasa has left IRC (staffencasa!~staffenca@128-193-149-96.oregonstate.edu, Ping timeout: 244 seconds)
14:10Yet_another_Bill has left IRC (Yet_another_Bill!billy@nat/redhat/x-fnjhqkvoytonlyay, Quit: Good night ^_^)
14:13
<mgariepy>
opening the panel is killing the network
14:13
at least it was a few months back
14:21
<Mava>
has any of you tried to boot sunray 2 thinclient into ltsp environemt? atm. having sunfire server running debian and one spare sunray 2 thinclient.. but honestly no idea what I should build into this ltsp server to be able to boot the thinclien from the server
14:21
<stgraber>
unity-2d should work, sadly unity-3d currently starts using software rendering making it crash and use a lot CPU
14:21
this is a bug in nux affecting more than LTSP so should be fixed soon
14:23
<Mava>
seems that this client is searching from network DNS name sunray-servers.DOMAIN and after founding that it tries to communicate with it using TCP and port 7009
14:24
<knipwim>
Mava: i think the sunray 2's use their own protocol to display something
14:24
as i recollect, they are truly stateless
14:25Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
14:26
<knipwim>
Mava: you need the sun ray software to make them work
14:26
<Mava>
knipwim: seems so.. more or less quite closed box. it seems they are only available to use their own SRSS (Sunrayserver software) and that's why it can be done
14:26
yea
14:27
<knipwim>
Mava: the sun ray software can be deployed on linux installs though
14:27
<Mava>
so to srss then or change to plans
14:28
found also one ubuntu based site concerning this srss
14:28
<knipwim>
yeah, saw it also when i was orienting
14:28
even gentoo was supported long ago
14:31
<Mava>
o.=
14:31
gees.. haven't been even able to install successfully ltsp on gentoo yet so SRSS in gentoo sounds pretty... perfect
14:35khildin has joined IRC (khildin!~khildin@ip-83-134-214-71.dsl.scarlet.be)
14:38
<knipwim>
Mava: gentoo ltsp works on my system :)
14:38
if you have any issues, i'd like to hear them
14:45
<Mava>
oooou
14:45
knipwim: you have no idea what you just promised.. my fingers are itching to start that project
14:47
but, once I find time to fiddle with gentoo I'll promise to tell some results to you about the project, whether they were good or bad. unfortunately priority is still a bit low for this, but...
14:53
<stgraber>
alkisg: I commited Q-FUNK's fix to the packaging branch, so it'll be there next time I upload
14:56
alkisg: wow, and thanks for the Launchpad cleanup ;)
14:59komunista has joined IRC (komunista!~slavko@adsl-195-098-015-242.dynamic.nextra.sk)
15:00mgariepy has left IRC (mgariepy!mgariepy@ubuntu/member/mgariepy, Quit: Leaving)
15:02mgariepy has joined IRC (mgariepy!mgariepy@ubuntu/member/mgariepy)
15:06
<alkisg>
stgraber: you're welcome ;) I should also close the -pae problem, right?
15:06
<stgraber>
alkisg: yep
15:07
<alkisg>
Closed :)
15:08komunista has left IRC (komunista!~slavko@adsl-195-098-015-242.dynamic.nextra.sk, Quit: Leaving.)
15:08freedomrun has joined IRC (freedomrun!~quassel@89.143.183.103)
15:09
<stgraber>
thanks
15:11loather has joined IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net)
15:11
<alkisg>
And we don't need the livecd-rootfs stuff anymore, do we? https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/540571
15:13
stgraber: where's your packaging branch? Maybe I can close a few more bugs about the alternate cd installer etc..
15:14
<stgraber>
alkisg: bzr get ubuntu:ltsp
15:14
<alkisg>
ty
15:15
<stgraber>
alkisg: you can either send me diffs or do merge proposals, whatever is the easiest
15:16
<alkisg>
I'll create a +junk branch and send you the link, or you can tell me how to send a merge proposal from there :)
15:19
<stgraber>
alkisg: just push to lp:~alkisg/ubuntu/precise/ltsp then do "bzr lp-propose-merge"
15:19
hmm: "lp:~alkisg/ubuntu/precise/ltsp/fixes" actually (or whatever you want instead of "fixes")
15:19
<alkisg>
OK, thanks - after the weekend probably, kids wanna go skiing :)
15:30Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Ping timeout: 272 seconds)
15:36Stefan544 has left IRC (Stefan544!~Stefan544@109-124-164-50.customer.t3.se, )
15:39
<alkisg>
stgraber: where should the ldm-related, non-ubuntu specific bugs go? https://bugs.launchpad.net/ubuntu/+source/ldm or https://bugs.launchpad.net/ltsp ?
15:41
<stgraber>
alkisg: https://bugs.launchpad.net/ltsp
15:41
<alkisg>
Ty, moving most of them... :)
15:41
<stgraber>
we probably should tag the bugs with ltsp, ldm, ltspfs, ltsp-docs, ... so we can easily find which component they're affecting
15:42
<alkisg>
I'm starting with removing all duplicate entries, so that we don't see the same bug in ltsp and in ltsp (ubuntu), that should reduce the mess, and we can continue with the tags later on
15:46jammcq has joined IRC (jammcq!~jam@70-91-230-209-BusName-Michigan.hfc.comcastbusiness.net)
15:46
<jammcq>
hello friends
15:47VectorX has left IRC (VectorX!~knight@unaffiliated/vectorx, Read error: Connection reset by peer)
15:48
<alkisg>
Hi jammcq :)
15:51
OK, only 2 bugs left in ldm (ubuntu) :d
15:51freedomrun_ has joined IRC (freedomrun_!~quassel@89.142.254.248)
15:51
<alkisg>
9 in ltsp (ubuntu), all the rest in ltsp (30)
15:52freedomrun has left IRC (freedomrun!~quassel@89.143.183.103, Ping timeout: 272 seconds)
15:53
<stgraber>
hey jammcq
15:54adrianorg has joined IRC (adrianorg!~adrianorg@187.115.107.166)
15:54
<gvy>
jammcq!!
16:00
<Hyperbyte>
jammcq!!!!!
16:05* highvoltage notices that alkisg assigned him a bug
16:05
<alkisg>
highvoltage: it was already assigned to you, just in ltsp (ubuntu) instead of ltsp
16:06
I didn't make any changes to assignees
16:06
<highvoltage>
ah
16:06risca has joined IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca)
16:08
<jammcq>
hey Hyperbyte
16:08
highvoltage: back in north america?
16:08
<highvoltage>
jammcq: yeppers
16:08
<jammcq>
welcome back
16:08
<highvoltage>
merci!
16:08
<jammcq>
stgraber: AWESOME job on the LTSP-5.3 release
16:08
kudos to EVERYONE involved
16:08
gvy: howdie
16:09
<stgraber>
jammcq: thanks, I was mostly monitoring and doing minor fixes for this release, alkisg and vagrantc did most of the work (started at the hackfest)
16:09khildin has left IRC (khildin!~khildin@ip-83-134-214-71.dsl.scarlet.be, Quit: I'm gone, bye bye)
16:09
<stgraber>
jammcq: I think I like the current 2 years cycle for major releases :) hopefully next one will be 6.0 with Scotty's new pam/nss magic
16:10
<jammcq>
yes, I'll be visiting scotty in may. I'll kick him to get moving on that
16:11
<alkisg>
stgraber, jammcq: I wonder, would using NIS make it easier for client authentication (without going to all the setting up ldap trouble)?
16:11* alkisg never used neither nis nor ldap
16:13
<jammcq>
ugh
16:13
isn't NIS evil ?
16:13
and really, with pam/nss, it shouldn't matter
16:13
<alkisg>
Dunno... I still see as supported it in a lot of places... is it insecure?
16:13
<jammcq>
ldap or nis could be used
16:13staffencasa has joined IRC (staffencasa!~staffenca@128-193-148-241.oregonstate.edu)
16:14
<jammcq>
nis is much easier to set up, but I don't think it's secure
16:14
<alkisg>
Ah... I just thought it would solve all the localapps etc authentication problems
16:14
<stgraber>
alkisg: scotty's stuff should fix everything for us without needing some evil like NIS
16:15
<alkisg>
Will e.g. a fat client user be able to change his password with pam/ssh?
16:15
Or unlock his screensaver?
16:16Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
16:17
<highvoltage>
didn't they implement a feature in X for that where you just have to enable numblock and press * or something?
16:19
<stgraber>
highvoltage: sadly Ubuntu didn't take that feature ;)
16:19
<alkisg>
Haha no that was a security issue :D
16:19
<highvoltage>
oh no. I had so many plans for that in the office :(
16:19
<stgraber>
alkisg: changing password I'm not sure how well pam_ssh handles it, but we can certainly add it without too much trouble
16:20
alkisg: unlocking the screensaver should work fine though
16:20Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Client Quit)
16:20
<alkisg>
Sounds very cool then, jammcq tell sbalneav that I'll send him as many baklavas as he can eat if he implements it :D
16:20
<jammcq>
i think the whole reason scotty was working on the ldap/pam/nss stuff was to handle password changing
16:21
alkisg: be careful what you promise. between me and scotty, you could go broke
16:21
<alkisg>
Hehe
16:21toscalix has joined IRC (toscalix!~toscalix@85.137.146.26.dyn.user.ono.com)
16:24Gremble has joined IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com)
16:24
<Gremble>
<Gremble> LDM_ALLOW_USER - does it actually work?
16:24
hi all
16:24
I asked this question yesterday, but had to leave before any answer came back
16:24
any ideas anyone?
16:25
I'm on Debian Squeeze
16:27
<alkisg>
Gremble: try LDM_USER_ALLOW
16:27
<Gremble>
OMG
16:27
does that change between distros?
16:27
<alkisg>
If it works, file a bug in LTSP so that we change the docs :)
16:28
No
16:28
<Gremble>
http://manpages.ubuntu.com/manpages/lucid/man5/lts.conf.5.html - its documented as LDM_ALLOW_USER there
16:29
cheers alkisg, I'll let you know
16:29
<alkisg>
ldm-trunk$ grep -rw LDM_USER_ALLOW *
16:29
rc.d/S20-restrictUser:if [ -n "${LDM_USER_ALLOW}" ]; then
16:29
rc.d/S20-restrictUser: for i in ${LDM_USER_ALLOW}; do
16:29
<Gremble>
:)
16:29
oopsy
16:32
<alkisg>
I want to update ltsp-docs, but english isn't my native language, so I'm hesitating a bit... does anyone volunteer to proofread them for grammar errors if I go ahead and update them?
16:32
<Gremble>
yes, me
16:32
:)
16:32killermike has joined IRC (killermike!~killermik@2.26.91.173)
16:33
<alkisg>
Cool, should I ping you here next week when I'm done with them?
16:34
Ty
16:37dobber has left IRC (dobber!~dobber@213.169.45.222, Remote host closed the connection)
16:38
<Gremble>
now worries, good to give something back, used to get more involved in sorting LTSP out, but now I'm just a user mainly, as it works so well for the most part
16:38loather has left IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net, Quit: This computer has gone to sleep)
16:40khildin has joined IRC (khildin!~khildin@ip-83-134-214-71.dsl.scarlet.be)
16:42gvy has left IRC (gvy!~mike@altlinux/developer/mike, Ping timeout: 240 seconds)
16:50asmok_web has joined IRC (asmok_web!559dcc0d@gateway/web/freenode/ip.85.157.204.13)
16:54gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
16:55Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
16:56asmok_web has left IRC (asmok_web!559dcc0d@gateway/web/freenode/ip.85.157.204.13, Quit: Page closed)
17:02gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: $HOME)
17:06markit has joined IRC (markit!~marco@88-149-177-66.staticnet.ngi.it)
17:16darkpixel_ has joined IRC (darkpixel_!~darkpixel@65.100.44.217)
17:17darkpixel_ has joined IRC (darkpixel_!~darkpixel@curetheitch/staff/darkpixel)
17:20risca has left IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca, Ping timeout: 245 seconds)
17:24risca has joined IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca)
17:28cliebow has joined IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us)
17:28dead_inside has joined IRC (dead_inside!~dead_insi@host-98-127-5-151.bln-mt.client.bresnan.net)
17:51GodFather_ has joined IRC (GodFather_!~rcc@c-98-250-128-114.hsd1.mi.comcast.net)
18:03toscalix has left IRC (toscalix!~toscalix@85.137.146.26.dyn.user.ono.com, Remote host closed the connection)
18:12dead_inside has left IRC (dead_inside!~dead_insi@host-98-127-5-151.bln-mt.client.bresnan.net, Quit: Leaving...)
18:18Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving)
18:18stratis has joined IRC (stratis!5e45cf58@gateway/web/freenode/ip.94.69.207.88)
18:19
<highvoltage>
stgraber, mgariepy: we should have some drinks in celebration of 5.3
18:19
<stratis>
alkisg τι έγινε με το στέκι των πληροφορικών;
18:19
<alkisg>
stratis: this is an english-only channel, use #linux.sch.gr for greek :)
18:20
Type /j #linux.sch.gr to join
18:29Gremble has left IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com, Quit: I Leave)
18:34stratis has left IRC (stratis!5e45cf58@gateway/web/freenode/ip.94.69.207.88, Quit: Page closed)
18:40
<stgraber>
highvoltage: sure ;)
18:43* alkisg tries to manually enable remote syslogging from a thin client, but he didn't manage to do it yet... any help?
18:43
<alkisg>
I'm using `tcpdump udp port 514 -i vboxnet0` and I see no messages arrive
18:44
In the client I've uncommented the IncludeConfig /etc/rsyslog.d/*.conf directive,
18:44
I renamed /etc/rsyslog.d/ltsp.conf to /etc/rsyslog.d/90-ltsp.conf so that it overrides the defaults,
18:45
I restarted the client rsyslog server, and I no longer see the messages in the client /var/log/syslog, but I don't see anything in tcpdump either
18:47komunista has joined IRC (komunista!~slavko@adsl-195-098-015-242.dynamic.nextra.sk)
18:51cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 240 seconds)
18:52
<alkisg>
stgraber: $ try_failure_hooks() {:;}
18:52
bash: syntax error near unexpected token `{:'
18:53
It needs spaces, but I haven't tried if plymouth is still fixed _with_ the spaces
19:02
<stgraber>
alkisg: oops ... yeah, it should be with the spaces
19:11Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Quit: "Achievement is not the end, its the beginning of new journey !!!")
19:29
<alkisg>
stgraber: the problem is again that `wait-for-root /dev/nbd0 30` doesn't detect the nbd root file system and waits for udev events for 30 seconds
19:29
I think that's because /dev/nbd0 is actually a "whole disk" and not a "partition"
19:29
$ udevadm info --query=all --name /dev/sda2 | grep ID_FS_TYPE
19:29
E: ID_FS_TYPE=ext4
19:30
udevadm info --query=all --name /dev/sda | grep ID_FS_TYPE
19:30
(nothing)
19:30
So, wait-for-root.c says that if it gets the ID_FS_TYPE from the device, it doesn't wait for udev events, and that's probably what we want
19:31
To work around it just temporarily, we can overwrite wait-for-dev with anything that returns tru
19:31
e
19:31risca has left IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca, Ping timeout: 255 seconds)
19:31
<highvoltage>
mgariepy: do you have either tonight or tomorrow night free?
19:31
<alkisg>
That will solve both the ROOTDELAY and the try_failure_hooks/plymouth problem
19:32risca has joined IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca)
19:37hughessd has joined IRC (hughessd!~steve@173-164-117-109-Oregon.hfc.comcastbusiness.net)
19:37cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
19:41alexqwesa_ has joined IRC (alexqwesa_!~alex@109.172.15.11)
19:41alexqwesa has left IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net, Ping timeout: 260 seconds)
19:41freedomrun has joined IRC (freedomrun!~quassel@89.142.254.248)
19:43
<stgraber>
alkisg: that'd work
19:43freedomrun_ has left IRC (freedomrun_!~quassel@89.142.254.248, Ping timeout: 260 seconds)
19:43
<alkisg>
stgraber: I'm digging into the udev rules a bit, to see if I can find a better fix, if not, I'll test+commit that
19:46
I.e. to write an udev rule that adds the ID_FS_TYPE property to /dev/nbd0
19:49Parker955_Away is now known as Parker955
19:51alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg)
19:51alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Disconnected by services)
19:51alkisg1 is now known as alkisg
20:15
<alkisg>
Found it: echo 'KERNEL=="nbd*", ENV{ID_FS_TYPE}="squashfs"' > /lib/udev/rules.d/90-squashfs.rules
20:27vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
20:27risca has left IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca, Ping timeout: 260 seconds)
20:28adrianorg has left IRC (adrianorg!~adrianorg@187.115.107.166, Ping timeout: 260 seconds)
20:28
<vagrantc>
slow start today...
20:28risca has joined IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca)
20:30vagrantc_ has joined IRC (vagrantc_!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
20:32
<alkisg>
stgraber: tested + pushed
20:32
<vagrantc>
so, to resolve the needless mail-transport-agent that gets pulled in, i guess i could use equivs to install a fake one.
20:32
<stgraber>
alkisg: cool
20:33
<alkisg>
Now it even saves us the 1 sec delay :)
20:33
<stgraber>
awesome :)
20:42
<alkisg>
vagrantc: I'd like to spend some time updating lts.conf.xml, how do you edit it? With a plain text editor?
20:42killermike has left IRC (killermike!~killermik@2.26.91.173, Remote host closed the connection)
20:43
<vagrantc>
alkisg: that's how i've edited it, dunno if others used anything fancier
20:44
<alkisg>
Ty... stgraber, any fancier tools for lts.conf.xml editing?
20:44
<stgraber>
I usually use vim for that, it's not great but it works ;)
20:45
<alkisg>
Haha ok I won't ask sbalneav, he'll tell me to use emacs :D
20:45
<stgraber>
alkisg: one thing I remember discussing with highvoltage and you may want to do is add a standard tag in the code next to where we use these variables
20:45
so then we can simply grep through the code for these comments and generate the list from that
20:46
<vagrantc>
i feel like i'm months behind LTSP development...
20:46
<alkisg>
stgraber: yes I thought about that in the past, sounds like a good idea, but will need a lot of work... maybe when we switch to the new configuration system for ltsp 6 or 7 :D
20:47
<stgraber>
having some way of extracting all the variables from the code would be awesome, this way we could potentially have scripts making sure all the variables are documented every time we release
20:47
<alkisg>
We can make the equivalent of "getltscfg" in the future to ignore all undocumented variables ;)
20:47
<stgraber>
alkisg: well, it can be done incrementally, we just need to tell everyone to put a standard comment in the code whenever they use a variable
20:47artista_frustrad has left IRC (artista_frustrad!~fernando@200.247.43.2, Quit: Leaving)
20:47
<vagrantc>
alkisg: your last commit seems to assume that squashfs is the only type of filesystem used with NBD ... ?
20:48
<alkisg>
vagrantc: I don't think it matters what I put there
20:48
<vagrantc>
?
20:48
<alkisg>
It's just a wait-for-root bug, the udev value isn't used for mounting
20:48
Let me try with ID_FS_TYPE=alkis...
20:48
<vagrantc>
pfft.
20:49
then it has the illusion of being related to squashfs, and that's confusing too :)
20:50
<alkisg>
Eh, no, it didn't work :D
20:51
<stgraber>
alkisg: try "rootfs"
20:52
<alkisg>
Nope
20:52
<vagrantc>
try with ext2
20:53
well, that lept out at me.
20:55
<alkisg>
mounting /dev/nbd0 on /root failed: invalid argument, again
20:55
We could write an udev RUN+= script to handle it... but that really should be done elsewhere, in udev, in squashfs, in initramfs-tools... dunno
20:56* alkisg tries with an empty ID_FS_TYPE...
20:56cliebow has left IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us, Quit: Leaving)
20:57
<alkisg>
No, that brought back the 30 secs delay again
20:57
We could overwrite "wait-for-root" with a script that returns "true", but that's not good either
20:58
(when called for /dev/nbd0 only)
20:59
<vagrantc>
the problem is a long wait for /dev/nbd0 to show up?
21:00
<alkisg>
Not exactly... init calls wait-for-root /dev/nbd0 30, and that in turn checks if it already knows the fstype, otherwise it wait for an udev signal for "device ready' which never comes because the device is already "ready", it's just that the ID_FS_TYPE info is missing
21:01
So not only it waits for 30 seconds, but it reports failure after that, and the failure hooks are called
21:01
...which break plymouth and I don't know what else
21:01
<stgraber>
alkisg: can you run "cat /proc/filesystems" from an initrd and look for any entry that's not nodev?
21:02
<alkisg>
Hey no ext2 there :)
21:03
ext3, ext4, fuseblk
21:03risca has left IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca, Ping timeout: 252 seconds)
21:03
<stgraber>
ok, try ext3 then
21:03
I'm assuming Debian probably also has ext3 builtin in their kernel or at least loaded very easily in the iniramfs
21:03
<alkisg>
There's no "squashfs" in /proc/filesystems
21:04
<stgraber>
not until you call mount
21:04
but wait-for-root is right after it
21:04bengoa has left IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9, Quit: Leaving.)
21:04
<alkisg>
Didn't work
21:04
<stgraber>
ok, maybe it actually has to match the filesystem then ;)
21:05
<vagrantc>
that's kind of what you're asking it to do...
21:08Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
21:10
<alkisg>
What I don't understand is how it manages to mount it after the 30 seconds delay
21:11
<vagrantc>
but setting ROOTDELAY=1 works around the problem?
21:11
or rootdelay=1
21:11
<alkisg>
Overwriting wait-for-root is better than that, because the failure hooks aren't called
21:11
...and there's no delay
21:12
So I think that up to now, the best idea is to divert wait-for-root and not call it for /dev/nbd0, but do call it for any other root devices
21:13
<vagrantc>
sounds like a painful best
21:13
<stgraber>
alkisg: did you try writting FSTYPE="ltsp" to /conf/param.conf?
21:14
<vagrantc>
alkisg: is this an ubuntu-specific problem?
21:14
i.e. i didn't notice issues when i was booting
21:14
<alkisg>
With the new root=/dev/nbd0 command line?
21:14
<vagrantc>
yes
21:15
<alkisg>
Hmmm
21:15* vagrantc was happy to see ltsp_nbd go
21:15
<alkisg>
:)
21:15
<vagrantc>
this was *days* ago, mind you... everything could have changed
21:15
<stgraber>
alkisg: wait-for-root is in a 'while [ -z "$FSTYPE" ]' loop, so if we define FSTYPE in the environment through /conf/param.conf, it "should" work, unless something resets it
21:15
<alkisg>
Setting FSTYPE might make the problem go away, but I still prefer the wait-for-root diversion, it's less intrusive
21:16
<vagrantc>
less intrusive?
21:16
<alkisg>
E.g. suppose that someone wants to use the same initramfs to boot a slow local disk
21:16
That way it won't have the ability to wait for a couple of seconds..
21:16
<||cw>
just a thought... could it be related to the nic going down/up and the switch having stp without portfast?
21:16
<stgraber>
alkisg: look for root=, if it's /dev/nbd0, then set FSTYPE=ltsp?
21:17
<vagrantc>
also check for init=/sbin/init-ltsp
21:17
<alkisg>
mountroot()
21:17
if [ -z "${ROOTFSTYPE}" ]; then
21:17
[ -n "${FSTYPE}" ] || FSTYPE=$(blkid -s TYPE -o value "${ROOT}")
21:17
ROOTFSTYPE="${FSTYPE}"
21:17
<vagrantc>
just in case they're also doing a non-ltsp NBD implementation with ltsp installed :)(
21:17
overwriting mountroot... that's like re-inventing ltsp_nbd
21:17
<alkisg>
We can just run blkid and set the fstype appropriately :)
21:18
<vagrantc>
stgraber: did you use mkdst for the tarball, or use dh_autoreconf?
21:18
<highvoltage>
stgraber: mgariepy says he doesn't feel like having some drinks with us because he feels like he hasn't done enough for LTSP 5.3 :'(
21:19
<alkisg>
He drove us all the way to the airport, that's more than enough :D
21:19
...and with the road full of snow
21:19
<stgraber>
highvoltage: ...
21:19
vagrantc: mkdst
21:20
<vagrantc>
hrm. gotta fix mkdst to support no autofoo mode.
21:20
having all that autofoo cruft in the upstream tarball makes code review between versions a bear.
21:21
<alkisg>
Yeah that sounds like a good plan. A local-top script, after nbd, which puts the output of blkid to param.conf
21:21
If it's empty, then wait-for-root will still be called
21:23Parker955 is now known as Parker955_Away
21:23
<highvoltage>
alkisg: hehe, indeed
21:23
<alkisg>
...should I name it nbd_ltsp? the opposite of ltsp_nbd :P
21:23
<vagrantc>
alkisg: what if the user wants to add something back in that was in one of the RM_* variables?
21:24
alkisg: it doesn't seem like there is any way to do that
21:24
<alkisg>
vagrantc: he's doomed
21:24
Yeah with all the hurry I missed some bits of "proper design"
21:24
We can put them now as bugfixes though :)
21:25
<vagrantc>
heh
21:25
too bad we didn't do this stuff like a month ago
21:25
<alkisg>
I would have done those right after the bts, but I thought that they weren't going to be in precise
21:25
So I left them for next year, after my phd...
21:26* alkisg thinks the best contribution of vagrantc to LTSP isn't his coding but his coding principles
21:26
<vagrantc>
oops
21:27
alkisg: i probably think of the flexibility "what if's" a lot
21:27
alkisg: sometimes to a fault
21:27
but yes, many times i feel like my biggest contribution is review of other's work
21:27
<alkisg>
In the next BTS, I'd like us to discuss a new (and more flexible) configuration mechanism
21:28
<vagrantc>
i can't wait till then, i'll need it before june
21:28
<alkisg>
The configuration system?
21:28
<vagrantc>
at least for things like removing services
21:29
ah, you mean the thing to replace lts.conf?
21:29
<alkisg>
Yup
21:29
An ldminfod like daemon which does everything in one
21:30
We started something like that with Gadi, but never finished it
21:30
And there's something similar in -cluster, we can merge that too
21:32
For the services... one thought is to make a convension, e.g. +service means "don't delete that"... another is to have a separate variable for the default deleted services, which can be overriden too
21:34
Or we can simply not add the user provided services to the list, but use it as is. So if the user doesn't want to delete one service, he'd have to provide all the others too
21:35
<vagrantc>
given my experience with RW_DIRS and such, that's a bad approach
21:35
when i implemented RW_DIRS_EXTRA, a huge sigh of relief was made.
21:35
<alkisg>
Or, a DONT_RM_SERVICES list
21:36
<vagrantc>
PLEASE_KINDLY_KEEP_SERVICES_REALLY
21:36
<alkisg>
Hehe
21:36
<vagrantc>
re-introduce the idea of a whitelist, basically.
21:36
KEEP_SERVICES
21:37
<alkisg>
Yeah.. did you have a whitelist with RW_DIRS?
21:37
...a way to not make the default ones RW?
21:37
<vagrantc>
with RW_DIRS, it was only the dirs listed, and later on i added an extra list, but you couldn't easily, without replacing the whole list, remove a dir.
21:38
though i think the comparison to services is a little different, i think you're more likely to want to enable a service that gets disabled by default than disable a writeable mountpoint that's writeable by default
21:38
<alkisg>
While with a proper configuration mechanism, those services would be listed in a conffile, and the user could just edit it
21:39
/etc/ltsp/rm-system-services etc
21:40
<vagrantc>
then you get into issues with updates
21:40
the + mechanism is workable.
21:41
<alkisg>
I like KEEP_SYSTEM_SERVICES / KEEP_THIN_SYSTEM_SERVICES better, easier to explain
21:42
<vagrantc>
harder to implement in code, though
21:42
at least, harder in my brain
21:42risca has joined IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca)
21:44* vagrantc is reminded of the loops within loops within loops problem of /etc/passwd processing we had a while back
21:45
<vagrantc>
for each service to remove, you'd have to check if you shouldn't remove it ...
21:45
<alkisg>
I think it can be done with two tr, two sort and a diff call, but it's faster if we do it with a single ${var%% $service } loop
21:45
<vagrantc>
that's either big loops, or lots of grep calls
21:46
<alkisg>
I'll try the latter
21:46
<vagrantc>
depends how big the loops get, too
21:46
but seems like you're removing a lot of services by default
21:46
<alkisg>
For 50 services, a single 50 times loop
21:47
Should be done in 0.0001 secs..
21:48
<vagrantc>
for each additional service to keep or remove
21:48mgariepy has left IRC (mgariepy!mgariepy@ubuntu/member/mgariepy, Quit: Leaving)
21:49Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving)
21:49
<alkisg>
No, for each of the (combined) RM_SYSTEM_SERVICES list
21:49
I'll have it in 5'...
21:52
<vagrantc>
ok
21:54
<alkisg>
Ah, `case` is even better than ${var% stuff}...
21:54
<vagrantc>
case is cool stuff.
21:57
<alkisg>
vagrantc: http://paste.ubuntu.com/846471/
21:57
Meh it took me 7, not 5 :P
22:03
<vagrantc>
ok, it takes a quarter of a second with around 1000 in both remove and keep services... not bad.
22:04
and that includes output
22:04
alkisg: ah, i see, you used some whitspace matching. nice.
22:05
<alkisg>
The loop will already be there, for the "rm" commands
22:05
So the actual overhead is just the case...
22:07
<vagrantc>
right.
22:07
in the past we've done loops within loops, but using case the way you did is rather elegant.
22:07* alkisg is a proud Delphi coder :)
22:07
<alkisg>
er... not so proud of the Delphi part :P
22:08
<vagrantc>
hah
22:08* vagrantc wondered if alkisg was referring to the more traditional Delphi refernce
22:09
<vagrantc>
or more classical Delphi reference
22:09
<alkisg>
Nah... the newer one, have 17 years of programming experience in that other OS
22:09
And 4 prouder ones in shell :D
22:10GodFather_ has left IRC (GodFather_!~rcc@c-98-250-128-114.hsd1.mi.comcast.net, Disconnected by services)
22:10
<vagrantc>
hah
22:10GodFather__ has joined IRC (GodFather__!~rcc@c-98-250-128-114.hsd1.mi.comcast.net)
22:10
<||cw>
yeay for wildcards in cases
22:11
<vagrantc>
that's two build failures because we've removed a bunch of cruft!
22:11* vagrantc cheers
22:14
<vagrantc>
speaking of cruft, should we finally kill of configure-x.sh ?
22:14
i think it's still in the source...
22:14
hah. i even install it...
22:15
<alkisg>
http://paste.ubuntu.com/846493 => without the case, real 0m0.007s, with the case, real 0m0.027s. For 1000 services to delete and 100 to keep, I think the "rm" commands will be 100 times longer :)
22:16komunista has left IRC (komunista!~slavko@adsl-195-098-015-242.dynamic.nextra.sk, Quit: Leaving.)
22:17
<vagrantc>
alkisg: what do you mean wwithout the case ?
22:17Parker955_Away is now known as Parker955
22:17
<vagrantc>
ah, if you pass 1 as an argument.
22:17
<alkisg>
Yup
22:17
To measure the difference, not the exact time
22:18
Ah and I'm using >/dev/null to not count the output
22:18
<vagrantc>
seems like a small increase for an important functionality increase.
22:19
<alkisg>
OK, I'll commit the KEEP_SYSTEM_SERVICES with the first chance
22:19
...and the other thing in local-top/nbd_ltsp :D
22:19
<vagrantc>
hopefully that's a freeze exception worthy change
22:20
<alkisg>
I'll hide it somewhere under the "bugfixes" label :P
22:24
<vagrantc>
are we basically to the point where ltsp-client-core is safe to install on a non-ltsp system and it would basically not break anything?
22:24
<alkisg>
I've seen a whole load of bugs about installation problems in launchpad about it
22:25
<vagrantc>
what do you mean?
22:25
<alkisg>
Dependencies problems? Haven't tried it yet
22:25bengoa has joined IRC (bengoa!~bengoa@187-27-60-216.3g.claro.net.br)
22:25
<vagrantc>
there was a preinst hook that fails to install if they don't touch /etc/ltsp_chroot
22:25bengoa has left IRC (bengoa!~bengoa@187-27-60-216.3g.claro.net.br)
22:25
<alkisg>
Ah
22:26
https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/470245 => biiig list of duplicates
22:26
<vagrantc>
but i'm wondering if we could make that go away now
22:27
<alkisg>
For each Ubuntu LTS release I write a manual (and an updated sch-scripts version) to describe how to best manage LTSP, for teachers here
22:27
For Precise, I'm thinking of suggesting to manage fat clients as vbox installations
22:27
...and develop a "vdi2squashfs" script
22:28
So I want to try installing ltsp-client-core in a normal VM client asap...
22:29
<vagrantc>
seems like we almost might be able to not break everything :)
22:29
might still be a problem if we force modules=netboot in the initramfs or whatever
22:29
<alkisg>
Why? Because of missing file system modules?
22:30
<vagrantc>
it might build the initramfs without disk modules or such
22:31
although i thought recent versions of initramfs-tools included the appropriate modules
22:32
<alkisg>
vagrantc: http://paste.ubuntu.com/846509/
22:32
Diff between the ltsp initramfs and the stock ubuntu initramfs
22:32
It doesn't look too big...
22:34
...and we need to copy the server /etc/default/keyboard to the chroot :)
22:35
<vagrantc>
thought i did that in ltsp-build-client plugins
22:36
finally got a successful build... let's see if it works...
22:37
<alkisg>
025-locales, cp /etc/default/console-setup $ROOT/etc/default/console-setup, but not the new "keyboard" file
22:37
<vagrantc>
oh well
22:37
can't keep up with all the latest fads
22:38brunolambert has left IRC (brunolambert!bruno@nat/revolutionlinux/x-lriwumglaxolpxym)
22:41
<vagrantc>
initramfs-tools/hooks/ltsp failed :(
22:42
<alkisg>
pushed the keyboard change
22:42
Why?
22:42
<vagrantc>
newfandangled nbd-client-proxy...
22:42
didn't install it in my packaging
22:43* jammcq misses the days when he was more involved in ltsp development
22:45* vagrantc waves to jammcq
22:45
<jammcq>
hey vagrantc
22:45
<alkisg>
Hey the Debian initramfs is < 10 Mb, in Ubuntu plymouth pushes it to 16 MB :( O
22:45
<vagrantc>
oh right, i handle nbd-proxy from debian/rules so we don't bother with it on non-linux arches
22:45
<jammcq>
i was congratulating the others earlier today on an awesome new release of ltsp.
22:46
vagrantc: major kudos goes to you too
22:46
<alkisg>
I'll send prebuilt debian chroots to schools with 64mb-ram clients :D
22:46
<vagrantc>
jammcq: thanks! it will surely be awesome. we may need some awesome bugfixes as well :)
22:48
though i think we're moving in really good direction.
22:48
using the init=/sbin/init-ltsp also allows distros that don't use an initramfs to play.
22:49
which may come in handy for my insane non-linux ports of LTSP :)
22:52khildin has left IRC (khildin!~khildin@ip-83-134-214-71.dsl.scarlet.be, Quit: I'm gone, bye bye)
22:54Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
22:55shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, Ping timeout: 276 seconds)
22:55Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Remote host closed the connection)
22:58jammcq has left IRC (jammcq!~jam@70-91-230-209-BusName-Michigan.hfc.comcastbusiness.net, Quit: leaving)
23:06
<vagrantc>
dynamically generating a package to satisfy the mail-transport-agent dependency has some appeal to it, although it's a bit on the ugly side.
23:07
s,dependency,recommends,
23:07
but that would allow it to install by default, without disabling recommends, and still allow them to install a real mta if they really want one.
23:08
and not have a huge mta installed and needlessly running.
23:08darkpixel_ has left IRC (darkpixel_!~darkpixel@curetheitch/staff/darkpixel, Quit: Leaving.)
23:09
<vagrantc>
well, initial boot was pretty ugly failure
23:09
ltsp-init spit out some error messages, /proc/cmdline wasn't parseable somewhere... but let's see...
23:09
but ldm came up, and can log in...
23:10
<alkisg>
vagrantc, stgraber: OK, pushed the yet-another-better workaround for wait-for-root
23:10
<stgraber>
cool!
23:11* vagrantc worries alkisg is about to turn into a pumpkin
23:13
<alkisg>
Kids gone to bed, logs in the fireplace, what better time to stay up coding :D
23:14
<vagrantc>
so, apparently /proc isn't available when init-ltsp is running :(
23:15
so some of the features are broken.
23:15
that's why running from initramfs had it's advantages
23:15darkpixel_ has joined IRC (darkpixel_!~darkpixel@65.100.44.217)
23:17
<vagrantc>
at least on my implementation of proc...
23:17
i guess one way would be to pass /proc/cmdline on somehow...
23:18
i'm not sure mounting it from there would be the best thing
23:18
seems like /proc/cmdline and /proc/meminfo are the ones that get called
23:18
<alkisg>
So if I put init=/bin/bash in debian, I won't get /proc mounted?
23:19* alkisg tries..
23:19
<alkisg>
vagrantc: I did get /proc mounted
23:20
vagrantc: are you using init=/sbin/init-ltsp? Or are you calling it from the initramfs?
23:20
<vagrantc>
init=
23:21
<alkisg>
cat /etc/issue => wheezy
23:21
And I have /proc mounted
23:21* vagrantc tries again and fires up a shell
23:21
<alkisg>
What do you get if you mount -t proc proc /proc?
23:22
can you cat /proc/mounts then?
23:22
<vagrantc>
i get it then...
23:23
initramfs-tools 0.100
23:23
<alkisg>
Hmm 0.99 here, let me upgrade...
23:23
(no ltsp, plain debian/lxde)
23:23
<vagrantc>
running 0.99 here...
23:23
but 0.100 in the initramfs
23:25
the 0.100 changelog for initramfs-tools includes unicode snowmen
23:26
0.100 was just uploaded 3 days ago
23:27
wonder if it was: * [5c68e6e] init: Prepare for switch_root(8) usage
23:28
<alkisg>
Hey I'm in the 0.100 changelog!
23:29
[ Alkis Georgopoulos ] * [b938c7e] configure_networking() wait for udev to populate available nics (LP: #682445)
23:29
<vagrantc>
alkisg: checking git, it seems like the switch_root call doesn't mount -o move /proc
23:30
<alkisg>
And it's mounted later on by init? Weird... but if you have to, you can temporarily mount it in init-ltsp, I guess.
23:31* vagrantc is looking into mounting it the same way when switch_root is used
23:31
<alkisg>
vagrantc: link to git?
23:31
<vagrantc>
doesn't work
23:31
well, that's a real shame.
23:32
<alkisg>
I hope we don't get any 0.100 initramfs-tools upgrade which will break ltsp in precise... :O
23:32
<vagrantc>
i didn't actually test it
23:33
forgot ltsp-update-kernels
23:34
<alkisg>
switch_root moves already mounted /proc, /dev and /sys to newroot and makes newroot the new root filesystem and starts init process.
23:34
<vagrantc>
alkisg: ok, so adding the mount move code worked...
23:34
<alkisg>
So it sounds like it should be taken care of without ltsp interviening...
23:34
<vagrantc>
oh, so switch_root should have handled that but didn't?
23:35
<alkisg>
Guess so
23:36
<vagrantc>
here's the weird thing...
23:36
switch_root isn't in the initramfs... but updating the codepath that uses it seems to work...
23:37
the new NBD_SWAP_THRESHOLD is kinda huge.
23:38
<alkisg>
vagrantc: and the new default SIZE too :D
23:38* alkisg ducks...
23:39
<alkisg>
I've heard many times people here with RAM-related problems
23:39
And activating or increasing the swap made them go away
23:39
I think it'd be better if the default covered most use cases, and those that want something more conservative, can set it in lts.conf...
23:40
<vagrantc>
suppose...
23:40
<alkisg>
I've seen firefox (not localapps) needing 300 mb for pixmaps
23:40* vagrantc also really doesn't like unencrypted swap by default
23:40
<alkisg>
Let's make encrypted the default then, I don't think it'll affect the performance much...
23:41
<vagrantc>
and then you're back to mkswap on client-side
23:41
<alkisg>
The code is already there, didn't touch that
23:44uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net)
23:44
<uskerine>
hi
23:45
could someone explain me if i could replace XDMCP with LTSP?
23:45
<alkisg>
uskerine: do you want remote booted clients, without using the local disks, or just remote desktop functionality?
23:46
<uskerine>
i want to deploy a server to be accessed by 15 concurrent users (through thin clients)
23:46
I have been happy with XDMCP since many years ago
23:46
<vagrantc>
oh, apparently ENCRYPT_SWAP is true by default...
23:46
<alkisg>
???!
23:46
Really?!
23:46
<uskerine>
but as server distro I have chosen LUBUNTU, which comes with LXDM which does not support XDMCP
23:46
hence I am looking for an alternative
23:46
alkisg, does it answer your question?
23:46
<alkisg>
uskerine: then LTSP does sound fine for you, you even get sound and local devices support
23:47
<uskerine>
that's great, as i would like to be able to have a soft-phone on the thin client
23:47
<alkisg>
How much RAM on the clients?
23:47
<uskerine>
could you please help me to start moving forward with this? how does it work?
23:47
i didn't buy them yet
23:47
i am thinking in an optiplex FX170
23:47
or something similar
23:48
<alkisg>
With 1 Gb RAM you could run fat clients, with lubuntu running locally, using a networked disk served by ltsp
23:48
!fatclients
23:48
<ltsp>
alkisg: fatclients: You may find some info about the Ubuntu/LTSP implementation of fat clients at https://help.ubuntu.com/community/UbuntuLTSP/FatClients
23:48
<alkisg>
Then you just install your softphone app to your chroot
23:49
<uskerine>
i see
23:49
so instead of deploying a server with 8gb ram or something like that
23:49
<alkisg>
You can use an optiflex for the server too :D
23:50
<uskerine>
well, i acatually think in reusing an old optiplex as server
23:50
equipped with more memory
23:50
optiplex fx170 is a pure thin client
23:50
http://www.dell.com/es/empresas/p/optiplex-fx170/pd
23:50
<alkisg>
2 Gb ram should suffice for the fat client server
23:50
<uskerine>
i understand
23:51
is it fast to run applications on the thin (fat) client without any sort of disk?
23:51
<alkisg>
I suggest you try lubuntu precise, not earlier
23:51
<uskerine>
lubuntu precise?
23:51
sorry i am not following you
23:51
<alkisg>
yes
23:51
Ah, that's lubunt 12.04
23:52
The one that's not released yet, it's in alpha 2
23:52
<uskerine>
i have installed the latest one
23:52
why should i use that one?
23:52
<vagrantc>
alkisg: apparently it's busybox's switch_root
23:52
<uskerine>
i have used the latest stable one
23:52
the one that you get directly from the main website
23:52
<alkisg>
uskerine: because fat clients had problems with lubuntu in previous ltsp versions
23:52
<vagrantc>
alkisg: which maybe doesn't do everything needed :(
23:52
<uskerine>
alkisg what about soft clients
23:52
<alkisg>
uskerine: With gigabit network and fat clients it's like if the clients had local disks, no difference at all
23:53
<uskerine>
that's good
23:53
<alkisg>
vagrantc: ah, ok so nothing to worry about in the long run, maybe a workaround for now
23:53
<uskerine>
so alkisg, could you briefly explain which are the main steps to set up this stuff?
23:53
and later point me to some good tutorial
23:53
<vagrantc>
alkisg: so i think i need to file a bug with initramfs-tools and see if they want to bother busybox to fix that, or implement a workaround themselves...
23:54
<alkisg>
uskerine: download the lubuntu 12.04 alpha 2 desktop .iso cd, install it, then follow the fatclients page I linked above
23:54
<uskerine>
even when the webpage is fot UBUNTU and not for LUBUNTU?
23:55
<vagrantc>
alkisg: alternately, i could try and force it to use switch_root binary, and see if that behaves correctly.
23:55
<alkisg>
uskerine: http://cdimage.ubuntu.com/lubuntu/releases/12.04/alpha-2/
23:56
<uskerine>
alkisg, is there any option to use thin clients with LTSP?
23:56
-i like the fat clients way but i might want to start at the beginning with thin clientes which might be easier to setup
23:56
<alkisg>
uskerine: a fat chroot can boot both thin and fat clients
23:56
<uskerine>
at the very beginning i will have only 3 or 4 users
23:56
<vagrantc>
uskerine: LTSP is thin clients
23:57
although performance for things like softphones will suffer using thin clients
23:57
<uskerine>
ok so in XDMCP, the login server (formerly XDM) listened at UDP 177 for incoming XDMCP connections
23:57
how does it work with LTSP?
23:57
<vagrantc>
you could use thin clients with localapps
23:57
and just run the local application as a thin client ... but fat clients are probablysimpler
23:57
<uskerine>
let's park the softphones for now, i would be more than happy for recovering the old and good XMDCP functionality :)
23:58
<vagrantc>
uskerine: it uses ssh to log into the server and start the X session that way.
23:58
which takes a performance hit, but there's an optiion to disable that for most of the traffic
23:58
<uskerine>
vagrantc, but i guess it runs a full xserver on the thin client, right?
23:58
<vagrantc>
no more so than XDMCP did
23:59alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg)
23:59
<uskerine>
i see
23:59* alkisg1 starts hating his ISP...
23:59
<vagrantc>
alkisg: using /sbin/switch_root worked, rather than busybox's switchroot