<div dir="ltr">On Tue, Sep 9, 2008 at 11:05 PM, David Van Assche <span dir="ltr"><<a href="mailto:dvanassche@gmail.com">dvanassche@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I've taken a look into the email in question, and can answer some<br>
questions. I in no way am affiliated with canonical, though I do work<br>
within the ed/ubuntu community. Firstly, Scott mentions not using<br>
8.04, clearly you should upgrade as that will solve 50% of your<br>
issues... the other issues are all valid, and I guess the problem is<br>
one of communication between developers and end users. Lets address<br>
the issues seperately:</blockquote><div><br>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. <br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
- The gnome lingering process problem<br>
<br>
Agreed.. this is a heavy issue that is a pain in the behind, but it is<br>
not LTSP centric... the fault lies with gnome. Right now the<br>
workaround is a watchdog script, which seems to work ok, but is by no<br>
means a fix... This needs to be tackled from the gnome side... Right<br>
now the solution is in monitoring and ending misbehaving processes<br>
through the script or by hand via pkill -u or killall. It makes sense<br>
to clean all processes at least 1 time per day... consider it<br>
maintenance.</blockquote><div><br>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?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
- tcm (thin client manager)<br>
<br>
Indeed this no longer exists, and I believe it has been discussed<br>
about here before on various occasions. Italc has replaced thin client<br>
manager as the software that should be run to control thin clients<br>
from a centralised location. The new documentation reflects this (new<br>
in intrepid ibex), and I agree it was confusing, but a quick jump to a<br>
channel of importance (#ltsp primarily, but also #edubuntu) will give<br>
you the answers you need. Or a search in google. To install it is<br>
apt-get install italc-client</blockquote><div><br>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?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
- port forwarding <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
The reason this is not built in is because no one knows how the<br>
network structure looks like at a particular location. There could be<br>
many different setups, but the documentation tells you how to easily<br>
do this in the most common way (this has been in documentation for a<br>
while now):</blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Setting network forwarding<br>
Primary server will act as an network gateway for other servers. With<br>
this configuration, other workstations will be able to<br>
access the network behind the primary server. Here is an example of<br>
script that setup the network forwarding. We put it in<br>
/etc/network/if-up.d/forward.sh, and make it executable. </blockquote><div><br>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?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The script<br>
will run at each network start. In this example, the primary<br>
server private IP is <a href="http://192.168.0.1" target="_blank">192.168.0.1</a>. It must be adapted for the IP address used.<br>
#!/bin/bash<br>
echo 1 > /proc/sys/net/ipv4/ip_forward<br>
echo Setting up the forwarding<br>
LAN_IP_NET="<a href="http://192.168.0.1/24" target="_blank">192.168.0.1/24</a>"<br>
LAN_NIC="eth1"<br>
OUT_NIC="eth0"<br>
iptables -t nat -A POSTROUTING -s $LAN_IP_NET -o $OUT_NIC -j MASQUERADE<br>
iptables -A FORWARD -j ACCEPT -i $LAN_NIC -s $LAN_IP_NET<br>
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT</blockquote><div><br>Is all of this above your fix for forwarding? There is neater documentation for this.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
- speaking to canonical employee<br>
<br>
Well, you may have spoken to canonical employees, but just like in any<br>
larger company, unless you talk to the ones involved in the area you<br>
are asking about, you'll probably get blank stares or answers that<br>
don't fit. You did not speak to any educational or ltsp canonical<br>
developer. I guarantee that if you search a little you'll quickly find<br>
out who they are. If you are serious about your issues and concerns,<br>
then why not try to contact one of these developers directly?</blockquote><div><br>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.<br>
<br>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.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
- lts.conf file<br>
<br>
This is where LTSP gets complex, and its the same across ALL<br>
distributions...</blockquote><div><br>This is absurd, David. LTS.CONF IS NOT THE SAME ACROSS ALL DISTRIBUTIONS. PERIOD.<br><br>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?<br>
<br>LTS.CONF is where LTSP gets less complex and more deployable if you have a good team upstream.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If you don't know how to create a file, then it is<br>
not recommended you touch a lts.conf file. Increasingly, reliance on<br>
this file has been diminished to the point that in MOST setups the<br>
lts.conf file is not really required. But if it is, a quick read<br>
through the documentation will show you an example file and where it<br>
should go.</blockquote><div><br>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. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
- upgrading from earlier versions<br>
<br>
Finally, I would recommend against upgrading, but instead noting the<br>
setup you have and migrating that to a new already working ltsp setup.<br>
If you have ubuntu 7.10, then installing a new 8.04 from the alternate<br>
cd is the best practice that will cause the least pain... and if you<br>
have problems... go to the #ltsp channel, where you will probably get<br>
an answer to any question within minutes. oh, and for the record...<br>
the devs do read this list...</blockquote><div><br>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?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Kind Regards,<br>
<font color="#888888">David Van Assche</font></blockquote><div><br>Aloha<br><br>--scott <br></div></div><br></div>