[389-users] Re: Failed to get the default state of cipher
> On 26 Jun 2020, at 05:08, Ghiurea, Isabella > wrote: > > William thank you for reply, bellow is output for certl cmd for this host > with error( Failed to get the default state of cipher) > To deploy almost identical ldap hosts , the Sys Admin here is using Puppet > but unfortunelly are always issues with rpms version mismatch and cfg , can > you suggest another solution to deploy multiple ldap hosts all running same > version and almost same cfg , only diff in ldap hosts is the name of DS > instance aka :ldap* Yeah, you can't do that easily. If you want "repeatable" installs, you should look at docker images for 389 instead, because you can just add files into /data/config after the first run, or you'll need to run dscreate on every host. Else we can't guarantee you've "taken all the steps" properly, which leaves your instance in unknown or unsupportable configurations like this :( For example, in your nssdb there are hidden generated secrets that 389 uses to encrypt attributes like replication secrets. So copying dse.ldif from one host to another means you won't be able to access those secrets because the nss db may differ. There are stacks of other examples like this. Alternately, you need puppet to run dscreate and use from-file + a series of post install dsctl commands. In the past I considered making an ansible module, but the interest evaporated really. :( sorry about that, > > Here is the output s per your request: > certutil -L -d /etc/dirsrv/slapd-ldap2/ > > Certificate Nickname Trust Attributes > > SSL,S/MIME,JAR/XPI > > n1-2.xxx.xxx.xxu,u,u > XX Internal Root CACT,, > XX Internal CA CT,, > > Regards > Isabella > > From: William Brown > Subject: [389-users] Re: 389-DS Failed to get the default state of > cipher > To: "389-users@lists.fedoraproject.org" > <389-users@lists.fedoraproject.org> > Message-ID: <87b2eb8a-ba13-4f9b-979e-252d5423c...@suse.de> > Content-Type: text/plain; charset=utf-8 > > > > > > we have another host with same version and suppose same cfg but never > > saw the error, > > > > [24/Jun/2020:09:22:54.687024072 -0700] - ERR - Security Initialization > > - _conf_setallciphers - Failed to get the default state of cipher > > (null) > > I'm curious - how did you make a host with the same config? Normally with 389 > you need to configure both individually to look the same but you can't > copy-paste config files etc. > > My guess here is that perhaps your nss db isn't configured properly, so I'd > want to see the output of certutil -L -d /etc/dirsrv/slapd-/ on the > affected host. > > — > Sincerely, > > William Brown — Sincerely, William Brown Senior 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
[389-users] Re: Provider Node Not Restarting Following Failed Schema Update
Trevor, I have not seen this before, but I also have not seen what happens when you add invalid schema. But to try and get the server back up and running try removing the /var/lib/dirsrv/slapd-YOUR_INSTANCE/db/__db.00* files. So make sure the ns-slapd process is not running, kill it if you have to, then remove those files and try starting it back up. HTH, Mark On 6/25/20 1:42 PM, Fong, Trevor wrote: Hi There, We tried to dynamically a new schema dynamically using /usr/lib64/dirsrv/slapd-eldapp1/schema-reload.pl Unfortunately, (and unknown to us at the time) the objectClass definition misspelt a couple of the attribute names. The schema reload process should have picked that up and refused it, but it didn't and so proceeded to update entries using the new schema. That's when we started getting errors like the following in the error log: [19/Jun/2020:10:28:08.390882389 -0700] - ERR - libdb - BDB0151 fsync: Input/output error [19/Jun/2020:10:28:08.399523527 -0700] - ERR - libdb - BDB0151 fsync: Input/output error [19/Jun/2020:10:28:08.404890880 -0700] - ERR - libdb - BDB0151 fsync: Input/output error [19/Jun/2020:10:28:08.430284251 -0700] - ERR - libdb - BDB0151 fsync: Input/output error [19/Jun/2020:10:28:08.466371449 -0700] - ERR - libdb - BDB0151 fsync: Input/output error [19/Jun/2020:10:28:08.495859651 -0700] - ERR - libdb - BDB0151 fsync: Input/output error [19/Jun/2020:10:28:08.522007224 -0700] - ERR - libdb - BDB0151 fsync: Input/output error [19/Jun/2020:10:28:08.546930415 -0700] - ERR - libdb - BDB4519 txn_checkpoint: failed to flush the buffer cache: Input/output error [19/Jun/2020:10:28:08.569781853 -0700] - CRIT - checkpoint_threadmain - Serious Error---Failed to checkpoint database, err=5 (Input/output error) I tried restarting dirsrv and that's when it started giving errors about the unknown (misspelt) attributes in the new objectClass. I fixed those errors in the schema and restarting dirsrv. I saw the following message in the error log: NOTICE - dblayer_start - Detected Disorderly Shutdown last time Directory Server was running, recovering database. There was no further log, but the CPU utilization for ns-slapd was at 99.9% so I just let it run over night hoping that it wasn't stuck in a loop. But there was no improvement the next morning, so I ordered a RAM increase from 4 GB à16 GB hoping that would fix it, I let it run for a while with no indication of progress. I also tried to run db2ldif to try to dump the db to an ldif file, but got the same "recovering database" message. That's where it is now - I'll let it run for a few hours and hope it does something. Would anyone be able to offer any further advice? Is there any way to see how it's getting along with the database recovery? Is this db well and truly hosed? Unfortunately this system was spec'd for development so no backups were running so recovery from backup is not an option. Thanks, Trev ___ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org -- 389 Directory Server Development Team ___ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
[389-users] Re: Failed to get the default state of cipher
William thank you for reply, bellow is output for certl cmd for this host with error( Failed to get the default state of cipher) To deploy almost identical ldap hosts , the Sys Admin here is using Puppet but unfortunelly are always issues with rpms version mismatch and cfg , can you suggest another solution to deploy multiple ldap hosts all running same version and almost same cfg , only diff in ldap hosts is the name of DS instance aka :ldap* Here is the output s per your request: certutil -L -d /etc/dirsrv/slapd-ldap2/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI n1-2.xxx.xxx.xxu,u,u XX Internal Root CACT,, XX Internal CA CT,, Regards Isabella From: William Brown Subject: [389-users] Re: 389-DS Failed to get the default state of cipher To: "389-users@lists.fedoraproject.org" <389-users@lists.fedoraproject.org> Message-ID: <87b2eb8a-ba13-4f9b-979e-252d5423c...@suse.de> Content-Type: text/plain; charset=utf-8 > > we have another host with same version and suppose same cfg but never > saw the error, > > [24/Jun/2020:09:22:54.687024072 -0700] - ERR - Security Initialization > - _conf_setallciphers - Failed to get the default state of cipher > (null) I'm curious - how did you make a host with the same config? Normally with 389 you need to configure both individually to look the same but you can't copy-paste config files etc. My guess here is that perhaps your nss db isn't configured properly, so I'd want to see the output of certutil -L -d /etc/dirsrv/slapd-/ on the affected host. - Sincerely, William Brown ___ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
[389-users] Provider Node Not Restarting Following Failed Schema Update
Hi There, We tried to dynamically a new schema dynamically using /usr/lib64/dirsrv/slapd-eldapp1/schema-reload.pl Unfortunately, (and unknown to us at the time) the objectClass definition misspelt a couple of the attribute names. The schema reload process should have picked that up and refused it, but it didn't and so proceeded to update entries using the new schema. That's when we started getting errors like the following in the error log: [19/Jun/2020:10:28:08.390882389 -0700] - ERR - libdb - BDB0151 fsync: Input/output error [19/Jun/2020:10:28:08.399523527 -0700] - ERR - libdb - BDB0151 fsync: Input/output error [19/Jun/2020:10:28:08.404890880 -0700] - ERR - libdb - BDB0151 fsync: Input/output error [19/Jun/2020:10:28:08.430284251 -0700] - ERR - libdb - BDB0151 fsync: Input/output error [19/Jun/2020:10:28:08.466371449 -0700] - ERR - libdb - BDB0151 fsync: Input/output error [19/Jun/2020:10:28:08.495859651 -0700] - ERR - libdb - BDB0151 fsync: Input/output error [19/Jun/2020:10:28:08.522007224 -0700] - ERR - libdb - BDB0151 fsync: Input/output error [19/Jun/2020:10:28:08.546930415 -0700] - ERR - libdb - BDB4519 txn_checkpoint: failed to flush the buffer cache: Input/output error [19/Jun/2020:10:28:08.569781853 -0700] - CRIT - checkpoint_threadmain - Serious Error---Failed to checkpoint database, err=5 (Input/output error) I tried restarting dirsrv and that's when it started giving errors about the unknown (misspelt) attributes in the new objectClass. I fixed those errors in the schema and restarting dirsrv. I saw the following message in the error log: NOTICE - dblayer_start - Detected Disorderly Shutdown last time Directory Server was running, recovering database. There was no further log, but the CPU utilization for ns-slapd was at 99.9% so I just let it run over night hoping that it wasn't stuck in a loop. But there was no improvement the next morning, so I ordered a RAM increase from 4 GB --> 16 GB hoping that would fix it, I let it run for a while with no indication of progress. I also tried to run db2ldif to try to dump the db to an ldif file, but got the same "recovering database" message. That's where it is now - I'll let it run for a few hours and hope it does something. Would anyone be able to offer any further advice? Is there any way to see how it's getting along with the database recovery? Is this db well and truly hosed? Unfortunately this system was spec'd for development so no backups were running so recovery from backup is not an option. Thanks, Trev ___ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
