1271054 – RFE: LDAP command verification

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1271054 - RFE: LDAP command verification

Summary: RFE: LDAP command verification

Keywords:
Status:	CLOSED WONTFIX
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	389-ds-base
Sub Component:
Version:	7.3
Hardware:	x86_64
OS:	Linux
Priority:	unspecified
Severity:	low
Target Milestone:	pre-dev-freeze
Target Release:	---
Assignee:	Noriko Hosoi
QA Contact:	Viktor Ashirov
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2015-10-13 04:31 UTC by Glen Babiano
Modified:	2020-09-13 21:37 UTC (History)
CC List:	4 users (show)
Fixed In Version:
Doc Type:	Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed:	2016-12-05 02:44:33 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Github	389ds 389-ds-base issues 1727	0	None	None	None	2020-09-13 21:37:12 UTC

Description Glen Babiano 2015-10-13 04:31:05 UTC

Description of problem:

1. Proposed title of this feature request

Checking command parameters are correct before committing changes in to the LDAP database

2. Who is the customer behind the request?
Account: Fonterra Co-Operative Group

TAM customer: NO
SRM customer: YES
Strategic: YES

3. What is the nature and description of the request?

Customer is requesting that a sanity check will be performed before committing changes in the database. For example the customer commits a typo in the update command below:
--------------
ldapmodify -D "cn=Directory Manager" -w ******** <<EOF
dn: cn=${server}Role,dc=zeus,dc=ghsewn,dc=com
changetype: modify
add: nsroledn
nsroledn: cn=sapCorpRole,dc=zeus,dc=ghsewn,dc=com
changetype: modify
add: nsroledn
nsroledn: cn=sapANZRole,ou=people,dc=zeus,dc=ghsewn,dc=com
EOF
---------------

The system should be able to detect the mistake on the command and show the an error/suggestion to the user such as below:
-------------
This one is incorrect "nsroledn: cn=sapCorpRole,dc=zeus,dc=ghsewn,dc=com"
This role is correct "nsroledn: cn=sapANZRole,ou=people,dc=zeus,dc=ghsewn,dc=com"
-------------

The customer suggested that the following parameters be checked:

- does role exist
- does policy exist
- group exist

4. Why does the customer need this? (List the business requirements here)

A typo in the command makes host/s unusable especially if you are using a script to run the command on multiple servers

5. How would the customer like to achieve this? (List the functional requirements here)

The customer wants a script that will check the syntax of the ldap command before it makes any changes in the database.

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

The customer can test this functionality in their test environment.

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?

I don't think there is one already.

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?

9. Is the sales team involved in this request and do they have any additional input?

10. List any affected packages or components.

11. Would the customer be able to assist in testing this functionality if implemented?

Yes

Comment 1 Rich Megginson 2015-10-13 13:27:54 UTC

Instead of an argument checker, what if there were a way to do a "dry-run" of the ldapmodify command, that would show you what the command would do?  Would that satisfy the customer's requirement?

Comment 4 Glen Babiano 2015-10-13 23:29:10 UTC

Hi all,

Not sure if this is relevant but the customer is running their Directory server on RHEL 6.6.

Regards,

Glen

Comment 7 Glen Babiano 2015-10-14 02:17:23 UTC

(In reply to Rich Megginson from comment #1)
> Instead of an argument checker, what if there were a way to do a "dry-run"
> of the ldapmodify command, that would show you what the command would do? 
> Would that satisfy the customer's requirement?

Reply from Customer:

if the dry-run was to say:

adding/modifying/deleteing 
[attribute/entry]

warning: attribute /policy / role doesnt exist

Comment 8 Noriko Hosoi 2015-12-23 22:21:06 UTC

Upstream ticket:
https://fedorahosted.org/389/ticket/48396

Comment 10 Nathan Kinder 2016-12-05 02:44:33 UTC

This functionality would really require a new LDAP standard, as LDAP clients (like ldapmodify) would need the ability to ask the server to perform a dry-run option via a control or extended operation.  This would be a very time consuming process to go through, and it's unclear that a new standard would be accepted.  In addition, the change would be very complex to implement on the server side.  Unless there is a really stong request to do this, I do not believe it is worth the investment.  Closing as WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.