> On 4 Feb 2019, at 17:07, Zarko D <za...@etcfstab.com> 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@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
