action #127091
closed
openQA default container should provide a certificate for starting
Added by okurz about 2 years ago.
Updated about 2 years ago.
Category:
Regressions/Crashes
Description
Observation¶
susetest:~ # podman run -t registry.opensuse.org/devel/openqa/containers15.4/openqa_webui
WARN[0000] Path "/etc/SUSEConnect" from "/etc/containers/mounts.conf" doesn't exist, skipping
WARN[0000] Path "/etc/zypp/credentials.d/SCCcredentials" from "/etc/containers/mounts.conf" doesn't exist, skipping
AH00526: Syntax error on line 18 of /etc/apache2/vhosts.d/openqa-ssl.conf:
SSLCertificateFile: file '/etc/apache2/ssl.crt/server.crt' does not exist or is empty
Expected result¶
The container should start with no error
- Related to action #127139: Docs for containerized setup lead to errors and ambiguity added
Can anyone execute this in rootless mode without running into?
podman run -t registry.opensuse.org/devel/openqa/containers15.4/openqa_webui
Trying to pull registry.opensuse.org/devel/openqa/containers15.4/openqa_webui:latest...
Getting image source signatures
Copying blob f145b778e007 done
Copying blob 89239c3d161f skipped: already exists
Error: copying system image from manifest list: writing blob: adding layer with blob "sha256:f145b778e0073edb01cb78328db3848cc52f268145d15c1ff8a10d53ece895c2": processing tar file(potentially insufficient UIDs or GIDs available in user namespace (requested 65534:0 for /var/lib/nobody): Check /etc/subuid and /etc/subgid if configured locally and run podman-system-migrate: lchown /var/lib/nobody: invalid argument): exit status 1
EDIT: It works after increasing the range in the files mentioned in the error accordingly.
One can use podman run -v ./container/webui/test-cert.pem:/etc/apache2/ssl.crt/server.crt:z -v ./container/webui/test-key.pem:/etc/apache2/ssl.key/server.key:z -v ./container/webui/test-cert.pem:/etc/apache2/ssl.crt/ca.crt:z -v ./container/webui/conf:/etc/openqa -t registry.opensuse.org/devel/openqa/containers15.4/openqa_webui
but then it of course fails because the database isn't reachable. Not very surprising considering we don't start the database within that container. Not sure whether that's wanted.
Speaking as a user who is just following the documentation I don't necessarily have an expectation where the database runs. But it should be documented and if the container requires another container it should fail with an error that tells me what it needs.
With a few changes to the startup script and config one could start the database within the container as well. It is not that bad considering even openQA-local-db
is already installed in the container anyways.
podman image build --tag='openqa_webui_local_build' .
…
podman run -p 1080:80 -p 1443:443 -v ./container/webui/test-cert.pem:/etc/apache2/ssl.crt/server.crt:z -v ./container/webui/test-key.pem:/etc/apache2/ssl.key/server.key:z -v ./container/webui/test-cert.pem:/etc/apache2/ssl.crt/ca.crt:z -v ./container/webui/conf:/etc/openqa -v /hdd/tmp/container-pgsql-data:/var/lib/pgsql/data -t openqa_webui_local_build:latest
…
Can not create MOJO_TMPDIR : mkdir /var/lib/openqa/share/factory: File exists at /usr/share/openqa/script/../lib/OpenQA/Setup.pm line 337.
…
Web application available at http://[::1]:9526
…
- Status changed from New to In Progress
- Due date set to 2023-04-26
Setting due date based on mean cycle time of SUSE QE Tools
- Status changed from In Progress to Resolved
The PR has been merged and other team members tested it.
Also available in: Atom
PDF