vagrantc: "localdev" is (#1) Information regarding using pluggable devices and cdroms with LTSP can be found at http://wiki.ltsp.org/twiki/bin/view/Ltsp/LTSP-42-LocalDev, or (#2) for ubuntu: https://wiki.ubuntu.com/EnableLTSP5LocalDevices, or (#3) for debian-edu: http://wiki.debian.org/DebianEdu/HowTo/LocalDeviceLtspfs

vagrantc: (factoids search [<channel>] [--values] [--{regexp} <value>] [<glob> ...]) -- Searches the keyspace for keys matching <glob>. If --regexp is given, it associated value is taken as a regexp and matched against the keys. If --values is given, search the value space instead of the keyspace.

vagrantc: "localdev" is (#1) Information regarding using pluggable devices and cdroms with LTSP can be found at http://wiki.ltsp.org/twiki/bin/view/Ltsp/LTSP-42-LocalDev, or (#2) for ubuntu: https://wiki.ubuntu.com/EnableLTSP5LocalDevices, or (#3) for debian-edu: http://wiki.debian.org/DebianEdu/HowTo/LocalDeviceLtspfs

vagrantc: "ubuntu" is a Debian based GNU/Linux distrubution that includes a Ubuntu specific version of LTSP. It can be found at http://www.ubuntulinux.org

04:37

<vagrantc>

ltspbot: learn ubuntu as to install ltsp on ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall

04:37

<ltspbot>

vagrantc: The operation succeeded.

04:37

<vagrantc>

!ubuntu

04:37

<ltspbot>

vagrantc: "ubuntu" is (#1) a Debian based GNU/Linux distrubution that includes a Ubuntu specific version of LTSP. It can be found at http://www.ubuntulinux.org, or (#2) to install ltsp on ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall

vagrantc: "debian" is is a GNU/Linux based operating system that makes an excellent LTSP server. You can find it at http://www.debian.org. for information about LTSP on debian see http://wiki.debian.org/LTSP

04:38

<vagrantc>

!ubuntu

04:38

<ltspbot>

vagrantc: "ubuntu" is (#1) a Debian based GNU/Linux distrubution that includes a Ubuntu specific version of LTSP. It can be found at http://www.ubuntulinux.org, or (#2) to install ltsp on ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall

04:39

<vagrantc>

ltspbot: learn ubuntu as a Debian based GNU/Linux distrubution that includes a Ubuntu specific version of LTSP. It can be found at http://www.ubuntulinux.org. to instal lltsp on ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall

04:39

<ltspbot>

vagrantc: The operation succeeded.

04:39

<vagrantc>

!ubuntu

04:39

<ltspbot>

vagrantc: "ubuntu" is (#1) a Debian based GNU/Linux distrubution that includes a Ubuntu specific version of LTSP. It can be found at http://www.ubuntulinux.org, or (#2) to install ltsp on ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall, or (#3) a Debian based GNU/Linux distrubution that includes a Ubuntu specific version of LTSP. It can be found at http://www.ubuntulinux.org. (1 more message)

04:39

<vagrantc>

ltspbot: forget ubuntu 1

04:39

<ltspbot>

vagrantc: The operation succeeded.

04:39

<ChinaForge>

vagrant,Thank you, I slow slow study!

04:39

<vagrantc>

!ubuntu

04:39

<ltspbot>

vagrantc: "ubuntu" is (#1) to install ltsp on ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall, or (#2) a Debian based GNU/Linux distrubution that includes a Ubuntu specific version of LTSP. It can be found at http://www.ubuntulinux.org. to instal lltsp on ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall

04:39

<vagrantc>

ltspbot: forget ubuntu 1

04:39

<ltspbot>

vagrantc: The operation succeeded.

04:40

<vagrantc>

!ubuntu

04:40

<ltspbot>

vagrantc: "ubuntu" is a Debian based GNU/Linux distrubution that includes a Ubuntu specific version of LTSP. It can be found at http://www.ubuntulinux.org. to instal lltsp on ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall

04:40

<vagrantc>

much simpler

04:40

<ogra>

lltsp?

04:40

lazyltsp ?

04:40

<vagrantc>

ogra: ?

04:40

oh

04:40

<ogra>

to instal lltsp on ubuntu

04:40

<vagrantc>

ltspbot: forget ubuntu

04:40

<ltspbot>

vagrantc: The operation succeeded.

04:41

cliebow has joined #ltsp

04:41

<vagrantc>

ltspbot: learn ubuntu as a Debian based GNU/Linux distrubution that includes a Ubuntu specific version of LTSP. It can be found at http://www.ubuntulinux.org. to install ltsp on ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall

04:41

<ltspbot>

vagrantc: The operation succeeded.

04:41

<vagrantc>

!ubuntu

04:41

<ltspbot>

vagrantc: "ubuntu" is a Debian based GNU/Linux distrubution that includes a Ubuntu specific version of LTSP. It can be found at http://www.ubuntulinux.org. to install ltsp on ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall

04:42

<ChinaForge>

I read a lot of ltsp tech documents,but most is for 4.XX,so ...

04:42

<ogra>

yeah

04:42

<vagrantc>

ChinaForge: yes, it's in transition from ltsp 4 to ltsp 5 right now ...

04:42

<ogra>

ChinaForge, there are some more on https://help.ubuntu.com/community/UbuntuLTSP

envite: so, in the canaries you're using both debian and ubuntu ? what decides which to do?

07:22

Thumann has joined #ltsp

07:23

<Thumann>

hi, we've been running a ltsp setup for about a year now, it currently holds around 50 concurrent users and for improving performance, and adding fail over, we'd like to make a "farm" of two ltsp servers. From what i can read from the net, this can be done using OpenSSI.. but this seems kinda.. outdated to say it mildly?

07:24

jammcq has joined #ltsp

07:24

cliebow has quit IRC

07:24

<vagrantc>

jammcq: morning

07:25

Thumann: probably the simplest thing to do that will partially address it is to do some sort of load-balancing in such a way that it provides cold failover

07:25

<Thumann>

Or is there any other type of setup you would recommend?

07:25

cliebow has joined #ltsp

07:26

<vagrantc>

cold failover being that if a server goes down while someone's using it, they'll have to log back in

07:26

<Thumann>

vagrantc: yes, load-balancing was acutally the "only" feature we would be needing.. and from what i can read on the net, openssi would hook you up with that.

07:26

vagrantc: and i'm familiar with the term cold faildover :)

07:27

Gianluca has quit IRC

07:27

<Thumann>

What do you guys use for load-balancing?

07:27

If there is an alternative to openssi

07:28

<vagrantc>

only thing i've worked with is manually choosing a server at login. but you could easily randomize that.

07:28

more dynamic load balancing is tricky

07:28

<Thumann>

yeah well, that wouldn't really be "load balancing" or i'd have to get some scripts made that would measure cpu and memory use etc.

07:29

<vagrantc>

yes, it wouldn't balance any load at all :P

07:30

Thumann: if you want "True" load-balancing, there hasn't been much done in that department

07:30

<Thumann>

vagrantc: Isn't that a.. hard blow for ltsp?

07:31

compared to citrix, ms term srv. etc. who all have this feature

07:31

<vagrantc>

when a simpler option works in most cases, no

07:32

<Thumann>

vagrantc: Do you have any knowledge of openssi?

07:32

<vagrantc>

i've heard about it a little. someone had worked on using it with ltsp.

07:33

<Thumann>

http://wiki.openssi.org/go/Talk:Main_Page , hehe.. defaced :S

07:33

<envite>

vagrantc: sorry, i was fighting with kde kiosk mode

07:33

jsgotangco has quit IRC

07:33

<Thumann>

or.. i wouldn't really call defacing a wikisite defacing.

07:34

<envite>

vagrantc: which is the meaning of the question? I do not understand it.

07:34

<jammcq>

g'morning kids

07:35

<vagrantc>

envite: well, when "meduxa" talked at the ubuntu education summit, he talked about using ubuntu ... and the other night you were talking about using debian ... so i was curious which gets used for which

07:36

<envite>

well, these are different projects

07:37

<vagrantc>

ah, i see.

07:37

<envite>

meduxa (Agustín Benito) talked in Sevilla about a work we did for Canary Islands govt. It is a educational distro based on Kubuntu and ha nothing to do with LTSP

07:37

<vagrantc>

got it

07:38

<envite>

besides that, we at the company use Debian, we install Debian to our customers (if they don't ask specifically for another thing) and we do LTSP 4.2 over Debian

07:39

rjune-isis has joined #ltsp

07:41

<envite>

the project we did for the govt. is called mEDUXa and was based in Kubuntu because we wanted the integrated feeling it gives to the Desktop, instead of the Debian way. And, moreover, because we wanted a stable branch and Debian stable, at the moment, was quite old

07:42

<vagrantc>

envite: what's the biggest thing holding you back from switching to ltsp5 ?

07:44

<envite>

well, running projects already using ltsp 4.2

07:44

<vagrantc>

heh :)

07:46

<envite>

I want to start learning ltsp5 but we need to keep running projects without big changes

07:46

btw

07:46

is ltsp5 as good as 4.2 in sound and lda?

07:46

<vagrantc>

mostly i'd say yes.

07:46

Thumann has left #ltsp

07:47

<vagrantc>

we didn't get ltspfs into debian/etch, but the ltspfs packages from lenny still work in etch

07:48

mhterres has joined #ltsp

07:48

<envite>

use the same fuse system?

07:48

<vagrantc>

sort of

07:48

parts of it are very different

07:51

<envite>

i see

07:51

and about sound? same esd way?

07:51

<vagrantc>

esd in debian. ubuntu switched to pulseaudio, and i suspect debian will follow

07:52

<envite>

i've never touched pulseaudio

07:53

<vagrantc>

i think it's intended to replace esd

07:53

<envite>

i'll try when i'll start with ltsp 5

07:57

vagrantc has quit IRC

08:01

<rjune-isis>

does pulse use the same protocol as esd?

08:06

<ogra>

no, it has an own native protocol

08:06

but it can emulate esd

08:07

even simultaneously

08:08

but what is more important, alsa has a plugin that emulates a native alsa device on top of the pulse network connection, so all apps using alsa and esd just work ootb

08:10

<rjune-isis>

that part is badass

08:11

Shane-S has joined #ltsp

08:11

<ogra>

the only problematic stuff stays oss crap using /dev/dsp directly but thats getting less and less

08:12

<Shane-S>

is this where i can get help for k12ltsp.org's project as well?

08:15

<Lumiere>

yes to the best of people's ability

08:16

<Shane-S>

ok, as per a note I found on the k12ltsp site, it says for NIC computers edit /opt/ltsp/i386/etc for video res and sound, I have no clue what options I have for video

08:16

right now my systems boot, but when the video is initialized for the GUI either the refresh rate or resolution is too high because the monitors just blink there power lights

08:16

their*

08:19

<envite>

Shane-S: you need to touch the lts.conf file

08:19

see the ltsp wiki page about lts.conf

08:20

<Shane-S>

ok

08:26

Blinny has joined #ltsp

08:30

Guaraldo has quit IRC

08:33

Guaraldo has joined #ltsp

08:33

sbalneav has joined #ltsp

08:33

<sbalneav>

Morning all

08:34

Guaraldo has left #ltsp

08:34

<envite>

morning

08:34

<Shane-S>

ok I read the wiki on Xserver stuff, it says it should detect the video card if it is not specified, will it auto detect the resolution or base it off the servers GUI settings?

08:34

<ogra>

!s

08:34

<ltspbot>

ogra: "s" is Scotty!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

08:34

<sbalneav>

hey ogra!

08:34

I was doing some work last night on LDM

08:34

<ogra>

yay

08:34

<jammcq>

!s

08:34

<ltspbot>

jammcq: "s" is Scotty!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

08:35

<ogra>

on the c or pyhon side ?

08:35

<sbalneav>

Gadi's not here, but rather than his 4 variables for autologin, I came up with an even easier solution.

08:35

Guaraldo has joined #ltsp

08:35

<sbalneav>

Morning jammcq

08:35

<envite>

Shane-S: no

08:35

<sbalneav>

python.

08:35

So, check this out: when we grab the IP, we grab the MAC as well.

08:35

<envite>

Shane-S: lts.conf is used to create an Xorg.conf file

08:35

<ogra>

Shane-S, if you use a distro with ltsp5 it will autodetect

08:35

<Shane-S>

envite: the wiki does show more then resolution and an full example, if there a simple resolution and refresh rate line?

08:35

<sbalneav>

We add a new lts.conf var: LDM_GREETER

08:36

path to a greeter.

08:36

<ogra>

sbalneav, fine

08:36

<envite>

so if you do not specify it, Xorg.conf will not have it configured

08:36

<sbalneav>

when running the greeter, pass it the IP and and MAC

08:36

<ogra>

it has the ip already

08:36

<sbalneav>

A standard "ask user for password" greeter will ignore it.

08:36

<ogra>

there is a function called get_ip()

08:36

<envite>

Shane-S: you can specify x_vert_refresh simply, or create a whole modeline

08:37

<sbalneav>

Right, but it's not passed to the greeter command line.

08:37

<Shane-S>

ty

08:37

<ogra>

sbalneav, why do you need it on the commandline ?

08:37

<sbalneav>

pass it to the greeter. Then, if you want autologin, you just need a shell script that looks like

08:37

#!/bin/sh

08:37

<envite>

Shane-S: all info you give to lts.conf will be used to the Xorg.conf

08:37

<ogra>

sbalneav, did you look at gadis autologin stuff ?

08:37

<sbalneav>

if [ip = something] ; echo "userid\npassword\n"

08:38

I did, but he specifies the password in the lts.conf

08:38

<envite>

but all info you do not give, will be inferred or detected or created or defaulted by X

08:38

<sbalneav>

which is mode 644

08:38

<Shane-S>

ohh found on wiki, was further down, is it X_VERTREFRESH or X_vert_refresh?

08:38

<sbalneav>

this way, you could make the autologin greeter mode 700, and protect the passwords.

08:38

<ogra>

sbalneav, you can just copy an sshkey in place instead

08:38

<envite>

i don't remember just new, let me see

08:39

<sbalneav>

How you gonna map an sshkey to a mac?

08:39

<ogra>

not at all

08:39

but i know the server ip

08:39

what do you need a mac for ?

08:40

<sbalneav>

Lets say I want terminal with mac 00:11:22:33:44:55 to autologin as "user1"

08:40

<ogra>

yeah

08:41

i put the key for user1 in the chroot and set LDM_USERNAME in lts.conf for that TC

08:41

<envite>

Shane-S: X_VERTREFRESH

08:42

<sbalneav>

Now you're going to force admins to set up individual ssh keys for all their users.

08:42

in addition to their regular user accounts.

08:43

I suppose for most autologin setups, it would be a small number of WS's

08:43

<ogra>

right

08:43

and usually one user bound to each

08:43

shogunx has quit IRC

08:44

<sbalneav>

you'll need an LDM_GREETER variable anyway, because you want to have different greeters, depending on GTK or KDE looks.

08:44

You'll see my patches, I'll upload my tree tomorrow.

08:45

Have you already merged gadi's patches into your tree?

08:46

<ogra>

i want the greeter to be autodetected by the installed dependencies in the chroot

08:46

(i didnt plan to install QT alongside the gtk greeter)

08:46

<sbalneav>

ok, but you'll want the user to be able to specify the greeter manually as well.

Well, default to autodetect, surely, but allow the option of an override.

08:48

<ogra>

there will be a default greeter which is either qt or gtk

08:49

<sbalneav>

[00:11:22...]

08:49

<ogra>

and there will be an optional low_ressources greeter (if someone writes one)

08:49

<sbalneav>

LDM_GREETER = /usr/lib/ltsp/greeters/kde

08:49

Don't see what's so complicated about that.

08:49

<ogra>

the admin will specify that at chroot build time

08:50

it introduce extra layers we dont need imho

08:50

<sbalneav>

It's, like, 5 lines of code in LDM

08:50

<ogra>

hrm

08:50

these start to stack up

08:51

gadi had 10 lines as well

08:51

and i might have ideas for 20 lines

08:51

<sbalneav>

Wasn't aware we were on a strict line budget for LDM.

08:52

<ogra>

well, you ar the guys complaining about >120second boots

08:52

<sbalneav>

The slowdown's not in LDM

08:53

Not that I can see, anyway.

08:53

<ogra>

and the bigger we pump up the python side of thngs the harder it will get to switch to something else at some point

08:54

<sbalneav>

For the LDM, I don't see we NEED to switch to something else. The greeter was what was taking up all the time, not the LDM itself. It's quite small.

08:54

<ogra>

well, if i pretend to have an ltsp4.2 chroot here (by setting a static xorg.conf and cutting down modules and raing udev a bit) i get nearly on par with bottimes ... ldm then still takes more than 2secs

08:54

*20

08:55

<sbalneav>

Is that LDM with the python greeter, or with the C greeter.

08:55

?

08:55

<ogra>

moquist tried the C greeter and dint see any much difference in boottime on his slow clients btw

08:55

the C greeter

08:56

the major amount of time that we loose is still spent in the python part

08:56

<sbalneav>

OK, so we just need to rewrite LDM in C then.

08:56

<ogra>

well

08:56

*just*

08:56

:)

08:56

<sbalneav>

that's easy. It's really not doing anything that complicated.

08:56

Tell you what.

08:56

<Shane-S>

thanks guys that worked!

08:57

<ogra>

its handling passwords

08:57

nicoAMG has joined #ltsp

08:57

<ogra>

it will take ages until we got full approval from the security team

08:57

an i have to run it past them for such a change

08:57

<Shane-S>

now I have a new question, I want to have a generic login, so I made a user called "student" and logged it in on one system...well the other warned I was logged in...

08:57

<sbalneav>

So, guess I better get busy then :)

08:57

* sbalneav hacks.

08:58

<Shane-S>

well when I go to launch things like FireFox on both clients, one says FFx is open already

08:58

<ogra>

and indeed it makes contributing a *lot* harder

08:58

that were my two main cause to keep it in py until now

08:58

<sbalneav>

Not really. In C it really wouldn't be THAT much bigger.

08:58

<Shane-S>

how can I make a generic login that does not share a session??

08:58

<ogra>

Shane-S, yes, use one user per client

08:58

<sbalneav>

It doesn't need to be setuid, since it's already running as root.

08:59

Q-FUNK has quit IRC

08:59

<Shane-S>

but I want to have a single user, not multiples

08:59

<sbalneav>

Essentially, it's job is just to: set up some environment variables, grab a userid and password from a greeter, and spawn an ssh session.

08:59

<ogra>

Shane-S, then you need to rewrite the world ... most applications and desktop environments cant handle that

09:00

<Shane-S>

alright

09:00

then is there a way to make it so I can use NULL passwords, it asks for 6 character minimum for users

09:00

* ogra just had a freaky idea how it would be possible to use one user for all

09:01

<Shane-S>

since I dont want the kids to have to remember their logins

09:01

unless Fedora can import logins from an OS X server??

09:03

<ogra>

sbalneav, how about a pam-mount script that creates a tmpfs mount for /home/$user, that way we could use the same user on every login :) (indeed with the cost that all data is lost on logout)

09:03

* highvoltage has done that before

09:04

<sbalneav>

Well, the mkhomdir code's already been done for that.

09:04

<ogra>

highvoltage, why do you keep such stuff secret :) thats awesome

09:04

<highvoltage>

I added a guest user home (/home/guest) to rw_dirs for diskless full machines

09:04

<ogra>

ah, no

09:04

<highvoltage>

ogra: I always asume everything I do is way to hacky for ubuntu

09:04

<ogra>

i'm talking about the server

09:04

<highvoltage>

aaah

09:05

<ogra>

make it create a tmpfs, mount /home/$user into it ... every new user gets a fresh home and no .lock files

09:05

i wonder how much dbus would get confused :)

09:06

envite has quit IRC

09:08

<rjune-isis>

Shane-S: does your OS X server use LDAP? if so, then in theory you can use an ldap server with any linux distro

09:09

<Shane-S>

yeah it has LDAP, but I guess for now it will just be easier to search how to make linux users with no passwords

09:09

I am only testing it right now anyway

09:14

mhterres has left #ltsp

09:15

markgreene has left #ltsp

09:20

Shane-S_ has joined #ltsp

09:22

Shane-S_ has quit IRC

09:33

vykarian has joined #ltsp

09:37

Shane-S has quit IRC

09:38

<vykarian>

hi all

09:38

found the error "_X11TransSocketINETConnect Can't get address for localhost"

09:39

any tip?

09:41

PMantis has joined #ltsp

09:42

shogunx has joined #ltsp

09:42

Guaraldo has left #ltsp

09:43

<vanya>

vykarian, check /etc/hosts for localhost record

09:44

<moquist>

ogra: interesting idea about the fresh /home/$user with no .lock files

09:44

I think FF's "You must close the other Firefox" message is one of the most amazingly terrible usability things in Ubuntu right now.

09:44

<vykarian>

thats message is on LTS client running freeNX client

09:44

<ogra>

well, it is right

09:45

it would break if two users use it at the same time

09:45

like openoffic

09:45

e

09:45

<moquist>

1. Usually (in my use cases) there is no other FF instance running. 2) The user has no idea how to figure out if there is one running or not, or where it is, or how to kill it. 3) The fix, 99% of the time in my use cases (LTSP), is to remove the lockfile(s), which the error message doesn't even mention.

09:46

It should *at least* give the option of using a different profile, which I believe it used to do.

09:46

<ogra>

indeed, that could be better

09:47

vagrantc has joined #ltsp

09:48

<moquist>

I have a "firefox-profile-whack" script in the Applications->Internet menu that moves the user's ~/.mozilla directory over by appending a date to the name, creates a fresh .mozilla directory (from /etc/skel, IIRC), and copies the bookmarks back in.

09:48

ogra: People run into that problem *ALL THE TIME* on our Edubuntu networks. I guess I could've mentioned it before now...

09:50

I think people don't shut down properly b/c thin clients seem so resiliant, and this is a symptom of that. User education is a good start on addressing the problem, but surely at least the error message could be better at pointing the user toward likely realities.

09:51

* vagrantc had to fight the ctrl-alt-backspace culture at freegeek

09:52

<vagrantc>

people kept doing that to "log out" and then wondered why their web browser would freak out once in a while

09:52

ogra-classmate has joined #ltsp

09:53

Q-FUNK has joined #ltsp

09:58

<ogra-classmate>

moquist: you coulkd add it to ldms session command

09:58

like we do with ltspfsmounter

09:58

look at the python code of 6the wrapper

09:58

<rjune-isis>

moquist: when We had that problem, we wrote a little program that let them reset firefox, OO.o, and a few other things to default configs.

09:59

<moquist>

rjune-isis: Right; I'm doing almost the same thing. We just haven't had so much trouble with OO.

09:59

Though resetting Gnome settings would be *really* valuable.

10:00

bobby_C has quit IRC

10:00

<moquist>

Is there a recommended way to allow users to log into systems with different versions of Gnome, all while sharing one ~/ ?

10:00

<rjune-isis>

it was just a bash script using kdialog. no reason it couldn't be adapted

10:00

<ogra-classmate>

well, do you know the status of gnome-reset ? we talked about it plenty of times but nobody contacted upstream yet afaik

10:00

<rjune-isis>

use a different .gnome dir for each one would be my guess

10:00

aka ./gnome-<version>

10:00

<moquist>

ogra-classmate: gnome-reset is packaged in universe.

10:01

<ogra-classmate>

yes, but unmaintained afaik

10:01

<moquist>

rjune-isis: That's my guess, too. Not sure how to set that up.

10:01

ogra-classmate: Ah, OK.

10:01

ogra-classmate: I'm still interested in it (obviously), but it's lower in my priority stack than getting these particular TCs booting faster so the big cheese doesn't axe the edubuntu direction we're taking. 8-\

10:02

<vagrantc>

ouch

10:02

<moquist>

ogra-classmate: Though it's occurred to me that his big reason for saying we need to standardize on one distro was so that people in the training facility would see the same desktop in the schools... I say we develop our own Gnome theme, and then we can run whatever the hell we want under the covers.

10:02

<ogra-classmate>

did you try the right udev changes

10:03

<moquist>

ogra-classmate: Yeah; the udev changes bought 20 seconds to bring boot-to-login time down to 4:40 instead of 5 min.

10:03

* ogra-classmate cant belive that ....

10:03

<moquist>

ogra-classmate: I still have the nbd& and static xorg.conf to try.

10:04

<ogra-classmate>

not waiting for udev should shove down more than 50%

10:04

<moquist>

ogra-classmate: It's *just* these laptops, of which we only have 12, out of probably more than 1000 TCs in the district. Surely the problem can be addressed. :)

10:04

<ogra-classmate>

udev and xorg autoconfig are the two big delays

10:05

well, there must be some kind of kernel issue

10:05

<moquist>

ogra-classmate: Yes.

10:05

<ogra-classmate>

probably acpi/apm related

10:05

<moquist>

ogra-classmate: Next on my list is changing the TC kernel config. Do you have any analysis methods to recommend other than just looking at the timestamps(right term?) in the TC syslog?

10:06

<ogra-classmate>

the kernel has only the bare minimum setup, i'd rather experiment ewith bootoptions

ogra-classmate: Yeah, it's on the gnome panel. In Edubuntu I have to wiggle the mouse-nub with my left hand to get into the menu, etc. My RH is ready to hit return as soon as it opens...it would be faster if I just moved my RH, or if I put a launcher on the panel... Hmm. :) That's not the crucial test, though.

10:13

ogra-classmate: I don't have numbers here for the 250Mhz 64MB netier TCs, but with Edubuntu those are ~2min to login, which I can sell (I think).

10:13

<ogra-classmate>

hmm, all toshiba ?

10:14

nolapic noacpi

10:14

<moquist>

ogra-classmate: I'm just working with this one slow laptop for now, until I get it booting reasonably. After that I'm going to tour all our schools with my testing setup and test every different type of TC, so when we (colleagues & boss) discuss this later we have all the data.

10:14

<ogra-classmate>

i'm oretty sure these two will solve it

10:14

pretty

10:15

<moquist>

ogra-classmate: Will give it a shot tomorrow and let you know. (Thanks.)

10:15

irule has joined #ltsp

10:15

Q-FUNK has joined #ltsp

10:15

<moquist>

ogra-classmate: any reason not to include those boot options in general for TCs?

10:16

<ogra-classmate>

yes, anything can be a thin client

10:16

and all newer models will work fine with acpi

10:16

<moquist>

ogra-classmate: K.

10:17

<ogra-classmate>

these toshibas are very likely from the time where the apm->acpi switch of the hw vendors took place

10:17

<moquist>

ogra-classmate: Yes.

10:17

<ogra-classmate>

i remember having some toshibas at that time where i needed to set these options

10:17

* moquist wishes he had one at home to test

10:18

<ogra-classmate>

its a laptop, you can carry it?

10:18

<moquist>

ogra-classmate: Yeah, but I leave work at work (most of the time). I've got other responsibilities I'm supposed to be meeting now... and now I have no choice, b/c I cannot test the laptop. :)

10:19

<ogra-classmate>

go to your meeting then :)

10:24

SlackDweber has joined #ltsp

10:24

<SlackDweber>

hii

10:25

excusme i have trouble about ltsp in client with pxe card

10:25

:(

10:25

<vagrantc>

what happens?

10:25

<SlackDweber>

i confused because on other pc with same pxe it can load n login on ltsp server :(

10:25

J45p3r_ has joined #ltsp

10:26

<SlackDweber>

im try to installing ltsp 4.2u2 in zenwalk

10:26

n successfully configure

10:26

but on client, i got searching dhcp :(

10:27

<vykarian>

guys

10:27

XIO: Fatal IO error 104 (connectoin reset by peer) on X server ":0.0"

10:27

<SlackDweber>

note: in client pc i use compaq build up with pxe card

10:27

<vykarian>

any parametters needed?

10:29

Egyptian[Home] has joined #ltsp

10:31

<SlackDweber>

ping

10:32

met malem om :)

10:34

prpplague has joined #ltsp

10:38

jsgotangco has joined #ltsp

10:48

Blinny has quit IRC

10:56

SlackDweber has quit IRC

10:59

Q-FUNK has quit IRC

11:08

PMantis has quit IRC

11:10

<sbalneav>

ogra-classmate: "ldm.c" [Modified] 253 lines --96%-- 245,30 97%

11:11

<vagrantc>

sbalneav: mornin

11:11

<sbalneav>

vagrantc: hello

11:11

vagrantc: ogra thinks ldm itself in python is slow.

11:12

So, it's getting re-written in c :)

11:12

<vagrantc>

so y'all are re-writing the whole thing in C ?

11:12

<sbalneav>

yep

11:12

<vagrantc>

so, while you're doing that

11:12

maybe this is a good time to think about putting a significant portion of the add-on features into other scripts

11:13

i.e. sound, localdev

11:14

<sbalneav>

Which, re-write them in C?

11:15

<vagrantc>

well, i think starting local device stuff shouldn't be handled by ldm, for example

11:16

oh, that stuff was in the ltsp-client init scripts

11:16

<sbalneav>

right

11:17

kaminski-ltsp-br has quit IRC

11:17

<sbalneav>

esd's started, so we could move that out, and just deal with making sure the environment's set up correctly.

11:17

sure.

11:18

<vagrantc>

i also don't understand why we try to get the ip address ... that should be handled server-side and pulled from SSH_CLIENT

11:19

<sbalneav>

Probably could be.

11:19

I'll look into it.

11:19

<vagrantc>

same for setting all the detailed information for PULSE_SERVER, ESPEAKER, etc.

what we need's a small shell script on the server that can be .'d, and sets up the env.

11:20

that's not that bad.

11:20

<vagrantc>

we can just drop files into /etc/X11/Xsession.d

11:20

<sbalneav>

that too.

11:21

hm

11:21

<vagrantc>

well, on debian-based systems

11:21

<sbalneav>

what if we have SOUND=n, LOCALDEV=n

11:21

kaminski-ltsp-br has joined #ltsp

11:21

* sbalneav thinks

11:21

Burgundavia has joined #ltsp

11:21

<sbalneav>

meh, first, I need to get something working :)

11:21

<vagrantc>

heh

11:22

sbalneav: well, i guess what i'm saying is don't re-implement all the features- just get the basic premise functional first

11:22

<sbalneav>

right.

11:23

ATM, I'm just going after getting the X session plumbed.

11:24

<vagrantc>

sbalneav: you could re-use an existing ssh-askpass to handle the password side of things

11:25

sbalneav: are you trying to re-use the greeter?

11:25

<sbalneav>

Well, we're going to want a greeter of some kind, yes?

11:25

<vagrantc>

right

11:27

just trying to guage where you're going with this

11:27

<Burgundavia>

hey vagrantc

11:27

<vagrantc>

Burgundavia: greetings. how's the homeland treating you?

11:27

<Burgundavia>

not bad

11:28

<sbalneav>

lets aim to use something existing if we can.

11:28

<Burgundavia>

yesterday I went to work at 11:30, had a two hour lunch and then went home at 4

11:28

<ogra-classmate>

vagrantc: i asked mdz about server sided stuff and he nearly got angry at me back then

11:28

<vagrantc>

sbalneav: i guess, i'm questioning some of the existing assumptions

11:28

ogra-classmate: back when?

11:29

<ogra-classmate>

i dont think its a good ide to rely to much on that, it breaks teh default compatibility with standard ssh logins

11:29

<vagrantc>

sbalneav: and if there's a lot of re-writing going on...

11:29

<ogra-classmate>

vagrantc: when i started with the first sound implementation

11:29

<vagrantc>

ogra-classmate: what do you mean it breaks default compatibility with standard ssh logins?

11:29

<ogra-classmate>

we shouldnt clutter /etc/X11/Xsession.d

11:29

<sbalneav>

Well, it's wide open now. I'm going to hack on it most of today. Hopefully I'll have something going and in bzr later today.

11:30

<ogra-classmate>

vagrantc: its supposed to work on any setup with ssh -X capability

11:30

without extra server side stuff

11:31

<vagrantc>

ogra-classmate: well, if they handle all the variables, we won't be breaking anything

11:31

<ogra-classmate>

the sound setup for pulse already breaks that rule and i'm planning to fix that before gutsy

11:31

no server sided hacks if avoidable ....

11:31

<vagrantc>

yes, let's do the most hair-brained client-side setup possible instead.

11:32

<ogra-classmate>

no, lets just make more usage of our socket ;)

11:33

we should be able to pump all data we need through it without and server sided stuff

11:35

<vagrantc>

this is one of those moments where i think about starting up lessdisks again

11:35

<ogra-classmate>

everything you would determine from SSH_CONNECTION would require server sided scripting

11:35

<vagrantc>

and as far as i'm concerned, that's a good thing.

11:36

<ogra-classmate>

we already have the tunnel, lets just use it and keep the scripts on one side

11:36

whats wrong with cutting down mainteneance by 50%?

11:36

<vagrantc>

what are we really gaining by doing that?

11:37

<ogra-classmate>

you only need to maintain one side

11:37

all is centralized on the client

11:37

you dont need to patch around in desktop apps to respect variables they dont know

11:37

<vagrantc>

except if the client is executing commands on the server, it needs to somehow handle dependency resolution server-side

11:38

<ogra-classmate>

right, thats what the -standalone metapackage does

11:38

beyond that the scripts should have enough error handling to not break everything if an app is missing

11:39

sepski has joined #ltsp

11:39

<vagrantc>

i guess, i'm just tired of a monolithic LDM that every time you add a new feature you have to hack ldm

11:39

ditto for the init scripts

11:39

we somewhat fixed that for ltsp-build-client

11:40

<ogra-classmate>

i'm fine with splitting them, i told you that before

11:40

i'm just opposing to do server side scripts as well

11:41

having a server sided script to determine ESPEAKER from SSH_CONNEFCTION just makes no sense imho

11:41

we should rather have ltsp-client-setup export the ip once in a global var so we have it in all subsequent initscripts

11:42

<vagrantc>

sure, that'd be an improvement.

11:42

<ogra-classmate>

i think we have the get_ip function three times in the bootprocess

11:42

two times in the initscripts and once in teh greeter

11:44

if we have an ltsp-client-sound package i see no reason not to use the ssh socket to execute asoundconfig pluse-enable on the server instead of having an ltsp-sound script in the session startup scripts

11:44

liekwise for everything else we need to set on the server side

11:45

i'm totally happy to modularize

11:47

but i'm all against to hack up the users session

11:48

* vagrantc thinks some

11:48

<vagrantc>

ogra-classmate: i think the only play we use the IP address is ldm

11:49

<ogra-classmate>

PULSESERVER needs it and ESPEAKER ... and the localdev scripts

11:49

<vagrantc>

yes, i know

11:49

well, not the localdev scripts

11:50

<ogra-classmate>

the ltspfsmounter needs it, but it gets it from teh client side scripts

11:50

through the socket

11:51

we should also think about a fallback mechanism for systems without Xsession

11:51

<vagrantc>

or put it in a different location

11:51

<ogra-classmate>

i.e. rely on xterm being in path and falling back to at least start that (with a popup message)

11:52

put it in a different location ?

11:52

<vagrantc>

just discovered on centos it's in /etc/X11/xinit/Xsession

11:52

<ogra-classmate>

ah, well we could walk the known paths

11:52

maaarek has quit IRC

11:53

maaarek has joined #ltsp

11:53

<vagrantc>

ogra-classmate: that would really suck on errors

11:54

<ogra-classmate>

?

11:54

<vagrantc>

well, unless we test for the file not found error

11:54

<ogra-classmate>

if /etc/X11?Xsession doesnt exist we try again with /etc/X11/xinit/Xsession if that doesnt exist either we fail

11:55

<vagrantc>

how you going to do that client-side ?

11:55

<ogra-classmate>

checking stderr of ssh-client ;)

11:55

<vagrantc>

and what if the connection fails for other reasons?

11:56

anyways ...

11:58

<ogra-classmate>

ssh -S /tmp/.ltspfs_socket test -x /etc/X11/Xsession || echo False

11:59

easy test :)

11:59

<vagrantc>

so we create the socket before actually logging the user in?

11:59

<ogra-classmate>

we could have a control connection that we establish first

12:00

Egyptian[Home] has quit IRC

12:00

<ogra-classmate>

it doesnt need to be through the socket

12:00

<vagrantc>

the slowest part of an ssh connection is the initialization ... so we don't want to start over

12:00

prpplague has quit IRC

12:01

<jammcq>

can't we just install a script on the server that always goes in the same place? Then, the script would take care of finding the xsession file

12:01

<ogra-classmate>

how about creating the connection first and then attaching process by process to the socket

12:01

<vagrantc>

jammcq: but that would be installing something server-side!

12:02

jammcq: apparently, that's to be avoided at all costs

12:02

<jammcq>

umm, yeah, that's the point. do this step server-side, where the cpu is nice and fast

12:02

<ogra-classmate>

jammcq: not really, its very ugly to poke around in teh defaukts on teh server siide

12:02

<vagrantc>

jammcq: i'm with you here

12:02

<jammcq>

how is this "poking around in the defaults" ?

12:03

<vagrantc>

all this code will be infinitely simpler to write server-side.

12:03

<ogra-classmate>

/etc/X11/Xsessio.d is the system X defaukts dir

12:03

\its not intended to be used like we do all teh time

12:03

<vagrantc>

it will also make it work for both XDMCP and ssh based logins.

12:03

<jammcq>

did I say it should go in /etc/X11/Xsession.d ?

12:03

<ogra-classmate>

where elsed would you put it ...

12:03

<vagrantc>

/usr/bin/ldm-session

12:03

<jammcq>

umm, how about /usr/bin ?

12:03

<ogra-classmate>

bah

12:04

so the great feature of 'log in to any ssh server' is briken then ?

12:04

*broken

12:04

<vagrantc>

that great feature never existed

12:04

<jammcq>

"great feature" ?

12:04

hmm, /me never saw that spec

12:04

<ogra-classmate>

it always did

12:04

i do it all the time here

12:04

<vagrantc>

log into any ssh server that has all the files in the right places

12:05

<ogra-classmate>

thats the initital design i took over from mdz

12:05

<vagrantc>

+ as long as the ssh keys are known to the thin client

12:05

<jammcq>

umm, was that really a design criteria ? or was did it "just so happen to work" ?

12:06

<ogra-classmate>

he was very clear that nothing has to be changed server side to not break anything of the defaults and to not depend on extra software

12:06

<jammcq>

hmm, 'was did' ? dunno what I said there

12:06

<ogra-classmate>

right

12:06

<jammcq>

so now he's god, eh?

12:06

<ogra-classmate>

log in from any ubuntu TC to any ubuntu system with ssh server

12:06

<jammcq>

sorry, couldn't resist poking :)

12:07

I'd add: "As long as the server has been configured to allow that"

12:07

<ogra-classmate>

jammcq: nope, but matt had a reason for all decisions he made in teh initial design ...

12:07

<vagrantc>

+ x11-common + a window manager of some form or fashion

12:07

<jammcq>

some of those reasons were formulated in a vacuum

12:08

<ogra-classmate>

imho adding server sided deps is as bad as adding and removing stuff in user homedirs

12:08

<vagrantc>

why?

12:08

<jammcq>

so to fix it, we'll depend on some goofy trial and error between the client and the server every time a user logs in.

12:08

<ogra-classmate>

if you force me to accept it i will have no choice but i would expect us to do more proper solutions

12:09

<jammcq>

this isn't about forcing. this is about discussing possibly solutions, to decide what makes sense

12:09

<vagrantc>

at the moment, i think we've got some pretty improper solutions.

12:09

<jammcq>

agreed

12:09

we just need to find the lesser of the evils

12:09

<vagrantc>

and i'd like to fix that.

12:09

<ogra-classmate>

well, you wont get me into the add more deps and scripts to teh server side camp, imho we do already way to much on that side

12:10

<vagrantc>

what is so wrong with that?

12:10

<jammcq>

I think there's a certain set of things that need to be installed server-side, just to expect a thin client to work.

12:10

above and beyond the whole chroot thing

12:11

LTSP is becoming an "API". There needs to be a set of services and scripts available on the server, in a known location, for the thin client to connect

12:11

<ogra-classmate>

vagrantc: you tweak defaults (/etc/X11/Xsession.d), you override system settings /etc/ltsp introduce open ports (all the inetd stuff) etc etc thats just as wrong as poking around in userdata

12:12

meduxa has joined #ltsp

12:12

<vagrantc>

ogra-classmate: i'll not that all that stuff was added by you, not me :P

12:12

note

12:12

<ogra-classmate>

especially since you always need to make sure your tweaks dont clash wint any other system sesttings probably used by a desktop env you have never seen

12:12

vagrantc: i didnt say it was right to add

12:13

<jammcq>

if you dont' want to "open ports, override system things, etc", then possibly the right approach is more like a RDP, ICA, NX way, where ALL communication is served by a single protocol/daemon

12:13

<ogra-classmate>

i think i'm saying since 30 mi9n i want tio get rid of it for more proper solutions ;)

12:13

and dont want you to introduce more if the evil :)

12:14

<dan__t>

'morning.

12:14

<vagrantc>

ok. so in what way does setitng stuff client-side prevent clashing with other system settings?

12:14

<ogra-classmate>

we have a proper mechanism in place we dont fully use yet

12:14

* jammcq is lost

12:14

<ogra-classmate>

it will only happen from a thin client login

12:14

<jammcq>

dunno what "proper mechanism" is being refered to

12:15

<ogra-classmate>

jammcq: ssh and its capabilities, we dont use 10% of what we have

12:15

<jammcq>

so fine, use ssh where it shines, but I don't think it makes sense to use ssh to go searching for a session script

12:16

<ogra-classmate>

sure it does

12:16

why wouldnt it

12:16

<jammcq>

you say tomato, I say tomato

12:16

<ogra-classmate>

the greeter is the place wher we want that info

12:16

<jammcq>

it shouldn't because it's EXPENSIVE to do that

12:16

<ogra-classmate>

??

12:17

its not more expensive than what we do now, not a byte

12:17

well, probably a byute or two :)

12:18

<vagrantc>

right now, it's essentially a hard-coded default. opening another ssh connection would slow login down considerably.

12:18

<jammcq>

if ! ssh host /etc/X11/Xsession then if ! ssh host /etc/X11/xession then if ! ssh host /usr/bin/start_my_session then if ! ....

12:18

<ogra-classmate>

heh, no

12:18

<jammcq>

heh, ok

12:18

<ogra-classmate>

i'm taliking about changing the general design here ...

12:19

<jammcq>

I guess I haven't seen that talking yet

12:19

<ogra-classmate>

you establish a session without any X

12:19

then you have your socket

12:19

<vagrantc>

(at which point you'll need to establish a second session with X)

12:19

<ogra-classmate>

now you can execute anything you like through that socket, no extra costs

12:19

<jammcq>

like how?

12:19

Guaraldo has joined #ltsp

12:20

<jammcq>

how do I say "if [ -x /etc/X11/Xsession ]" over a socket ?

12:20

<ogra-classmate>

vagrantc: why ? ssh -S <socket> Xsession will just start the session in the existing tunnel

but there's still a cost ty running 'ssh -S <socketnname>' it doesn't come for free

12:22

<ogra-classmate>

no, indeed, but you are executing something that is already ion ram and hands over to the existing process after invoking

12:22

thats marginal

12:22

<jammcq>

we can debate that mirginal-ness all day, i'm not sure who's right there

12:23

there may be other things you are trying to solve with this <socketname> thing, I'm just thinking that finding the session script isn't one of them

12:23

<ogra-classmate>

well, i know it only attaches the server side process to the socket for IO and it wont live longer than that in my processlist

12:25

i think having a non Xsession connection established first and then using the socket here is the best thing we could do ...

12:26

<jammcq>

this really all boils down to who is gonna do the work. at this point, you are more likely to do it than I am, so naturally, you'll do it the way you think is best. I've said my opinions about where it should be done. the balls in your court

12:26

<ogra-classmate>

even better would beto build that with a bidirectional socket

12:27

that way we could redirectpower events ;)

12:28

* jammcq remembers several people saying we set the bar too high with ltsp-4.2. apparently we did something right

12:28

<vagrantc>

ok

12:28

"ssh -S <socket> -X" doesn't work after the fact

12:29

<ogra-classmate>

jammcq: well, actually the ball is more in vagrants court here :)

12:29

<jammcq>

heh

12:29

Burgundavia has quit IRC

12:29

<jammcq>

we could all be in for a surprise

12:29

<ogra-classmate>

we scared Burgundavia already :)

12:30

vagrantc: thats how ldm invokes it atm

12:30

<jammcq>

ogra-classmate: did you get that wireless driver for the classmate?

12:30

<ogra-classmate>

it could be that the socket file needs to exist or something

12:30

<Lumiere>

ogra-classmate: if I wanted to start a discussion about when edubuntu releases... where should I go?

12:30

<vagrantc>

ogra-classmate: no, it's invoked -M -S <socket>

12:30

<ogra-classmate>

jammcq: we got something two days ago, baenc is testing today

12:30

looks like a firmware issue

12:31

<jammcq>

cool, so it's Opensource, and hopefully going into the kernel?

12:31

<ogra-classmate>

vagrantc: ohy, indeed, you need to create a master socket

12:31

<vagrantc>

ogra-classmate: you have to enable the -X when you create the master socket, according to my quick experiment.

12:31

<ogra-classmate>

jammcq: if i understood ben right we already have everything but the firmware ... and the driver uses an hardcoded path for searching the frimware

12:32

the firmware is free and shippable

12:32

only the searchpath needs to be fioxed

12:32

<jammcq>

cool.

12:32

<ogra-classmate>

vagrantc: yes thats how i planned to do it

12:33

vagrantc: but dont start an Xsession

12:33

<vagrantc>

ogra-classmate: right ...

12:33

<ogra-classmate>

if the tunnel is established we start to do all wotrk through the socket

12:33

and start the found Xsession sriot from there

12:33

script

12:34

<vagrantc>

still going to be a hell of a lot more overhead than a server-side script.

12:34

<ogra-classmate>

that has the advantage that we can hand over global vars etc easily

12:34

but we have the proper communication going so errors can be forwarded, smartcdards will become an option etc

12:35

and i dont think its that much overhead

12:35

some ram for the second ssh binary

12:35

mosto of it should be shared with the first one running anyway

12:36

i will try to write a proof of concept if i'm done with the classmate

12:38

(which will surely still take some days ... i'm just starting to write an installer that operates from initramfs, punches the partitions on the flash and untars the system image)

12:40

vagrantc has quit IRC

12:53

bengoa has joined #ltsp

12:53

muh2000 has quit IRC

12:54

<bengoa>

jammcq, happy birthday buddy

12:54

<jammcq>

heh, thanks bengoa

12:54

<bengoa>

jammcq, :-)

12:55

<ogra-classmate>

jammcq: oh

12:55

ahppy birthday

12:55

or happy :)

12:55

<jammcq>

gee thanks ogra-classmate

12:57

<mistik1>

For he's a jolly good fellow, for he's a jolly fellow, for he's a jolly good fellooooooooooooow, which nobody can deny.

12:57

Happy Birthday Jim

12:58

Avatara has quit IRC

12:58

<jammcq>

mistik1: thanks, i'm getting tears in my eyes now

12:58

<mistik1>

;-)

12:59

<Guaraldo>

hi, jammcq... Happy Birthday to you!!!

13:00

<jammcq>

jeez, they're crawling out of the woodwork

13:00

<mistik1>

You're lucky we're not living closer, the Red Stripe would be on me today

13:01

<whiprush>

jammcq: happy birthday dude

13:01

<cliebow_>

yay!!!

13:02

<jammcq>

yeah, finally hit 29

13:02

<cliebow_>

heh

13:03

sepski has quit IRC

13:04

vdittgen has joined #LTSP

13:05

vdittgen has quit IRC

13:05

a5benwillis has joined #ltsp

13:09

spectra has joined #ltsp

13:10

maximi89 has joined #ltsp

13:10

<maximi89>

hi

13:10

recently i release to LTSP 5.0

13:10

few minuts ago i was using 4.2

13:10

but now with all changes i have a problem with sh: /etc/rc.early_sysinit: nout found

13:11

about that file /etc/rc.early_sysinit

13:11

what mean? that is because i dont have the tftpboot correctly? vmlinuz

13:12

/tftpboot/lts/2.6.16.1-ltsp-2

13:12

or /tftpboot/lts/2.6.17.8-ltsp-1

13:12

??

13:14

<jammcq>

maximi89: sounds like you are using LTSP-5 with a ltsp-4.2 kernel

13:15

gepatino has joined #ltsp

13:15

<maximi89>

uhmm how can i fix this problem?

13:15

i don't understand at all this problem

13:16

<jammcq>

look at your /etc/dhcpd.conf file, and see what 'filename' is set to

13:16

it might be in /etc/ltsp/dhcpd.conf

13:16

<maximi89>

filename "/tftpboot/lts/vmlinuz-2.6.16.1-ltsp-2";

13:16

<jammcq>

yeah, that's wrong

13:16

what distro?

13:16

<maximi89>

ok only like this:

13:16

filename "/etc/ltsp/dhcpd.conf";

13:16

Debian 4.0

13:17

uhmm?

13:17

where is that file /etc/ltsp/dhcpd.conf?

13:18

ltsp i think can be in my case ltsp-5.0

13:18

<jammcq>

you'll need to change it to '/var/lib/tftpboot/ltsp/i386/pxelinux.0'

13:18

but that's the PXE kernel

13:18

I think you might need an Etherboot kernel

13:18

<maximi89>

yes

13:18

<jammcq>

so, go look in /var/lib/tftpboot/ltsp/i386 and tell me what you see there

13:19

<maximi89>

ok

13:20

no, i don't have that directory

13:20

i have /tftboot/

13:20

<jammcq>

hmm

13:20

hmm, looks like we lost vagrantc, the guru in debian/ltsp

13:21

<maximi89>

xD

13:21

"que mala onda!"

13:23

http://pastebin.ca/507707

13:24

that is the /etc/dhcpd.conf

13:24

<jammcq>

maximi89: you installed from the tarball ?

13:24

<maximi89>

http://pastebin.ca/507715

13:25

uhmm the installers come from a community called "EducaLibre" in www.educalibre.cl

13:25

<jammcq>

hmm, maybe you need to talk to them.

13:31

privet has quit IRC

13:35

SBNet has joined #ltsp

13:35

bobby_C has joined #ltsp

13:41

joebaker has joined #ltsp

13:45

meduxa has quit IRC

13:46

<joebaker>

ogra: Remember the parallel port printer problem I had under Ubuntu 6.10 LTSP? It's working ok now under 7.04. THANK YOU!

13:47

<ogra-classmate>

yay, great :)

13:48

* ogra-classmate would love to fix serial printers this round, but doent know anyone owning one

13:49

<ogra-classmate>

maximi89: if you use debian you should use debians ltsp, not a third party one

13:49

!debian

13:49

<ltspbot>

ogra-classmate: "debian" is is a GNU/Linux based operating system that makes an excellent LTSP server. You can find it at http://www.debian.org. for information about LTSP on debian see http://wiki.debian.org/LTSP

13:51

<maximi89>

thanks guys

13:52

<dan__t>

Aaaalrighty. Anyone know how I might be able to change the desktop background on a client?

13:52

Using gnome

13:52

<jammcq>

sure, right click on the desktop, and select 'Change desktop background'

13:53

<dan__t>

Well, remotely heheh.

13:53

Through a config file or gconf2 maybe

13:54

<ogra-classmate>

in recent gnomes you should be able to drop a config file in /usr/share/gconf/defaults/

13:55

if you pick a sequence number around 25 your setting will override the system default

13:55

gepatino has quit IRC

13:55

<dan__t>

sequence number?

13:56

<ogra-classmate>

look i9n that dir, your diswtro should have put some defqaults in there already

i can easily get the thin clients to crash (hard-lock, no mouse movement) if i do things like log out with a bunch of applications open

18:40

it seems like the video chipsets are being detected correctly, as there are two different types of thin clients (thus video chipsets) but they behave the same

18:41

a5benwillis has joined #ltsp

18:41

<lns_>

ubuntu Feisty on the server btw

18:42

w/ltsp5 installed

18:42

and 2.6.20-15-386 kernel on the chroot

18:43

can anyone give me any clues as to investigation?

18:49

also, i get this weird dotted line toward the upper-left corner of the screen when X is starting

18:49

almost like video corruption..but but that only seems to be on the neoware boxes

18:50

ogra-classmate has quit IRC

19:05

lns_ has quit IRC

19:09

sbalneav_ has joined #ltsp

19:09

<sbalneav_>

Evening all

19:09

sbalneav_ is now known as sbalneav

19:30

youngun has joined #ltsp

19:31

<youngun>

is therre someon who can assit me in sound capture problems

19:32

anyone there

19:33

<sbalneav>

youngun: Hello, what can I help you with?

19:33

<youngun>

i have ltsp 5 (standalone)

19:33

i have redirected the sound

19:33

and when a client logs in it sounds off gud

19:34

but i can't get the web browsers to create sound like movie/news to work

19:34

ugh

19:34

I have downloaded flash

19:34

but still no sound

19:34

<sbalneav>

What distro are you running?

19:35

<youngun>

ubuntu ultimate

19:35

<sbalneav>

Which version?

19:35

<youngun>

7.04

19:35

<sbalneav>

So you're running feisty fawn?

19:35

<youngun>

with firefox 2.03 (which locks up on the clients)

19:35

yes

19:36

<sbalneav>

Well, check and see if the pulseaudio alsa redirector is loaded.

19:36

<youngun>

how?

19:37

<sbalneav>

lsmod should tell you. Paste the results to the pastebot

19:37

!pastebot

19:37

<ltspbot>

sbalneav: "pastebot" is The LTSP pastebot is at http://pastebot.ltsp.org. Please paste all text longer than a line or two to the pastebot, as it helps to reduce traffic in the channel. A link to the content will be pasted in the channel.