[SERVER-54729] MongoDB Enterprise Debian/Ubuntu packages should depend on libsasl2-modules and libsasl2-modules-gssapi-mit Created: 23/Feb/21 Updated: 29/Oct/23 Resolved: 03/Jun/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Packaging |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0-rc1, 4.2.16, 4.4.8, 5.0.2, 4.0.27 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Emilio Scalise | Assignee: | Ryan Egesdahl (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Backport Requested: |
v5.0, v4.9, v4.4, v4.2, v4.0
|
||||||||||||
| Sprint: | Dev Platform 2021-03-22, Dev Platform 2021-05-31, Dev Platform 2021-06-14 | ||||||||||||
| Participants: | |||||||||||||
| Case: | (copied to CRM) | ||||||||||||
| Description |
|
MongoDB Enterprise Debian/Ubuntu packages should depend on libsasl2-modules and libsasl2-modules-gssapi-mit. Currently they depend only on libsasl2-2 package only. This means that PLAIN (ldap) and GSSAPI (kerberos) authentication won't work on a MongoDB Enterprise installation out of the box after installing it using the apt repository. Please note that the RPM packages in our Redhat/Centos repositories are dependent on the cyrus-sasl, cyrus-sasl-plain, cyrus-sasl-gssapi so the issue is likely only for DEB packages. If the sasl modules are missing the mongo shell may throw at connection time: On the other side also the mongod server uses the library for the same authentication purposes. |
| Comments |
| Comment by Githook User [ 21/Jul/21 ] |
|
Author: {'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}Message: Some dependencies were not being captured automatically by the Debian (cherry picked from commit 829e4a097bdf3e54fab7097697242334c4a79154) |
| Comment by Githook User [ 21/Jul/21 ] |
|
Author: {'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}Message: Revert " This reverts commit 3620bc7612d48f1ca7e2030b623c51328c9d5b09. |
| Comment by Githook User [ 20/Jul/21 ] |
|
Author: {'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}Message: Some dependencies were not being captured automatically by the Debian (cherry picked from commit 829e4a097bdf3e54fab7097697242334c4a79154) |
| Comment by Githook User [ 20/Jul/21 ] |
|
Author: {'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}Message: Some dependencies were not being captured automatically by the Debian (cherry picked from commit 829e4a097bdf3e54fab7097697242334c4a79154) |
| Comment by Githook User [ 20/Jul/21 ] |
|
Author: {'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}Message: Some dependencies were not being captured automatically by the Debian (cherry picked from commit 829e4a097bdf3e54fab7097697242334c4a79154) |
| Comment by Githook User [ 20/Jul/21 ] |
|
Author: {'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}Message: Some dependencies were not being captured automatically by the Debian (cherry picked from commit 829e4a097bdf3e54fab7097697242334c4a79154) |
| Comment by Githook User [ 03/Jun/21 ] |
|
Author: {'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}Message: Some dependencies were not being captured automatically by the Debian |
| Comment by Ryan Egesdahl (Inactive) [ 18/Mar/21 ] |
|
acm The SASL dependencies, it turns out, end up being the only ones we're not expressing in the Debian packages. I am just saying that we should be as explicit about our dependencies in our Debian packaging as we are in our RPM packaging. My concern is that we don't have any way of capturing that we might have added a system library dependency which is not captured in either packaging format. There are ways to lint for that, and we should be - the Debian packaging system already does this to some extent, and we might be able to just pay better attention to those log messages. It's not a huge concern for the moment, though, which is why I'm not suggesting we do it right now. It just needs to be something we are aware of and intend to handle at some point. |
| Comment by Andrew Morrow (Inactive) [ 18/Mar/21 ] |
|
I agree there is no way for our packaging to autodetect these dependencies. If we have feature dependencies on them though, we should make the dependencies explicit in our package definitions as you suggest. I'm not as worried about things that we directly dlopen: we don't make heavy use of that in the server codebase. We have an abstraction for it, SharedLibrary, and I see it being used only for Windows to access ntdll.dll and Schannel.dll. There is some dlopen related stuff in our bundled third_party code, including in wiredtiger. But I think for the purposes of this ticket we can keep the focus on introducing requirement style dependencies on the SASL plugins that support enterprise features. |
| Comment by Ryan Egesdahl (Inactive) [ 17/Mar/21 ] |
|
Based on what I am seeing, the issue doesn't appear to be with a binary not being able to find a library but with the SASL framework being able to dlopen() a plugin. This is definitely a shortcoming of how we have our dependencies defined in the package because there never could be a way packaging systems could detect them. However, there is a second problem that we also don't state dependencies that we dlopen(), either. I think a correct solution to this ticket is to mirror the dependencies we're expressing the the RPM spec files for now to be safe, since it doesn't matter if we express dependencies that would already be captured automatically. Then, later on, we can maybe follow up with finding ways to track external dependencies the packaging systems can't detect on their own. |
| Comment by Andrew Morrow (Inactive) [ 16/Mar/21 ] |
|
ryan.egesdahl - My guess is that these libs get dlopen and that we don't actually have a DT_NEEDED dependency on them at all, directly or indirectly. |
| Comment by Ryan Egesdahl (Inactive) [ 16/Mar/21 ] |
|
This concerns me just a little because we're using ${shlibs:Depends} to tell the Debian packaging system to run dpkg-shlibdeps to include all shared libraries as dependencies which appear in DT_NEEDED on binaries. If this particular dependency is not being picked up, there may be others we aren't capturing. I'm going to do a bit of digging into why this dependency isn't being picked up automatically so I can be absolutely sure we're not missing others the same way. |