Is it just me, or is LTSP a mess?

[R. Scott Belford]

On Tue, Sep 9, 2008 at 11:05 PM, David Van Assche <dvanassche at gmail.com>wrote:

> I've taken a look into the email in question, and can answer some
> questions. I in no way am affiliated with canonical, though I do work
> within the ed/ubuntu community. Firstly, Scott mentions not using
> 8.04, clearly you should upgrade as that will solve 50% of your
> issues... the other issues are all valid, and I guess the problem is
> one of communication between developers and end users. Lets address
> the issues seperately:


Actually, David, I have tested 8.04 in my labs, have installed it several
times, but do not dare deploy it in a production environment.  7.10 was too
detrimental, and the Canonical/Edu/Ubu cultures are still maturing to the
point that user issues on an official mailing list find a path upstream to
real fixes.


>
> - The gnome lingering process problem
>
> Agreed.. this is a heavy issue that is a pain in the behind, but it is
> not LTSP centric... the fault lies with gnome. Right now the
> workaround is a watchdog script, which seems to work ok, but is by no
> means a fix... This needs to be tackled from the gnome side... Right
> now the solution is in monitoring and ending misbehaving processes
> through the script or by hand via pkill -u or killall. It makes sense
> to clean all processes at least 1 time per day... consider it
> maintenance.


The issue never existed in any K12LTSP or Skolelinux releases.  What did
they do differently?  Why are they not blaming Gnome?  Do you truly think
that telling a teacher just to run pkill or killall will help advance the
adoption of FOSS in schools?  Is this the final product that Edubuntu
seeks?  Are you familiar with the one-hour per week of Admin time that is
fundamental to the Skolelinux architecture?

>
>
> - tcm (thin client manager)
>
> Indeed this no longer exists, and I believe it has been discussed
> about here before on various occasions. Italc has replaced thin client
> manager as the software that should be run to control thin clients
> from a centralised location. The new documentation reflects this (new
> in intrepid ibex), and I agree it was confusing, but a quick jump to a
> channel of importance (#ltsp primarily, but also #edubuntu) will give
> you the answers you need. Or a search in google. To install it is
> apt-get install italc-client


Intrepid documentation addresses this, or Feisty/Hardy documentation address
this?  Why should a first-time adopter go to IRC or anywhere other than
Edubuntu documentation to solve this?  What is the goal of this project - to
appeal to advanced users or to appeal to educators?


>
>
> - port forwarding
>

>
> The reason this is not built in is because no one knows how the
> network structure looks like at a particular location. There could be
> many different setups, but the documentation tells you how to easily
> do this in the most common way (this has been in documentation for a
> while now):


The issue is that the standard method for activating port forwarding was
broken in Feisty.  You could not run echo 1 > /proc/sys/net/ipv4/ip_forward
and have it work.  It works fine in Debian.  The issue was not that port
forwarding was off by default.  It is off by default in Debian.  The
documentation had several, contradicting fixes, for a while now.


>
>
> Setting network forwarding
> Primary server will act as an network gateway for other servers. With
> this configuration, other workstations will be able to
> access the network behind the primary server. Here is an example of
> script that setup the network forwarding. We put it in
> /etc/network/if-up.d/forward.sh, and make it executable.


This is or is not included in Hardy?  If one wishes to share the WAN on a
LAN with Edubuntu, they also had to hack the dhcpd.conf file to set the
gateway to be the same IP address as the Edubuntu server.  You don't seem to
mention this below.  Have you shared your WAN in a Feisty environment with
computers other than thin-clients before?


> The script
> will run at each network start. In this example, the primary
> server private IP is 192.168.0.1. It must be adapted for the IP address
> used.
> #!/bin/bash
> echo 1 > /proc/sys/net/ipv4/ip_forward
> echo Setting up the forwarding
> LAN_IP_NET="192.168.0.1/24"
> LAN_NIC="eth1"
> OUT_NIC="eth0"
> iptables -t nat -A POSTROUTING -s $LAN_IP_NET -o $OUT_NIC -j MASQUERADE
> iptables -A FORWARD -j ACCEPT -i $LAN_NIC -s $LAN_IP_NET
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT


Is all of this above your fix for forwarding?  There is neater documentation
for this.

>
>
> - speaking to canonical employee
>
> Well, you may have spoken to canonical employees, but just like in any
> larger company, unless you talk to the ones involved in the area you
> are asking about, you'll probably get blank stares or answers that
> don't fit. You did not speak to any educational or ltsp canonical
> developer. I guarantee that if you search a little you'll quickly find
> out who they are. If you are serious about your issues and concerns,
> then why not try to contact one of these developers directly?


Do you know who I spoke with, David?  They knew Richard and Ollie.  Did you
notice in my commentary about speaking with them that it was their
suggestion that I blog or write about my issues on the mailing list?  I am
quite serious about my issues and concerns, I have used the official
Edubuntu mailing list to address them, I have addressed them with executives
who purportedly have relationships with Mr. Shuttleworth, and I have
addressed the education team that sometimes speaks up on this mailing list.

To date the meetings I set up for the Canonical executives interested in
selling into Hawaii's government and DOE are still waiting for follow-up
from Canonical.

>
>
> - lts.conf file
>
> This is where LTSP gets complex, and its the same across ALL
> distributions...


This is absurd, David.  LTS.CONF IS NOT THE SAME ACROSS ALL DISTRIBUTIONS.
PERIOD.

Have you seen the lts.conf file that came from the Jim McQuillan/Eric
Harrison combo with the K12LTSP?  I suppose not based on your comment.  Have
you seen the lts.conf file in Skolelinux?  Have you seen the different
LTS.CONF files shared by others on this list?

LTS.CONF is where LTSP gets less complex and more deployable if you have a
good team upstream.



> If you don't know how to create a file, then it is
> not recommended you touch a lts.conf file. Increasingly, reliance on
> this file has been diminished to the point that in MOST setups the
> lts.conf file is not really required. But if it is, a quick read
> through the documentation will show you an example file and where it
> should go.


Look, the fact of the matter is that the only way to support the generations
of hardware that the Edubuntu documentation said was supported was to tweak
LTS.CONF.  Period.


>
> - upgrading from earlier versions
>
> Finally, I would recommend against upgrading, but instead noting the
> setup you have and migrating that to a new already working ltsp setup.
> If you have ubuntu 7.10, then installing a new 8.04 from the alternate
> cd is the best practice that will cause the least pain... and if you
> have problems... go to the #ltsp channel, where you will probably get
> an answer to any question within minutes. oh, and for the record...
> the devs do read this list...


I find it hard to believe that any devs with any power or will to improve
Edu/Ubu Buntu actually read this list and take the time to test fixes.  What
is your relationship with Canonical and your depth of experience setting up,
deploying, supporting, and advocting on behalf of Thin Client setups, David?


>
>
> Kind Regards,
> David Van Assche


Aloha

--scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/edubuntu-users/attachments/20080910/cab9524b/attachment-0001.htm