hwscan3 IMS: TCC processor inventory report |  |
hwscan3 IMS: TCC processor inventory report | |
This document describes the implementation of the system described in hwscan3 3.0: TCC processor inventory report. It includes the entire source code in lightweight literate programming style.
This script is run as a cron job once a day. It generates two kinds of pages:
The start page contains a table of servers, a bullet list of open labs, and a table of classrooms.
For each classroom and open lab, it generates a room page with a table showing the hardware configuration of each client in that room as a table.
In general, the execution proceeds in two phases:
Extract all the input information from three sources:
LDAP, the XML-RPC GetHardware interface,
and the scanreport.xml file.
TCC's ldap0 server will provide us
with a complete list of all the hosts (servers and
clients). For particulars, see LDAP attribute
cross-reference.
Note that servers such as login are
considered clients by LDAP.
The XML-RPC interface GetHardware is
the primary source for hardware configuration data.
See the TCC internal Wiki under Software/HomeGrown/Forge/ForgeWeb/GetHardware.
Any client in LDAP that is an office machine (tccOfficeMachine is true), or is not known
to GetHardware, such as a Macintosh,
will not appear in the report.
The scanreport.xml file characterizes rooms, and
explicitly lists the rooms, services, and
peripheral devices of interest.
Generate the start page. While generating the start page content for each open lab and classroom, generate the room page for that room.
Before considering what classes we need, let's look at the order in which we need to access the data.
In the server table on the start page, we want to present the servers in alphabetical order by server name.
In the open lab bullet list and also in the classroom table, the order of presentation is alphabetical by room name.
In a room page, the table row for each client lists
the peripheral devices in the same order as the
entries in the scanreport.xml file's deviceList element.
These needs suggest that there be two top-level class instances to represent all the input sources:
An single instance of a class named ClientSet will hold all the information
derived from LDAP and GetHardware. See
Section 25, “class ClientSet: Container for client
configurations”.
This instance will be a container for instances of a
class named ClientConfig, each of which
describes one client (including servers).
A single instance of class ReportInfo
represents the scanreport.xml file. It can generate a
list of rooms in alphabetical order. It can generate a
list of servers in alphabetical order. It can also
generate a list of device types in the same order in
which they appear in the scanreport.xml file. See Section 27, “class ReportInfo: Reading
report information”.
Hence, the two main phases of execution become:
Instantiate the ClientSet object. Its
constructor will query LDAP and GetHardware.
Generate the start page using this instance, generating room pages as their links are placed onto the start page.