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


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

01:26F-GT has quit IRC
01:45F-GT has joined #ltsp
02:12morfic is now known as phr0zen
02:13phr0zen is now known as morfic
02:54alkisg has joined #ltsp
02:58alkisg has quit IRC
03:00Patina has quit IRC
03:03alkisg has joined #ltsp
03:05alkisg has quit IRC
03:12alkisg has joined #ltsp
03:23johnny has left #ltsp
03:24alkisg has quit IRC
03:25johnny has joined #ltsp
03:35alkisg has joined #ltsp
03:43nokia3510 has joined #ltsp
03:51alkisg has quit IRC
03:53alkisg has joined #ltsp
03:56johnny has left #ltsp
04:00johnny has joined #ltsp
04:19ogra has quit IRC
04:20ogra has joined #ltsp
04:50Sarten-X2 has quit IRC
05:01sene has joined #ltsp
05:56pem725 has quit IRC
05:56elias_a_ has quit IRC
06:00elias_a has joined #ltsp
06:11pem725 has joined #ltsp
06:24
<alkisg>
pem725, how are your fat clients today? :)
06:53GGD_ has quit IRC
07:28GGD has joined #ltsp
07:31mikkel has joined #ltsp
08:04F-GT has quit IRC
08:07Selveste1_ is now known as Selveste1
08:20F-GT has joined #ltsp
08:51hersonls has joined #ltsp
08:52alkisg has quit IRC
08:59
<pem725>
alkisg: clients seem to hang just after mount commands fail. I am checking into this further.
09:15Sarten-X has joined #ltsp
09:34alkisg has joined #ltsp
09:51
<pem725>
alkisg: my fat clients won't boot. They hang after a few mount errors - status 1 - saying they were already mounted.
09:51
do you think this is a problem with nfs competing with ssh?
09:51
<alkisg>
pem725: that's Usual", not the actual error
09:51
Ubuntu doesn't use nfs by dfault
09:51
default
09:51
So try to remove "quiet splash" from /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default, to better see any error messages
09:52
<pem725>
yeah, I might have gotten my instructions messed up and installed nfs and setup my exports. I will kill that just in case.
09:52
ok
09:56
alkisg: I got it to boot and now it boots to a login prompt.
09:57
<alkisg>
X login or console login?
09:57
<pem725>
I did two things...stopped nfs (and commented out export line) and got rid of quiet splash.
09:57
console login
09:58
<alkisg>
That might be a graphics driver problem. What graphics cards do you clients have?
09:58
<pem725>
nvidia
09:58
I used this command to setup the fatclient:
09:58
<alkisg>
Lucid or Karmic?
09:58
<pem725>
ltsp-build-client --arch i386 --fat-client --fat-client xubuntu-desktop
09:58
<alkisg>
Ouch
09:58
<pem725>
would that be sufficient to get me an x login?
09:59
Karmic
09:59
uh oh...
09:59
<alkisg>
I don't think anyone has tried xubuntu-desktop with fat clients...
09:59
What DM does xubuntu have?
09:59
<pem725>
xfce
09:59
<alkisg>
(display manager, like gdm or kdm)
10:00
<pem725>
oh, sorry...usually gdm
10:00
<alkisg>
Ah, if it's gdm it should work then
10:00
<pem725>
I probably need to install gdm in the chroot, right?
10:00
<alkisg>
If xubuntu-desktop depends on that, it should already be installed
10:00
Is that the actual command line that you used?
10:00
<pem725>
I can start from scratch with gnome just to get one up and going.
10:00
yes
10:00
<alkisg>
Or did you use --fat-client-desktop ?
10:01
<pem725>
nope, I used the one I pasted into the IRC
10:01
<alkisg>
Then you have an ubuntu desktop :)
10:01
The command line parameter to select a xubuntu desktop would be --fat-client-desktop
10:01
OK, so: sudo gedit /var/lib/tftpboot/ltsp/i386/lts.conf
10:01
In that, put:
10:02
[Default]
10:02
XSERVER=vesa
10:02
And reboot your client...
10:02
<pem725>
OK
10:04
still gives me a console login.
10:05
<alkisg>
What's your ltsp version? dpkg -l ltsp-server
10:05
<pem725>
I will start over with the build client just to make sure I get this right.
10:05
5.2-0ubuntu2~ppa1~karmic1
10:06
what command should I use to build the fat client?
10:06
<alkisg>
Let me give you an ltsp-build-client.conf
10:06
<pem725>
ok
10:07
<alkisg>
sudo mkdir -p /etc/ltsp
10:07
sudo gedit /etc/ltsp/ltsp-build-client.conf
10:07
And paste those lines:
10:07
ARCH=i386
10:07
FAT_CLIENT_DESKTOPS="ubuntu-desktop"
10:07
MOUNT_PACKAGE_DIR="/var/cache/apt/archives"
10:08
Then just run sudo ltsp-build-client with no parameters at all.
10:08
Do you have an non-english locale?
10:09
If so, you might also add something like LOCALE="el_GR.UTF-8"
10:09
<pem725>
no non-english locale.
10:09
<alkisg>
OK
10:09
Check the ltsp-build-client output for any errors
10:09
<pem725>
I am rm -rf my previous fat client.
10:10
<alkisg>
OK
10:11
<pem725>
so when it builds the fatclient, does it put in soft links to existing software installed on the server or must I install the software I want to run locally into the chroot?
10:13
<alkisg>
It installs about what you can find in a live ubuntu cd
10:14
<pem725>
got it.
10:14
<alkisg>
So if you want more, you must install it manually after the building is done
10:14
<pem725>
when I want say google-chrome, I need to install it in the chroot, right?
10:14
<alkisg>
Right
10:15
<pem725>
I'm going to try another client than my previous this go around.
10:15
<alkisg>
You could also add a LATE_PACKAGES in ltsp-build-client.conf
10:15
<pem725>
the client I kept getting a console login was an eeepc
10:15
<alkisg>
And add any packages you wanted to install there
10:15
<pem725>
ah, perfect.
10:15
that would be great.
10:16
<alkisg>
And EARLY_MIRRORS for any mirrors (like, for chrome)
10:16
<pem725>
do you suggest I build clients from scratch when updating or just apt-get update/upgrade in the chroot?
10:17
<alkisg>
update/upgrade
10:17
Unless you upgrade to lucid, where a new ltsp-build-client would be better.
10:17
<pem725>
OK
10:17
how far is lucid along now?
10:18
is it ready for install in a production environment?
10:18
<alkisg>
Nope. https://wiki.ubuntu.com/LucidReleaseSchedule
10:18
<pem725>
k
10:18
<alkisg>
I do work with it on my laptop, it's stable enough, but it's still alpha, not in any way ready for production
10:18
<pem725>
good to know.
10:18
I usually hold back from upgrades for about 4-6 months.
10:18
<alkisg>
But for fat client tests it might be more stable than karmic :D
10:18
<pem725>
post release.
10:19
yeah, that is why I asked.
10:19
I figured it might be the case.
10:19
does order matter in the ltsp-build-client.conf file?
10:19
<alkisg>
No
10:19
<pem725>
OK
10:19
<alkisg>
Hmmm maybe I should write a small wiki page for fat clients...
10:20
<pem725>
that would be great.
10:20
if you need someone to try out your steps, I would be a happy and willing participant.
10:21
<alkisg>
OK, I'll do that now.
10:21
<pem725>
is there a man page or some online docs for ltsp-build-client.conf?
10:21
<alkisg>
I've made a GUI for building fat client chroots and managing them, but it's mostly in Greek... :-/
10:21
Nope
10:22
<pem725>
I always wanted to learn Greek.
10:22
probably not the best time to learn though...
10:22
<alkisg>
Heh :)
10:22
OK, trying the non-GUI way, to write the wiki page...
10:23
<pem725>
when I specify LATE_PACKAGES, do I space separate the packages or put them in quotes, or what?
10:23
<johnny>
alkisg, considered trying to see if packagekit could use a chroot to install into?
10:23
or even ubuntu software center?
10:24
<alkisg>
pem725: space separated
10:24
johnny: I've never tried packagekit...
10:24
<pem725>
alkisg: no quotes, right?
10:24
<johnny>
imo.. if you want to make it easy to install apps into a chroot, you should use the same gui tools that are on the server
10:24
<alkisg>
pem725: LATE_PACKAGES="package1 package2"
10:24hersonls has quit IRC
10:24
<pem725>
ah, perfect.
10:25
<johnny>
alkisg, and if you use packagekit directly.. you get tools that work on many distros
10:25
<pem725>
how about for MIRRORS?
10:25
same?
10:25
<alkisg>
johnny: I think the best way would be to use a different partition on the server, and *boot with it normally* to manage the chroot :)
10:25
<johnny>
including all supported distros by ltsp
10:25
sure.. except this time.. no booting
10:25
that's a big deal imo
10:25
would be better if you could say
10:25
$packagekitapi --root=/path/to/chroot
10:25
<alkisg>
nbd can even export the new partition directly, so no ltsp-update-image anymore
10:25
<johnny>
or perhaps even a wrapper around it
10:26
partitions suck too
10:26
too much effort for the user
10:26
unless they were lvm by default
10:26
<alkisg>
A .vmdk (vbox disk) would be fine as well...
10:26
And they could manage it with vbox
10:26
<johnny>
except that's not open is it..
10:26
oh.. wait.. i think i have it backwards
10:26
<alkisg>
The format? I'd bet it is...
10:26
<johnny>
for some reason i was thinking vmware..
10:26
not virtualbox :)
10:27
<alkisg>
Even lxc (linux containers) could be useful for managing the chroot
10:27
<johnny>
you could.. but i think trying to use the open tools we have right now woulc be good
10:27
and would make packagekit more useful..
10:28jammcq has quit IRC
10:28
<johnny>
not just for fat clients too alkisg ..
10:28
but regular ltsp clients with local apps
10:28
which you can't rely on booting from to be able to install anything
10:29
<alkisg>
johnny: is packagekit available for ubuntu right now?
10:29
Or is it something that needs work to get integrated?
10:29
<johnny>
thought it was..
10:29
it works on debian a bit
10:29
it's nowhere near as good at apt directly
10:29
<alkisg>
Well it'd be better if we relied on *existing* technologies :D
10:29
<johnny>
but for just installing and removing packages
10:30
it works for installing and removing software on multiple distros
10:30
including gentoo now i heard
10:30
i heard that months ago actually..
10:31
alkisg, packagekit is just a wrapper for common functions around the distro specific ways of doing it
10:31
it also integrates with policykit
10:31
<alkisg>
For me, fat clients should be managed from a GUI, like vbox or another server partition. That would allow the admin to even use sabayon, gconf etc to manage his chroot.
10:31
I don't see any reason for adding another layer of management
10:32
<johnny>
sure.. but you're forgetting regular chroots..
10:32
with localapps
10:32
<alkisg>
I don't really care about localapps. What can they offer, that fat clients cannot?
10:33
IMHO when fat clients are more mature, more people will stop using localapps and switch to fat clients
10:33
<johnny>
isn't there a ram constraint issue?
10:33
<alkisg>
I don't think there's any difference in firefox running as a localapp, as opposed to running in a thin client
10:33
Both would need 512 M
10:34
<johnny>
wait.. you're saying a standard ltsp thin client setup with the only local app being firefox..
10:34
is no worse on ram usage than a full fat client?
10:35
<alkisg>
Pretty much. Firefox needs 512 Mb. 50 more or less don't really make a difference, I think.
10:35
It *would* make a difference for other localapps, like sip phones, that are not so memory hungry as firefox
10:35
<johnny>
and what if people also want to use openoffice at the same time?
10:35
what would you do then?
10:35
use ltsp-remoteapps instead?
10:36
<alkisg>
No, fat clients for >= 512 Mb, thin clients for less
10:36
<johnny>
so you can really run both at the same time ?
10:36
in 512? and be OK?
10:36
with flash?
10:36
<alkisg>
Yes, with 512 Mb and a swap partition it's OK.
10:36
I'd only use localapps for light multimedia apps
10:37
(like the sip phone I said above)
10:37Egyptian[Home] has joined #ltsp
10:37
<alkisg>
But for firefox + flash + openoffice, I don't think they're better than fat clients...
10:40
<pem725>
alkisg: I'm getting closer. Now it is just hanging at a black screen.
10:40
I will check the terminal on the thin client to see what is up.
10:41markit has joined #ltsp
10:41
<markit>
hi, I've tried to upgrade my client chroot, following the usual steps (chroot, mount proc, export LTSP_HANDLE_DAEMONS=false, upgrade)
10:41
but I get this error when upgrading packages
10:42
Can not write log, openpty() failed (/dev/pts not mounted?)
10:42
<alkisg>
You can ignore that.
10:42
<markit>
is it normal? what did I did wrong?
10:42
<pem725>
alkisg: failed to connect to NBD server.
10:42
<markit>
debian sid, ltsp 5.2
10:43
alkisg: thanks :) btw, no solution so far for the atom thin clients, sigh
10:43
<alkisg>
pem725: at what point? any messages before or after that?
10:43
<johnny>
alkisg, hmm.. i'd like to give this a shot
10:43
thanks for the info.. i was assuming i couldn't handle it
10:43
it*
10:43
<markit>
alkisg: we also buy some mini-itx with intel atom, and they fail at boot also
10:43
<johnny>
I just picked up 512mb pc133.. for some old p3s in the 700-1ghz range
10:44
should be good enough right?
10:44
<alkisg>
markit: could you try with an ubuntu kernel (in case it has any firmware that the debian one doesn't have by default)?
10:44
<johnny>
they are at my store, just need to install :)
10:44
<markit>
seems that having a certain hardware work with GNU/Linux does not make sure it works with ltsp also, and it's very oddy
10:44
<pem725>
alkisg: yes, it says Negotiation: Error: server closed connection right after it ran /scripts/nfs-top with success.
10:44
<alkisg>
johnny: fat clients behave like "real" clients with a tad slower hard disk. So 512 would be enough, but of course not lightning fast...
10:44
<markit>
alkisg: do you mean download in my sqeeze client a kernel taken from ubuntu repository? will it work? is easy to do?
10:44
<alkisg>
pem725: sudo netstat -nap | grep 2000
10:45
<pem725>
tcp 0 0 0.0.0.0:2000 0.0.0.0:* LISTEN 1770/inetd
10:45
<alkisg>
pem725: anything weird with your dhcp? Is the ltsp server also the dhcp server?
10:46
Or do you have an external dhcp server around?
10:46
<pem725>
yes, both the same ltsp=dhcp server
10:46
<alkisg>
markit: I'm not sure how to try that. E.g. you could try with an ubuntu live cd, I guess..
10:46
<pem725>
the only thing weird is my internal ip addresses and the fact that I use fixed ip addresses for many of my clients.
10:46
<markit>
btw, is there an easy way to scan the subnet for available dhcp servers? I've tried to scan for dhcp port, but I have it triggered also by "not active" dhcp servers
10:47
<pem725>
I use 192.169.100.x internally.
10:47
<markit>
alkisg: I could install ltsp and configure in my laptop (ubuntu 9.10) and use it as ltsp server just for experiment
10:47
or create a virtual machine (KVM) with ubuntu
10:48
I'm very frustrated and disappointed for this problems, since atom based hardware is becoming common
10:48
<pem725>
alkisg: any thoughts on the error?
10:49
<markit>
btw, anyone here has a atom based, possibly gb ethernet, client working?
10:49
<alkisg>
pem725: sudo gedit /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default
10:49
pem725: in the place of "quiet splash" there, put "break=mount" instead (no quotes)
10:49
That will get you a prompt right before the nbd error. You can try mounting manually there.
10:49
<pem725>
ok
10:50
when I get the prompt, how do I mount it manually?
10:51
<alkisg>
nbd-client server-ip 2000 /dev/nbd0
10:52
markit: well my daughter's atom booted fine with no problems at all.
10:52
<pem725>
alkisg: I get an error saying Server closed connection.
10:53
<alkisg>
pem725: any firewalls on your server?
10:53
<pem725>
I just did a clean install.
10:53
<alkisg>
A clean LTSP install, or a clean Karmic install?
10:54
<pem725>
I just tried to restart the nbd-server and it said "Cound not parse config file: Could not open config file"
10:54
<alkisg>
pem725: no, don't start it manually, it starts from inetd
10:54
<pem725>
both a clean Karmic and a clean LTSP.
10:54
OK
10:54
I won't try to restart it.
10:54
<alkisg>
To restart it you need to do: sudo service openbsd-inetd restart
10:55
<markit>
alkisg: what ethernet hardware does it has? what distro? debian? version of the client chroot? squeeze?
10:55shogunx has quit IRC
10:55
<markit>
I'm not sure, but I could say that with previous ltsp my netbook booted also
10:56
I've upgraded because new ethernet nic harware was not supported by older kernel
10:56
<pem725>
alkisg: I restarted inetd and still no joy.
10:56
<markit>
but now seems that netbook nor new hardware can boot anymore
10:56
<alkisg>
markit, ubuntu, multiple versions, all booted ok. I don't remember the NIC, but I think it isn't atheros
10:57
<markit>
alkisg: ok, I will try ubuntu then. Any debian packager/manteiner around?
10:57
<alkisg>
pem725: weird. Can you try nbd-client locally on your server?
10:58
pem725: is the image there? ls -l /opt/ltsp/images/i386.img
10:58
pem725: also, try `grep nbd /etc/inetd.conf`
11:00
<pem725>
alkisg: AHA!
11:00
I found the problem.
11:01
in the inetd.conf file, the image file was specified as my first attempt at the fat client fati386.
11:02
<alkisg>
Ah
11:02
OK, fix it and restart openbsd-inetd
11:02* alkisg reboots, brb...
11:02alkisg has quit IRC
11:04alkisg has joined #ltsp
11:05
<pem725>
alkisg: back to a console prompt.
11:05
so at least it works again but no X login.
11:06
<alkisg>
pem725: how big is your image? ls -l /opt/ltsp/images/i386.img
11:06
...because I think it finished *too* quickly :D
11:06
<pem725>
624M
11:07alkisg has quit IRC
11:07shogunx has joined #ltsp
11:09alkisg has joined #ltsp
11:09
<pem725>
alkisg: is 624M about the right size? As far as speed, my computer has a quad-processor with 16 GB of RAM..
11:10
it better be quick!
11:11
<alkisg>
I'm using much larger chroots, I'm not sure if 624 is OK. Could be.
11:11shogunx_ has joined #ltsp
11:11
<alkisg>
Try: sudo chroot /opt/ltsp/i386 dpkg -l gdm
11:12
And also with ldm, to verify that both of them are there.
11:12* alkisg is affected by the dreaded "Enter freezes X" Lucid bug :(
11:12
<pem725>
alkisg: both are installed
11:13shogunx has quit IRC
11:13
<alkisg>
pem725: sudo gedit /var/lib/tftpboot/ltsp/i386/lts.conf
11:13
<pem725>
another reason to steer clear of Lucid for now.
11:13
<alkisg>
SCREEN_02=shell
11:13
(under [Default] )
11:13
That should get you a console on the client, on the next reboot
11:13
In that console, try: X -configure
11:14
<pem725>
I didn't setup a root password. Is that still necessary?
11:14
<alkisg>
Not with SCREEN_02=shell
11:14
<pem725>
OK
11:14
<alkisg>
It's only necessary without it
11:14GGD has quit IRC
11:14
<pem725>
got it.
11:16
<alkisg>
Also try looking at the xorg logs at /var/log/Xorg.0.log, brb.
11:16
<pem725>
alkisg: I just ran X -configure and then tried to start X with the new xorg.conf.new file and it hangs with a black screen.
11:16
k
11:18
<alkisg>
pem725: does it *hang* there, or does e.g. the keyboard work?
11:18
Can you switch to vt1 with alt+ctrl+f1?
11:18
<pem725>
the keyboard still works.
11:18
it says "Setting master"
11:18
and then...
11:18
<alkisg>
OK, then try both SCREEN_02=shell and SCREEN_07=ldm
11:19
This way you'll be able to inspect from the shell what happens on ldm
11:19
E.g. run a `ps` etc
11:19
<pem725>
OK
11:19
<alkisg>
And another test, to verify that this isn't a fat client problem, you can set LTSP_FATCLIENT=false in lts.conf.
11:20
<pem725>
rebooting now.
11:20
ah, great.
11:20
<alkisg>
This will use the chroot as a thin client chroot.
11:20
<pem725>
I will try that too.
11:20
<alkisg>
ok, brb
11:21GGD has joined #ltsp
11:22
<pem725>
alkisg: on vt 7, I get tty=/dev/tty2
11:22
expr: syntax error
11:22
and then a prompt.
11:25
alkisg: when I try the thin client (via LTSP_FATCLIENT=false) it works!
11:26
alkisg: whoa! there is something really bizarre. All the text and desktop are upside down and backwards.
11:26
I thought I was reading Russian at first.
11:29
<alkisg>
pem725: ignore that, that's because you have intel client + nvidia drivers on the server
11:29
You can workaround it by disabling compiz
11:30
<pem725>
yep, I just read your post on ubuntu bug page.
11:30
<alkisg>
pem725: I'm worried about karmic incompatibilities... what ltsp version do you have in the chroot?
11:31
sudo chroot /opt/ltsp/i386 dpkg -l ltsp-client
11:32
<pem725>
5.1.90-0ubuntu3
11:32
<alkisg>
Yeah, it wouldn't work with that :)
11:32
You need to add stgraber's repository to the chroot, and upgrade/update the image
11:32
<pem725>
should I copy my sources to the chroot?
11:32
<alkisg>
Do you want me to help with vnc?
11:32
<pem725>
nah, I can get it.
11:33
<alkisg>
OK. Either copy the sources, or use add-apt-repository.
11:33
sudo add-apt-repository ppa:stgraber, if you have add-apt-repository installed.
11:35
<pem725>
OK, so the updates are installed now.
11:35
<alkisg>
You also need sudo ltsp-update-image outside of the chroot
11:35
<pem725>
yep
11:35
I'm on it right now....
11:35
<alkisg>
Then, remove LTSP_FATCLIENT from lts.conf, and reboot the client
11:38
<pem725>
YES!!!
11:39
alkisg: the system booted up and now has full access to the internet through firefox.
11:40
<alkisg>
Goodies
11:40
pem725: ok, give it a try, and then give some feedback on whan can be improved :)
11:41
<pem725>
alkisg: thanks, I will do just that. Also, I want to know how I can make sure that apps are indeed running locally versus on my server.
11:41
<alkisg>
pem725: run a `ps -ef` on your server
11:41
<pem725>
oh yeah, right.
11:41
silly me.
11:41
<alkisg>
E.g. if you open firefox on the client, and run ps on the server, you should not be seeing it
11:42
<pem725>
yep
11:42
got it.
11:42
troubleshooting sure does make me stupid sometimes.
11:42
thanks for all your help today.
11:42
<alkisg>
pem725: also you'll see much better multimedia performance, e.g. full screen flash etc
11:42
<pem725>
indeed.
11:42
<alkisg>
*you'll need to install ubuntu-restricted-extras on the chroot for that
11:43
<pem725>
alkisg: is sound now pushed off to the clients as opposed to distributing sound through pulse?
11:43
<alkisg>
Now the client is running *everything* locally. It only uses /home/username from the server, nothing else (and of course the root, / with nbd)
11:44
So it's like a regular client, with a bit slower hard disk (depending on your network speed)
11:44
<pem725>
wonderful!
11:44
gigabit with multiple NIC's on the server.
11:44
hopefully that will suffice.
11:44
<alkisg>
I bet it will
11:44
<pem725>
great
11:44
thanks again.
11:44
off to play with my new setup.
11:44
<alkisg>
The server will cache all the nbd image on ram
11:44
<pem725>
I owe you more than just thanks and feedback.
11:45
<alkisg>
So after a few minutes, it should be as fast as a regular hard disk
11:45
You're welcome
12:00markit has quit IRC
12:10vagrantc has joined #ltsp
12:15ogra_cmpc has quit IRC
12:27
<alkisg>
vagrantc: Hi! (As you already know :)) I'm looking for a way to automatically enable NBD_SWAP for clients with low RAM. I've thought of a new way, which would be less intrusive: NBD_SWAP_THRESHOLD. So if someone sets that to 100 (Mb), NBD_SWAPping will be automatically enabled for clients below that: http://paste.ubuntu.com/381105/
12:27ogra_cmpc has joined #ltsp
12:27
<alkisg>
On the usual case, where it's not set, the old behavior remains, so it shouldn't affect existing installations in any way.
12:30
<vagrantc>
alkisg: looks good to me :)
12:31
alkisg: though preferably as 2-3 separate commits
12:31
alkisg: and one minor issue ...
12:31
<alkisg>
Heh, ok
12:31
What issue?
12:31
<vagrantc>
+ if [ $(($memtotal)) -lt $(($NBD_SWAP_THRESHOLD)) ]; then
12:31
the $(()) are unecessary
12:31
<alkisg>
They aren't :)
12:31
<vagrantc>
or?
12:32
<alkisg>
E.g. if memtotal is empty for some reason, this evaluates it to zero
12:32
The same for NBD_SWAP_THRESHOLD
12:32
If one sets it to "one hunderd megabytes" in lts.conf, it won't stop because of that
12:32
<vagrantc>
i suppose so... it's a bit ugly...
12:33
<alkisg>
I could sed it for digits only, and then do an "if [ -z ]", but it would be too long...
12:34
Maybe I could do it on a separate line, with a comment:
12:35
NBD_SWAP_THRESHOLD=$(($NBD_SWAP_THRESHOLD)) # Ensure that it is numerical only
12:35
<vagrantc>
that makes it clearer what's going on, even if 2-3 lines longer that way
12:35
<alkisg>
OK, will do it this way.
12:36
<vagrantc>
ditto for memtotal
12:36
don't know if a better name for lts.conf than NBD_SWAP_THRESHOLD
12:37
<alkisg>
I'm all ears!
12:37* vagrantc contemplates
12:38
<vagrantc>
hard to come up with something ... but i could see people stumble over the spelling of THRESHOLD pretty easily...
12:39* vagrantc contemplates more
12:39
<johnny>
/me is tired of freenode not support an xmpp interface :(
12:40* vagrantc is happy to not be an xmpp interface
12:43
<alkisg>
We could also secretly allow the use of NBD_SWAP=100 instead of introducing a new variable :P
12:45
<vagrantc>
evil
12:50
<alkisg>
Strictly speaking, when using a threshold value, an additional true/false value isn't required
12:50otavio has quit IRC
12:51
<vagrantc>
true enough
12:51
<alkisg>
So (if we had a good name for it) NBD_SWAP_THRESHOLD=0 (=the default) would mean "never swap", and NBD_SWAP_THRESHOLD=100000 would mean "always swap"...
12:51
...and NBD_SWAP could be used only for some time, for compatibility
12:53
<vagrantc>
well, strictly speaking... you could have 100,000 megs of swap
12:53
:)
12:53
er, ram
12:54
<alkisg>
...and 64mb more network swap would save you :D
12:55
I mean that it is possible to only use/document one variable for nbd swapping, in the long run
12:56
<vagrantc>
well, i can see the temptation to just support one variable name...
12:56
<alkisg>
Of course a web-based lts.conf would make that decision on the server, making the threshold value obsolete
12:56
<vagrantc>
optionally on the server
12:56
it still could spit out stuff processed on the client
13:29
<alkisg>
Maybe I should just submit it as NBD_SWAP_THRESHOLD... it will take some time until people start using it, so if we or some other devs come up with a better idea, we can change it in the mean time.
13:34
<vagrantc>
alkisg: works for me :)
13:43ogra_cmpc has quit IRC
13:45ogra_cmpc has joined #ltsp
13:57GGD has quit IRC
14:07bobby_C has joined #ltsp
14:42nubae has quit IRC
14:42_nubae_ has quit IRC
14:43nubae has joined #ltsp
14:43_nubae_ has joined #ltsp
14:48ogra_cmpc has quit IRC
14:49ogra_cmpc has joined #ltsp
15:04johnny has quit IRC
15:10shogunx_ has quit IRC
15:10alexbodn has quit IRC
15:17
<stgraber>
http://www.stgraber.org/2010/02/21/ltsp-52-out
15:17
please poke me if I forgot anything major :)
15:18vagrantc has quit IRC
15:26shogunx_ has joined #ltsp
15:50
<alkisg>
stgraber: on Lucid, SCREEN_02=shell / SCREEN_07=ldm gets me ldm on vt1! Is that a known problem?
15:50
<stgraber>
I believe I saw it already but haven't looked at it closely yet ...
15:51
it might be X doing something weird though, I recently had issues switching VT with lucid
15:54
LTSP announce waiting on slashdot, lxer and linuxtoday. If someone can review/vote on one of these, please do ;)
15:55
<alkisg>
Woohoo! :)
15:57
<stgraber>
yeah, with the few recent announcements I did I now have a good list of places to nag to get better news coverage ;)
15:57
the ltsp-cluster announcement got over 15000 visits :)
15:58
<alkisg>
I also linked to your announcement from my greek-teachers forum ;)
15:58
<stgraber>
and the LTSP 5.2 announcement is currently the topic with the most vote on slashdot for the Linux category, so it's quite likely that my server will be dead in a few hours ;)
15:59
<jcastro>
people read slashdot still?
16:00johnny has joined #ltsp
16:00
<stgraber>
jcastro: looks like it
16:02
alkisg: regarding r1682, any reason you disabled compiz for everyone ? that's making the behavior different from what happens with a regular thin client. Also, can you make disabling the lock screen a default setting and not mandatory ?
16:03
alkisg: at the office, my fat clients users actually use the lock screen feature. The just su to root and change their password, then it works.
16:03
<alkisg>
stgraber: I'm not sure the default settings work
16:05
stgraber: they're doing that on every login?
16:06
<stgraber>
alkisg: well, in their case every login means once a week, so yes ;)
16:06
<alkisg>
OK. Sure, no problem with me. I'm also looking on how to prevent suspension and hibernation, but polkit-1 isn't ready yet
16:07
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/432598
16:07
<stgraber>
strangely enough, suspend works correctly here ;)
16:07
it suspends and resumes quite well. Haven't tried suspending for hours though.
16:07
<alkisg>
nbd-proxy works wonders ;)
16:07
<stgraber>
yeah, as long as you don't rebuild your .img in the meantime, it should work well ;)
16:07
<alkisg>
stgraber: feel free to change whatever defaults/mandatory settings you want, I just wanted to get rid of the gconftool-2 call
16:07
<stgraber>
seems like Linux doesn't like you changing block devices on resume :)
16:09
alkisg: will you hate me if I drop that metacity change ? :) I'd really like to have compiz start in a similar way for both thin and fat clients :)
16:09huayra has joined #ltsp
16:09
<alkisg>
No of course not - I'm still wondering myself why I put it there - just because I've heard too many compiz problems lately, I imagine...
16:09
<stgraber>
ok :)
16:09
<huayra>
I am trying to find a list of supported Thin Client models. Is there any?
16:10
<alkisg>
stgraber: we could also make an Ubuntu specific plugin to generate a shadow entry, for the users to be able to authenticate for fat clients
16:10
<huayra>
Thinking of LTSP-Cluster
16:10
<alkisg>
stgraber: vagrantc doesn't really like the idea of keeping a hash locally. But I don't really think of it as a security concern, so if you also want it, I can put an option for it in ldm...
16:11
<huayra>
I know of Multiframe which supports many thin clients and has a very small footprint and specific support of some thin clients. But I need to know how LTSP is doing in that front
16:11
<stgraber>
alkisg: we can probably do that with a small ldm hack, though I don't like the idea of having your password stored in a variable and hashed ... too many things that can go wrong (and your password exposed)
16:11
<alkisg>
stgraber: ldm will only expose the hash to shadow, not the password anywhere
16:11
<stgraber>
huayra: ideally, take something using an Intel Atom CPU, with >= 512MB of RAM and Intel chipsets.
16:12
huayra: the manufacturer isn't very important as long as it's the same chipsets.
16:12
<moldy>
i can confirm that atoms work great
16:12
<stgraber>
huayra: you may have some success with VIA-based thin clients though but in my experience, Atoms one are cheaper and work a lot better
16:12
<alkisg>
stgraber: for me, if someone has root access on a TC, it'd be much easier for him to install a keylogger than decrypt the hash :D
16:12
<moldy>
with enough ram, an atom will allow you to run firefox with flash plugin locally
16:12
which is great
16:13
<stgraber>
and with a bit more ram, you can even run everything locally if you want ;) (fat clients !)
16:13
<alkisg>
stgraber: it can also be an lts.conf option, so that the admin explicitly states that he's ok with that.
16:13
<huayra>
stgraber, Norway has the highest density of Thin Clients in the world and they are bought already
16:13
<stgraber>
actually, I'm doing fat clients with 512MB of RAM here (on a Symbio thin client, atom based)
16:13
<moldy>
stgraber: yeah, i don't want to do that, though :)
16:14
<huayra>
http://multiframe.projects.linpro.no/wiki/CompatibilityList
16:14
I need support down to 64MB RAM
16:14
is that even possible with LTSP ? Or can you tweak it so it can be so?
16:15
<alkisg>
64mb cliens work ok with ltsp
16:15
<stgraber>
huayra: these are mostly VIA-based with low-memory. That should work as long as you don't want anything running locally and don't expect to be able to use youtube or other accelerated content (or 3D apps).
16:15
<moldy>
it's possible with ltsp, you just won't be able to run much stuff locally
16:16
youtube actually worked pretty well non-locally here
16:16
even with a via client
16:16
<huayra>
stgraber, these are ment to be "diskless" clients mostly. So besides a strip down Firefox under X nothing more than RDP/ICA or similar stuff will run on them
16:16
<stgraber>
moldy: yeah but don't expect to have 100 users on an application server while watching youtube ;)
16:16
<moldy>
right, for 100 users, you'd need more servers :)
16:17
10 users worked ok here before i switched to local firefox
16:17
<stgraber>
moldy: with localapps I can get up to 150 users on a server and the network link is only gigabit from the DC to the school. The network would be too slow for flash running on the application server and I would only be able to have 30 or so users if I didn't have localapps.
16:18
<moldy>
yeah, the localapps support is a great step forward for ltsp
16:18
<stgraber>
moldy: well, my current deployment is of 5000 thin clients on 50 servers :) changing the ratio from 100/1 to 10/1 would be an issue ;)
16:19
<moldy>
i see
16:20
<stgraber>
also we noticed that if someone is watching a fullscreen flash video with a remote firefox, it can go up to 100Mb/s of bandwidth for only one thin client ...
16:20
<huayra>
moldy and stgraber tahnks for the insight ;)
16:20
<stgraber>
huayra: np
16:20
<moldy>
yeah, fullscreen is a no-no with a 100mbit link
16:20
<huayra>
I guess if the new LTSP release has a nice GUI to manage this stuff then Multiframe has no reason to live in a sense
16:20
<moldy>
it works somewhat ok with gigabit though. we need faster networks ;p
16:22
<highvoltage>
don't forget to vote for the slashdot entry for LTSP 5.2 at http://linux.slashdot.org/story/10/02/21/225233/After-2-Years-of-Development-LTSP-52-Is-Out !
16:22alexbodn has joined #ltsp
16:25
<stgraber>
huayra: the new ltsp-cluster will have a nice gui. Unfortunately I can't call our current GUI "nice" but at least we have one ;)
16:25
huayra: https://ltsp-control01.stgraber.org/loadbalancer/overview if you want to look at what we're working on (that's the loadbalancer pool management page)
16:26
(feel free to change whatever you want on it, it's just a demo :))
16:26
<huayra>
I will take a look. I know and work with the people behind Multiframe and to be honest I think is time to rethink the product
16:27
I will write them an email and see what they say
16:30
<stgraber>
And we are on slashdot !!! http://linux.slashdot.org/
16:30Patina has joined #ltsp
16:33mikkel has quit IRC
16:37
<alkisg>
moldy: full screen is fine with 100 mbps and divx movies, though
16:37
...but it needs ~50mbps, so that only works for 2 clients :P :D
16:39
<highvoltage>
alkisg: have you ever played with multicast?
16:39
<stgraber>
alkisg: divx usually works because it's using the XV extension so less bandwidth is used (scaling is done on the thin client instead of the server), flash is sending raw X11 at the fullscreen resolution
16:39
<alkisg>
highvoltage: a little. It was difficult to setup, but I think I once got it working, I believe with vlc?
16:40
<stgraber>
highvoltage: we tried to play with multicast at some point, though the issue is to have the customer's routers and switches configured properly so it works ...
16:40
<alkisg>
stgraber: yup, and if YV12 is used, it only needs 12 bits per pixel, not 24/32...
16:40
<stgraber>
alkisg: yeah VLC is the easiest to use to setup multicast broadcast
16:41
<alkisg>
That's the good thing with HTML5... it'll give us full screen youtube ;)
16:42
<stgraber>
indeed, I've been testing it with Google chrome on youtube, works quite well
16:42
<highvoltage>
nice :)
16:45anivair_ has joined #ltsp
16:45
<anivair_>
at the moment I'm still troubleshooting the twinkle issue some of you may recall from earlier. Seems every time I log out and back in the sound settings that I changed vanish. Is that normal? Can I fix it?
16:47vagrantc has joined #ltsp
17:12huayra has quit IRC
17:14bobby_C has quit IRC
17:33alkisg has quit IRC
17:41jammcq has joined #ltsp
17:41
<jammcq>
stgraber: ping
17:44alexqwesa__ is now known as alexqwesa
17:48johnny has left #ltsp
18:21johnny has joined #ltsp
18:29
<moldy>
alkisg: i was talking 100mb per client :)
19:09try2free has joined #ltsp
19:14try2free has left #ltsp
19:18__nubae__ has joined #ltsp
19:19nubae has quit IRC
19:19_nubae_ has quit IRC
19:20nubae has joined #ltsp
19:34vagrantc has quit IRC
19:39Aryq46254 has joined #ltsp
19:40Faithful has quit IRC
19:44sene has quit IRC
19:48mushroomblue has quit IRC
19:52mushroomblue has joined #ltsp
19:55Aryq46254 has quit IRC
20:20ericdc has joined #ltsp
20:20
<ericdc>
Amazing!
20:21
ltsp 5.2 rocks!
20:31otavio has joined #ltsp
20:45Faithful has joined #ltsp
20:44ltspbot has joined #ltsp
20:46johnny has left #ltsp
20:52vagrantc has joined #ltsp
21:03Faithful has quit IRC
21:22shogunx_ has quit IRC
21:24shogunx has joined #ltsp
21:34johnny has joined #ltsp
21:43johnny has left #ltsp
21:45johnny has joined #ltsp
22:02ericdc has quit IRC
22:32ogra_cmpc has quit IRC
22:33ogra_cmpc has joined #ltsp
22:39ogra_cmpc has quit IRC
22:40ogra_cmpc has joined #ltsp
22:42Faithful has joined #ltsp
23:00khris4 has joined #ltsp
23:02
<khris4>
hello everyone
23:25
anyone here
23:38F-GT has quit IRC
23:55F-GT has joined #ltsp