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


Channel log from 6 March 2012   (all times are UTC)

00:07primeministerp has left IRC (primeministerp!~ppouliot@static-71-174-244-28.bstnma.fios.verizon.net, Remote host closed the connection)
00:14andyGraybeals has left IRC (andyGraybeals!~andy@h215.212.22.98.dynamic.ip.windstream.net, Read error: Operation timed out)
00:29
<vagrantc>
hmmm... NFS support using qemu-system-arm doesn't work so well.
01:22Parker955_Away is now known as Parker955
01:37risca has left IRC (risca!~risca@wi-secure-5637.cc.umanitoba.ca, Quit: Lämnar)
01:57Parker955 is now known as Parker955_Away
01:59DIoX|DaZ has left IRC (DIoX|DaZ!~KaKa@server.civicclub.lt, Ping timeout: 240 seconds)
02:01
<vagrantc>
tagged ltsp 5.3.4 ... working on editing the changelog, and then upload.
02:11DIoX|DaZ has joined IRC (DIoX|DaZ!~KaKa@server.civicclub.lt)
02:24Parker955_Away is now known as Parker955
02:25
<vagrantc>
ah, the dir ltsp-client-setup isn't really even used anymore.
02:47adrianorg__ has left IRC (adrianorg__!~adrianorg@186.215.16.184, Ping timeout: 245 seconds)
02:51risca has joined IRC (risca!~risca@out-on-143.wireless.telus.com)
03:08risca has left IRC (risca!~risca@out-on-143.wireless.telus.com, Quit: Lämnar)
03:58
<vagrantc>
ltsp 5.3.4-1 uploaded to debian
04:04
and of course, i forgot my workaround.
04:04
for the stupid apt-get clean bug.
04:18Parker955 is now known as Parker955_Away
05:25
<shogunx>
hey vagrantc. the little arm based hp works great. thanx.
05:28
<vagrantc>
shogunx: ah, cool!
05:29
shogunx: i haven't messed with it in a while, i guess they were discontinued
05:31alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
05:33
<shogunx>
yep... should be cheap if you can find them tho.
05:48monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 255 seconds)
05:58alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
05:58
<vagrantc>
shogunx: so the howto worked for you? i didn't miss any steps?
06:00monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net)
06:01alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
06:01
<vagrantc>
alkisg: morning!
06:01
<alkisg>
Hi vagrantc!
06:02
Saw you released 5.3.4, nice!
06:03
<vagrantc>
yup.
06:03* alkisg wants to spend some time today optimizing LTSP wrt RAM usage
06:03
<vagrantc>
definitely better than the last version, but still a few things i'm not satisfied with
06:03
<alkisg>
Like what?
06:05
<vagrantc>
still don't like hoow i handle ltsp-update-image ...
06:06
<alkisg>
I'm going to write an ltsp-publish-image alternative in the next couple of months, maybe you could use that instead...
06:06
<vagrantc>
hope so!
06:16
<alkisg>
Btw should we try to utilize the -regex parameter of mksquashfs, to exclude some files/dirs like /root/*, /proc/*, /var/cache/apt/archives/* etc?
06:16
Or would it be better to have an option to "ltsp-publish-image --clean-tree"?
06:24
I'm thinking of disabling the network-manager service on thin clients by default,
06:24
and idmapd portmap rpcbind-boot if "nfs" isn't contained in /etc/fstab... vagrantc, those services aren't needed for the nfs root mounted by the initramfs, right?
06:32
...and we probably don't need dbus on thin clients either... we didn't have it before
06:41
Meh /etc/update-motd.d needs more than 1 second... should find a way to disable it without disabling the mounted-run service
06:57
<vagrantc>
alkisg: the excludes generally catch the whole dir...
06:57
<alkisg>
vagrantc: even with regex?
06:58loather-work has joined IRC (loather-work!~khudson@wsip-98-175-250-115.sd.sd.cox.net)
07:01killermike has joined IRC (killermike!~killermik@2.26.91.162)
07:06
<alkisg>
openvt could go away too, with a bit of restructuring we can avoid using its -wait parameter...
07:12
<vagrantc>
alkisg: dunno. experimentation will tell.
07:12
openvt go away?
07:12
<alkisg>
Yes no need to have it wait there wasting ram
07:13joat has joined IRC (joat!~freenode@ip70-160-216-251.hr.hr.cox.net)
07:13
<alkisg>
ltsp-client-core => start_screen_sessions => start-stop-daemon => screen_session => ( entry scripts, openvt screen_script, exit scripts)
07:14
If we put openvt before screen_session, there's no need to wait for it
07:17
<vagrantc>
the reason for the wait was to control which vt actually got priority.
07:18
<alkisg>
I don't get it, in other words?
07:18
<vagrantc>
if you have multiple X sessions, it's a race condition as to which actually ends up with the controlling tty.
07:18
<alkisg>
We can call openvt without the -s (switch) parameter
07:18
And only put the -s to the default screen script
07:19
The waiting currently is done with fgconsole + sleep, not with openvt
07:19
The openvt wait afaik is only because openvt itself is in the wrong position in the code
07:20
<vagrantc>
you're a clever one, alkisg :)
07:20
<alkisg>
Haha :D
07:20
The problem is that screen_session will need a bit of rewriting to get it properly... not sure if stgraber will be ok with that , precise-freeze considered
07:22
vagrantc: why are we using start-stop-daemon instead of e.g. plain openvt?
07:22* alkisg has yet to understand the concept/usefullness of start-stop-daemon in general...
07:38alexqwesa has left IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net, Quit: Хана X'ам !!!)
07:44alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net)
07:46
<vagrantc>
alkisg: it keeps track of a variety of things
07:49
well, long day, turning in.
07:49
<alkisg>
'night vagrantc
07:50vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Quit: leaving)
07:58khildin has joined IRC (khildin!~khildin@ip-80-236-227-45.dsl.scarlet.be)
08:17alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
08:18loather has left IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net, Quit: This computer has gone to sleep)
08:25khildin has left IRC (khildin!~khildin@ip-80-236-227-45.dsl.scarlet.be, Ping timeout: 276 seconds)
08:36dobber has joined IRC (dobber!~dobber@213.169.45.222)
08:54bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
09:13rickogden has joined IRC (rickogden!~rickogden@146.87.65.30)
09:17Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com)
09:19Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com)
09:20xsl has joined IRC (xsl!~silence@unaffiliated/xsl)
09:25ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood)
09:27ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
09:58loather has joined IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net)
10:01loather-work has left IRC (loather-work!~khudson@wsip-98-175-250-115.sd.sd.cox.net, Quit: This computer has gone to sleep)
10:03bmonkj has joined IRC (bmonkj!~skumlesen@46.32.130.15)
10:04bauerski has joined IRC (bauerski!~witekb@frodo.psp.opole.pl)
10:07khildin has joined IRC (khildin!~khildin@ip-80-236-227-45.dsl.scarlet.be)
10:27alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
10:28Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71)
10:42alexqwesa has left IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net, Quit: Хана X'ам !!!)
10:47Mava has left IRC (Mava!~Mava@ip-45-224.dhcp.opintanner.fi, Read error: Operation timed out)
10:47Mava has joined IRC (Mava!~Mava@ip-45-224.dhcp.opintanner.fi)
10:53adrianorg__ has joined IRC (adrianorg__!~adrianorg@186.215.16.184)
10:57wim_ has joined IRC (wim_!~chatzilla@WEGC203035.KFUNIGRAZ.AC.AT)
10:58alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
11:02andyGraybeals has joined IRC (andyGraybeals!~andy@h215.212.22.98.dynamic.ip.windstream.net)
12:09ltsp has joined IRC (ltsp!ltspbot@middelkoop.cc)
12:10
<Hyperbyte>
Hm
12:11ltsp` has left IRC (ltsp`!ltspbot@middelkoop.cc, Ping timeout: 245 seconds)
12:11
<Hyperbyte>
Ah.
12:14[GuS] has joined IRC ([GuS]!~MysT@unaffiliated/gus/x-663402)
12:14alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net)
12:20monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, *.net *.split)
12:20TatankaT has left IRC (TatankaT!~tim@peno.cwlab.kotnet.org, *.net *.split)
12:20leio has left IRC (leio!~leio@gentoo/developer/leio, *.net *.split)
12:20shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com, *.net *.split)
12:21xsl has left IRC (xsl!~silence@unaffiliated/xsl, Quit: Connection reset by fear)
12:23monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net)
12:23TatankaT has joined IRC (TatankaT!~tim@peno.cwlab.kotnet.org)
12:23leio has joined IRC (leio!~leio@gentoo/developer/leio)
12:23shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com)
12:27artista-frustrad has joined IRC (artista-frustrad!~fernando@200.247.43.2)
12:27wim_ has left IRC (wim_!~chatzilla@WEGC203035.KFUNIGRAZ.AC.AT, Quit: ChatZilla 0.9.88 [Iceweasel 10.0.2/20120217174734])
12:45* [GuS] Morning
12:50Parker955_Away is now known as Parker955
12:57Parker955 is now known as Parker955_Away
12:57rickogden has left IRC (rickogden!~rickogden@146.87.65.30, Quit: Leaving.)
13:06brunolambert has joined IRC (brunolambert!bruno@nat/revolutionlinux/x-ktldenookkphejwi)
13:22primeministerp has joined IRC (primeministerp!~ppouliot@static-71-174-244-28.bstnma.fios.verizon.net)
13:53alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
14:08
<Hyperbyte>
Morning GuS :-)
14:13dead_inside has joined IRC (dead_inside!~dead_insi@76.75.3.174)
14:20khildin has left IRC (khildin!~khildin@ip-80-236-227-45.dsl.scarlet.be, Ping timeout: 276 seconds)
15:03Da-Geek has joined IRC (Da-Geek!~Da-Geek@50.56.228.48)
15:07
<alkisg>
I'm thinking of disabling cron, dbus, rsyslog etc for clients with <=128 MB RAM... or does that sound too extreme?
15:07
(they can be reenabled from lts.conf)
15:09
<Hyperbyte>
How much ram do cron, dbus and rsyslog use?
15:10
They all use next to nothing, don't they?
15:11
<alkisg>
Errr I wouldn't say that, no
15:11
In real testing, disabling those services made a major difference in an 128mb client
15:11
I.e. first it needed to swap all the time, making surfing unbearable, and after the removal it worked fine
15:11
When a client has 4 MB free, even 1 more makes a difference
15:11
dbus-daemon: 4060 1936
15:12
rsyslogd: 39388 1496
15:12
cron: 2600 884
15:12
<Hyperbyte>
mhm
15:12
On my client, pulseaudio is a huuuge memory hog
15:12
<alkisg>
Than can be disabled with SOUND=False
15:13
<Hyperbyte>
This I know
15:14
<alkisg>
Essentially cron is only used for SHUTDOWN_TIME, rsyslog for troubleshooting, and dbus for nothing that I know of.
15:14
(since ldm isn't dbus-aware)
15:14
So having extreme lags just in case you'd want to troubleshoot something sometime, doesn't sound right to me...
15:22toscalix has joined IRC (toscalix!~toscalix@195.235.115.44)
15:28khildin has joined IRC (khildin!~khildin@ip-80-236-227-45.dsl.scarlet.be)
15:31
<Hyperbyte>
You could implement the LDM idle shutdown feature request, and then obsolete SHUTDOWN_TIME and cron. ;-)
15:32
<alkisg>
Or implement a lighter kernel? :P
15:33
Meh it still lags some times even with those services disabled... let me disable localdev and localapps too
15:34
<Hyperbyte>
That saves a bunch, doesn't it? sshfs, for starters...
15:37
<alkisg>
Yeah... so my idea is that 64-128mb ram clients would be in a "only basic things work" mode, because it's not possible to do otherwise with all the kernel/X bloat etc, and clients with more than 128 would work as usual
15:38
Before starting the optimization process, my 128mb client booted in 5 mins, due to swapping :
15:42rickogden has joined IRC (rickogden!~rickogden@146.87.86.156)
15:42
<alkisg>
Yup, keeping only the sound did it, 128mb ram client works. No localdev, localapps, cron, dbus etc etc
15:43
<Hyperbyte>
alkisg, you know my phone has more than 128mb ram right? :P
15:43
Actually six times as much. :P
15:44
<||cw>
Hyperbyte: one of the selling points of thin clients is that you don't have to replace them unless they fail. there's plenty of 10 year old clients out there...
15:44
<Hyperbyte>
Hehe, I know... I'm just rubbing it in a little.
15:44
<||cw>
and since the CFO's were told they wouldn't have to be replaced, getting budjet to replace them simply due to kernel bloat is hard to manage
15:45
I would love to see the JeOS images make a return
15:45
<Hyperbyte>
alkisg is working in a school environment, I'm working for a commercial organisation, where our main reason for using LTSP is freedom & elimination of local system management
15:45
Different environment. :-)00000000000
15:45
<alkisg>
Hyperbyte: unfortunately we have thousands of 15 year old computers, and it was hard to put more ram into them so that they have 64 or 128 !
15:46
<Hyperbyte>
So I tease alkisg a little about it, but deep down inside I'm actually quite proud of what he achieves with what little hardware he has.
15:46
<alkisg>
Telling them they'll have to drop 64mb clients is bad enough :(
15:46
But if you want to send us your servers, they're most welcome :P
15:47
<||cw>
alkisg: any local off-lease pc recyclers? they are practically giving away P3's with 256MB+, one might actually give them for a tax writeoff
15:47
<alkisg>
||cw: I'm trying to make things better for schools in all greece, so it's difficult to find so many recycled pcs
15:48
And I don't think we have tax writeoffs for giving hardware to schools here
15:49
<||cw>
that's too bad
15:51
<Hyperbyte>
alkisg, by the way... over here there's been a lot of complaints about all the money that the Netherlands and EU are sending to Greece, to help the financial situation there... lots of politicians critised Greece for not managing things well, etc...
15:52
<alkisg>
That's true
15:52
<Hyperbyte>
Five days ago it was announced that the Netherlands is having a big financial problem, and we need to cut 16 billion within the next year.
15:52
<alkisg>
What's worse is that things were better before the EU started sending money 10-15 years ago
15:52
<Hyperbyte>
Haha... haven't heard anyone complain since then...
15:52
<alkisg>
Haha
15:53
<Hyperbyte>
I wonder how they're gonna get 16 billion though... seeing as we only have about 16 million people living here, that's quite a big number.
15:55
By the way, the 16 will be on top of the 18 billion euros of cutbacks that have already been decided on.
15:55
<alkisg>
Well... after all that, how much money will a public teacher make per month there?
15:57
<Hyperbyte>
I have no idea.
15:58
Income in public sector isn't so bad here I think.
16:06
<alkisg>
OK, done testing, so at least for ubuntu 12.04 I think that 128 mb clients == bare mode with just sound, 64 mb clients == unsupported.
16:07
I'll commit the changes later on so that 128 mb clients at least work without terrible lags.
16:31bengoa has joined IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9)
16:33alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
16:39toscalix has left IRC (toscalix!~toscalix@195.235.115.44, Read error: Connection reset by peer)
16:40dobber has left IRC (dobber!~dobber@213.169.45.222, Remote host closed the connection)
16:41alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
16:42rickogden has left IRC (rickogden!~rickogden@146.87.86.156, Quit: Leaving.)
16:56komunista has joined IRC (komunista!~slavko@adsl-195-168-242-217.dynamic.nextra.sk)
17:00komunista has left IRC (komunista!~slavko@adsl-195-168-242-217.dynamic.nextra.sk, Client Quit)
17:04dptech has joined IRC (dptech!~dptech@can06-1-82-242-223-39.fbx.proxad.net)
17:16[GuS] has left IRC ([GuS]!~MysT@unaffiliated/gus/x-663402, Remote host closed the connection)
17:27srdjo has joined IRC (srdjo!~srdjo@109.228.93.179)
17:28
<srdjo>
hi all
17:28
can someone help me with LTSP FAT client cups setup ?
17:28
i added CUPS_SERVER=localhost in lts.conf
17:33
<mmetzger>
srdjo: For a local or a network printer
17:33
?
17:36
<srdjo>
local printer
17:36
on one client
17:36
and the same printer shared to other clients (on other clients)
17:37
I can set it and it works until I log off
17:37
but when I log on it is not there any more
17:37
it is the same for local and network printers
17:38
<mmetzger>
I haven't done much with local printers yet, but I believe you can simply set the PRINTER_X_* settings to configure it appropriately
17:39
And then set the other clients to use it as the cups server
17:41
<Hyperbyte>
srdjo, LTSP uses jetpipe for local printers, basically turning your LTSP clients into print servers. So you can just configure your printer on your CUPS server as a network printer with the client address.
17:41
<srdjo>
the same way we did for thin clients ?
17:42
it all worked well when we used thin client
17:42ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 246 seconds)
17:43ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
17:48monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 255 seconds)
17:49
<Hyperbyte>
Hmm, I think easiest is to configure cups on the server with all printers, and set the clients to use cups on the server
17:51
<srdjo>
that is the way we used it until we converted all of our thin clients to fat
17:51
cups server is on the ltsp server
17:51
and it all worked
17:52
but we had some small problem - if we had to turn of or restart the printer, we would have to restart the thinclient also
17:52
<alkisg>
srdjo: so it works for one time, and then after you logoff you lose the printer?
17:52
<srdjo>
yes
17:52
<alkisg>
Ubuntu? Which version?
17:52
<srdjo>
it looks like cups settings are not persistent
17:53
11.10
17:53
<alkisg>
Also, why "localhost"? Don't you want the other clients to be able to see that printer?
17:53
I imagine that you'd need to put the client IP there
17:53
<srdjo>
they see it - i enable "see shared printers on other systems" on other cilents
17:54
and they see it
17:54
but only until they log off
17:54
<alkisg>
Hmm that doesn't sound right
17:54
I think that CUPS_SERVER defaults to LDM_SERVER, which defaults to SERVER
17:55
Anyway... from that fat client with the printer, if you log off and then back on, do you see the printer again?
17:55
<srdjo>
no - until i add it again
17:55
<alkisg>
Wait, you need to add the printer? It's not automatically added?
17:57
<srdjo>
in system-config-printer I have a screen like this
17:57
http://fermilinux.fnal.gov/documentation/tips/printing/slf5/printer-configuration-server-settings-2.png
17:57
and I select a sone of these settings
17:58
but when I log on, they are all unchecked
17:58
<alkisg>
That part is to share the printer. But, are you seeing the printer from that client where it's plugged in?
17:58
<srdjo>
give me a moment to check
17:59
<alkisg>
What I'd like to know is, if you logoff + logon on that client with the printer any number of times, if you're *always* able to see the printer and print there locally
18:00monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net)
18:04
<srdjo>
i am not able to see if it is shown localy because the office is currently locked, but it is not shared anymore and it was until the coworker relogged in the system
18:06
the other system that also has the local printer and that was left loged in is shown (coworket forgot to log off)
18:09dptech has left IRC (dptech!~dptech@can06-1-82-242-223-39.fbx.proxad.net, Quit: When two people dream the same dream, it ceases to be an illusion. KVIrc 3.4.2 Shiny http://www.kvirc.net)
18:14
<alkisg>
The current logic of CUPS_SERVER is to point an ltsp client to another (possibly non-ltsp) system with a shared printer. So CUPS_SERVER only works when an ltsp user is logged on, and the setting is deleted on logout.
18:15
...maybe another variable needs to be introduced for sharing local printers with cups
18:15yanu has left IRC (yanu!~yanu@lugwv/member/yanu, Read error: Connection reset by peer)
18:15yanu has joined IRC (yanu!~yanu@lugwv/member/yanu)
18:23Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com, Quit: Leaving)
18:24komunista has joined IRC (komunista!~slavko@adsl-195-168-242-217.dynamic.nextra.sk)
18:24
<srdjo>
this way of using the local printers with fat clients is much better then using jetpipe because one can restart the printer without restarting the client the printer is on.
18:24
also the configuration is much simpler
18:25
we only need to find a way to make changes persistent
18:25
or point each client to unique cups.config file on the server
18:25
and then we would have true FAT client support
18:26
<alkisg>
srdjo: file a bug report so that the problem is not forgotten, I'm sure that a developer will fix it when he needs it :D
18:27
<srdjo>
I sure will - is there some startup script that could replace cups config for that user only (workaround) ?
18:29
<alkisg>
Remove that code from X01-localapps:
18:29
if [ -n "${CUPS_SERVER}" ]; then
18:29
echo "ServerName ${CUPS_SERVER}" > /etc/cups/client.conf
18:29
else
18:29
echo "ServerName ${LDM_SERVER}" > /etc/cups/client.conf
18:29
fi
18:29
....and put an rc_file in your lts.conf to call cups_ctl to enable printer sharing on boot
18:30
!ltsp-bug
18:30
<ltsp>
alkisg: ltsp-bug: To file a bug report for upstream LTSP, go to https://bugs.launchpad.net/ltsp
18:33Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Quit: "Achievement is not the end, its the beginning of new journey !!!")
18:40vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net)
18:46Da-Geek has left IRC (Da-Geek!~Da-Geek@50.56.228.48, Quit: Leaving)
18:51srdjo has left IRC (srdjo!~srdjo@109.228.93.179, Ping timeout: 248 seconds)
18:59risca has joined IRC (risca!~risca@wi-secure-433.cc.umanitoba.ca)
19:22SmallR2002 has joined IRC (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net)
19:24
<alkisg>
Is cron used for anything else than SHUTDOWN_TIME? In other words, if SHUTDOWN_TIME and CRONTAB* are not set, can we remove the service?
19:28
<vagrantc>
ali[2~[2~
19:28
gr.
19:29
alkisg: it's not used by anything else specific to LTSP, but someone might reasonably expect to drop something into cron.d or something and expect it to work "normally"
19:30
that's the nervousness i have with a lot of the silently disabling services that appear to be there...
19:31
<alkisg>
Indeed, but the reasoning for disabling the services is that most of them don't make sense to have in readonly/live systems...
19:31
<vagrantc>
sure, i see both sides there
19:31
<alkisg>
And at least in Ubuntu many more were already disabled in previous versions, now there are _less_ disabled services
19:31
<vagrantc>
yay
19:31
:)
19:31Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
19:32
<vagrantc>
i wonder how to make it more transparent exactly what's getting disabled?
19:32
<alkisg>
Instead of rm'ing stuff, move it to some special place?
19:34
<vagrantc>
alkisg: or simply producing a list of disabled services in /etc/ltsp/disabled on the running system, maybe with comments about how to re-enable them
19:35
<alkisg>
In /etc? Or in /var/log/ltsp-something?
19:36
<vagrantc>
somewhere
19:36
and/or in syslog?
19:36
that way if remote logging was enabled, they could look.
19:37
on the server...
19:37* alkisg starts restructuring screen_session to save the openvt memory...
19:44
<alkisg>
Urmgh... init-ltsp.d/Ubuntu/60-screen-sessions???
19:45
<vagrantc>
whee!
19:46
!seen gadi
19:46
<ltsp>
vagrantc: gadi was last seen in #ltsp 9 weeks, 0 days, 4 hours, 7 minutes, and 5 seconds ago: <Gadi> :)
19:46
<vagrantc>
:(
19:46
<alkisg>
Haha Gadi you left chaos behind you :D
19:46* alkisg wonders what's actually used in Ubuntu, ltsp-client-core or the generated services...
19:46
<vagrantc>
iff nothing else, it's forced us to sort out the chaos
19:48Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving)
19:48
<alkisg>
I don't have any /etc/init/screen* scripts there, so I'm guessing we're still using ltsp-client-core
19:48
Maybe because it's echo <<EOF instead of cat <<EOF...
19:48
<vagrantc>
probably
19:49
<alkisg>
OK, let's decide on a tactic here
19:50* alkisg prefers sysv scripts than upstart scripts, for less debian delta
19:50
<alkisg>
But I can see the benefits of using the "native" Ubuntu upstart system, automatic respawn etc etc
19:51* vagrantc is whisked away to all-day meetings
19:52srdjo has joined IRC (srdjo!~srdjo@78.155.58.190)
20:00* stgraber just synced ltspfs 1.1 to Ubuntu, for some reason we were still on 1.0
20:03
<stgraber>
vagrantc: hmm, what did you do to your .orig.tar.gz in Debian?
20:03
vagrantc: 5.3.4 contains a debian/ directory and a .bzr in debian/ :)
20:03
<vagrantc>
stgraber: mkdst fail.
20:03
<stgraber>
I guess I won't be using that as my clean upstream source for my 5.3.4 upload and will just use mkdst to get me clean one ;)
20:04
<vagrantc>
i used mkdst ... but apparently something went wrong
20:04
oddly enough, lintian didn't catch that?
20:05
<stgraber>
yeah it's a bit surprising :)
20:06
<vagrantc>
if you use source/format 3.0 (quilt)
20:06
the debian dir problem should be a non-issue.
20:06
<stgraber>
I use 3.0 (quilt) but with a source bzr branch where I merge the upstream tarballs, suddenly having debian/ in the tarball makes it explode :)
20:07
otherwise I probably wouldn't have noticed either...
20:07
<vagrantc>
shouldn't make it explode...
20:07
huh.
20:07Parker955_Away is now known as Parker955
20:08
<stgraber>
I'm using bzr-builddeb and did a "bzr merge-upstream --version 5.3.4 ltsp_5.3.4.orig.tar.gz" and it complained about the changelog becoming a mess, a bunch of conflicts and so on :)
20:08
<vagrantc>
ah well.
20:09
i should've used my script instead of mkdst. meh.
20:09
and i should fix mkdst.
20:11komunista has left IRC (komunista!~slavko@adsl-195-168-242-217.dynamic.nextra.sk, Quit: Leaving.)
20:13
<stgraber>
alkisg: so we were saying we should have ltsp-client-core installed for the "defaults" runlevels?
20:14
alkisg: (preparing the 5.3.4 upload for Ubuntu)
20:14
<alkisg>
stgraber: default start = S 2 3 4 5, default stop = 0 6?
20:17komunista has joined IRC (komunista!~slavko@adsl-195-168-242-217.dynamic.nextra.sk)
20:18
<vagrantc>
S ?
20:18
<alkisg>
What's the single mode called? 1 ?
20:20
<muppis>
Yes.
20:22khildin has left IRC (khildin!~khildin@ip-80-236-227-45.dsl.scarlet.be, Quit: I'm gone, bye bye)
20:22
<stgraber>
alkisg: do we actually want ltsp-client-core to start in single mode? (if that ever happens)
20:23
<vagrantc>
that's the question
20:23
on debian, the answer is no. single user-mode is... without networking, for example...
20:23
<alkisg>
Networking is enabled in the initramfs though
20:23
<muppis>
Can client be booted in single mode anyway?
20:23
<stgraber>
alkisg: single calls /etc/init.d/networking stop
20:24
<alkisg>
Which won't do anything for manually managed interfaces
20:24
<stgraber>
alkisg: except that this doesn't do anything in Ubuntu for a few releases now ;)
20:24
<vagrantc>
maybe...
20:24
<alkisg>
muppis: I tried it, yes, it can
20:26
<stgraber>
»···dh_installinit -a --no-start -u"start 25 2 3 4 5 . 01 0 6"
20:26
alkisg: ^
20:26
so starting with the same priority as it currently has in runlevel 2,3,4 and 5
20:26
<alkisg>
What is that -a?
20:26
I don't think I saw it in the manpage...
20:26
<stgraber>
and stopping as early as possible in runlevel 0 and 6
20:27
-a simply means install any init script you find
20:27
<alkisg>
Ah ok
20:27
Aren't the defaults 20?
20:27
Why 25?
20:27
<stgraber>
no idea, that's the value it had until now ;)
20:27
<vagrantc>
historically, there was a thing it needed to run after or before.
20:27
<stgraber>
if there's a good reason to move it earlier, I don't mind doing that
20:27
<alkisg>
Reason == speed only
20:28
<stgraber>
yeah, but I'd prefer to have someone test it at 20 and make sure it won't miss a dependency or something because of that
20:28
<vagrantc>
those numbers are, as far as i know, almost pointless now.
20:28
<stgraber>
if we cared about speed we'd make it an upstart job anyway
20:28
vagrantc: not in Ubuntu, we don't use insserv :)
20:28
<vagrantc>
they're ignored on debian (which uses lsb headers)... are they used by upstart?
20:28
<alkisg>
stgraber: I've been running it at 20 for a month now
20:29
<stgraber>
vagrantc: so we either use upstart to have the dependency stuff or we use the old sysvinit going through the sequence
20:29
alkisg: ok, moving to 20 then
20:29
<alkisg>
I think "defaults" will do?
20:29
<stgraber>
no, defaults will make ltsp-client-core stop later than 01
20:30
and will make it stop when switching to runlevel 1 too
20:30
(though we have a hack to prevent that, granted)
20:30
<vagrantc>
manually managing numeric ordering on runlevels is insane.
20:30
<stgraber>
vagrantc: yes, that's why we're treating shipping main packages without upstart job as insanity ;)
20:31
actually I guess I'll just write the upstart job, it's not like ltsp-client-core is complicated now ;)
20:32bengoa has left IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9, Quit: Leaving.)
20:33
<alkisg>
stgraber: take a look at init-ltsp.d/Ubuntu/60-screen-sessions
20:33
That currently doesn't work due to a bug, but if it's fixed, then I don't think we need ltsp-client-core anymore at all
20:33srdjo has left IRC (srdjo!~srdjo@78.155.58.190, Quit: Leaving)
20:34
<alkisg>
But I still think I prefer less delta with debian against some msec faster booting
20:36
Btw, I was about to rewrite screen-session so that it doesn't need openvt hanging around and wasting RAM... I'd probably postpone it until the upstart vs sysvinit thing is decided :)
20:39
<stgraber>
alkisg: http://paste.ubuntu.com/872039/
20:40
alkisg: do you know what's happening with 60-screen-sessions?
20:40
<alkisg>
I guess so... but I'd hate to have to maintain the code in 2 different places
20:40
<stgraber>
alkisg: is it simply not starting or failing for some reason?
20:40
<alkisg>
stgraber: with a first glance, it has an echo instead of a cat
20:41
But even so, it should generate empty files, and it doesn't
20:41
So not sure what other problem it has
20:41
But I'm still reluctant about the upstart jobs, as they'll mean we'll have to maintain the code in 2 places
20:42
<stgraber>
well, that's why we have distro maintainers for ;)
20:42
currently ltsp-client-core doesn't work as it should on Ubuntu because we don't use insserv so all the dependencies are ignored
20:42
to have the same feature, we need to use upstart
20:43
init scripts are pretty much never portable across distros, though they usually "work" between Debian and Ubuntu
20:43
<alkisg>
What dependencies? remote_fs? We have the from the initramfs
20:45
<stgraber>
well, on Debian as soon as these dependencies are met, the script will start which as you point out is really early as they're met by the initramfs
20:45
in Ubuntu, old sysvinit scripts are called at the very end of the boot as a fallback
20:45
<alkisg>
OK, anyway, as you said, ltsp-client-core is small now. But is there a need for 60-screen-sessions?
20:45
Can't we call all of them from ltsp-client-core?
20:46
It's not like they'll use different "start on" conditions...
20:47
The change I'm thinking is, call openvt -s (switch) for the SCREEN_DEFAULT, and plain openvt for all the other ones,
20:47
<stgraber>
I think Gadi's approach is right and we should indeed use it an get rid of ltsp-client-core at lesat in Ubuntu
20:47
but it'll need some more changes to work properly
20:47
<alkisg>
and then let the screen-session script check for fgconsole == screen_num etc
20:47
<stgraber>
for example with ltsp-cluster, SCREEN_XX can change at any time
20:47pimpministerp has joined IRC (pimpministerp!~ppouliot@static-71-174-244-28.bstnma.fios.verizon.net)
20:48
<stgraber>
so you need these jobs to run getltscfg every time they die in that case to check if they should do something or just wait
20:48
<alkisg>
stgraber: we talked with Gadi about that, but I don't see the reason nor the way to properly implement changing SCREEN_XXs
20:48
Can you give me a real use case?
20:49
<stgraber>
sure, at Revolution Linux, customers were often switching the role of thin clients between ldm and rdesktop or to some fallback session when the application servers were dead for some reason
20:49
in such case, they expect that the next time whatever screen.d script is running dies, the new one is spawned
20:49primeministerp has left IRC (primeministerp!~ppouliot@static-71-174-244-28.bstnma.fios.verizon.net, Ping timeout: 245 seconds)
20:50Parker955 is now known as Parker955_Away
20:50
<alkisg>
So you have e.g. SCREEN_07=ldm, and the linux server dies, and the control center decides that SCREEN_07 should now be rdesktop, to point to the windows server?
20:50
I think that's too complicated, I would prefer a SCREEN_07=get_any_active_server script instead
20:51
For me, SCREEN_XX means a certain script running forever at a certain tty
20:51
That script can be a wrapper for multiple others, sure
20:51
But I think that changing SCREEN_XX is too complicated to explain or even to properly implement it
20:53
<stgraber>
well, we've had it in LTSP for a while, dropping it now would be a regression...
20:53
it's currently done at the beginning of main() in screen-session
20:53
every time we go through main() we source the config again and then only call the SCREEN_XX script
20:54pimpministerp is now known as primeministerp
20:55
<alkisg>
For the openvt part, even if openvt is called before screen_session, what you're saying can still be done
20:55
So sysvinit, upstart, openvt all those don't matter for this specific use case
20:56
<stgraber>
the only problem in there are the "return" calls in main()... ideally it shouldn't be possible to leave main() and we should just wait a few seconds instead (this can be configurable though to avoid having a lot of sleeps running)
20:57
how are you planning on getting rid of openvt and avoid race conditions?
20:57
<alkisg>
From somewhere, either sysvinit or upstart, start_screen_sessions is called
20:57
It decides SCREEN_DEFAULT first, and calls openvt -s for that one
20:58
-s ==> switch to that vt
20:58
It doesn't use -w, no waiting needed
20:58
Then, for all the other screens, it calls openvt without -s (and without -w)
20:58
And it finishes
20:58
So we have screen-sessions running, and one of them is in the active vt
20:59
The others are waiting with the classic fgconsole delay
20:59
When one switches to them, they call getltscfg(-cluster), evaluate SCREEN_xx, and execute that command
20:59
Then the go back to the fgconsole waiting, and they keep doing that forever
21:00
In case of errors, they display a message and wait for enter
21:00
I think the race conditions were there because all openvt calls were using -s
21:00
<stgraber>
sounds reasonable, I seem to remember having some issues because of plymouth/X/whatever else also doing some VT switch messing with everything, but hopefully that's fixed now ;)
21:01
<alkisg>
OK, so, plan: I delete 60-screen-sessions and implement everything from inside start_screen_sessions,
21:01
and if you want write the upstart equivalent of ltsp-client-core
21:02
(which you've done already :))
21:02
<stgraber>
I already did, package is building
21:02
(in a PPA for now, I want to test a boot with that before pushing it to the archive ;))
21:03
<alkisg>
Cool... it's late here though, so I'll do my part tomorrow
21:04
(16default-tty and 15default-screen need some cleaning too, it's going to take a while to do all of it properly + test it)
21:05
And also openvt/chvt should be completely removed from screen scripts, e.g. from ssh:
21:05
# chvt to the right screen
21:05
[ -n "${SCREEN_NUM}" ] && openvt chvt ${SCREEN_NUM}
21:06
<stgraber>
indeed, screen.d should mess with vt switching
21:11
<vagrantc>
is there any way the upstart jobs and init scripts can share functions?
21:12
to reduce the code duplication
21:12
<muppis>
To do same job?
21:13
<alkisg>
vagrantc: insserv/upstart will call start_screen_sessions, from there on the code is shared
21:14* vagrantc hasn't fully read the backscroll
21:15
<vagrantc>
the debian/ubuntu diff with ltsp is fairly large, and i think there are other places that would be more fruitful to reduce the diff, if it means using a sub-optimal init system.
21:16
meh. mkdst-trunk is in an old version.
21:16
<stgraber>
vagrantc: the upstart job is already down to pretty much nothing as it sources init-functions and calls 3 functions :)
21:16
<vagrantc>
er, in an old bzr format.
21:17
stgraber: that's what i was figuring.
21:17
<stgraber>
we could probably move some of the locale stuff to ltsp-init-common and the ltsp-cluster bit too
21:17
if we really want to cut down to nothing we could have a start_ltsp meta-function in ltsp-init-common
21:17
than all upstart/sysvinit/systemd/whatever jobs would simply call
21:18
*that
21:19Parker955_Away is now known as Parker955
21:31Parker955 is now known as Parker955_Away
21:37Da-Geek has joined IRC (Da-Geek!~Da-Geek@50.56.228.48)
21:39
<alkisg>
'night all
21:39alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
21:43Da-Geek has left IRC (Da-Geek!~Da-Geek@50.56.228.48, Quit: Leaving)
21:52Parker955_Away is now known as Parker955
21:59artista-frustrad has left IRC (artista-frustrad!~fernando@200.247.43.2, Quit: Leaving)
22:16Parker955 is now known as Parker955_Away
22:17bergerx has left IRC (bergerx!~bergerx@46.196.249.86, Quit: Leaving)
22:20leio has left IRC (leio!~leio@gentoo/developer/leio, Read error: Operation timed out)
22:26bergerx has joined IRC (bergerx!~bergerx@46.196.249.86)
22:26bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Quit: Goin' down hard)
22:26leio has joined IRC (leio!~leio@gentoo/developer/leio)
22:47brunolambert has left IRC (brunolambert!bruno@nat/revolutionlinux/x-ktldenookkphejwi, Remote host closed the connection)
23:03dead_inside has left IRC (dead_inside!~dead_insi@76.75.3.174, Quit: Leaving...)
23:14komunista has left IRC (komunista!~slavko@adsl-195-168-242-217.dynamic.nextra.sk, Quit: Leaving.)
23:17jvin has joined IRC (jvin!~jvin@108-82-19-151.lightspeed.livnmi.sbcglobal.net)