A few people asked for information about where we are currently with the computer lab, network etc. Basically the technical aspects of the project. Here you are:
When we first got our shipments from the port, we went over the inventory, and were quite pleased. Many Dell Optiplex GX110s, some newer lower quality off brand Pentium III systems, one Pentium 4 tower, and some fairly useless Pentium Pro/Pentium towers.
When we got to Kumasi, we found that the Dell systems had been imaged by the organization that donated them to have Windows 98, OpenOffice, and some other software installed, which was nice since they just worked out of the box. Others had no hard drive, wiped hard drives, or old personal installs (complete with personal information).
At first we copied the Win98 image from machine to machine, and I was trying to install Edubuntu on others. This was just to get the machines working so class could resume. The sad truth about Edubuntu (a desktop Linux-based OS, focused on schools) is that it is basically unusable on machines with less than 512 mb of ram. This is very disappointing.
Sorry if this upsets people, but a School-focused linux distribution should not require top of the line equipment. Boston Public Schools are barely better off with regards to processing power, so I find the Edubuntu desktop, basically, a failure for developing nations.
Harsh words, but frankly Gnome 2 is slow, there are no decent network/user management tools unless you are deploying the LTSP (which is awesome, however), and yes I am going to say it... it should LOOK like windows. Sorry, I don't care for idealistic GUI politics, I run Mac OS X, OpenBSD, and Windows2k/XP as desktops (when required), and don't care if it is windows or not (give my a CLI, a text editor, and firefox), but PARENTS/EDUCATORS DO. Basically, unless you are deploying terminals, or using very fast hardware, Edubuntu should be avoided. Though I do like Xubuntu, a lightweight non-education focused distro by the same people.
I've come to the realization that I will have to heavily customize an LTSP-based linux distro (or make my own) to run on this hardware and our network infrastructure. Which is not good when we are running decent hardware, probably some of the best in Ghana, and a fast network. I still plan on doing it, though. And I will actually spend a LOT of time building it, but It just isn't going to happen for another 6 months.
Due to virus/network/security related (read: student) issues, we had to jump away from windows 98 as soon as possible. I found the nLiteOS project again and started working (read: chucking about a dozen burned CDs on the floor) on a new custom windows XP build. I got one working after about 2 days of testing (and numerous power outages) cd images and installs.
The first build was designed to work on our Ubuntu/Samba-based Primary Domain Controller server. I quickly took the server down after the near-constant power outages were making me worry about losing our 300GB hard drive. The second build included SP 2, and some further network/workgroup customizations.
The outages have been every few days, but the days they happen, it is either on/off every 20 minutes, or off for several hours. This coupled with Africa Online's (AOL) service, has made my job exceedingly difficult.
Due to network/equipment/power issues, I decided to hold off on deploying parts of the network that will make it easy to manage and started my focuses on routers/dhcp server/dns/etc issues. I really want to roll out the Domain-based/group policy/terminals/RandomAdvancedNetworkIdea setup seamlessly and quietly as possible. I will probably deploy the enterprise-level aspects of windows domain networking within the next 6 months.
There were however certain more advanced aspects of the network that deploying immediately have already shown improvements in the network. Though I still think I am a month behind schedule due to power/internet issues (sadly I did not plan for outages from both so frequently).
When I first got here, replacing the old router with my airport extreme base station made significant improvements in network performance, latency, lookup times, etc. Switching to OpenBSD as a router/DHCP Server/Firewall/Simple Web&FTP server had added some minor speed gains under heavier load (on a 900mhz p3 with 256mb of ram). I hope to separate these servers for security/bandwidth shaping reasons using Xen.
It was a little tricky to initially configure, the syntax changed on a few things from the older versions (some FAQs/Guides are almost worthless now), also I had to locally mirror most of the packages before I could really attempt configuring it fully. But after I got it working as a simple NAT/Firewall/DHCP Server life became easier for everything. Also this let me bring my Wireless Base Station into my room, which is always nice.
OpenBSD 4.0 is what most people actually want when they look at Linux distros for network server setups. They have an amazing security record, modifying many opensource packages to be more secure (chrooted environments, etc) and really make package management a breeze. you set the pkg_path (location of applications/packages, ftp, local, http, network-based) and then use pkg_add packagename or pkg_delete. Very elegant, especially compared to the dependency hell that is Linux-bsed distributions.
Anyway, one cool thing we did with the OpenBSD server was that we added a DNS caching server. What a DNS server does is when your computer requests http://www.google.com it asks your dns server (in our case an OpenBSD 4.0 box) to do a "lookup" in global DNS servers for the ip address, and then connects you to the ip address through your gateway (home routers/cable modems/wifi base stations, etc).
What a caching DNS server does is it installs a BIND server (DNS server), and when BIND looks up a domain name (www.domain.tld) it saves the ip address to the server, so it doesn't have to do a lookup again (which on our connection takes a second or three). This saves a significant amount of time on networks with high latency about 2 seconds per new domain, which can be x.domain.tld, xxxxxxxx.tld, or xxx.x.xxx.x.tld. It is much akin to using a phone book, as it looks up the name, and returns the phone number.
This is not something most people with low latency/fast connections would need, but with our 1-3 second each way latency (worst during the day), it saves a lot of time. And in the future with Satellite this will get worse. We will actually have speed of light delays.
My plans for December/Early January:
Setup a transparent Squid Proxy Cache. What this will do is it will locally cache websites we go to on a server, and only download new information if the website has changed. Which on slow/high latency connections can be a tremendous time saver.
Also, I want to setup ntop to gather network utilization statistics to help with fundraising/grant writing.
Then I will take a look at the WPKG and Unattended projects for creating a simple to maintain/administrate windows network.
Start working on designing new install builds in a virtual environment alla VMWare, and doing significant testing/configuration before installing onto a "production machine." Oh no, there it was, my first use of a very specific network deployment term.
And finally I wish to start working with Xen to consolidate low cpu utilization servers into a virtualized environment that will allow multiple operating systems to run at once on a server.
Right now we are basically testing various ways of doing things. We started with trying to do imaging, which I actually found to be not as good as unattended clean installs. We continued on with trying a domain controller from the start, but changed to a workgroup environment until we have a more stable electrical infrastructure. I tried using Edubuntu as a desktop for some of the machines, but due to the piggishness of gnome2 with regards to memory/cpu utilization, I will be holding off on Linux desktops until I have time to develop a customized (read: fast and responsive) LTSP-based linux distro.
All in all, I am learning a lot about setting up enterprise level networks, figuring out what works and what doesn't, and trying to integrate as much free software was we can.