search

phpmyadmin / docker

Docker container for phpMyAdmin
https://hub.docker.com/_/phpmyadmin
GNU General Public License v3.0
663 stars 453 forks source link

Missing libraries for gd/zip extensions #416

Closed ederuiter closed 1 year ago

ederuiter commented 1 year ago

Today I was experimenting with the phpmyadmin docker containers and came across a couple of error message from the container startup:

PHP Startup: Unable to load dynamic library 'zip.so' (tried: /usr/local/lib/php/extensions/no-debug-non-zts-20210902/zip.so (libzip.so.4: cannot open shared object file: No such file or directory), /usr/local/lib/php/extensions/no-debug-non-zts-20210902/zip.so.so (/usr/local/lib/php/extensions/no-debug-non-zts-20210902/zip.so.so: cannot open shared object file: No such file or directory))
PHP Startup: Unable to load dynamic library 'gd.so' (tried: /usr/local/lib/php/extensions/no-debug-non-zts-20210902/gd.so (libpng16.so.16: cannot open shared object file: No such file or directory), /usr/local/lib/php/extensions/no-debug-non-zts-20210902/gd.so.so (/usr/local/lib/php/extensions/no-debug-non-zts-20210902/gd.so.so: cannot open shared object file: No such file or directory))

It seems the container is missing the libraries for the zip/gd extensions (libzip.so.4, libpng16.so.16, libwebp.so.7, libjpeg.so.62, libXpm.so.4 libfreetype.so.6):

root@fa581549c630:/usr/local/lib/php/extensions/no-debug-non-zts-20210902# ldd *
bz2.so:
    linux-vdso.so.1 (0x00007ffc6bd23000)
    libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007fb4ca632000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb4ca451000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fb4ca652000)
gd.so:
    linux-vdso.so.1 (0x00007fffcfe46000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f715484a000)
    libpng16.so.16 => not found
    libwebp.so.7 => not found
    libjpeg.so.62 => not found
    libXpm.so.4 => not found
    libfreetype.so.6 => not found
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7154667000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f71548d9000)
mysqli.so:
    linux-vdso.so.1 (0x00007fffacbc3000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f491e4f8000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f491e708000)
opcache.so:
    linux-vdso.so.1 (0x00007fff16fc8000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7dad447000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7dad266000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f7dad573000)
sodium.so:
    linux-vdso.so.1 (0x00007ffeff572000)
    libsodium.so.23 => /lib/x86_64-linux-gnu/libsodium.so.23 (0x00007f8ade417000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8ade236000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8ade231000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f8ade490000)
zip.so:
    linux-vdso.so.1 (0x00007ffdf869c000)
    libzip.so.4 => not found
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f94b8914000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f94b8b0e000)

Where it gets weirder is when I double checked which version I was running. Turns out the latest image pulled from docker.io/library/phpmyadmin:latest has a different digest that the one reference in the docker hub interface :thinking:

Nevermind .. see https://github.com/docker/hub-feedback/issues/1925 :disappointed:

So according to the Dockerfile these libraries should have been installed https://github.com/phpmyadmin/docker/blob/9a7991c3f2359933d2d39e937ad275120b381ece/apache/Dockerfile#L9-L16

eric@eric-desktop:~$ docker run --rm -it phpmyadmin:latest /bin/bash
root@7a57b6b6f283:/var/www/html# dpkg -l | grep libzip
root@7a57b6b6f283:/var/www/html# dpkg -l | grep zip   
ii  bzip2                         1.0.8-5+b1                     amd64        high-quality block-sorting file compressor - utilities
ii  gzip                          1.12-1                         amd64        GNU compression utilities
root@7a57b6b6f283:/var/www/html#

^ But they are not installed inside the container :thinking:

williamdes commented 1 year ago

That's weird, let's wait for an upstream fix then ?

I had it today too

docker-phpmyadmin-1  | <b>Warning</b>:  PHP Startup: Unable to load dynamic library 'gd.so' (tried: /usr/local/lib/php/extensions/no-debug-non-zts-20210902/gd.so (libpng16.so.16: cannot open shared object file: No such file or directory), /usr/local/lib/php/extensions/no-debug-non-zts-20210902/gd.so.so (/usr/local/lib/php/extensions/no-debug-non-zts-20210902/gd.so.so: cannot open shared object file: No such file or directory)) in <b>Unknown</b> on line <b>0</b><br />
ederuiter commented 1 year ago

tldr;

In short: debian 12 usr merge caused the issue and debian knew about this problem for at least since 2017 .. and did not fix it yet.

Adding this line 

    | awk '{print $1} {system("realpath " $1)}' \

after https://github.com/phpmyadmin/docker/blob/9a7991c3f2359933d2d39e937ad275120b381ece/apache/Dockerfile#L31

Solves the problem

Explanation

I just tried building the phpmyadmin image locally and I saw this in the build output:

+ awk /=>/ { print $3 }
+ + php -r echo ini_get("extension_dir");
sort -u
+ xargs -r dpkg-query -S
+ cut -d: -f1
+ sort -u
+ xargs -rt apt-mark manual
+ ldd /usr/local/lib/php/extensions/no-debug-non-zts-20220829/bz2.so /usr/local/lib/php/extensions/no-debug-non-zts-20220829/gd.so /usr/local/lib/php/extensions/no-debug-non-zts-20220829/mysqli.so /usr/local/lib/php/extensions/no-debug-non-zts-20220829/opcache.so /usr/local/lib/php/extensions/no-debug-non-zts-20220829/sodium.so /usr/local/lib/php/extensions/no-debug-non-zts-20220829/zip.so
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libX11.so.6
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libXau.so.6
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libXdmcp.so.6
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libXpm.so.4
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libbrotlicommon.so.1
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libbrotlidec.so.1
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libbsd.so.0
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libcrypto.so.3
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libfreetype.so.6
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libjpeg.so.62
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libmd.so.0
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libpng16.so.16
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libsodium.so.23
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libwebp.so.7
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libxcb.so.1
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libzip.so.4
apt-mark manual libbz2-1.0 libc6 libgcc-s1 zlib1g
libc6 was already set to manually installed.
libgcc-s1 was already set to manually installed.
zlib1g was already set to manually installed.
libbz2-1.0 set to manually installed.
+ apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false
Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be REMOVED:
  libbrotli-dev* libbsd0* libbz2-dev* libfreetype-dev* libfreetype6*
  libfreetype6-dev* libjpeg-dev* libjpeg62-turbo* libjpeg62-turbo-dev*
  libpng-dev* libpng16-16* libpthread-stubs0-dev* libwebp-dev* libwebp7*
  libwebpdemux2* libwebpmux3* libx11-6* libx11-data* libx11-dev* libxau-dev*
  libxau6* libxcb1* libxcb1-dev* libxdmcp-dev* libxdmcp6* libxpm-dev* libxpm4*
  libzip-dev* libzip4* x11proto-dev* xorg-sgml-doctools* xtrans-dev*
  zlib1g-dev*
0 upgraded, 0 newly installed, 33 to remove and 0 not upgraded.

So problem is not that the packages don't get installed .. instead they get removed again. Digging into the problem; this seems to be the cause:

dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libzip.so.4

dpkg-query does not find the packages belonging to the libraries that the extensions depend on .. so these package are removed again :disappointed:

The underlying problem seems to be that in debian 12 the /lib dir is now a symlink to /usr/lib. And in /etc/ld.so.conf.d/x86_64-linux-gnu.conf looks like this:

# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

So it prefers /lib/x86_64-linux-gnu over /usr/lib/x86_64-linux-gnu (which are both the same thing in reality)

But even if we would fix this issue (either by removing the line /lib/x86_64-linux-gnu from /etc/ld.so.conf.d/x86_64-linux-gnu.conf or by using realpath or readlink) we have some remaining issues, because after doing that we still end up with

dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/libbz2.so.1.0
dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/libc.so.6
dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/libm.so.6
dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/libpthread.so.0
dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/libz.so.1

For these the issue is that the package uses /lib/x86_64-linux-gnu as its library install path:

root@a6628e6a9679:/# dpkg -L libbz2-1.0
/.
/lib
/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu/libbz2.so.1.0.4
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libbz2-1.0
/usr/share/doc/libbz2-1.0/changelog.Debian.amd64.gz
/usr/share/doc/libbz2-1.0/changelog.Debian.gz
/usr/share/doc/libbz2-1.0/changelog.gz
/usr/share/doc/libbz2-1.0/copyright
/lib/x86_64-linux-gnu/libbz2.so.1
/lib/x86_64-linux-gnu/libbz2.so.1.0

It seems debian knew about this issue for a very long time, but it is not fixed :disappointed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858331

So I think the only viable option is to check both the path reported by ldd and the realpath of that. Adding a line like this

| awk '{print $1} {system("realpath " $1)}' \

After this one: https://github.com/phpmyadmin/docker/blob/9a7991c3f2359933d2d39e937ad275120b381ece/apache/Dockerfile#L31

This seems to fix the problem:

libbrotli1 was already set to manually installed.
libc6 was already set to manually installed.
libgcc-s1 was already set to manually installed.
libsodium23 was already set to manually installed.
libssl3 was already set to manually installed.
zlib1g was already set to manually installed.
libbsd0 set to manually installed.
libbz2-1.0 set to manually installed.
libfreetype6 set to manually installed.
libjpeg62-turbo set to manually installed.
libmd0 set to manually installed.
libpng16-16 set to manually installed.
libwebp7 set to manually installed.
libx11-6 set to manually installed.
libxau6 set to manually installed.
libxcb1 set to manually installed.
libxdmcp6 set to manually installed.
libxpm4 set to manually installed.
libzip4 set to manually installed.
+ apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false
Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be REMOVED:
  libbrotli-dev* libbz2-dev* libfreetype-dev* libfreetype6-dev* libjpeg-dev*
  libjpeg62-turbo-dev* libpng-dev* libpthread-stubs0-dev* libwebp-dev*
  libwebpdemux2* libwebpmux3* libx11-dev* libxau-dev* libxcb1-dev*
  libxdmcp-dev* libxpm-dev* libzip-dev* x11proto-dev* xorg-sgml-doctools*
  xtrans-dev* zlib1g-dev*
0 upgraded, 0 newly installed, 21 to remove and 0 not upgraded.
williamdes commented 1 year ago

I can commit this myself, but if you want to open a pull-request that could be cool We should also add something for the Dockerfile to fail if this happens again, like a file existence check

ederuiter commented 1 year ago

:white_check_mark: I will create a PR for this and I also reported it upstream

williamdes commented 1 year ago

Thank you for all the work, it is now deployed to the hub: https://hub.docker.com/_/phpmyadmin/tags Ref: https://github.com/docker-library/official-images/pull/14960