IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 12 April 2011 (all times are UTC)
| 00:15 | monteslu (~monteslu@ip68-109-170-79.ph.ph.cox.net) left irc: Read error: Connection timed out | |
| 00:16 | monteslu (~monteslu@ip68-109-170-79.ph.ph.cox.net) joined #ltsp. | |
| 00:29 | vagrantc (~vagrant@c-24-21-191-93.hsd1.or.comcast.net) left irc: Quit: leaving | |
| 00:39 | ogra_ (~ogra@ubuntu/member/ogra) left irc: Read error: Operation timed out | |
| 00:41 | Gremble (~Ben@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com) joined #ltsp. | |
| 00:49 | viks (ca8a720f@gateway/web/freenode/ip.202.138.114.15) joined #ltsp. | |
| 00:49 | <viks> #ulteo
| |
| 00:53 | ogra_ (~ogra@p5098ed03.dip0.t-ipconnect.de) joined #ltsp. | |
| 00:57 | Trixboxer (~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:05 | cyberorg (~cyberorg@opensuse/member/Cyberorg) left irc: Quit: Leaving | |
| 01:16 | bobby_C (~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) joined #ltsp. | |
| 01:17 | ogra_ (~ogra@p5098ed03.dip0.t-ipconnect.de) left irc: Read error: Operation timed out | |
| 01:23 | ogra_ (~ogra@p5098ed03.dip0.t-ipconnect.de) joined #ltsp. | |
| 01:29 | dlezcano (~dlezcano@AToulouse-159-1-58-152.w92-134.abo.wanadoo.fr) left irc: Ping timeout: 258 seconds | |
| 01:37 | cyberorg (~cyberorg@opensuse/member/Cyberorg) joined #ltsp. | |
| 01:50 | viks (ca8a720f@gateway/web/freenode/ip.202.138.114.15) left irc: Ping timeout: 252 seconds | |
| 01:53 | bobby_C (~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) left irc: Remote host closed the connection | |
| 02:00 | bobby_C (~bobby@85.124.22.227) joined #ltsp. | |
| 02:24 | monteslu (~monteslu@ip68-109-170-79.ph.ph.cox.net) left irc: Ping timeout: 246 seconds | |
| 02:24 | monteslu (~monteslu@ip68-109-170-79.ph.ph.cox.net) joined #ltsp. | |
| 02:36 | viks (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:36 | dlezcano (~dlezcano@nat/ibm/x-glqgunxbquvbuzzj) joined #ltsp. | |
| 02:36 | <viks> alkisg : tell me
| |
| 02:37 | alkisg : it is showing ltsp installation ended abnormally
| |
| 02:42 | alkisg (~alkisg@ubuntu/member/alkisg) left irc: Quit: Leaving. | |
| 02:43 | <Hyperbyte> Awwwe
| |
| 03:10 | viks (ca8a720f@gateway/web/freenode/ip.202.138.114.15) left irc: Ping timeout: 252 seconds | |
| 03:19 | Gremble (~Ben@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com) left irc: Remote host closed the connection | |
| 03:31 | LoveStorm (Storm@217.18.70.231) left irc: Read error: Operation timed out | |
| 04:04 | <Trixboxer> :)
| |
| 04:15 | LoveStorm (~Storm@217.18.70.231) joined #ltsp. | |
| 04:15 | alkisg (~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:16 | shawnp0wers (~Adium@linuxjournal/staff/shawnp0wers) joined #ltsp. | |
| 05:18 | highvoltage (~highvolta@ubuntu/member/highvoltage) left irc: Quit: Lost terminal | |
| 05:33 | dlezcano (~dlezcano@nat/ibm/x-glqgunxbquvbuzzj) left irc: Ping timeout: 240 seconds | |
| 05:51 | dlezcano (~dlezcano@nat/ibm/x-iapuuqvqvvkdfzmj) joined #ltsp. | |
| 05:53 | highvoltage (~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:36 | primeministerp (~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:05 | dlezcano (~dlezcano@nat/ibm/x-iapuuqvqvvkdfzmj) left irc: Read error: Operation timed out | |
| 07:13 | brunolambert (~brunolamb@2001:470:8829:1000:221:6aff:fe94:21d8) joined #ltsp. | |
| 07:20 | Roasted (~jason@206.82.22.190) joined #ltsp. | |
| 07:24 | primeministerp (~ppouliot@64.119.153.82) left irc: Ping timeout: 260 seconds | |
| 07:27 | primeministerp (~ppouliot@64.119.153.82) joined #ltsp. | |
| 07:37 | bobby_C (~bobby@85.124.22.227) left irc: Ping timeout: 260 seconds | |
| 07:41 | mistik1 (mistik1@unaffiliated/mistik1) left irc: Read error: Connection reset by peer | |
| 07:42 | mistik1 (mistik1@unaffiliated/mistik1) joined #ltsp. | |
| 07:50 | alkisg (~alkisg@ubuntu/member/alkisg) left irc: Quit: Leaving. | |
| 07:58 | dobber (~dobber@89.190.197.77) left irc: Remote host closed the connection | |
| 07:59 | primeministerp (~ppouliot@64.119.153.82) left irc: Read error: Connection reset by peer | |
| 08:01 | primeministerp (~ppouliot@64.119.153.82) joined #ltsp. | |
| 08:05 | dlezcano (~dlezcano@AToulouse-159-1-58-152.w92-134.abo.wanadoo.fr) joined #ltsp. | |
| 08:16 | staffencasa (~staffenca@128.193.148.149) joined #ltsp. | |
| 09:16 | primeministerp (~ppouliot@64.119.153.82) left irc: Read error: Connection reset by peer | |
| 09:23 | Gremble (~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:09 | Gremble (~Ben@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com) left irc: Quit: I Leave | |
| 10:18 | otavio (~otavio@debian/developer/otavio) left irc: Ping timeout: 260 seconds | |
| 10:18 | otavio (~otavio@debian/developer/otavio) joined #ltsp. | |
| 10:19 | chupacabra (~chupacabr@cpe-70-112-10-45.austin.res.rr.com) left irc: Ping timeout: 240 seconds | |
| 10:24 | chupacabra (~chupacabr@cpe-70-112-10-45.austin.res.rr.com) joined #ltsp. | |
| 10:44 | Nick change: zz_evil_root -> evil_root | |
| 10:51 | shawnp0wers (~Adium@linuxjournal/staff/shawnp0wers) left irc: Quit: Leaving. | |
| 11:18 | alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp. | |
| 11:23 | Ahmuck (~quietly@p178n22.ruraltel.net) left irc: Remote host closed the connection | |
| 11:23 | Trixboxer (~Trixboxer@office.supportdepartment.net) left irc: Quit: "Achievement is not the end, its the beginning of new journey !!!" | |
| 11:25 | Ahmuck (~quietly@p178n22.ruraltel.net) joined #ltsp. | |
| 11:34 | dlezcano (~dlezcano@AToulouse-159-1-58-152.w92-134.abo.wanadoo.fr) left irc: Ping timeout: 240 seconds | |
| 11:54 | RiXtEr (~blah@72-161-236-101.dyn.centurytel.net) left irc: Ping timeout: 260 seconds | |
| 11:54 | RiXtEr (~blah@99-195-108-82.dyn.centurytel.net) joined #ltsp. | |
| 11:59 | RiXtEr (~blah@99-195-108-82.dyn.centurytel.net) left irc: Ping timeout: 252 seconds | |
| 11:59 | vagrantc (~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) joined #ltsp. | |
| 12:00 | RiXtEr (~blah@72-161-220-243.dyn.centurytel.net) joined #ltsp. | |
| 12:11 | vagrantc (~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) left irc: Ping timeout: 258 seconds | |
| 12:21 | RiXtEr (~blah@72-161-220-243.dyn.centurytel.net) left irc: Ping timeout: 258 seconds | |
| 12:22 | RiXtEr (~blah@72-161-220-243.dyn.centurytel.net) joined #ltsp. | |
| 12:32 | alkisg (~alkisg@ubuntu/member/alkisg) left irc: Quit: Leaving. | |
| 12:35 | Roasted (~jason@206.82.22.190) left irc: Ping timeout: 246 seconds | |
| 12:42 | andygraybeal (~andy.gray@obsidian.casanueva.com) left irc: Remote host closed the connection | |
| 13:13 | RiXtEr (~blah@72-161-220-243.dyn.centurytel.net) left irc: Ping timeout: 276 seconds | |
| 13:13 | RiXtEr (~blah@75-121-248-251.dyn.centurytel.net) joined #ltsp. | |
| 13:18 | brunolambert (~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:51 | Nick change: evil_root -> zz_evil_root | |
| 14:04 | Gadi_android (~yaaic@184.240.82.11) joined #ltsp. | |
| 14:07 | sep (~sep@40.211.jostedal.no) left irc: Ping timeout: 246 seconds | |
| 14:08 | sep (~sep@40.211.jostedal.no) joined #ltsp. | |
| 14:09 | Gadi_android (~yaaic@184.240.82.11) left irc: Ping timeout: 260 seconds | |
| 14:11 | bobby_C (~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) joined #ltsp. | |
| 14:27 | Mip5 (~chatzilla@75-148-124-137-colorado.hfc.comcastbusiness.net) joined #ltsp. | |
| 14:27 | alexqwesa (~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:30 | alexqwesa (~alex@alexo-veto.broker.freenet6.net) joined #ltsp. | |
| 14:58 | ogra_ (~ogra@p5098ed03.dip0.t-ipconnect.de) left irc: Ping timeout: 240 seconds | |
| 14:58 | <Mip5> Gotta run - take care everyone. M
| |
| 14:58 | Mip5 (chatzilla@75-148-124-137-colorado.hfc.comcastbusiness.net) left #ltsp. | |
| 14:58 | ogra_ (~ogra@p5098ed03.dip0.t-ipconnect.de) joined #ltsp. | |
| 15:01 | RiXtEr (~blah@75-121-248-251.dyn.centurytel.net) left irc: Ping timeout: 276 seconds | |
| 15:02 | RiXtEr (~blah@75-121-251-74.dyn.centurytel.net) joined #ltsp. | |
| 15:07 | shawnp0wers (~spowers@linuxjournal/staff/shawnp0wers) joined #ltsp. | |
| 16:27 | moldy (~rene@unaffiliated/moldy) left irc: Ping timeout: 248 seconds | |
| 16:27 | moldy (~rene@unaffiliated/moldy) joined #ltsp. | |
| 16:37 | bobby_C (~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) left irc: Ping timeout: 246 seconds | |
| 16:43 | staffencasa (~staffenca@128.193.148.149) left irc: Quit: Leaving | |
| 17:30 | MorningSon (~MorningSo@cpe-72-181-35-91.satx.res.rr.com) joined #ltsp. | |
| 17:51 | artista_frustrad (~artista_f@187.7.151.105) left irc: Quit: Leaving | |
| 18:12 | shawnp0wers (~spowers@linuxjournal/staff/shawnp0wers) left irc: Quit: Leaving. | |
| 18:31 | shawnp0wers (~spowers@linuxjournal/staff/shawnp0wers) joined #ltsp. | |
| 18:48 | shawnp0wers (~spowers@linuxjournal/staff/shawnp0wers) left irc: Quit: Leaving. | |
| 19:07 | Nick change: zz_evil_root -> evil_root | |
| 19:13 | Nick change: evil_root -> zz_evil_root | |
| 19:30 | roasted__ (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) left irc: Read error: Connection reset by peer | |
| 19:32 | alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp. | |
| 19:33 | Roasted (~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:48 | MorningSon (~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:37 | RiXtEr (~blah@75-121-251-74.dyn.centurytel.net) left irc: Ping timeout: 264 seconds | |
| 21:38 | RiXtEr (~blah@72-161-222-2.dyn.centurytel.net) joined #ltsp. | |
| 21:48 | vvinet (~vince@2001:470:8829:1000:227:eff:fe25:ee64) left irc: Read error: Operation timed out | |
| 21:49 | mgariepy (~mgariepy@ubuntu/member/mgariepy) left irc: Read error: Operation timed out | |
| 21:56 | dobber (~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:22 | mgariepy (~mgariepy@ubuntu/member/mgariepy) joined #ltsp. | |
| 22:22 | vvinet (~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:27 | mgariepy (~mgariepy@ubuntu/member/mgariepy) left irc: Ping timeout: 264 seconds | |
| 22:27 | vvinet (~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:32 | vvinet (~vince@2001:470:8829:1000:227:eff:fe25:ee64) joined #ltsp. | |
| 22:32 | mgariepy (~mgariepy@ubuntu/member/mgariepy) joined #ltsp. | |
| 23:03 | vvinet (~vince@2001:470:8829:1000:227:eff:fe25:ee64) left irc: Ping timeout: 260 seconds | |
| 23:03 | mgariepy (~mgariepy@ubuntu/member/mgariepy) left irc: Read error: Operation timed out | |
| 23:04 | mgariepy (~mgariepy@2001:470:8829:1040:21e:c9ff:fe3c:ff2a) joined #ltsp. | |
| 23:04 | mgariepy (~mgariepy@2001:470:8829:1040:21e:c9ff:fe3c:ff2a) left irc: Changing host | |
| 23:04 | mgariepy (~mgariepy@ubuntu/member/mgariepy) joined #ltsp. | |
| 23:08 | vvinet (~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 | |