ContainerizedSetup: a better way for chmod -R 777 data?

[MaxPeal]

setting it to 777, (readable, writable and executable by anyone), should be avoided,
is with the newer docker versions and podman a batter way?

openQA/docs/ContainerizedSetup.asciidoc

Lines 143 to 151 in 14886a8

	And set permissions, so any user can read/write the data:
	chmod -R 777 data
	This step is unfortunately necessary with Docker because Docker
	https://github.com/docker/docker/issues/7198[can not mount a volume with
	specific user ownership] in container, so ownership of mounted folders (uid
	and gid) is the same as on your host system (presumably 1000:1000 which maps
	into nonexistent user in all of the containers).

maybe a better way is the use of
https://github.com/just-containers/s6-overlay#fixing-ownership-and-permissions

Fixing ownership and permissions
This section describes a functionality from the versions of s6-overlay that are anterior to v3. fix-attrs is still supported in v3, but is deprecated, for several reasons: one of them is that it's generally not good policy to change ownership dynamically when it can be done statically. Another reason is that it doesn't work with USER containers. Instead of fix-attrs, we now recommend you to take care of ownership and permissions on host mounts offline, before running the container. This should be done in your Dockerfile, when you have all the needed information.

That said, here is what we wrote for previous versions and that is still applicable today (but please stop depending on it):

Sometimes it's interesting to fix ownership & permissions before proceeding because, for example, you have mounted/mapped a host folder inside your container. Our overlay provides a way to tackle this issue using files in /etc/fix-attrs.d. This is the pattern format followed by fix-attrs files:

or
https://github.com/boxboat/fixuid

fixuid is a Go binary that changes a Docker container's user/group and file permissions that were set at build time to the UID/GID that the container was started with at runtime. Primary use case is in development Docker containers when working with host mounted volumes.

fixuid was born because there is currently no way to remap host volume UIDs/GIDs from the Docker Engine, moby/moby#7198 for more details.

Check out BoxBoat's blog post for a practical explanation of how fixuid benefits development teams consisting of multiple developers.

fixuid should only be used in development Docker containers. DO NOT INCLUDE in a production container image

[Martchus]

The documentation about achieving a containerized setup is a mix of several approaches done in the past by different people covering different distributions. Git tells me that this instruction goes back to a8f80a4. I personally never followed it but could nevertheless achieve a setup via docker-compose which I've described in "my" documentation section "Setup openQA with openSUSE-based images and docker-compose".

Maybe the documentation deserves a cleanup. I usually just want to avoid removing other people's work and there are so many ways of using containers in the context of setting up openQA so it is not clear to me what other people (still) do or not.

[Martchus]

Note that last time I improved the documentation I've moved this instruction to the Fedora-specific section and generally separated the approach using Fedora-based images from the mentioned openSUSE-based one. So I can only recommend following the openSUSE-based section as it is likely more recently updated (while the Fedora section seems quite outdated to me).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.