IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 9 November 2011 (all times are UTC)
| 00:14 | MrDoh has left IRC (MrDoh!~mrdoh@r74-192-178-144.htvlcmta01.hnvitx.tl.dh.suddenlink.net, Ping timeout: 248 seconds) | |
| 00:28 | Parker955_Away is now known as Parker955 | |
| 00:56 | MrDoh has joined IRC (MrDoh!~mrdoh@r74-192-178-144.htvlcmta01.hnvitx.tl.dh.suddenlink.net) | |
| 01:00 | MrDoh has joined IRC (MrDoh!~mrdoh@r74-192-178-144.htvlcmta01.hnvitx.tl.dh.suddenlink.net) | |
| 01:12 | cliebow has joined IRC (cliebow!~cliebow@66.63.66.218) | |
| 01:53 | 16WAATSL4 <16WAATSL4!~fernando@189.30.138.160> has quit IRC (Quit: Leaving) | |
| 01:53 | Damianos has joined IRC (Damianos!~Damianos@70.145.74.43) | |
| 02:11 | abeehc has left IRC (abeehc!~bob@2001:1938:1a3:0:216:41ff:fe2c:9b3c, Read error: Operation timed out) | |
| 02:16 | abeehc has joined IRC (abeehc!~bob@50.92.192.146) | |
| 02:18 | artista_frustrad has joined IRC (artista_frustrad!~artista_f@189.30.138.160) | |
| 02:34 | GodFather has joined IRC (GodFather!~rcc@d47-69-227-53.col.wideopenwest.com) | |
| 02:34 | rccGodFather_ has joined IRC (rccGodFather_!~rcc@d47-69-227-53.col.wideopenwest.com) | |
| 02:35 | GodFather has left IRC (GodFather!~rcc@d47-69-227-53.col.wideopenwest.com, Remote host closed the connection) | |
| 02:35 | GodFather has joined IRC (GodFather!~rcc@d47-69-227-53.col.wideopenwest.com) | |
| 02:52 | Damianos has left IRC (Damianos!~Damianos@70.145.74.43, Quit: Damianos) | |
| 03:12 | petre has joined IRC (petre!~petre@scheie.homedns.org) | |
| 03:13 | <petre> evening all
| |
| 03:15 | I'm running on ubuntu 10.4. Whenever the NIC for the TCs comes up, the system adds it as a default route to the routing table.
| |
| 03:15 | But there's nothing in /etc/network/interfaces telling it to do so.
| |
| 03:16 | And, of course, this additional route (the public-facing NIC should be the default gw) means clients can't get to the internet.
| |
| 03:16 | Any ideas where this extra default route is coming from?
| |
| 03:21 | Damianos has joined IRC (Damianos!~Damianos@adsl-070-145-074-043.sip.cha.bellsouth.net) | |
| 03:34 | Damianos has left IRC (Damianos!~Damianos@adsl-070-145-074-043.sip.cha.bellsouth.net, Quit: Damianos) | |
| 03:40 | Parker955 is now known as Parker955_Away | |
| 03:43 | cliebow has left IRC (cliebow!~cliebow@66.63.66.218, Quit: Leaving) | |
| 03:45 | monkeydiver has joined IRC (monkeydiver!~de3legged@24.152.225.163.res-cmts.mtp2.ptd.net) | |
| 04:00 | GodFather has left IRC (GodFather!~rcc@d47-69-227-53.col.wideopenwest.com, Quit: Ex-Chat) | |
| 04:15 | petre has left IRC (petre!~petre@scheie.homedns.org, Quit: Leaving) | |
| 04:29 | fellowEntx has left IRC (fellowEntx!~fellowEnt@69.25.2.66, Read error: Connection reset by peer) | |
| 04:29 | fellowEntx has joined IRC (fellowEntx!~fellowEnt@69.25.2.66) | |
| 04:31 | jvin has joined IRC (jvin!~jvin@108-82-19-151.lightspeed.livnmi.sbcglobal.net) | |
| 04:49 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 05:08 | Matrix3000_ has joined IRC (Matrix3000_!~Matrix300@cpe-184-57-1-218.columbus.res.rr.com) | |
| 05:08 | <Matrix3000_> so, I just tried installing zabbix-agent into the thin client image
| |
| 05:08 | for fat clients
| |
| 05:08 | lol
| |
| 05:08 | not a bad idea i might say to monitor computers
| |
| 05:16 | <alkisg> What does that do?
| |
| 05:17 | <Matrix3000_> gives me a wide array of stats into my zabbix monitoring software
| |
| 05:17 | <alkisg> Like http://munin-monitoring.org/ ?
| |
| 05:17 | <Matrix3000_> including processor use, memory use
| |
| 05:17 | yea kinda like that
| |
| 05:17 | <alkisg> Nice
| |
| 05:17 | <Matrix3000_> http://www.zabbix.com
| |
| 05:17 | going to try it tomorrow
| |
| 05:18 | hopefully it works great
| |
| 05:18 | i make a cron job to kill all user processes at midnight daily
| |
| 05:18 | and i forgot where it would be
| |
| 05:18 | any ideas
| |
| 05:18 | <alkisg> Do tell us of any significant results
| |
| 05:19 | Thin clients or fat?
| |
| 05:19 | <Matrix3000_> figured it out
| |
| 05:19 | sudo crontab -e
| |
| 05:19 | i didn't have it in /etc/cron.daily
| |
| 05:19 | like i should have
| |
| 05:20 | <alkisg> That's for thin clients then
| |
| 05:20 | <Matrix3000_> yea
| |
| 05:20 | i put it there cause people's web browsers aka firefox would go bursurk on system resources
| |
| 05:20 | that was back when most hte computer were thin clients
| |
| 05:20 | <alkisg> I thought you installed zabbix-agent in a fat chroot :)
| |
| 05:20 | Ah
| |
| 05:20 | <Matrix3000_> i did
| |
| 05:20 | i have it on both now
| |
| 05:20 | the ltsp server and the fat chroot
| |
| 05:20 | <alkisg> k
| |
| 05:21 | <Matrix3000_> hopefully this works awesomely
| |
| 05:21 | if so i will put it on the ltsp site because this could help many people diagnose their thin client issues
| |
| 05:21 | such as low memory on a few, or a few thin clients not communicating properly
| |
| 05:21 | <alkisg> You think it will work on thin clients too?
| |
| 05:22 | <Matrix3000_> if you put it in chroot
| |
| 05:22 | and make it run on start as a local app
| |
| 05:22 | i will have to try it in a test env or you can if you already have one
| |
| 05:22 | its simple
| |
| 05:23 | sudo apt-get install zabbix-agent
| |
| 05:23 | <alkisg> Nah, our thin clients are too thin to install extra programs
| |
| 05:24 | <Matrix3000_> http://www.brainhemorage.com/2010/08/05/installing-zabbix-on-ubuntu-10-04-lts/
| |
| 05:24 | ah figures
| |
| 05:24 | <alkisg> With 64mb ram one only installs the necessary services :)
| |
| 05:24 | <Matrix3000_> most people running real thin clients without local apps can't install anything lol
| |
| 05:24 | yep
| |
| 05:26 | ill also try and get it to show me on fat clients who's logged into what pc
| |
| 05:26 | and setting nfs_home in the lts.conf
| |
| 05:26 | big difference
| |
| 05:26 | much better performance
| |
| 05:26 | but i had to make sure that nfs-common was installed in fat chroot
| |
| 05:27 | as well as on the server itself
| |
| 05:27 | so I need to update the wiki with that
| |
| 05:32 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Read error: Operation timed out) | |
| 05:41 | staffencasa has left IRC (staffencasa!~staffenca@128-193-146-230.oregonstate.edu, Ping timeout: 260 seconds) | |
| 06:29 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 06:54 | chokesmaster has joined IRC (chokesmaster!~chokesmas@65.92.140.229) | |
| 06:56 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 06:56 | chokesmaster has left IRC (chokesmaster!~chokesmas@65.92.140.229, Client Quit) | |
| 06:57 | chokesmaster has joined IRC (chokesmaster!~chokesmas@bas5-sherbrooke40-1096584421.dsl.bell.ca) | |
| 07:04 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 07:05 | <alkisg> Ouch that doesn't sound encouraging for gnome-fallback-mode (from http://www.phoronix.com/scan.php?page=news_item&px=MTAxMjI):
| |
| 07:05 | "I expect that once most hardware that previously needed the fallback mode is covered, fallback mode will die. AIUI, fallback mode isn't meant to be a GNOME 2-by-stealth for Shell refuseniks, it's purely an attempt to accommodate hardware which doesn't support Shell."
| |
| 07:10 | Gadi has left IRC (Gadi!~romm@ool-4571ca04.dyn.optonline.net, Read error: Connection reset by peer) | |
| 07:27 | Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.69) | |
| 07:28 | Gadi has joined IRC (Gadi!~romm@ool-4571ca04.dyn.optonline.net) | |
| 08:00 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 08:08 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 240 seconds) | |
| 08:19 | Matrix3000_ has left IRC (Matrix3000_!~Matrix300@cpe-184-57-1-218.columbus.res.rr.com, Quit: ~ Trillian Astra - www.trillian.im ~) | |
| 08:22 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 08:37 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 255 seconds) | |
| 08:42 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 08:49 | loather has left IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net, Quit: This computer has gone to sleep) | |
| 08:51 | <Hyperbyte> alkisg, I think they pushed Gnome3 into production too quickly.
| |
| 08:52 | <alkisg> Yeah... and I'm still not convinced that gnome shell or unity are better, usability-wise, than the old gnome panels etc
| |
| 08:52 | <Hyperbyte> You can't release a new version of a product, with less features than the previous ones... it'll make lots of users unhappy... yet that's exactly what Gnome3 is.
| |
| 09:03 | dobber has joined IRC (dobber!~dobber@89.190.199.210) | |
| 09:04 | toscalix has joined IRC (toscalix!~toscalix@212.170.226.171) | |
| 09:15 | <alkisg> !learn panic-reboot as The panic=<timeout> kernel parameter can be used to automatically reboot hanged clients. See also http://www.kernel.org/doc/Documentation/kernel-parameters.txt
| |
| 09:15 | <ltsp> alkisg: The operation succeeded.
| |
| 09:17 | <Hyperbyte> :)
| |
| 09:32 | Gremble has joined IRC (Gremble!~Ben@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com) | |
| 09:35 | garymc has joined IRC (garymc!~chatzilla@81.138.225.164) | |
| 09:45 | toscalix_ has joined IRC (toscalix_!~toscalix@212.170.226.171) | |
| 09:46 | toscalix has left IRC (toscalix!~toscalix@212.170.226.171, Ping timeout: 258 seconds) | |
| 10:04 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 255 seconds) | |
| 10:25 | vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 240 seconds) | |
| 10:40 | toscalix_ has left IRC (toscalix_!~toscalix@212.170.226.171, Read error: Connection reset by peer) | |
| 10:49 | lifeboy_ has joined IRC (lifeboy_!~roland@41.183.26.154) | |
| 10:54 | vmlintu has joined IRC (vmlintu!~vmlintu@dsl-hkibrasgw2-ff78c300-68.dhcp.inet.fi) | |
| 11:09 | abeehc has left IRC (abeehc!~bob@50.92.192.146, Ping timeout: 255 seconds) | |
| 11:15 | abeehc has joined IRC (abeehc!~bob@50.92.192.146) | |
| 11:16 | Damianos has joined IRC (Damianos!~Damianos@70.145.74.43) | |
| 11:27 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 12:06 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 258 seconds) | |
| 12:32 | Parker955_Away is now known as Parker955 | |
| 12:46 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
| 12:52 | Parker955 is now known as Parker955_Away | |
| 12:57 | pingufan has joined IRC (pingufan!~rainer@goliath.hantsch.co.at) | |
| 12:58 | garymc has left IRC (garymc!~chatzilla@81.138.225.164, Quit: ChatZilla 0.9.87 [Firefox 8.0/20111104165243]) | |
| 12:59 | <pingufan> Hello, what can cause a server to suddenly get a system load of 170 ? This phenomen exists (randomly) since I installed kiwi-ltsp. Before it worked absolutely stable for 2 years.
| |
| 13:01 | Da-Geek has joined IRC (Da-Geek!Da-Geek@nat/redhat/x-ccnosrnokkdtacck) | |
| 13:02 | [GuS] has joined IRC ([GuS]!~MysT@190.245.108.178) | |
| 13:02 | [GuS] has joined IRC ([GuS]!~MysT@unaffiliated/gus/x-663402) | |
| 13:10 | mrcarrot has joined IRC (mrcarrot!~lasse@unaffiliated/mrcarrot) | |
| 13:18 | <mrcarrot> i have a problem with some laptops connected to projectors. at ldm login, the screen gets extended to both the laptop and the projector
| |
| 13:18 | half of the loginwindow is in the laptop, the other half at the projector
| |
| 13:18 | fn-f7 is not working until i have been logging in
| |
| 13:18 | is there anyway i can tweak this behavior?
| |
| 13:22 | <pingufan> How can I do a "local-reboot" of a client initialized from the server?
| |
| 13:22 | <mrcarrot> pingufan: i am usually installing openssh-server on the clients. then it is just to ssh and run the reboot command
| |
| 13:24 | <pingufan> Is this part different between ltsp and kiwi-ltsp ?
| |
| 13:26 | I am very new to this ltsp and have my troubles with it.
| |
| 13:27 | dobber has left IRC (dobber!~dobber@89.190.199.210, Read error: Operation timed out) | |
| 13:29 | <alkisg> mrcarrot: login, open a terminal, and run xrandr
| |
| 13:29 | Then try to disable the projector with xrandr
| |
| 13:30 | E.g. xrandr --output DVI-1 --off or something
| |
| 13:30 | Once you have that, you can put it in lts.conf
| |
| 13:30 | <mrcarrot> alkisg: how do i do to put a command in lts.conf?
| |
| 13:30 | <alkisg> !lts.conf | echo mrcarrot:
| |
| 13:30 | <ltsp> mrcarrot: lts.conf: http://manpages.ubuntu.com/lts.conf
| |
| 13:31 | <alkisg> See the xrandr vars there
| |
| 13:31 | You don't need a command
| |
| 13:31 | <pingufan> alkisg: Can I start a local application on a client by adding an entry to lts.conf ? I actually do not want to allow the users local apps on the clients.
| |
| 13:32 | <alkisg> pingufan: yes, see the lts.conf manpage
| |
| 13:32 | RCFILE
| |
| 13:32 | <mrcarrot> ahm thanks
| |
| 13:33 | <pingufan> Where has a script/program to be stored on the server to be available for the client afterwards ?
| |
| 13:34 | <alkisg> In the chroot, e.g. /opt/ltsp/i386/somewhere, or wherever else kiwi puts its chroot
| |
| 13:36 | <pingufan> I have a /opt/ltsp/. It is a symlink to /srv/kiwi-ltsp. But there I see only one file: i386.img.
| |
| 13:36 | This location?
| |
| 13:36 | <alkisg> No, that's the compressed form
| |
| 13:36 | The uncompressed chroot should be around somewhere, ask in #kiwi-ltsp
| |
| 13:38 | dobber has joined IRC (dobber!~dobber@89.190.199.210) | |
| 13:38 | <pingufan> Ah - ok. peek inti #kiwi-ltsp and count active users. ;)
| |
| 13:39 | mrcarrot has left IRC (mrcarrot!~lasse@unaffiliated/mrcarrot) | |
| 13:39 | <alkisg> That's your choice :)
| |
| 13:39 | I select my distro based on the support I can get, too
| |
| 13:41 | <pingufan> I am close to throw away this stupid ltsp and use something different. nxserver i.e.
| |
| 13:41 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 13:42 | <alkisg> nxserver doesn't support netbooted clients afaik
| |
| 13:43 | <pingufan> or ncomputing's L300
| |
| 13:43 | <alkisg> It works much better than ltsp over slow links, and much worse over local lan
| |
| 13:43 | I've seen several people here that switched to ltsp after being too disappointed by ncomputing
| |
| 13:44 | <pingufan> But I never had a crash with 30 users on one server (and such a system I administrate), while I permanently have troubles with ltsp
| |
| 13:44 | <alkisg> I don't have problems with ltsp
| |
| 13:44 | <pingufan> Ok, I would still prefer the free ltsp.
| |
| 13:46 | But I don't like to fiddle around in such depths without a really usable guide.
| |
| 13:46 | <alkisg> LTSP has good guides. I don't know about kiwi-ltsp.
| |
| 13:46 | And e.g. the Ubuntu ltsp installation is just an "f4 - install an ltsp server" on the installation cd
| |
| 13:47 | <pingufan> Well, a native install is also not more that two lines. First install the packages repos, then the prebuilt system. But finetuning is badly documented.
| |
| 13:50 | Always the same: Wiki here, wiki there -- and then try to find the answer(s).
| |
| 13:50 | <alkisg> What would you prefer, if not wikies?
| |
| 13:51 | <pingufan> A clean and well structured PDF.
| |
| 13:51 | <alkisg> It's there, see the /topic
| |
| 13:51 | dead_inside has joined IRC (dead_inside!~dead_insi@76.75.3.174) | |
| 13:51 | <pingufan> One document, always on latest revision. No searching game.
| |
| 13:51 | <alkisg> Yes, it's a single pdf
| |
| 13:52 | <pingufan> Is the nbdrootd the directory I need ?
| |
| 13:53 | <alkisg> No idea, in upstream we call nbdrootd the daemon, not the chroot
| |
| 13:54 | <pingufan> The nbd directory used by it.
| |
| 13:56 | anyway, I give up. I will try to figure out how this kiwi works. Wish me luck...
| |
| 13:57 | <alkisg> Good luck :)
| |
| 13:58 | <pingufan> Thanks.
| |
| 13:59 | pingufan has left IRC (pingufan!~rainer@goliath.hantsch.co.at, Remote host closed the connection) | |
| 14:26 | vmlintu has left IRC (vmlintu!~vmlintu@dsl-hkibrasgw2-ff78c300-68.dhcp.inet.fi, Ping timeout: 260 seconds) | |
| 14:46 | muppis has left IRC (muppis!muppis@viuhka.fi, Ping timeout: 245 seconds) | |
| 14:48 | muppis has joined IRC (muppis!muppis@viuhka.fi) | |
| 14:51 | Da-Geek has left IRC (Da-Geek!Da-Geek@nat/redhat/x-ccnosrnokkdtacck, Quit: Leaving) | |
| 14:58 | andygraybeal_ has joined IRC (andygraybeal_!~andy.gray@obsidian.casanueva.com) | |
| 14:58 | <andygraybeal_> :)
| |
| 15:03 | jtsop has joined IRC (jtsop!~quassel@athedsl-07209.home.otenet.gr) | |
| 15:05 | <Hyperbyte> Andy!
| |
| 15:16 | Matrix3000 has joined IRC (Matrix3000!~Matrix300@rrcs-70-61-255-227.central.biz.rr.com) | |
| 15:16 | <Matrix3000> !!!! alkisg !!!!!
| |
| 15:16 | <ltsp> Matrix3000: Error: "!!!" is not a valid command.
| |
| 15:16 | <Matrix3000> it's amazing
| |
| 15:16 | <alkisg> ?
| |
| 15:16 | <Matrix3000> i am not monitoring all fat clients
| |
| 15:16 | artista_frustrad has left IRC (artista_frustrad!~artista_f@189.30.138.160, Ping timeout: 258 seconds) | |
| 15:16 | <Matrix3000> i am ***
| |
| 15:16 | now monitoring
| |
| 15:16 | <alkisg> With the z* thing you were saying yesterday?
| |
| 15:16 | <Matrix3000> yea
| |
| 15:16 | zabbix
| |
| 15:17 | <alkisg> Cool, and any remarks?
| |
| 15:17 | <Matrix3000> other than im able to monitor ram and processor usage on fat clients
| |
| 15:17 | <alkisg> Nice, ram and processor, anything else? Network bandwidth?
| |
| 15:18 | <Matrix3000> yep
| |
| 15:18 | per client bandwidth
| |
| 15:18 | im also monitoring bandwidth on teh server too
| |
| 15:18 | and getting graphs of it
| |
| 15:18 | as well as process count and load
| |
| 15:18 | <alkisg> Yeah I used to do that with munin in the past
| |
| 15:18 | <Matrix3000> and if it goes beyond a point im alerted
| |
| 15:18 | <alkisg> Now I'm mostly using iperf or netperf to check if the network installation is ok
| |
| 15:19 | Does zabbix eat significant system resources?
| |
| 15:19 | How much RAM does a ps aux|grep zabbix indicate?
| |
| 15:20 | (and its dependencies, e.g. java, python, apache, whatever it is)
| |
| 15:28 | artista_frustrad has joined IRC (artista_frustrad!~artista_f@189.30.138.160) | |
| 15:29 | Damianos has joined IRC (Damianos!~Damianos@adsl-070-145-074-043.sip.cha.bellsouth.net) | |
| 15:36 | * Gadi wonders why he doesn't get emails anymore when pushing commits | |
| 15:37 | <Gadi> alkisg: I just made some significant changes to ltsp_config. Please have a look when you get a chance
| |
| 15:37 | <alkisg> Gadi: the branches were re-created, you need to sign up for changes again
| |
| 15:37 | * alkisg checks... | |
| 15:37 | <Gadi> ah
| |
| 15:38 | <alkisg> Gadi, ;et
| |
| 15:38 | <Matrix3000> nop
| |
| 15:38 | <alkisg> let's talk about the mechanism
| |
| 15:38 | Gremble has left IRC (Gremble!~Ben@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com, Quit: I Leave) | |
| 15:38 | <Matrix3000> nope doesn't seem that way
| |
| 15:38 | <alkisg> /var/cache/ltsp/ltsp_config_env vs /var/cache/ltsp/ltsp_config, what's the difference?
| |
| 15:39 | <Matrix3000> process usage is mainly on the zabbix server
| |
| 15:39 | <Gadi> before we do that, do I simply subscribe myself on launchpad?
| |
| 15:40 | <alkisg> On the branch
| |
| 15:40 | <Gadi> it seems like all Commiters are subscribed
| |
| 15:40 | <alkisg> The committers are subscribed as a team
| |
| 15:40 | But we have no team email set up
| |
| 15:41 | Not sure if launchpad is supposed to mail us separately
| |
| 15:41 | <Gadi> do you get emails?
| |
| 15:41 | <alkisg> No
| |
| 15:41 | <Gadi> ok
| |
| 15:41 | <alkisg> I haven't subscribed again since the branch re-creation
| |
| 15:42 | Ah
| |
| 15:42 | <Gadi> I think we are subscribed, but I don't see how to turn on getting emails
| |
| 15:42 | <alkisg> Gadi: https://code.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/+subscription/ltsp-upstream
| |
| 15:42 | Notification level: no emails
| |
| 15:42 | Maybe warren didn't like the emails? Not sure
| |
| 15:42 | <Gadi> heh
| |
| 15:42 | <Matrix3000> alkisg: http://screencast.com/t/9jlrdOHD
| |
| 15:42 | <Gadi> ok, whatever
| |
| 15:42 | :)
| |
| 15:42 | <alkisg> Gadi: We can change it, or we can individually subscribe
| |
| 15:42 | <Gadi> right
| |
| 15:43 | anyhow, so /var/cache/ltsp/ltsp_config is a file used to add *additional* vars to the lts env
| |
| 15:43 | while /var/cache/ltsp/ltsp_config_env is a sourceable file of all lts vars
| |
| 15:44 | <alkisg> ltsp_config is generated dynamically to store the vars we want to remember later on
| |
| 15:44 | <Gadi> so, the former will be included when the vars are first "processed"
| |
| 15:44 | from the various sources
| |
| 15:44 | while the latter is used to set/reset all lts vars in the env
| |
| 15:44 | this way, we can, for example,
| |
| 15:45 | download a new lts.conf sometime after boot
| |
| 15:45 | <alkisg> Who/what sets ltsp_config the way you describe it?
| |
| 15:45 | <Gadi> and reprocess it (which includes resetting the env)
| |
| 15:45 | the scripts in ltsp_config.d
| |
| 15:45 | which now include: getltscfg, getltscfg-cluster, ...
| |
| 15:46 | <alkisg> Ah, big topic.. and what's the difference between ltsp_config.d and initramfs-scripts.d? Where would scripts in those 2 cases store the env vars they want to remember later on?
| |
| 15:46 | I don't know the whole separation seems kinda compicated to me
| |
| 15:47 | We don't even have 1 script to get all our config yet
| |
| 15:47 | <Gadi> so, initramfs-scipts.d/ is only run by initramfs
| |
| 15:47 | <alkisg> (that would call getltscfg, -cluster, source ltsp_config, whatever)
| |
| 15:47 | <Gadi> so, it is only in that limited env
| |
| 15:47 | <alkisg> (go on..)
| |
| 15:47 | <Gadi> and only that limited time
| |
| 15:47 | whereas
| |
| 15:47 | ltsp_config
| |
| 15:47 | gets sourced by any script running at any time that needs the lts vars in its env
| |
| 15:47 | <alkisg> Cool
| |
| 15:48 | <Gadi> which could be a udev script
| |
| 15:48 | or an init script
| |
| 15:48 | or whatever
| |
| 15:48 | <alkisg> I like the explanation even though it didn't match reality so far :P
| |
| 15:48 | It's a good plan
| |
| 15:48 | <Gadi> so, if there is something that initramfs wants to store for later
| |
| 15:48 | <alkisg> So, those scripts in ltsp_config.d that just set some vars statically, should move to initramfs, right?
| |
| 15:48 | <Gadi> or for use in, say, a later udev script
| |
| 15:49 | it can just echo "var=val" /var/cache/ltsp/ltsp_config
| |
| 15:49 | and that should be scooped up the first time lts conf params are processed
| |
| 15:50 | and if someone wants lts conf params to be reprocessed
| |
| 15:50 | they can set PROCESS_LTS_CONF=True before sourcing ltsp_config
| |
| 15:50 | <alkisg> That's complicated, I don't like it
| |
| 15:50 | Scripts should now themselves if they need to recalculate or not
| |
| 15:50 | *know
| |
| 15:50 | <Gadi> well they do
| |
| 15:51 | but, say you have a script that re-downloads lts.conf before the session starts
| |
| 15:51 | and overwrites the old one
| |
| 15:51 | so, every time someone logs out, it gets a new lts.conf
| |
| 15:51 | well, ltsp_config needs to know that it is new
| |
| 15:51 | otherwise, it will just pull from the old cache
| |
| 15:52 | <alkisg> OK, this is how I'd implement it:
| |
| 15:52 | I'd create an "get-ltsp-config" script, that would just run_parts ltsp_config.d
| |
| 15:52 | But it would also take a "phase" parameter
| |
| 15:52 | Like we did in the past together; and i think -cluster has something similar
| |
| 15:52 | Any scripts in ltsp_config.d that calculate vars statically should move to initramfs.d
| |
| 15:53 | All those that remain should be dynamic scripts
| |
| 15:53 | And they'd recalculate or not based on the phase
| |
| 15:53 | <andygraybeal_> Hyperbyte! :P
| |
| 15:54 | <Gadi> but, recalculating may take time and I may not want to recalculate if nothing has changed
| |
| 15:54 | <alkisg> That's just an if in your script code
| |
| 15:54 | But it should be decided on a per script basis
| |
| 15:55 | E.g. I may have a script that calculates something only the first time X runs
| |
| 15:55 | I don't want to have it ran multiple times - I just set a var for that
| |
| 15:55 | OK let me actually see the commit :D\
| |
| 15:57 | jtsop has left IRC (jtsop!~quassel@athedsl-07209.home.otenet.gr, Remote host closed the connection) | |
| 15:59 | artista_frustrad has left IRC (artista_frustrad!~artista_f@189.30.138.160, Ping timeout: 258 seconds) | |
| 16:02 | <alkisg> E.g. client/ltsp_config.d/10ltsp-server should go to the initramfs.d, right?
| |
| 16:03 | <Gadi> definitely
| |
| 16:03 | <alkisg> client/ltsp_config.d/15default-screen, client/ltsp_config.d/20fatclients, client/ltsp_config.d/25sound, client/ltsp_config.d/30localdev, client/ltsp_config.d/35encrypted-swap too
| |
| 16:03 | (and the next ones)
| |
| 16:04 | load ltsp config === . /usr/share/ltsp/ltsp_config => I like that, so we should only have 1 single getltscfg -a call in our whole codebase
| |
| 16:05 | <Gadi> right
| |
| 16:05 | <alkisg> OK so let's see which scripts will be left in ltsp_config.d
| |
| 16:06 | getting lts.conf, -cluster, parsing it, sourcing the ltsp_config (or .env) files
| |
| 16:06 | Avoiding typos
| |
| 16:06 | That's about it?
| |
| 16:07 | <Gadi> well, until now, ltsp has only thought in terms of getting an lts.conf on boot
| |
| 16:07 | and not so much how it might change
| |
| 16:07 | lets have a look at the -cluster code that is sprinkled about
| |
| 16:08 | because, I would like to use this to clean that up
| |
| 16:08 | <alkisg> Yes, that's long overdue
| |
| 16:09 | <Gadi> but so far, I think you are right - everything >=10- and <= 40-
| |
| 16:09 | in those ltsp_config.d scripts
| |
| 16:09 | <alkisg> Gadi, so lets see if I understood correctly: ltsp_config is mostly created by initramfs.d scripts, and only once, right?
| |
| 16:09 | <Gadi> can prolly bemoved to initramfs
| |
| 16:09 | fellowEntx has left IRC (fellowEntx!~fellowEnt@69.25.2.66, Quit: Leaving) | |
| 16:09 | <alkisg> I.e. after boot it won't ever be modified
| |
| 16:09 | And ltsp_config_env is just a way to store the env vars from the ltsp_config.d scripts?
| |
| 16:10 | <Gadi> the goal is that it *can* be modified
| |
| 16:10 | after boot
| |
| 16:10 | so, lets say you wanted to change "SCREEN_07"
| |
| 16:10 | <alkisg> Modified as a file or overriden by sourcing ltsp_config_env?
| |
| 16:10 | <Gadi> and have the client see that change upon logout
| |
| 16:10 | loather has joined IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net) | |
| 16:11 | <Gadi> so, I might have a script in screen_session.d/ that says "PROCESS_LTS_CONF=True"
| |
| 16:12 | and an ltsp_config.d/ script that tftp's lts.conf again before processing it
| |
| 16:12 | artista_frustrad has joined IRC (artista_frustrad!~artista_f@189.30.138.160) | |
| 16:12 | <Gadi> my SCREEN_07 changes, and I take action
| |
| 16:12 | or some such
| |
| 16:13 | or maybe my script tftp's the lts.conf and sees if it changed and if not, does nothing
| |
| 16:13 | <alkisg> And what's the save/restore env logic?
| |
| 16:13 | <Gadi> along those lines
| |
| 16:13 | oh, so all of our lts conf vars get dumped into the env
| |
| 16:14 | so, if you, say, want a var removed,
| |
| 16:14 | Steve_the_Pirate has joined IRC (Steve_the_Pirate!Gary@nat/redhat/x-ghfaiohvzvcdayuc) | |
| 16:14 | <Gadi> it is not so easily done
| |
| 16:14 | (In most of our scripts, the env hasn't changed, because we source everything)
| |
| 16:14 | so, you need to reset all that you set
| |
| 16:14 | and then set it again
| |
| 16:15 | to ensure your env is not polluted
| |
| 16:15 | <alkisg> Why not just append VAR=<empty> in ltsp_config_env ?
| |
| 16:16 | <Gadi> because if you removed a var from your lts.conf, how does ltsp_config know to remove it from _env?
| |
| 16:16 | artista_frustrad has left IRC (artista_frustrad!~artista_f@189.30.138.160, Ping timeout: 245 seconds) | |
| 16:16 | <Gadi> alkisg: have a look at the screen-session script
| |
| 16:17 | take a look at the -cluster code there
| |
| 16:17 | do you see how they are resetting the env?
| |
| 16:19 | <alkisg> Erm sorry, what is the exact filename?
| |
| 16:19 | <Gadi> client/screen_session
| |
| 16:19 | look in the main() function
| |
| 16:19 | <alkisg> Yup, I can't say I like it
| |
| 16:19 | <Gadi> right
| |
| 16:20 | so, they unset basically everything
| |
| 16:20 | except a few things
| |
| 16:20 | because they don't know what was an lts param
| |
| 16:20 | but, if you have a cache of all lts params, it is easy to reset just those params
| |
| 16:21 | I would like to replace all of that code, with a simple: PROCESS_LTS_CONF=True . /usr/share/ltsp/ltsp_config
| |
| 16:23 | Steve_the_Pirate has left IRC (Steve_the_Pirate!Gary@nat/redhat/x-ghfaiohvzvcdayuc, Quit: Leaving) | |
| 16:24 | <alkisg> I think `PHASE=session . usr/share/ltsp/ltsp_config` would be a bit more flexible, but I got the idea, let me thing about it...
| |
| 16:24 | staffencasa has joined IRC (staffencasa!~staffenca@128-193-146-230.oregonstate.edu) | |
| 16:26 | <alkisg> In my idea above, we'd start with a clean environment each time, and just run_parts whatever configuration sources we have. If one configuration source wants to use caching, it's their responsibility, we'd only cache the initramfs.d output
| |
| 16:27 | When do we want to have PROCESS_LTS_CONF=True?
| |
| 16:27 | And, which events do we have?
| |
| 16:27 | X started, Login, Logout, ?
| |
| 16:29 | artista_frustrad has joined IRC (artista_frustrad!~artista_f@189.30.138.160) | |
| 16:30 | jvin has left IRC (jvin!~jvin@108-82-19-151.lightspeed.livnmi.sbcglobal.net, Read error: Operation timed out) | |
| 16:32 | <Gadi> so your get-ltsp-config would be used just as getltscfg is, where we would eval `get-ltsp-config $phase`
| |
| 16:32 | something like that?
| |
| 16:33 | <alkisg> No, One clean solution would be to expect whatever sources of configuration we have to do this: if they set a var once, they always need to have it
| |
| 16:33 | *copy paste error
| |
| 16:33 | No, `PHASE=session . usr/share/ltsp/ltsp_config`
| |
| 16:33 | I don't like eval, sourcing is better
| |
| 16:33 | artista_frustrad has left IRC (artista_frustrad!~artista_f@189.30.138.160, Ping timeout: 240 seconds) | |
| 16:35 | <Gadi> I guess the whole premise here is that we want to allow ltsp_config to be expensive if it needs to process the variables, but otherwise it should be fast
| |
| 16:35 | and the only time it should have to process variables is if those params change in lts.conf (or equivalent qsource)
| |
| 16:36 | dobber has left IRC (dobber!~dobber@89.190.199.210, Remote host closed the connection) | |
| 16:40 | <alkisg> Hmm, I still think looking at the events when we have to source ltsp_config may be helpful
| |
| 16:40 | E.g. we source it on screen.d scripts, we'd need a complete evaluation there anyway
| |
| 16:41 | On the next screen.d call, the environment is clean, no need to unset vars
| |
| 16:43 | LDM also calls scripts on x start etc, those also source ltsp_config, right?
| |
| 16:43 | Won't we get lts.conf again at that point?
| |
| 16:46 | artista_frustrad has joined IRC (artista_frustrad!~artista_f@189.30.138.160) | |
| 16:48 | <Gadi> so, looking at getltscfg-cluster, it seems they identify a few phases: boot, prompt, login, logout, and refresh|ldm
| |
| 16:48 | Damianos has left IRC (Damianos!~Damianos@adsl-070-145-074-043.sip.cha.bellsouth.net, Quit: Damianos) | |
| 16:51 | artista_frustrad has left IRC (artista_frustrad!~artista_f@189.30.138.160, Ping timeout: 256 seconds) | |
| 16:51 | <alkisg> What's the prompt phase?
| |
| 16:52 | <Gadi> that seems to be called in screen_session
| |
| 16:52 | "refresh" seems to be called in ltsp-setup
| |
| 16:52 | and "boot" in ltsp-core
| |
| 16:53 | (btw, I plan to make the initscripts go away and write upstart scripts on the fly out of initramfs-scripts.d/)
| |
| 16:53 | <alkisg> Nice, I thought about that :)
| |
| 16:54 | No need to conditionally disable them in this case
| |
| 16:54 | <Gadi> part of this effort is to get a framework to which to move things
| |
| 16:54 | :)
| |
| 16:54 | <alkisg> (just symlinks would do)
| |
| 16:54 | <Gadi> that includes -cluster stuff
| |
| 17:04 | artista_frustrad has joined IRC (artista_frustrad!~artista_f@189.30.138.160) | |
| 17:04 | <alkisg> We wouldn't even have an equivalent of ltsp-setup and ltsp-core now, right?
| |
| 17:05 | <Gadi> right
| |
| 17:06 | (in Ubuntu)
| |
| 17:06 | <alkisg> Not in all distros?
| |
| 17:07 | <Gadi> not sure all distros use upstart
| |
| 17:07 | so, they may have to customize initramfs-scripts.d/
| |
| 17:07 | <alkisg> No I mean that we won't be using our own init/upstart script
| |
| 17:07 | We'll stick to whatever the disto has
| |
| 17:07 | <Gadi> right
| |
| 17:07 | <alkisg> And just modify config files in the initramfs.d
| |
| 17:07 | <Gadi> that's my hope
| |
| 17:08 | and my upstart scripts right now will call screen_session on the appropriate tty
| |
| 17:08 | hughessd has joined IRC (hughessd!~hughessd@173-164-117-109-Oregon.hfc.comcastbusiness.net) | |
| 17:09 | <alkisg> Right, so you'll just modify/rewrite tty1.conf etc
| |
| 17:09 | <Gadi> right, which will call screen_session 1
| |
| 17:09 | etc
| |
| 17:09 | <alkisg> That's the equivalent of the "prompt" event?
| |
| 17:10 | <Gadi> heh
| |
| 17:10 | good question
| |
| 17:10 | <alkisg> Do we even need such an event? Or the initramfs is enough?
| |
| 17:10 | <Gadi> well, we don't want to break cluster
| |
| 17:10 | not sure what happens in cluster when there are multiple screens
| |
| 17:11 | maybe mgariepy or stgrabe can weigh in
| |
| 17:11 | *stgraber
| |
| 17:12 | <alkisg> Hmm.... suppose we have an rdesktop session, which needs to check various servers
| |
| 17:12 | I can't check on initramfs, as it'll want to check the next time it starts too
| |
| 17:12 | (after logout)
| |
| 17:13 | <Gadi> define "check"
| |
| 17:13 | <alkisg> Check load? Check availability?
| |
| 17:14 | <Gadi> thats different than lts.conf
| |
| 17:15 | but, if you take the simple case of changing the server IP in lts.conf
| |
| 17:15 | and not wanting to reboot
| |
| 17:15 | <alkisg> Maybe it gets the availability from the RDP_SERVERS lts.conf var, dunno...
| |
| 17:15 | <Gadi> then, yes, that should be called in the rdesktop loop
| |
| 17:16 | <alkisg> OK so let's stick to the -cluster defined events for now
| |
| 17:16 | <Gadi> right
| |
| 17:16 | <alkisg> How much caching do we need?
| |
| 17:16 | Let's start with lts.conf
| |
| 17:16 | There's not much point to check if it's modified
| |
| 17:16 | The question is, do you redownload it with tftp or not
| |
| 17:17 | <Gadi> well, tftp is dumb, so you may want to turn that on its head, and say always download it with tftp but only process it if its modified
| |
| 17:18 | * alkisg times that... | |
| 17:18 | <Gadi> right - which takes longer
| |
| 17:18 | :)
| |
| 17:19 | heh - of course one might modify lts.conf for a different client
| |
| 17:19 | :P
| |
| 17:21 | maybe we should just have a param to enable re-downloading of lts.conf at phases other than boot. Then, if it causes too much pain on slower clients, they can turn it off
| |
| 17:25 | <alkisg> getltscfg -a is a bit faster than tftp localhost, but not much. tftp server would prolly be slower, but anyway it's a good thing to check if lts.conf has been modified before calling getltscfg -a again.
| |
| 17:25 | Although I don't know how faster the check itself would be :)
| |
| 17:26 | Ah, not much if done with diff
| |
| 17:26 | (and tftp doesn't set the file date)
| |
| 17:26 | So anyway I think we can redownload lts.conf at all those events
| |
| 17:27 | Maybe we could avoid the logout event, but I don't think it's worth it to start caching just because of that
| |
| 17:27 | I think the case with getltscfg will be similar, and the ltsp_config.d scripts would even be faster
| |
| 17:27 | So I'm not sure that the whole save env/restore env is worth the trouble
| |
| 17:28 | <Gadi> I think we will run into problems if we don't reset the env properly
| |
| 17:28 | on scripts that loop
| |
| 17:28 | <alkisg> The screen.d scripts get a clean env from the upstart or init scripts
| |
| 17:29 | <Gadi> but what about the screen_session script
| |
| 17:29 | it does not
| |
| 17:29 | screen.d scripts don't (usually) loop
| |
| 17:29 | with the exception of rdesktop
| |
| 17:30 | they usually exit and then are respawned by screen_session
| |
| 17:37 | <alkisg> Gadi, will we have a screen_session script? Will we allow for changing SCREEN_xx dynamically?
| |
| 17:37 | <Gadi> I would like to
| |
| 17:37 | yes
| |
| 17:37 | <alkisg> So if e.g. I have SCREEN_02=shell, and SCREEN_07=ldm, and on ldm logout I get SCREEN_02=xterm, what do I do?
| |
| 17:37 | Kill the shell I have there and start an xterm?
| |
| 17:38 | <Gadi> it might make more sense if you log out of the shell for it to come back as an xterm, no?
| |
| 17:38 | <pmatulis> plugging a webcam into my thin client the device is not "registered", yet it works/registered on my laptop. troubleshooting tips?
| |
| 17:39 | <Gadi> pmatulis: what distro?
| |
| 17:39 | <pmatulis> Gadi: ubuntu 11.10
| |
| 17:40 | <alkisg> Gadi: so, I'd check SCREEN_x (the one that I'm in), and modify init/ttyx.conf accordingly, and restart the ttyx service? Sounds complicated, but it still gives me a clean environment for my screen script
| |
| 17:42 | <pmatulis> Gadi: this is from my laptop: http://paste.ubuntu.com/733313/
| |
| 17:42 | Gadi: this is from my thin client: http://paste.ubuntu.com/733314/
| |
| 17:43 | <alkisg> Gadi, do you have a specific use case for the SCREEN_x dynamic changing?
| |
| 17:44 | Maybe a reboot directive would be more appropriate?
| |
| 17:44 | <Gadi> ph call
| |
| 17:44 | <alkisg> np
| |
| 17:50 | bb in 30', will read backlog
| |
| 17:55 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 260 seconds) | |
| 18:30 | vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi) | |
| 18:39 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 18:46 | komunista has joined IRC (komunista!~slavko@adsl-195-098-014-097.dynamic.nextra.sk) | |
| 18:57 | [GuS] has left IRC ([GuS]!~MysT@unaffiliated/gus/x-663402, Remote host closed the connection) | |
| 19:09 | artista_frustrad has left IRC (artista_frustrad!~artista_f@189.30.138.160, Ping timeout: 240 seconds) | |
| 19:11 | <Matrix3000> alkisg, did you get my screenshot?
| |
| 19:11 | loather-work has joined IRC (loather-work!~khudson@68.25.27.54) | |
| 19:13 | <alkisg> Matrix3000: yes, but that was showing a lot of thin client sessions on the server? Or did I understand it wrong?
| |
| 19:14 | <Matrix3000> oh that wasn't the server that was a fat client
| |
| 19:14 | the server is where much of the processing is
| |
| 19:14 | i have 80 fat/thin clients on the network
| |
| 19:15 | im monitoring 66 of them at teh moment
| |
| 19:15 | http://screencast.com/t/gLK9BkpSaaRT
| |
| 19:15 | that was a few instances running on the thin client
| |
| 19:15 | i ment "fat client" sorry
| |
| 19:15 | the one i sent
| |
| 19:15 | on the server it will show this
| |
| 19:16 | <alkisg> Got it. Cool!
| |
| 19:16 | <Matrix3000> http://screencast.com/t/aIsEQlGL
| |
| 19:16 | zabbix_server runs on one pc/server (the monitoring system)
| |
| 19:16 | and you run zabbix_agentd on the thin clients or fat clients and servers
| |
| 19:17 | it also alerts me when my ltsp server has over 2000 running processse
| |
| 19:17 | and more than 50 users directly logged in
| |
| 19:18 | yea, right now i a mloving it
| |
| 19:18 | someone unplugged their desktop and it alerted me
| |
| 19:18 | :)
| |
| 19:18 | cause the fat client stopped communicating
| |
| 19:19 | so lets say a bad network jack or something you can find it
| |
| 19:20 | loather-work has left IRC (loather-work!~khudson@68.25.27.54, Ping timeout: 260 seconds) | |
| 19:21 | <alkisg> Nice. Gadi, one way to reinitialize the environment is with plain subshells: http://paste.ubuntu.com/733429
| |
| 19:30 | quietone has joined IRC (quietone!~quietone@121-98-80-11.bitstream.orcon.net.nz) | |
| 19:32 | <Gadi> alkisg: sorry. lots of phone calls :)
| |
| 19:32 | pmatulis: apologies, as well
| |
| 19:32 | <alkisg> np sorry myself it took me more than expected
| |
| 19:32 | loather-work has joined IRC (loather-work!~khudson@68-25-27-54.pools.static.spcsdns.net) | |
| 19:32 | <Gadi> alkisg: the issue is that we are sourcing ltsp_config to populate the env
| |
| 19:33 | we aren't actually calling subshells
| |
| 19:33 | <alkisg> We can source it in a subshell
| |
| 19:33 | E.g. the rdesktop:
| |
| 19:33 | <Gadi> ah
| |
| 19:33 | I guess
| |
| 19:33 | <alkisg> (ok no example needed :P)
| |
| 19:33 | <Gadi> as long as we're changing scripts... :)
| |
| 19:33 | might as well change them all
| |
| 19:33 | <alkisg> But let's see when we actually need that
| |
| 19:34 | So, screen.d/* are clean, initially
| |
| 19:34 | screen_session will be written as upstart/init scripts, clean too, no loop
| |
| 19:34 | Right?
| |
| 19:34 | <Gadi> screen_session itself runs in a loop
| |
| 19:35 | the upstart scripts will call screen_session
| |
| 19:35 | <alkisg> Won't we completely remove screen_session?
| |
| 19:35 | And have init scripts instead?
| |
| 19:35 | Or did I misunderstand?
| |
| 19:35 | <Gadi> no - I think it will be easier to maintain if the upstart scripts exec screen_session
| |
| 19:36 | <alkisg> Let's see a use case
| |
| 19:36 | <Gadi> that way, distros of all kinds can use the same screen_session
| |
| 19:36 | <alkisg> I say, SCREEN_02=shell, SCREEN_07=ldm
| |
| 19:36 | Are those written as upstart scripts from initramfs.d?
| |
| 19:36 | <Gadi> I almost have the code to generate the screen scripts done
| |
| 19:36 | let me finish it up and push it
| |
| 19:37 | <alkisg> OK
| |
| 19:37 | <Gadi> so you can see what I am thinking
| |
| 19:37 | <alkisg> Mhm
| |
| 19:45 | loather-work has left IRC (loather-work!~khudson@68-25-27-54.pools.static.spcsdns.net, Ping timeout: 252 seconds) | |
| 19:47 | klausade has joined IRC (klausade!~klaus@cm-84.215.152.210.getinternet.no) | |
| 19:48 | mistik1_ has joined IRC (mistik1_!mistik1@unaffiliated/mistik1) | |
| 19:50 | <Gadi> ok
| |
| 19:50 | pushed
| |
| 19:50 | mistik1 has left IRC (mistik1!mistik1@unaffiliated/mistik1, Ping timeout: 245 seconds) | |
| 19:50 | mistik1_ is now known as mistik1 | |
| 19:50 | <Gadi> basically, my thinking is that each of the ttys is actively waiting for a possible screen_session to run
| |
| 19:51 | when one is set in lts.conf, it initializes
| |
| 19:51 | which means that running sessions that change will change upon logout
| |
| 19:51 | loather-work has joined IRC (loather-work!~khudson@68-25-27-54.pools.static.spcsdns.net) | |
| 19:53 | <Gadi> in fact, the fgconsole code can be brought into the loop, so that if something initializes a new X it doesn't steal focus
| |
| 19:53 | let me change that
| |
| 20:00 | <quietone> cool, just got sound working on a thin client ;-)
| |
| 20:03 | <alkisg> Gadi, I don't know, I see no point in having e.g. 6 loops when we can do the same in 1 loop
| |
| 20:03 | We can save 5*ramof(shell) this way
| |
| 20:03 | <Gadi> where do you see 6 loops?
| |
| 20:03 | only one
| |
| 20:03 | in screen_session
| |
| 20:03 | <alkisg> Running screen_session 6 times just in case there's a SCREEN_0x var
| |
| 20:04 | Sorry, 12
| |
| 20:04 | for i in 1 2 3 4 5 6 7 8 9 10 11 12; do echo <<EOF >/etc/init/tty${i}.conf
| |
| 20:04 | <Gadi> ok, use case:
| |
| 20:04 | I boot with no SCREENs set. I then set SCREEN_02=shell, SCREEN_07=ldm
| |
| 20:04 | I don't want to reboot
| |
| 20:04 | how do you start screen_02?
| |
| 20:05 | mistik1 has left IRC (mistik1!mistik1@unaffiliated/mistik1, Ping timeout: 240 seconds) | |
| 20:05 | <alkisg> With the screen_script? Or with plain ttyx.conf?
| |
| 20:05 | With the central screen script:
| |
| 20:05 | <Gadi> either
| |
| 20:05 | <alkisg> I'd have an upstart job for it, and symlink it to init on boot
| |
| 20:06 | <Gadi> explain
| |
| 20:06 | <alkisg> Like the one you create as tty1.conf
| |
| 20:06 | Parker955_Away is now known as Parker955 | |
| 20:06 | <alkisg> As I'd have only one, there's no need to generate it dynamically
| |
| 20:06 | It could be a static file
| |
| 20:07 | <Gadi> ok, so that works on boot
| |
| 20:07 | what happens when lts.conf changes?
| |
| 20:07 | <alkisg> When that upstart job runs, it sources ltsp_config, and spawns 1 openvt process for each one of the SCREENs
| |
| 20:08 | <Gadi> ...
| |
| 20:08 | <alkisg> So if I only have 1 screen, I only get one shell
| |
| 20:08 | hughessd has left IRC (hughessd!~hughessd@173-164-117-109-Oregon.hfc.comcastbusiness.net, Quit: hughessd) | |
| 20:08 | <Gadi> (03:07:21 PM) Gadi: what happens when lts.conf changes?
| |
| 20:08 | <alkisg> When those screen scripts exit, they can ping it to re-read lts.conf etc
| |
| 20:08 | And start all over again
| |
| 20:09 | <Gadi> so, all of the sessions on every screen have to logout?
| |
| 20:09 | loather-work has left IRC (loather-work!~khudson@68-25-27-54.pools.static.spcsdns.net, Ping timeout: 252 seconds) | |
| 20:09 | <alkisg> But before going to details, the question is: what's the use case for dynamic screen changes?
| |
| 20:09 | <Gadi> at the same time?
| |
| 20:09 | <alkisg> No
| |
| 20:09 | Any one of them can ping the main process to re-read the config
| |
| 20:09 | SIG_USRsomething
| |
| 20:10 | <Matrix3000> http://pastebin.com/XZFV0VuA
| |
| 20:10 | <alkisg> So we don't even need to sleep in a while
| |
| 20:10 | <Matrix3000> alksig, you might want to look at that
| |
| 20:10 | how do I fix that
| |
| 20:10 | <alkisg> (10:09:09 μμ) alkisg: But before going to details, the question is: what's the use case for dynamic screen changes?
| |
| 20:10 | <Gadi> well, the sleep was to be able to set a default screen
| |
| 20:10 | mistik1 has joined IRC (mistik1!mistik1@unaffiliated/mistik1) | |
| 20:10 | <Gadi> use cases abound:
| |
| 20:10 | <Matrix3000> sorry shoulnd't of directly asked you
| |
| 20:11 | anyone know how to fix this linux-image-2.6.38-12-generic
| |
| 20:11 | <Gadi> I want to change the session from ldm to rdesktop without requiring the users to reboot
| |
| 20:11 | <Matrix3000> http://pastebin.com/XZFV0VuA
| |
| 20:11 | thats inside of fatclient chroot
| |
| 20:11 | <Gadi> I want to add screens without having the thin clients reboot
| |
| 20:11 | <alkisg> How do you decide that?
| |
| 20:12 | To change screen from ldm to rdesktop?
| |
| 20:12 | <Gadi> who cares?
| |
| 20:12 | <alkisg> Maybe what you actually need is a different screen script?
| |
| 20:12 | That would be just one, run always, and that would decide what you want to run?
| |
| 20:12 | <Gadi> I dont follow you
| |
| 20:13 | <alkisg> SCREEN_07=gadis_special_case_of_running_either_rdesktop_or_ldm
| |
| 20:13 | ...script
| |
| 20:13 | <Gadi> you dont think in general people would find it easier to be able to modify sessions without rebooting the client?
| |
| 20:13 | <Matrix3000> i hate fat clients!!!!
| |
| 20:14 | <Gadi> Matrix3000: that's just plain prejudice
| |
| 20:14 | :P
| |
| 20:14 | <Matrix3000> lol
| |
| 20:14 | the linux image wont install ro uninstall
| |
| 20:14 | <alkisg> Gadi, I can't imagine when I'd want to do that in production, to have the same screen using a different screen script on each loop
| |
| 20:15 | <Matrix3000> http://pastebin.com/VbvYeMgB
| |
| 20:15 | <alkisg> Matrix3000: file a bug against linux and grub, that it doesn't want to upgrade on chroots
| |
| 20:15 | Matrix3000: Also, purge grub :)
| |
| 20:15 | <Gadi> Matrix3000: mount proc in the chroot?
| |
| 20:15 | <alkisg> apt-get purge --auto-remove grub-pc os-prober => something like that
| |
| 20:16 | <Matrix3000> Gadi: tried that
| |
| 20:16 | <alkisg> Gadi, I'd consider that a special use case that needs some special screen script + maybe more client side code
| |
| 20:16 | <Matrix3000> alkisg: still wont remove that 2.6.38
| |
| 20:17 | <Gadi> huh
| |
| 20:17 | <alkisg> Matrix3000: open /etc/kernel/postinst.d/zz-update-grub and put "exit 0" near its top
| |
| 20:17 | <Matrix3000> am i going to have to rebuild the image?
| |
| 20:17 | <Gadi> ok...
| |
| 20:17 | with that line of thinking, I cannot think of any reason why you would ever want to change anything without rebooting
| |
| 20:18 | <Matrix3000> alkisg, ok done
| |
| 20:18 | <alkisg> For example, I may want to change LDM_USERNAME/PASSWORD based on date
| |
| 20:18 | Or I may want to change the server I want to login to
| |
| 20:19 | But I really can't imagine a real use case where people would like to see something different on logout than what they had previously, and without changing screens
| |
| 20:19 | <Gadi> why not reboot for those, as well?
| |
| 20:19 | <alkisg> OK bottom line is this: if you actually have a use case, by all means, let's do it
| |
| 20:19 | <Gadi> maybe because you have labs that are used for Windows at one part of the day and Linux another?
| |
| 20:19 | <alkisg> But how would they switch?
| |
| 20:19 | <Gadi> maybe because you have rdp running on several screens at the same time for security reasons?
| |
| 20:19 | <alkisg> Suppose I'm in the login prompt
| |
| 20:20 | And the hour for windows has passed, and the time for linux has come
| |
| 20:20 | <Matrix3000> ok it finally started working
| |
| 20:20 | <alkisg> I need to login + logout for the change to take effect?
| |
| 20:20 | <Matrix3000> did an update first
| |
| 20:20 | then tried
| |
| 20:20 | <alkisg> OK I have many rdp screens - what's the change there?
| |
| 20:21 | <Gadi> so, maybe I change the server that screen 1's rdp connection logs into
| |
| 20:21 | <Matrix3000> rdp for windows terminal sessions?
| |
| 20:21 | <alkisg> Gadi, that's an lts.conf change, not a screen change
| |
| 20:21 | <Gadi> I specify with SCREEN_01="rdesktop server"
| |
| 20:22 | <alkisg> You just change that screen's params, you don't launch a different script script
| |
| 20:22 | <Gadi> and it is
| |
| 20:22 | <alkisg> It's still rdesktop, no change, don't think with implementation details
| |
| 20:22 | <Gadi> cant use RDP_SERVER, bec I have 3 different screens
| |
| 20:22 | <alkisg> Let's see if we can find a use case where you need a different screen script
| |
| 20:23 | Because if the same rdesktop screen sources ltsp_config, it can then read your changed server
| |
| 20:23 | In a loop, without it ever exiting
| |
| 20:23 | <Gadi> hmm
| |
| 20:23 | ok
| |
| 20:23 | <pmatulis> Gadi: np. do you have any idea why the webcam does not work on a client but it does on a full install (laptop)?
| |
| 20:23 | <mistik1> greetings guys
| |
| 20:23 | <alkisg> Hi mistik1
| |
| 20:23 | <Gadi> pmatulis: it looked like usbcore was not loaded?
| |
| 20:24 | <Matrix3000> pmatulis: do you have drivers etc configured in the thin client
| |
| 20:24 | <alkisg> Gadi, or, if we can find a use case where we want to dynamically add a new screen
| |
| 20:24 | <Gadi> pmatulis: or maybe your user was not in a proper group?
| |
| 20:24 | alkisg: well, I guess that would mostly be in the troubleshooting case
| |
| 20:24 | alkisg: but, you are right in that should be infrequent
| |
| 20:24 | and rebooting is fine
| |
| 20:24 | so, ok
| |
| 20:25 | I'll buy it
| |
| 20:25 | <alkisg> So, with respawn in init/tty1.conf, you don't even need a loop
| |
| 20:25 | <Gadi> right - but we don't know that all distros will use upstart
| |
| 20:25 | so safer to have the loop in the script
| |
| 20:26 | <alkisg> inittab has respawn too afaik
| |
| 20:26 | <pmatulis> Matrix3000: drivers configured in the client? er, not sure i understand
| |
| 20:26 | <alkisg> Gadi but then we lose the "service tty1 stop" ability
| |
| 20:26 | I don't know if that will be needed
| |
| 20:26 | <Gadi> hmm
| |
| 20:26 | ok
| |
| 20:26 | <alkisg> But it's expected,if it's a service
| |
| 20:26 | OK minor
| |
| 20:26 | Don't really care about that
| |
| 20:27 | <Gadi> I think it a misnomer to call it tty1.conf
| |
| 20:27 | <alkisg> So, we can generate those tty* in initramfs like you already do, and forget about them
| |
| 20:27 | tty1 == something declared as SCREEN_01
| |
| 20:27 | <Gadi> ah
| |
| 20:27 | right
| |
| 20:27 | <alkisg> We can call it screen01.conf instead
| |
| 20:27 | <Gadi> we still need to sleep for the SCREEN_DEFAULT stuff
| |
| 20:27 | that's why we had it to begin with
| |
| 20:27 | <alkisg> This way we have 1 process per screen, I'm ok with that
| |
| 20:27 | I didn't like the 12 processes
| |
| 20:28 | <Gadi> but, I can limit the ttys that get spawned to just one
| |
| 20:28 | <alkisg> We could have 1 main process with signals etc
| |
| 20:28 | But I don't think it's worth it, most people only have 1-2 screens
| |
| 20:28 | We can only generate as many screen0x.conf as we have SCREEN_0x in lts.conf
| |
| 20:29 | The tty[1-6] in Ubuntu are special service names, we probably shouldn't use those
| |
| 20:29 | You delete [2-5] now already, don't you?
| |
| 20:29 | So screen0x.conf sounds good to me
| |
| 20:36 | Also, I'm not sure if upstart is the way to go yet. If we don't need anything upstart specific, why not stay with sysvinit and be compatible with more distros?
| |
| 20:36 | hughessd has joined IRC (hughessd!~hughessd@173-164-117-109-Oregon.hfc.comcastbusiness.net) | |
| 20:37 | <alkisg> Of course we'll delete the upstart services we don't need, but that's just an "rm", while dynamically writing init scripts takes a bit more code
| |
| 20:40 | <Gadi> well, the dynamic creation part I think comes from not wanting a live chroot fat client when booted to necessarily come up to ldm, right?
| |
| 20:40 | <alkisg> Errr explain more?
| |
| 20:40 | <Gadi> (though, not sure exactly your thoughts on that)
| |
| 20:41 | hughessd has left IRC (hughessd!~hughessd@173-164-117-109-Oregon.hfc.comcastbusiness.net, Client Quit) | |
| 20:41 | <Gadi> well, you wanted to be able to boot a chroot OS in a VM (not netboot, but local boot), right?
| |
| 20:41 | <alkisg> Yes,... ?
| |
| 20:41 | <Gadi> ok, when that comes up, it should come up like a regular OS
| |
| 20:42 | boot to gdm
| |
| 20:42 | <alkisg> I'm not arguing against dynamic creation of init scripts
| |
| 20:42 | <Gadi> and I suppose have some user that one can log into
| |
| 20:42 | <alkisg> I'm arguing against maintaining the code to do that in sysvinit, upstart and systemd
| |
| 20:42 | While currently sysvinit suffices
| |
| 20:42 | <Gadi> right right
| |
| 20:42 | no - I am on a different topic
| |
| 20:42 | <alkisg> Go on
| |
| 20:43 | <Gadi> just making sure I am clear on dynamically writing that upstart file from initramfs rather than having it as a static file
| |
| 20:43 | tho, I suppose it could be a static file that bails out if it doesnt have the right conf file or something
| |
| 20:44 | <alkisg> Or you could have a static file in /usr/share/ltsp/initscripts and just symlink it to /etc/init.d, maybe even with update-rc.d
| |
| 20:44 | Erm, maybe have it in /etc/init.d and use update-rc.d to put it to specified runlevels :D
| |
| 20:44 | Or something, np there
| |
| 20:45 | <Gadi> well, lets get into that when we get to hacking up that existing code
| |
| 20:45 | <alkisg> Yeah those are details more or less
| |
| 20:45 | <Gadi> I have been trying to be a bit careful right now to not break the old way
| |
| 20:45 | while we work on the new way
| |
| 20:46 | <alkisg> You can leave the ltsp-setup etc and delete them from the initramfs, though I don't see a point in it
| |
| 20:46 | <Gadi> nah - I just wouldn't package those
| |
| 20:46 | <alkisg> Good
| |
| 20:46 | <Gadi> and right now, it is easy to just package some things and not others
| |
| 20:47 | like throw in the init-bottom/ and remove the nfs-botton
| |
| 20:47 | <alkisg> But if things move from ltsp_config.d to initramfs?
| |
| 20:47 | <Gadi> *m
| |
| 20:47 | right
| |
| 20:47 | thats why I haven't moved those yet
| |
| 20:47 | <alkisg> Gotcha
| |
| 20:48 | <Gadi> I know - a lil half-baked
| |
| 20:48 | :)
| |
| 20:48 | but, we are certainly finding room for things
| |
| 20:48 | <alkisg> I think vagrantc's in favor of this, I don't know what stgraber thinks about it, but I think it's probably too late, if he wants the old code for precise he'd need to select a prior revision anyway
| |
| 20:49 | <Gadi> not really
| |
| 20:49 | <alkisg> So maybe if you/we go on and move the rest of the stuff and stabilize in time, it might even go into precise
| |
| 20:49 | <Gadi> nohe can just package things the old way
| |
| 20:50 | <alkisg> Ah, ok, that's good. Hm...
| |
| 20:52 | komunista has left IRC (komunista!~slavko@adsl-195-098-014-097.dynamic.nextra.sk, Quit: Leaving.) | |
| 20:52 | <Gadi> then again, I would love to start cleaning up the -cluster code
| |
| 20:53 | which I was thinking of doing by ripping it out of the hardcoded scripts and getting it into ltsp_config.d
| |
| 20:53 | <alkisg> I think we need stgraber's thoughts on this; if he's planning on getting some previous snapshot, there's no point in trying too much to not break the old packaging
| |
| 20:53 | stgraber?
| |
| 20:53 | <Gadi> right
| |
| 20:54 | ok
| |
| 20:54 | bbiab
| |
| 20:55 | <Matrix3000> how do i send a message to a thin client user
| |
| 20:55 | through the server
| |
| 20:55 | like to his computer directly
| |
| 20:55 | Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.69, Quit: "Achievement is not the end, its the beginning of new journey !!!") | |
| 21:04 | <alkisg> Matrix3000: normally you're not allowed to access the X display of the users. Are you looking for a hack or for a program?
| |
| 21:06 | <Matrix3000> na
| |
| 21:07 | just trying to send a message to people who restart their computers
| |
| 21:07 | we have a problem with people restarting when they have issues even if its not a pc issue
| |
| 21:12 | <alkisg> It was a multiple choice question... "Are you looking for a hack or for a program?"
| |
| 21:12 | You're supposed to answer (1) or (2), not (3) - noone of the above :P
| |
| 21:13 | <Matrix3000> hahaha
| |
| 21:13 | just something built in
| |
| 21:13 | not a biggie
| |
| 21:14 | <alkisg> There's no builting mechanism to access other people's displays
| |
| 21:14 | If you want a hack, here it is: http://paste.ubuntu.com/733570/
| |
| 21:14 | If you want a program, here it is: www.epoptes.org
| |
| 21:40 | jvin has joined IRC (jvin!~jvin@108-82-19-151.lightspeed.livnmi.sbcglobal.net) | |
| 22:01 | jvin has left IRC (jvin!~jvin@108-82-19-151.lightspeed.livnmi.sbcglobal.net, Ping timeout: 240 seconds) | |
| 22:02 | lifeboy_ has left IRC (lifeboy_!~roland@41.183.26.154, Quit: Time to go...) | |
| 22:02 | lifeboy has left IRC (lifeboy!~roland@41.183.26.154, Quit: Time to go...) | |
| 22:09 | andygraybeal has left IRC (andygraybeal!~andy.gray@obsidian.casanueva.com, Quit: Ex-Chat) | |
| 22:14 | jvin has joined IRC (jvin!~jvin@108-82-19-151.lightspeed.livnmi.sbcglobal.net) | |
| 22:23 | Damianos has joined IRC (Damianos!~Damianos@adsl-070-145-074-043.sip.cha.bellsouth.net) | |
| 22:35 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Read error: Operation timed out) | |
| 22:37 | Parker955 is now known as Parker955_Away | |
| 22:51 | dead_inside has left IRC (dead_inside!~dead_insi@76.75.3.174, Quit: Leaving...) | |
| 22:52 | fosser_josh has joined IRC (fosser_josh!~prathames@02799a2d.bb.sky.com) | |
| 22:53 | fosser_josh has left IRC (fosser_josh!~prathames@02799a2d.bb.sky.com) | |
| 22:58 | fosser_josh has joined IRC (fosser_josh!~prathames@02799a2d.bb.sky.com) | |
| 23:03 | fosser_josh has left IRC (fosser_josh!~prathames@02799a2d.bb.sky.com) | |
| 23:12 | vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) | |
| 23:22 | hughessd has joined IRC (hughessd!~hughessd@173-164-117-109-Oregon.hfc.comcastbusiness.net) | |
| 23:29 | Damianos has left IRC (Damianos!~Damianos@adsl-070-145-074-043.sip.cha.bellsouth.net, Quit: Damianos) | |
| 23:30 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 23:38 | jtsop has joined IRC (jtsop!~quassel@athedsl-07209.home.otenet.gr) | |
| 23:41 | Matrix3000 has left IRC (Matrix3000!~Matrix300@rrcs-70-61-255-227.central.biz.rr.com) | |
| 23:49 | Gadi has left IRC (Gadi!~romm@ool-4571ca04.dyn.optonline.net, Ping timeout: 240 seconds) | |