Why YAML, Why?

 Last night I finally joined the ranks of those who despise YAML. I've always known (and known of) admins who loathe YAML. They rail against it every time they have to use it, or any time it is even mentioned. Primarily, they complain about it being white space sensitive.

  In the past, I considered this an extreme reaction. An overreaction to a minor annoyance. I'd not encountered any problems in using YAML so far, even when making the same edits they complained bitterly about. I considered the indentation fairly logical, and figured that if you treated YAML a bit like a wild animal, by giving it some respect and moving slowly, that it wasn't very likely to bite you and everything would be fine. For a long time, it was. Until it wasn't.

  I should preface that my bad experience with YAML did occur at almost 2am, so I wasn't functioning at peak capacity by any means. I was trying to implement Authelia for my self-hosted sites and it uses YAML for its config and its on disk user database both. I finished configuring it and launched it for the first time, then tried visiting my site, and got a 500 error. 

  Several rounds of troubleshooting later I found that the container was failing due to errors reading the config file. I found the line number where it began complaining about not finding expected keys and took a look, but couldn't see anything wrong. After many attempts, I ended up going back to the sample config file I had copied as the base for my file, and copied several lines to either side of the offending line. I then removed these same visually identical lines from my config, and pasted those from the sample config back in. Visually, nothing had changed, but the logs no longer complained about errors in the configuration.

  Instead, they complained that the display name of my one user couldn't be an empty value. It wasn't empty. I tried several variations, before finally tracking down a sample file, commenting out my entry, pasting in the sample, and then modifying it with my user's details. And it worked. Annoyingly.

  My best guess is that there was whitespace, either tabs vs spaces, at the ends of the lines, or on seemingly blank lines that was the source of the problem. Visually, there were no differences between the working and the non-working code. Indentation was the same. And of course, the error messages are very unhelpful. The problem wasn't that the value was empty, but that something else was causing the parsing to be incorrect.

  So, freshly burned by this experience, I have reluctantly converted to the side of those who consider YAML a terrible format for configuration files. There are much more forgiving options out there that don't require dark magic or blind copy pasting to get working when nothing is visually wrong with the data. 

  You won't convince me that whitespace is a problem in Python though. Not yet at least.

Changing terminal font in Visual Studio Code on Linux to get symbols working

 I've been using VS Code lately, since Atom is being killed off. I also switch to using ZSH with OhMyZsh a while back. I had noticed that while using the integrated terminal in VS Code, all of my nice status icons were showing as empty boxes, indicating that the font didn't have symbol support compiled in.

  I found this post for fixing the problem on OSX, and was able to adapt it to my needs. 

• Press Ctrl + Shift + P and choose Preferences: Open User Settings (JSON)
• Add these lines (in my case) to your config:

"terminal.integrated.defaultProfile.linux": "zsh",

"terminal.integrated.fontFamily": "SauceCodePro Nerd Font"

SauceCodePro is my preferred font currently, being the Nerd Fonts version of Adobe's Source Code Pro font.

Once you save the settings.json file, the terminal (if visible) should immediately update and your symbols should be visible. This of course assumes that you have a working font with symbols already installed and that you specify it correctly on the second line.

Dotfiles Part 3: Wherein Things Remain the Same

I spent some time trying to get my dotfiles working with git-crypt. I really tried. However, I kept having problems with it. Bad problems, like accidentally committing unencrypted files to my repo. Undoing that means purging and re-writing history, which is a major pain.

Some of these mistakes were my fault. I thought everything was working after a reimaging and restore from backup, but had failed to re-initialize git-crypt so it didn't know it was supposed to  be encrypting or with what keys. However, some were not. One of the problems is that due to the transparent way git-crypt works, a git show will always show you the plaintext changes, so there is no obvious indicator that something isn't going to be encrypted as expected. Git-crypt added a check command because of user feedback, which let's you check to make sure a file is being encrypted on commit. I ran into at least one situation where I checked a file with git-crypt check, and it reported that it would be encrypted, and yet on checkin it was still committed in plain text.

There is just too much danger of accidentally exposing the sensitive files you are trying to keep encrypted for me to have any confidence in continuing to use git-crypt as a solution. Which is a real shame, because the transparency which is its weakness is also its biggest strength. I was able to easily add it into the dotfiles script to handle unencrypting automatically which made it frictionless in normal use, at least on the receiving/installing end of things.

Dotfiles Part 2: I Knew It Couldn't Be That Easy

    As I discussed in the first post, I wanted a place to store my dotfiles where I could easily pull them down onto a new system. Github has become a popular place for this. It makes sense. Github is a cloud based git repo that you can easily reach from anywhere you have an internet connection. Git is a VCS which makes it easy to track changes to text files, which dotfiles are by definition. A simple git clone on a new system, and you have all your files ready and waiting for you.

    There are, of course, some issues with simply creating a git repo out of your entire home directory. So, many systems have been created which usually use symlinks to point into the repo controlled directory instead. There is even a nice listing available on the unofficial guide at github at http://dotfiles.github.io. It lists out some bootstrap systems to handle the symlinking and setup. It moves on to some app specific options, for things like shells and editors which may have extensive config and plugins that may be better managed with a dedicated system. Lastly, it covers general purpose dotfiles utilities, which may do more than just symlinking and syncing them for you.

    I've started to figure out how I wanted to manage my dotfiles many times over the years, and never gotten much further than looking at this massive page of options, opening up many of them in tabs, and then getting overwhelmed or distracted. This time, however, I was determined to make a choice and start trying to implement it. Even if it didn't end up being the solution I use in the end, I needed to get started at some point and figure out what would and wouldn't work for me. So, I made an initial pick.

Dotfiles: More Than Meets the Eye

    Dotfiles are pretty important. Anyone who has used a *NIX OS for a while will recognize the truth of this simple statement. For the uninitiated, Linux, Unix, and BSD (and OSX, which is a variant of BSD) operating systems have many things in common. One of these things is that files whose name begins with a period, like .config for example, are treated specially and hidden from the vanilla file list command, ls. Now, they aren't super secret or anything. A simple -a added to the ls command (making it ls -a) will show them again, they are just hidden by default. Due to the naming and pronunciation (.config would be spoken dotconfig by most people) they have become known collectively as dotfiles.

    The assumption is that they will be system files, usually configuration settings and the like, that you won't work with every day and won't want cluttering up your file listings all the time. Which is a pretty good assumption considering that the things multiply like crazy. These days it isn't just dotfiles, you have entire subdirectories that hold all sorts of things for whatever program uses them. Example, I have a .weechat that holds all the config settings, plugins, and chat logs from my irc client. Many programs use these the way Windows programs use their directory under Program Files. It is a good system, as it keeps the config easily findable in the user's home directory and also keeps the config user specific.

    Since they control the configuration of so many different pieces of your system, the dotfiles become important. They are how your system has been configured the way you like it. How it knows the behavior you want. They become very valuable, and over time, very difficult to replace. Some people spend years making small modifications to files like .bashrc and .vimrc until the resulting config is perfect. However, recreating it from scratch might be impossible as you won't remember what the setting you found on that obscure blog 3 years ago that solved this one issue was. You basically have to start over and tweak slowly until you arrive at another working, but inevitably different, config.