IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 6 March 2012 (all times are UTC)
| 00:07 | primeministerp has left IRC (primeministerp!~ppouliot@static-71-174-244-28.bstnma.fios.verizon.net, Remote host closed the connection) | |
| 00:14 | andyGraybeals 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:22 | Parker955_Away is now known as Parker955 | |
| 01:37 | risca has left IRC (risca!~risca@wi-secure-5637.cc.umanitoba.ca, Quit: Lämnar) | |
| 01:57 | Parker955 is now known as Parker955_Away | |
| 01:59 | DIoX|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:11 | DIoX|DaZ has joined IRC (DIoX|DaZ!~KaKa@server.civicclub.lt) | |
| 02:24 | Parker955_Away is now known as Parker955 | |
| 02:25 | <vagrantc> ah, the dir ltsp-client-setup isn't really even used anymore.
| |
| 02:47 | adrianorg__ has left IRC (adrianorg__!~adrianorg@186.215.16.184, Ping timeout: 245 seconds) | |
| 02:51 | risca has joined IRC (risca!~risca@out-on-143.wireless.telus.com) | |
| 03:08 | risca 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:18 | Parker955 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:31 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 05:33 | <shogunx> yep... should be cheap if you can find them tho.
| |
| 05:48 | monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 255 seconds) | |
| 05:58 | alkisg 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:00 | monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net) | |
| 06:01 | alkisg 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:58 | loather-work has joined IRC (loather-work!~khudson@wsip-98-175-250-115.sd.sd.cox.net) | |
| 07:01 | killermike 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:13 | joat 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:38 | alexqwesa has left IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net, Quit: Хана X'ам !!!) | |
| 07:44 | alexqwesa 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:50 | vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Quit: leaving) | |
| 07:58 | khildin has joined IRC (khildin!~khildin@ip-80-236-227-45.dsl.scarlet.be) | |
| 08:17 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 08:18 | loather has left IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net, Quit: This computer has gone to sleep) | |
| 08:25 | khildin has left IRC (khildin!~khildin@ip-80-236-227-45.dsl.scarlet.be, Ping timeout: 276 seconds) | |
| 08:36 | dobber has joined IRC (dobber!~dobber@213.169.45.222) | |
| 08:54 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
| 09:13 | rickogden has joined IRC (rickogden!~rickogden@146.87.65.30) | |
| 09:17 | Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com) | |
| 09:19 | Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com) | |
| 09:20 | xsl has joined IRC (xsl!~silence@unaffiliated/xsl) | |
| 09:25 | ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood) | |
| 09:27 | ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de) | |
| 09:58 | loather has joined IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net) | |
| 10:01 | loather-work has left IRC (loather-work!~khudson@wsip-98-175-250-115.sd.sd.cox.net, Quit: This computer has gone to sleep) | |
| 10:03 | bmonkj has joined IRC (bmonkj!~skumlesen@46.32.130.15) | |
| 10:04 | bauerski has joined IRC (bauerski!~witekb@frodo.psp.opole.pl) | |
| 10:07 | khildin has joined IRC (khildin!~khildin@ip-80-236-227-45.dsl.scarlet.be) | |
| 10:27 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 10:28 | Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71) | |
| 10:42 | alexqwesa has left IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net, Quit: Хана X'ам !!!) | |
| 10:47 | Mava has left IRC (Mava!~Mava@ip-45-224.dhcp.opintanner.fi, Read error: Operation timed out) | |
| 10:47 | Mava has joined IRC (Mava!~Mava@ip-45-224.dhcp.opintanner.fi) | |
| 10:53 | adrianorg__ has joined IRC (adrianorg__!~adrianorg@186.215.16.184) | |
| 10:57 | wim_ has joined IRC (wim_!~chatzilla@WEGC203035.KFUNIGRAZ.AC.AT) | |
| 10:58 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 11:02 | andyGraybeals has joined IRC (andyGraybeals!~andy@h215.212.22.98.dynamic.ip.windstream.net) | |
| 12:09 | ltsp has joined IRC (ltsp!ltspbot@middelkoop.cc) | |
| 12:10 | <Hyperbyte> Hm
| |
| 12:11 | ltsp` 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:14 | alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net) | |
| 12:20 | monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, *.net *.split) | |
| 12:20 | TatankaT has left IRC (TatankaT!~tim@peno.cwlab.kotnet.org, *.net *.split) | |
| 12:20 | leio has left IRC (leio!~leio@gentoo/developer/leio, *.net *.split) | |
| 12:20 | shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com, *.net *.split) | |
| 12:21 | xsl has left IRC (xsl!~silence@unaffiliated/xsl, Quit: Connection reset by fear) | |
| 12:23 | monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net) | |
| 12:23 | TatankaT has joined IRC (TatankaT!~tim@peno.cwlab.kotnet.org) | |
| 12:23 | leio has joined IRC (leio!~leio@gentoo/developer/leio) | |
| 12:23 | shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com) | |
| 12:27 | artista-frustrad has joined IRC (artista-frustrad!~fernando@200.247.43.2) | |
| 12:27 | wim_ has left IRC (wim_!~chatzilla@WEGC203035.KFUNIGRAZ.AC.AT, Quit: ChatZilla 0.9.88 [Iceweasel 10.0.2/20120217174734]) | |
| 12:45 | * [GuS] Morning | |
| 12:50 | Parker955_Away is now known as Parker955 | |
| 12:57 | Parker955 is now known as Parker955_Away | |
| 12:57 | rickogden has left IRC (rickogden!~rickogden@146.87.65.30, Quit: Leaving.) | |
| 13:06 | brunolambert has joined IRC (brunolambert!bruno@nat/revolutionlinux/x-ktldenookkphejwi) | |
| 13:22 | primeministerp has joined IRC (primeministerp!~ppouliot@static-71-174-244-28.bstnma.fios.verizon.net) | |
| 13:53 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 14:08 | <Hyperbyte> Morning GuS :-)
| |
| 14:13 | dead_inside has joined IRC (dead_inside!~dead_insi@76.75.3.174) | |
| 14:20 | khildin has left IRC (khildin!~khildin@ip-80-236-227-45.dsl.scarlet.be, Ping timeout: 276 seconds) | |
| 15:03 | Da-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:22 | toscalix has joined IRC (toscalix!~toscalix@195.235.115.44) | |
| 15:28 | khildin 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:42 | rickogden 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:31 | bengoa has joined IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9) | |
| 16:33 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 16:39 | toscalix has left IRC (toscalix!~toscalix@195.235.115.44, Read error: Connection reset by peer) | |
| 16:40 | dobber has left IRC (dobber!~dobber@213.169.45.222, Remote host closed the connection) | |
| 16:41 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 16:42 | rickogden has left IRC (rickogden!~rickogden@146.87.86.156, Quit: Leaving.) | |
| 16:56 | komunista has joined IRC (komunista!~slavko@adsl-195-168-242-217.dynamic.nextra.sk) | |
| 17:00 | komunista has left IRC (komunista!~slavko@adsl-195-168-242-217.dynamic.nextra.sk, Client Quit) | |
| 17:04 | dptech 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:27 | srdjo 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:42 | ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 246 seconds) | |
| 17:43 | ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de) | |
| 17:48 | monteslu 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:00 | monteslu 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:09 | dptech 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:15 | yanu has left IRC (yanu!~yanu@lugwv/member/yanu, Read error: Connection reset by peer) | |
| 18:15 | yanu has joined IRC (yanu!~yanu@lugwv/member/yanu) | |
| 18:23 | Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com, Quit: Leaving) | |
| 18:24 | komunista 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:33 | Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Quit: "Achievement is not the end, its the beginning of new journey !!!") | |
| 18:40 | vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) | |
| 18:46 | Da-Geek has left IRC (Da-Geek!~Da-Geek@50.56.228.48, Quit: Leaving) | |
| 18:51 | srdjo has left IRC (srdjo!~srdjo@109.228.93.179, Ping timeout: 248 seconds) | |
| 18:59 | risca has joined IRC (risca!~risca@wi-secure-433.cc.umanitoba.ca) | |
| 19:22 | SmallR2002 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:31 | Steve_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:48 | Steve_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:52 | srdjo 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:07 | Parker955_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:11 | komunista 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:17 | komunista 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:22 | khildin 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:32 | bengoa 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:33 | srdjo 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:47 | pimpministerp 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:49 | primeministerp has left IRC (primeministerp!~ppouliot@static-71-174-244-28.bstnma.fios.verizon.net, Ping timeout: 245 seconds) | |
| 20:50 | Parker955 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:54 | pimpministerp 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:19 | Parker955_Away is now known as Parker955 | |
| 21:31 | Parker955 is now known as Parker955_Away | |
| 21:37 | Da-Geek has joined IRC (Da-Geek!~Da-Geek@50.56.228.48) | |
| 21:39 | <alkisg> 'night all
| |
| 21:39 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 21:43 | Da-Geek has left IRC (Da-Geek!~Da-Geek@50.56.228.48, Quit: Leaving) | |
| 21:52 | Parker955_Away is now known as Parker955 | |
| 21:59 | artista-frustrad has left IRC (artista-frustrad!~fernando@200.247.43.2, Quit: Leaving) | |
| 22:16 | Parker955 is now known as Parker955_Away | |
| 22:17 | bergerx has left IRC (bergerx!~bergerx@46.196.249.86, Quit: Leaving) | |
| 22:20 | leio has left IRC (leio!~leio@gentoo/developer/leio, Read error: Operation timed out) | |
| 22:26 | bergerx has joined IRC (bergerx!~bergerx@46.196.249.86) | |
| 22:26 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Quit: Goin' down hard) | |
| 22:26 | leio has joined IRC (leio!~leio@gentoo/developer/leio) | |
| 22:47 | brunolambert has left IRC (brunolambert!bruno@nat/revolutionlinux/x-ktldenookkphejwi, Remote host closed the connection) | |
| 23:03 | dead_inside has left IRC (dead_inside!~dead_insi@76.75.3.174, Quit: Leaving...) | |
| 23:14 | komunista has left IRC (komunista!~slavko@adsl-195-168-242-217.dynamic.nextra.sk, Quit: Leaving.) | |
| 23:17 | jvin has joined IRC (jvin!~jvin@108-82-19-151.lightspeed.livnmi.sbcglobal.net) | |