00:03 | map7 has joined #ltsp | |
00:10 | alkisg has joined #ltsp | |
00:16 | F-GT has quit IRC | |
00:32 | F-GT has joined #ltsp | |
00:34 | alkisg has quit IRC | |
01:23 | alkisg has joined #ltsp | |
01:55 | pts_ has joined #ltsp | |
01:58 | Gadi_eeepc has quit IRC | |
01:58 | Egyptian[Home] has quit IRC | |
01:58 | waldo323 has quit IRC | |
01:58 | jhutchins has quit IRC | |
01:58 | HardDisk has quit IRC | |
01:58 | kusznir has quit IRC | |
01:58 | stgraber has quit IRC | |
02:01 | stgraber has joined #ltsp | |
02:01 | HardDisk has joined #ltsp | |
02:02 | jhutchins has joined #ltsp | |
02:06 | kusznir has joined #ltsp | |
02:08 | Gadi_eeepc has joined #ltsp | |
02:12 | Egyptian[Home] has joined #ltsp | |
02:18 | <alkisg> Concerning the udhcp script, I think it will be less hacky and more readable to do the following:
| |
02:19 | gnunux has joined #ltsp | |
02:19 | <alkisg> 1) Split the udhcp script in two, so that a separate script exists than is called by the udhcpc client.
| |
02:19 | *that
| |
02:19 | <gnunux> hi
| |
02:19 | <alkisg> 2) Copy that script in the initramfs, *in the same path* where it is in the chroot
| |
02:20 | E.g. in /usr/share/initramfs-tools/scripts/udhcp-called-script.sh
| |
02:20 | This will result in a "weird" initramfs, which will contain a /usr/share path
| |
02:21 | 3) Call udhcpc -s /usr/share/initramfs-tools/scripts/udhcp-called-script.sh. This way it will find it in the initramfs, but it will also find it afterwards, when the lease expires and is called again
| |
02:22 | I think using two scripts will be more readable than just one. stgraber, vagrantc, any thoughts on that?
| |
02:23 | Or we could put that script in /bin, to avoid creating a weird path...
| |
02:23 | ...hmm maybe that one's better.
| |
02:25 | stgraber, vagrantc: so is it OK if I put an extra script, /sbin/udhcpc-called-script, in ltsp-client-core?
| |
02:25 | Gadi_eeepc has quit IRC | |
02:26 | <alkisg> (and copy it to /sbin/ in the initramfs from the udhcp hook?)
| |
02:27 | Gadi_eeepc has joined #ltsp | |
02:27 | <alkisg> I think that's a quite clean solution..
| |
02:31 | Ah, better yet, why not use the default location, /etc/udhcpc/default.script
| |
02:31 | This way we won't even need a -s parameter to udhcpc
| |
02:34 | Nah udhcpc already provides that file... so maybe, /etc/udhcpc/ltsp.script
| |
02:50 | <vagrantc> alkisg: i don't see any problem with a weird distant path...
| |
02:51 | <alkisg> vagrantc: on second thought, I think a conffile in /etc/udhcpc/ltsp.script would be better
| |
02:51 | It would save the code reader from having to understand about a hacky script that is called multiple times for *different* purposes
| |
02:52 | And if some admin needs to do something special on dhcp leases, a conffile works better on upgrades
| |
02:52 | (...but "readable" is my main concern :))
| |
02:53 | It will require a small change in packaging, though...
| |
02:55 | ...so I'd need approval before commiting any of this
| |
03:07 | klausade has quit IRC | |
03:21 | comfrey_ has quit IRC | |
03:21 | comfrey has quit IRC | |
03:22 | evilx has quit IRC | |
03:32 | <alkisg> Hey, we already have wget (=busybox) in the initramfs, and it works fine! (no dns thought). Heh, some web-based configuration system might be near... :)
| |
03:49 | ogra has quit IRC | |
03:50 | ogra has joined #ltsp | |
03:54 | vagrantc has quit IRC | |
04:22 | alkisg has quit IRC | |
04:27 | mikkel has joined #ltsp | |
05:01 | hersonls has joined #ltsp | |
05:19 | lucascoala has quit IRC | |
05:23 | lucascoala has joined #ltsp | |
05:26 | sene has quit IRC | |
05:29 | alkisg has joined #ltsp | |
05:59 | frederickjh has joined #ltsp | |
06:11 | bassie has joined #ltsp | |
06:11 | <bassie> hi all, i got a small question. the linux kernel in ubuntu 9.04 is giving me a headache so i installed kernel 6.2.30.
| |
06:12 | how do i update the kernel on the thinclient?
| |
06:12 | i tried ltsp-update-kernel, but i don't notice a difference in /opt/ltsp/i386/boot
| |
06:12 | lucascoala has quit IRC | |
06:13 | <alkisg> bassie: you need to install the kernel *on the chroot* before running ltsp-update-kernels
| |
06:13 | Then, ltsp-update-kernels gets the kernels from /opt/ltsp/i386/boot and puts them to the tftpboot dir
| |
06:13 | <bassie> so i copy the deb files to /opt/ltsp/i386/
| |
06:13 | chroot to that directory and dpkg -i them?
| |
06:13 | <alkisg> Something like that, yes
| |
06:14 | <bassie> ok i'll try
| |
06:14 | mind if i post my commands here?
| |
06:14 | <alkisg> Of course not
| |
06:14 | <bassie> mv *deb /opt/ltsp/i386/root/
| |
06:16 | chroot /opt/ltsp/i386/
| |
06:16 | cd root
| |
06:16 | avlis has joined #ltsp | |
06:16 | <bassie> dpkg both pachages (header and kernel)
| |
06:17 | <alkisg> bassie: wait
| |
06:17 | I don't think there's need for the headers, lemme check...
| |
06:17 | <bassie> well they won't cause any harm and aren't that big
| |
06:17 | <alkisg> ii linux-firmware 1.29 Firmware for Linux kernel drivers
| |
06:17 | ii linux-image-2.6.32-12-generic 2.6.32-12.17 Linux kernel image for version 2.6.32 on x86/x86_6
| |
06:17 | ii linux-image-generic 2.6.32.12.12 Generic Linux kernel image
| |
06:18 | OK. Those are what I have, but sure, the headers won't hurt
| |
06:18 | <bassie> if both are installed i ctrl D
| |
06:18 | <alkisg> See if you get any errors, if you do, then mount /proc
| |
06:19 | <bassie> do i ltsp-update image in the chroot or exit it first?
| |
06:19 | *ltsp-update-kernel
| |
06:19 | <alkisg> exit first, ltsp-update-kernels after
| |
06:19 | <bassie> k
| |
06:19 | <alkisg> Then, ls -l /var/lib/tftpboot/ltsp/i386 to make sure that it was updated
| |
06:20 | <bassie> /var/lib/tftpboot/ltsp/i386 has nbi.img-2.6.30-020630-generic and so on
| |
06:21 | is this procedure somewhere documented?
| |
06:21 | <alkisg> Yes, in the ubuntu wiki
| |
06:21 | <bassie> tried finding it but couldn't
| |
06:21 | guess google wasn't my friend
| |
06:21 | <alkisg> https://help.ubuntu.com/community/UbuntuLTSP/UpdatingChroot
| |
06:21 | put "ubuntultsp" in google to locate the wiki pages more easily...
| |
06:22 | pmatulis has joined #ltsp | |
06:22 | <bassie> guess i missed it.... thx, now lets hope the new kernel fixed my sound problem
| |
06:24 | pulseaudio keeps crashing on an intel audio card. Read there where a lot of problems with that specific type of hardware
| |
06:24 | an older debian kernel works perfect
| |
06:25 | <alkisg> You may also try a full karmic chroot if you want...
| |
06:25 | <bassie> could try that.....
| |
06:25 | bobby_C has joined #ltsp | |
06:25 | <bassie> didn't install karmic becouse that has problems joining a skolelinux domain
| |
06:33 | <sep> joining a domain ? it's just pam and nss ldap right ?
| |
06:34 | <bassie> yea
| |
06:34 | it's been posted on the skolelinux mailinglist but no solution
| |
06:34 | sep..; aren't you a skolelinux developer?
| |
06:34 | <sep> guess so.. :)
| |
06:35 | <bassie> recognise the name...
| |
06:35 | <sep> http://wiki.skolelinux.de/Skolelinux/Ubuntu collects some of the various mail's that have been on the topic
| |
06:36 | very old much of it i see
| |
06:36 | <bassie> got to switch computer.... brb
| |
06:36 | bassie has quit IRC | |
06:38 | bassie has joined #ltsp | |
06:38 | <bassie> backj
| |
06:40 | guess that didn't work....
| |
06:43 | <sep> bassie, also there is #debian-edu on oftc, people there that have more experience with ubuntu vs skolelinux then i have.
| |
06:43 | <bassie> well i downgraded to 9.04 and that works too....
| |
06:43 | so didn't have any need to bother anyone
| |
06:44 | and it was my own fault... should have just stayed with debian
| |
06:47 | <alkisg> bassie: is the sound problem a driver problem?
| |
06:50 | <bassie> probably yes
| |
06:50 | after the upgrade my thin client won't boot... looking into it now
| |
06:52 | vvinet has quit IRC | |
06:52 | <bassie> i'm getting mount errors.
| |
06:52 | <alkisg> Those are "normal" :)
| |
06:52 | Ignore them.... anything else?
| |
06:53 | <bassie> i'm getting thrown to initramfs
| |
06:53 | target filesystem doesn't have /sbin/init
| |
06:53 | <alkisg> Hmmm
| |
06:53 | <bassie> no in it found. Try passing init = bootarg
| |
06:54 | <alkisg> Is nbd-client running?
| |
06:54 | <bassie> yep
| |
06:54 | nbdclient 172.16.2.13 2000 /dev/nbd0 -persist
| |
06:54 | <alkisg> And I suppose root isn't mounted in /root, right?
| |
06:54 | <bassie> BUT......
| |
06:55 | mount /dev/nbd0 on rofs failed
| |
06:55 | Gadi_eeepc has left #ltsp | |
06:55 | scottmaccal has joined #ltsp | |
06:56 | <bassie> alkisg: "And I suppose root isn't mounted in /root, right?" what do you mean? how do i check?
| |
06:57 | <alkisg> Well if mount failed, root won't be there
| |
06:57 | But I don't know why mount would fail...
| |
06:58 | bobby_C has quit IRC | |
06:58 | bobby_C has joined #ltsp | |
06:59 | <bassie> dmesg: squashfs error: majof/minor mismatch, older squashfs 3.1 filesystems are unsupported
| |
06:59 | could this be it?
| |
06:59 | <alkisg> Yup
| |
06:59 | <bassie> and i guess squashfs is in the kernel :-)
| |
07:00 | ok i'll install an older kernel then :-)
| |
07:00 | <alkisg> bassie: maybe you could update squashfs-tools in your server?
| |
07:00 | <bassie> i'll try with an older kernel first...
| |
07:01 | <alkisg> I've never done that, but the squashfs-tools dependencies seem simple..
| |
07:04 | <bassie> just making an image with kernel 2.6
| |
07:04 | 2.6.26 that is
| |
07:04 | <alkisg> Weren't you trying to update your kernel, not downgrade it? :)
| |
07:04 | <bassie> well ubuntu has kernel 2.28 and taht is bugged
| |
07:04 | kernel 2.26 and 2.30 are both ok
| |
07:05 | *6.26 and 6.30
| |
07:05 | <alkisg> Ah, ok
| |
07:06 | <bassie> atleast i'm hoping that is the fix
| |
07:06 | same mounting problem, but now i don't get the squashfs error
| |
07:10 | avlis has quit IRC | |
07:12 | alkisg has quit IRC | |
07:14 | <bassie> gonna do a fresh install and experiment in next wednesday...
| |
07:15 | avlis has joined #ltsp | |
07:18 | GodFather has joined #ltsp | |
07:20 | evilx has joined #ltsp | |
07:23 | mgariepy has joined #ltsp | |
07:30 | vvinet has joined #ltsp | |
07:30 | Briareos1 has joined #ltsp | |
07:30 | <Briareos1> good afternoon
| |
07:38 | Faithful has joined #ltsp | |
07:45 | flip_ has joined #ltsp | |
07:47 | stgraber has quit IRC | |
07:47 | stgraber has joined #ltsp | |
07:48 | flip_ is now known as Sorrel | |
08:05 | grantk has joined #ltsp | |
08:06 | grantk has left #ltsp | |
08:06 | grantk has joined #ltsp | |
08:21 | grantk has left #ltsp | |
08:21 | grantk has joined #ltsp | |
08:23 | pimpministerp has joined #ltsp | |
08:24 | pimpministerp has quit IRC | |
08:26 | wftl has quit IRC | |
08:33 | waldo323 has joined #ltsp | |
08:44 | pts_ has quit IRC | |
08:44 | wftl has joined #ltsp | |
08:56 | <sbalneav> Morning all
| |
08:57 | <vbundi> mornin
| |
09:00 | <sbalneav> Dear Scott Balneaves,
| |
09:00 | We are pleased to inform you that you are now part of the GNOME
| |
09:00 | Foundation Membership.
| |
09:00 | Hooray!
| |
09:00 | <Briareos1> hi
| |
09:01 | <sbalneav> Morning Briareos1
| |
09:01 | <Briareos1> gratulations
| |
09:01 | what's the benefits of that? :)
| |
09:01 | <alincoln> sbalneav: yay!
| |
09:01 | bobby_C has quit IRC | |
09:03 | <sbalneav> Briareos1: I can vote in GNOME elections, or run for the board, and I can get a @gnome.org email.
| |
09:04 | <Briareos1> nice :)
| |
09:04 | <vbundi> neato
| |
09:05 | shawnp0wers has joined #ltsp | |
09:07 | <sbalneav> So, I'm now officially upstream GNOME. Foundation member, git access, the whole works.
| |
09:15 | * appiah bows to sbalneav | |
09:16 | bobby_C has joined #ltsp | |
09:17 | cliebow has joined #ltsp | |
09:27 | <_UsUrPeR_> hey all. Having a problem with 9.10 and an intel-based client. I'm getting repeating errors of the following in shell on the client: [ server time] hda-intel: spurious response 0x0 0x0, last cmd=0x1421422
| |
09:28 | this is specific to 9.10
| |
09:28 | and anybody seen anything like this?
| |
09:32 | alkisg has joined #ltsp | |
09:32 | waldo323 has quit IRC | |
10:11 | CAN-o-SPAM has joined #ltsp | |
10:11 | tstafford has joined #ltsp | |
10:11 | GGD has joined #ltsp | |
10:15 | etyack has joined #ltsp | |
10:17 | dberkholz has quit IRC | |
10:17 | dberkholz has joined #ltsp | |
10:28 | staffencasa has joined #ltsp | |
10:29 | <sbalneav> _UsUrPeR_: No, sorry, haven't seen that
| |
10:29 | <_UsUrPeR_> sbalneav: I think it's specific to an azelia sound card. If I shut it off in the BIOS, the error goes away.
| |
10:29 | unfortunately, I don't have sound after that
| |
10:30 | This is a 9.10+-specific issue. In 9.04, no errors, no problems
| |
10:30 | same problem evident in 10.04 Alpha
| |
10:31 | <sbalneav> Obviously a kernel issue.
| |
10:31 | try the LKML mailing list.
| |
10:31 | appiah has quit IRC | |
10:32 | <ogra> or ubuntu-kernel@
| |
10:32 | gnunux has quit IRC | |
10:34 | Appiah has joined #ltsp | |
10:47 | avlis has quit IRC | |
10:59 | <johnny> _UsUrPeR_, also lookup that card in the alsa wiki, there are often quirks you can set
| |
10:59 | or by forcing the model
| |
10:59 | sometims the autodetect isn't perfect
| |
10:59 | <_UsUrPeR_> johnny: thx
| |
10:59 | <johnny> i've had to do that once or twice
| |
11:01 | <_UsUrPeR_> johnny: it's strange. sound works, it's just these messages that keep coming up.
| |
11:03 | <johnny> sure.. that's why they came up with quirky parameters..
| |
11:04 | sometimes it's hard for them to discover certain sound cards
| |
11:04 | as vendors will use the same model number for a sound system that uses a different chip internally.. or a diferent version
| |
11:04 | lame stuff
| |
11:04 | happens all the time tho
| |
11:05 | we're lucky computers work at all if you think about all those hacks..
| |
11:30 | <knipwim> :)
| |
11:31 | reminds me of an interview with nasa concernign the early apollo missions
| |
11:32 | "how did you make the software work in such a short time"
| |
11:33 | where the nasa dude replied that they accidentaly discovered a missing - in a navigational calculation a day before launch
| |
11:33 | and had they not discovered, the mission would have failed
| |
11:44 | Gadi1 has joined #ltsp | |
11:53 | the_fronny has joined #ltsp | |
11:53 | tstafford has quit IRC | |
11:55 | tstafford has joined #ltsp | |
11:56 | <the_fronny> We've been running ltsp-4.2 on Ubuntu jaunty serving compaq EN SFF clients, and have just received a couple test Acer Aspire Revos. They use Atom cpus and, I think, nvidia chipsets/video. They won't boot on our setup. Is this possible on ltsp5 and/or with a newer OS on the server?
| |
11:56 | <vbundi> most likely
| |
11:56 | reynolds has joined #ltsp | |
11:56 | <vbundi> LTSP5 has much better support for newer hardware
| |
11:57 | nvidia and intel atom both have good support
| |
11:58 | <reynolds> Does anyone have an opinion about server processors, I am looking to purchase a server for my school which will support around 60 clients, that will be using flash?
| |
11:58 | <vbundi> what's your budget
| |
11:59 | <reynolds> xeon e5300 or e5500? quad, dual
| |
11:59 | around 4,000
| |
11:59 | <the_fronny> Thanks vbundi! I'm not sure I like ltsp to be so completely integrated with the host OS but it looks like we (we here) are being pushed that way.
| |
12:00 | <vbundi> the_fronny make sure you test your old hardware with LTSP5 if you are going to continue using it.... I'm having troubles running LTSP5 on my HP T5700s
| |
12:01 | <CAN-o-SPAM> vbundi: whats the troubles with HP t5700s:?
| |
12:01 | <vbundi> Transmeta Crusoe processor doesn't play nice with the new kernel and udev
| |
12:02 | <the_fronny> vibundi: Will do. About a year ago I was able to deliver a full ubuntu environment (using fluxbox) to a bunch of Vectra P1 clients with 32MB of ram. No more, so we are pretty aware of possible pitfalls. Thanks.
| |
12:03 | <vbundi> the_fronny: yea now I'm stuck trying to figure out how to set up ltsp 4.2 as the previous guy in charge of this didn't document anything or set up a maintainable system
| |
12:04 | reynolds: I'm running 15 clients on a Q6600 that gets to about 15% cpu usage during peak
| |
12:05 | <the_fronny> vbundi: Is there anything in particular that you're having trouble with?
| |
12:07 | <vbundi> the_fronny: step 1, I can find old documentation for ltsp 3.0 but I have no idea where to start with 4.2, I've downloaded all the tgz's from the repo but not really sure how to put it together on a newer system ie Karmic
| |
12:07 | <reynolds> I am looking for something pretty beefy, I want the ability to grow if need be., So 60 clients running WELL is ideal.
| |
12:09 | <vbundi> reynolds: go with an LGA1366 Xeon then like an X5550
| |
12:10 | reynolds: overkill, and almost $1200 but it sounds like that's what you're going for? ;) my reasoning is that the LGA1366 socket is new and not dead like 775/771
| |
12:10 | <sbalneav> vbundi: You'd be far better off to drop 4.2, and move to five.
| |
12:11 | Why is it you can't move to 5?
| |
12:11 | <the_fronny> vbundi: look around for "ltspadmin". It's a neat little app that will do the initial ltsp setup on the host. Then you get to monkey around with the host settings (dhcp, xdmcp, etc. yourself) ltsp5 is very much more tightly knit to the host OS.
| |
12:11 | <sbalneav> the_fronny: No it's not
| |
12:11 | TDK has joined #ltsp | |
12:11 | <sbalneav> it uses all the same services
| |
12:12 | <reynolds> vbundi: Thanks!
| |
12:12 | <vbundi> sbalneav: I realise this, but I don't think that my client wants to buy all new terminals (Acer revos are what, $300?) when all the users are doing is running Accounting software
| |
12:12 | <sbalneav> What are the old terminals?
| |
12:12 | TDK has quit IRC | |
12:13 | <vbundi> HP T5700's TM5700 (800mhz) 256MB Ram
| |
12:13 | Lns has joined #ltsp | |
12:13 | <sbalneav> Those will work fine under ltsp5
| |
12:13 | I've got one.
| |
12:13 | <Lns> morning all
| |
12:13 | <vbundi> mornin Lns
| |
12:14 | <sbalneav> What problem are you having with yours?
| |
12:14 | <vbundi> sbalneav: really? because I've been trying for 3 days to get one working with Karmic, all I'm running is rdesktop and scrolling in a window or browser is quite choppy
| |
12:15 | they also take 5 minutes to boot unless I disable ltspfs_entry, in which case they take 2-3 minutes still.
| |
12:15 | the_fronny: "ltspadmin
| |
12:15 | the_fronny: is it in a repository or do I compile it from tar
| |
12:15 | <the_fronny> Don't want to start an argument here but it's been pretty clear in my experience that we can run much older clients on ltsp-4.2 than we can on ltsp5. Some of this might be ltsp based, some might be ubuntu based, I don't care.
| |
12:16 | <Lns> the_fronny: that's been well known by most ltsp admins for a while now ;)
| |
12:16 | ltsp 4.2 was around what... 96? 97?
| |
12:17 | <sbalneav> I can see I'm pretty much done here.
| |
12:17 | Bye all
| |
12:17 | sbalneav has quit IRC | |
12:17 | <the_fronny> vbundi: Go to www.ltsp.org and you should be able to find it on that page, or a link to it.
| |
12:17 | <vbundi> Lns: not this ltsp admin ;)
| |
12:17 | <CAN-o-SPAM> Lns: twitter eh? ;)
| |
12:17 | <Lns> CAN-o-SPAM: ;) was poking around last night at some followers of others
| |
12:17 | reynolds has quit IRC | |
12:17 | <Lns> vbundi: well now you do, too.
| |
12:18 | ltsp 4.2 is old, insecure and not supported. If you want to roll it out you're pretty much on your own.
| |
12:19 | <the_fronny> Lns: I'm sure it has, but the traffic comes from those just thrown into the mix, not the practiced. Right?
| |
12:19 | <vbundi> I've heard of this ltspadmin but haven't been able to find it, and after looking again on ltsp.org.. still can't
| |
12:20 | <Lns> the_fronny: what?
| |
12:20 | vbundi: ltspadmin...from 4.2?
| |
12:20 | <vbundi> Lns: yeah if I can convince these guys to spend money on hardware rather than spending money on my hours I will
| |
12:21 | lns: yea, I don't see it anywhere on the server
| |
12:21 | <Lns> What's keeping anyone from rolling their own minimalized kernel/chroot changes/etc in ltsp5? Wouldn't that help at least some?
| |
12:22 | <vbundi> yeah I suppose running an older kernel might help
| |
12:23 | <Lns> vbundi: not an older kernel per say, but one you compiled with minimal options (and therefore minimal memory usage)
| |
12:23 | <the_fronny> vbundi: ltsp42 is indeed gone from the site. Your choice is simple now.
| |
12:23 | <Lns> you can tune the chroot to your heart's content really
| |
12:23 | I don't get why people are so stuck on 4.2
| |
12:24 | <alkisg> Lns, well if you have 32Mb terminals, I don't think ltsp 5 can boot them
| |
12:24 | The 2.6 kernel is just too big for that
| |
12:24 | scottmaccal has quit IRC | |
12:24 | <vbundi> they're 256MB terminals and they still run like molases
| |
12:24 | <Lns> vbundi: i have 128mb terminals running just fine....
| |
12:24 | <vbundi> it's the cpu that's the problem I think
| |
12:25 | Lns: what processor are you running?
| |
12:25 | <Lns> via 1ghz
| |
12:25 | <alkisg> vbundi: your case is weird. Your cpu should be enough, so something's wasting it
| |
12:25 | <Lns> or the network
| |
12:25 | <alkisg> vbundi: I have 300 MHz clients that boot in 1:10
| |
12:25 | <vbundi> network is great
| |
12:25 | alkisg: wow.. have you seen my bootchart for 5:40?
| |
12:25 | <alkisg> vbundi: I wonder if it could be your network driver that wastes cpu
| |
12:25 | vbundi: yup
| |
12:26 | <Lns> vbundi: have you disabled splash screen and watched bootup msgs?
| |
12:26 | <alkisg> vbundi: why don't you run a netperf to see how they handle the network?
| |
12:26 | (or iperf)
| |
12:26 | <vbundi> Lns: yes, aside from the mount messages I get to stare at Starting LTSP... for a few minutes
| |
12:27 | <alkisg> vbundi: If you see a very high cpu usage with a low network speed, then the driver might be your problem
| |
12:27 | <Lns> vbundi: do you have remote syslog enabled?
| |
12:27 | <vbundi> Lns: don't think so
| |
12:27 | <Lns> k
| |
12:27 | <vbundi> alkisg
| |
12:27 | alkisg: network driver?
| |
12:27 | <alkisg> yup, just an idea..
| |
12:27 | <vbundi> Lns: how would I enable remote syslog...
| |
12:28 | <Lns> vbundi: you don't want to ;)
| |
12:28 | vbundi: what about network swap..?
| |
12:28 | how many terminals do you have? do they all boot up at the same time?
| |
12:28 | <vbundi> Lns: oh, heh
| |
12:28 | Lns: I'm just testing right now running 1 terminal trying to boot from a default Karmic Setup
| |
12:29 | GodFather has quit IRC | |
12:29 | <Lns> ah
| |
12:29 | have you gone through the client's bios and disabled/optimized for thin client environment?
| |
12:30 | <vbundi> yeah
| |
12:30 | <Lns> such as, disable local disk controllers, upped video ram, etc
| |
12:30 | k
| |
12:30 | so...it's bootup and regular usage sludgy
| |
12:30 | network driver seems like a good place to start like alkisg said
| |
12:32 | <vbundi> Lns: yep did all that
| |
12:32 | Lns: let me check to see what chipset it's using
| |
12:33 | <the_fronny> vbundi: Here: http://ltsp.mirrors.tds.net/pub/ltsp/utils/. You'll want ltsp-utils. BUT if you have 256MB clients, AND their video is well supported by ltsp5 and the host you're using, ltsp-4.2 is not your best choice.
| |
12:33 | good luck
| |
12:33 | the_fronny has quit IRC | |
12:33 | <vbundi> cool
| |
12:34 | netperf shows I'm getting 94Mbit
| |
12:34 | <alkisg> Is that from a *local* terminal?
| |
12:34 | (otherwise you just run it locally on the server....)
| |
12:35 | <vbundi> ran in from this box to that server
| |
12:35 | <alkisg> "box" == gnome-terminal?
| |
12:35 | !localxterm
| |
12:35 | <ltspbot> alkisg: "localxterm" :: while sitting on a thin client, open a gnome terminal. In that, run: ltsp-localapps xterm. An xterm will open. That xterm runs locally, so any commands you enter there are executed directly on the client.
| |
12:35 | <vbundi> box = this computer not a terminal ;)
| |
12:36 | <alkisg> OK, just making sure. So you installed netperf on the chroot? And, CPU usage while getting 94 mbit?
| |
12:36 | <vbundi> no I didn't install netperf on the chroot, just tested from this workstation... I didn't realise that's what you meant till you just said it ;P
| |
12:37 | I guess if I want to test THAT network driver I should probably use it.
| |
12:37 | <alkisg> OK, then you just benchmarked your server's speed :)
| |
12:37 | <vbundi> yea and this machine ;P
| |
12:37 | <alkisg> You can install it (or copy it) directly on the client if you want
| |
12:37 | <Lns> hehe
| |
13:12 | vagrantc has joined #ltsp | |
13:16 | Kicer86 has joined #ltsp | |
13:29 | puck1 has joined #ltsp | |
13:31 | <puck1> How can I tell if my NFS server is responding fast enough? I have an LTSP server that is running very slow at times and was thinking the NFS access time may be the problem.
| |
13:38 | :-/
| |
13:39 | <vbundi> the server is slow or the clients are
| |
13:40 | <puck1> The clients are slow. The server is a little slow but the clients come to a crawl
| |
13:41 | <vbundi> and you think it might be a network problem?
| |
13:42 | <puck1> I have about 20 thin clients with firefox running as local apps. When I try to start GIMP or something similar everything comes to a crawl
| |
13:43 | i am taking a shot at something. It does not appear to be processor related. I have a core 2 quad running at 2.8Gh and it appears to have some room left.
| |
13:43 | <vbundi> hmm, you could try installing netperf in your chroot and on the nfs server and checking the connection between a terminal and that server
| |
13:44 | make sure your network is working well, your'e running 100Mbit?
| |
13:44 | <puck1> I am not familiar with netperf
| |
13:44 | <vbundi> neither was I an hour ago
| |
13:44 | <puck1> Yes 100Mbit to the clients and gig to the server
| |
13:45 | OK I'll look it up. Thanks
| |
13:45 | <vbundi> you apt-get install netperf on your endpoints and run netperf between them
| |
13:45 | it checks your network performance, makes sure you aren't having problems with ur pipes
| |
13:45 | it's pretty simple.. if you run into trouble gimmie a shout
| |
13:46 | <puck1> Thanks for your help. It will be tomorrow before I can get back to you, I am in Turkey and have to put the kids to bed.
| |
13:47 | <vbundi> ah cool, I'll be here.. and I'm sure someone with real knowledge will be around too ;)
| |
13:53 | <alkisg> puck1: do you have LDM_DIRECTX=true?
| |
13:54 | puck1: also, check this: https://help.ubuntu.com/community/UbuntuLTSP/FlowControl
| |
14:01 | <vbundi> alkisg: when I run ethtool -a eth0 I get an error
| |
14:01 | Cannot get device pause settings: Operation not supported
| |
14:02 | <alkisg> vbundi: you have a mixed mode network?
| |
14:02 | I.e. gigabit server and 100 mbps clients?
| |
14:02 | <vbundi> yes
| |
14:02 | <alkisg> Did you ran that as root?
| |
14:02 | <vbundi> yep
| |
14:03 | <alkisg> Then your nic driver doesn't support that. Is that realtek?
| |
14:03 | <vbundi> intel
| |
14:03 | <alkisg> Hmmm that doesn't sound right...
| |
14:04 | In any case, if you have a managed switch, you should do it from there
| |
14:04 | <vbundi> lemme try another box, it didn't work on my attansic one.. but it seems to be a weird nic as it is
| |
14:04 | <alkisg> If not... yeah, you should disable flow control on the server
| |
14:05 | <vbundi> so I want flow control disabled on my 1gig ports
| |
14:05 | well if I disable it in the switch I'd want to make sure it was disabled on my server as well still right
| |
14:07 | <alkisg> No, if your switch doesn't accept pause packets, then it doesn't matter what the server does
| |
14:07 | *doesn't *send*
| |
14:09 | <vbundi> oh so even if the server sends a pause packet it'll be dropped by the switch?
| |
14:09 | <alkisg> No it's the other way around
| |
14:09 | If the switch doesn't send pause packets, then the server doesn't have any reason to slow down
| |
14:10 | (but of course it slows down by tcp mechanisms - just not ethernet ones, which are the problem)
| |
14:11 | <vbundi> ok so I've got a managed switch, I've turned flow control OFF, if flow control is still ON at each endpoint it doesn't matter as long as the switch is off?
| |
14:11 | <alkisg> Yes
| |
14:11 | (and we only care about the server ==> switch traffic actually)
| |
14:12 | <vbundi> oh I thought it was point to point kinda thing, ie if it was a dumb switch, the endpoint would send a pause
| |
14:13 | which I guess it could be but you're saying if the switch has flow control off on that port it will ignore pause packets anyway
| |
14:13 | in the case of a "smart" switch
| |
14:14 | sorry if I'm spamming about nothing.. :)
| |
14:15 | shawnp0wers has quit IRC | |
14:19 | <alkisg> The best way to check is to run netperf from e.g. 10 clients together, and verify that you get more than 900 mbps on the server.
| |
14:24 | <vbundi> just make an init script that runs netperf -H <serverip> ?
| |
14:24 | <alkisg> No no, do it by hand...
| |
14:25 | *manually...
| |
14:25 | <vbundi> lol
| |
14:25 | <alkisg> See the command I used here: https://help.ubuntu.com/community/UbuntuLTSP/Trunking#Benchmarks
| |
14:26 | You just run this command on 10 clients, and in 1-2 minutes you'll know if your network is OK or not..
| |
14:26 | <vbundi> tc console = ?
| |
14:26 | <alkisg> Yes, from the tc console
| |
14:26 | <vbundi> ohhh tc = thin client
| |
14:26 | was wondering what tc console meant
| |
14:26 | <alkisg> Ah
| |
14:27 | <vbundi> oh so you're serious when you mean do it by hand
| |
14:27 | <alkisg> Yup, it doesn't take long.... just 10 commands
| |
14:27 | <vbundi> like run over to each terminal and run that command from a local xterm
| |
14:27 | <alkisg> Right
| |
14:27 | <vbundi> it does take long if you have 10 terminals spread out over a decent sized office ;P
| |
14:28 | <alkisg> Heh ... well, you could also use ssh
| |
14:28 | (but that's another story)
| |
14:28 | cliebow has quit IRC | |
14:28 | <vbundi> oh yea I guess heh
| |
14:30 | cool documentation, I haven't tried bonding before
| |
14:31 | <alkisg> Thanks
| |
14:33 | puck1 has left #ltsp | |
14:35 | sbalneav has joined #ltsp | |
14:36 | |Paradox| has joined #ltsp | |
14:36 | <vbundi> sbalneav: you came back!
| |
14:36 | <sbalneav> yeah, I just had to run off for a bit
| |
14:36 | Afternoon all
| |
14:37 | <vbundi> thought we pissed you off with the ltsp4 chat
| |
14:37 | <sbalneav> (&%(&^%( DSL's been whacked out all day
| |
14:37 | Nah, I don't care about that.
| |
14:38 | <vbundi> so you say you've got TM5700's running LTSP5 pretty well?
| |
14:38 | <sbalneav> I think it's silly people spending time trying to keep ltsp 4.2 hobbling along, as opposed to fixing things that don't work in ltsp5, but that's me.
| |
14:38 | For linux, yeah
| |
14:38 | I don't use an rdesktop script
| |
14:39 | I tested my hp term about 3 weeks ago.
| |
14:39 | with lucid.
| |
14:39 | <vbundi> well I hadn't really been trying them running just linux desktops so I'll try that
| |
14:40 | I thought running rdesktop would be just as quick though
| |
14:40 | <sbalneav> rdesktop's had problems, I don't know what. Gadi's the rdesktop screen script guy.
| |
14:41 | I've got:
| |
14:42 | ah, sorry, I've got a TM5500
| |
14:42 | It's still transmeta, 256 meg
| |
14:43 | Could be different video card, though.
| |
14:43 | What kind of video card's in it?
| |
14:44 | <vbundi> radeon
| |
14:46 | <sbalneav> What video driver are you using? Just letting it autodetect?
| |
14:46 | Maybe it's picking vesa
| |
14:50 | Q-FUNK has joined #ltsp | |
14:50 | <Q-FUNK> re
| |
14:50 | <stgraber> mgariepy: ping
| |
14:50 | mgariepy: Gadi would need some help ;)
| |
14:50 | <mgariepy> hey
| |
14:51 | what can i do for you Gadi1 ?
| |
14:55 | <vbundi> sbalneav: I ran lspci -vv -nn|grep radeon and it showed up loading 2 radeon modules
| |
14:56 | <alkisg> vagrantc: right now, the users can't authenticate themselves on the clients (e.g. on fat clients, if gnome-screensaver runs, the users can't unlock it). Is this by design, or could I propose some workaround, e.g. by remembering the password from ldm and generating an appropriate shadow entry?
| |
14:56 | <vbundi> sbalneav: are you able to get me an lspci output on your terminal to compare hardware?
| |
14:56 | Kicer86 has quit IRC | |
14:59 | <vagrantc> alkisg: definitely not by design... just simply difficult to do well.
| |
14:59 | alkisg: caching the password locally is kind of unpleasant.
| |
15:00 | <alkisg> vagrantc: would that approach be acceptable? i.e. as soon as ldm authenticates, do a passwd or something, and discard the password
| |
15:01 | <vagrantc> alkisg: seems risky.
| |
15:01 | <alkisg> How about caching the crypt?
| |
15:02 | The TC root will be the only one who can read it, and even if he can read it, he'd have to uncrypt it, which should be rather safe...
| |
15:02 | It won't be cached for long - just until the user is authenticated
| |
15:03 | I guess we can even do that from inside sshutils.c, so that it doesn't "leave" the process at all...
| |
15:03 | <sbalneav> vbundi: It'll have to wait until tonight, I'm at work atm
| |
15:05 | <vbundi> sbalneav: sure thing, I suppose I could see if I can find the alternative specs on google for those clients
| |
15:10 | hersonls has quit IRC | |
15:10 | <alkisg> vagrantc: e.g. we can put a crypt + append passwd in ldm.c, right after loginfo(_("Established ssh session.")); This would be completely safe imho.
| |
15:11 | ldm knows the user password at that point, and can crypt it.
| |
15:13 | *append shadow, I mean
| |
15:14 | <vagrantc> alkisg: the whole premise of storing passwords, even crypted, allows a compromised terminal to cache it or upload it somewhere and decrypt it on their own time...
| |
15:14 | asglayobn has joined #ltsp | |
15:14 | <alkisg> That's why I asked if it was by design :)
| |
15:15 | <vagrantc> alkisg: to do this properly, i think we'll have to wait for sbalneav's libpam-ssh stuff
| |
15:15 | <alkisg> vagrantc: how would that help?
| |
15:15 | <Gadi1> bot a root-only owned file in TC RAM is no less secure than a root-only file on a hard drive
| |
15:15 | |Paradox| has quit IRC | |
15:16 | <vagrantc> Gadi1: but storing it in two places at least doubles the opportunity to compromise it.
| |
15:16 | <alkisg> ...and I bet that if someone has compromised a TC, he'd use a keylogger or a fake gtkgreeter, and not try to decrypt the shadow entry ;)
| |
15:16 | <vbundi> ^
| |
15:17 | <alkisg> But sure, there are some cases where it makes sense, e.g. if it is compromised a long time *after* the users logs in
| |
15:17 | (and the ram is overwritten etc etc)
| |
15:17 | <vagrantc> it's a concern. do with it what you will.
| |
15:18 | <alkisg> I'm just asking - I won't go ahead to do anything unless there's consensus :)
| |
15:19 | Or, we could put it as an lts.conf option
| |
15:19 | (shouldn't be much more unsafe than ldm_directx etc...)
| |
15:19 | How would libpam_ssh help?
| |
15:19 | pmatulis has quit IRC | |
15:20 | <vbundi> so on a fat client they're doing the remote session thing, why is gnome-screensaver popping up at all
| |
15:21 | <alkisg> A fat client doesn't run a remote session, it runs a local session
| |
15:21 | <vbundi> feel free to shut me up, maybe I'm missing this whole thing completely
| |
15:21 | Q-FUNK has left #ltsp | |
15:22 | jammcq has joined #ltsp | |
15:23 | <jammcq> stgraber: hey, I see your blogpost about ltsp-cluster made it to fsdaily. good job!
| |
15:23 | <alkisg> vagrantc, thank you for your time... :)
| |
15:24 | evilx has quit IRC | |
15:25 | <vagrantc> alkisg: maybe it's not libpam-ssh ... what it does is allows local pam authentication if you can ssh to the ssh authentication server.
| |
15:26 | <alkisg> sbalneav, will all that pam, nss etc cache things locally? E.g. crypts?
| |
15:27 | Or will it use sshlib2 every time it needs to verify the user password again?
| |
15:28 | evilx has joined #ltsp | |
15:28 | the_fronny has joined #ltsp | |
15:28 | <stgraber> jammcq: yep, looks like we quite well managed to spread the word this time ;)
| |
15:29 | <sbalneav> alkisg: So far, I haven't looked at any caching
| |
15:30 | <alkisg> sbalneav: so if gnome-screensaver comes up, it will ssh to the server again to check if the user password is ok?
| |
15:30 | <jammcq> alkisg: isn't the screensaver running on the server anyway?
| |
15:31 | assuming it's not a local app
| |
15:31 | <alkisg> jammcq: not for fat clients - but maybe I chose the wrong example...
| |
15:31 | <jammcq> ah, so it would be a local app
| |
15:31 | <alkisg> I should choose something else, applicable for thin clients as well...
| |
15:37 | asglayobn is now known as |Paradox| | |
15:39 | <alkisg> Anyway thank you all, I'll just disable fat client screen locking for now, and maybe I'll need to bring it up again if some more "serious" problem comes up....
| |
15:40 | (e.g. keyrings? hmm....)
| |
15:40 | <vbundi> how are you connecting to the remote end?
| |
15:40 | like what are you using
| |
15:41 | Polyglot has joined #ltsp | |
15:41 | <alkisg> vbundi: ubuntu lucid has a new fat client plugin
| |
15:41 | Polyglot has left #ltsp | |
15:41 | <alkisg> It's very nice for powerful stations, but it still needs some work.
| |
15:42 | <vbundi> oh I thought you were talking about the old GDM remote session thing
| |
15:42 | etyack has quit IRC | |
15:42 | <alkisg> No it's more of a "remote disk" thing
| |
15:43 | <vbundi> oh kind of like roaming profiles for a M$ setup
| |
15:43 | etyack1 has joined #ltsp | |
15:43 | <alkisg> No, remote disk for root, not for home
| |
15:43 | (root = the whole /)
| |
15:45 | <vbundi> oh
| |
15:46 | so what you're essentially in a chroot then right
| |
15:53 | johnny has left #ltsp | |
15:54 | johnny has joined #ltsp | |
15:56 | vvinet has quit IRC | |
16:28 | mgariepy has quit IRC | |
16:29 | the_fronny has quit IRC | |
16:29 | mikkel has quit IRC | |
16:45 | |Paradox| has quit IRC | |
16:47 | etyack1 has quit IRC | |
16:48 | alkisg has quit IRC | |
16:49 | mgariepy has joined #ltsp | |
16:58 | jammcq has quit IRC | |
17:08 | <vbundi> wow tried booting a thick client to LTSP newer onboard nvidia.. I get a readable display but the resolution is all weird, not a typical computer one, doesn't even say on the monitor "info" osd
| |
17:08 | grantk has left #ltsp | |
17:09 | <vbundi> do you have to add in nvidia modules? I figured they'd be built in
| |
17:12 | johnny has left #ltsp | |
17:13 | johnny has joined #ltsp | |
17:20 | CAN-o-SPAM has quit IRC | |
17:24 | <Briareos1> good night altogether
| |
17:25 | Briareos1 has quit IRC | |
17:25 | Gadi1 has quit IRC | |
17:25 | ogra has quit IRC | |
17:25 | Egyptian[Home] has quit IRC | |
17:28 | ogra has joined #ltsp | |
17:28 | Egyptian[Home] has joined #ltsp | |
17:29 | Gadi1 has joined #ltsp | |
17:34 | Gadi1 has left #ltsp | |
17:37 | mgariepy has quit IRC | |
17:43 | frederickjh has quit IRC | |
18:07 | vvinet has joined #ltsp | |
18:15 | bobby_C has quit IRC | |
19:03 | Lns has quit IRC | |
19:21 | vagrantc has quit IRC | |
19:41 | etyack has joined #ltsp | |
19:47 | Faithful has quit IRC | |
19:58 | jcastro has joined #ltsp | |
20:02 | Faithful has joined #ltsp | |
20:04 | pmatulis has joined #ltsp | |
20:21 | GGD has quit IRC | |
20:45 | japerry has quit IRC | |
20:46 | pmatulis has quit IRC | |
21:20 | Gadi_eeepc has joined #ltsp | |
21:21 | mushroomtwo has joined #ltsp | |
21:21 | morfic has quit IRC | |
21:21 | mushroomblue has quit IRC | |
21:22 | morfic has joined #ltsp | |
22:06 | etyack has left #ltsp | |
22:16 | mgariepy has joined #ltsp | |
22:33 | mgariepy has quit IRC | |
22:39 | Sorrel has quit IRC | |
23:03 | testoutit has joined #ltsp | |
23:18 | F-GT has quit IRC | |
23:27 | shogunx has quit IRC | |
23:31 | johnny has left #ltsp | |
23:32 | johnny has joined #ltsp | |
23:34 | F-GT has joined #ltsp | |