shreemaan-abhishek opened a new pull request, #627:
URL: https://github.com/apache/apisix-docker/pull/627
### What this fixes
The `saml-auth` plugin added in APISIX 3.17.0 (apache/apisix#13346) pulls in
the `lua-resty-saml` rock. Its native `saml.so` dynamically links
`libxml2.so.2` and `libxslt.so.1`, which are **not installed** in the runtime
images. As a result every worker logs this on startup and the plugin cannot be
used:
```
[error] load_plugin(): failed to load plugin [saml-auth] err: error loading
module 'saml'
from file '/usr/local/apisix/deps/lib/lua/5.1/saml.so':
libxml2.so.2: cannot open shared object file: No such file or directory
```
Reproduce on the published image:
```
docker run --rm --entrypoint sh apache/apisix:3.17.0-debian \
-c "ldd /usr/local/apisix/deps/lib/lua/5.1/saml.so"
# libxml2.so.2 => not found
# libxslt.so.1 => not found
```
### Fix
Install `libxml2` + `libxslt1.1` (debian/ubuntu) and `libxml2` + `libxslt`
(redhat) as runtime dependencies. After the fix, `ldd` resolves both libraries
and APISIX boots with no `saml-auth` load errors.
### Why CI didn't catch it
The `Test route` step checked `compose/apisix_log/error.log`, but that file
never exists (the container's `error.log` is symlinked to stderr), so `grep ...
&& exit 1` always short-circuited and startup errors slipped through green.
This PR makes the step grep the container logs instead, so a failing plugin
load now fails the build.
### Verification
Built the patched debian image locally and booted it against etcd:
```
ldd .../saml.so # libxml2.so.2 and libxslt.so.1 both resolved
docker logs <apisix> # 0 "failed to load plugin [saml-auth]" lines
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
