I've thought about this type of school server farm setup a bit. You would have a master template that defined the services, and a pool of resources consisting of one or more servers. The template would define the how the services were distributed among the resources, with a reasonably sane default for the initial install. Adding more resources after the initial installation and template choices would be as quick as PXE booting an additional "server", and a few automated DNS changes triggered by the template would migrate services to the newly provided resource(s). This type of architecture should be very simple to migrate to a cloud based architecture later on if hosting prices continue to fall.
Couple it with a shared file system such as Redhat GFS and some utilities such as heartbeat or DRBD, and high availability becomes a relatively simple addition. A minimal implementation could run on one box, and expand from there. I would really like to see the ability to eliminate any dependencies on the initially installed hardware by making it simple to migrate nodes to new hardware as well. For example, do a pilot installation on an old desktop, add a good server later, and simply checkmark "Migrate an existing server node to new hardware" somewhere on a web form, and follow the prompts.
Once you had at least two nodes up, at the bare minimum each node should be able to replicate all the other services of the other node in case of a node failure, perhaps by a manual setting change in the web template interface on the surviving node. This is sort of a "borg" mentality, but it should scale to dozens of servers with ease, and provide a reasonably simple, albeit manually triggered, safeguard against server failure. To recap, each server would be pretty much identically configured, but most services would be disabled unless the node was the designated primary for a particular service.
I would try to NOT integrate most of the various service management GUIs into the project with the exception of perhaps a few key services needed, such as PXE, LDAP and DNS.
Is there a project out there that already implements this type of "master template" architecture?
Skole Linux is the only one I am aware of that tries to address the implementation from scratch of a complete educational institution relevant server network. I have not evaluated Skole Linux for a while, but it might be a good resource to consider.
Come up with a snazzy name for the project, like "The Borg Initiative" that would get people's attention, spend some effort on marketing our intentions so we can recruit interested talent, and focus on building a simple, modular framework that makes it as easy as possible to add new services and maintain and upgrade the infrastructure.
I think we'd have a winner.
Anybody want to host a project outline wiki page?
Senior Network Engineer
Northwest Regional Education Service District
sharbour nwresd k12 or us
Date: Wed, 10 Nov 2010 18:34:55 -0500
From: "Steven Santos" <Steven SimplyCircus com>
To: "'Support list for open source software in schools.'"
<k12osn redhat com>
Subject: Re: [K12OSN] Life after LTSP
><!&!AAAAAAAAAAAYAAAAAAAAAKzbmNxEOCVDh/33yLUBdkDCgAAAEAAAAPvPOaNVTnZOqaqa0UxIRgYB>AAAAAA== SimplyCircus com>
Content-Type: text/plain; charset="us-ascii"
K12LTSP was a success because it did everything we needed it to do, and it
did it with little fuss.
What if the future is not in a given tech, but in the concept or what Eric
did way back when?
Why couldn't we come up with a system where you use one DVD to setup and
install a complete working linux network for a school. This should allow
for all network services commonly needed in a school setting, including:
- Student administration
- Admin / Teacher desktops (DRBL)
- SIS including classes, grade, etc
- Classroom Services
- Student desktops (DRBL)
- Moodle virtual classroom
- School Wide Wiki
- Lab services
- Writing lab (LTSP)
- Science lab (DRBL)
- Library Services
- KOHA / OPEC
- Library desktops (DRBL)
- Common network services
- School-wide print services
- Restricted Internet access, filtering and local caching
- Lunchroom / School Store
- POS terminals
Step 1: setup the servers
- DNS / DHCP servers
- 389 Directory Server
- Set up the network admin group (auto)
- Set up the office/admin group (auto)
- Set up the teacher group (auto)
- Set up the Lunchroom group (auto)
- Set up the schoolstore group (auto)
- Set up the student groups (auto, by class, graduating year)
- Set up software access groups (interactive)
- NIS / Kerbos (using 389DS)
- Generate certificates
- Copy certificates to USB drive or NFS share for later use
- SAMBA4 (setup using LDAP/NIS authentication)
- Set up domain for use with windows clients
- MySQL server (setup using LDAP/NIS authentication)
- CUPS print server (setup using LDAP/NIS authentication)
- File Server (/home server)
- DRBL Server (setup using LDAP/NIS authentication)
- SQUID web proxy (restrict net access / setup with LDAP)
- Setup the virtual servers
- Remote Access Server (remote. / ptpp server setup using
- Mail server (mail. / setup using LDAP)
- Apache server (www. and web. / setup using LDAP)
- Koha server (library. / setup using LDAP)
- School Tool (sis. / setup using LDAP)
- Moodle (moodle. / setup using LDAP)
Step 2: setup the DRBL (Diskless Remote Boot in Linux) boot images
- Staff desktops with NIS/LDAP authentication.
- Standard education image with NIS/LDAP authentication
- Library PC image / standard image with addition of a local, no pwd
acct, but with restrictions on what apps it can launch without being logged
in as a standard user
- Kiosks image / web browser only, no local log-in option, fixed start
- Point of Sale terminals
Director, Simply Circus, Inc.
Email: Steven SimplyCircus com
Gym: 86 Los Angeles Street
Newton, MA 02458
Mail: 14 Pierrepont Road
Newton, MA 02462
K12OSN mailing list
K12OSN redhat com
For more info see <http://www.k12os.org>