Bug 1295972 - rhds10 doc - incomplete error code and tag list
rhds10 doc - incomplete error code and tag list
Status: CLOSED CURRENTRELEASE
Product: Red Hat Directory Server
Classification: Red Hat
Component: Doc-config-command-file-reference (Show other bugs)
10.0
Unspecified Unspecified
high Severity unspecified
: ---
: ---
Assigned To: Marc Muehlfeld
Viktor Ashirov
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-05 19:05 EST by Marc Sauton
Modified: 2016-12-19 03:34 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-19 03:34:53 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marc Sauton 2016-01-05 19:05:11 EST
Description of problem:

the RHDS 10 command and file reference doc has a truncated list of LDAP result codes that stops at err=36, where it used to show all the way to err=97

that list needs to be restored and updated.
for example, it may be missing err=357

7.4. LDAP Result Codes
LDAP has a set of result codes with which it is useful to be familiar.
Table 7.5. LDAP Result Codes

it only list the first 36 codes


then, the tag list is incomplete
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/logs-reference.html#Access_Log_Content-Default_Access_Logging_Content
chapter
7.1.2. Default Access Logging Content
Table 7.1. Commonly-Used Tags

it need to be updated, for example for the tag=121


Version-Release number of selected component (if applicable):
RHDS 10 doc / command and file reference


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:


example of access log in IPA context on RHEL 7.1

[10/Dec/2015:10:40:45 -0800] conn=54 fd=131 slot=131 connection from local to /var/run/slapd-EXAMPLE-COM.socket
[10/Dec/2015:10:40:45 -0800] conn=54 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[10/Dec/2015:10:40:45 -0800] conn=54 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[10/Dec/2015:10:40:45 -0800] conn=54 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
[10/Dec/2015:10:40:45 -0800] conn=54 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[10/Dec/2015:10:40:45 -0800] conn=54 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
[10/Dec/2015:10:40:45 -0800] conn=54 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/idm01.example.com@example.com,cn=services,cn=accounts,dc=example,dc=com"
...
[10/Dec/2015:10:40:45 -0800] conn=54 op=3 SRCH base="cn=dns,dc=example,dc=com" scope=2 filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" attrs=ALL
...
[10/Dec/2015:10:40:48 -0800] conn=54 op=3 RESULT err=357 tag=121 nentries=0 etime=3


what is err=357 ? or 0x165 ?
tag=121 seem to be for a result for a search, but it is not documented, and could not locate in 1.2.11 nor 1.3.4 source code, so not that clear on what this is exactly.
Comment 1 Marc Sauton 2016-01-05 19:57:46 EST
wibrown pointed me to

./ldap/servers/slapd/slapi-plugin.h:#define LDAP_RES_INTERMEDIATE ((ber_tag_t) 0x79U)

the following would need dev review for correctness:

some newer tags are "conditional":

tag=121
#ifndef LDAP_RES_INTERMEDIATE
#define LDAP_RES_INTERMEDIATE ((ber_tag_t) 0x79U)
#endif

tag=128
#ifndef LDAP_TAG_IM_RES_OID
#define LDAP_TAG_IM_RES_OID   ((ber_tag_t) 0x80U)
#endif

tag=129
#ifndef LDAP_TAG_IM_RES_VALUE
#define LDAP_TAG_IM_RES_VALUE ((ber_tag_t) 0x81U)
#endif


but some may collide with
#ifndef LDAP_SYNC_OID
/* LDAP Content Synchronization Operation -- RFC 4533 */
...
#define LDAP_TAG_SYNC_NEW_COOKIE        ((ber_tag_t) 0x80U)
#define LDAP_TAG_SYNC_REFRESH_DELETE    ((ber_tag_t) 0xa1U)
#define LDAP_TAG_SYNC_REFRESH_PRESENT   ((ber_tag_t) 0xa2U)
#define LDAP_TAG_SYNC_ID_SET            ((ber_tag_t) 0xa3U)
...
#define LDAP_TAG_SYNC_COOKIE            ((ber_tag_t) 0x04U)
#define LDAP_TAG_REFRESHDELETES         ((ber_tag_t) 0x01U)
#define LDAP_TAG_REFRESHDONE            ((ber_tag_t) 0x01U)
#define LDAP_TAG_RELOAD_HINT            ((ber_tag_t) 0x01U)

and

#ifndef LDAP_REQ_BIND
#define LDAP_REQ_BIND           ((ber_tag_t) 0x60U)     /* application + constructed */
#define LDAP_REQ_UNBIND         ((ber_tag_t) 0x42U)     /* application + primitive   */
#define LDAP_REQ_SEARCH         ((ber_tag_t) 0x63U)     /* application + constructed */
#define LDAP_REQ_MODIFY         ((ber_tag_t) 0x66U)     /* application + constructed */
#define LDAP_REQ_ADD            ((ber_tag_t) 0x68U)     /* application + constructed */
#define LDAP_REQ_DELETE         ((ber_tag_t) 0x4aU)     /* application + primitive   */
#define LDAP_REQ_MODDN          ((ber_tag_t) 0x6cU)     /* application + constructed */
...
#define LDAP_REQ_COMPARE        ((ber_tag_t) 0x6eU)     /* application + constructed */
#define LDAP_REQ_ABANDON        ((ber_tag_t) 0x50U)     /* application + primitive   */
#define LDAP_REQ_EXTENDED       ((ber_tag_t) 0x77U)     /* application + constructed */
#endif


was:

<wibrown> msauton: It's syncrepl related. I'm still digging more.
<wibrown> You can tell, because tag=121 is 0x79L which is the BER tag for LDAP_RES_INTERMEDIATE
<wibrown> and that's only using in syncrepl
<wibrown> I'm going to work out where this 357 comes from though.
<msauton> wibrown, seem "weird in the context of the ipa local search
<wibrown> It's not
<wibrown> It's the named server
<wibrown> look at the query
<wibrown> bind uses a syncrepl connection via the slapi socket
<msauton> wibrown, yes, ok for named
<wibrown> I can't see where 357 (0x165) is coming from though. It's not used anywhere in the code base. I'm assuming it's in an external library, the code around there is all BER related.
<wibrown> It's probably something for one of the wizards like nhosoi or mreynolds, they will probably know off the top of their head.
<wibrown> It may be worth checking the named log in parallel though, IIRC it's in /var/run/named/named.run
<msauton> wibrown, that's what I though for the third party err code, and  /var/run/named/named.run was not captured by the sosreport, thx for your time and help...
Comment 9 Marc Muehlfeld 2016-12-14 03:05:06 EST
Updated result code list:
* Updated result code list
* Updated column width
* Moved additional information to footnotes

Preview (master):
http://jenkinscat.gsslab.pnq.redhat.com:8080/view/Directory%20Server/job/doc-Red_Hat_Directory_Server-Configuration_Command_and_File_Reference%20(html-single)/lastSuccessfulBuild/artifact/tmp/en-US/html-single/index.html#LDAP_Result_Codes
(same update in the 10.1, 10.0, and DS-9 branch of the guide.)



Updated tag list:
* Added tag 121
* Updated column width

Preview (master):
http://jenkinscat.gsslab.pnq.redhat.com:8080/view/Directory%20Server/job/doc-Red_Hat_Directory_Server-Configuration_Command_and_File_Reference%20(html-single)/lastSuccessfulBuild/artifact/tmp/en-US/html-single/index.html#common-tags
(same update in the 10.1, 10.0, and DS-9 branch of the guide.)
Comment 10 Marc Muehlfeld 2016-12-19 03:34:53 EST
The update is now available on the Customer Portal.

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