How to Install Computer Labs

If you ever need to set up a large number of computers in identical configurations, you have a few options:

• Install each one individually by hand
• Automate the standard install process, for example using:
  • AIK for Windows;
  • Kickstart for Red Hat Linux, CentOS and Ubuntu; or
  • sysinstall and mfsroot for FreeBSD.
• Configure one machine exactly how you like it, and then exactly duplicate the hard disk to the others (disk imaging)

The first option (manual installation) is extremely slow, tedious, error-prone, unlikely to result in identical machines, and does not speed up future installations or reinstallations.

The second option requires using rarely-used and less tested parts of the installer, scales poorly in performance for simultaneous installations, and places limits on what you can customise. For example, it could be impossible to customise /etc/rc.conf using the installer on FreeBSD, and pre-installing SSH keys is tricky. I also spent days writing a sysinstall script to automate a process that I could have done in half an hour by configuring a single machine manually.

Therefore I prefer the third option, system imaging.

What is System Imaging

Imaging is the process of making exact copies of one machine’s hard disk, including all partitions, onto another. This only works when the second hard disk is at least as large as the first. It works best when all the PCs are identical.

Imaging is independent of the operating system. You can image Windows, FreeBSD, any version of Linux, dual-boot and triple-boot installations, whatever you like.

We successfully used imaging to set up the PCs for these workshops:

• AfNOG 2009, Cairo, all tracks
• KENET BMO Training, Nairobi 2009
• AfNOG 2010, Kigali, for three tracks: SA-E, SS-E and SI-F

How to Image

Many systems administrators have heard of Norton Ghost and Acronis True Image, two of the most popular commercial applications.

However, open source alternatives such as G4L (Linux-based) and its ancestor G4U (FreeBSD-based) are pretty good, and completely free. G4L however lacks a website, and it’s not obvious how best to use it, hence this post.

G4L is quite similar to G4U, and I could have used G4U instead. But I find the Linux kernel’s hardware support a bit better than FreeBSD’s, and G4L supports multicasting, which enables it to install many machines at the same time with good performance.

Using Ghost for Linux (G4L)

I’ve successfully used Ghost 4 Linux (G4L) versions 0.27 and 0.33 for this process. 0.33 has multicast support, which allows setting up an entire room in one go, without wasting network bandwidth copying the same 4 GB disk image to each of 50 machines independently.

Set up an FTP server on your network with an account that supports downloads and uploads (e.g. on a local server on your network). Make sure it has plenty of disk space free, perhaps 40 GB. Create an “img” directory under the FTP user’s home directory for the images.

Download G4L and burn some CDs, maybe about five copies, or set up network booting (this conflicts with FreeBSD PXE installation and may require BIOS setup changes to enable PXE).

To boot into G4L:

• Reboot or power up the machine
• Press the key to choose boot device
• If CD-ROM is not on the list, reboot, go into the BIOS and enable booting from CD-ROM
• Choose to boot from the CD
• Choose the default kernel at the GRUB screen (just press Enter)
  • If for some reason the default kernel doesn’t work, the machine hangs or crashes or doesn’t detect the network interface, then try one or two other kernels
• Wait for the kernel and initrd to be loaded (two long lines of dots)
• Then you can remove the CD, about one minute from cold boot, and start booting another PC
• Press space to skip each of the information/advertising screens (about 8 of them)
• Enter g4l at the prompt (if you go past this and get a shell, just type g4l at the shell prompt)
• You can access other consoles with Ctrl-Alt-F1 to F4, log in as g4l with no password, and run g4l, ifconfig, ping or whatever
• Choose Network Use (default)
• Choose Raw Mode (default)
• Check that you have an IP address (option B) or try again to acquire one by DHCP
• If you can’t get an IP address by DHCP, check your cabling and DHCP server

Create a Restore Image (optional)

Back up one of your PCs if necessary (if you plan to restore the PCs later) by:

• Follow the procedure above to get into Ghost for Linux
• Enter the FTP server’s IP address, username and password
• Choose an image name, e.g. backup_original_2010_07_22.img
• Choose the back up option
• Press Space to select the entire disk (mark it with an asterisk [*])
• Start backing up the image

This process can take 1-2 hours. In the mean time…

Set up the Master PC

Boot G4L on the PC that you will use as the master. Use DD to wipe the entire disk with zeroes:

dd if=/dev/zero of=/dev/sda bs=1M

This makes the image much smaller, and transfer much faster.

Install FreeBSD or whatever operating system(s) on the master PC, and set it up exactly the way you want all of the PCs to be. Examples include:

• Install Gnome (gnome/gnome2)
• Install Xorg (x11/xorg)
• Install Firefox (www/firefox35)
• Install Xpdf (print/xpdf)
• Enable gnome and sshd in /etc/rc.conf, and add templates for the IP address configuration (this saves typing when setting all the machines to static IPs):

  hostname="pc01.sse.ws.afnog.org"
  ifconfig_bge0="dhcp"
  # ifconfig_bge0="196.200.219.101/24"
  defaultrouter="196.200.219.254"
  gnome_enable="YES"
  sshd_enable="YES"
  

• Create a user account (e.g. username afnog, password afnog)
• Log into Gnome, add firefox, terminal and the Downloads folder to your toolbar, and remove epiphany and evolution
• Edit /etc/fstab and add the proc filesystem:

  proc /proc procfs rw 0 0
  

  (this allows GDM to display the user list and shut down and restart the machine)

• Edit /etc/profile and set the default pager to less by adding:

  PAGER=less; export PAGER
  

• Set the timezone by softlinking /etc/localtime to something like /usr/share/zoneinfo/Africa/Kigali
• Create /etc/rc.local and have it run /usr/sbin/ntpd -qg to set the time once at boot

I recommend using DHCP on this machine. Otherwise all the imaged machines will boot up with the same IP address, causing IP address conflicts, and you will have to reconfigure them before you can access the Internet at all, or reconfigure them automatically.

Create some SSH keys for use in administering the machines. You may wish to set up the local server already and generate the keys there for security. I recommend adding the keys to /root/.ssh/authorized_keys. Please test that they work, and that sshd comes up automatically after boot!

Imaging the other PCs

On all the PCs (master and clones):

• Boot G4L as above
• Check that it has an IP address (option B)

Once a master is online, all the PCs will show “press any key to start”. Pressing any key on any computer will start all the machines imaging. If any PCs are not ready yet, you will have to cancel the imaging process on all of them and start again, or image those PCs later. So:

Start the master last! (when all the other PCs are ready)

Start the clones first, by following these steps on each one:

• Choose UDP Multicast Client (option U)
• Select the entire disk, /dev/sda with the space key
• Say yes, you’re sure
• When it says “Compressed UDP receiver”, it’s ready and waiting for a master to appear on the network

Then start the master:

• Get ALL the clones ready, as above, before doing this!
• On the master, choose UDP Multicast Server (option W)
• Select the entire disk, /dev/sda, with the space key
• Leave the options blank
• Say yes, you’re sure
• The master start accepting connections from clients, which will happen automatically. The screens on the clients will also change.
• Please check that every client says “Press any key to start”.
• If not, please check it for network problems, etc.
• DO NOT stop or kill the server now, unless you want to visit every client again!
• You can press Ctrl+C on the client and run g4l again to check the IP address, retry DHCP, and try the UDP Multicast Client option again.
• This is your last chance to join any remaining clients to the group for this imaging session!
• When all the clients are ready, press a key on the master to start transfer.

The master will show progress of the transfer, and an error line if any clients fail to respond. Clients that cause too many errors will be kicked out of the group and appear to “finish” early.

It’s difficult to tell if the imaging process finished successfully or failed on the clients. However it appears that FreeBSD is very good at detecting filesystem corruption, and will fail to boot if the image was not completely transferred. So you can test them by trying to boot FreeBSD and seeing if it boots completely or stops with a filesystem error. Ideally this would be improved in future versions of G4L.

So I was very interested to see a new training workshop being run by the Science Dissemination Unit (SDU) of the Abdus Salam International Centre for Theoretical Physics (ICTP). The workshop is on Mobile Science: Sensing, Computing and Dissemination and the deadline for applications is tomorrow, July 10th.

Quoting from the announcement:

The Science Dissemination Unit (SDU) of the Abdus Salam International Centre for Theoretical Physics (ICTP), with the assistance of the University of Washington (USA) and of the UCLA Centerfor Embedded Networked Sensing (USA) will hold a Workshop on “Mobile Science: Sensing, Computing and Dissemination” in Trieste (Italy) from the 2 to the 5 of November 2010.

Mobile applications offer tremendous benefits to academic research and
education, and to society as a whole throughout the world. This is an
opportunity that deserves attention and promotion, especially in less
developed areas where mobile phones are the first telecommunications
technology in history to have more users than in the developed world.

The specific things that interested me were:

The Mobile Science workshop aims to engage the scientific community in developing countries in the design, development, and deployment of the newest mobile scientific applications;

i.e. advocating appropriate mobile applications in scientific
research/academia;

Participants will learn how to apply mobile technology tools to retrieve scientific data

I.e. designing mobile apps for science data collection;

how to apply appropriate web-based analysis to assimilate mobile data into scientific studies

I.e. web-based statistical analysis and presentation, like a free online version of SPSS? As far as I know this doesn’t exist yet. The closest that I can think of is the Google Docs spreadsheet, which is of course just a spreadsheet, requires an internet connection and doesn’t allow plugins for additional scientific analysis functionality. But there could be a very interesting app to develop here.

and how to share their scientific findings with a potentially large mobile audience.

I.e. low bandwidth design with an emphasis on web standards for cross-platform compatibility, so that it works on the largest number of mobile devices.

If you want to apply, better get on your bike (or modem?) because the deadline is tomorrow. If you want to do mobile scientific research applications, please get in touch, we’d like to help you.

We were helping to deliver hands-on computer training for 150 young Zambian women as part of our ongoing work with Camfed. The training was framed as an introduction to email; for many it was a first introduction to computers.

We did not expect great Internet connectivity. We set up  a local email system  for the training to avoid dependency on a good connection. While practical, this approach wasn’t ideal as we wanted to offer as much real experience of the Internet as possible.

The rural high school where we were working  has a small IT lab that is connected to the Internet through a directional WIFI link to a near by youth skills centre where there is a VSAT link to the rest of the world.

The environment was harsh for network equipment. The mains power supply was was poor, with regular cuts and brown outs. The school and skills centre both had back-up generators but these  were started manually and not always at the same time. The route to the Internet could not have been called reliable. Neither building normally had UPSs to condition the power to their network equipment, though fortunately we had brought some with us.

Adjusting the antenna to improve signal-to-noise ratio

When conditions conspired to supply power to all the right places, Internet access at the school worked, but it wasn’t great. A VSAT connection has an unavoidably high latency and costs prohibit high bandwidth connections. The  Internet connection at the school was a nominal 1Mbit/s with a 1:10 contention ratio which means we were sharing our satellite bandwidth with nine other user sites. This works well in countries with abundant Internet connectivity as network use is effectively intermittent and sharing doesn’t cause much degradation of service. In Zambia, and much of Africa, a connection like his is often shared between a number  schools, hospitals and telecentres, etc., meaning network use is almost constant. Our experience of bandwidth was often that of the worst-case: 12Kbyte/s.  Though we soon found there were more serious problems with the connection.

Corruption

The web is surprisingly forgiving over a lossy connection experiencing data corruption, and at first it was easy to dismiss slow page load times as a limitation of the connection. Though it soon became obvious that something else was wrong. The image above shows corruption to image data downloaded from a popular mapping site.

A web page with corrupted content can be simply reloaded, but when downloading Ubuntu packages to update a machine we found the md5sums weren’t matching.

The following tests helped us uncover network faults:

• Pinging hosts on the Internet route using a larger packet (-s packet size).
• Downloading a large file with a known hash and comparing the computed value. If the hash value didn’t match, then repeating the download and checking if the computed value has changed.
• Using MTR to see at what router packet loss is occurring.
• Using Network Diagnostic Tool from a JAVA enabled browser to measure network performance.

Having identified the problem we wanted to establish that the corruption wasn’t happening on our own network: we repeated  the above tests while directly connected to the school’s router, and using more than one computer. The corruption was happening somewhere upstream of our connection, so we called our local ISP (by mobile telephone):

“Can we get an engineer to look into this?”

“Our engineers only visit Samfya district as part of a regular inspection”

“How often do your engineers come out?”…

“Once a month”.

No such visit was likely before we left Zambia. We needed  to find a workaround.

When running a shell over SSH on the trouble connection,  every so often the session would close with a “Corrupted MAC on input” error. This indicates that the last SSH packet failed verification, presumably because the underlying transport layers failed to guarantee the integrity of the data. It seemed like this characteristic could be useful in building a system to help download large files.

Being able to drop connections when ever packets are corrupted isn’t in itself going to help download complete files. But it does mean that a file transfer application running over SSH will never unknowingly write incorrect data to the file (up to the point that SSH MAC checks can detect the problem). This lead to the idea of a brute force solution by persistently running a file transfer application over SSH until the whole file is successfully downloaded. The file transfer application must be able to resume part-way through a file if the link is dropped. A suitable application is rsync.

If files are available on a remote host which can be accessed using public key authentication so that it can be left running unattended, the described work around becomes in shell script form;

return 1
until [ $? -eq 0 ] ; do
 rsync -axrv --partial --inplace <remote-host>:directory .
done

With this method we were able to retrieve the Ubuntu packages we needed up update our servers.

Is there a better way?

Having to manually transfer data through a third machine is inconvenient, a better solution would be transparent to the existing network. Although we can’t easily solve the underlying problem, which is the failure of the relatively small size of the TCP checksum to guarantee the data integrity (in this instance), it is possible to create the conditions where it’s no longer a problem. To do this we might look at reliable transport protocols implemented on top of UDP, which could then be used to tunnel the troubled TCP connections.

Here’s the synopsis… (although Africa Gathering has previously been described as an “unconference” so I may be tempted to slip into a bit of “unpresentation” if the situation warrants it).

The reciprocal relationship between ICTs and Participation

Over the last few decades of software engineering there is a rising tide of emphasis on the value of participation. The growth of the “Agile” software methodologies is a good example. The finding, which really shouldn’t be that surprising, is that participation makes better software. Participation with the client, with the users with the
stakeholders etc.

Seven years ago, at the start of Aptivate, that’s how we saw participation. As a means to creating better software. Over the last year we have seen that relationship reverse. IT is a means for better participation. It’s not just that new technologies like web 2.0 enable people to collaborate. Engaging in software projects themselves are excellent excuses for participation and human development. Finally, the dog is wagging the tail again and not the other way round.

Africa Gathering will be in London on the 2nd and 3rd of July. Get your tickets now while there’s still some left! For more information see the Africa Gathering site.

Jakob Nielsen

13 years ago Jakob Nielsen wrote an important article stating that one of the most significant factors in web usability is speed.

In the work that we do, designing web applications that are used in developing countries, we have taken this advice very much to heart.

13 years later Jakob Nielsen has felt the need to write a new version of that article again. And I am glad he has! Despite the roll out of broadband web authors are still creating sites that are slow, although for different reasons, according to Jakob.

In the original article Jakob said that large images were the main culprit in causing slow web pages. Now he says, with the advent of broadband, large images are not the main problem.

Interestingly, with the sites we look at and the connection speeds we deal with, large images still are one of the main contributing factors to slow sites.

Jakob now lays the blame on too many fancy widgets.

I would agree with Jakob here. In my experience the size of javascript is now rivalling that of the large images for the sites we’re interested in.

The research into user interface response times is as true now as it was back in 1968 when it was done. From Nielsen’s article, remember these times:

• 0.1 seconds gives the feeling of instantaneous response — that is, the outcome feels like it was caused by the user, not the computer.
• 1 second keeps the user’s flow of thought seamless. Users can sense a delay, and thus know the computer is generating the outcome, but they still feel in control of the overall experience and that they’re moving freely rather than waiting on the computer.
• 10 seconds keeps the user’s attention. From 1–10 seconds, users definitely feel at the mercy of the computer and wish it was faster, but they can handle it. After 10 seconds, they start thinking about other things, making it harder to get their brains back on track once the computer finally does respond.

A 10-second delay will often make users leave a site immediately.

Now consider the implications of these times in conjunction with your users’ connection speed, particularly if they happen to be in the developing world.

(see also our web design guidelines for low bandwidth connections.)

Imagine for a moment you’re an engineer working on hard-drive design. Your goal is obvious – you want to cram more stuff in less area on a disk. You want it to work faster and for mobile devices in particular, use less power. It might not be easy to achieve but you know what you’re trying to do.

Imagine you’re a chip designer. What are your goals? You want to make chips with more stuff in less area, that work faster and use less power.

So while Moore’s Law states that the hardware capability follows a geometric increase, Alan’s Random Idea says that software capability increases linearly.

Imagine you’re working on the Microsoft Excel team. What’s your goal? You can already embed the kitchen sink in a cell. What are you going to make it do next? Put the cells in a cube instead of a grid? (Hey.. that’s actually quite a mad idea… hmm… that’s another blog post).

The goals for software, for what we want to do with computers, require more imagination. So REAL software capability progresses linearly.

The area between Moore’s curve and mine I call “guff“. The not-so essential stuff we waste all our computing power on.

Let me give you an example of what I mean. Do you remember DOS? That thing we had before Windows? Even on an old DOS machine you can run WordPerfect, the word processor and Visicalc the spreadsheet. I bet you could even run an email program on it. A lot of the business value you get from a computer in most small businesses is in doing email, writing documents and working out things in spreadsheets.

Guff, the Great Leap and the Bicycle

The Brompton folding bicycle is a classic in design. Beautifully engineered and fantastically functional. People love Bromptons. You could own one for 10 years and it wouldn’t even lose 10% of its value. They’re expensive too.

At the other end of the spectrum we have the “Cambridge Bicycle“. Cambridge must be the world capital of bicycle theft. The un-written rule in Cambridge is you should spend more on your lock than on the bike. And most people don’t like to spend more than £20 on a lock. The bikes are atrocious. New-comers to Cambridge at first cower away when they see a typical bike worried that just being near the rusting, brake-less thing might pre-dispose them to having a nasty accident.

However, from a distance… a long distance… (like out in space), the difference in capability between someone with a Brompton and a Cambridge Bike is a lot less than that between having a Cambridge bike and having none at all. However terrible a Cambridge bike may be, it’s already made the “Great Leap“.

The same is true of the DOS machine, which is the Cambridge Bicycle of the of the computing world. It’s also already made the Great Leap between having no computer and having something useful. Moore’s Law means that the cost of making the Great Leap becomes, at least in theory, incredibly cheap. The current crop of mobile phones have enough processing power to run a business. In a couple of years time they will be throw-away items.

There are many people in the world who are seriously constrained by resources, who are living on just a few dollars a day. Perhaps Moore’s Law and Alan’s Random Idea might mean they have a chance, if they can get by without the guff, of making a great leap.

This was the gist of a last minute lightning talk I gave at SPA2010.

C’est grâce au soutient de l’INASP que nous avons pu développer notre Guide de conception Web pour environnements à bande passante faible en 2007, et ce dans le cadre d’une initiative visant à faciliter l’accès aux informations en ligne partout dans le monde, quel que soit le niveau de bande passante disponible. Nous utilisons les techniques décrites dans ce guide dans les divers projets centrés sur le contenu en ligne et les sites Web auxquels nous participons en collaboration avec nos partenaires.

Nous comptons à présent transférer ce guide depuis notre site Web vers Wordpress afin d’en faciliter la future traduction. Si vous souhaitez nous aider à traduire ce guide dans votre langue ou nous faire part de vos suggestions en matière d’ajouts ou de spécifications, n’hésitez pas à nous contacter.

We launched the guidelines with the support of INASP in 2007, as part of our ongoing efforts to make online information accessible to as many people as possible, regardless of their location or bandwidth. The techniques described in the guidelines inform our work on projects with partner organisations based around online content and websites.

We’re currently looking at moving the guidelines over from static content to Wordpress, which will make translation into other languages even easier in the future. If you would like to work with us to translate the guidelines into another language, please contact us. If you have suggestions for material that we could add to the guidelines, we’d like to hear about that too.

The average size of web pages has been growing much faster than the average speed of connections in developing countries, and journal websites are no exception, as you can see in Alan’s blog post:

Average Page Size vs Bandwidth

As Alan points out, the average journal’s home page in his sample would take over 90 seconds to load on average, for researchers at universities in developing countries. Usability research has shown that people expect a computer to respond within 30 seconds. Making them wait longer interrupts their concentration, causes dissatisfaction and annoyance, and they often abandon the process. The biggest factor in user satisfaction is speed of response.

While this research probably did not include users who are accustomed to slow and unreliable computers, I think it’s safe to say that most people would find it annoying and difficult to use the Internet on a dial-up modem. And even a modem would have been preferable to some of the Internet connections that I’ve experienced (and paid for) in some countries in the last few years.

Academics have little ability to persuade their universities to upgrade their internet connections, at a cost of several peoples’ salaries (several thousand dollars a month). The only people who can change this are the publishers of the journals, by optimising their journals’ websites for users with slower connections.

But how to persuade the publishers that this is important? We built a low bandwidth simulator ourselves, and took it to Oxford, to INASP and the ACU’s Publishers for Development conference.

What We Did

We set up spare machine as a bandwidth management box, and used it as a network filter for the participants. They could come and plug their laptops into the box, and browse the Internet and their own websites at a simulated slow speed.

Exercise Table

We configured the box for transparent bridging. This allowed us to insert and remove it from the network easily, just by switching over a network cable, to demonstrate the difference between fast and slow loading of pages.

We gave the participants at the meeting tasks to perform on various publishers’ websites, for example finding and downloading an academic paper by topic or researcher.

Playing the Game

I think they found the activities enlightening, because we had some very good comments from some of the participants:

• “We’re so pleased that Alan was able to work his magic at the recent PfD session – his delivery is innovative, dynamic and fact-packed so it really sparks enthusiasm from the audience… [which] is demonstrably channelled into action once people return to their places of work.“
  Publishers for Development Team
• “It was really useful to try the low bandwidth! [Our site] is already considered fast but it made us think even more around this issue, what else can we do etc.“
  Anonymous Participant
• “Alan Jackson’s information about bandwidth was kind of shocking even if I knew it before, but to really experience it was very valuable. We are going to redesign DOAJ’s home page and this must be the starting point.“
  Sonja Brage, DOAJ
• “Site speed is a major consideration for us, and I really enjoyed Alan/Aptivate’s session, experiencing the exasperation of trying (and failing) to connect via low-bandwidth… I have a feeling that there is ‘excess baggage’ on a number of the pages…“
  James Kitchen, OECD

How We Did It

We used FreeBSD as the operating system for the software bridge, because its dummynet traffic shaper is relatively easy to use, and very good at simulating slow connections.

We wanted to use a laptop instead of a desktop machine, so that we could carry it to the conference easily, but we had hardware compatibility issues with FreeBSD on all the laptops we had available to us (mostly IBM Thinkpads). We ended up using a compact Fujitsu desktop box.

We installed FreeBSD 8 on it, and configured it to transparently bridge between two interfaces. Our internet access at the conference would be wireless, but we had issues with bridging wired and wireless interfaces together. So instead we used a Linksys WRT-54GL router with the Tomato firmware, which enables wireless client mode, to connect to the network:

Throttler Network Diagram

And this is what it looked like in the room. Notice the essential coffee and cupcake, without which the system mysteriously failed to work:

Network Close Up

We configured the FreeBSD box to bring up the bridge automatically at boot time, and to load a set of ipfw firewall rules to enable dummynet, the traffic shaper. On this box, the ethernet interfaces are called em0 and rl0, so we added the following lines to /etc/rc.conf:

ifconfig_em0="up"
ifconfig_rl0="up"
cloned_interfaces="bridge0"
ifconfig_bridge0="addm em0 addm rl0 up dhcp"

firewall_enable="YES"
firewall_type="/etc/ipfw.rules"
dummynet_enable="YES"

Then we created /etc/ipfw.rules with the following contents:

# with bridge mode, two nics. em0 is wan
add pipe 1 all from any to any out recv em0
add pipe 2 all from any to any out xmit em0
add allow all from any to any
pipe 1 config delay 700ms bw 40Kbit/s mask dst-ip 0x000000ff
pipe 2 config delay 700ms bw 40Kbit/s mask src-ip 0x000000ff

This configuration creates two dummynet pipes. Pipe 1 is for traffic received on the external interface (downloads), and pipe 2 is for traffic being sent out of the external interface (uploads). We have to follow this by a rule which allows all other traffic, otherwise local traffic (on the box itself) is denied by default when the firewall is enabled, which breaks local DNS and inbound SSH and makes the box pretty unusable on the console.

Then we configure both pipes to allocate 40 Kbps (kilobits per second) for each individual IP address in the private subnet (allocated by the DHCP server on the Tomato router) and a 700 ms delay in each direction, which gives a 1400 ms round trip time. This is somewhat higher than the expected 600 ms round trip for a connection by geostationary satellite.

The end result is that each user connects a laptop to the switch behind the box, gets an IP address from the DHCP server on the router, is NATted by the router onto the public network, and is able to browse the Internet with a connection of 40 kbps upload and download. If you remove the FreeBSD box, by connecting the switch directly to the router, you can access the public network at full speed.

One issue was that the public network used a captive portal, which we had to log into. We didn’t want each client on our network to have to log in separately, so we enabled NAT on the router, and in wireless client mode, all the NATted clients get the MAC address of the router, so the public network thinks that they’re all the same PC and doesn’t ask them to log in again.

Why We Did it

We think that members of universities and research institutions need to be able to join and participate in the global research community as equals, in order to play their part in assisting development in their home countries.

Programmes such as PERii, HINARI and AGORA negotiate free or discounted online access to these journals for universities in developing countries. But the users still need to get online and access the content.

Online publishing for Western markets is usually designed for users with fast Internet connections, which Western universities have. But in other regions, universities often can’t afford fast connections, and this makes it very difficult for them to access these journals online.

Publishers for Development is bringing international publishers together who are interested in finding out how they might contribute to discourse and action around developing country access, encourage publication from developing country researchers and understand the diversity within research cultures/communities and the challenges these present.

training the trainers

Information and Communication Technology (ICT) is a central part of the programme: the trainees email their mentors using Internet-enabled mobile phones and computers. Getting them all up to speed with a few hours training was a great challenge: Aptivate worked with six of the young women who have become the ICT trainers. They deliver all the training, though they were new to computers themselves when the programme started.

The trainers are proud to be associated with the Ubuntu logo, which you see when the computers start up.

thin client networking

For the training we chose a network of sixteen Aleutia thin-client workstations running LTSP, and two Ubuntu servers. We chose net-tops with full-size keyboards and screens because we wanted the two ladies to be able to work together at one workstation in the classroom. The whole network draws only a kilowatt and could easily be run from solar panels.

The tiny thin-client computer is attached to the back of the screen.

virus-protection

A Linux desktop system is less likely to be affected by viruses and other unwanted software than a Windows based system. The school where the training would be held had been disconnected from the Internet by their Internet service provider (ISP) because their Windows-based computers were infected with software that was generating undesirable network traffic. The ISP were happy to connect our Ubuntu network to the Internet while we cleaned the school’s Windows PCs using anti-virus software so they could remain connected after we left.

The command-line projected onto the wall of the training room.

local email

For the email training we installed an open-source web-mail system on one of our servers giving lighting-fast email for our classroom practical sessions.  The trainees enjoyed competing to send emails to the instructor’s inbox which we projected onto the wall. Seeing their messages arrive in real-time was very rewarding.

Projecting onto a blackboard created new learning opportunities: trace the outline of Zambia…

… get everyone to put a sticky note on the map where they come from.