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


Channel log from 9 November 2011   (all times are UTC)

00:14MrDoh has left IRC (MrDoh!~mrdoh@r74-192-178-144.htvlcmta01.hnvitx.tl.dh.suddenlink.net, Ping timeout: 248 seconds)
00:28Parker955_Away is now known as Parker955
00:56MrDoh has joined IRC (MrDoh!~mrdoh@r74-192-178-144.htvlcmta01.hnvitx.tl.dh.suddenlink.net)
01:00MrDoh has joined IRC (MrDoh!~mrdoh@r74-192-178-144.htvlcmta01.hnvitx.tl.dh.suddenlink.net)
01:12cliebow has joined IRC (cliebow!~cliebow@66.63.66.218)
01:5316WAATSL4 <16WAATSL4!~fernando@189.30.138.160> has quit IRC (Quit: Leaving)
01:53Damianos has joined IRC (Damianos!~Damianos@70.145.74.43)
02:11abeehc has left IRC (abeehc!~bob@2001:1938:1a3:0:216:41ff:fe2c:9b3c, Read error: Operation timed out)
02:16abeehc has joined IRC (abeehc!~bob@50.92.192.146)
02:18artista_frustrad has joined IRC (artista_frustrad!~artista_f@189.30.138.160)
02:34GodFather has joined IRC (GodFather!~rcc@d47-69-227-53.col.wideopenwest.com)
02:34rccGodFather_ has joined IRC (rccGodFather_!~rcc@d47-69-227-53.col.wideopenwest.com)
02:35GodFather has left IRC (GodFather!~rcc@d47-69-227-53.col.wideopenwest.com, Remote host closed the connection)
02:35GodFather has joined IRC (GodFather!~rcc@d47-69-227-53.col.wideopenwest.com)
02:52Damianos has left IRC (Damianos!~Damianos@70.145.74.43, Quit: Damianos)
03:12petre 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:21Damianos has joined IRC (Damianos!~Damianos@adsl-070-145-074-043.sip.cha.bellsouth.net)
03:34Damianos has left IRC (Damianos!~Damianos@adsl-070-145-074-043.sip.cha.bellsouth.net, Quit: Damianos)
03:40Parker955 is now known as Parker955_Away
03:43cliebow has left IRC (cliebow!~cliebow@66.63.66.218, Quit: Leaving)
03:45monkeydiver has joined IRC (monkeydiver!~de3legged@24.152.225.163.res-cmts.mtp2.ptd.net)
04:00GodFather has left IRC (GodFather!~rcc@d47-69-227-53.col.wideopenwest.com, Quit: Ex-Chat)
04:15petre has left IRC (petre!~petre@scheie.homedns.org, Quit: Leaving)
04:29fellowEntx has left IRC (fellowEntx!~fellowEnt@69.25.2.66, Read error: Connection reset by peer)
04:29fellowEntx has joined IRC (fellowEntx!~fellowEnt@69.25.2.66)
04:31jvin has joined IRC (jvin!~jvin@108-82-19-151.lightspeed.livnmi.sbcglobal.net)
04:49alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
05:08Matrix3000_ 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:32alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Read error: Operation timed out)
05:41staffencasa has left IRC (staffencasa!~staffenca@128-193-146-230.oregonstate.edu, Ping timeout: 260 seconds)
06:29alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
06:54chokesmaster has joined IRC (chokesmaster!~chokesmas@65.92.140.229)
06:56alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
06:56chokesmaster has left IRC (chokesmaster!~chokesmas@65.92.140.229, Client Quit)
06:57chokesmaster has joined IRC (chokesmaster!~chokesmas@bas5-sherbrooke40-1096584421.dsl.bell.ca)
07:04alkisg 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:10Gadi has left IRC (Gadi!~romm@ool-4571ca04.dyn.optonline.net, Read error: Connection reset by peer)
07:27Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.69)
07:28Gadi has joined IRC (Gadi!~romm@ool-4571ca04.dyn.optonline.net)
08:00cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
08:08cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 240 seconds)
08:19Matrix3000_ has left IRC (Matrix3000_!~Matrix300@cpe-184-57-1-218.columbus.res.rr.com, Quit: ~ Trillian Astra - www.trillian.im ~)
08:22cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
08:37cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 255 seconds)
08:42cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
08:49loather 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:03dobber has joined IRC (dobber!~dobber@89.190.199.210)
09:04toscalix 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:32Gremble has joined IRC (Gremble!~Ben@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com)
09:35garymc has joined IRC (garymc!~chatzilla@81.138.225.164)
09:45toscalix_ has joined IRC (toscalix_!~toscalix@212.170.226.171)
09:46toscalix has left IRC (toscalix!~toscalix@212.170.226.171, Ping timeout: 258 seconds)
10:04alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 255 seconds)
10:25vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 240 seconds)
10:40toscalix_ has left IRC (toscalix_!~toscalix@212.170.226.171, Read error: Connection reset by peer)
10:49lifeboy_ has joined IRC (lifeboy_!~roland@41.183.26.154)
10:54vmlintu has joined IRC (vmlintu!~vmlintu@dsl-hkibrasgw2-ff78c300-68.dhcp.inet.fi)
11:09abeehc has left IRC (abeehc!~bob@50.92.192.146, Ping timeout: 255 seconds)
11:15abeehc has joined IRC (abeehc!~bob@50.92.192.146)
11:16Damianos has joined IRC (Damianos!~Damianos@70.145.74.43)
11:27alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
12:06cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 258 seconds)
12:32Parker955_Away is now known as Parker955
12:46bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
12:52Parker955 is now known as Parker955_Away
12:57pingufan has joined IRC (pingufan!~rainer@goliath.hantsch.co.at)
12:58garymc 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:01Da-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:10mrcarrot 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:27dobber 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:38dobber has joined IRC (dobber!~dobber@89.190.199.210)
13:38
<pingufan>
Ah - ok. peek inti #kiwi-ltsp and count active users. ;)
13:39mrcarrot 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:41mgariepy 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:51dead_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:59pingufan has left IRC (pingufan!~rainer@goliath.hantsch.co.at, Remote host closed the connection)
14:26vmlintu has left IRC (vmlintu!~vmlintu@dsl-hkibrasgw2-ff78c300-68.dhcp.inet.fi, Ping timeout: 260 seconds)
14:46muppis has left IRC (muppis!muppis@viuhka.fi, Ping timeout: 245 seconds)
14:48muppis has joined IRC (muppis!muppis@viuhka.fi)
14:51Da-Geek has left IRC (Da-Geek!Da-Geek@nat/redhat/x-ccnosrnokkdtacck, Quit: Leaving)
14:58andygraybeal_ has joined IRC (andygraybeal_!~andy.gray@obsidian.casanueva.com)
14:58
<andygraybeal_>
:)
15:03jtsop has joined IRC (jtsop!~quassel@athedsl-07209.home.otenet.gr)
15:05
<Hyperbyte>
Andy!
15:16Matrix3000 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:16artista_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:28artista_frustrad has joined IRC (artista_frustrad!~artista_f@189.30.138.160)
15:29Damianos 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:38Gremble 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:57jtsop has left IRC (jtsop!~quassel@athedsl-07209.home.otenet.gr, Remote host closed the connection)
15:59artista_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:09fellowEntx 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:10loather 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:12artista_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:14Steve_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:16artista_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:23Steve_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:24staffencasa 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:29artista_frustrad has joined IRC (artista_frustrad!~artista_f@189.30.138.160)
16:30jvin 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:33artista_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:36dobber 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:46artista_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:48Damianos has left IRC (Damianos!~Damianos@adsl-070-145-074-043.sip.cha.bellsouth.net, Quit: Damianos)
16:51artista_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:04artista_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:08hughessd 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:55alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 260 seconds)
18:30vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi)
18:39alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
18:46komunista 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:09artista_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:11loather-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:20loather-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:30quietone 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:32loather-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:45loather-work has left IRC (loather-work!~khudson@68-25-27-54.pools.static.spcsdns.net, Ping timeout: 252 seconds)
19:47klausade has joined IRC (klausade!~klaus@cm-84.215.152.210.getinternet.no)
19:48mistik1_ has joined IRC (mistik1_!mistik1@unaffiliated/mistik1)
19:50
<Gadi>
ok
19:50
pushed
19:50mistik1 has left IRC (mistik1!mistik1@unaffiliated/mistik1, Ping timeout: 245 seconds)
19:50mistik1_ 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:51loather-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:05mistik1 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:06Parker955_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:08hughessd 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:09loather-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:10mistik1 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:36hughessd 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:41hughessd 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:52komunista 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:55Trixboxer 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:40jvin has joined IRC (jvin!~jvin@108-82-19-151.lightspeed.livnmi.sbcglobal.net)
22:01jvin has left IRC (jvin!~jvin@108-82-19-151.lightspeed.livnmi.sbcglobal.net, Ping timeout: 240 seconds)
22:02lifeboy_ has left IRC (lifeboy_!~roland@41.183.26.154, Quit: Time to go...)
22:02lifeboy has left IRC (lifeboy!~roland@41.183.26.154, Quit: Time to go...)
22:09andygraybeal has left IRC (andygraybeal!~andy.gray@obsidian.casanueva.com, Quit: Ex-Chat)
22:14jvin has joined IRC (jvin!~jvin@108-82-19-151.lightspeed.livnmi.sbcglobal.net)
22:23Damianos has joined IRC (Damianos!~Damianos@adsl-070-145-074-043.sip.cha.bellsouth.net)
22:35bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Read error: Operation timed out)
22:37Parker955 is now known as Parker955_Away
22:51dead_inside has left IRC (dead_inside!~dead_insi@76.75.3.174, Quit: Leaving...)
22:52fosser_josh has joined IRC (fosser_josh!~prathames@02799a2d.bb.sky.com)
22:53fosser_josh has left IRC (fosser_josh!~prathames@02799a2d.bb.sky.com)
22:58fosser_josh has joined IRC (fosser_josh!~prathames@02799a2d.bb.sky.com)
23:03fosser_josh has left IRC (fosser_josh!~prathames@02799a2d.bb.sky.com)
23:12vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net)
23:22hughessd has joined IRC (hughessd!~hughessd@173-164-117-109-Oregon.hfc.comcastbusiness.net)
23:29Damianos has left IRC (Damianos!~Damianos@adsl-070-145-074-043.sip.cha.bellsouth.net, Quit: Damianos)
23:30alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
23:38jtsop has joined IRC (jtsop!~quassel@athedsl-07209.home.otenet.gr)
23:41Matrix3000 has left IRC (Matrix3000!~Matrix300@rrcs-70-61-255-227.central.biz.rr.com)
23:49Gadi has left IRC (Gadi!~romm@ool-4571ca04.dyn.optonline.net, Ping timeout: 240 seconds)