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


Channel log from 12 April 2011   (all times are UTC)

00:15monteslu (~monteslu@ip68-109-170-79.ph.ph.cox.net) left irc: Read error: Connection timed out
00:16monteslu (~monteslu@ip68-109-170-79.ph.ph.cox.net) joined #ltsp.
00:29vagrantc (~vagrant@c-24-21-191-93.hsd1.or.comcast.net) left irc: Quit: leaving
00:39ogra_ (~ogra@ubuntu/member/ogra) left irc: Read error: Operation timed out
00:41Gremble (~Ben@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com) joined #ltsp.
00:49viks (ca8a720f@gateway/web/freenode/ip.202.138.114.15) joined #ltsp.
00:49
<viks>
#ulteo
00:53ogra_ (~ogra@p5098ed03.dip0.t-ipconnect.de) joined #ltsp.
00:57Trixboxer (~Trixboxer@office.supportdepartment.net) joined #ltsp.
01:03
<viks>
any body know how to give user to access through domain login
01:03
in pxe boot
01:05cyberorg (~cyberorg@opensuse/member/Cyberorg) left irc: Quit: Leaving
01:16bobby_C (~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) joined #ltsp.
01:17ogra_ (~ogra@p5098ed03.dip0.t-ipconnect.de) left irc: Read error: Operation timed out
01:23ogra_ (~ogra@p5098ed03.dip0.t-ipconnect.de) joined #ltsp.
01:29dlezcano (~dlezcano@AToulouse-159-1-58-152.w92-134.abo.wanadoo.fr) left irc: Ping timeout: 258 seconds
01:37cyberorg (~cyberorg@opensuse/member/Cyberorg) joined #ltsp.
01:50viks (ca8a720f@gateway/web/freenode/ip.202.138.114.15) left irc: Ping timeout: 252 seconds
01:53bobby_C (~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) left irc: Remote host closed the connection
02:00bobby_C (~bobby@85.124.22.227) joined #ltsp.
02:24monteslu (~monteslu@ip68-109-170-79.ph.ph.cox.net) left irc: Ping timeout: 246 seconds
02:24monteslu (~monteslu@ip68-109-170-79.ph.ph.cox.net) joined #ltsp.
02:36viks (ca8a720f@gateway/web/freenode/ip.202.138.114.15) joined #ltsp.
02:36
<viks>
i am not able to do ltsp kisok in karmic ubuntu is there any bug in that
02:36dlezcano (~dlezcano@nat/ibm/x-glqgunxbquvbuzzj) joined #ltsp.
02:36
<viks>
alkisg : tell me
02:37
alkisg : it is showing ltsp installation ended abnormally
02:42alkisg (~alkisg@ubuntu/member/alkisg) left irc: Quit: Leaving.
02:43
<Hyperbyte>
Awwwe
03:10viks (ca8a720f@gateway/web/freenode/ip.202.138.114.15) left irc: Ping timeout: 252 seconds
03:19Gremble (~Ben@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com) left irc: Remote host closed the connection
03:31LoveStorm (Storm@217.18.70.231) left irc: Read error: Operation timed out
04:04
<Trixboxer>
:)
04:15LoveStorm (~Storm@217.18.70.231) joined #ltsp.
04:15alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp.
04:20
<Hyperbyte>
Hey alkisg. :-)
04:20
And Trixboxer. :-)
04:22
<alkisg>
Hi all
04:22
<Trixboxer>
Hi guys
04:22
<Hyperbyte>
Could you help me a bit more with my USB drive problem?
04:23
I've tried running the commands you gave me, but I can't interpret the output. I'm quite new to udev...
04:23
I have found some new information though. If I have the USB DVD drive connected while the terminal starts up, it detects it fine. Mounts, umounts perfectly when I insert/remove a CD.
04:24
If I unplug it while the terminal it already running, it doesn't get mounted.
04:29
I have gathered the following info: http://local.recreatie-zorg.nl/jan/udevadm-monitor.txt http://local.recreatie-zorg.nl/jan/udevadm-info-scd0.txt http://local.recreatie-zorg.nl/jan/udev-ltsp-rules.txt
04:31
(two lines above should read 'plug' rather than 'unplug')
04:32* alkisg doesn't ever use localdevs so he can't help. Hyperbyte, do file a bug about it with the info you gathered, or mail the ltsp-discuss mailing list.
04:32
<Hyperbyte>
Alright. :) Thanks.
05:16shawnp0wers (~Adium@linuxjournal/staff/shawnp0wers) joined #ltsp.
05:18highvoltage (~highvolta@ubuntu/member/highvoltage) left irc: Quit: Lost terminal
05:33dlezcano (~dlezcano@nat/ibm/x-glqgunxbquvbuzzj) left irc: Ping timeout: 240 seconds
05:51dlezcano (~dlezcano@nat/ibm/x-iapuuqvqvvkdfzmj) joined #ltsp.
05:53highvoltage (~highvolta@ubuntu/member/highvoltage) joined #ltsp.
05:56
<Hyperbyte>
If anyone stumbles into the same problem as me (DVD drive only mounting as localdev when plugged in as boot)... I've managed to work around this by adding 'auto' at the end of the RUN command in
05:57
.. in /opt/ltsp/i386/etc/udev/rules.d/88-ltsp.rules for "other drives"
05:57
Not sure if this has any concequences for USB sticks or harddrives, but it seems to overcome the USB DVD/CD drive problem.
05:58
<alkisg>
Hyperbyte: the best thing to do is to file a bug and post your workaround
05:58
Then it can be reviewed and submitted upstream for later versions, and for everyone
05:59
Not only to the persons visiting the channel now...
05:59
Either a bug report in launchpad, or a mail in the ltsp-discuss mailing list
06:16
<Hyperbyte>
alkisg: I'm filing a bug in Launchpad actually, don't worry. =)
06:16
I just figured I'd share my findings here as well, because I posed the question here as well.
06:17
If I recall correctly this chatroom gets logged on Google as well, so someone could stumble into it while looking for a solution to the same problem.
06:25
https://bugs.launchpad.net/ltsp/+bug/758751 There you go. :-)
06:25
Just took me a while to get all the info straightened out and double check that my workaround really fixes it.
06:36primeministerp (~ppouliot@64.119.153.82) joined #ltsp.
06:40
<alkisg>
I don't worry, I don't even use localdevs :) It was just a suggestion
06:42
<_UsUrPeR_>
Has anybody else had any problems getting thin client sound working in 11.04?
06:46
<Hyperbyte>
alkisg: and it was a good one. :P
06:46
<alkisg>
:)
06:46
<Hyperbyte>
Thanks, have a good evening
07:05dlezcano (~dlezcano@nat/ibm/x-iapuuqvqvvkdfzmj) left irc: Read error: Operation timed out
07:13brunolambert (~brunolamb@2001:470:8829:1000:221:6aff:fe94:21d8) joined #ltsp.
07:20Roasted (~jason@206.82.22.190) joined #ltsp.
07:24primeministerp (~ppouliot@64.119.153.82) left irc: Ping timeout: 260 seconds
07:27primeministerp (~ppouliot@64.119.153.82) joined #ltsp.
07:37bobby_C (~bobby@85.124.22.227) left irc: Ping timeout: 260 seconds
07:41mistik1 (mistik1@unaffiliated/mistik1) left irc: Read error: Connection reset by peer
07:42mistik1 (mistik1@unaffiliated/mistik1) joined #ltsp.
07:50alkisg (~alkisg@ubuntu/member/alkisg) left irc: Quit: Leaving.
07:58dobber (~dobber@89.190.197.77) left irc: Remote host closed the connection
07:59primeministerp (~ppouliot@64.119.153.82) left irc: Read error: Connection reset by peer
08:01primeministerp (~ppouliot@64.119.153.82) joined #ltsp.
08:05dlezcano (~dlezcano@AToulouse-159-1-58-152.w92-134.abo.wanadoo.fr) joined #ltsp.
08:16staffencasa (~staffenca@128.193.148.149) joined #ltsp.
09:16primeministerp (~ppouliot@64.119.153.82) left irc: Read error: Connection reset by peer
09:23Gremble (~Ben@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com) joined #ltsp.
09:40
<andygraybeal>
okay, this is going to sound like spam, but it isn't! i don't know if any of you have run across it yet, but i recently just found 'zentyal', formerly ebox ... it's a small business server, much like microsoft's backoffice. they have a bounty out to develop LTSP integration into their system.
09:40
http://pledgie.com/campaigns/15114
09:41
it's a bunch of integrated applications running on ubuntu and running the ldap directory server
09:43
<Roasted>
I've ran Zentyal for some services in the past. It's a pretty good platform to use.
09:43
I recently tried to utilize their Radius plugin, but their Radius plugin is just a bad joke. Their other stuff is pretty nice though.
09:44
plus I think zentyal is officially supported by canonical, which is a plus of course
10:09Gremble (~Ben@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com) left irc: Quit: I Leave
10:18otavio (~otavio@debian/developer/otavio) left irc: Ping timeout: 260 seconds
10:18otavio (~otavio@debian/developer/otavio) joined #ltsp.
10:19chupacabra (~chupacabr@cpe-70-112-10-45.austin.res.rr.com) left irc: Ping timeout: 240 seconds
10:24chupacabra (~chupacabr@cpe-70-112-10-45.austin.res.rr.com) joined #ltsp.
10:44Nick change: zz_evil_root -> evil_root
10:51shawnp0wers (~Adium@linuxjournal/staff/shawnp0wers) left irc: Quit: Leaving.
11:18alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp.
11:23Ahmuck (~quietly@p178n22.ruraltel.net) left irc: Remote host closed the connection
11:23Trixboxer (~Trixboxer@office.supportdepartment.net) left irc: Quit: "Achievement is not the end, its the beginning of new journey !!!"
11:25Ahmuck (~quietly@p178n22.ruraltel.net) joined #ltsp.
11:34dlezcano (~dlezcano@AToulouse-159-1-58-152.w92-134.abo.wanadoo.fr) left irc: Ping timeout: 240 seconds
11:54RiXtEr (~blah@72-161-236-101.dyn.centurytel.net) left irc: Ping timeout: 260 seconds
11:54RiXtEr (~blah@99-195-108-82.dyn.centurytel.net) joined #ltsp.
11:59RiXtEr (~blah@99-195-108-82.dyn.centurytel.net) left irc: Ping timeout: 252 seconds
11:59vagrantc (~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) joined #ltsp.
12:00RiXtEr (~blah@72-161-220-243.dyn.centurytel.net) joined #ltsp.
12:11vagrantc (~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) left irc: Ping timeout: 258 seconds
12:21RiXtEr (~blah@72-161-220-243.dyn.centurytel.net) left irc: Ping timeout: 258 seconds
12:22RiXtEr (~blah@72-161-220-243.dyn.centurytel.net) joined #ltsp.
12:32alkisg (~alkisg@ubuntu/member/alkisg) left irc: Quit: Leaving.
12:35Roasted (~jason@206.82.22.190) left irc: Ping timeout: 246 seconds
12:42andygraybeal (~andy.gray@obsidian.casanueva.com) left irc: Remote host closed the connection
13:13RiXtEr (~blah@72-161-220-243.dyn.centurytel.net) left irc: Ping timeout: 276 seconds
13:13RiXtEr (~blah@75-121-248-251.dyn.centurytel.net) joined #ltsp.
13:18brunolambert (~brunolamb@2001:470:8829:1000:221:6aff:fe94:21d8) left irc: Ping timeout: 260 seconds
13:24
<stgraber>
I just released ltsp 5.2.7 to fix a critical bug in Ubuntu Natty (permission issue on initrd and kernel)
13:24
it'll be available in Ubuntu quite soon (pending code review). If you want the tarball before that, just ping me.
13:28
<roasted__>
When using the shutdown_time option in lts.conf, how long afterwards would the systems auto-halt upon boot? I had a lab shutdown at 3 and I turned them on at 3:20 for something unrelated and they all were halting immediately when starting up.
13:51Nick change: evil_root -> zz_evil_root
14:04Gadi_android (~yaaic@184.240.82.11) joined #ltsp.
14:07sep (~sep@40.211.jostedal.no) left irc: Ping timeout: 246 seconds
14:08sep (~sep@40.211.jostedal.no) joined #ltsp.
14:09Gadi_android (~yaaic@184.240.82.11) left irc: Ping timeout: 260 seconds
14:11bobby_C (~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) joined #ltsp.
14:27Mip5 (~chatzilla@75-148-124-137-colorado.hfc.comcastbusiness.net) joined #ltsp.
14:27alexqwesa (~alex@alexo-veto.broker.freenet6.net) left irc: Read error: Operation timed out
14:28
<Mip5>
Hey Gang - is there a good documentation for setting up auto shutdown on ltsp? I'm running ubuntu 10.04
14:30alexqwesa (~alex@alexo-veto.broker.freenet6.net) joined #ltsp.
14:58ogra_ (~ogra@p5098ed03.dip0.t-ipconnect.de) left irc: Ping timeout: 240 seconds
14:58
<Mip5>
Gotta run - take care everyone. M
14:58Mip5 (chatzilla@75-148-124-137-colorado.hfc.comcastbusiness.net) left #ltsp.
14:58ogra_ (~ogra@p5098ed03.dip0.t-ipconnect.de) joined #ltsp.
15:01RiXtEr (~blah@75-121-248-251.dyn.centurytel.net) left irc: Ping timeout: 276 seconds
15:02RiXtEr (~blah@75-121-251-74.dyn.centurytel.net) joined #ltsp.
15:07shawnp0wers (~spowers@linuxjournal/staff/shawnp0wers) joined #ltsp.
16:27moldy (~rene@unaffiliated/moldy) left irc: Ping timeout: 248 seconds
16:27moldy (~rene@unaffiliated/moldy) joined #ltsp.
16:37bobby_C (~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) left irc: Ping timeout: 246 seconds
16:43staffencasa (~staffenca@128.193.148.149) left irc: Quit: Leaving
17:30MorningSon (~MorningSo@cpe-72-181-35-91.satx.res.rr.com) joined #ltsp.
17:51artista_frustrad (~artista_f@187.7.151.105) left irc: Quit: Leaving
18:12shawnp0wers (~spowers@linuxjournal/staff/shawnp0wers) left irc: Quit: Leaving.
18:31shawnp0wers (~spowers@linuxjournal/staff/shawnp0wers) joined #ltsp.
18:48shawnp0wers (~spowers@linuxjournal/staff/shawnp0wers) left irc: Quit: Leaving.
19:07Nick change: zz_evil_root -> evil_root
19:13Nick change: evil_root -> zz_evil_root
19:30roasted__ (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) left irc: Read error: Connection reset by peer
19:32alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp.
19:33Roasted (~jason@unaffiliated/roasted) joined #ltsp.
19:34
<alkisg>
Roasted: did that change that vagrantc suggested fix your time issue?
19:34
(removing the & at the end)
19:35
<Roasted>
alkisg, I believe so. He suggested to me 2 things, one from Gadi from 3 weeks back and one he recommended on the fly.
19:36
alkisg, If you have a minute I can explain what I saw in my testing.
19:36
<alkisg>
Sure
19:36
I think the fix from Gadi is the one that got committed upstream
19:36
<Roasted>
the ironic thing is I think I had issues with that
19:36
I had a few boxes that just SAT at the loading screen
19:37
<alkisg>
Some fellow teachers here see the same problems with time sync here, so I'm thinking about backporting that fix...
19:38
<Roasted>
so here's Gadi's fix - ntpdate $TIMESERVER; hwclock --systohc --${HWCLOCK:-"utc"} --noadjfile
19:38
here's what vagrantc suggested - ntpdate $TIMESERVER && hwclock --systohc --${HWCLOCK:-"utc"} --noadjfile || true
19:38
Gadi's fixed worked with the time, but sometimes I had box's just sit at the tsplash screen
19:38
with Ubuntu listed there and the 5 dots going across as if it was loading
19:39
It wasn't often. I tested it in my two small labs (9 in one area, 8 in another) and one time I had ALL of them do it, but after tha Ic ould only get 1 at a time to do it.
19:39
Either way, the time acted predictably in every scenario.
19:39
I put Vagrantc's suggestion in with the true statement at the end and I wasn't able to get them to foul up. I mean... I must have rebooted the 9 and 8 count lab about 20 times today. I jjust tried to make them freeze.
19:40
But each time they came up. Sometimes the time was off by a hair from 1 box to another... like I might boot up 9 systems and have 1 that is 20 seconds off. But it's MUCH better than it was. Time was 100% more predictable.
19:40
<alkisg>
Oh. Strange results.
19:41
<Roasted>
I was going to wait a week to say something so that way users in the labs who reboot them, power them on, etc., might put it through their paces and report to me if any issues come up at any time of them powering on and fully booting up without issue.
19:41
<alkisg>
It sounds like it still needs a better fix
19:41
<Roasted>
vagrantc also suggested to me his idea may take longer to boot.
19:41
so... I used a stopwatch to time it :P
19:41
<alkisg>
Haha
19:41
<Roasted>
it was about a .75 second difference. hardly anything to sneeze at.
19:42
<alkisg>
If it's easy for you to test, I can tell you a different line that doesn't have this delay
19:42
<Roasted>
It's very easy for me to test. What do you suggest?
19:42
<alkisg>
...I'm proposing that because it's easy for you to reproduce the problem, while here for me it always works :(
19:42
<Roasted>
I've said it before... if my limited knowledge can help, I'd certainly like to. What do you have in mind?
19:43
<alkisg>
sh -c "ntpdate $TIMESERVER && hwclock --systohc --${HWCLOCK:-"utc"} --noadjfile || true" &
19:43
<Roasted>
Is it possible you could explain to me the differences between your suggestion above and vagrantc's?
19:43
<alkisg>
Of course
19:44
They do exactly the same thing, but mine calls another shell to do it, and puts that shell in the background
19:44
So it doesn't have that .75 secs delay
19:44
<Roasted>
what about the "race" you guys weer speaking of... what if one thing takes too long?
19:44
Does it have a failsafe or would it hang the system?
19:44
<alkisg>
But, there's a chance that it might have the same problem as the initial line that caused the race
19:45
That race wasn't pinpoined, we're not sure what causes it
19:45
If it's a subshell that causes it, i.e. (command) &, then sh -c 'command' wouldn't have the problem
19:45
<Roasted>
The race refers to 2 things happening at once. One being (whatever else) and the other being ntpdate, correct?
19:46
<alkisg>
If there's something external that kills the initscript commands that delay too long, then it would have the same issue
19:46
<Roasted>
and if everything else completes before ntpdate, it just ignores ntpdate, boots up, and hello incorrect time.
19:46
<alkisg>
Something like that, yes. But we don't know exactly what's the "other thing".
19:47
<Roasted>
Can't you put an entry that halts the system from fully booting for (up to) 5 seconds and/or until ntpdate successfully completes?
19:47
<alkisg>
So I hope that with the `sh -c "command" &` change, you'll have the same results but without the .75 sec delay
19:47
<Roasted>
That way if ntpdate stalls, it has a 5 second window to complete or else the system bypasses it.
19:47
<alkisg>
ntpdate supposedly automatically stops after 1 sec
19:48
And with vagrantc's fix, we wait for it to finish
19:48
But I'm worried about dns timeouts and other networking problems that take a lot longer than 1 sec
19:48
<Roasted>
so with vagrantc's fix, if ntpdate for some reason NEVER responds... we never boot
19:48
<alkisg>
Theoretically ntpdate stops after 1 sec, even if it has problems
19:48MorningSon (~MorningSo@cpe-72-181-35-91.satx.res.rr.com) left irc: Ping timeout: 276 seconds
19:49
<alkisg>
In practice I'm worried about dns timeouts etc delaying it longer
19:49
<Roasted>
I see. I think I misunderstood how ntpdate was working during the bootup script.
19:49
I thought ntpdate was like an active process that initializes and thereby runs full bore during the duration of the system uptime.
19:49
<alkisg>
But I don't think it'll stop "for ever" even on extreme problems
19:49
<Roasted>
But you're making it sound like ntpdate initializes and shuts off immediately during boot up, thereby finalizing the boot process without ntpdate being there, however, recently ran.
19:49
Am I accurate on that?
19:50
<alkisg>
ntpdate is not a daemon, if that's what you're asking
19:50
It runs and stops after that 0.75 sec that you're seeing
19:50
Then if you `ps` you won't see it
19:50
<Roasted>
is it basically doing an ntpdate 10.52.1.8 during the bootup?
19:50
like I did manually?
19:50
<alkisg>
Yes
19:51
<Roasted>
I see, I see
19:51
beginning to make more sense now
19:51
Well, I'll tell ya what... if I get an open window in one of the two smaller labs (8 or 9 count) I'll tes each scenario.
19:51
We of course knows what happens with the default code... otehrwise I wouldn't have bitched about it endlessly :P
19:51
<alkisg>
Hehe
19:51
The problem is that I can't reproduce it here, so I can't test myself
19:52
<Roasted>
But I'll put in gadi's suggestion, vagrantc's, and your's, and reboot each scenario several times and document what I find and what time stamps the systems have upon bootup (whether accurate or off, etc)
19:52
<alkisg>
vagrantc's solution is a "superset" of Gadi's
19:52
<Roasted>
I've had good luck at reproducing it, and like I said, so far vagrantc's was the one that booted the most without issue. (in fact his never had an issue)
19:52
<alkisg>
So you don't need to test Gadi's solution
19:52
<Roasted>
Gadi's only gave me an issue one out of the 20 times I booted the lab.
19:52
But one time was enough to raise an eyebrow when it happened to ALL the systems.
19:53
How does Gadi's and Vagrantc's differ? Does Gadi's still race?
19:53
<alkisg>
The specific ltsp initscript that calls ntpdate is ran with `set -e`
19:53
That means, "abort if any command reports a problem"
19:54
So if ntpdate for some reason can't contact the server, all the rest of the script is aborted
19:54
Hmmmm actually maybe no
19:54
Let me see
19:54
<stgraber>
alkisg: if you are talking of what's currently upstream, isn't there a || true on that line ?
19:55
<alkisg>
stgraber: yes, that's "vagrantc's" solution, roasted asked about the previous, "Gadi" solution
19:55
Roasted: hmm no, even Gadi's solution shouldn't fail, as we call it as "set_time || true"
19:56
<Roasted>
you're saying "set_time || true" is within his line?
19:56
<alkisg>
It goes like this:
19:56
boot process calls the ltsp initscript "ltsp-client-setup"
19:57
Inside this there's this line: "set_time || true"
19:57
That "set_time" is a function inside the script
19:57
Inside that function there's the line that you're changing
19:57
<Roasted>
ahh
19:57
gotcha
19:57
<alkisg>
So what I'm saying is that while vagrantc's version is a little better than Gadi's, they shouldn't be able to cause different results
19:58
So I'm unable to explain your observations
19:58
<Roasted>
like I said, Gadi's worked, but that one time the systems just hung at the boot screen I was like, okay, I'd rather have improper time than non booting systems...
19:58
but when I rebooted them a dozen times, they worked
19:59
so like you, while Gadi's worked for me, Vagrantc's just worked a little (LITTLE) more predictably.
19:59
<alkisg>
Hmm. OK. So, I'll assume that that "LITTLE better" was pure chance
19:59
<Roasted>
it very well could have been.
20:00
I have to be fair too, when I am working on things, I'm doing about a dozen at once.
20:00
I recall being remoted into 3 servers from my laptop while I was working on this lab...
20:00
so tomorrow if I have a lab open I'll test it for a good hour or so and try out each scenario several times.
20:00
Documenting every step of the way, what I'm doing, etc. I'll post up lts.conf's if necessary and throw my findings in a google doc and share it out at he end of the day.
20:01
<alkisg>
And maybe there's a chance that that hung wasn't related to ntpdate. If it was, you should be still experiencing that, even infrequently
20:01
<Roasted>
Then maybe you guys can pick it apart and piece together what I was seeing vs what was difference from all 3 of your ideas.
20:01
This is the way I have it broken down right now: http://tinypaste.com/6c2cdb
20:01
original line was obviously tested out the tailpipe, but the rest I'll try more tomorrow
20:02
<alkisg>
Ah
20:02
Let me change my line a bit
20:02
<Roasted>
go for it
20:02
If you want me to test multiple lines from you, toss them up so I can take them in my docs for tomorrow
20:03
<alkisg>
sh -c "ntpdate $TIMESERVER && hwclock --systohc --${HWCLOCK:-utc} --noadjfile || true" &
20:03
I just removed the quotes around utc
20:03
<Roasted>
what bearing would that have?
20:04
<alkisg>
Just better syntax, nothing serious
20:04
<Roasted>
gotcha
20:04
<alkisg>
It actually makes no difference at all, it's just easier to read
20:05
<Roasted>
hahaha, good stuff
20:05
<alkisg>
(because nesting quotes within quotes can be a little unreadable at times)
20:05
<Roasted>
well I'll give this a whirl tomorrow and we'll go from there
20:05
<alkisg>
I'd hope to see exactly the same results that you're seeing now, but without the 0.75 sec delay
20:05
<Roasted>
yeah - I'll make a note to time it as well.
20:06
My time results are from the second the boxs get an IP from PXE boot titll I see the login screen.
20:06
It went from 32.75 to 33.42 or something like that.
20:06
<alkisg>
No need to bother with timing though
20:06
<Roasted>
I'll time it if its brutally longer.
20:06
Noticably longer.
20:07
<alkisg>
The change is predictable. Yup, do it if it takes e.g. 20 secs longer
20:07
<Roasted>
appreciate your continued effort with this
20:07
<alkisg>
"My" version shouldn't be able to delay the boot process even if ntpdate completely hanged
20:08
<Roasted>
pending what my results are, would it be changed accordingly upstream?
20:09
<alkisg>
Yes
20:09
<Roasted>
good stuff
20:09
<alkisg>
I'd send it to the other teachers here first though, to double cross the results
20:09
<Roasted>
of course
20:09
<alkisg>
As we still don't know what causes the race condition :(
20:10
<Roasted>
ah well, if you can at least bandage the consequences of the race condition to be more bearable that's at least progression
20:10
I wasn't aware this was an issue that was made aware of already.
20:10
I was confused when vagrantc suggested that I was caught by it.
20:11
But then a few others chimed in with "oh yeah's" and whatnot.
20:11
<alkisg>
Right
20:11
<Roasted>
It seems like this also cured my shutdown issue I was having.
20:11
Some of the labs didn't all shut off. It was scatered.
20:11
Today the lab of 8 all powered off.
20:12
However, if I power them on, they automatically halt even tho it was 15 or 20 minutes past their halt time, but they at least all powered off which was a start.
20:12
<alkisg>
Erm... if your local time is not *guaranteed* to be valid, I wouldn't use automatic shutdown if I were you :)
20:12
<Roasted>
it was just something I was testing
20:12
<alkisg>
So until we completely solve the time issue, you might want to avoid shutdown time
20:12
<Roasted>
mostly because some irresponsible teachers leave labs turned on al l night/weekend
20:13
so when I saw the shutdown time thing I figured it could be a nice forceful "take that"
20:13
but we're also not full scale with LTSP
20:13
Does shutdown time look at the time on the login screen?
20:14
<alkisg>
On login and from a cron job
20:14
I don't know all the details though, we shut them down from the server here
20:14
<Roasted>
oh, really?
20:15
how so?
20:15
<alkisg>
We have developed something like italc, for remote control, boot, shutdown, updates etc
20:15
<Roasted>
ah
20:15
italc is another thing I need to get running...
20:16
it's been a minor headache for a little bit
20:16
<alkisg>
It crashed much too often for us, that's why we developed another app to replace it
20:16
<Roasted>
is that app just internal to you guys?
20:16
<alkisg>
No, it's open source, but we didn't have time to internationalize it so it's in greek for the time :)
20:17
<Roasted>
lol
20:17
well maybe some greek language classes are in order :P
20:17
<alkisg>
1-2 US teachers wanted to use it though so they translated a version of it in english
20:17
So try italc, and if it crashes too much and it's unusable, ping me to send you that english .deb
20:18
<Roasted>
Sounds good. My issue with italc hasn't been crashes. I haven't been able ot detect the clients so far.
20:18
I haven't tried italc with LTSP yet though. Just Ubuntu-Windows and Windows-Windows.
20:18
<alkisg>
`sudo apt-get install italc-master` on the ltsp server, and logoff
20:18
That should make it see all ltsp clients automatically
20:18
<Roasted>
is italc client already on ltsp clients?
20:18
<alkisg>
They run it on logon
20:19
<Roasted>
what about he keys?
20:19
the
20:19
<alkisg>
They login on the server, so they use the server keys. No need to copy them
20:19
<Roasted>
ah, duur
20:19
even to the chroot?
20:19
<alkisg>
There's an alternate method of installation that involves installing italc in the chroot. That one needs key copying
20:19
<Roasted>
is it required?
20:20
<alkisg>
The advantage of the first is simplicity + less ram on the client (as it runs on the server)
20:20
<Roasted>
nice, nice
20:20
<alkisg>
The advantage of the second is that you can control the clients even if they're sitting in the login screen
20:20
(while in the first case you can only see them *after* they logon)
20:20
<Roasted>
Is there no way from the server terminal to shutdown all clients connected?
20:20
@ login screen that is
20:21
<alkisg>
With the default ltsp installation, no, the ltsp clients don't listen for external commands
20:21
Of course you can then put scripts to do anything you want, exactly as you want it
20:21
<Roasted>
but if I get italc running I might be good anyway
20:21
you mean like a cron job in the chroot?
20:21
poweroff @ 3pm etc
20:21
<alkisg>
that's what shutdown_time does
20:22
<Roasted>
oh
20:22
<alkisg>
It doesn't help if you don't have the correct time though
20:22
<Roasted>
well, as of today, I've had the correct time :P
20:22
but I get what you mean. I'll sit tight with it for now.
20:22
<alkisg>
There are many methods. Some people install ssh in the chroot. But it does have some security imolications
20:22
p
20:22
<Roasted>
But I have to wonder, what's up with them auto halting? Is that normal?
20:23
<alkisg>
No idea, I haven't checked that part of the code. We even disable cron here, so that automatic updates etc don't run on the thin clients
20:23
<Roasted>
automatic updates shouldn't come up to non root users though, I thought
20:23
<alkisg>
They run from cron
20:23
<Roasted>
oh
20:24
<alkisg>
As `update-apt-xapian-index` and a lot of other automatic stuff
20:24
<Roasted>
gotcha, gotcha
20:24
good stuff
20:25
<alkisg>
OK, /me tries to make a "reboot vbox client until the time is wrong" script...
20:25
<Roasted>
lol...
20:26
We had another meeting today to discuss the recent usage of LTSP and Ubuntu in our environment.
20:26
My boss asked me to talk about the product and what it's been doing, etc.
20:26
I was really at a loss for words. All I could say, word for word, "The damn thing just plain works."
20:26
It was a short, yet approving meeting. ;)
20:27
<alkisg>
Hehe
20:27
"except for fat clients. They don't work at all :P"
20:27
<Roasted>
Oh they work quite fine.
20:27
But that triple authentication was a pita.
20:28
<alkisg>
Did you setup the multiple ltsp servers that you were thinking about?
20:28
<Roasted>
I have 3 right now
20:28
<alkisg>
1 server in each row or something?
20:28
<Roasted>
oh no
20:28
my boss caved and got me ram
20:28
see, it's a crock right now. in Pennsylvania USA we got a new governor, who cut educational spending tremndously.
20:29
<alkisg>
How many clients does each server serve now?
20:29
<Roasted>
Granted, our last governor was a moron and gave money to schools as if it was free.
20:29
So buying things is hard to do, such as 12gb of 300 dollar RAM for an experiment.
20:29
But he caved and bought it with great results.
20:29
My setups are as follows...
20:29
<alkisg>
Hehe, hiring someone to solve you the authentication problem would come cheaper :D
20:30
<Roasted>
30 clients - Edubuntu 10.10 64 bit - one GB NIC - Two Xeon 2.66ghz dual core processors (4 cores total) w/ 14GB RAM (12 new + 2 remaining)
20:30
9 clients - Edubuntu 10.10 64 bit - one GB NIC - Dual Core AMD 2.0ghz processor, 4gb RAM.
20:30
8 clients - Edubuntu 10.10 64 bit - One GB NIC - Quad Core Intel processor - 6gb RAM
20:31
<alkisg>
I see. In my experience, even the first server wouldn't handle more than 6-7 students watching youtube :(
20:31
<Roasted>
The Quad Core box was used for Windows MultiPoint Server 2010 with HP thin clients. It was just a bad joke all around. So my boss told me to "format that shit" and get LTSP running on it, so I did.
20:31
The Dual Core box is just a regular desktop, nothing special.
20:31
<alkisg>
That's why we invested in fat clients, were we had the equipment for it
20:32
<Roasted>
That's why I want to look into localapps for flash and FF for that lab.
20:32
However, I will say this...
20:32
I tried to kill that server.
20:32
<alkisg>
With localapps they'll still have the authentication problem
20:32
<Roasted>
I opened up every application that's frequently used in that lab.
20:32
ah shit..
20:32
scratch that then
20:33
I opened up Firefox, Gimp, Inkscape, Reader, Audacity, VLC, Writer, Spreadsheet, Impress, and I was streaming video. On every. single. client.
20:33
While I hit 10gb usage on the server RAM and made the 4 cores work pretty hard, general usage didnd't feel slow at all.
20:33
I could still open new Firefox instances without any lag time.
20:33
Streaming videos from CNET.com, yes, it was choppy and laggy.
20:33
<alkisg>
1-2 more NICs might help there
20:33
<Roasted>
But I think that's just the architecture of flash. Every thin client system I've used, whether Linux or Windows based, has done the exact same thing
20:34
<alkisg>
Yes flash sucks as a video playback method
20:34
Both in cpu + bandwidth
20:35
<Roasted>
Remind me - why would localapps with Firefox still have the uathentication issue if the authentication issue is using nautilus with windows file servers?
20:36
<alkisg>
If one has hd monitor resolution and tries to watch a 320x200 video full screen, flash will eat up all the CPU plus *more* than 1 Gb of bandwidth. All that for a single client.
20:37
You're using gvfs (nautilus) to access the share. That ~/.gvfs directory isn't accessible from the localapps as it doesn't really exist on the file system, it's something like an "addon" to the file system that only exists within the user processes on the server
20:38
So the localapps, which access the user home with sshfs, won't be able to see that directory, they'll need to remount it
20:38
<Roasted>
ahhhhh
20:38
yeah I remember now
20:38
<alkisg>
So if a user tries to save something from firefox directly to the nautilus share, he won't be able to
20:38
He'll need to save it to another location, and then use nautilus to move it to the nautilus share
20:39
Of course you could do that with fat clients as well (moving with nautilus)
20:39
<Roasted>
I think I'll begin to do a little more digging on the authentication/fat client thing once I'm sure the time issue is solved.
20:39
I guess I had low expectations of thin clients versus fat clients when I switched over.
20:40
but I can really, really pound that server and it just smiles and gives me what applications I click on nearly instantly.
20:40
flash, yes... issues... but that's flash
20:40
everything else is just flawless
20:40
<alkisg>
There are many other apps with problems on thin clients
20:40
<Roasted>
but not fat?
20:41
<alkisg>
3d apps, impress, anything that requires a lot of multimedia straggles with thin clients
20:41
Fat clients are like local installations, no difference
20:41
If it works on a standalone installation, it works on fat too
20:41
<Roasted>
right. I just meant in regard to "other" issues like the auth thing
20:41
<alkisg>
Again, same as standalone
20:42
Think of live cds
20:42
<Roasted>
stand-alone installs have no authentication issues like fat clients do
20:42
of the issue I experienced
20:42
<alkisg>
They do
20:42
<Roasted>
nope :)
20:42
<alkisg>
If you boot a live cd, you can't access the domain
20:42
<Roasted>
live cd, yes
20:42
stand alone install, no
20:42
<alkisg>
(06:42:00 AM) alkisg: Think of live cds
20:42
<Roasted>
gotcha :P
20:42
<alkisg>
OK let's not go back to that subject again :)
20:43
<Roasted>
haaa, it's a dead horse anyway my friend
20:43
but we'll get there. I'll do some digging as time frees up and if it can get figured out, perhaps it can be published in documentation somewhere.
20:43
for now the thin client solution is just perfect so I'll roll with it in production for now.
20:43
I do have to ask something though
20:44
in the future will you guys actively support thin and fat clients, or do you anticipate one or the other being more common in the long run?
20:44
<alkisg>
Of course. That's what I like most about LTSP, it's customizable to every site's needs
20:45
Difficult question
20:45
Most devs in LTSP care about thin clients and use them in production somewhere
20:46
Personally I only use thin clients for old hardware, and switch to fat whenever the equipment supports it
20:46
<Roasted>
so you don't see thin clients as being the future, or fat clients as being the future.
20:46
<alkisg>
I think both have a future
20:46
Thin clients are very easy to administer, and they're perfect for setups that don't have much multimedia needs
20:46
<Roasted>
I was just curious if the thought process was, well, since hardware is getting cheaper, its just easier to use fat clients
20:47
yet on the flip side, cheaper hardware means even cheaper servers.
20:47
thereefore making thin clients maybe more attractive to certain scenarios.
20:48
if I were calling the shots, in our high school I can see 8 of our labs being thin, 2 being fat.
20:48
mostly because 8 labs are business, writing, research, library, etc.
20:48
the other 2 are photoshop related, cadd, etc
21:20
<alkisg>
Roasted: when the time is synchronized successfully and it's written to the CMOS clock, then it stays synchronized for the next boots. So if you see a computer drift off about e.g. 20 secs, then it hasn't been successfully synchronized for days...
21:21
So I'm wondering if removing the "&" actually solved the problem. To test, you'd need to change the clock from bios on each client, and reboot.
21:21
<Roasted>
alkisg, are you suggesting I use the original code, but without &
21:21
<alkisg>
No
21:21
<Roasted>
alkisg, also keep something in mind, I'm also pretty sure it was random which box was off by 20 seconds.
21:21
<alkisg>
I'm suggesting to keep the code you have now
21:21
And only enter the bios + change the time
21:22
<Roasted>
I'm almost postivie I'd boot up the 8 systems, and one would be 20 secs off. then maybe next reboot number 3 would be. next reboot 8 would be, etc.
21:22
It wasn't consistent, however they were SO close I was just so happy to see them nearly 100%
21:22
and it's not o say every time thter was 1 box that was off
21:22
a lot of the time, they were all perfect
21:22
but "sometimes" that was the case, where I noticed one was 15:51 and one was 15:52
21:23
then by counting manually I would see a 10-20 sec difference
21:23
<alkisg>
For proper time testing, the correct way would be to have a completely broken time on boot, and see if ltsp syncs it
21:23
You can either do that from BIOS, or I can give you a line in ltsp_nbd which forces a wrong time
21:24
I tried that here in my vbox, and I was able to reproduce the problem randomly
21:24
<Roasted>
okay. I'll do that.
21:24
Let me take that in my notes..
21:24
<alkisg>
But I fear that the problem isn't in time, it's deeper and worse... testing...
21:24
<Roasted>
not sure I follow. you think this is a much bigger problem?
21:25
<alkisg>
Yes, but let me test before commenting more
21:25
<Roasted>
well, let's hope its fixable, whatever it may be :P
21:37RiXtEr (~blah@75-121-251-74.dyn.centurytel.net) left irc: Ping timeout: 264 seconds
21:38RiXtEr (~blah@72-161-222-2.dyn.centurytel.net) joined #ltsp.
21:48vvinet (~vince@2001:470:8829:1000:227:eff:fe25:ee64) left irc: Read error: Operation timed out
21:49mgariepy (~mgariepy@ubuntu/member/mgariepy) left irc: Read error: Operation timed out
21:56dobber (~dobber@89.190.197.77) joined #ltsp.
22:19
<Roasted>
alkisg, before I head out of here, is there any other good stuff you're running across?
22:19
<alkisg>
Roasted: still debugging this, it's difficult but I think I'll have enough time to finish it today later on
22:22mgariepy (~mgariepy@ubuntu/member/mgariepy) joined #ltsp.
22:22vvinet (~vince@2001:470:8829:1000:227:eff:fe25:ee64) joined #ltsp.
22:22
<Roasted>
alkisg, good deal. If there's anything my limited knowledge can help with let me know. Meanwhile are you still interested in what I find out or is what you're doing now going to make the testing we talked about irrelevant?
22:24
<alkisg>
Roasted: postpone your testing for tomorrow, I'll probably do enough testing myself today to understand well enough the problem so that only confirmation-testing would be needed then
22:26
<Roasted>
alkisg, all right. I really appreciate your help with this.
22:26
alkisg, out of curiosity, did you start ltsp?
22:27
<alkisg>
Of course not
22:27mgariepy (~mgariepy@ubuntu/member/mgariepy) left irc: Ping timeout: 264 seconds
22:27vvinet (~vince@2001:470:8829:1000:227:eff:fe25:ee64) left irc: Ping timeout: 264 seconds
22:28
<Roasted>
alkisg, ah, wasn't sure how long ltsp was around in conjunction with what you do with it. ;)
22:29
<alkisg>
LTSP has been around for more than 10 years, while I've been a linux user for 3 years :)
22:29
<Roasted>
well, that answers it :P
22:29
are you an actual LTSP dev or just a really really helpful bystander?
22:29
<alkisg>
I was a helpful bystander and one of the devs signed me up one day :)
22:30
<Roasted>
nice, nice
22:30
anyway, I'll let ya to your testing. thanks for your help bro.
22:30
it's appreciated
22:30
<alkisg>
np
22:32vvinet (~vince@2001:470:8829:1000:227:eff:fe25:ee64) joined #ltsp.
22:32mgariepy (~mgariepy@ubuntu/member/mgariepy) joined #ltsp.
23:03vvinet (~vince@2001:470:8829:1000:227:eff:fe25:ee64) left irc: Ping timeout: 260 seconds
23:03mgariepy (~mgariepy@ubuntu/member/mgariepy) left irc: Read error: Operation timed out
23:04mgariepy (~mgariepy@2001:470:8829:1040:21e:c9ff:fe3c:ff2a) joined #ltsp.
23:04mgariepy (~mgariepy@2001:470:8829:1040:21e:c9ff:fe3c:ff2a) left irc: Changing host
23:04mgariepy (~mgariepy@ubuntu/member/mgariepy) joined #ltsp.
23:08vvinet (~vince@2001:470:8829:1000:227:eff:fe25:ee64) joined #ltsp.
23:32
<muppis>
Is there existing plugin for rdesktop or do I have create one?
23:35
<alkisg>
There's a screen script for rdesktop
23:35
man lts.conf => search for RDP , I think it's documented
23:36
muppis: otherwise just read this: /opt/ltsp/i386/usr/share/ltsp/screen.d/rdesktop
23:36
<muppis>
alkisg, thanks. :)
23:58
<alkisg>
The time-sync problem seems to be that something kills the initscript processes that delay too long
23:58
So e.g. ntpdate -p 1 (ask only for 1 sample) finishes very fast and it works, while "sleep 3" doesn't, it gets killed
23:59
*the initscript ***spawned*** processes, not the initscript processes themselves. Which I would classify as a bug (not an ltsp one though)
00:00--- Wed Apr 13 2011