Cockpit plugin ooops (unexpected internal error) #4671
Comments
|
Thanks for reporting the issue. It's very possible it has been fixed in a newer version (as I can not reproduce this problem on the latest version). Could you please send us the console log of the error? Press F12 in the browser, and reproduce the crashes you are seeing - it should have logged an error or two related to this. This will help us confirm if it's already been fixed. I'm not sure what the latest available version on CentOS is, but we might need to get some new builds fired off. |
|
Well the schema issue I just recently fixed. The replication one is a bit different, but it still looks familiar. Can you run: And provide the python exception stack? Thanks! |
|
DEBUG: The 389 Directory Server Configuration Tool ] ] |
|
I think this was also fixed, but I need to look at it tomorrow. Thank you very much for being so helpful in providing this information! We'll get it all fixed up shortly and get new builds out... |
|
My pleasure! Let me know if you need anything else.
Cheers!
…--
Luc Lalonde
On Monday, Mar 15, 2021 at 9:45 PM, Mark Reynolds ***@***.*** ***@***.***)> wrote:
I think this was also fixed, but I need to look at it tomorrow. Thank you very much for being so helpful in providing this information! We'll get it all fixed up shortly and get new builds out...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub (#4671 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AF6DYHL2QLNABPOKMJORB43TD2Z2NANCNFSM4ZHH4SYA).
|
|
Ok found the problem (it's new), and a fix to prevent the UI crash, etc, but I have some questions. Is this on a test system? Has replication actually been setup on this server? Basically you got into this situation because it is searching for the suffix RUV, and it's missing, or no updates have occurred on that replica (no maxcsn). Now there is nothing wrong with that, and the CLI should handle that better, but I just want to understand how we got into this situation. If you check you access log from the time you reproduced the issue, what is the RESULT line in the access log for a search using this filter: (&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone)) |
|
Here's such an entry in the access logs: [15/Mar/2021:13:30:26.001498900 -0400] conn=169 op=4 SRCH base="dc=info,dc=polymtl,dc=ca" scope=2 filter="(&(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nstombstone))" attrs="nsds50ruv" I'm no longer seeing the error in the UI this morning in the 'Monitoring->Replication'. To answer your question: I'm migrating my LDAP servers from CentOS 7 to CentOS 8. It is in production in a 4-way multimaster setup. |
|
Would it be possible to get your custom schema files? I'd like to verify that your issue is actually fixed. What I'm really looking for is to see if the X-ORIGIN keyword is used in your custom schema files, and if so, how is it being used(what value, etc). |
|
Sure thing, here you go: |
mreynolds389
added
cockpit
|
Turns out both of these UI crashes were new bugs. Thanks @scylla999 for the schema files! I'll be filing a PR shortly... |
Description: if schema attributes were missing x-origin it would crash the browser,
and in Monitor -> Replication, if the replication agreement is in an
odd state, and the lag was not computable, it could also crash the UI.
Relates: #4671
Reviewed by: mreynolds (one line commit rule)
Description: if schema attributes were missing x-origin it would crash the browser,
and in Monitor -> Replication, if the replication agreement is in an
odd state, and the lag was not computable, it could also crash the UI.
Relates: #4671
Reviewed by: mreynolds (one line commit rule)
Description: if schema attributes were missing x-origin it would crash the browser,
and in Monitor -> Replication, if the replication agreement is in an
odd state, and the lag was not computable, it could also crash the UI.
Relates: #4671
Reviewed by: mreynolds (one line commit rule)
|
Wow! Great, thanks.
…--
Luc Lalonde
On Thursday, Mar 18, 2021 at 1:22 PM, Mark Reynolds ***@***.*** ***@***.***)> wrote:
e249c0d (https://github.com/389ds/389-ds-base/commit/e249c0ddcad585db28f1bfcb197a7a69410d7dac)..72726e4 (72726e4) master -> master
b190d1f (https://github.com/389ds/389-ds-base/commit/b190d1fb89c5f5ab8f95dea7da7955a4fe107da9)..8d08168 (8d08168) 389-ds-base-1.4.4 -> 389-ds-base-1.4.4
a412c94 (https://github.com/389ds/389-ds-base/commit/a412c94f71bfad8aa79577570432e06e520c152e)..d1ec1da (d1ec1da) 389-ds-base-1.4.3 -> 389-ds-base-1.4.3
I'll get new builds done soon, and eventually they should get picked up in CentOS.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (#4671 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AF6DYHJUJML42PRVRYJRSOLTEIZFXANCNFSM4ZHH4SYA).
|
|
I've created new builds, they will soon land in epel-testing. Please try them and let us know in case of any issues. |
In the Cockpit 389-DS interface, I have a couple places that cause an 'unexpected internal error':
I have some imported schema files... Could that be the cause?
Here's what I have installed (Centos-Stream 8, kernel 4.18.0-277.el8.x86_64):
cockpit-389-ds-1.4.3.17-1.module_el8+10764+2b5f8656.noarch
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
389-ds-base-legacy-tools-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64
Thank You!
The text was updated successfully, but these errors were encountered: