Updated: April 8, 2020
Backups are important. Backups are crucial. Backups are love, backups are life. Over the years, I've talked about the cardinal value of keeping your data safe, and that means multiple copies, multiple locations. We also talked about how to concoct your own quick 'n' dirty setup with tar and gpg recently. That one covers both data and application settings. Speaking of the latter ...
Let's expand on this some more. If you have multiple computers, reinstall systems frequently, or just like to have a consistent configuration across multiple hosts, you might be interested in a way to manage application settings. In Linux, most software keeps their configurations in hidden files inside the home directory, either at the top level (/home/username) or inside the .config sub-directory. Either way, there could be plenty of them, you want to make sure you always have a copy, and if something goes wrong, you can easily revert to a good checkpoint. Introducting YADM and Homeshick.
Yet Another Dotfiles Manager (YADM)
The name isn't inspiring, but the program comes with a noble mission. It's designed to help you keep versioned copies of your configuration files, so that you have a flexible, robust setup. This concept is different from software that tries to auto-guess your settings - it's more like my manual one-liner above, in that you need to take care of every configuration file separately. However, a DIY setup requires that you constantly keep copies of data, and this might be cumbersome, plus you won't necessarily know which particular backup contains the right changes.
YADM aims to introduce an element of temporal depth by using git in the background. Basically, you commit your own configurations to your own repo, and this gives you all the necessary bits and pieces, like version history, diff and alike. All right, let's see how it works.
The start was promising. I had YADM running, and I was able to add files:
roger@matrix:~$ yadm add .ssh
roger@matrix:~$ yadm add .gnupg
However, when I tried to commit the files, YADM complained that it didn't know who I was:
roger@matrix:~$ yadm commit
*** Please tell me who you are.
git config --global user.email "firstname.lastname@example.org"
git config --global user.name "Your Name"
to set your account's default identity.
Omit --global to set the identity only in this repository.
fatal: unable to auto-detect email address (got 'roger@matrix.(none)')
This error is kind of unnecessary. The program could check whether you've identified before you add any files. Moreover, I'm not sure what would happen if you identify with an incorrect email or name? How would this affect authentication later on? I decided not to risk it, so I used localhost to get past this stage, and then I was able to commit.
roger@matrix:~$ git config --global user.email "email@example.com"
roger@matrix:~$ git config --global user.name "Roger Bodger"
yadm commit -m "Testing commits first batch"
[master (root-commit) fe99215] Testing commits first batch
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 .gnupg/pubring.kbx
create mode 100644 .gnupg/trustdb.gpg
But then, the last step baffled me - the actual push. Yes, I know how git works and all that - so that means you actually do need to have a server, running git, available on your network (LAN or the Internet or whatever). If so, this complicates the setup, and also makes it less flexible, because you can't really keep modular, independent offline files.
I spent a bit of time reading the documentation, and I found the workflow rather cumbersome. Perhaps I'm missing something really obvious, but I also believe in self-explanatory simplicity of great software. The fact I wasn't having a stellar experience right away, no questions asked, means this is a solution with a different brain pattern - and thus need - to mine.
You may think this is Sean Connery's favorite git-based backup software, but the joke is on you, ha ha! It's a shell script version of the now deprecated Ruby-based Homesick dotfiles synchronizer software. The BASH-ful nature of this tool should make it simple to configure and use.
I followed the instructions, and indeed, the setup is trivial. But you also need to append the script sourcing to the end of your .bashrc file in your home directory, otherwise, you will need to use the full proper path to run the tool.
Now, Homeshick works by combining git with symlinking. Basically, any file you add to it will then be symlinked to your repo. Which brings the question, what happens if you want to "remove" a file? Anyway, the repos are actually called castles (the default one is CASTLE).
homeshick uses git in concert with symlinks to track your precious dotfiles.
Usage: homeshick [options] TASK
homeshick cd CASTLE # Enter a castle
homeshick clone URI.. # Clone URI as a castle for homeshick
homeshick generate CASTLE.. # Generate a castle repo
However, the instructions aren't clear enough - if you run the first command right away, you'll get an error:
homeshick cd CASTLE
bash: cd: /home/roger/.homesick/repos/CASTLE: No such file or directory
The script doesn't check whether there's a repo, so it won't warn you that you need to generate one. This isn't a big problem, but there's really no reason why there couldn't be a friendly default setup, or at least a warning so the users can sort it out.
homeshick generate CASTLE
Getting started etc
Looking at the existing list of repos, the author's one is there too. Anyway, I went on about using the script. Basically, it's manual work. You specify the repo and the file you want to move inside, which will then be symlinked in the correct place, e.g.:
homeshick track CASTLE ~/.profile ~/.gnupg
The next step is to commit the change, and then push to a repo - bringing about the online nature of this script, much like YADM. Unless, of course, you want to use your own server configuration. Not trivial, and I had to consult the documentation. You end up doing cd CASTLE, git commit, git push , the whole deal. So in a way, homeshick abstractizes a bunch of git commands (like branches and such). I found this equally baffling to my earlier attempt, so I guess the software is mostly designed for developers.
There were some odd errors, too. Like the repo refresh. What does that do really? How does it determine that a local repo is outdated if it indeed has no upstream? I was also frightened that my files might somehow get overwritten, and what happens then?
refresh The castles CASTLE,homeshick are outdated.
no upstream Could not pull CASTLE, it has no upstream
My brain is definitely not that of a software developer - which is why I find a tool like git not friendly at all. It feels like a machine-oriented rather than human-oriented piece of software, and it feels more convoluted than it should be. Similarly, YADM and Homeshick don't strike me as ideal solutions to the home directory config question. If I need to do things manually, and then commit them to a backup (archive), I might as well do it proper manually, with more flexibility and control.
I understand what these two tools try to solve, and having a fully synced and versioned setup on multiple systems is a good idea (you can script the pull and push procedures, have it all running smoothly in the background), but both programs are too nerdy, and they should have more elegant initial configuration and better error checking. Lastly, there's the question of privacy. Do you really want to push important files into an online repo just like that? Are you comfortable with the security levels, encryption levels - and your ability to make the setup tight and smart without silly holes? So to my original quest, I think the simplicity of rsync, tar and gpg remain my preferred solutions to the home directory backup. But if you are a young git - and not an old git like me - then you might like this. There we go.