Running SecureDrop inside of podman containers on Fedora 33
Last week, while setting up a Fedora 33 system, I thought of running the SecureDrop development container there, but using podman instead of the Docker setup we have.
I tried to make minimal changes to our existing scripts. Added a ~/bin/docker
file, with podman $@
inside (and the sha-bang line).
Next, I provided the proper label for SELinux:
sudo chcon -Rt container_file_t securedrop
The SecureDrop
container runs as the normal user inside of the Docker
container. I can not do the same here as the filesystem gets mounted as root,
and I can not write in it. So, had to modify one line in the bash script, and
also disabled another function call which deletes the /dev/random
file inside
of the container.
diff --git a/securedrop/bin/dev-shell b/securedrop/bin/dev-shell
index ef424bc01..37215b551 100755
--- a/securedrop/bin/dev-shell
+++ b/securedrop/bin/dev-shell
@@ -72,7 +72,7 @@ function docker_run() {
-e LANG=C.UTF-8 \
-e PAGE_LAYOUT_LOCALES \
-e PATH \
- --user "${USER:-root}" \
+ --user root \
--volume "${TOPLEVEL}:${TOPLEVEL}" \
--workdir "${TOPLEVEL}/securedrop" \
--name "${SD_CONTAINER}" \
diff --git a/securedrop/bin/run b/securedrop/bin/run
index e82cc6320..0c11aa8db 100755
--- a/securedrop/bin/run
+++ b/securedrop/bin/run
@@ -9,7 +9,7 @@ cd "${REPOROOT}/securedrop"
source "${BASH_SOURCE%/*}/dev-deps"
run_redis &
-urandom
+#urandom
run_sass --watch &
maybe_create_config_py
reset_demo
This time I felt that build time for verifying each cached layer is much longer than what it used to be for podman. Maybe I am just mistaken. The SecureDrop web application is working very fine inside.
Package build containers
We also use containers to build Debian packages. And those molecule scenarios
were failing as ansible.posix.synchronize
module could not sync to a podman
container. I asked if there is anyway to do that, and by the time I woke up,
Adam Miller had a branch that fixed the
issue. I directly used the same in my virtual environment. The package build
was successful. Then, the testinfra tests failed due as it could not create
the temporary directory inside of the container. I already opened an
issue for the same.