Solution for problem: rootless Docker container cannot ping outside networks

I am running a rootless docker container on a Ubuntu host (24.04 LTS). However, I cannot ping the host where the container is running and the outside network. The workaround I created are two steps:

1. Run the container with the --privileged option, as in

   docker container run --privileged 

2. On the host where the container is running, set Linux kernel parameber `net.ipv4.ping_group_range` to include the group id that runs the container. For instance, if the group id of the user that runs the container is 3000, we can set the parameter as follows:

   echo "3000 3000" > /proc/sys/net/ipv4/ping_group_range

If tests indicate that pings are successful in the container, we can set the kernel parameter through a configuration file so that the setting can survive reboot, e.g.,

• On the host that the container is running, create a file, e.g., /etc/sysctl.d/99-ping-group-range.conf as in:

  echo "net.ipv4.ping_group_range=3000 3000" \
         > /etc/sysctl.d/99-ping-group-range.conf

The idea of these is from

1. https://github.com/containers/podman/issues/2488
2. https://opennms.discourse.group/t/how-to-allow-unprivileged-users-to-use-icmp-ping/1573

SSH Publication Key Authentication Fails When Home is on NFS

As the title stated, regardless how I try, I couldn't get SSH publication key authentication to work for a Linux host. It turns out that the Linux host that runs the SSH server has SELinux enabled. To make public key authnentication work for SSH, we simply need to configure SELinux, i.e.,

sudo setsebool -P use_nfs_home_dirs 1

Signing Git Commits: Inappropriate ioctl for device

When I attempted to sign a Git commit, I encountered the following error:

$ git commit -S -m "important change"
error: gpg failed to sign the data:
[GNUPG:] KEY_CONSIDERED AAAABBBBCCCCDDDD00000 2
[GNUPG:] BEGIN_SIGNING H8
[GNUPG:] PINENTRY_LAUNCHED 583247 curses 1.2.1 - xterm localhost:10.0 - 1000/2001 0
gpg: signing failed: Inappropriate ioctl for device
[GNUPG:] FAILURE sign 83918950
gpg: signing failed: Inappropriate ioctl for device

fatal: failed to write commit object

After an investigation, I learned that the problem could be somethign with gpg itself. To gauge whether it is the problem with gpg, we could sign a message with gpg, e.g.,

$ echo "test" | gpg --clearsign
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

test
gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device

Clearly, we observe the same error message. We can conclude it is the issue with gpg. It turns out that one reason of this is that tty is not set properly. To fix this, we set tty for gpg using

export GPG_TTY=$(tty)

This can be added to shell script's profiles

Cannot start cmd.exe on Windows 10

Somehow I encountered the problem that I could not start the Windows Command Prompt (cmd.exe). The solution turns out is to remove a key from the registry. A number of posts points to the removal of HKCU\Software\Microsoft\Command Processor\AutoRun. A complexity comes from the factor that the user account is a standard user account; howeer, regedit needs to run as an administrator, which means the HKCU is the administrator, not the standard user.

To address this issue, we can perform the following steps

1. Figure out the user's sid:

   
       whoami /user
       

   The sid begins with S- that we can easily recognize from the output.
2. Open regedit, and browse to HKEY_USERS, to the user according to the user's sid, to Software, to Microsoft, to Command Processor, and then locate AutoRun, and remove it.

A StackOverflow post indicates several more keys to remove, but it is not necessary in my case, but it is good to document it, just in case in the future

reg delete "HKCU\Console" /f
reg delete "HKCU\Software\Microsoft\Command Processor" /v "AutoRun" /f
reg delete "HKLM\Software\Microsoft\Command Processor" /v "AutoRun" /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File 
Execution Options\cmd.exe" /f

Installing Git and Other Tools on Linux Systems without Administrative Privilege

Sometimes I want to install software tools, such as Git, Screen, and the others on a Linux System, however, I find outselves without administraive priviledge. The first method comes to mind is to download the source code and to compile and to set it up. This method can be sometimes challenging due to numerous dependencies may also be missing on the system.

Recently it comes to me that we can do this via conda. For instance, the following steps let me install both Git and Screen on a Linux system without administrative priviledge

1. Download miniconda.

   
   wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
       

2. Set up miniconda

   
       bash Miniconda3-latest-Linux-x86_64.sh
       

3. Initialize conda. Exit shell and get back in, and then

   
       conda init
       

4. Install Git via conda

   
       conda install anaconda::git
       

5. Install Screen via conda

   
       conda install conda-forge::screen
       

6. Find and install others ...

Some may think this method is overkill. However, it saves me tons of time to download and compile tons of dependencies. Is our own time more valuable?

Windows Update Failed with Error Code 0x80070643

A recent Windows 10 udpate resulted in error code 0x80070643. The cause was that the Windows Recovery partition was not big enough. Recreating a larger Windows Recovery partition solved the issue. The references helped me are as follows:

1. Install error - 0x80070643
2. KB5034441: Windows Recovery Environment update for Windows 10, version 21H2 and 22H2: January 9, 2024
3. KB5028997: Instructions to manually resize your partition to install the WinRE update