Andrew Latham

A recurring issue in most computer system infrastructure is the System of Record (SOR)[1] which is a source of truth about the desired state or the current state of systems and networks. Many outsiders or senior management are left to believe that the planned state and the current state are the same but that rarely happens. I have written a few SORs and enabled others to be more accurate. Much of the work on modern container image manifests [2] has made great advancements to a more complete language to communicate the details of an endpoint. An issue I would love to resolve is the assumption that a single application is the SOR. The reality is that a data service is the ultimately the SOR and many things might read from or write to it. Today if I was asked to write another SOR I would setup RethinkDB [3] and establish a table named 'help' that pointed to a table named 'standards' and thus became self documenting system.

SORs should also be free to access offline in emergencies and distributed systems like RethinkDB and even Git are perfect for this type of setup. A support person or team can maintain a local copy of the SOR with little to no overhead. Even tools like MediaWiki[4] are great as they can be duplicated or distributed as a side effect of their design. For discovery there are established tools like DNS SRV [5] that are often overlooked. A popular solution for datacentres is NetBox [6] which is a fine step forward from RackTables [7] which served many for years and is still not a horrible solution. In my spare time I hope to integrate a DCIM [8] solution into Odoo [9] to connect the various organizational groups together.

  1. https://en.wikipedia.org/wiki/System_of_record
  2. https://github.com/opencontainers/image-spec/blob/master/manifest.md
  3. https://www.rethinkdb.com/
  4. https://www.mediawiki.org/wiki/MediaWiki
  5. https://en.wikipedia.org/wiki/SRV_record
  6. https://netbox.readthedocs.io/en/latest/
  7. https://www.racktables.org/
  8. https://en.wikipedia.org/wiki/Data_center_infrastructure_management
  9. https://www.odoo.com/
Andrew Latham

My Personal Infrastructure

I have possibly too much physical hardware for one person to use. I like to setup laboratories and prove things out. I can spin up a VM on any given system I have in a matter of minutes. I care about my tools. Lets look at some concepts to creating a commercial and personal lab.

Commercial Laboratory

A commercial laboratory starts with product development and ends with product support in the lifecycle. The business will look at it as overhead when it falls under multiple budgets. Identify the laboratory as a shared resource.

  • Open Access Wiki
  • IPAM
  • Physical Hardware to match Production (trouble shoot hardware issue)
  • Software stack to match production (regression testing only)
  • API endpoints for testing
  • End user devices (tablet, phone, laptop) Apply roles and rights to the resource so that you capture the value. Example if a C-Level manager wants to do a private demo for a customer use the laboratory. Assign roles for network security, application security, network support, application support, customer support, product development, hardware support, production support and any number of roles. Do not call it a playground. Create environments within the laboratory for development, quality, production to enable the development and refinement of the product lifecycle and or the promotion life cycle.

Personal Laboratory

Limited resources are not a limitation in technology. A personal laboratory is not a business critical resource so you can build and destroy freely. You want to develop some simple processes for the build of VMs of various environments and make sure that it is easy. If it is easy for you to test something then you will test things with ease. Using a wiki you can also build up a complex environment without the resources others have by documentation.

  • Open Access Wiki
  • Laptop/Desktop you can afford to keep around
  • Network/NAS/Router that you can afford off of ebay

Test things

With decades of Open Source Software work I know to trust volunteer developed software more than commercial software. This is not tree hugging bias but actual experience. It is important to test things and build that experience for yourself. Proving out the impact of a change on a system in a laboratory vs production will obviously get you a raise some day so give it a go. Learn how to replicate a system package for package, config for config, and document the results of upgrades, changes etc.

Freedom

With a personal laboratory feel free to test any software you read about, hear about, and or asked about. If you can setup random solutions in minutes and do it often then you will become confident in the process.

Andrew Latham

Mediawiki hacking to make it self editable

Good documentation sometimes needs good style. Mediawiki (what powers wikipedia.org) is a great solution. Along with private SSL you can have a secure but fast documentation system anywhere in the world. By default Mediawiki will load CSS enteries from the Mediawiki: namespace. You can add overrides to these files to change the look or even add your own classes.


Common.css for screens http://wiki.domain.tld/index.php/MediaWiki:Common.css for installs without rewrite rules http://wiki.domain.tld/MediaWiki:Common.css

Print.css for printing http://wiki.domain.tld/index.php/MediaWiki:Print.css for installs without rewrite rules http://wiki.domain.tld/MediaWiki:Print.css