Docker Desktop on Linux - Credential Store

Introduction

According to the documentation, in order to sign into Docker Desktop on Linux, pass must be installed and configured. While I already use pass, I wanted to keep Docker Desktop's use of pass separate. For a while I used the PASSWORD_STORE_DIR environment variable to manage separate password store locations, but I was not happy with that and started looking for alternative methods.

Docker Desktop vs. Docker Engine

Just to level set, Docker Engine and its associated command line tools are what most Linux users are familiar with. The dockerd daemon runs on a Linux host and users interact with it via the docker CLI. Containers use the host system's kernel and sudo is required to execute docker commands unless the user is in the docker group or rootless docker is used. Docker Engine is open source and is now based on the Moby Project.

While Linux users could simply run Docker Engine, Windows and Mac users had to use Docker Desktop. Docker Desktop included the same command line tools, but also provided a UI, and more importantly it provided a Linux virtual machine (VM) to run Docker Engine and the containers it managed. Unlike Docker Engine, Docker Desktop is not open source and in 2021 it changed from a free product to one with a cost for organizations of certain sizes.

In 2022, Docker Desktop was finally released for Linux. Just like Docker Desktop for Windows and Mac, it provided both a UI and a Linux VM for dockerd and running containers. Why run these in a VM when they can run natively? A reason given is it provides a consistent experience across all three platforms (Linux, Windows, Mac) because you have the same UI and the VM, which provides the same kernel version. Another reason given is security as your containers are no longer running on the host system, they are running a VM. This also makes it so neither sudo nor the docker group are required to execute docker commands.

Credential Store

When using Docker Engine alone, and without a credential helper, executing 'docker login' results in your docker credentials stored in plaintext in a file in your home directory. Installing a credential helper directs it to use one of the available credential stores such as pass or the D-Bus secret service.

The documentation for Docker Desktop is very clear that pass will be used and must be enabled to be able to sign in. There are no other alternatives provided. Given that I did not want to continue using pass for this, I started looking to see if the question had come up before.

Docker Desktop with D-Bus Secret Service

I was unable to find any official documentation that would confirm or deny if there was a way to use the D-Bus secret service. But I did come across a credential helper issue that requested a documentation update based on the issue creator figuring out how to do this. I was able to use the issue to configure Docker Desktop  to use the D-Bus secret service.

• I downloaded the docker-credential-secretservice-* binary for my platform, installed it in /usr/local/bin (anywhere on the PATH would be fine), and made it executable.
• In ~/.docker/desktop/settings.json I changed the credentialHelper value from "docker-credential-pass" to "docker-credential-secretservice".

That was it. When I signed into Docker Desktop, I was able to confirm that my credentials were not in pass, they were in my keychain which I could view with Seahorse.

I do not know if the lack of official documentation for this means there is some sort of risk associated with this method, or if only supporting one type of credential helper is done just to keep things simple; docker-credential-pass is part of the installation package. Regardless, it seems to be working just fine and I like having credentials in the D-Bus service rather than having them in my pass store.

GNOME Boxes - Backup / Restore

Introduction

I finally started to play with GNOME Boxes in conjunction with getting a RedHat Enterprise Linux (RHEL) individual developer subscription. Immediately I was curious about what it would take to backup and restore a virtual machine (VM) for a host reload, or to move a VM from one host to another. This post details my experience with this process.

GNOME Boxes

GNOME Boxes is a Graphical User Interface (GUI) for managing VMs on a Linux host. It aims to simply the process of creating and running a VM. In my exploration I ran it on a Pop!_OS 22.04 host and a Fedora Workstation 39 host. It is installed by default on Fedora (assuming the default Fedora Workstation is what you are running) and it has to be manually installed on Pop!_OS.

Pop!_OS is where I started playing around with it. I installed it via the Pop!_Shop. There are two options, one to install the Ubuntu .deb package and the second to install it via Flatpak. I started with the .deb package.

Boxes gives you an opportunity to let it download an operating system (OS) image for you. Unfortunately, on Pop!_OS, RHEL was not one of the choices. So I simply downloaded the image myself. Later on I did notice on Fedora, and with the Flatpak install, RHEL was an option listed.

RHEL

RedHat provides a free RHEL subscription to individual developers. They allow up to 16 instances to be deployed with that subscription. I opted to use RHEL because I wanted to have an instance around for some personal development activities. The registration did not bother me as I welcomed the RedHat Developer weekly emails that I get. While not everything in them is relevant to me, I am finding a useful article here or there.

Backup

I had to do some searching to find out how to properly backup a VM image managed by Boxes. There isn't anything in the GUI that exports a VM and its metadata. But I found a couple of posts both detailing the same information.

Although I ran the backup on Pop!_OS, the instructions are the same on Fedora and should be the same on any other distribution. The variation will be with a Flatpak install which I cover later.

Metadata

To export the metadata for an image, you need its domain name. This does not appear to be available via Boxes. It can be retrieved via the 'virsh' command. This command is installed by default on Fedora but it needs to be installed on Pop!_OS via the 'libvirt-clients' package. To get the list of domain names, run:

virsh -c qemu:///session list --all

On my system, this was the output:

 Id   Name        State
----------------------------
 -    rhel9.3-2   shut off

In this case, 'rhel9.3-2' is my domain name. To export the metadata I ran:

virsh dumpxml rhel9.3-2 > rhel9.3-2.xml

I then copied the resulting XML to a USB stick for my backup.

Image

The image itself was easy to find. The images are all located here:

$HOME/.local/share/gnome-boxes/images

The filename of the image should match the domain name. On some posts it was stated there would be a file extension, but that was not the case for my image, it was simply called 'rhel9.3-2'. I copied this to my USB stick for a backup.

Restore

While I did the backup on Pop!_OS, I did the restore on Fedora. Again, this describes the process when using the distribution package rather than the Flatpak install. After performing these two steps, the VM showed up in Boxes for me and worked just fine.

Image

I simply copied my 'rhel9.3-2' image backup to:

$HOME/.local/share/gnome-boxes/images

Metadata

The metadata restore was also straightforward:

virsh define rhel9.3-2.xml

Flatpak Variations

A Flatpak is simply a distribution independent application package that runs on in a sandbox environment. Boxes is available as a Flatpak. After my initial backup / restore test with distribution native packages, I installed the Boxes Flatpak on Pop!_OS. There were just a couple of things I had to adjust in the process.

virsh

When running Boxes via Flatpak, the distribution native 'virsh' will not have access to your image metadata. You need to run 'virsh' from within the Flatpak sandbox for Boxes. You can enter a shell for that environment via this command:

flatpak --command=bash run org.gnome.Boxes

When doing so, since it is a sandbox you will not have access to your full host filesystem. Unless you restrict the permissions yourself, you will have access to your home fileystem and can run the 'virsh' commands from above and have read / write access to your home filesystem.

Image Location

Your VM images will still be stored in your home filesystem, but Flatpaks store their data in a different location. You will find your images here:

$HOME/.var/app/org.gnome.Boxes/data/gnome-boxes/images

XML

A backup / restore from a distribution native package to a distribution native package does not require any XML changes. A backup / restore from a Flatpak install to a Flatpak install does not require any XML changes. But if one system is using a distribution native package and the other is using Flatpak, the metadata XML will require two modifications before it can be restored. Please note that it was only two modifications for my use case, more advanced use cases may require additional changes.

Disk Image Location

The path to the VM image is in the XML. The difference between distribution native and Flatpak can be seen here:

<source file='/home/userid/.local/share/gnome-boxes/images/rhel9.3-2'/>

vs

<source file='/var/data/gnome-boxes/images/rhel9.3-2'/>

The path just needs to be updated for the desired target.

The reason the Flatpak image location looks different in the XML than the path I provided in the previous section is because the Flatpak sets up the sandbox environment with /var/data/gnome-boxes pointed to $HOME/.var/app/org.gnome.Boxes/data.

Emulator

The path to the hardware emulator is also in the XML. The difference between distribution native and Flatpak can be seen here:

<emulator>/usr/bin/qemu-system-x86_64</emulator>

vs

<emulator>/app/bin/qemu-system-x86_64</emulator>

Once again, the path just needs to be adjusted for the desired target.

Conclusion

While Boxes doesn't provide a direct way of backing up and restoring your VM images, it doesn't take much to do so. Beyond testing this process out I have yet to do anything useful with Boxes or RHEL, so I am not an expert by any means. But I hope this little bit of information will be useful.

 

Disable Laptop Keyboard

My laptop keyboard is having issues where a shift key stopped working and now (after I tried messing with it) is in a perpetual state of shift. At first, plugging in a USB keyboard mitigated the issue, except during boot where I had to hit my caps lock in order to type in my luks passphrase, but now it starts acting up within a few minutes of actually trying to use it.

While repairing the keyboard, or getting a new laptop 😀, is the ideal solution, I needed a quicker and cheaper option. After doing some searching, I found this askUbuntu post explaining how to disable the laptop keyboard so I could just use my USB keyboard.

I am running Pop!_OS now. I have a System76 laptop, which is about 5 years old (so they keyboard thing isn't an immediate failure), and wanted to give it shot while updating my firmware. I have been pretty happy with it, but that also means I am using systemd-boot to boot my laptop.

For anyone using Pop!_OS, the way to make this change is to run:

sudo vi /boot/efi/loader/entries/Pop_OS-current.conf

At the end of the options line I added the i8042.nokbd that is mentioned in the post I referenced.

The 8042 is an Intel microcontroller. One of its functions is to handle the standard keyboard interface. Adding that option to the kernel disables the keyboard interface. The USB keyboard I am using is unaffected because it is a USB keyboard. The nokbd option is handled by the i8042.c driver.

All you have to do is reboot after making the change, nothing else is needed. If you are concerned about your old kernel boot config, you can also modify the Pop_OS-oldkern.conf in the same location.

Firefox and Netflix

Netflix announced playback is now available (but not supported) in Firefox on Linux. This uses the optional EME module that can be installed in Firefox 47 or newer. Controversy about DRM aside, it is nice that they are doing this.

However, the blog post doesn't mention one important fact. I tried watching a video in Firefox running on Fedora. I got the unsupported page. I know the EME module is working because I can watch Amazon Prime videos on this same browser.

I got to looking at their system requirements page that I kept getting sent to. Apparently, it only works with official builds of Firefox from Mozilla; it will not work with non-Mozilla builds. So I downloaded Firefox directly from Mozilla to try it out. And sure enough, it did work (I ran it under the same Firefox user profile for consistency between the tests). Tried again with the Fedora build and no luck.

So either they are checking to see if it is an official Mozilla build or there is something disabled in Fedora's Firefox build. And it isn't the EME module as that is downloaded from Google if you check the box in the preferences to play DRM content.

I guess this is one step forward and half a step back. I prefer to just let Fedora (or whatever distro I am using at the time) update my Firefox versions, I am not interested in using or maintaining a downloaded copy.

Sigh.

UPDATE:

When I originally tried this out I did look at the user agent strings between the two browser instances and thought they were the same. However, after a suggestion to look at them again I noticed one minor difference:

Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Changing my general.useragent.override in the about:config to the second one got things to work. So not as dreadful as I originally though, just a minor annoyance. I can live with my user agent being changed permanently to leave off the "Fedora" :)

Simple Scan Slackbuild

The simple-scan package on SlackBuilds.org lists two dependencies: vala and libgusb. If you look at the README via sbopkg, it lists them as libgusb and vala. Order is important in this case. vala has to be installed first for simple-scan to compile properly as libgusb apparently has some vala hooks that simple-scan relies upon. If you build libgusb first and then vala, simple-scan's build will report an error (I didn't keep track of the exact error message, but it amounted to libgusb not having some sort of vala reference). Re-building libgusb resolved the issue for me.

Facebook GPG

This news is almost 2 years old now but I just got back onto Facebook a few months ago and found this to be interesting.

Facebook allows you to upload your public key so you have have all of your notifications encrypted.

I haven't fully enable it yet, I've just sent the test email to my account and it worked just fine. I haven't enabled it yet because right now I using Gmail's web interface as my mail "client" as a test (more on that later). And the last time I checked (plus a real quick search right now) doesn't show any sort of GPG integration with Gmail. But I may yet switch after I am done (if I am done) with the Gmail web interface.

Algorithmic Bias

Two days ago the ACM published a press release on algorithmic bias. Included in there is a PDF listing 7 principles for developers and organizations to consider when developing their algorithms. Computing automates many things and discrimination is unfortunately one of them.

Facebook has had a question come up with their ethnic affinity feature for ads. NOTE: I am not saying Facebook is engaging in discrimination with their ads. I haven't done any further research into this particular story to determine how the ethnic affinity actually works. I am merely posting it as an example of a question that has come up about an algorithm that a prominent company uses. If interested, please do additional research before making any judgments.

I don't know how much impact the ACM's statement will have on the developer community. But I do salute them for at least publishing this out there for awareness.