Ubuntu-ltsp is not a mess! [ but needs some polish :) ]

[Scott Balneaves]

On Thu, Sep 11, 2008 at 02:07:23PM +0200, Pierre Yann Baco wrote:

> First sites used woody+LTSP4.2. Last june, the local education 
> department required all schools to be updated to Ubuntu Hardy + LTSP5. 
> I've done so (inc. adding an extra 64Mb in some (too) thin clients) in 
> august. Globally, the new solution runs fine. LTSP5 is easy to 
> setup-configure, it supports a large set of hardware, local USB-sound 
> works like a charm.

Good to hear.

> 1°) ldm:
>    - Not localized. This is a real issue in french (and I guess others) 
> elementary schools. "Username" and "Password" are simple english words 
> (and we french need to improve our english), but there should not be the 
> first two words displayed by a computer in a french school.

Interesting.  From the ldm code itself:

int
get_userid(char *str, int len)
{
    char *prompt1 = "prompt <b>";
    char *prompt2 = _("Username");
    char *prompt3 = "</b>\n";

So, we're surrounding the "Username" string with the g18n _() bit which SHOULD
provide translations.  There is a fr.po, with "Nom d'utilisateur" in it, so I'd
like to think you should get it, but I'll proviso here with the fact that I'm a
stereotypical Western Canadian who doesn't know much outside of English.  So
I'm somewhat at a loss here as to why that doesn't work.  Maybe someone else
can look at the code and tell us what we're doing wrong?

>    - NumLock off: Can't force NumLock ON prior to enter username and 
> password. 8 years old kids (and their teachers...) always forget to 
> press NumLock prior to enter their (often birtdhay date based) password, 
> and login fails until they realize it (sometimes they don't!)

I may be wrong here, but I'm not sure that should be part of LDM.  Personally,
how I've always solved this is by installing the "numlockx" package, and set up
an Xsession init script. So, create a file called /etc/X11/Xsession.d/80numlock
with:

numlockx on

in it.

However, if people feel this should be part of LTSP, we can look at adding it.
Come to think of it, someone may have done this at the recent hackfest, so I
can check that out, and backport to hardy if it's there.

>    - persistence of ldm screen after server shutdown or network failure: 
> When the server is down (or the link between it and a thin client), ldm 
> continues to ask gently for username/password "as usual". There's no way 
> for a user to know something is wrong "on the other side". You can't 
> imagine the number of support calls I get from users entering 20 times 
> in a row their login/passwords (as they can't check the server status 
> located elsewhere). With LTSP4.2, thin client gdm screens were 
> locked-greyed out when the network or the server was down.

Here's the issue with that one.  4.2 used XDM as the login method.  So,
essentially, X was just "running", and used UDP to get the login screen.  There
was keepalive packets, etc.

LDM is essentially an app that runs locally, collects the username and
password, and then spawns an ssh session to the server.  If the server's gone
down in the meantime, it won't know that until it tries to contact it.  Not
sure what the solution to that one is.  Maybe pinging the host right before the
ssh to see if it's alive, so we can issue an error message immediately?  I'll
put some thought to it.

> 2°) PolicyKit:
>    - Can't use GNOME administration utilities (users-admin etc.) on a 
> thin client. (same happens within NX remote sessions). Works only on 
> server console. It's also a real issue when the server is in a locked 
> room. I've found a couple of threads about this, but could not find a 
> real solution for it. I've tried almost all polkit-gnome-authorization 
> configurations: still no success. And don't even think to ask a teacher 
> to run useradd/userdel from command line to add 30 login names every 
> Sept 1st....

OK, we'll have a look into this one.  Is this a case where policy-kit isn't
remote aware, I wonder.

> 3°) Process cleanup:
>    - This list has received many posts about this (persistence of 
> processes after thin client logouts). There are workarounds, but no real 
> fix yet (or workaround included in a .deb update). My quick and dirty 
> workaround: crontab based reboot every night.

Rather than a reboot, a killjob would be better.

I understand everyone's frustration with this, but this isn't an LTSP problem,
period.  If something doesn't clean up after itself, that's a bug with that
program. The problem is, everyone comes to the LTSP mailing lists, or the
Edubuntu or K12LTSP mailing lists, etc, with this problem, and we keep "fixing"
it by writing ever more baroque "cleanup" jobs.  What we NEED users to do is
file bugs against the offending programs.  Maybe that's something we can do
next Wednesday: come up with an exhaustive list of "things that don't play nice
in an LTSP environment", file a set of bugs (or, find existsing bugs that have
already been filed), set up a wiki page with pointers to the bugs, and get the
LTSP community to comment/support the bugs to let the developers know how
important it is for their stuff to clean up after itself.  If they think the
only use case they have is a single user system where a logout also usually
implies a shutdown, they're not going to spend any time on their "cleanup".

>    - same (gnome) problem with the ~/.gvfs still mounted after user 
> logout. This generates a problem with userdel and/or other user 
> administration utilities (can't delete user homedir).

Exactly the same issue as above.  Things I see in my environment here:

gconfd's
gvfsd's
gam_server's

And less frequently, some oowriters and firefox's, but they're not usual
culprits.

> 4°) Sound compatibility with some educational programs:
>   - ChildsPlay and tuxpaint are not very happy with remote sound (no way 
> to quit the application except big red switch, (leaving CPU eating 
> processes). There's a workaround (manually disable esound in the launch 
> script), but it would be nice to have an add-on deb package (like 
> "tuxpaint-ltsp.deb") to integrate the workaround in the general 
> update/upgrade process.

Even better would be to get these programs off of old esound/writing directly
to /dev/dsp, and have them use the ALSA libs for sound so that they interact
seamlessly with pulse.  I think this one's either bugfile, or, alternatively,
if we can get some of the ltsp issues out of the way in the next few months,
I'd be willing to look into how hard it would be to patch them.

> No need to say I'm ready to help and contribute (more details, 
> additional testing, translation, etc.)

If you can chip in next Wednesday, I know it would be greatly appreciated by
myself, and probably others.

Looking forward to some bug squashing,

Cheers,
Scott

-- 
Scott L. Balneaves | "There are many causes I am prepared to die for,
Systems Department |  but no causes I am prepared to kill for."
Legal Aid Manitoba |    -- Mohandas Karamchand Gandhi