nubae's Habari | Linux and Education

I recently found myself banging my head against a wall because my fatclient script had stopped working for Jaunty, even though I was assured that the plugins code had not been modified. After some help in the #ltsp channel, I added set +x to the top of my script and set -x to the bottom, and this way saw specifically where the script was dying, which turned out to be due to another recent script that was smashing my own variables. This kind of thing happens because I've not uploaded the script upstream. Anyway, I tested the script and built a jaunty gnome evnironment which worked without problems. It was nice to see the quite significant speed increase one can get by using the script on modern netbooks with atom processors. As always, copy the script here and save to /usr/share/ltsp/plugins/ltsp-build-client/Ubuntu/030-fatclient

Rate It! (Average 0, 0 votes)

• 1
• 2
• 3
• 4
• 5

My previous attempts at installing opensuse have been mostly fiascos, but a lot has changed in the latest incarnation, opensuse 11.1. Unlike its predecessors, I installed it to the hard disk using a live dvd, available here: http://download.opensuse.org/repositories/Education/images/iso/

After loading up the dvd, which takes a while to start up, one is greeted with a blank desktop with a couple of options for using the DVD. You can run the LTSP server straight from the DVD without installing anything to the hard drive. This works by serving pre-built kiwi images to the clients. I, however, chose to install to the hard drive by using the installer found on the desktop.

Unlike previous attempts, I was asked only a couple of questions such as timezone, keyboard settings, and partitioning schematics, before the installation process got underway. About 30 minutes later I restarted my computer and had a nicely functional desktop running gnome. I have 2 network cards, but those were easy enough to setup, by clicking on the bottom left computer menu, and then choosing network. The settings here are quite straightforward, and I had to set my 2 network cards to be either internal or external, and make sure the network settings were correct. I set my LTSP facing network card to internal, which is important for firewall issues, and then ran easy-ltsp. Here I had to change a couple of settings for my dhcp server, as the default serves a 10.0.x.x range, which is often used by routers, like mine.

After doing this, I plugged in a thin client, and it loaded up with no problems. On startup, the thin client gives some options such as boot from hard disk, turn apic off, shell prompt. If nothing is chosen, it loads up the thin client and you can start using LTSP. Setting up users is best done through the GUI, but can be done from the terminal using the useradd -m command, which is slightly different from Ubuntu, but has much more integration with LDAP, which is useful for larger setups. I went on to setup italc for ltsp client monitoring. Italc requires a keypair to be created and permissions to be set so anyone in the group italc can read the keys by doing:

ica -createkeypair
chgrp -R italc /etc/italc/keys/private
chmod -R 640 /etc/italc/keys/private
chmod -R ug+X /etc/italc/keys/private

This will probably be done automatically in the next incarnation of the livedvd, but for now, it has to be done manually, if you change your network settings from the default.

I also chose to setup samba for file sharing, which was quite straightforward, and as with other services, is best setup through yast. The defaults seemed fine for what I wanted, which was users home directories shared, using nbd password. The only annoyance I found here is that you have to set the username and passwords for the smb shares from the terminal. It is possible to set up LDAP to work with samba to provide authentication through a gui, but that seems overkill for smaller setups. To setup a samba user with password I did: smbpasswd -a nubae

Just for the sake of trying it out, I went through the process of setting up LDAP with samba to see if windows systems could then login with no problems. I followed this tutorial: http://digiplan.eu.org/ldap-samba-howto-v4.html

That seemed to work fine, though it realls is far too complicated for the typical home or school user. Setting the smbpasswd and using samba to directly authenticate is far easier and faster to setup. Taking it further than the fileserver, I also tries using ldap to authenticate the LTSP users when logging into LDM, and that worked great. If one is interested in using the fatclient option for LTSP, using LDAP is required.

One of the interesting options with opensuse's LTSP is the ability to choose different types of images, such as nomad or AOE. Nomad is a useful image type for thin clients because it allows for the network disconnection with the client without loosing data. That is to say, a user can continue using the thin terminal when the network comes back. AOE is used for fatclient implementation, where services and apps run directly on the client, as opposed to on the server. Of course, there is also the local apps possibility, whereby individual apps are chosen to be run directly on the client. Under opensuse this is very easy to setup, using the easy-ltsp configurator. The easy-ltsp configurator also allows for individual setting for thin clients, such as installation of printers and so on.

A quick glance at the applications available makes you realise there is almost everything one could wish for in an educational environment. There are almost too many edu apps available. It would have been nice to see some grouping of the educational apps, to make life easier for teachers, but the choice is a great start, and quite unique amongst distros. Lacking were some teacher tools, for creating educational content, but I have it on good authority that these will be included soon.

All in all, I was quite impressed with Opensuse and the wide variety of services it can run, be it as a fileserver, ltsp server, ldap server, or desktop machine. The educational software collection is impressive, and the ability to use many kinds of images via easy-ltsp makes it quite friendly to use. I would have to say that next to Ubuntu, this is the best implementation of LTSP so far. The only negative thing I can say is that Opensuse tends to do things in its own way, as opposed to following the upstream projects, but this allows it to be ahead of the game. I will certainly continue using it as my main desktop alongside ubuntu.

Rate It! (Average 0, 0 votes)

• 1
• 2
• 3
• 4
• 5

We recently held a olpc / LTSP presentation in Vienna, which had the enormous turnout of 11 people. Though the turnout was pretty bad, it did give us the opportunity to be experimental and check the wonderful world of using sugar on various platforms via LTSP.

We hooked up 2 acers, a thin can (artec), a laptop acting as LTSP and ejabberd server, along with 2 traditional xos. Before going into the details of the experiment some explanation is due. LTSP stands for Linux Terminal Server Project, and refers to the use of a mainframe like infrastructure, where minimal systems without hardrives and little cpu and ram can be used as diskless terminals. The idea is that everything runs from the server, with the client netbooting the environment and using the little ram and cpu it has to load the kernel and connect its display session to the server.

Usually older computers (pentium 200hz+ with 64 MB ram) are re-used in this way, though there are various dedicated thin terminals that are mobile phone sized and are highly energy efficient. LTSP terminals usually have no moving parts, making them hard to break. Whereas the XO, and rightly so, has been marketed as the guerrilla
educational device for the 3rd world, it is a little tied in with a specific company and a specific set of hardware. Sugar on the other hand is not, and in my view the more hardware can run sugar natively and flawlessly, the closer we get to a solution that can really feed the masses. As the politics of OLPC grow and change, such as dropping
sugar support, or moving to windows (these are just speculations), Sugar's growth and deployment should not be affected. If anything gives sugar and Sugar Labs a firm grounding its its ability to run on multiple systems and scenarios. I am aware that Sugar Labs is in communication with various vendors and distributors, and it is only a matter of time before some interesting deals are struck.

In our presentation case, for a mobile server, we used a dual core 1.8ghz with 2 gigs of RAM. Setting up the server on the laptop was pretty straight forward, and involved installing LTSP on top of a base Ubuntu system, and then
adding ejabberd as well as Sugar sessions for all newly created users. One can choose other sessions of course, but our interest was to test collaboration on all the machines, in which case Sugar was our environment of choice, and the login session for all our users. Installing ejabberd on the ltsp server was the only requirement for sharing across all machines. I followed the instructions as layed out on the laptop.org wikipedia and nubae.com site. There are still some issues installing ejabberd, such as permissions of the /etc directory, but it has generally become much simpler to install for anyone. Without ejabberd the machines did see each other via xmpp-local, including seeing shared activities, but they tended to fall of the network neighborhood. With ejabberd the machines were visible continuously and were very responsive to connections.

For testing purposes we tried sharing chat across all the machines, which worked flawlessly. The applications in general seemed to load much faster than with the xo hardware, both on the thin can and the acer ones. It was nice to see that a dual core laptop with 2 gigs of ram was more than happy to serve 6 thin terminals at once. This makes
the perfect mobile school, with all the machinery fitting into one backpack!

The laptop server was set up to get wireless internet, and then hand out LTSP through the wired interface, using a gigabit switch as a connector. One of the things that still requires a lot of work, and perhaps this
is due to using Ubuntu, is getting all the activities to work. I tested various activities like puzzle slider and jigsaw puzzle, which just left the activity icon cursor flashing on the screen and eventually fell back to the main screen. Another problem was that turning off or restarting the session was nonreactive. Also many, of the items in the control panel either crashed sugar out completely (date/time) or didn't work. These problems have recently been turned into bug reports, so we hope by the next release of Ubuntu, the environment works as it should.

LTSP and sugar are a great combination and much wished for in schools in the developing and developed world. We will talk a little more about the advantages of LTSP, Sugar and scaling, as well as wireless LTSP and Fat clients in another article.

Rate It! (Average 0, 0 votes)

• 1
• 2
• 3
• 4
• 5

Making ssh less exploitable from internet brute force break in attempts is something relatively important and straight forward under ubuntu. The way LTSP works right now, makes the ssh handling available to the outside world if you dont block access to port 22 from the wan interface entirely. This is potentially unsafe if your users have weak passwords, because there is potential for anyone on the internet to gain user-level access by brute-force attack. The solution, which is somewhat controversial, as many say you should be making the passwords strong enough so you don't need this, is to create 2 instances of ssh, one serving the internal ip on port 2222 and one serving the wan interface on port 22. If you only have one interface, then both ssh sessions would serve the same interface, but one would serve port 22, and the other 2222. This is how to set this up:

sudo cp /etc/init.d/ssh /etc/init.d/ltsp-ssh
sudo cp /etc/default/ssh /etc/default/ltsp-ssh
sudo cp /etc/ssh/sshd_config /etc/ltsp/ltsp-sshd_config
sudo cp -a /var/run/sshd /var/run/ltsp-ssh
sudo sed -ie 's/Port 22/Port 2222/' /etc/ltsp/ltsp-sshd_config

Note that these are the filenames in a Debian-based system. Other systems may vary. Also you are free to use a different port than 2222, it is just used here as an example. If you are using 2 interfaces also do:

sudo sed -ie 's/#ListenAddress 0.0.0.0/ListenAddress 192.168.0.1/' /etc/ltsp/ltsp-sshd_config

Here change 192.168.0.1 as needed.

sudo sed -ie 's/#ListenAddress 0.0.0.0/ListenAddress 10.0.0.42/' /etc/ssh/sshd_config

Change 10.0.0.42 with the address of your wan facing interface.

You will also need to change the .pid of the new ssh instance:

sudo echo "PidFile /var/run/ltsp-sshd.pid" | tee -a /etc/ltsp/ltsp-sshd_config /dev/null
sudo sed -ie 's/SSHD_OPTS=/SSHD_OPTS=\"-f \/etc\/ltsp\/ltsp-sshd_config\"/' /etc/default/ltsp-ssh
sudo sed -ie 's/AllowUsers/AllowUsers *@192.168.0.0\/24/' /etc/ltsp/ltsp-sshd_config

Finally we harden the outward facing wan interface by doing the following:

sudo sed -ie 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -ie 's/PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -ie 's/AllowUsers/AllowUsers sysadmin nubae/' /etc/ssh/sshd_config

Changing your most trusted sudoing users for sysadmin and nubae in the above example.

To make the second ssh instance default to start also do:

sudo update-rc.d ltsp-ssh defaults

A final note is that the safest approach over all would be to put a firewall and port blocker on a totally different machine and only allow ssh access to one account on that computer, from which one could then access the internal network. But if you just have one server, hopefully this gives you peace of mind.

Rate It! (Average 0, 0 votes)

• 1
• 2
• 3
• 4
• 5