Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1860291

Summary: db2ldif does not display non existing file error as command output
Product: Red Hat Directory Server Reporter: sgouvern
Component: 389-ds-baseAssignee: mreynolds
Status: CLOSED ERRATA QA Contact: LDAP QA Team <idm-ds-qe-bugs>
Severity: medium Docs Contact: Evgenia Martynyuk <emartyny>
Priority: high    
Version: 11.3CC: aadhikar, idm-ds-dev-bugs, mreynolds, pasik, spichugi, tbordaz, vashirov
Target Milestone: DS12.2Keywords: Triaged
Target Release: dirsrv-12.2   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: sync-to-jira
Fixed In Version: redhat-ds-12-9020020230314150545.1674d574 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-30 09:40:35 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:

Description sgouvern 2020-07-24 09:18:33 UTC
Description of problem:
When a "Can't open file" type of error occurs, db2ldif command line does not display the error. 
Seeing the ldiffile path displayed is misleading and makes think that the file as actually been created.
Nothing shows that the operation couldn't be performed, unless looking at the errors log


Version-Release number of selected component (if applicable):
389-ds-base-1.4.3.8-4.module+el8.3.0+7193+dfd1e8ad.x86_64


How reproducible:
always

Steps to Reproduce:
automated test export/export_test.py::test_db2ldif_with_non_accessible_ldif_file_path will be sent soon as PR for review
or
1. import data in "dc=example,dc=com"
2. stop the ds instance
3. run # db2ldif -Z standalone1 -s "dc=example,dc=com" -a ldif/db.ldif

Actual results:
# db2ldif -Z standalone1 -s "dc=example,dc=com" -a ldif/db.ldif
Exported ldif file: /mnt/tests/rhds/tests/upstream/ldif/db.ldif
[24/Jul/2020:04:55:06.947184501 -0400] - INFO - slapd_exemode_db2ldif - db2ldif - Backend Instance(s): 
[24/Jul/2020:04:55:06.952243624 -0400] - INFO - slapd_exemode_db2ldif - db2ldif - userRoot
ldiffile: /mnt/tests/rhds/tests/upstream/ldif/db.ldif



Expected results:
The error should be displayed as command output, in addition of info already displayed :
[24/Jul/2020:04:55:06.976484643 -0400] - ERR - bdb_db2ldif - db2ldif: userRoot: can't open /mnt/tests/rhds/tests/upstream/ldif/db.ldif: 2 (No such file or directory) while running as user "dirsrv"

It should be clear that ldiffile: /mnt/tests/rhds/tests/upstream/ldif/db.ldif couldn't be created and that the operation failed




Additional info:

Comment 1 sgouvern 2020-07-31 08:20:34 UTC
Not having the error collected in output stream leads to lib389 debug message being incomplete :
DEBUG:lib389:Command: /usr/sbin/ns-slapd db2ldif -D /etc/dirsrv/slapd-standalone1 -n userRoot -s dc=example,dc=com -a /root/export.ldif failed with the return code 255 and the error

Having the error displayed would be useful

Comment 2 sgouvern 2020-09-28 08:45:32 UTC
To be noted that 'dsctl db2ldif' doesn't redirect either the cmd output on the terminal, when specifying a output file which cannot be accessed :

# /usr/sbin/ns-slapd db2ldif -D /etc/dirsrv/slapd-standalone1 -n userRoot -a /tmp/nonexistent/export.ldif
ldiffile: /tmp/nonexistent/export.ldif

With such an output, it is not possible straight away to know that the command failed.

For a better user experience, and for consistency, one should have displayed at least an extract of the errors log, as it is the case for other error misusage cases.
For example, we should have something like :
[28/Sep/2020:04:37:28.496635032 -0400] - ERR - bdb_db2ldif - db2ldif: userRoot: can't open /tmp/nonexistent/export.ldif: 2 (No such file or directory) while running as user "dirsrv"

Comment 4 thierry bordaz 2021-06-16 15:14:33 UTC
Is this problem reproducible with dsctl ? Else we will close it (no enhancement on legacy tools)

Comment 5 Viktor Ashirov 2021-06-17 10:11:02 UTC
With dsctl it's even worse as it doesn't display any output why the command failed, please see comment #2.

Comment 6 thierry bordaz 2021-06-17 11:41:51 UTC
Thanks Viktor for the confirmation. As it is likely an easy fix to for this usability issue, I moved its jira ticket to the top

Comment 8 mreynolds 2023-02-06 21:25:32 UTC
Upstream ticket:

https://github.com/389ds/389-ds-base/issues/5632

Comment 14 Viktor Ashirov 2023-05-04 13:35:21 UTC
Automated test passed:
============================================================= test session starts =============================================================
platform linux -- Python 3.9.16, pytest-6.2.2, py-1.10.0, pluggy-0.13.1 -- /usr/bin/python3
cachedir: .pytest_cache
389-ds-base: 2.2.7-2.module+el9dsrv+18726+78959e84
nss: 3.79.0-18.el9_1
nspr: 4.34.0-18.el9_1
openldap: 2.6.2-3.el9
cyrus-sasl: not installed
FIPS: disabled
rootdir: /root/ds/dirsrvtests, configfile: pytest.ini
collected 1 item

dirsrvtests/tests/suites/export/export_test.py::test_db2ldif_cli_with_non_accessible_ldif_file_path PASSED                              [100%]

======================================================= 1 passed, 5 warnings in 30.35s ========================================================


db2ldif prints an error:
# dsctl standalone1 db2ldif userroot /tmp/nonexistent/export.ldif
Error: The LDIF file location does not exist: /tmp/nonexistent/export.ldif

Marking as VERIFIED.

Comment 16 errata-xmlrpc 2023-05-30 09:40:35 UTC
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 (redhat-ds:12 bug fix and enhancement update), 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-2023:3344