Glossary:

Core Database:

central database – a SQL data base that runs on the central server.  Stores all centralized info about each machine, profile, and user of the system.

Pre-compiled SQL Stored Procedures – a collection of stored queries such as “select * from machines where OS='gentoo', to be used by the interfaces.  This is simply an aid to reduce the duplication of code/queries for each interface.

Interfaces (the hobbits): -- ALL programs that get/store data from the central database need to do so through these interfaces.  This is for data integrity purposes.

C Interface (sam) – An interface to the central database written in C.  Without stored procedures this interface would be a bitch to code.

Python Interface (pippin) –  An interface to the central database written in Python.  This will likely be used by the GLI modules (GLIMD) to gather/store machine and profile information.

Perl Interface (merry) --  An interface to the central database written in Perl.  

PHP Interface (frodo) --  An interface to the central database written in PHP.  This will probably be the most popular

Generic Interface for the Management of Linux Installations (GIMLI) – The grand interface, which acts like a portal and is the main access point/login for all other utilities.  The main role of this interface is to link all the others and handle the user sign-in.   This will run on the central server.  Core applications are required and will come with gimli.

Applications:

Profile Manager – simply handles changes to profiles such as the packages that the profile chooses to install.  These profiles are used for and by most applications.  Having the profile manager here is most useful by the Software Updater.  This will initially be gentoo-only since our profiles store lists of gentoo packages only.

Software Updater – handles the updating of the gentoo machines in the system.  It will have three main functions, to test updates on the staging box of each group, to deploy updates to the rest of the machines in a group of machines, and to rollback updates if necessary.  This can/should be extended in the future.

Scripter – Lets you run a script/command on multiple machines.  Simply gets machine info from a hobbit.  This should always be distro-independent.  This is a core application.

Machine Information Lookup – The quick and easy list of machines and simple queries/searches of machines and information about the machines.  This may link to GLIMD for various things.  This is a core application.

Summary Status Screen – You know, like status stuff.  Pretty pictures of how many machines are of what OS, etc. This is a core application.

User Manager – Deals with the users of gimli.  Users will need defined privileges for series of machines, and all of that.  This is a core application.

Administration Utilities – The main ones thought up so far are the loading and saving of the machines list.  This could be quite the security issue.  Also, the ability to import a machines list from several other systems (such as RH Satellite, m23, and Nagios) would be very important.  User manager may fall under this category, not sure.  This is a core application.

Nagios Integration – just one of the many proposed applications that could be integrated into GIMLI.  Rather than rebuild their entire interface, it would be simplest to just use a hobbit to gather the relevant information about the machines and feed it to a script to send to Nagios.

Gentoo Linux Installation Management Daemon (GLIMD) – This application is concerned only with installing systems.  It will run as its own server (gliserv.py).  Its two main utilities will be GLI through its webgli interface and GLR (R=Replicator), an imaging solution using GLI install profiles.  GLIMD will pass it's information about discovered machines, installed machines, and profiles to the Python Interface to the central server.

Example scenario of usage:
A textbook example of mass deployment of differently-roled machines is a computer lab.  Imagine 3 differnet labs of 30 machines each, 3 printer servers, 2 dns machines, and 4 NFS servers.  
The user would startup the central server and setup their administrator users.
Then they would netboot the client machines.  The machines will be discovered by GLIMD, and they will be added to the machines list.

The user will then create 6 profiles, one for each type of machine: “desktop1”, “desktop2”, “desktop3”, “printer-server”, “dns”, and “nfs”.  They will then have the choice of determining which method to use to deploy their installations.  

For the workstations, they would use the GLR, and first create an image.  This step would be a GLI installation to a chroot using the “desktop” profile and “chroot” role/mode of the installer.  Once the image has been created, it can then be customized with proprietary programs, custom files, etc.  Once ready, machines would then be selected from the list by MAC address and their unique networking information provided.  Then their installations would be deployed using the “stage4” role/mode of the installer.

An alternative would be to do an install of one workstation (the lead/staging box), and then customize that and then use that as the “image” to be deployed.  This has the  benefit of not needing to use the central server as a image store and reduced network bogdown of the central server.