Guiding principles

As I go through this process, there are several principles that I will use to guide my actions. They are all what I consider "best practice" for any environment, but particularly for "enterprise" ones. As with most principles, it is much easier to pick some strict ones to start with then loosen them up IF some exceptions are needed. It is EXTREMELY difficult to tighten things up "later when we are...".

• Source code control
  Everything that is a text file, goes into a source code control system. Probably some binaries are going in too, either for convenience or for tracking purposes. Whereever possible, the Date, Revision and URL of the file will be included. [Particularly given my work environment for this project (the metro bus) and the time frames, it is vital to record what I am doing, as I do it. It is NEVER easy to pick up where you left off 3 days ago.]
• Comments and documentation
  Text files should be commented, preferably with the 'why' not just the 'what'. It is very easy to misunderstand why something was done, particularly if you are not the one who made the decision.
• Least privilege
  Anything that can be done as non-root, should be. It is just sanitary
• Security in general
  Anything that I do, could eventually end up in the production space. Lab projects ALWAYS leak. It means you are doing something right. Just because I think I am in a "safe" environment does not mean I can let my guard down. "Shields up!"
• SELinux in particular
  SELinux is left in Enforcing mode, ALWAYS! If it blocks something, it is because I've broken guidelines set down by those much more experienced in security than I am. I need to identify how, or why I've stepped on the landmine and fix MY process and procedure, not "get around" it for convenience. If I can't do it right in a lab, why would I think I can do it right in production?
• Scripting
  If I am repeatedly doing something, it needs to be scripted or added as an alias. If I add it as an alias or script, it needs to be versioned, commented and managed.
• Failing
  Always try to fail safely. One compromise or error should not cascade through or be leveragable into larger problems.
• Simplicity
  KISS and Occam's Razor are good guidelines. Small, modular pieces with clearly defined interactions are always easier to understand and debug than monolilths. Of course this fits with the bus ride time frame. I need 'projects' which I can go from start to a stable stopping point in about 30 minutes. This forces me to break things up.
• Brevity
  This one doesn't fit with the "enterprise" nature, but it does with my work schedule. If I can't understand it in 15 minutes, find something simpler. If I can't find simpler, figure out how to break it into smaller steps. At my age and place in life, I've come to accept that it is unlikely that I will have more than that much uninterrupted time on a regular basis.

Other writings

• Discussion about social networking. Prepared for a COLUG meeting. Lead to a lively discussion about privacy, security, etc. Note that this was given before Twitter and Facebook became huge (Jim pat's himself on the back)
• Voodoo Engineering. A discussion about how technology decisions are made. I wrote this in the early 2000's for a large company I was working for. Sadly, it is still 100% true almost a decade later (for that company and for our industry)
• Flashing a Linksys router Another COLUG presentation. Did this one at a library branch and almost took out their wireless network (oops)
• ISCSI for the hobbyist Ohio Linux Fest 2008 presentation. Probably my largest audience ever, in excess of 200 people. Notable for me dropping my USB drive towards the end and crashing the demo portion of the presentation (nother oops)
• Server provisioning and management paper Wrote this based on my experience trying to help, then battling the rollout of a 1 size fits all provisioning and management system. I tried to be dispassionate and now, years removed from the battle, I think it holds up well (they ignored me).

---

Contact mll@rossberry.com

Copyright © 2010, 2011 Jim Wildman. All rights reserved.