Spencer Christensen Site Reliability Engineer

Spencer's blog

Sundance 2023 - back to in-person

I volunteered for Sundance again this past year. This was the first time we were in-person since the COVID-19 pandemic started. I was at the Rose Wagner theater downtown Salt Lake this time. It's a nice venue and was a good experience.



I saw these films this year:

  • King Coal
  • Drift
  • You Hurt My Feelings
  • Shortcomings
  • It's Only Life After All
  • Squaring the Circle (The Story of Hipgnosis)



Most of them were seen while I was on-shift and working as an usher. None of them were really amazing. I enjoyed Squaring the Circle and thought King Coal was really evenly done. Great acting in Drift and Shortcomings, although I didn't really connect with the story lines.



Blogs, vulnerabilities, and DIY

A while ago I got a notice from Google that my personal website was flagged as a phishing site and had likely been compromised. Weird! I have never seen such an email before and wasn't sure if it was real or not. So I ignored it for a while, like a week or so. But then I decided to checkout my website and see if things are ok or not. I use a hosting company which provides easy to install and manage instances of things like WordPress, which is what I've been using.

I ssh'd into my site and looked around and sure enough I saw some strange files and folders that I didn't put there! What the heck!! So I immediately shut down my website and put up a temporary page explaining my site had been compromised and I took it down.

Read More

Sundance 2020 films

Another Sundance year comes to a close. This year I ended up seeing a lot of documentaries and no narrative films. Not on purpose, I guess. It just turned out that way. Here is a list of the films I saw this year:



  • The Painter and the Thief
  • Boys State
  • The Dissident
  • The Earth is Blue as an Orange
  • Softie
  • Influence
  • Us Kids
  • Spaceship Earth


Of these films I'd say my favorites were Us Kids, Boys State, The Painter and the Thief, and Softie. Well, actually I really enjoyed them all. :-)



Sundance films from that last couple years

It's been a while since I wrote about Sundance and the films I've seen there. I wanted to start writing them down so I don't forget (which I have started to already).

Last year, 2018, I saw these films:
  • Minding the Gap
  • Searching
  • The Devil We Know
  • Inventing Tomorrow
  • Won't You Be My Neighbor
My favorite was probably Searching, followed closely by Won't You Be My Neighbor. Searching is a dramatic thriller starring John Cho, and the movie is mostly told through device screens- laptops, FaceTime, Skype, iphones, Facebook posts, videos, other social media sites, etc. It tells the story of a missing daughter mystery and all the worry and effort of a parent to find her. And as with a good mystery it has a few plot twists and surprises.

Won't You Be My Neighbor is a documentary about Fred Rogers and his show Mr. Rogers. It is a touching, sentimental look at the tv show, but open and honest about the man. I loved it.

At the Sundance festival 2017, I am having a really hard time remembering what films I saw. The only one that stands out is ICARUS, and it is outstanding. It is a documentary about Brian Fogel who wants to be a successful cyclist. He discusses and decides to delve into the world of athletes doping. He tries it himself and documents his experience, but then the film turns to another character the director of the Russian anti-doping agency and follows his amazing story and exposing the doping problem in Russia (and implies throughout the world).

Heroes in a Tech Company

Technology is awesome. It's hard to imagine a world without computers, tv, phones, and the internet. Right? And if you work for a tech company then you get a peek behind the scenes into what helps make and provide all this coolness to the world. In any tech company there are those who are the experts with certain systems, and those experts can often be called on to address problems with it. However when there are major problems, these people have to jump in and save the day- being heroes. And what also often happens is that management looks to these heroes as being awesome, special, and hold them up to the rest of the group to say, "Hey look at what so-and-so did! They are really dedicated and willing to put in all this extra effort to rescue us! Don't you want to be like so-and-so!!??!?!"

I worry about people getting praise for being a hero in a time of need like this. Yes, there are emergencies which need addressing and people to step in and actively solve problems. And yes, recognizing people for their extra effort is important. But it is very dangerous to hold up heroes as the standard expectation for others in the organization. This is dangerous because a culture of heroes and heroism in a group isn't sustainable and will burn out employees. It is also a symptom of a system that is continually in need of being saved, which means that it isn't reliable or sustainable enough. The whole reason that so-and-so had to step in was because your system broke, right?

Instead of expecting everyone to be heroes to keep things running smoothly, it should be the focus of management to make their systems more reliable and sustainable for their employees. Thus, reducing the need for heroes and heroic efforts. How can management do that? By making it a priority and spending effort and money to see that it happens. If you need more servers to handle the traffic, then spend the money! If you need more people on the team to spread out the work load, the hire more people! If your employees have a plan to stop the system failures from happening, then give them time to work on that plan!

How can you remove a culture of heroes and heroism from your company? First address the root cause of a bad system that is in need of saving. Second, but still very important, is don't pressure people to be heros. There is a difference between expecting people to respond to emergencies when needed, and expecting people to "be like so-and-so". It is important to recognize and support those people who do go above and beyond the call of duty, but do it in a quiet way that lets the individual know they are appreciated but doesn't hold them up to the rest of the group as the example that others need to be like. Or if you do recognize them in public, then do not go into all the details of their act of heroism. Saying something like, "aren't they great for working all weekend to get us back up and running! We'd be sunk without them!" sends a message to the other employees that "so-and-so is more special than you and that if you want to be recognized too then you'll need to be a hero like them." There is pressure on other employees in that message which isn't healthy. Don't do it.

It would be great if leadership in tech organizations recognized that making systems run more reliable and more sustainable is more important than making heros.

Running "Back in Time" as root

When running the backup software "Back in Time" on Linux as a normal user is no problem at all. However you will be limited to the directories and files that you can back up that are accessible as that normal user. If you want to back up things only root can access then you'll need to run Back in Time as root. There is a mode to do this, however there is a bug with the scheduling code which sets the cronjob as root to run the backups. This can be corrected by manually editing root's crontab after you've set up Back in Time as you want. Set the cronjob to look something like this:
#Back In Time system entry, this will be edited by the gui:
0 1 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime --backup-job --config /home/schristensen/.config/backintime/config --profile profile1 >/dev/null 2>&1


Update: with recent changes to backintime, the cronjob should look like this now:
#Back In Time system entry, this will be edited by the gui:
0 1 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime --config /home/schristensen/.config/backintime/config --profile-id 1 backup-job >> /root/backintime.log 2>&1

Project Hamster for the win

At my last job, End Point Corp, we tracked our time every day for everything we did. This served many purposes and was required for all employees including executives. The biggest reason is that the company is a consulting company and we need accurate time tracking in order to bill our clients correctly for time spent for them. And with many clients that everyone is working for, it is important to log 15 minutes here, 30 minutes there, and include in the log the who/what/why/problems/etc. as well.

Another reason we did this was so managers knew exactly what each team member was working on each day and would review every team members log daily. This also meant that we didn't need to have meetings just to catch up on what people are doing and to give status updates, since those are all in the daily logs.

Another benefit to time tracking is for each person to see what they are *actually* spending their time on versus what they *planned on*. This is important to realize and can help to more accurately estimate future projects and to investigate problems. It can also help motivate people to keep on task or to manage distractions better (stop checking email so often!). It can help users with their own time management. And for system administrators who are constantly interrupt driven, this can be a big issue.

At End Point we used an in-house built web app for tracking/reviewing/reporting all of our time. And not that I'm with a different company I no longer have access to that app and so have looked for some alternative. The best one by far that I have found for Linux users is Project Hamster.

Project Hamster is a personal time tracker and unfortunately not a shared one for teams. However, it is great at what it does. It is written to work with GNOME and is written in python and uses a SQLite db as its storage for all your time tracking data.

What makes it so great is that it can be so simple and easy to use that it is not a burden at all to enter/edit your time tracking entries. I highly recommend that you set a custom keyboard short-cut to launch the app. In Ubuntu, go to System Settings -> Keyboard -> Shortcuts -> Custom Shortcuts. Then Add a new shortcut and enter Name: "Hamster Time Tracker" and Command: "/usr/bin/hamster-time-tracker" and then Apply. Then click on the word Disabled for the new shortcut and press your new keyboard shortcut. For me I use Super+H.

Bingo. Now any time you want to enter or update your time hit Super+H, begin typing, save your entry and the hit ESC to close the window and return to what you are doing. Read the Help Context docs for how to efficiently enter tasks! You can do the entire process without your hands leaving the keyboard (no mouse needed), and you can be in and out in seconds. Awesome.

And I haven't even talked about the reports that you can review and customize. So cool. Check it out.

Now if only they could support running it on Macs! That would be a big win for other members of my team.

 

Using sshpass to ssh to a host with a password automatically

Most times you want to automate an ssh connection to a host you would think of using ssh public/private keys. And well you should; they are the best way to access a host without using passwords. However there are sometimes when you are not able to use keys, such as logging into a switch, router, blade chassis, or other device that doesn't support the use of keys. What are you to do to automate ssh connections to them?

Some may look to using expect, and that is fine. But expect can be complicated to learn and get right. There is a simpler solution: sshpass.

You may need to install the sshpass package for your Linux distro (yum install sshpass, apt-get install sshpass).

Then you can run:
sshpass -p$PASS ssh $user@$host $command
OR
sshpass -e ssh $user@$host $command
In the first example you provide the password in the $PASS variable in the command line. This may or maynot be a problem depending on how you are entering the command.

In the second example you first need to export SSHPASS="$PASS" and then the -e option uses this env variable for the password.

Code Freeze is dumb and here's why

If you work for a company that does web development and periodically they put a hold on all changes from being released, known as a "code freeze", then you are not alone. Several companies choose to do this especially around the holiday season (4th quarter, October - December). However, this is actually a poor choice and shows a lack of solving much deeper problems.

The main reasons for having a code freeze is to mitigate risk- to prevent a change from being released that takes the site down. And down time during the busy season is really bad! Right?!?!? So it is worth it to stop all changes (or severely limit them) during this time period. Right??!? It doesn't really matter that engineers will just have to find something to keep them busy until January (because their velocity of deploying changes will drop to zero).

There is more going on here that people are not discussing. The fact that they don't want to release during the busy season because they fear downtime means that they fear releasing. True? It means that releasing changes is too risky and they don't want to take the risk. Now we come to the heart of the matter- Why is releasing during the busy season too risky?

Fear (and risk) of releasing changes comes down to these main issues:
  1. Not enough planning (including deployment and rollback plans)
  2. Not enough testing, or not enough confidence in testing
  3. The release process itself is not stable or efficient enough
These are the problems that really need to be attacked instead of wasting time with a code freeze. If you properly plan releases you can mitigate risk. If changes are thoroughly tested then you will have confidence in the release and know what to expect. If your release process itself is reliable and easy then you should be able to release often without it being a burden or risky.

So here is the challenge- take this next code freeze time to focus on these problems. Make it a goal to make your releases as risk free as possible. Set a goal to release multiple times a day on your busiest day of the year. What do you need to do, what changes need to be made in order for you to do that? Now that is the direction you should be headed!

Code freeze is a symptom of being lazy and cowardly. Thinking it is not important enough to fix those three problems above is just ignoring the fact that your release process is holding your business hostage and will always hold you back until you wake up and fix it.

 

New approach to long-running personal project

Some time ago I may have mentioned a personal project about being able to view and request movies from your local library with a nice modern web app, not like the clunky web sites that libraries normally offer. It would also provide a way to queue up requests, with a "Watch List", similar to Netflix or Amazon Prime Streaming or others.

However, as a personal project I have hardly any time to give to it. And so little actual progress has been made. Until recently!

I took a vacation recently with my family and took the opportunity to do a little R&D and have adopted a few new tools to help me with this project which is in-progress now.

The tools I am using now include: Fun!