On 7/7/21 5:18 PM, Gary Waters wrote:
> Hello Everyone,
> I have been having trouble with Cockpit and 389 since I upgraded to
> 389-ds-base to 1.4.X from 1.3.X.
> I was initially having trouble with rendering the replication page but
> I have determined that the monitoring page is not rendering as well.
> (or maybe I am not waiting log enough, I waited 15 minutes).
> Has anyone had any luck on making this work again ?
> Ctrl-Shift-J had errors about some CSP stuff, but I allowed everything
> from the url via Chrome and Brave Browser settings, so now the only
> error (apparently a big one for both pages) is
> index.js:117 Uncaught TypeError: Cannot read property 'length' of
> at Function.<anonymous> (index.js:117)
> at cockpit.js:1
> at cockpit.js:1
> at A (cockpit.js:1)
> I tried upgrading to the latest cockpit 389 plugin but it still doesnt
> Red Hat Enterprise Linux release 8.4 (Ootpa)
This is definitely not supported. Not even sure how you even got 2.0.4
for RHEL 8 (since that is the RHEL 9 version). Anyway you can NOT run
different versions of 389-ds-base, python-lib389 and cockpit-389-ds.
They are very tightly interconnected. The UI uses lib389 to perform all
its operations, and lib389 is vastly different in 2.0.4 verses 1.4.3.
Yes some of it might work, but most of it probably won't.
If these were the same version, then I can still not explain this
behavior, and it is not a known issue. Is your browser/client far away
from the server hosting the server/cockpit? Over a WAN? For me the
entire UI loads in 10-15 seconds (and each tab only takes a few seconds
to load), but I am not going over a WAN to connect to it.
If you get all the components to the same version then I'd be interested
in seeing the console log from the chrome browser (we do not test
Brave), just Firefox and Chrome. Make sure the console logging (F12)
is including the timestamp, then try and capture these "rendering
issues" and send us the logging please. The UI logs all lib389/CLI
commands it uses to gather the UI data, so we should see what commands
are run when things are not working. You can even copy and paste those
exact commands (dsconf ...) from the console logging on the server
machine and you can test if they respond quickly when run locally.
But... The UI is a single page web page app that is a Cockpit plugin.
There is much performance improvements we can make to it on the DS side
of things. Now the UI that ships with 1.4.3 "should" be minimized (aka
production ready). Can you send the "ls" output of:
/usr/share/cockpit/389-console/ There is a slim chance you have a
non-production version of the UI since you are on a older version of
1.4.3 (the latest for RHEL 8 is 188.8.131.52 or higher). So upgrading to
the latest 1.4.3 version is another option you should look into.
Otherwise I suspect there is a network issue at play, and the console
logging (F12) might help figure out what the UI is doing while there are
these rendering issues.
Again don't gather any on this information until all the 389 components
are at the same version.
> 389-users mailing list -- firstname.lastname@example.org
> To unsubscribe send an email to email@example.com
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> Do not reply to spam on the list, report it:
Directory Server Development Team
389-users mailing list -- firstname.lastname@example.org
To unsubscribe send an email to email@example.com
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://firstname.lastname@example.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure