[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] RE: Major schools deployments


Below is a documentation summary of our LDAP system written by one of our volunteers, Grant Bowman.  We have a team of really capable server architects who build a kick-ass Ubuntu LDAP network. 

Sean described some issues with LTSP.  I have found that LTSP requires tremendously powerful servers.  It would be interesting to read some documentation of Veronica, Archie, etc, (the LSTP servers that Paul Nelson build) because I am guessing that the reason the Riverdale High School LTSP works really well is that they have built some really powerful servers there. 

We were having trouble running OpenOffice and video on Firefox using the LTSP network that we had built.  LDAP seemed to do better at load balancing , using the resources of the clients to take some pressure off of the server. 

The link to our documentation is here:


I have pasted the contents of that document below.  I hope this is helpful to others who are experiencing issues with performance on their LTSP systems.  I'm not saying our solution is right for everyone, but it does work well for us.


The time spent preparing the lab and keeping it running is significant, though far less than a similar lab using machines that run other operating systems.  The system outlined in this document is designed to minimize the valuable staff time spent on hardware and software issues.  Should a problem occur with a computer, the time required to swap in a spare computer and reload the faulty machine is minimal.  Though the focus of this document is describing all the technical requirements of a computer lab system, working with teachers, students, the local Linux community, school administration and the school district are all extremely important parts of a successful project.  In our case, a single person has been the administrative and organizational contact.  Since he lives near the schools, his consistent physical presence helping in the schools has been the key to all of the progress our sub projects have gained.


Hardware is a necessary but not sufficient component of a project's success.

The server is a 2.8 GHz Pentium D with two gigabytes of RAM, 320 GB of disk and two gigabit Ethernet cards, one for the 192.168.10.x internal network where full services are provided and one connecting to the school's standard network using a DHCP assigned IP address.

Lab computers are all donated Pentium 4 machines with 512 MB of RAM, at least 10 GB of disk space and 100 megabit ethernet cards. Fast Ethernet (10/100 Mbit) switches are used for the lab so that plenty of bandwidth is available within the lab for playing video on many machines simultaneously and so that any switch can be daisy chained from any other via gigabit Ethernet uplinks.

The operating system we chose is Ubuntu's Long Term Support (LTS) version aka. 8.04 Hardy Heron released in April of 2008.  Ubuntu itself is based on the highly successful Debian GNU/Linux distribution.  We plan to migrate the lab to the next Ubuntu LTS version scheduled to be 10.04 in April of 2010.

A budget and/or donations must be secured for the lab to replace broken and damaged hardware such as mice and keyboards.

We are using a Google Docs spreadsheet to track the hardware.  It is publically visible. http://is.gd/1X3Js

Network Routing


Firestarter frontend

The network topology is pretty simple - one network card is the gateway for and provides all the key services necessary.  The other network card can be configured via static or dhcp on whatever school or main network that has connectivity to the Internet.  This configuration will not conflict with any possible existing network services while still providing robust services to Linux clients.

Network Services

All of these services are NOT publicly visible.  They are only visible to our subnet's client machines.

DNS/DHCP (dnsmasq)

  1. IP Addressing, Routing, DNS services (address from name dhclient supplies)
  2. Name resolution, internal and external
  3. PXE image name for network booting

PROXY Services

  1. Squid proxy content caching
  2. Privoxy address filtering
  3. Drew's youtube rewrite squid plugin script

-     Firefox prefs.js on clients

LDAP (openldap)

  1. Authentication services (pamldap)
  2. Secured by ssl
  3. frontend admin by phpldapadmin


  1. Exported /home partition from server containing student /home/<userid> directories


  1. Used by LDAP for secure authentication


  1. Hosts standard repository (see Package Repository below) and custom packages such as msttcorefonts, install_flash_player_10_linux.deb
  2. Hosts pre-seed install files such as hardy-placement.cfg and post-placement.sh
  3. Hosts myldapadmin ldap frontend tool


  1. maintained by apt-mirror, served to clients through through HTTP Apache
  2. used by cron-apt to keep clients updated
  3. used by debian-installer for network installs


  1. PXELinux boot via TFTP (tftpd-hpa)
  2. ISOLinux for creating CD boot images with menus (alternate iso)

Linux Client Package


  1. Installs dependent packages, Depends on standard packages, backports, some custom compiled packages (italc)
  2. Configures client for network services including a line in /etc/fstab for NFS mounting of /home        /home    nfs4             rw,soft,intr 0 0
Configuration files are stored in and symbolic linked to /etc/x-client-config/


This document was created by a team.  Please email comments to: Grant Bowman <grantbow gmail com>


Latest Version

The latest version can be found as a publicly viewable google document: https://docs.google.com/Doc?docid=0Aa7wSBzNDXVYZGZ6Y3hjanJfMmNoYzVjcWNn&hl=en or  http://docs.google.com/View?id=dfzcxcjr_2chc5cqcg

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]