Home of the Mobile Linux Lab
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
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?
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.
Always try to fail safely. One compromise or error should not cascade
through or be leveragable into larger problems.
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.
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
Some links to other presentations and writings I've done.
- 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
- 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
- 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).