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


Channel log from 11 February 2010   (all times are UTC)

00:03map7 has joined #ltsp
00:10alkisg has joined #ltsp
00:16F-GT has quit IRC
00:32F-GT has joined #ltsp
00:34alkisg has quit IRC
01:23alkisg has joined #ltsp
01:55pts_ has joined #ltsp
01:58Gadi_eeepc has quit IRC
01:58Egyptian[Home] has quit IRC
01:58waldo323 has quit IRC
01:58jhutchins has quit IRC
01:58HardDisk has quit IRC
01:58kusznir has quit IRC
01:58stgraber has quit IRC
02:01stgraber has joined #ltsp
02:01HardDisk has joined #ltsp
02:02jhutchins has joined #ltsp
02:06kusznir has joined #ltsp
02:08Gadi_eeepc has joined #ltsp
02:12Egyptian[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:19gnunux 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:25Gadi_eeepc has quit IRC
02:26
<alkisg>
(and copy it to /sbin/ in the initramfs from the udhcp hook?)
02:27Gadi_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:07klausade has quit IRC
03:21comfrey_ has quit IRC
03:21comfrey has quit IRC
03:22evilx 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:49ogra has quit IRC
03:50ogra has joined #ltsp
03:54vagrantc has quit IRC
04:22alkisg has quit IRC
04:27mikkel has joined #ltsp
05:01hersonls has joined #ltsp
05:19lucascoala has quit IRC
05:23lucascoala has joined #ltsp
05:26sene has quit IRC
05:29alkisg has joined #ltsp
05:59frederickjh has joined #ltsp
06:11bassie 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:12lucascoala 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:16avlis 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:22pmatulis 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:25bobby_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:36bassie has quit IRC
06:38bassie 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:52vvinet 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:55Gadi_eeepc has left #ltsp
06:55scottmaccal 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:58bobby_C has quit IRC
06:58bobby_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:10avlis has quit IRC
07:12alkisg has quit IRC
07:14
<bassie>
gonna do a fresh install and experiment in next wednesday...
07:15avlis has joined #ltsp
07:18GodFather has joined #ltsp
07:20evilx has joined #ltsp
07:23mgariepy has joined #ltsp
07:30vvinet has joined #ltsp
07:30Briareos1 has joined #ltsp
07:30
<Briareos1>
good afternoon
07:38Faithful has joined #ltsp
07:45flip_ has joined #ltsp
07:47stgraber has quit IRC
07:47stgraber has joined #ltsp
07:48flip_ is now known as Sorrel
08:05grantk has joined #ltsp
08:06grantk has left #ltsp
08:06grantk has joined #ltsp
08:21grantk has left #ltsp
08:21grantk has joined #ltsp
08:23pimpministerp has joined #ltsp
08:24pimpministerp has quit IRC
08:26wftl has quit IRC
08:33waldo323 has joined #ltsp
08:44pts_ has quit IRC
08:44wftl 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:01bobby_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:05shawnp0wers 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:16bobby_C has joined #ltsp
09:17cliebow 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:32alkisg has joined #ltsp
09:32waldo323 has quit IRC
10:11CAN-o-SPAM has joined #ltsp
10:11tstafford has joined #ltsp
10:11GGD has joined #ltsp
10:15etyack has joined #ltsp
10:17dberkholz has quit IRC
10:17dberkholz has joined #ltsp
10:28staffencasa 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:31appiah has quit IRC
10:32
<ogra>
or ubuntu-kernel@
10:32gnunux has quit IRC
10:34Appiah has joined #ltsp
10:47avlis 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:44Gadi1 has joined #ltsp
11:53the_fronny has joined #ltsp
11:53tstafford has quit IRC
11:55tstafford 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:56reynolds 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:11TDK 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:12TDK has quit IRC
12:13
<vbundi>
HP T5700's TM5700 (800mhz) 256MB Ram
12:13Lns 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:17sbalneav 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:17reynolds 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:24scottmaccal 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:29GodFather 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:33the_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:12vagrantc has joined #ltsp
13:16Kicer86 has joined #ltsp
13:29puck1 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:15shawnp0wers 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:28cliebow 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:33puck1 has left #ltsp
14:35sbalneav 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:50Q-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:56Kicer86 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:10hersonls 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:14asglayobn 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:19pmatulis 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:21Q-FUNK has left #ltsp
15:22jammcq 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:24evilx 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:28evilx has joined #ltsp
15:28the_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:37asglayobn 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:41Polyglot has joined #ltsp
15:41
<alkisg>
vbundi: ubuntu lucid has a new fat client plugin
15:41Polyglot 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:42etyack 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:43etyack1 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:53johnny has left #ltsp
15:54johnny has joined #ltsp
15:56vvinet has quit IRC
16:28mgariepy has quit IRC
16:29the_fronny has quit IRC
16:29mikkel has quit IRC
16:45|Paradox| has quit IRC
16:47etyack1 has quit IRC
16:48alkisg has quit IRC
16:49mgariepy has joined #ltsp
16:58jammcq 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:08grantk has left #ltsp
17:09
<vbundi>
do you have to add in nvidia modules? I figured they'd be built in
17:12johnny has left #ltsp
17:13johnny has joined #ltsp
17:20CAN-o-SPAM has quit IRC
17:24
<Briareos1>
good night altogether
17:25Briareos1 has quit IRC
17:25Gadi1 has quit IRC
17:25ogra has quit IRC
17:25Egyptian[Home] has quit IRC
17:28ogra has joined #ltsp
17:28Egyptian[Home] has joined #ltsp
17:29Gadi1 has joined #ltsp
17:34Gadi1 has left #ltsp
17:37mgariepy has quit IRC
17:43frederickjh has quit IRC
18:07vvinet has joined #ltsp
18:15bobby_C has quit IRC
19:03Lns has quit IRC
19:21vagrantc has quit IRC
19:41etyack has joined #ltsp
19:47Faithful has quit IRC
19:58jcastro has joined #ltsp
20:02Faithful has joined #ltsp
20:04pmatulis has joined #ltsp
20:21GGD has quit IRC
20:45japerry has quit IRC
20:46pmatulis has quit IRC
21:20Gadi_eeepc has joined #ltsp
21:21mushroomtwo has joined #ltsp
21:21morfic has quit IRC
21:21mushroomblue has quit IRC
21:22morfic has joined #ltsp
22:06etyack has left #ltsp
22:16mgariepy has joined #ltsp
22:33mgariepy has quit IRC
22:39Sorrel has quit IRC
23:03testoutit has joined #ltsp
23:18F-GT has quit IRC
23:27shogunx has quit IRC
23:31johnny has left #ltsp
23:32johnny has joined #ltsp
23:34F-GT has joined #ltsp