On Thu, Jul 8, 2021 at 8:34 PM Gary Waters <gwaters-web@xxxxxxxxxxx> wrote:
I was pointed at EPEL8. It appears that the packages are being uploaded
to all the mirrors as el8.
https://download.fedoraproject.org/pub/epel/8/Modular/x86_64/
Can the RHEL9 versions be built into epel/9 instead ?
There is no EPEL9 yet. So to test the next versions of 389ds on EL there are 'next' and 'testing' streams [1].]
Looks like you're using 389-directory-server module from EPEL8 with 'testing' stream, and you have a mix of different module versions (12009 and 10764). As Mark said, you can't run different versions of 389-ds-base, lib389 and cockpit-389ds, they should all come from the same module.
Thanks so much for your help, downgrading helped.
-Gary
On 7/7/21 2:57 PM, Mark Reynolds wrote:
>
> 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
>> undefined
>> 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 work.
>>
>> Red Hat Enterprise Linux release 8.4 (Ootpa)
>>
>> 4.18.0-305.7.1.el8_4.x86_64
>>
>> 389-ds-base-libs-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64
>> 389-ds-base-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64
>> cockpit-389-ds-2.0.4-2.module_el8+12009+23f3e50a.noarch
>> python3-lib389-1.4.3.17-1.module_el8+10764+2b5f8656.noarch
>
> 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 1.4.3.22 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.
>
> Thanks,
>
> Mark
>
>
>>
>> Thanks,
>>
>> Gary
>>
>> _______________________________________________
>> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>> 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://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Viktor
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
