Managing my doftfiles
1 History
From the time I started working as a Unix administrator professionally, I’ve had an interest in dotfiles. My first job was as a Solaris administrator. For the time, they had a nice set up with NIS and NFS mounted home directories. My dotfiles followed me to which ever machine I logged into. This allowed me to have a unified dotfile experience, so I kept building my dotfiles for the years I was there.
In my spare time, I tinkered with FreeBSD at home, but I didn’t go all out customizing those dotfiles. These dotfiles were lost in the early 2000s along with ALL of my other data (photos, music, videos, etc) thanks to IBM Deathstar, sorry, Deskstar hard drives. I had a RAID of four of these drives. All of them died within five days of each other. Let’s not dwell on that.
My next job was managing a fleet of development machines including Solaris, AIX, HPUX, and Linux operating systems. It was a great place to expand my collection of dotfiles. I didn’t have centralize home directories, so I wrote a small script to upload them from my workstation to the server, whenever I logged in. The servers were developer machines, so I didn’t log in much. We also changed operating system versions frequently, so there was no point updating server side dotfiles. CVS (Concurrent Versions System) was the predominant versioning system at the time. I wasn’t keen on maintaining an instance of CVS, so my dotfiles travelled through email and USB key fobs.
The next place I worked was an Ubuntu shop in the middle of migrating to CentOS. Of course, my dotfiles came along and I bashed them up with CentOS and Ubuntu things. A few things specific to the work environment, variables and the like, were also added in.
From that job on, the environments have been primarily Linux, so they had largely been static. A couple of years ago, however, most of my work has been done from Apple Macbooks. So, my dotfiles have had to undergo some changes yet again.
2 Technical
Around the time I started working with CentOS and Ubuntu, my dotfiles found a permanent home in a private cloud Git repository. Of course, I had to sanitize them for any employer specific things on the off chance they ended up in the wild.
While I was working with Puppet professionally, I worked with Ansible in my spare time, to expand my knowledge. I first created system configuration playbooks for my systems in Ansible then Saltstack and back to Ansible. The playbooks deploy my dotfiles using read-only deploy keys for the dotfile repo.
Aside from Ansible setting up the dotfile repo on my workstation or server, Ansible will run stow. Stow is a symlink manager that I use to manage my dotfiles. My Ansible playbook will look at each file in the dotfile repository and check if there is a non-symlink version in my home directory and delete it. This is almost always the OS installed version. Stow then creates symlinks to the dotfiles in the local repo. That’s all.
There are many awesome tools for managing dotfiles. Perhaps better than this. Maybe I’ll investigate other options one day, but they would have to be simpler than this.
3 What's in the dotfiles?
Where to begin? I use Oh My ZSH on top of a ZSH as my primary terminal interface. There is a bit of setting that up. Mostly just the theme.
As I’ve said previously, I use VIM a bunch, so I have customization for that, however I’ve been using VSCode more and more lately.
Of course, my .profile has fun stuff in it. Stuff like setting up lolcat and cowsay if they are available.
It’ll also pipe fortune through those, if available. .profile will also show me brief useful info on the system. For example:
|
|
.profile also does mundane things like looking for, and displaying if found, /etc/motd and $HOME/.plan.
Unsurprisingly, it is my .ssh/config that changes the most. ssh is my sixth most used command, after all.
4 Conclusion
My dotfiles have been with me through the ups and downs of my Unix adventures. They’ve evolved alongside the changing tech scene, from Solaris to Macbooks.
I have thought about putting my dotfiles in a public repository, but I keep deciding against it. Mostly I don’t want to sanitize them but also if I put them in a public place, they aren’t really mine any more.
They’ve become a companion in my technical journey, diligently shaping my environment and growing with me. I look forward to seeing what we evolve into next.