Bug 1451460
| Summary: | error messages during ldif2db after enabling encryption on an attribute | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Roshni <rpattath> | ||||
| Component: | 389-ds-base | Assignee: | Simon Pichugin <spichugi> | ||||
| Status: | CLOSED ERRATA | QA Contact: | RHDS QE <ds-qe-bugs> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 7.4 | CC: | bsmejkal, cpelland, eg, mreynolds, nhosoi, nkinder, pasik, rmeggins, rpattath, vashirov | ||||
| Target Milestone: | rc | Keywords: | Reopened | ||||
| Target Release: | 7.7 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 389-ds-base-1.3.9.1-1.el7 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-08-06 12:58:23 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1454955 | ||||||
| Attachments: |
|
||||||
|
Description
Roshni
2017-05-16 16:58:53 UTC
Hi Roshni, Could you attach the dbout-new.ldif to this bug? 5. db2ldif -n pki-ca-rpattath-May18-CA -E -a /tmp/dbout-new.ldif -s "o=pki-ca-rpattath-May18-CA" And the steps 6 through 8 do not look correct to me... Before the step 6, could you disable SSL/startTLS? Plus instead of "8. replace the ...", enable SSL/startTLS with the permanent certs? 6. deleted this entry cn=AES,cn=encrypted attribute keys,cn=userRoot,cn=ldbm database,cn=plugins,cn=config (otherwise I was not able to restart the ldap server after replacing the temp CA with permanent CA) 7. Stop ldap server 8. replace the temporary CA and Server Cert with permanent certs. Also, if you are on Console, you may want to try this GUI. https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing-certs#renewing-certs Found the actual issue is https://bugzilla.redhat.com/show_bug.cgi?id=1451494. So closing this bug. Thanks for the update, Roshini! Reopening the bug because eventhough attribute encryption and ldif2db were successful, noticed the messages in the attachment. Created attachment 1280246 [details]
error during ldif2db
Two issues here: [1] If you use "-q" with ldif2db/db2ldif it will not log those DEBUG messages. [2] Are you concerned about: [17/May/2017:10:23:50.320813265 -0400] - ERR - attrcrypt_cipher_init - No symmetric key found for cipher AES in backend CC-NonTMS-LDAP, attempting to create one... [17/May/2017:10:23:50.371331841 -0400] - ERR - attrcrypt_cipher_init - No symmetric key found for cipher 3DES in backend CC-NonTMS-LDAP, attempting to create one... These actually should not be errors (ERR), but NOTICE. Was it [1] or [2], or both that you were concerned about? (In reply to mreynolds from comment #8) > Two issues here: > > [1] If you use "-q" with ldif2db/db2ldif it will not log those DEBUG > messages. > > [2] Are you concerned about: > > [17/May/2017:10:23:50.320813265 -0400] - ERR - attrcrypt_cipher_init - No > symmetric key found for cipher AES in backend CC-NonTMS-LDAP, attempting to > create one... > [17/May/2017:10:23:50.371331841 -0400] - ERR - attrcrypt_cipher_init - No > symmetric key found for cipher 3DES in backend CC-NonTMS-LDAP, attempting to > create one... > > These actually should not be errors (ERR), but NOTICE. > > > Was it [1] or [2], or both that you were concerned about? I was concerned about [1] because I was not able to understand what those messages meant. For [2] I knew why those messages were shown. Will the doc have to be updated to use -q to not see those DEBUG messages? (In reply to Roshni from comment #9) > > Was it [1] or [2], or both that you were concerned about? > I was concerned about [1] because I was not able to understand what those > messages meant. For [2] I knew why those messages were shown. Will the doc > have to be updated to use -q to not see those DEBUG messages? Well it is documented. "-q" is quiet mode. It is in the docs, usage, and man page. These DEBUG messages have always been present as far as I know. That being said I don't think they should be logged/displayed by default. It should be "quiet" by default, and use a verbose option to turn it on. But since this has always been the behavior, I think we can push this out to 7.5 (or 8) (In reply to mreynolds from comment #10) > (In reply to Roshni from comment #9) > > > Was it [1] or [2], or both that you were concerned about? > > I was concerned about [1] because I was not able to understand what those > > messages meant. For [2] I knew why those messages were shown. Will the doc > > have to be updated to use -q to not see those DEBUG messages? > > Well it is documented. "-q" is quiet mode. It is in the docs, usage, and > man page. These DEBUG messages have always been present as far as I know. > > That being said I don't think they should be logged/displayed by default. > It should be "quiet" by default, and use a verbose option to turn it on. > But since this has always been the behavior, I think we can push this out to > 7.5 (or 8) So do we need a bug for this and [2] in comment 8 ? (In reply to Roshni from comment #11) > (In reply to mreynolds from comment #10) > > (In reply to Roshni from comment #9) > > > > Was it [1] or [2], or both that you were concerned about? > > > I was concerned about [1] because I was not able to understand what those > > > messages meant. For [2] I knew why those messages were shown. Will the doc > > > have to be updated to use -q to not see those DEBUG messages? > > > > Well it is documented. "-q" is quiet mode. It is in the docs, usage, and > > man page. These DEBUG messages have always been present as far as I know. > > > > That being said I don't think they should be logged/displayed by default. > > It should be "quiet" by default, and use a verbose option to turn it on. > > But since this has always been the behavior, I think we can push this out to > > 7.5 (or 8) > > So do we need a bug for this and [2] in comment 8 ? We need to open a RFE to remove the "-q" option, and be "quiet' by default, and to add a "verbose" option. I would set the version to RHEL 7.5 (although it won't be until RHEL 8 that we actually address it) RHDS 9 does *not* require a -q option to not log debugging messages. We did not see this output until we were loading our data into RHDS 10 this morning. I would therefore state that this is definitely a bug, because it's not expected or reasonable behavior. More detail: -q also suppresses the output that had been included before when doing an import. So I would not suggest removing the -q option, just require a -v option to log/produce the DEBUG output. Reopening to evaluate regression in behavior. Upstream issue - https://pagure.io/389-ds-base/issue/50145 Build tested: 389-ds-base-1.3.9.1-5.el7.x86_64 db2ldif, ldif2db, db2bak and bak2db scripts now contain verbose option to display DEBUG messages. 1) # db2ldif --help ... -V - Verbose output ... # db2ldif -Z test -n userRoot -s dc=example,dc=com -a /tmp/userRoot.ldif Exported ldif file: /tmp/userRoot.ldif ldiffile: /tmp/userRoot.ldif # db2ldif -Z test -n userRoot -s dc=example,dc=com -a /tmp/userRoot.ldif -V Exported ldif file: /tmp/userRoot.ldif ldiffile: /tmp/userRoot.ldif [06/May/2019:04:18:14.484980689 -0400] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [06/May/2019:04:18:14.497231211 -0400] - INFO - ldbm_back_ldbm2ldif - export userRoot: Processed 9 entries (100%). [06/May/2019:04:18:14.498092567 -0400] - INFO - dblayer_pre_close - All database threads now stopped 2) # ldif2db --help ... -V - Verbose output ... # ldif2db -Z test -n userRoot -s dc=example,dc=com -i /tmp/userRoot.ldif importing data ... # # ldif2db -Z test -n userRoot -s dc=example,dc=com -i /tmp/userRoot.ldif -V importing data ... [06/May/2019:04:33:37.807225227 -0400] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [06/May/2019:04:33:37.818503144 -0400] - INFO - dblayer_instance_start - Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [06/May/2019:04:33:37.819716225 -0400] - INFO - check_and_set_import_cache - pagesize: 4096, available bytes 1601572864, process usage 22863872 [06/May/2019:04:33:37.820267088 -0400] - INFO - check_and_set_import_cache - Import allocates 625614KB import cache. [06/May/2019:04:33:37.843633007 -0400] - INFO - import_main_offline - import userRoot: Beginning import job... ... (skipped some messages because of length) ... [06/May/2019:04:33:38.761923077 -0400] - INFO - dblayer_pre_close - All database threads now stopped [06/May/2019:04:33:38.762728453 -0400] - INFO - import_main_offline - import userRoot: Import complete. Processed 9 entries in 1 seconds. (9.00 entries/sec) 3) # db2bak --help ... -V - Verbose output ... # db2bak -Z test Back up directory: /var/lib/dirsrv/slapd-test/bak/test-2019_05_06_04_43_01 # db2bak -Z test -V Back up directory: /var/lib/dirsrv/slapd-test/bak/test-2019_05_06_04_43_13 [06/May/2019:04:43:14.012136512 -0400] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [06/May/2019:04:43:14.022638127 -0400] - INFO - dblayer_copy_directory - Backing up file 1 (/var/lib/dirsrv/slapd-test/bak/test-2019_05_06_04_43_13/userRoot/entryrdn.db) ... (skipped some messages because of length) ... [06/May/2019:04:43:14.056350406 -0400] - INFO - dblayer_pre_close - All database threads now stopped 4) # bak2db --help ... -V - Verbose output ... # bak2db /var/lib/dirsrv/slapd-test/bak/test-2019_05_06_04_43_46 -Z test # # bak2db /var/lib/dirsrv/slapd-test/bak/test-2019_05_06_04_43_46 -Z test -V [06/May/2019:04:48:43.079721313 -0400] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [06/May/2019:04:48:43.088835243 -0400] - INFO - dblayer_delete_transaction_logs - Deleting log file: (/var/lib/dirsrv/slapd-test/db/log.0000000001) [06/May/2019:04:48:43.090990509 -0400] - INFO - dblayer_copy_directory - Restoring file 1 (/var/lib/dirsrv/slapd-test/db/userRoot/entryrdn.db) ... (skipped some messages because of length) ... [06/May/2019:04:48:43.135418802 -0400] - INFO - dblayer_pre_close - All database threads now stopped # Marking as VERIFIED. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:2152 |