389 Directory Server Manager not show even cockpit-389-ds is installed

[Kelvin Yeung]

[ Impact ]

It is expected that there will be minimal impact by updating the package from 2.0.15 to 2.0.16. I have reviewed the upstream commits between the two versions and the only commits are ones that close upstream bugs. No new features are included and no functionality is changed. The biggest difference between 2.0.15 and 2.0.16 is the inclusion of the missing files for cockpit-389-ds. Version 2.0.15 ships an empty package for cockpit-389-ds which causes the plugin to be non-functional.

[ Test Plan ]

1. Install the following packages on a fresh installation of Jammy
 - 389-ds
 - cockpit
 - cockpit-389-ds

2. Ensure that cockpit is enabled and listening on port 9090

3. Open a browser and connect to the system on port 9090

4. Login to the cockpit web application

5. Verify that the menu on the left includes the 389 Directory Server link

6. Click the link and use the plugin to create a new instance of 389-ds

[ Where problems could occur ]

While issues are unlikely, there are a number of places where bug fixes include minor changes to the cockpit UI. If users rely on scripts for automated testing/automation (e.g. selenium), these changes could cause those tests/automations could break.

[ Other Info ]

 * This change only applies to jammy as releases after jammy have a newer
   version of 389-ds-base that includes the missing files

[ Original Bug Description ]

In 22.04 LTS, cockpit-389-ds will also install when install 389-ds

```
# apt info 389-ds
Package: 389-ds
Version: 2.0.15-1
Priority: optional
Section: universe/net
Source: 389-ds-base
Origin: Ubuntu
Maintainer: Ubuntu Developers <email address hidden>
Original-Maintainer: Debian FreeIPA Team <email address hidden>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 49.2 kB
Depends: 389-ds-base, cockpit-389-ds
Homepage: https://directory.fedoraproject.org
Download-Size: 10.8 kB
APT-Manual-Installed: yes
APT-Sources: http://azure.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
Description: 389 Directory Server suite - metapackage
 Based on the Lightweight Directory Access Protocol (LDAP), the 389
 Directory Server is designed to manage large directories of users and
 resources robustly and scalably.
 .
 This is a metapackage depending on the LDAPv3 server and a Cockpit UI plugin
 for administration.
```

After cockpit-389-ds install, 389 Directory Server suppose could be administrated via Cockpit but "389 Directory Server" does not shown after login Cockpit.

After check the files installed via cockpit-389-ds, it seems missing some files inside /usr/share/cockpit/389-console such as /usr/share/cockpit/389-console/manifest.json, /usr/share/cockpit/389-console/index.html, etc.

```
# dpkg --listfiles cockpit-389-ds
/.
/usr
/usr/share
/usr/share/cockpit
/usr/share/cockpit/389-console
/usr/share/doc
/usr/share/doc/cockpit-389-ds
/usr/share/doc/cockpit-389-ds/copyright
/usr/share/metainfo
/usr/share/metainfo/389-console
/usr/share/metainfo/389-console/org.port389.cockpit_console.metainfo.xml
/usr/share/doc/cockpit-389-ds/changelog.Debian.gz
```

Thank you for your time!

[jf Desir (ziongate)]

Hi all,

I have the same issue

regards,

[jf Desir (ziongate)]

A solution is here: https://<email address hidden>/msg1854674.html

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "lp2008441.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Heitor Alves de Siqueira (halves)]

Thank you for taking the time to fix this one, Tom!

The debdiff you submitted is quite big. If I'm understanding correctly, your intention was to submit a new upstream microrelease into the Ubuntu repos. While the SRU policy does foresee the case of a bugfix-only microrelease, I'm not fully confident that this is what we're dealing with here. Although I'm not an expert on the cockpit and 389-ds packages, there are a few things that do stand out from an initial review:
- there's additions of new rust depedencies (from the cargo.lock file)
- several requirements seem to have gone through version changes
- new vendor files being added (like "wasi", "winapi" and "unicode-xid")
- introduces new "acl" requirement in the spec file (this is explicitly called out a a no-go in the SRU Policy, as it'd introduce structural changes to the build system)

Furthermore, the upstream commit log between 2.0.15 and 2.0.16 [1] lists 44 commits, which is quite a bit for a microrelease. I'd really like us to double-check whether all 44 commits are needed for fixing this bug. Some of the commits don't seem related to the original issue (e.g. [2]).

It'd be great if we could either:
1) Provide /strong/ justification (and testing) in favor of pushing the 2.0.16 microrelease
2) Narrow down the (few?) responsible commits and backport only those to Jammy

Considering there's no SRU exception for this package, I'd expect significant resistance to the first option, unless we have significant motive as well :)

Ultimately, if the underlying problem is missing UI files, could this actually be a packaging or build-time bug? That won't have a corresponding upstream commit, and the original description mentioning index.html and manifest.json files does seem to hint at this (these don't seem to be in the 2.0.15..2.0.16 diff either).

[0] https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases
[1] https://github.com/389ds/389-ds-base/compare/389-ds-base-2.0.15...389-ds-base-2.0.16
[2] https://github.com/389ds/389-ds-base/commit/f46ab49c9f06