Hi

My contribution to the podman-py module got merged, and now I can work on the other blocker that has been stopping me in the previous week.

Every week, I start working on the next week deliverable after the weekly meeting. I didn't start working on this week's deliverable until Monday. So, I had three days as opposed to the normal five days. The first thing I did was review the notes from the last meeting; then I decided not to do the tasks sequentially (i.e start the second one only after finishing the first one) because I had only three days to the next meeting.

I started working on the two problems concurrently; I did this by allocating about 30 minutes to each task and switching between them. The initially problem was SELinux related, so I downloaded and watched a couple of videos on Security-Enhanced Linux(SELinux) labeling to really understand what it entails (N.B: There is still a whole lot of confusion with this topic).

After making the use of argparse in lcitool more robust in the previous week(check the last article for more details), a couple of new optional arguments such as --env, --workdir, --user were added. These optional arguments don't do anything, and so I had to implement a solution to make them work when running workload in a container. I was able to get this done on Tuesday, and so I had less than a day to figure out the other problem(it was Virtual machine (VM) related).

Why was I trying to creating a VM? I wanted to test if the mounts argument in the.create() endpoint used when creating a container in podman-py works when SELinux label options (z or Z) is passed. SELinux is disabled by default on Ubuntu (my current OS). Ubuntu uses AppArmor. In other to test the mounts argument, I wanted to create a Fedora-36 virtual machine using virt-install. NB: The mounts argument is used to share contents between host system and container.

Like every problem, I initially struggled with creating the VM, but after reading virt-install man page, I got a hint of how to properly create the virtual machine. I had downloaded the ISO image for Fedora-36 the previous night, I passed the necessary arguments and the installation process began.

The next problem I had was how to connect remotely to the virtual machine's console using SSH. After configuring libvirt-nss related settings with my mentor on the last weekly meeting, I had expected to be able to connect to the VM's console immediately after creating the VM —which wasn't the case(I was getting ssh: connect to host localhost port 22: Connection refused error).

It turns out that I had this problem because sshd( the openSSH server process) required to connect via SSH was not working(i.e the status was stopped). I figured this out by spinning up the virtual machine using virt-viewer( It opens the VM with a graphical interface that users can interact with). The solution was to set the sshd process to always be enabled whenever the VM boots up.

This was done with:

sudo systemctl enable ssh

I shutdown the VM to enable the new changes to be effected, and I was able to connect to the VM's console afterwards using ssh {user}@{vm name};

ssh baz@fed-36

MORE FROM THE WEEK

• While working on the optional argument problem, I learnt that in order to specify user parameter in a container, the user must be defined in the /etc/passwd file.

• I couldn't get the SELinux label test to work before the meeting. The meeting was mainly about reviews of the work I had done with podman-py community.

DELIVERABLE

Add a shell sub-command to lcitool, this would allow users to spin up an interactive tty from a container. Basically, the implementation of podman exec -it "image name" /bin/sh using podman-py.

NB: I was able to test the SELinux problem before the meeting ended. Very nice feeling.

REFERENCES

For connecting to a VM's console: READ

TTY DEMYSTIFIED: READ