This error means that the detected or requested type of NSS is DBM(legacy), but NSS built for this system doesn't provide DBM functionality.

Right. What nss package version is used here? What is 389-ds-base version as well?

I am looking at the latest nss update in Fedora 33: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c489b93b18, it has no problem with IPA installation (switch to Automated Tests tab, all IPA-related tests are green or blue).

Latest 389-ds-base (1.4.4.10) was unpushed due to GSSAPI failures: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e81d94692a but the previous version (1.4.4.9) is working just fine: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5f9a6218fa

May it be the result of previous FreeIPA installations?

Right. What nss package version is used here? What is 389-ds-base version as well?

I am looking at the latest nss update in Fedora 33: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c489b93b18, it has no problem with IPA installation (switch to Automated Tests tab, all IPA-related tests are green or blue).

Latest 389-ds-base (1.4.4.10) was unpushed due to GSSAPI failures: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e81d94692a but the previous version (1.4.4.9) is working just fine: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5f9a6218fa

rpm -qa 389-ds-base
389-ds-base-1.4.4.9-1.fc33.x86_64

dnf upgrade --advisory=FEDORA-2020-c489b93b18
Last metadata expiration check: 2:32:32 ago on Fri Jan 22 06:50:23 2021.
No security updates needed, but 15 updates available
Dependencies resolved.
Nothing to do.
Complete!

slev commented 5 hours ago
May it be the result of previous FreeIPA installations?

Good point. Yes this is a test machine and Kerberos was being tested outside of FreeIPA, to work with NIS.

I do see that ipa-server-install --uninstall does NOT remove all of the components correctly.

Is there a suggested work around?

What components were not removed correctly?

I think slev was suggestion that there was an existing IPA installation that was created while dbm support existed in NSS.

What components were not removed correctly?

Well after using --uninstall I try an installation again and it fails with:

Disabled p11-kit-proxy Synchronizing time No SRV records of NTP servers found and no NTP server or pool address was provided. Using default chrony configuration. Attempting to sync time with chronyc. Time synchronization was successful. Configuring directory server (dirsrv). Estimated time: 30 seconds [1/45]: creating directory server instance [error] AssertionError: Another instance named 'OURDOMAIN-EDU' may already exist Another instance named 'OURDOMAIN-EDU' may already exist

I think slev was suggestion that there was an existing IPA installation that was created while dbm support existed in NSS.

OK so what's the fix? Thanks for the replies so far.

Please provide additional context.

Was this a previous realm name you used with IPA? Were you experimenting with 389-ds by itself?

ipa-server-install --uninstall is idempotent and can be run again. On a blown installation it's possible that all state is not collected so re-running the uninstaller may clean additional things up.

To remove the DS instance run: remove-ds.pl -i OURDOMAIN-EDU

To really force it use -f.

Please provide additional context.

Was this a previous realm name you used with IPA? Were you experimenting with 389-ds by itself?

ipa-server-install --uninstall is idempotent and can be run again. On a blown installation it's possible that all state is not collected so re-running the uninstaller may clean additional things up.

To remove the DS instance run: remove-ds.pl -i OURDOMAIN-EDU

To really force it use -f.

Previous realm name. I'll try again as I'm getting:
ipa-server-install --uninstall -bash: /usr/sbin/ipa-server-install: No such file or directory

Configuring directory server (dirsrv). Estimated time: 30 seconds [1/45]: creating directory server instance [error] AssertionError: Another instance named 'OURDOMAIN-EDU' may already exist Another instance named 'OLDDSM-DSM-FORDHAM-EDU' may already exist The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information [root@olddsm ~]# remove-ds.pl -i OURDOMAIN.EDU

-bash: remove-ds.pl: command not found

No joy

You don't have the IPA (or 389-ds) packages installed.

Uninstalling the packages will not remove the configuration or data.

rcritten commented
You don't have the IPA (or 389-ds) packages installed.

Uninstalling the packages will not remove the configuration or data.

389-ds-base-libs-1.4.4.9-1.fc33.x86_64

Hm sure seems I do:

rpm -aq|grep 389- 389-ds-base-libs-1.4.4.9-1.fc33.x86_64 python3-lib389-1.4.4.9-1.fc33.noarch 389-ds-base-1.4.4.9-1.fc33.x86_64 389-ds-base-snmp-1.4.4.9-1.fc33.x86_64 389-ds-base-devel-1.4.4.9-1.fc33.x86_641

Did Fedora 33 change the way this program is invoked?

Yes but you lack the freeipa-server packages. It isn't strictly needed but I doubt that the 389-ds instance is the only thing left over.

For F33 use this to remove the instance.

dsctl [instance] remove [-h] [--do-it]

The state changes for ipa is saved into /var/lib/ipa/sysrestore. You can look at that to see if anything remains to be restarted. The client has a similar directory, /var/lib/ipa-client/sysrestore/

If the server has unrestored bits then re-run ipa-server-install --uninstall -U and it will attempt to restore the remaining pieces. It is safe to re-run this multiple times.

Services that aren't normally used outside a Kerberos or IPA environment that fail to start afterward can probably be ignored as they aren't normally enabled by default. As a double-check I'd ensure the service isn't set to restart automatically using systemctl but most services are not by default, httpd being an exception.

This is beyond frustrating. I think I uninstall everything and then I experience another error this time with the certificate.

[1/3]: configuring TLS for DS instance [error] CalledProcessError: CalledProcessError(Command ['/usr/bin/certutil', '-d', 'sql:/etc/dirsrv/slapd-OLDDSM2-DSM-FORDHAM-EDU/', '-A', '-n', 'OURDOMAIN.EDU IPA CA', '-t', 'CT,C,C', '-a', '-f', '/etc/dirsrv/slapd-OLDDSM2-DSM-FORDHAM-EDU/pwdfile.txt'] returned non-zero exit status 255: 'certutil: could not decode certificate: SEC_ERROR_REUSED_ISSUER_AND_SERIAL: You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert.\n') CalledProcessError(Command ['/usr/bin/certutil', '-d', 'sql:/etc/dirsrv/slapd-OURDOMAIN-EDU/', '-A', '-n', 'OURDOMAIN.EDU IPA CA', '-t', 'CT,C,C', '-a', '-f', '/etc/dirsrv/slapd-OURDOMAIN-EDU/pwdfile.txt'] returned non-zero exit status 255: 'certutil: could not decode certificate: SEC_ERROR_REUSED_ISSUER_AND_SERIAL: You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert.\n') The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information

So should I delete /etc/dirsrv/slapd-OURDOMAIN-EDU and try again?

Edit: ipa-server-install --uninstall -U succeeded, so perhaps the -U option helped.

However the install failed again at the original place:

[7/10]: upgrading server Upgrade failed with NSS is built without support of the legacy database(DBM) [error] RuntimeError: NSS is built without support of the legacy database(DBM) [cleanup]: stopping directory server [cleanup]: restoring configuration Update failed: NSS is built without support of the legacy database(DBM) The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information

Can you list the files in /etc/dirsrv/slapd-OURDOMAIN-EDU/*.db?

Just tried uninstalling, ran it a few times for good measure. Reinstall errors at same place.
-rw-r----- 1 dirsrv root 28672 Jan 26 22:19 /etc/dirsrv/slapd-OURDOMAIN-EDU/cert9.db
-rw-r----- 1 dirsrv root 36864 Jan 26 22:19 /etc/dirsrv/slapd-OURDOMAIN-EDU/key4.db

Can you compress and attach /var/log/ipaserver-install.log?

Not sure if attachments work here but I also have it at this URL

So your files in /etc/dirsrv use the NSS sqlite format so this isn't the source of the issue.

The actual source of the error is getting lost in the re-raising of errors but can you see if there are any *.db files in /etc/httpd/alias (notably cert8.db and/or key3.db)? If so that's the culprit. mod_nss uses /etc/httpd/alias for its NSS datatabase.

If that doesn't exist can you try running: ipa-server-upgrade

and attach a compressed /var/log/ipaupgrade.log?

Assuming it can run at all given the quasi-installed state I think it will fail in the same/similar way but provide a better traceback.

Yes those 2 filenames are there, they appear to be older files. Should I delete them?

ls -l /etc/httpd/alias
total 84
-rw-r----- 1 root apache 65536 Jan 8 2018 cert8.db
-rw-------. 1 root root 4614 Jan 25 2014 install.log
-rw------- 1 root root 32 Jan 26 22:21 ipasession.key
-rw-r----- 1 root apache 32768 Jan 8 2018 key3.db
lrwxrwxrwx 1 root root 33 Jul 28 22:57 libnssckbi.so -> ../../..//usr/lib64/libnssckbi.so
-rw-r----- 1 root apache 16384 Jan 8 2018 secmod.db

ipa-server-upgrade
IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
IPA is not configured on this system.
The ipa-server-upgrade command failed.

edit:

ls -l /var/log/ipaupgrade.log
ls: cannot access '/var/log/ipaupgrade.log': No such file or directory

Theoretically there could be key material and/or certs stored in there so I think it's safer to move the *.db out of the directory (or just rename the whole directory). If you aren't using mod_nss and it is still installed I'd recommend removing it it before trying ipa-server-install again.

As I had feared about ipa-server-upgrade the installation hadn't proceeded far enough for it to see the partial install so refused to run.

Would this help to see the exact NSS directory?

diff --git a/ipapython/certdb.py b/ipapython/certdb.py
index 8e0faffdd0a..a18c825f7e2 100644
--- a/ipapython/certdb.py
+++ b/ipapython/certdb.py
@@ -265,7 +265,8 @@ class NSSDatabase:

         if dbtype == "dbm" and not nss_supports_dbm():
             raise ValueError(
-                "NSS is built without support of the legacy database(DBM)"
+                "NSS is built without support of the legacy database(DBM)",
+                f"NSS directory: '{nssdir}'",
             )

         if nssdir is None:

None in the case of tmpdir.

Theoretically there could be key material and/or certs stored in there so I think it's safer to >
move the *.db out of the directory (or just rename the whole directory). If you aren't using > > > mod_nss and it is still installed I'd recommend removing it it before trying ipa-server-install >
again.

Well that was it! We used NIS and had to use /etc/nsswitch.conf on this server to perhaps some checking of that is in order?

Just these warnings:

The ipa-client-install command was successful

DNS query for ourdomain.edu. RdataType.A failed: All nameservers failed to answer the query ourdomain.edu. IN A: Server 127.0.0.1 UDP port 53 answered SERVFAIL

unable to resolve host name ourdomain.edu. to IP address, ipa-ca DNS record will be incomplete

Setup complete

It wouldn't be related to NIS. When the mod_nss package is installed it creates a database and issues a self-signed cert in a similar that mod_ssl does. I'm guessing this F33 is upgraded from a previous release.

slev, yes, I'm planning on doing that along with seeing if I can catch and ignore this error during the upgrade process. I'll need to think through the implications carefully as it could probably trip someone up who upgrades from F28 directly to F33 for example (a terrible idea in general but people try things like this).

I'm guessing this F33 is upgraded from a previous release.

Yes that's correct.

Thanks for your patience and getting this working. Hopefully I've given you enough to make the installation/uninstallation process better for future users.

@rcritten, I want just to note that if NSS is built without DBM support, then the migration DBM->SQL is impossible.

@slev yep. sqlite has been the default for a couple of Fedora releases now so I think it would only affect very old systems upgrading directly to F33+. I have it spit out as a warning now as there isn't anything we can do. Let it plow ahead and see what happens.

If this ever indeed did happen where the RA cert was in an old format database the user would need a container or another system to pull the cert out manually.

https://github.com/freeipa/freeipa/pull/5489

master:

• 693ac70 Report the NSS database directory if it cannot be opened
• 43222cb Ignore database errors when trying to extract ipaCert on upgrade

master:

• bd7214b ipatests: Update NSSDatabase DBM test on non-DBM-capable installs

ipa-4-9:

• b71c0c6 Report the NSS database directory if it cannot be opened
• 348d4ee Ignore database errors when trying to extract ipaCert on upgrade
• 7f1849e ipatests: Update NSSDatabase DBM test on non-DBM-capable installs

@rcritten the commits have been pushed on master and ipa-4-9 branch, does it mean we can close the issue? From your comment I understand that the patch doesn't fix the issue but prints additional messages, not sure what to do with this ticket...

Closing after confirmation on IRC with @rcritten