[389-users] Re: Cockpit and 389
On Thu, Jul 8, 2021 at 8:34 PM Gary Waters 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. [1] https://www.port389.org/docs/389ds/download.html#centos-81-ds-14x > > 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. (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@lists.fedoraproject.org > >> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > >> 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: > >> >
[389-users] Re: Cockpit and 389
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 ? 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. (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@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-users] Re: Cockpit and 389
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. (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@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Directory Server Development Team ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
