"I expect that once most hardware that previously needed the fallback mode is covered, fallback mode will die. AIUI, fallback mode isn't meant to be a GNOME 2-by-stealth for Shell refuseniks, it's purely an attempt to accommodate hardware which doesn't support Shell."

I think `PHASE=session . usr/share/ltsp/ltsp_config` would be a bit more flexible, but I got the idea, let me thing about it...

16:24

staffencasa has joined IRC (staffencasa!~staffenca@128-193-146-230.oregonstate.edu)

16:26

<alkisg>

In my idea above, we'd start with a clean environment each time, and just run_parts whatever configuration sources we have. If one configuration source wants to use caching, it's their responsibility, we'd only cache the initramfs.d output

16:27

When do we want to have PROCESS_LTS_CONF=True?

16:27

And, which events do we have?

16:27

X started, Login, Logout, ?

16:29

artista_frustrad has joined IRC (artista_frustrad!~artista_f@189.30.138.160)

(btw, I plan to make the initscripts go away and write upstart scripts on the fly out of initramfs-scripts.d/)

16:53

<alkisg>

Nice, I thought about that :)

16:54

No need to conditionally disable them in this case

16:54

<Gadi>

part of this effort is to get a framework to which to move things

16:54

:)

16:54

<alkisg>

(just symlinks would do)

16:54

<Gadi>

that includes -cluster stuff

17:04

artista_frustrad has joined IRC (artista_frustrad!~artista_f@189.30.138.160)

17:04

<alkisg>

We wouldn't even have an equivalent of ltsp-setup and ltsp-core now, right?

17:05

<Gadi>

right

17:06

(in Ubuntu)

17:06

<alkisg>

Not in all distros?

17:07

<Gadi>

not sure all distros use upstart

17:07

so, they may have to customize initramfs-scripts.d/

17:07

<alkisg>

No I mean that we won't be using our own init/upstart script

17:07

We'll stick to whatever the disto has

17:07

<Gadi>

right

17:07

<alkisg>

And just modify config files in the initramfs.d

17:07

<Gadi>

that's my hope

17:08

and my upstart scripts right now will call screen_session on the appropriate tty

17:08

hughessd has joined IRC (hughessd!~hughessd@173-164-117-109-Oregon.hfc.comcastbusiness.net)

17:09

<alkisg>

Right, so you'll just modify/rewrite tty1.conf etc

17:09

<Gadi>

right, which will call screen_session 1

17:09

etc

17:09

<alkisg>

That's the equivalent of the "prompt" event?

17:10

<Gadi>

heh

17:10

good question

17:10

<alkisg>

Do we even need such an event? Or the initramfs is enough?

17:10

<Gadi>

well, we don't want to break cluster

17:10

not sure what happens in cluster when there are multiple screens

17:11

maybe mgariepy or stgrabe can weigh in

17:11

*stgraber

17:12

<alkisg>

Hmm.... suppose we have an rdesktop session, which needs to check various servers

17:12

I can't check on initramfs, as it'll want to check the next time it starts too

17:12

(after logout)

17:13

<Gadi>

define "check"

17:13

<alkisg>

Check load? Check availability?

17:14

<Gadi>

thats different than lts.conf

17:15

but, if you take the simple case of changing the server IP in lts.conf

17:15

and not wanting to reboot

17:15

<alkisg>

Maybe it gets the availability from the RDP_SERVERS lts.conf var, dunno...

17:15

<Gadi>

then, yes, that should be called in the rdesktop loop

17:16

<alkisg>

OK so let's stick to the -cluster defined events for now

17:16

<Gadi>

right

17:16

<alkisg>

How much caching do we need?

17:16

Let's start with lts.conf

17:16

There's not much point to check if it's modified

17:16

The question is, do you redownload it with tftp or not

17:17

<Gadi>

well, tftp is dumb, so you may want to turn that on its head, and say always download it with tftp but only process it if its modified

17:18

* alkisg times that...

17:18

<Gadi>

right - which takes longer

17:18

:)

17:19

heh - of course one might modify lts.conf for a different client

17:19

:P

17:21

maybe we should just have a param to enable re-downloading of lts.conf at phases other than boot. Then, if it causes too much pain on slower clients, they can turn it off

17:25

<alkisg>

getltscfg -a is a bit faster than tftp localhost, but not much. tftp server would prolly be slower, but anyway it's a good thing to check if lts.conf has been modified before calling getltscfg -a again.

17:25

Although I don't know how faster the check itself would be :)

17:26

Ah, not much if done with diff

17:26

(and tftp doesn't set the file date)

17:26

So anyway I think we can redownload lts.conf at all those events

17:27

Maybe we could avoid the logout event, but I don't think it's worth it to start caching just because of that

17:27

I think the case with getltscfg will be similar, and the ltsp_config.d scripts would even be faster

17:27

So I'm not sure that the whole save env/restore env is worth the trouble

17:28

<Gadi>

I think we will run into problems if we don't reset the env properly

17:28

on scripts that loop

17:28

<alkisg>

The screen.d scripts get a clean env from the upstart or init scripts

17:29

<Gadi>

but what about the screen_session script

17:29

it does not

17:29

screen.d scripts don't (usually) loop

17:29

with the exception of rdesktop

17:30

they usually exit and then are respawned by screen_session

17:37

<alkisg>

Gadi, will we have a screen_session script? Will we allow for changing SCREEN_xx dynamically?

17:37

<Gadi>

I would like to

17:37

yes

17:37

<alkisg>

So if e.g. I have SCREEN_02=shell, and SCREEN_07=ldm, and on ldm logout I get SCREEN_02=xterm, what do I do?

17:37

Kill the shell I have there and start an xterm?

17:38

<Gadi>

it might make more sense if you log out of the shell for it to come back as an xterm, no?

17:38

<pmatulis>

plugging a webcam into my thin client the device is not "registered", yet it works/registered on my laptop. troubleshooting tips?

17:39

<Gadi>

pmatulis: what distro?

17:39

<pmatulis>

Gadi: ubuntu 11.10

17:40

<alkisg>

Gadi: so, I'd check SCREEN_x (the one that I'm in), and modify init/ttyx.conf accordingly, and restart the ttyx service? Sounds complicated, but it still gives me a clean environment for my screen script

17:42

<pmatulis>

Gadi: this is from my laptop: http://paste.ubuntu.com/733313/

17:42

Gadi: this is from my thin client: http://paste.ubuntu.com/733314/

17:43

<alkisg>

Gadi, do you have a specific use case for the SCREEN_x dynamic changing?