Installing Firefox inside the LTSP chroot and setting LOCAL_APPS_MENU=True in lts.conf
will make Firefox to run locally on the thin client. The XDG integration takes care of adding the application in the menu or replacing it by the local application if it's already present.
Ahhh, the art of deception. I have, in fact been able to install Firefox in the LTSP chroot, and have also created and modified the lts.conf file appropriately. I have not found it true that the the application is replaced by the local application however. Nor have I been able to actually get Internet on Firefox when it is running as a local application. This is important because, as much as I enjoy seeing that familiar Firefox screen indicating that I am NOT, in fact, connected to the Internet, I think I speak for most users when I say that the value of Firefox is vastly diminished without Internet connectivity. Before I write more about that, however, let me give a little background to those who are about to walk in my footsteps.
I really don't understand why there is an opt/ltsp folder on the server or why it seems to have the exact same files that are on the Server file system already. I used to think that the server was operating in its own environment and the Clients were all in another environment under opt/ltsp and that to update the server was one thing, but to update the clients you had to use the command line and change root to opt/ltsp and then run updates from there. And while I still think this is sort of true, it doesn't explain why I can just install an application on the Server and that application will then become available on the Thin Clints. Shouldn't I have to install the application within opt/ltsp as well?
Anyhow, I followed this post and was able to install Firefox in the LTSP chroot, which I guess lets it run on the Thin Clients instead of the Server, and everything seemed to be fine. I can follow his command "ltsp-localapps firefox" on the Thin Clients and Firefox indeed pops up, although with no Internet. According to the post, I have to set up the Server as a NAT/Gateway or whatever. No problem, I get that: normally the Thin Clients look no further than the Server for their network information, but now we need them to be able to look beyond the Server to the actual Internet. Fine.
I followed as best as I could all the instructions on the How to NAT wiki page, and I thought I did everything right, even performing the checks (accurately I thought). At the end of the day, however, I could still not get Internet on Firefox as a local app. I even used my work Windows XP laptop to run ipconfig while on the LTSP network and couldn't get it to see past the Server. I'm not sure what I did wrong, but if I ever find out I'll be sure to post it here with the quickness.
What I really want to whine about, though, is the lack of accurate documentation available for things like this. I feel like the devs all complain about a lack of testers and inaccurate bug filing and maybe they are right about that last one (I wouldn't know, the process is so complex I just avoid it altogether because I'm afraid of doing something wrong). The former issue, though, could be helped with a little better documentation on things. Two examples:
Example 1:
I tried to set up my Server as a Gateway/NAT as described above, but here is the first check I am supposed to perform:
Test: Reboot the PC, to ensure it sees this and examine the default route (on linux type route -n).
Okay, I can reboot the PC (although the first time I followed this tutorial I thought I was supposed to reboot the Thin Client) but then what? I am supposed to ensure that it sees WHAT? How do I ensure that it sees this? What do I specifically do to ensure it sees whatever it is supposed to be seeing? Then I am supposed to examine the default route? Examine it for what? What am I examining and how will I know if something is wrong?
I guessed that I was supposed to ensure that the PC saw the change in the option routers. But there was no change to make for me. The "change" was to "change" a network address to what was set up by the LTSP install by default. If this is correct, shouldn't there be a note that this might be the case? As far as "examining" the default route, I guessed that this meant typing "ipconfig" in the command line on my Windows XP laptop while it was connected to the LTSP network. When I did this it seemed to show that it was seeing the "new" network address, but I didn't really know if what I was looking at was correct and I could proceed or not.
Example #2:
A while back I posted about kiosk mode in XFCE 4 and even posted the contents of my kioskrc file that locks down the Thin Clients. This was a huge breakthough because it allowed me to configure all the clients quickly with just one small file and I could be confident that they wouldn't be tinkered with my malevolent students. Well, Xubuntu Jaunty uses the latest version of XFCE, version 4.6. Overall the changes seem positive (I LOVE being able to click and drag to select multiple files on the desktop) but my old kioskrc trick doesn't work anymore, and there is NO documentation for XFCE 4.6. I don't mean that there is little documentation, or that the documentation is inadequate or hard to find. I mean that on the XFCE.org website under "documentation" it says:
We're sorry, but there is no documentation for 4.6 (yet).So, I play the waiting game (again) and they don't get their user testing.
Today I switched to GNOME , deciding to give it another try after bailing on it over a year ago. Unfortunately GNOME remains slower on Thin Clients than XFCE, gconf still sucks to use (I set a "disable switching users" key to "mandatory" and it entirely removed from the panel the button to log out AND refused to let me change the key back!), Pessulus is still lacking all the options I need (and thinks people are using Epiphany instead of Firefox for some inane reason) and Sabayon still crashes when I try to run it. It's like May 2008 all over again!
I'll be sure to post again when I have some good news. For now, I'm going to litter the intertubes with requests for information about XFCE kiosk details and clarification on the How to NAT. Cheers! -joe
6 comments:
Joe, I think it's a bit unfair to blame your lack of networking understanding on the LTSP developers. NAT or routing knowledge is an essential requirement for anyone wanting to set up a server for clients to connect through. There are a great many tutorials on both these topics as it is the heart of what makes TCP/IP work.
Setting up a server is not difficult, but for an desktop skill level user it can be a daunting task, but it is not the job of the LTSP devs to teach you that.
As with most software systems there is a great deal of dependency on other and mostly underlying systems that should be understood to a larger or lesser degree. This is the case here as well, so once you have an understanding of routing and/or NAT'ing on a linux server, most of your problems will go away I would think.
There is another way, see https://wiki.ubuntu.com/ThinClientProxyRedirect
You might want to try to a few things.
enable ip forward in the kernel on your server with:
echo 1 > /proc/sys/net/ipv4/ip_forward
and then setup a NAT rule to masquerade to your "outside" interface. Since my outside interface is eth1, I use:
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
(I have these two lines in my /etc/rc.local file)
Then chroot into /opt/ltsp/i386 and nano /etc/resolv.conf and add the nameservers that you have listed in /etc/resolv.conf on your server. Exit chroot environment and rebuild the client image.
When you boot your client, go into an ltsp-localapps xterm session and you should be able to ping any of your name servers by ip or name.
This will allow firefox to resolve names.
Scratch what I said about editing /etc/resolv.conf from the client terminal window. Instead, add SERVER, SEARCH_DOMAIN, and DNS_SERVER entries to your lts.conf file. My entries look like:
# IP address of the LTSP server
SERVER = 192.168.0.254
# Required to build /etc/resolv.conf on client
SEARCH_DOMAIN = isp-systems.lcl
DNS_SERVER = 192.168.1.5
Where I run a local network name server on 192.168.1.5
The SERVER entry is optional, but you do need both the SEARCH_DOMAIN and DNS_SERVER entries so the bootscript will build /etc/resolv.conf on the client.
You do still need the ip_forward and NAT rules from my previous post.
Drat, I hope that is clear:
echo 1 > /proc/sys/net/ipv4/ip_forward
and
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
are both on single lines.
The iptables NAT rule wrapped in this text box.
Joe, please do us all a favour and delete (and ban) all these sneaky bastard spammers that are filling up the comments?
thanks and regards
Post a Comment