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.

Sorting Algorithms

I just want to call out a nice site that has a visual representation of various sorting algorithms.

http://www.sorting-algorithms.com

They have eight different sorts offered, with different data sizes, and with data in various starting configurations (random, neatly sorted, reversed, few unique). Having the different input configurations is really nice as it will visually show you the strengths and weaknesses of the various sorts. It also includes a short discussion of the algorithms and lists their properies.

Laptop Hibernation

I enabled hibernation on my laptop where I am using LUKS + LVM on Fedora 25.

1. Edit /etc/default/grub to add resume=swapdevice to GRUB_CMDLINE_LINUX (my device was /dev/fedora/swap since "fedora" is my volume group and "swap" is my logical volume for swap).
2. sudo dracut -f

While I did install the hibernate status button extension, I was also able to test things out with 'sudo systemctl hibernate'. The laptop went into hibernation and I was able to boot back up picking up where I left off.

And the nice thing, my swap is on the encrypted volume so my save image is therefore encrypted as well.

LUKS & SSD

I tried out Fedora on my laptop. The installation went rather smooth. My laptop has a SSD that I used as my primary drive and I installed using it alone, using LUKS and LVM.

Since it is an SSD, I needed to configure things to allow discards so I could run a trim command against it. While I have done this before, I had not on Fedora. So I did some searching and came across a Q&A about the proper way of setting up fstrim on Fedora 23. I did not run into the same problems that person ran into that required extra steps so I wanted to share what worked for me.

I had to do the following:

1. Change /etc/lvm/lvm.conf to set issue_discards=1
2. Add 'discard' to the line in /etc/crypttab for my volume as the 4th field
3. Run 'dracut -f' to create a new initrd

That was all. Upon reboot I was able to run 'fstrim -a -v' to see that all of my filesystems on the SSD were trimmed. I did not have to alter my grub config to make things work; the /etc/crypttab getting copied into the initrd seemed to be the only thing necessary for me.

I did then run the commands (as root) they had to enable the timer and service:

systemctl enable fstrim.timer
systemctl start fstrim.service

With that I had things working just fine. The timer worked as expected.

Super Bowl, Copyright, and Trademark

Ars Technica has a wonderful article about Super Bowl legal trademark and copyright myths. I would encourage reading it as it is an example of how large companies (NFL in this case) try to use their size to prevent legal use of their products.

GNOME Orca on Slackware 14.1

On Slackware 14.1 I wanted to get Orca up and running without a full GNOME install just like I had in the past with 13.37. With the GNOME Slackbuilds project no longer active I took a different route.

From Slackbuilds.org I installed the following packages because I am going to be using espeak as my speech synthesizer:

• portaudio
• espeak

I got everything else from the dropline GNOME project. I am only installing selected packages from their 3.10 packages just to get Orca running, but you could simply use their installer to install the full GNOME desktop for an overall better accessibility experience on the desktop.

Download and install/upgrade the following packages from their 3.10 site:

• at-spi2-atk-2.10.2-x86_64-1dl (use upgradepkg)
• at-spi2-core-2.10.2-x86_64-1dl (use upgradepkg)
• atk-2.10.0-x86_64-1dl (use upgradepkg)
• dotconf-1.3-x86_64-1dl
• glib2-2.38.2-x86_64-1dl (use upgradepkg)
• gobject-introspection-1.38.0-x86_64-1dl (use upgradepkg)
• orca-3.10.2-x86_64-1dl
• py3gobject-3.10.2-x86_64-1dl
• pyatspi-2.10.0-x86_64-1dl
• pygobject3-3.10.2-x86_64-1dl (use upgradepkg)
• python3-3.3.2-x86_64-1dl

There is one required package that I do not have in that list, speechd-0.8-x86_64-1dl.txz. It was built without espeak installed so it does not have espeak support. By default it has Festival support. If you use Festival, you should be fine with the downloaded package. Since I am using espeak, I needed to rebuild it.

How you rebuild speech-dispatcher is up to you. I was playing around with some alternate instructions I found before I just used the dropline packages. Since I still had Aiyumi's slackbuilds on my system I modified the speech-dispatcher slackbuild to install 0.8.1 and build it that way. Orca 3.10 requires speech-dispatcher 0.8 or greater which is why I had to change the version.

On a final note, Firefox on Slackware is built without accessibility support enabled. You either need to rebuild after modifying Patrick's slackbuild to enable it, or you just need to download it directly. I do the latter, but I us Ruario's latest-firefox script in order to repackage it as a Slackware package.

Slackware 14 & Epson XP-410

We replaced our old Multifunction Printer (MFP). I looked for an affordable replacement compatible with Linux (specifically Slackware), OS X, and Windows. I chose the Epson XP-410 printer. Epson provides Linux drivers on their website, research indicated it works perfectly with Linux, and I found it on sale locally.

The OS X and Windows installs were done via the Epson provided software. So what about Slackware?

Slackware 14 does not ship with a PPD file for the XP-410. I went to SlackBuilds.org and found the epson-inkjet-printer-escpr package, which corresponds to the driver I saw on the Epson site. However, the source URL provided does not exist. So I downloaded the epson-inkjet-printer-escpr-1.2.3-1lsb3.2.tar.gz source from Epson.

I used the CUPS localhost:631 web interface for setup. I set it up as a AppSocket/JetDirect network printer as it is not directly connected to my machine. The XP-410 PPD from the installed package showed up as expected. I added the printer and the test page was successful.

I use SimpleScan for scanning and the XP-410 did not show up as an available scanner unless I disable my firewall. I did some poking around, expecting to have to add a firewall rule, but found that adding 'net <printer ip address>' to /etc/sane.d/epson2.conf was the only thing necessary to get it to work.

Overall, setup was pretty simple within the context of Slackware. Other distributions may ship the PPD's by default. I tried the openSUSE 12.3 Live CD. The package is available in their repository, but does not come with the XP-410 driver. Epson indicates the XP-410 is "new" so I assume openSUSE 12.3 shipped before the driver was released (I failed to note the installed version).

I am pleased with the purchase as far as OS compatibility and setup goes. I have not used it enough to comment on it as a MFP in general, but initial use has been satisfactory.

On a tangent, for those reading this newer to Slackware and/or Slackbuilds.org, I use Sbopkg to manage my SlackBuilds.org packages. As mentioned, I downloaded the source from Epson and placed it in /var/cache/sbopkg. In Sbopkg, I edited the Slackbuild and Info files for the package to use the downloaded source. In the Slackbulid script, I changed the version from 1.2.2 to 1.2.3. In the Info file, I made the same version change everywhere I saw it, and I changed the MD5SUM to match the downloaded source MD5SUM. The MD5SUM is not required, but it eliminates a warning during the build and install process. After that, the build and install worked fine.

GNOME Orca on Slackware 13.37

I am trying to learn more about web accessibility. Since I am a Linux user, GNOME Orca with Firefox is the route to go (right now at least). The only problem with that for me is that I am a Slackware user right now and GNOME is not available out of the box on Slackware. Plus I do not really want a full GNOME install, I would prefer to just install Orca and the components needed by it.

Thankfully, the GNOME SlackBuild project makes this relatively easy to do. The first thing you want to do is to install slapt-get using their manual instructions. I am running Slackware 13.37 but I used the 13.1 64-bit package (I was having trouble getting this going with the work-in-progress that they had for Slackware  13.37). I did not have to worry about any of the configuration, it worked out of the box as is, however you still need to update it:

slapt-get --update
slapt-get --add-keys

Once that is done, you can install Orca itself via slapt-get:

slapt-get --install orca

This installed the following packages:


GConf-2.28.1-x86_64-1gsb
gnome-keyring-2.28.2-x86_64-1gsb
gnome-vfs-2.24.3-x86_64-1gsb
libgnomeui-2.24.3-x86_64-1gsb
at-spi-1.30.1-x86_64-1gsb
espeak-1.43.03-x86_64-1gsb
gail-1.22.3-x86_64-3gsb
gnome-mag-0.16.1-x86_64-1gsb
gnome-speech-0.4.25-x86_64-4gsb
libgail-gnome-1.20.3-x86_64-1gsb
ORBit2-2.14.18-x86_64-1gsb
gnome-mime-data-2.18.0-x86_64-3gsb
libbonobo-2.24.3-x86_64-1gsb
libbonoboui-2.24.3-x86_64-1gsb
libdaemon-0.14-x86_64-1gsb
libgnome-2.30.0-x86_64-1gsb
libgnomecanvas-2.30.1-x86_64-1gsb
libtasn1-2.7-x86_64-1gsb
portaudio-V19-x86_64-1gsb
pyorbit-2.24.0-x86_64-2gsb
speex-1.2rc1-x86_64-3gsb
avahi-0.6.27-x86_64-1gsb
orca-2.30.2-x86_64-1gsb


There is one more package that is needed that was not installed:

slapt-get --install gnome-python

Which will just install gnome-python-2.28.1-x86_64-1gsb. I did have to reboot after all of this to get Orca to run. There was probably something else that could be done but I took the quick and easy route for that part.

Next there is a gconf2 setting needed that I found on the Orca mailing list:

gconftool-2 --set /desktop/gnome/interface/accessibility --type boolean true

Once that is set you should be able to run Orca from a terminal to go through its setup. After that Orca should run just fine if you are running KDE (as I am) due to the dbus dependency. But you can just run Orca with dbus-launch if you are running something like Fluxbox (I am currently testing it in Fluxbox as I type this).

There is one final issue. Orca is relatively useless without applications that provide it the necessary information. Firefox normally would do this but Pat's SlackBuild script configures it with the --disable-accessibility option. So you either need to alter the SlackBuild script to enable accessibility and rebuild the package or just download Firefox from its site (this is what I did as I didn't want to wait for the build) and you will be set.

I don't have much experience at all with using screen readers so I cannot comment on how well Orca works compared to others, but it is reading Firefox for me and should be good enough to validate accessibility techniques for me.

On a side note, I did try Orca on a couple of other distros just in case I wanted to switch for this reason or at least dual boot. I was happy that I got it working on Slackware though. But Orca Ubuntu 11.04 worked great out of the box for me in both fallback and Unity (once again, I don't have experience with screen readers so my assessment may not reflect reality for someone that has to depend on this technology). It worked relatively well on Fedora 15 as well with Gnome 3 but I did have to set the gconf setting manually there.

So I consider this a success for my purposes (a sighted developer looking to learn more about accessibility).