Docker container points to the wrong runc after a reconfigure in GNU GUIX
About a couple of years ago, I decided to try GNU GUIX as my main linux distribution. This came with a significant learning curve, which tested my patience multiple times, as I had to solve problems that in other distributions are not that common. This post is about one of these problems which I encountered recently, where a docker container stopped working after invoking the reconfigure command in GUIX to update my system.
The solution to the problem is not mine, in fact, it was posted as an issue in the GUIX issue tracker a few years ago; however, I had to make a tiny change to make it work on my end.
As soon as I tried to restart the docker container after reconfiguring my system I got an error that was similar to this (taken from the issue above):
Unknown runtime specified /gnu/store/jx64b4nnh6yvsbp117bfjc5spqz0jfq5-runc-1.0.0-rc6/sbin/runc
which seems to indicate that the container keeps the links to a specific version of runc that is different to the one being used by the current/updated Docker instance. The solution is to find the following file:
/var/lib/docker/containers/<container-hash-goes-here>/hostconfig.json
and edit it to use the same version of runc that is installed in GUIX. One quick way to find out what packages are currently installed is to call
guix package -I
As a final step, we need to run the following command:
sudo herd restart dockerd
this will allow the old containers to run again. The issue that describes the original fix mentions that the hostconfig.json file could be located in
/var/run/docker/containers/<container-hash-goes-here>
whereas in my case the file was in:
/var/lib/docker/containers/<container-hash-goes-here>
Hopefully this will help others having the same problem.
Adding multiple remotes for a single git repository
It is sometimes useful to make multiple remote copies of a git repository, for instance, pushing your changes to both GitLab and GitHub. This can easily be done by calling the following commands:
git remote add gitlab url-to-your-gitlab-repository git remote add github url-to-your-github-repository
The url-to-your-gitlab/github-repository part assumes that you already have
created an empty repository in GitLab/GitHub. Now we are ready to push the
latest changes using:
git push gitlab branch-name git push github branch-name
where the branch-name variable refers to the actual name of the branch
you need to push.
How to move to the next or previous workspace in i3
I have been trying to find default keybindings in i3 to move to the next and previous workspaces for some time now without any luck. Recently I found an alternative way to do it that works for my setup. Here it is:
First we need to install jq, which is a JSON parser. This can be done by
calling this in a terminal (assuming that you are using any flavour of
Ubuntu):
sudo apt install jq
Once this was installed, I created bash scripts called .i3-move-next.sh
and .i3-next.sh, and placed them under my home directory. Both of them
must have the necessary permissions to allow the execution as programs. The
contents of the files are as follows:
.i3-move-next.sh
wsNext=$(( $( i3-msg -t get_workspaces | jq '.[] | select(.focused).num' ) + $1)) i3-msg move container to workspace $wsNext i3-msg workspace $wsNext
.i3-next.sh
wsNext=$(( $( i3-msg -t get_workspaces | jq '.[] | select(.focused).num' ) + $1)) i3-msg workspace number $wsNext
Finally I used these keybindings in my i3 configuration file:
bindsym $mod+bracketright exec ~/.i3-move-next.sh 1 bindsym $mod+bracketleft exec ~/.i3-move-next.sh -1 bindsym $mod+equal exec ~/.i3-next.sh 1 bindsym $mod+minus exec ~/.i3-next.sh -1
Now I can use the mod key and [ to move a container to the previous
workspace and the mod key with ] to send it to the next one. Similarly,
if I just want to go to these workspaces without bringing a container I can
just type the mod key and = to go to next and - to go to the previous
one. This was done based on the type of keyboard I was using, it might not
be as efficient for other configuration. The important thing here is that
you can just change the key to whatever you like to achieve the same
thing. I didn't test this solution extensively, still have to see if it
works for a multiple monitor setup.
The solution came from the comments in this Reddit thread.
Installing SLYCOT to use the python-control toolbox
In order to use some features of the python-control toolbox, you need to
have the Subroutine Library in Systems and Control Theory (SLYCOT)
installed. I issued the following commands to install it under Ubuntu
20.04:
$ sudo apt install cmake $ sudo apt install gfortran $ sudo apt install libopenblas-dev
The first line gives you cmake which I thought it should have been
installed by default, but it wasn't the case. The second line installs a
FORTRAN compiler called gfortran; there are others, but this is the one I
tried since it is suggested in the python-control toolbox
documentation. Finally, I installed OpenBLAS by calling libopenblas-dev,
which gives you access to BLAS/LAPACK dependencies.
The last thing I did was to install SLYCOT by calling:
$ pip install slycot
The documentation of the python-control toolbox can be found
here. The python-control toolbox has its own wrapper for SLYCOT and it can
be found here.
Deploying my site to the server
I have managed to deploy this website using a really nice blog post by Andrew J. Flemming where he speaks about creating HUB and PRIME git repositories to interact with his server in mediatemple. I followed his steps and just had to change the paths pretty much. Here is a recap.
1. Create the PRIME repository
First I created an empty git repository in the public html folder of the domain
(This assumes that you have ssh access to your server). Also, I made an
initial commit there.
$ cd /path-to-your-domain/html $ git init $ git add . $ git commit -m "First import"
2. Create the HUB repository
Then I placed the HUB outside the public html folder, not in
the home directory as Andrew J. Flemming suggested. I created a folder called repo
which sits inside the domain folder. Inside repo, I added another folder
called your-domain.git, which will host a bare git repository (notice
that you can call this folder any way you want, as long as it ends with
.git, your-domain.git is just a placeholder in this case).
$ cd /path-to-your-domain/ $ mkdir repo $ cd repo $ mkdir your-domain.git $ cd your-domain.git $ git --bare init
3. Remote and Hooks
Our PRIME repository needs to have a remote repository in order to get
the files that are part of the website, in this case the
folder we just created your-domain.git will act as the remote.
$ cd /path-to-your-domain/html $ git remote add hub /path-to-your-domain/repo/your-domain.git $ git remote show hub $ git push hub master
Then we just need to add two hooks. These will tell the repositories that
we created what to do once they receive new code. Two hooks are needed: a
post-commit, and a post-update. The post-commit, has to be created in
the .git/hooks/ folder of your PRIME repository. We can do this by adding
the following code the post-commit.sample file and then removing the
.sample part to activate it.
#!/bin/sh git push hub
If you don't have a post-commit.sample, just create the post-commit
file directly and add the previous bit of code.
Now we need a post~update hook that will reside in the
your-domain.git/hooks/ folder. This will tell our HUB to go to the PRIME
repository and then execute a pull from that location for us.
#!/bin/sh cd /path-to-your-domain/html || exit unset GIT_DIR git pull hub master git-update-server-info
4. Push local changes to the HUB
In my case, I had some code in my local repository already since I wanted
to test how the website would look before deploying it to the server. Then
I just had to add a remote to the local repository as follows:
$ cd /path-to-your-local-repository $ git remote add hub ssh://yourdomain.com@yourdomain.com:/path-to-your-domain/repo/your-domain.git $ git pull hub master
Notice that in the previous code, the line
ssh://yourdomain.com@yourdomain.com: assumes that you have a username
(part before the @) and the address of the server you want to access (what
comes after the @).
Finally, I was able to push the site I built locally to the server using these commands:
$ git add . $ git commit -m "Initial commit of my website" $ git push hub master
The same procedure can be used for other domains in your server as long as you define a HUB for each of them.