[Freeipa-users] Asking for help with crashed freeIPA istance

[Daniel Schimpfoessl]

Anything else I should look for?

2017-01-11 22:33 GMT-06:00 Daniel Schimpfoessl <daniel at schimpfoessl.com>:

> Flo,
>
> these are all the errors found:
> grep 'RESULT err=' access | perl -pe 's/.*(RESULT\s+err=\d+).*/$1/g' |
> sort -n | uniq -c | sort -n
>       2 RESULT err=6
>      95 RESULT err=32
>     200 RESULT err=14
>    2105 RESULT err=0
>
>
> 2017-01-05 8:10 GMT-06:00 Florence Blanc-Renaud <flo at redhat.com>:
>
>> On 01/04/2017 07:24 PM, Daniel Schimpfoessl wrote:
>>
>>> From the logs:
>>> /var/log/dirsrv/slapd-DOMAIN-COM/errors
>>> ... a few warnings about cache size, NSACLPLugin and schema-compat-plugin
>>> [04/Jan/2017:12:14:21.392642021 -0600] slapd started.  Listening on All
>>> Interfaces port 389 for LDAP requests
>>>
>>> /var/log/dirsrv/slapd-DOMAIN-COM/access
>>> ... lots of entries, not sure what to look for some lines contain RESULT
>>> with err!=0
>>> [04/Jan/2017:12:18:01.753400307 -0600] conn=5 op=243 RESULT err=32
>>> tag=101 nentries=0 etime=0
>>> [04/Jan/2017:12:18:01.786928085 -0600] conn=44 op=1 RESULT err=14 tag=97
>>> nentries=0 etime=0, SASL bind in progress
>>>
>>> Hi Daniel,
>>
>> are there any RESULT err=48 that could correspond to the error seen on
>> pki logs?
>>
>> Flo
>>
>> /var/log/dirsrv/slapd-DOMAIN-COM/errors
>>> [04/Jan/2017:12:19:25.566022098 -0600] slapd shutting down - signaling
>>> operation threads - op stack size 5 max work q size 2 max work q stack
>>> size 2
>>> [04/Jan/2017:12:19:25.572566622 -0600] slapd shutting down - closing
>>> down internal subsystems and plugins
>>>
>>>
>>> 2017-01-04 8:38 GMT-06:00 Daniel Schimpfoessl <daniel at schimpfoessl.com
>>> <mailto:daniel at schimpfoessl.com>>:
>>>
>>>     Do you have a list of all log files involved in IPA?
>>>     Would be good to consolidate them into ELK for analysis.
>>>
>>>     2017-01-04 2:48 GMT-06:00 Florence Blanc-Renaud <flo at redhat.com
>>>     <mailto:flo at redhat.com>>:
>>>
>>>
>>>         On 01/02/2017 07:24 PM, Daniel Schimpfoessl wrote:
>>>
>>>             Thanks for your reply.
>>>
>>>             This was the initial error I asked for help a while ago and
>>>             did not get
>>>             resolved. Further digging showed the recent errors.
>>>             The service was running (using ipactl start --force) and
>>>             only after a
>>>             restart I am getting a stack trace for two primary messages:
>>>
>>>             Could not connect to LDAP server host wwgwho01.webwim.com
>>>             <http://wwgwho01.webwim.com>
>>>             <http://wwgwho01.webwim.com> port 636 Error
>>>             netscape.ldap.LDAPException:
>>>             Authentication failed (48)
>>>             ...
>>>
>>>             Internal Database Error encountered: Could not connect to
>>>             LDAP server
>>>             host wwgwho01.webwim.com <http://wwgwho01.webwim.com>
>>>             <http://wwgwho01.webwim.com> port 636 Error
>>>             netscape.ldap.LDAPException: Authentication failed (48)
>>>             ...
>>>
>>>             and finally:
>>>             [02/Jan/2017:12:20:34][localhost-startStop-1]:
>>>             CMSEngine.shutdown()
>>>
>>>
>>>             2017-01-02 3:45 GMT-06:00 Florence Blanc-Renaud
>>>             <flo at redhat.com <mailto:flo at redhat.com>
>>>             <mailto:flo at redhat.com <mailto:flo at redhat.com>>>:
>>>
>>>                 systemctl start pki-tomcatd at pki-tomcat.service
>>>
>>>
>>>
>>>         Hi Daniel,
>>>
>>>         the next step would be to understand the root cause of this
>>>         "Authentication failed (48)" error. Note the exact time of this
>>>         log and look for a corresponding log in the LDAP server logs
>>>         (/var/log/dirsrv/slapd-DOMAIN-COM/access), probably a failing
>>>         BIND with err=48. This may help diagnose the issue (if we can
>>>         see which certificate is used for the bind or if there is a
>>>         specific error message).
>>>
>>>         For the record, a successful bind over SSL would produce this
>>>         type of log where we can see the certificate subject and the
>>>         user mapped to this certificate:
>>>         [...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to
>>>         10.34.58.150
>>>         [...] conn=47 TLS1.2 128-bit AES; client CN=CA
>>>         Subsystem,O=DOMAIN.COM <http://DOMAIN.COM>; issuer
>>>         CN=Certificate Authority,O=DOMAIN.COM <http://DOMAIN.COM>
>>>         [...] conn=47 TLS1.2 client bound as
>>> uid=pkidbuser,ou=people,o=ipaca
>>>         [...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL
>>>         [...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0
>>>         dn="uid=pkidbuser,ou=people,o=ipaca"
>>>
>>>         Flo
>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20170115/90b185a1/attachment.htm>