Re: 389 fails to start, libdb: BDB1546 unable to join the environment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On 4 Feb 2019, at 17:07, Zarko D <zarko@xxxxxxxxxxxx> wrote:
> 
> Thanks for reply  William, I believe I restored db with command "ipa-restore -d --data /path/ipa-data-2018-12-30-20-12-00" but 389ds still fails to start .
> 
 <snip>

> 
> ns-slapd[3533]: [03/Feb/2019:22:55:04.336762406 -0800] attrcrypt - All prepared ciphers are not available. Please disable attribute encryption.
> ns-slapd[3533]: [03/Feb/2019:22:55:04.346874658 -0800] attrcrypt - attrcrypt_unwrap_key: failed to unwrap key for cipher AES
> ns-slapd[3533]: [03/Feb/2019:22:55:04.347913178 -0800] attrcrypt - attrcrypt_cipher_init: symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped.  To recover the encrypted contents, keep the wrapped symmetric key value.
> ns-slapd[3533]: [03/Feb/2019:22:55:04.350743010 -0800] attrcrypt - attrcrypt_unwrap_key: failed to unwrap key for cipher 3DES
> ns-slapd[3533]: [03/Feb/2019:22:55:04.351680066 -0800] attrcrypt - attrcrypt_cipher_init: symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped.  To recover the encrypted contents, keep the wrapped symmetric key value.
> ns-slapd[3533]: [03/Feb/2019:22:55:04.352567754 -0800] attrcrypt - All prepared ciphers are not available. Please disable attribute encryption.
> systemd[1]: dirsrv@x-COM.service start operation timed out. Terminating.
> systemd[1]: Failed to start 389 Directory Server x-COM..
> systemd[1]: Unit dirsrv@x-COM.service entered failed state.
> systemd[1]: dirsrv@x-COM.service failed.
> _______________________________________________
> 

So this looks like an issue in the IPA restore tool. attrcrypt is deeply tied to the *nss database* in /etc/dirsrv/slapd-x-COM, however, most people fundamentally misunderstand and think it relates to the *certificates* (apparently no one listens to me :) ). I would hazard a guess the ipa backup tool dumps certs from the db but doesn’t backup the secmod.db file, which has caused this problem on restore.

So as a result, it looks like when you restored the IPA from backup, it probably re-built/removed/changed the nss db content which has effectively erased your attribute encryption key.

Now I think attribute encryption does very little to protect from real threats anyway, but I don’t control the IPA project, so I don’t know why they thought it was reasonable to enable it.

In this case, you need to use your *latest* nss db from /etc/dirsrv/slapd- (IE from BEFORE you started the restore process …), and put it back into the location. I think you need key3.db, cert8.db and secmod.db files to fix this. Provided you can copy those back in, then it “should” startup …. 

Alternately, if you want to do this “the DS way”, you could on another master ipa server do “db2ldif -r” (-r is important!), then on the restoring master in this state, do an ldif2db. There are some attr encryption parameters to check. I think you need to just disable attribute encryption in db2ldif -r call, and then it “should work” on the import. 

Finally, another option is to disable attribute encryption, and then do a full-reinint via the replication process, but given this is IPA there are lots of possible edgecases that I don’t understand here, and I don’t know the ipa tools well enough to tell you how to trigger the replication re-init. The above db2ldif process is basically the same thing anyway :) 

Otherwise, I’m sorry, but the best advice is to remove the IPA replica and rebuild it. I’m really really sorry, but it looks like IPA’s assumptions around attrcrypt here may have really hurt you :( 

—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux