fix: Add libsasl2-modules-gssapi-mit to Dockerfile

[ryanhall07]

This shared library is needed for users of the kafka plugin + kerberos+gssapi.

Without they get the error

sasl_[ssl://xxxxxxxxnet:6668/bootstrap](ssl://xxxxxxxxnet:6668/bootstrap): Cyrus/libsasl2 is missing a GSSAPI module: make sure the libsasl2-modules-gssapi-mit or cyrus-sasl-gssapi packages are installed

Fixes #10240

---

Enter [N/A] in the box, if an item is not applicable to your change.

Testing
Before we can approve your change; please submit the following in a comment:

• [ N/A] Example configuration file for the change
• [ N/A] Debug log output from testing the change

• [N/A ] Attached Valgrind output that shows no leaks or memory corruption was found

If this is a change to packaging of containers or native binaries then please confirm it works for all targets.

• [ N/A] Run local packaging test showing all targets (including any new ones) build.
• [ N/A] Set ok-package-test label to test for all targets (requires maintainer to do).

Documentation

• [ N/A] Documentation required for this feature

Backporting

• [ N/A] Backport to latest stable release.

---

Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.

[niedbalski]

@ryanhall07 Before I can merge. Please follow the contribution guidelines https://github.com/fluent/fluent-bit/blob/master/CONTRIBUTING.md#commit-changes for the commit message. Use dockerfile: xxx.

[patrick-stephens]

We should really update the sanity tests as well to start verifying these runtime dependencies ideally too.

[patrick-stephens]

Does this resolve #10240? Are there any others we should add now?

[patrick-stephens]

I presume this requires no additional build time dependencies?

[stoksc]

No, builds work fine without anything additional and with this flb finds the library

[edsiper]

to get this merged we need the change mentioned in #10308 (comment)

[stoksc]

@edsiper @niedbalski I've updated the commit to match expectations.

[patrick-stephens]

I would like to really see some tests to be honest around preventing regressions, whacking in random libraries without them makes it hard to later know/verify why those libraries are present. Can we add a build time check potentially in cmake to test for presence or some other simple dry-run approach that will verify loading the library to ensure it is present?

e.g. a config like #10240 (comment) can be used to exercise at least the library loading.

[stoksc]

@patrick-stephens I will try to add a simple test.

FWIW, I have a true end to end test for this that runs Kafka and Kerberos that works, but it is complicated.

Give me a moment to digest some stuff and clean this up and I'll ping back for review. It isn't ready yet, sorry.

[stoksc]

A question though, why is there so much divergence between production and debug's packages?

[stoksc]

I had to unwind the changes to the production target because distroless doesn't have a shell and librdkafka uses the system call to invoke kinit.

[patrick-stephens]

A question though, why is there so much divergence between production and debug's packages?

Debug needs a lot of things to help you debug things, production should only have what is required to run. In addition, "just" adding a shell and package managers requires another entire stack of dependencies - one of the reasons for distroless.

[stoksc]

@patrick-stephens lost this for a bit, is there an existing example of a test like that?

[patrick-stephens]

We have the integration tests if that's the only way but was hoping a simple dry run should work