This is an early workflow - it needs completely revised.

Item is ordered

New orders file created with rfe orders/{orderno} Existing format preserved, example below :-

1.item:HP 8300CMT i5 3.2GHz, 8GB, 500GB
2.item:Dell Ultrasharp 20" 2001FP
2.warranty:3 years

Explain format - lineitem/orderline.

Note description will be as entered by purchaser. Won't necessarily include manufacturer, and model maybe be inconsistent. Usually includes disk size and memory size, but not in any standard format.

Sync'd either synchronously after edit or as part of a periodic sweep through all orders looking for updated files. Uses purchaseorder->last_loaded field to determine whether a sync is required.

An entry in 'purchaseorder' table is created, recording PO, supplier, order date, and VAT. (Note VAT value applies to all items in purchase order. Could change so that VAT value could be an attribute of line item rather than of the order, but that would require changing all our existing order files (possible). )

For each individual item (all SNOs for all lineitems), a row in the 'item' table is created, recording description, warranty, price, serial-no, delivery date, budget, requestor and category. Note that a row will be created even if SNO is blank. NOTE: shouldn't bother creating item entry where no delivery date given - we currently do

Item is delivered

The serial number and delivery date is manually added to the orders file using rfe orders/{orderno}, eg :-


A resync (either sync or async as before) (because mtime on orders file has changed) will occur. All item rows associated with this order will be deleted. New item rows will be created, as above, but this time also recording delivery date and serial numbers.

Now that the delivery date and SNOs are specified, a row in the system table is created for any item with category desktop | server | ? | ? | ?. Owner = informatics, allocated = nobody, type = undef (though perhaps that should default to self-managed-dynamic-dhcp?).

Mac address learning

As part of the Select PC agreement, the suppliers produce a periodic spreadsheet (period = ?) that lists all PCs ordered by the University under the agreement - providing serial number, cost, purchase order and, crucially, mac address.

This spreadsheet, and historic spreadsheets, for each Select PC supplier are merged into one CSV file which is periodically loaded into the 'supplierreport' table. On reload of the 'supplierreport' table, a script will create any necessary rows in the 'macaddr' table for PCs that we have order details for.

It should be possible to produce a tool that populates the x.sno lines in an order file from the supplierreport table - this would save manual re-typing of serial numbers.

This now gives us a means of tracking self-managed desktops (which we couldn't previously do easily as we didn't harvest mac addresses on delivery).

This also gives us the option to master mac-addresses in the inventory, rather than in LCFG profiles as is currently done.

Kit ordered outwith the Select PC scheme will still require their mac addresses to be manually set (using 'ii' tool)

Location Discovery

Periodically (period=?), the MAChistory files are downloaded from the site netmon servers. These are combined and processed to give a macaddr:location:last_seen triple. These triples are then used to update the system->space and system->last_seen columns for the system row associated with each macaddr.

A system's location can be set using 'ii set --serial CZ8993H7Y --location IF-5.14'. The system->last_seen column will be set to the current time and the flag manual_location set to true.

What should happen when a system has manual_location=true, but the MAChistory report indicates a newer location (than last_seen)? Should it just override the location and set manual_location = false, or flag a warning?


For a system, when any of system->{location,allocated,allocated_type,type,hostname} are changed, a row is created in the history table with the date, the type of change and the new value. System "creation", "disposal" are also recorded in the history table.


Comments can be associated with a system by creating a row with history->changetype = 'comment' and history->newvalue storing the comment string.

Allocate machine - self managed dynamic dhcp

Eg. ii set --serial CZC2457YM0 --allocated ascobie

system->type = selfdynamic
system->allocated_type = user | server | podium | lab | junk | other 
system->allocated = {user} if allocated_type = user
system->modified = true

Allocate machine - self managed static dhcp

Eg. ii set --serial CZC2457YM0 --allocated ascobie --newname --type selfstatic

system->type = selfstatic
system->allocated_type = user | server | podium | lab | junk | other 
system->allocated = {user} if allocated_type = user
system->modified = true
system->hostname = {hostname}

(How DHCP entry created? Would prefer not to require LCFG profile)

Allocate machine - DICE install (already have mac addr from supplier report)

Eg. ii set --serial CZC2457YM0 --allocated ascobie --newname --type lcfg

system->type = lcfg
system->allocated_type = user | server | podium | lab | junk | other 
system->allocated = {user} if allocated_type = user
system->modified = true
system->hostname = {hostname}

Create an lcfg stub with relevant sysinfo fields.

(DICE install could refuse to install if the actual serial number doesn't match that in the inventory)

Allocate machine - DICE install (have no mac addr)

* As above but use 'ii addmacaddr --serial CZC2457YM0 xx:xx:xx:xx:xx:xx' to add a macaddress

DICE -> self managed (static)

Eg ii set --serial CZC245YM0 --type selfstatic

system->type = selfstatic
system->modified = true
system->os = undef

(How DHCP entry created? Would prefer not to require LCFG profile)

Remove lcfg stub if exists (need to do whenever type is set to anything from lcfg) Remove any clientreport for this machine (need to do whenever type set to anything from lcfg)

Manually delete LCFG profile

DICE -> self managed (dynamic)

Eg ii set --serial CZC245YM0 --type selfdynamic

same as DICE -> self managed (static), but also

system->type = selfstatic
system->hostname = undef

(DHCP entry should magically disappear)

Manually delete LCFG profile

DICE -> unallocated/spare (not that this is a type)

Eg ii set --serial CZC245Y0 --allocated_type = unallocated

system->allocated_type = unallocated
system->allocated = undef

DICE -> disposal


Delete LCFG profile

self managed (static) -> self managed (dynamic)

ii set --serial CZC245YM0 --type selfdynamic

system->type = selfdynamic
system->hostname = undef

- remove DNS entry

(DHCP entry should magically disappear)

self managed (static) -> DICE

ii set --serial CZC245YM0 --type lcfg

system->type = lcfg
(DHCP entry should magically change)

- create LCFG profile

self managed (static) -> spare

ii set --serial CSCZ234KY --allocated_type = unallocated

system->allocated_type = unallocated
system->allocated = undef

self managed (static) -> disposal


self managed (dynamic) -> self managed (static)

ii set --serial CSC234K93 --type=selfstatic --newname

system->type = selfstatic
system->hostname =
- create dns entry

self managed (dynamic) -> DICE

ii set --serial CSC234345J8 --type=lcfg --newname

system->type = selfdynamic
system->hostname =

- create dns entry - create LCFG profile

self managed (dynamic) -> spare

ii set --allocated_type = unallocated

system->allocated_type = unallocated
system->allocated = undef

self managed (dynamic) -> disposal


Rename machine (DICE or self-managed-static)

ii set --serial CKC348HUYZ --newname

system->hostname =  (Reject if type = self-managed-dynamic)

Rename LCFG profile

An incorrect serial number has been entered as part of an order

The serial number is simply corrected in the orders file. This file will be sync'd (sync or async) because the order file's mtime will be updated and > purchaseorder->last_loaded.

The system ids for any system rows associated with items purchased on this order are stored in a hash, indexed by the associated serial no. All item rows associated with this order are deleted and re-created afresh. A system row will be created for any new serial number which is for an item with category = desktop | laptop | .... Any system row stored in the hash for which its serial no is no longer associated with this order (most likely because the serial number was incorrectly entered) will be marked as an orphan. (Slight optimisation: if the system->modified flag is 'false' for any row, the row is just deleted rather than orphaned as it hols no data). The orphaned system row entry won't have any record of the old serial number, so this should be recorded in an associated history record (type=comment?)

Kit has been returned as faulty on arrival

One possibility would be to use the disposal fields in the relevant item (should be system) row. Another possibility would be to remove the serial number from the relevant field in the orders file which would orphan the associated system row. The comment (?) field could be used to record the serial number for reference purposes.

Kit is disposed of

An item being tracked in the system table - mark as disposed (how?). Add an entry to the 'disposal' table - keyed on po:serial-no.

An item not being tracked in system table (eg monitor) - ????

Combination systems

Systems can be made up over several items (eg storage array, network router), so the

Periodic maintenance

  • remove orders files, purchaseorder rows, item rows, for stuff that is ordered but not delivered within, say, 6 months.
  • process orphaned system rows
  • report providing list of systems (perhaps just desktop | server ?) with no mac address entry
  • report on any LCFG profiles that don't have system->type = lcfg


  • barcode field needs removed from the orders files - it's not usable as can't associate with a particular SNO


  • How deal with insurance reports ? particularly wrt building up value of a complete server rack
  • Might wish for better link between system and clientreport tables?
  • Clientreport should report multiple mac addresses and multiple monitors. How would that be represented in report table?
  • should have a value in space table for each site that says "somewhere at this site"
  • How record disposal - can't record in item table as rows are reloaded at order file editing. If record in system table, can only record disposal of systems - that might be sufficient?
  • How record "purpose"? Purposes table? Multiple purpose per system?
  • Produce a script to autopopulate sno records of orders files from the SelectPC supplier report
  • Add a "should_be_here" location field for manual setting - means can report on "this kit should be here, but is actually here instead". Useful for public access machines?
  • Should macaddr table support IPV6 client identifiers?

-- AlastairScobie - 05 Aug 2013

Topic revision: r4 - 09 Apr 2015 - 11:14:56 - ChrisCooke
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies