On 01/03/2018 12:37 PM, Sergei
Gerasenko wrote:
Digging deeper into the access log, I see that certain operations return with non-zero error codes. The most prolific are 14 and 32. These are LDAP_SASL_BIND_IN_PROGRESS and LDAP_NO_SUCH_OBJECT respectively. So *maybe* the SNMP counter is incremented on those error codes. I’m currently looking at the source code trying to confirm that.It's in ldap/servers/slapd/result.c:367 if (err != LDAP_SUCCESS) { /* count the error for snmp */ /* first check for security errors */ if (err == LDAP_INVALID_CREDENTIALS || err == LDAP_INAPPROPRIATE_AUTH || err == LDAP_AUTH_METHOD_NOT_SUPPORTED || err == LDAP_STRONG_AUTH_NOT_SUPPORTED || err == LDAP_STRONG_AUTH_REQUIRED || err == LDAP_CONFIDENTIALITY_REQUIRED || err == LDAP_INSUFFICIENT_ACCESS || err == LDAP_AUTH_UNKNOWN) { slapi_counter_increment(g_get_global_snmp_vars()->ops_tbl.dsSecurityErrors); } else if (err != LDAP_REFERRAL && err != LDAP_OPT_REFERRALS && err != LDAP_PARTIAL_RESULTS) { /*madman man spec says not to count as normal errors --security errors --referrals -- partially seviced operations will not be conted as an error */ slapi_counter_increment(g_get_global_snmp_vars()->ops_tbl.dsErrors); } } And yes err=32 is no such object (common error code especially if you are using the 389-console), and err=14 is normal during GSSAPI binds. Regards, Mark I couldn’t find the definitions of those codes in the 389-ds-base source base. I found them here (of all places): https://docs.oracle.com/cd/E19957-01/817-6707/resultcodes.html#wp30446 I know it’s a totally different code base, but it appears to share some standards with the 389-ds implementation. |
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx