Issue from tarantool/tarantool#5051
Packpack script has the following block of code:
echo "#!/bin/sh";
echo "useradd -u $(id -u) $USER";
echo "usermod -a -G sudo $USER 2>/dev/null || :";
echo "usermod -a -G wheel $USER 2>/dev/null || :";
echo "usermod -a -G adm $USER 2>/dev/null || :";
echo "export HOME=/home/$USER" ;
echo "exec chroot --userspec=$USER / \$@";
) > ${BUILDDIR}/userwrapper.sh
which takes the user's UID of the packpack runner and reuses it inside the docker image to be sure that newly created files/directories at the shared volumes will be owned by the same user on the real host outside of docker.
Sometime the docker images already have this UID in use and fails like this:
[root@b5905ebcfe5a source]# ./build/userwrapper.sh
useradd: UID 995 is not unique
chroot: invalid user
the same UID exists in Fedora 29:
[root@6b9797f4fd60 source]# grep 995 /etc/passwd
systemd-timesync:x:995:995:systemd Time Synchronization:/:/sbin/nologin
Seems that the packpack may use this user:
diff --git a/packpack b/packpack
index 11da30e..72d2ec5 100755
--- a/packpack
+++ b/packpack
@@ -132,7 +132,7 @@ if [ "${OS}" = "alpine" ]; then
else
(
echo "#!/bin/sh";
- echo "useradd -u $(id -u) $USER";
+ echo "useradd -u $(id -u) $USER 2>/dev/null || :";
echo "usermod -a -G sudo $USER 2>/dev/null || :";
echo "usermod -a -G wheel $USER 2>/dev/null || :";
echo "usermod -a -G adm $USER 2>/dev/null || :";
but not all users have needed options and in the current example it fails because of chroot not available for him:
OS=fedora DIST=29 ./packpack/packpack
+ docker pull packpack/packpack:fedora-29
fedora-29: Pulling from packpack/packpack
Digest: ...
Status: Image is up to date for packpack/packpack:fedora-29
docker.io/packpack/packpack:fedora-29
+ docker run ...
chroot: invalid user
We can set the other UID for docker, but in this way we'll put the files outside the docker using shared volume with permissions not available on the real host.
Issue from tarantool/tarantool#5051
Packpack script has the following block of code:
which takes the user's UID of the packpack runner and reuses it inside the docker image to be sure that newly created files/directories at the shared volumes will be owned by the same user on the real host outside of docker.
Sometime the docker images already have this UID in use and fails like this:
the same UID exists in Fedora 29:
Seems that the packpack may use this user:
but not all users have needed options and in the current example it fails because of chroot not available for him:
We can set the other UID for docker, but in this way we'll put the files outside the docker using shared volume with permissions not available on the real host.