infra/tickets

Fork 1

Critical error in IPA from ipa-healthcheck #13323

New issue

Closed

opened 2026-05-05 11:17:38 +00:00 by gwmngilfen · 7 comments

gwmngilfen commented

2026-05-05 11:17:38 +00:00

Member

Description of request

I'm setting up monitoring of IPA via ipa-healthcheck. This tool lists a lot of warnings (>30 atm) which we may get to, but it also lists one critical issue which I'd like to fix, because then we can have monitoring of "critical > 0".

The issue is reported as this:

# ipa-healthcheck --output-type json --failures-only --severity CRITICAL
[
  {
    "source": "ipahealthcheck.ds.backends",
    "check": "BackendsCheck",
    "result": "CRITICAL",
    "uuid": "bc3fc47b-eadf-4b32-b24b-d3405a8f40bc",
    "when": "20260501121510Z",
    "duration": "0.117271",
    "kw": {
      "key": "DSVIRTLE0001",
      "items": [
        "Virtual Attributes",
        "dc=stg,dc=fedoraproject,dc=org",
        "Class Of Service (COS)",
        "cosAttribute: nsaccountlock"
      ],
      "msg": "You should not index virtual attributes, and as this will break searches that\nuse the attribute in a filter."
    }
  }
]

Note the dc=stg part, this is from stg, however a similar issue is in the prod instance too.

@abompard any ideas?

### Description of request I'm setting up monitoring of IPA via ipa-healthcheck. This tool lists a *lot* of warnings (>30 atm) which we may get to, but it also lists one critical issue which I'd like to fix, because then we can have monitoring of "critical > 0". The issue is reported as this: ``` # ipa-healthcheck --output-type json --failures-only --severity CRITICAL [ { "source": "ipahealthcheck.ds.backends", "check": "BackendsCheck", "result": "CRITICAL", "uuid": "bc3fc47b-eadf-4b32-b24b-d3405a8f40bc", "when": "20260501121510Z", "duration": "0.117271", "kw": { "key": "DSVIRTLE0001", "items": [ "Virtual Attributes", "dc=stg,dc=fedoraproject,dc=org", "Class Of Service (COS)", "cosAttribute: nsaccountlock" ], "msg": "You should not index virtual attributes, and as this will break searches that\nuse the attribute in a filter." } } ] ``` Note the `dc=stg` part, this is from stg, however a similar issue is in the prod instance too. @abompard any ideas?

smoliicek added the

labels

2026-05-05 19:04:01 +00:00

kevin was assigned by smoliicek

2026-05-05 19:04:08 +00:00

kevin added this to the Sprint ( 2026-05-04 to 2026-05-18 ) project

2026-05-05 19:07:26 +00:00

kevin commented

2026-05-05 20:43:54 +00:00

Owner

ok, claude spewed some nice sounding things, but I don't trust what it found and do not want to do what it suggested.

I think we need to ping the ipa folks or file a issue with them.

ok, claude spewed some nice sounding things, but I don't trust what it found and do not want to do what it suggested. I think we need to ping the ipa folks or file a issue with them.

abbra commented

2026-05-06 03:55:32 +00:00

this is coming from 389-ds healthcheck, so please open an issue to 389-ds.

vashirov commented

2026-05-07 18:34:56 +00:00

The healthcheck is correct, nsAccountLock should not be indexed.

kevin commented

2026-05-07 20:38:08 +00:00

Owner

Sure... but that brings up two other questions:

How did this get indexed? If we drop the index will it just appear again?
How can we drop the index safely. Does that need doing on all servers?

Sure... but that brings up two other questions: 1. How did this get indexed? If we drop the index will it just appear again? 2. How can we drop the index safely. Does that need doing on all servers?

vashirov commented

2026-05-07 21:15:57 +00:00

It's not indexed by default by 389DS or FreeIPA. Someone explicitly added it. You can check createTimestamp in the index entry in cn=config to find out when it was created. And if you have access logs from that time, find ADD operation, something like

[07/May/2026:21:07:07.096872394 +0000] conn=1 op=11 ADD dn="cn=nsAccountLock,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config"

It won't get recreated by itself, unless you have some kind of automation that can bring it back.

It needs to be done on all servers. Run

dsconf <instance> backend index delete --attr nsaccountlock <backend_name>

See https://github.com/389ds/389-ds-base/issues/3615 for some background about this warning.

1. It's not indexed by default by 389DS or FreeIPA. Someone explicitly added it. You can check `createTimestamp` in the index entry in `cn=config` to find out when it was created. And if you have access logs from that time, find ADD operation, something like ``` [07/May/2026:21:07:07.096872394 +0000] conn=1 op=11 ADD dn="cn=nsAccountLock,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" ``` It won't get recreated by itself, unless you have some kind of automation that can bring it back. 2. It needs to be done on all servers. Run ``` dsconf <instance> backend index delete --attr nsaccountlock <backend_name> ``` See https://github.com/389ds/389-ds-base/issues/3615 for some background about this warning.

kevin commented

2026-05-07 22:10:48 +00:00

Owner

Thanks much @vashirov

Alas, it doesn't seem to be in logs, it may have been done when we move datacenters...

ok. I ran 'dsconf STG-FEDORAPROJECT-ORG backend index delete --attr nsaccountlock userroot' on all the servers.

All of them are now clear of critical stuff. ;)

Thanks much @vashirov Alas, it doesn't seem to be in logs, it may have been done when we move datacenters... ok. I ran 'dsconf STG-FEDORAPROJECT-ORG backend index delete --attr nsaccountlock userroot' on all the servers. All of them are now clear of critical stuff. ;)

kevin closed this issue

2026-05-07 22:10:49 +00:00

abompard commented

2026-05-11 08:55:48 +00:00

Member

This is coming from this block in freeipa-fas, I'll remove it.

This is coming from [this block in freeipa-fas](https://github.com/fedora-infra/freeipa-fas/blob/29f091130ed70d962f6835210d129fb65660378a/updates/89-fas.update#L106), I'll remove it.