Is it just me, or is LTSP a mess?

[David Van Assche]

Rather than make this heated, lets try and keep it productive so the
thread becomes helpful rather than offensive.

On Wed, Sep 10, 2008 at 5:58 PM, R. Scott Belford <scott at hosef.org> wrote:
> 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.

This is a choice you make, but I agree that 7.10 had a lot of issues.
8.04, in stark contrast has few of the same issues, and works quite
well in production environments. Not to mention the fact that an LTS
should make you feel a little more comfortable than focusing on a
product which won't be supported much longer. I really don't
understand that last part of that paragraph about ubuntu cultures, but
I guess you are implying fixes are not being taken care of. This is
simply not true.

>>
>> - 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?

Have you tested all the skolelinux and k12ltsp versions?

You do realise that kde is not gnome right? (skolelinux = kde,
k12ltsplinux = kde as default)

skolelinux is debian
k12ltsp is centos or now Fedora

The code is the SAME in ALL LTSP 5... is that so hard to grasp?

And yes I have run both debian + ltsp and fedora + ltsp with exactly
the same misbehaving processes issue...

Or are you comparing LTSP 4.2 with LTSP 5? The 2 are entirely
different beasts, and you are welcome to continue using the older 4.2
if it seems more stable to you. But for a majority of users I'd
imagine they want to use something a little more recent than a 4 year
old OS running ancient kde...

>>
>>
>> - 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?

As stated above... intrepid... the documentation for
feisty/gutsy/hardy is a little outdated granted. irc is the second
line of support, if you don't find what you are looking for in
documentation...

>>
>> - 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.

please list the contradicting fixes that are in the documentation, as
I only know of the one I pasted from the documentation itself... it
would help to fix these documentation issues, and that I can do.

>>
>> 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

is included in hardy

> 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?

really don't know what you mean with that hack... its not a hack, its
an option... I've always used shorewall to masquerade my traffic, but
that's not the point. The point is that the reason this is not done by
default is that all networks are different as another user has already
agreed to and given an example in this same thread

>>
>> 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.

No... this is copy and paste from documentation...

>>
>> - 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

So you've spoken to Richard and Ollie about your concerns directly?

> 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.

Dude... I have just rewritten the documentation for LTSP, and lts.conf
is the SAME across all LTSP 5... the same file, the same options... is
this so difficult to grasp, I must be repeating myself...

> 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?

1. The options that lts.conf takes are the SAME across all distros...
obviously different users use different sets of these options...
2. LTSP 4.2 =! LTSP 5

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

have you got any idea of who ltsp upstream is right now? And what
exactly do you mean by lts.conf making ltsp _less_ complex..?
More deployable... I whole heartedly agree, as long as you don't mind
creating and editing the file ;-)

>
>
>>
>> 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.

can u note down which of your hardware requires lts.conf support
please. I'm just curious what you are using... I run 150 thin clients
at a deployed 8.04 location (all kinds of machines and graphics cards,
you couldn't get a more mixed up setup) and I use lts.conf to push
through resolution and printing, nothing more...

>>
>>
>> - 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?

Well, with emails like these, I can imagine their willpower dwindling
quickly... like I mentioned before I have no association with
canonical, but I do know the people who are responsible for making
LTSP and edubuntu available... they deserve a great deal of respect
for having done massive amounts of LTSP work that is now used in other
distros as well as ubuntu. I have been involved with this for a good 2
years now, so no I don't remember what ltsp 4.2 was like, but my depth
of experience is related to the amount of time I chose to get involved
in all aspects of ltsp 5 and its deployment in schools. I have been a
teacher using LTSP in the classroom, and a unix/linux sysadmin for 10+
years and I am involved in the community and have offered and now
completed  updating the LTSP documentation for all distros.

Kind Regards,
David Van Assche