A book that greatly influenced my career path, The Cuckoo’s Egg by Clifford Stoll1 still holds up after all these years.
Cover art for The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage by Clifford Stoll
I first read this book when I was in college majoring in astronomy, (coincidentally same major as the author). Being as-yet blissfully unaware of the field of computer security was not a hinderance to getting locked-in to this true computer caper story.
The author tells the tale of hunting down the cause of a computer network usage billing discrepancy of 75 cents, ($0.75 USD), at Lawrence Berkeley National Laboratory in 1986. Rather than ignore it he starts digging and soon finds this seemingly innocuous discrepancy was due to an unauthorized user exploiting software vulnerabilities to gain higher priviliges, and then leapfrogging into other connected sensitive government systems.
The fascinating thing about this story in my opinion is while the underlying tech has evolved the basic tactics of exploitation remain the same. For example some of the more glaring security lapses uncovered in the story are cases where sensitive computers and networks are being secured with manufacturer default passwords or an easily guessable credential.
This highlights the well-known security adage that no matter how advanced our systems remain as vulnerable as the weakest link - the weakest link more often than not being the human-factor.
I’d like to believe hardening and performing basic security measures has become the norm for sysadmins since 1986, but computer security news has a way of disproving this almost daily. Remember to change the factory password, folks.
One deliciously nerdy detail I had forgotten until re-reading was Stoll’s description of the Morris Number Sequence (look-and-say sequence), which gives a shout-out to the book from its own wiki article2.
As a recovering champion yak shaver I used to obsessively customize the heck out of every single environment, operating system, or program I touched. In my wiser years I have to shake my head at such time-intensive exercises.
In my experience the less customization the better. As a dev you should be able to blow away any program, environment, or operating system at the drop of a hat and be functional in minimal time.
In my opinion it is no use being precious about extensive customizations if it takes one a long time to re-create.
Oh, you have a 15-pane tmux with customized run commands? Cool. Your IDE settings.json stretches from here to Timbuktu? Nice!
I really hope you don’t have to reinstall that program/env/OS or, heaven-forbid, have it suddenly become unavailable on your machine due to org security or compliance reasons.
I now prefer to use default programs and commands to get up and running as soon as possible on a clean reinstall of software.
If you must customize, then save a copy of modified settings if possible on separate media or a remote repo to be able to quickly re-customize. However even this I’ve found to be a pain point.
Don’t get me started on devs that hesitate to drop dev databases and re-create from scratch, when this is exactly the purpose of dev databases. They are ephemeral and built to be blown away with regularity.
If you are not able to drop a dev DB for fear of losing info, consider a rake task or seed file to easily re-create this info.
This brings up a corrolary to this principle which is don’t alias destructive commands. Destructive in this case meaning irreversible.
I am big fan of trash the brew cask that gives the user a command to send files to system trash. However I made a huge mistake when I aliased the system’s rm to trash.
It is way too easy to slip into muscle memory in the wrong circumstances. You could one day be SSH’ed into a remote machine and forget this alias isn’t available and rm -rf <something important>. Oops, I just destroyed <something important> instead of sending it to system purgatory.
My point is yak shaving is fun until we have to reset your environment or OS. Always keep a backup, but better yet get to know and love default programs/commands. Usually the functionality you are seeking is already there, e.g. using default zsh functionality instead of the overkill that is oh-my-zsh framework.
I’ve had switch default zsh to brew zsh more than once so into a blog post it goes. Luckily macOS seems to now keep system packages more up-to-date than in yesteryear.
$ which zsh
/bin/zsh
brew install zsh
$ which zsh
/opt/homebrew/bin/zsh
Update iTerm2 or favorite term program to use /opt/homebrew/bin/zsh.
Add the brew zsh to the list of acceptable shells in /etc/shells if you plan on using ftpd.
# Add to list then run command
chsh -s /opt/homebrew/bin/zsh
Also a cargo cult relic of mine is a .zprofile file, I believe brew used to tell you to do this:
