Re: [Freeipa-users] Multiple issues (weblogin, DNS) with 4.3.1

2016-06-30 Thread Tomasz Torcz
On Wed, Jun 22, 2016 at 10:26:16AM -0400, Rob Crittenden wrote:
> Tomasz Torcz wrote:
> > On Tue, Jun 21, 2016 at 01:38:19PM -0400, Rob Crittenden wrote:
> > > > > > [Sat Jun 18 18:59:11.337717 2016] [wsgi:error] [pid 748083] 
> > > > > > CertificateOperationError: Certificate operation cannot be 
> > > > > > completed: Unable to communicate with CMS (Internal Server Error)
> > > > > > [Sat Jun 18 18:59:11.337770 2016] [wsgi:error] [pid 748083]
> > > > > > [Sat Jun 18 18:59:11.338805 2016] [wsgi:error] [pid 748083] ipa: 
> > > > > > INFO: [jsonserver_session] ad...@pipebreaker.pl: 
> > > > > > cert_find(version=u'2.164'): CertificateOperationError
> > > > > > 
> > > > > >  How to fix those?
> > > > > 
> > > > > You'll need to look at the dogtag debug log for the reason it threw a 
> > > > > 500,
> > > > > it's in /var/log/pki-tomcat/ca or something close to that.
> > > > 
> > > > 
> > > > I've looked into the logs but I'm not wiser.  Is there a setting to 
> > > > get
> > > > rid of java traceback from logs and get more useful messages?  There 
> > > > seem
> > > > to be a problem with SSL connection to port 636, maybe because it seems 
> > > > to use
> > > > expired certificate?
> > > 
> > > Not that I know of. The debug log is sure a firehose but you've identified
> > > the problem.
> > > 
> > > > $ echo | openssl s_client  -connect okda.pipebreaker.pl:636  | openssl 
> > > > x509 -noout
> > > > depth=1 O = PIPEBREAKER.PL, CN = Certificate Authority
> > > > verify return:1
> > > > depth=0 O = PIPEBREAKER.PL, CN = okda.pipebreaker.pl
> > > > verify error:num=10:certificate has expired
> > > > notAfter=Nov 17 12:19:28 2015 GMT
> > > > verify return:1
> > > > depth=0 O = PIPEBREAKER.PL, CN = okda.pipebreaker.pl
> > > > notAfter=Nov 17 12:19:28 2015 GMT
> > > > verify return:1
> > > > DONE
> > > 
> > > Run getcert list and look at the expiration dates. What you want to do is
> > > kill ntpd, set the date back to say a week before the oldest date, restart
> > > the dirsrv, restart the pki-tomcat/pki-cad service then restart 
> > > certmonger.
> > > This should force a renewal attempt.
> 
> What you need to do is setup certmonger to track all the certificates
> properly and get things renewed. I'm away from my desk so can't provide any
> instructions on how to do this and they depend on whether or not this
> machine is the renewal master.


   I've used instructions from 
https://www.redhat.com/archives/freeipa-users/2015-October/msg00174.html
to remind certmonger about other certificates. I had to adjust paths:
-d /var/lib/pki/pki-tomcat/alias/
-B /usr/libexec/ipa/certmonger/stop_pkicad 
and
-C '/usr/libexec/ipa/certmonger/renew_ca_cert "${nickname}"'

I've rolled back time and I'm waiting for certmonger to refresh
those certs:

Request ID '20160630083224':
status: MONITORING
subject: CN=CA Audit,O=PIPEBREAKER.PL
expires: 2015-11-06 09:42:50 UTC
Request ID '20160630083226':
status: MONITORING
subject: CN=CA Subsystem,O=PIPEBREAKER.PL
expires: 2015-11-06 09:42:49 UTC
Request ID '20160630083227':
status: MONITORING
subject: CN=okda.pipebreaker.pl,O=PIPEBREAKER.PL
expires: 2017-10-25 15:20:52 UTC
root@okda ca$ date
Thu Nov  5 11:39:41 CET 2015

It's been 2 hours and certificates are still not refreshed.


 
> > P.S. Unfortunately https://fedorahosted.org/pki/ticket/1752 (Renewing 
> > already expired CA certificate) didn't
> > make into FreeIPA 4.4.0 alpha. :-(
> 
> This is unrelated. I seriously doubt your CA is near expiration (my guess is
> it expires in 2033).

  I'm not sure about CA certificate itself, but "CA Subsystem" certificate is 
expired.
As far as I understand, 1752 is about refreshing certs by going directly 
through socket,
mitigating expired certificates.

-- 
Tomasz Torcz"Funeral in the morning, IDE hacking
xmpp: zdzich...@chrome.plin the afternoon and evening." - Alan Cox

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] Multiple issues (weblogin, DNS) with 4.3.1

2016-06-25 Thread Tomasz Torcz
On Wed, Jun 22, 2016 at 05:01:55PM +0200, Youenn PIOLET wrote:
> Hi,

  Hello Youen,

> 
> Can you provide the output of :
> certutil -L -d /etc/dirsrv/slapd-/ on replicas that can't
> start the PKI?
> Your CA Cert attributes should be CT,C,C

---
$ certutil -L -d /etc/dirsrv/slapd-PIPEBREAKER-PL/

Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI

Server-Cert  u,u,u
PIPEBREAKER.PL IPA CACT,C,
---

Last 'C' is missing; according to certutil manpage, this is for ”object 
signing”.

> 
> I experience the same issue as you every two replica I install. The fix is :
> certutil -d /etc/dirsrv/slapd-/ -A -t "CT,C,C" -n " DOMAIN> IPA CA" -i /etc/ipa/ca.crt

  After this command, the output is now:
PIPEBREAKER.PL IPA CACT,C,C



> and restart ipa server.

It seems error message changed, now it's ”Subsystem unavailable”:

---
Jun 25 20:29:35 okda.pipebreaker.pl server[846021]: Jun 25, 2016 8:29:35 PM 
org.apache.catalina.core.ContainerBase backgroundProcess
Jun 25 20:29:36 okda.pipebreaker.pl server[846021]: WARNING: Exception 
processing realm com.netscape.cms.tomcat.ProxyRealm@3e8fa209 background process
Jun 25 20:29:36 okda.pipebreaker.pl server[846021]: 
javax.ws.rs.ServiceUnavailableException: Subsystem unavailable
Jun 25 20:29:36 okda.pipebreaker.pl server[846021]: at 
com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:130)
Jun 25 20:29:36 okda.pipebreaker.pl server[846021]: at 
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1127)
Jun 25 20:29:36 okda.pipebreaker.pl server[846021]: at 
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5642)
Jun 25 20:29:36 okda.pipebreaker.pl server[846021]: at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1377)
Jun 25 20:29:36 okda.pipebreaker.pl server[846021]: at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1381)
Jun 25 20:29:36 okda.pipebreaker.pl server[846021]: at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1381)
Jun 25 20:29:36 okda.pipebreaker.pl server[846021]: at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1349)
Jun 25 20:29:36 okda.pipebreaker.pl server[846021]: at 
java.lang.Thread.run(Thread.java:745)
---

 
> https://www.redhat.com/archives/freeipa-users/2013-August/msg00088.html
> 
> Can you also provide the following line of the file generated by following
> commands:
> 
> $ ipa certprofile-show --out /tmp/caIPAserviceCert.cfg caIPAserviceCert

  This command creates 0-length file. I've kinited to admin before invoking the 
command:

---
…
ipa: INFO: trying https://okda.pipebreaker.pl/ipa/json
ipa: DEBUG: NSSConnection init okda.pipebreaker.pl
ipa: DEBUG: Connecting: 2a00:d880:5:a14::8b0d:aed
ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server
ipa: DEBUG: cert valid True for "CN=okda.pipebreaker.pl,O=PIPEBREAKER.PL"
ipa: DEBUG: handshake complete, peer = 2a00:d880:5:a14::8b0d:aed
ipa: DEBUG: Protocol: TLS1.2
ipa: DEBUG: Cipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ipa: DEBUG: received Set-Cookie 'ipa_session=2906766f27c485b00049c51a0ca7d86a; 
Domain=okda.pipebreaker.pl; Path=/ipa; Expires=Sat, 25 Jun 2016 19:39:54 GMT; 
Secure; HttpOnly'
ipa: DEBUG: storing cookie 'ipa_session=2906766f27c485b00049c51a0ca7d86a; 
Domain=okda.pipebreaker.pl; Path=/ipa; Expires=Sat, 25 Jun 2016 19:39:54 GMT; 
Secure; HttpOnly' for principal ad...@pipebreaker.pl
ipa: DEBUG: Created connection context.rpcclient_140035796262032
ipa: DEBUG: raw: certprofile_show(u'caIPAserviceCert', rights=False, 
out=u'/tmp/caIPAserviceCert.cfg', all=False, raw=False, version=u'2.164')
ipa: DEBUG: certprofile_show(u'caIPAserviceCert', rights=False, 
out=u'/tmp/caIPAserviceCert.cfg', all=False, raw=False, version=u'2.164')
ipa: INFO: Forwarding 'certprofile_show' to json server 
'https://okda.pipebreaker.pl/ipa/json'
ipa: DEBUG: NSSConnection init okda.pipebreaker.pl
ipa: DEBUG: Connecting: 2a00:d880:5:a14::8b0d:aed
ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server
ipa: DEBUG: cert valid True for "CN=okda.pipebreaker.pl,O=PIPEBREAKER.PL"
ipa: DEBUG: handshake complete, peer = 2a00:d880:5:a14::8b0d:aed
ipa: DEBUG: Protocol: TLS1.2
ipa: DEBUG: Cipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ipa: DEBUG: received Set-Cookie 'ipa_session=c6b47d5eb7a504b7ab629a2111dec4f3; 
Domain=okda.pipebreaker.pl; Path=/ipa; Expires=Sat, 25 Jun 2016 19:39:56 GMT; 
Secure; HttpOnly'
ipa: DEBUG: storing cookie 'ipa_session=c6b47d5eb7a504b7ab629a2111dec4f3; 
Domain=okda.pipebreaker.pl; Path=/ipa; Expires=Sat, 25 Jun 2016 19:39:56 

Re: [Freeipa-users] Multiple issues (weblogin, DNS) with 4.3.1

2016-06-22 Thread Youenn PIOLET
Hi,

Can you provide the output of :
certutil -L -d /etc/dirsrv/slapd-/ on replicas that can't
start the PKI?
Your CA Cert attributes should be CT,C,C

I experience the same issue as you every two replica I install. The fix is :
certutil -d /etc/dirsrv/slapd-/ -A -t "CT,C,C" -n " IPA CA" -i /etc/ipa/ca.crt
and restart ipa server.

https://www.redhat.com/archives/freeipa-users/2013-August/msg00088.html

Can you also provide the following line of the file generated by following
commands:

$ ipa certprofile-show --out /tmp/caIPAserviceCert.cfg caIPAserviceCert
$ grep policyset.serverCertSet.1.default.params.name
/tmp/caIPAserviceCert.cfg

Regards,

--
Youenn Piolet
piole...@gmail.com


2016-06-22 16:26 GMT+02:00 Rob Crittenden :

> Tomasz Torcz wrote:
>
>> On Tue, Jun 21, 2016 at 01:38:19PM -0400, Rob Crittenden wrote:
>>
>>> [Sat Jun 18 18:59:11.337717 2016] [wsgi:error] [pid 748083]
>> CertificateOperationError: Certificate operation cannot be completed:
>> Unable to communicate with CMS (Internal Server Error)
>> [Sat Jun 18 18:59:11.337770 2016] [wsgi:error] [pid 748083]
>> [Sat Jun 18 18:59:11.338805 2016] [wsgi:error] [pid 748083] ipa:
>> INFO: [jsonserver_session] ad...@pipebreaker.pl:
>> cert_find(version=u'2.164'): CertificateOperationError
>>
>>  How to fix those?
>>
>
> You'll need to look at the dogtag debug log for the reason it threw a
> 500,
> it's in /var/log/pki-tomcat/ca or something close to that.
>


 I've looked into the logs but I'm not wiser.  Is there a setting to
 get
 rid of java traceback from logs and get more useful messages?  There
 seem
 to be a problem with SSL connection to port 636, maybe because it seems
 to use
 expired certificate?

>>>
>>> Not that I know of. The debug log is sure a firehose but you've
>>> identified
>>> the problem.
>>>
>>> $ echo | openssl s_client  -connect okda.pipebreaker.pl:636  | openssl
 x509 -noout
 depth=1 O = PIPEBREAKER.PL, CN = Certificate Authority
 verify return:1
 depth=0 O = PIPEBREAKER.PL, CN = okda.pipebreaker.pl
 verify error:num=10:certificate has expired
 notAfter=Nov 17 12:19:28 2015 GMT
 verify return:1
 depth=0 O = PIPEBREAKER.PL, CN = okda.pipebreaker.pl
 notAfter=Nov 17 12:19:28 2015 GMT
 verify return:1
 DONE

>>>
>>> Run getcert list and look at the expiration dates. What you want to do is
>>> kill ntpd, set the date back to say a week before the oldest date,
>>> restart
>>> the dirsrv, restart the pki-tomcat/pki-cad service then restart
>>> certmonger.
>>> This should force a renewal attempt.
>>>
>>
>> Expiration date look fine:
>>
>> root@okda ~$ getcert list
>> Number of certificates and requests being tracked: 1.
>> Request ID '20131116123125':
>>  status: CA_UNREACHABLE
>>  ca-error: Server at https://okda.pipebreaker.pl/ipa/xml failed
>> request, will retry: 4301 (RPC failed at server.  Certificate operation
>> cannot be completed: Unable to communicate with CMS (503)).
>>  stuck: no
>>  key pair storage:
>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>>  certificate:
>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
>> Certificate DB'
>>  CA: IPA
>>  issuer: CN=Certificate Authority,O=PIPEBREAKER.PL
>>  subject: CN=okda.pipebreaker.pl,O=PIPEBREAKER.PL
>>  expires: 2017-12-10 19:44:31 UTC
>>  principal name: HTTP/okda.pipebreaker...@pipebreaker.pl
>>  key usage:
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>  eku: id-kp-serverAuth,id-kp-clientAuth
>>  pre-save command:
>>  post-save command: /usr/lib64/ipa/certmonger/restart_httpd
>>  track: yes
>>  auto-renew: yes
>>
>>
>>It's in 2017. The output seem quite short, on the other replica
>> "getcert list" returns 9 certificates.
>>
>
> The 503 suggests that the CA didn't come up (service not available). This
> may be due to expired certs.
>
> What you need to do is setup certmonger to track all the certificates
> properly and get things renewed. I'm away from my desk so can't provide any
> instructions on how to do this and they depend on whether or not this
> machine is the renewal master.
>
> P.S. Unfortunately https://fedorahosted.org/pki/ticket/1752 (Renewing
>> already expired CA certificate) didn't
>> make into FreeIPA 4.4.0 alpha. :-(
>>
>
> This is unrelated. I seriously doubt your CA is near expiration (my guess
> is it expires in 2033).
>
> rob
>
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:

Re: [Freeipa-users] Multiple issues (weblogin, DNS) with 4.3.1

2016-06-22 Thread Rob Crittenden

Tomasz Torcz wrote:

On Tue, Jun 21, 2016 at 01:38:19PM -0400, Rob Crittenden wrote:

[Sat Jun 18 18:59:11.337717 2016] [wsgi:error] [pid 748083] 
CertificateOperationError: Certificate operation cannot be completed: Unable to 
communicate with CMS (Internal Server Error)
[Sat Jun 18 18:59:11.337770 2016] [wsgi:error] [pid 748083]
[Sat Jun 18 18:59:11.338805 2016] [wsgi:error] [pid 748083] ipa: INFO: 
[jsonserver_session] ad...@pipebreaker.pl: cert_find(version=u'2.164'): 
CertificateOperationError

 How to fix those?


You'll need to look at the dogtag debug log for the reason it threw a 500,
it's in /var/log/pki-tomcat/ca or something close to that.



I've looked into the logs but I'm not wiser.  Is there a setting to get
rid of java traceback from logs and get more useful messages?  There seem
to be a problem with SSL connection to port 636, maybe because it seems to use
expired certificate?


Not that I know of. The debug log is sure a firehose but you've identified
the problem.


$ echo | openssl s_client  -connect okda.pipebreaker.pl:636  | openssl x509 
-noout
depth=1 O = PIPEBREAKER.PL, CN = Certificate Authority
verify return:1
depth=0 O = PIPEBREAKER.PL, CN = okda.pipebreaker.pl
verify error:num=10:certificate has expired
notAfter=Nov 17 12:19:28 2015 GMT
verify return:1
depth=0 O = PIPEBREAKER.PL, CN = okda.pipebreaker.pl
notAfter=Nov 17 12:19:28 2015 GMT
verify return:1
DONE


Run getcert list and look at the expiration dates. What you want to do is
kill ntpd, set the date back to say a week before the oldest date, restart
the dirsrv, restart the pki-tomcat/pki-cad service then restart certmonger.
This should force a renewal attempt.


Expiration date look fine:

root@okda ~$ getcert list
Number of certificates and requests being tracked: 1.
Request ID '20131116123125':
 status: CA_UNREACHABLE
 ca-error: Server at https://okda.pipebreaker.pl/ipa/xml failed 
request, will retry: 4301 (RPC failed at server.  Certificate operation cannot 
be completed: Unable to communicate with CMS (503)).
 stuck: no
 key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
 certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB'
 CA: IPA
 issuer: CN=Certificate Authority,O=PIPEBREAKER.PL
 subject: CN=okda.pipebreaker.pl,O=PIPEBREAKER.PL
 expires: 2017-12-10 19:44:31 UTC
 principal name: HTTP/okda.pipebreaker...@pipebreaker.pl
 key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
 eku: id-kp-serverAuth,id-kp-clientAuth
 pre-save command:
 post-save command: /usr/lib64/ipa/certmonger/restart_httpd
 track: yes
 auto-renew: yes


   It's in 2017. The output seem quite short, on the other replica "getcert 
list" returns 9 certificates.


The 503 suggests that the CA didn't come up (service not available). 
This may be due to expired certs.


What you need to do is setup certmonger to track all the certificates 
properly and get things renewed. I'm away from my desk so can't provide 
any instructions on how to do this and they depend on whether or not 
this machine is the renewal master.



P.S. Unfortunately https://fedorahosted.org/pki/ticket/1752 (Renewing already 
expired CA certificate) didn't
make into FreeIPA 4.4.0 alpha. :-(


This is unrelated. I seriously doubt your CA is near expiration (my 
guess is it expires in 2033).


rob

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] Multiple issues (weblogin, DNS) with 4.3.1

2016-06-22 Thread Tomasz Torcz
On Tue, Jun 21, 2016 at 01:38:19PM -0400, Rob Crittenden wrote:
> > > > [Sat Jun 18 18:59:11.337717 2016] [wsgi:error] [pid 748083] 
> > > > CertificateOperationError: Certificate operation cannot be completed: 
> > > > Unable to communicate with CMS (Internal Server Error)
> > > > [Sat Jun 18 18:59:11.337770 2016] [wsgi:error] [pid 748083]
> > > > [Sat Jun 18 18:59:11.338805 2016] [wsgi:error] [pid 748083] ipa: INFO: 
> > > > [jsonserver_session] ad...@pipebreaker.pl: cert_find(version=u'2.164'): 
> > > > CertificateOperationError
> > > > 
> > > > How to fix those?
> > > 
> > > You'll need to look at the dogtag debug log for the reason it threw a 500,
> > > it's in /var/log/pki-tomcat/ca or something close to that.
> > 
> > 
> >I've looked into the logs but I'm not wiser.  Is there a setting to get
> > rid of java traceback from logs and get more useful messages?  There seem
> > to be a problem with SSL connection to port 636, maybe because it seems to 
> > use
> > expired certificate?
> 
> Not that I know of. The debug log is sure a firehose but you've identified
> the problem.
> 
> > $ echo | openssl s_client  -connect okda.pipebreaker.pl:636  | openssl x509 
> > -noout
> > depth=1 O = PIPEBREAKER.PL, CN = Certificate Authority
> > verify return:1
> > depth=0 O = PIPEBREAKER.PL, CN = okda.pipebreaker.pl
> > verify error:num=10:certificate has expired
> > notAfter=Nov 17 12:19:28 2015 GMT
> > verify return:1
> > depth=0 O = PIPEBREAKER.PL, CN = okda.pipebreaker.pl
> > notAfter=Nov 17 12:19:28 2015 GMT
> > verify return:1
> > DONE
> 
> Run getcert list and look at the expiration dates. What you want to do is
> kill ntpd, set the date back to say a week before the oldest date, restart
> the dirsrv, restart the pki-tomcat/pki-cad service then restart certmonger.
> This should force a renewal attempt.

Expiration date look fine:

root@okda ~$ getcert list
Number of certificates and requests being tracked: 1.
Request ID '20131116123125':
status: CA_UNREACHABLE
ca-error: Server at https://okda.pipebreaker.pl/ipa/xml failed request, 
will retry: 4301 (RPC failed at server.  Certificate operation cannot be 
completed: Unable to communicate with CMS (503)).
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=PIPEBREAKER.PL
subject: CN=okda.pipebreaker.pl,O=PIPEBREAKER.PL
expires: 2017-12-10 19:44:31 UTC
principal name: HTTP/okda.pipebreaker...@pipebreaker.pl
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: 
post-save command: /usr/lib64/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes


  It's in 2017. The output seem quite short, on the other replica "getcert 
list" returns 9 certificates.


P.S. Unfortunately https://fedorahosted.org/pki/ticket/1752 (Renewing already 
expired CA certificate) didn't
   make into FreeIPA 4.4.0 alpha. :-(

-- 
Tomasz TorczOnce you've read the dictionary,
xmpp: zdzich...@chrome.pl   every other book is just a remix.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] Multiple issues (weblogin, DNS) with 4.3.1

2016-06-21 Thread Rob Crittenden

Tomasz Torcz wrote:

On Sat, Jun 18, 2016 at 11:02:23PM -0400, Rob Crittenden wrote:


Most of the functions work, but 5) I cannot get Authentication→Certificates
list:

On okda, going to Certificates list yields ”Certificate operation cannot be 
completed: Unable to communicate with CMS (Internal Server Error)”
and error_log contains:
[Sat Jun 18 18:59:10.523796 2016] [wsgi:error] [pid 748083] 
falsefalsefalsefalsefalsetruefalsefalsefalsefalsefalsefalse
[Sat Jun 18 18:59:11.244206 2016] [wsgi:error] [pid 748083] ipa: DEBUG: HTTP 
Response code: 500
[Sat Jun 18 18:59:11.248305 2016] [wsgi:error] [pid 748083] ipa: ERROR: 
ipaserver.plugins.dogtag.ra.find(): Unable to communicate with CMS (Internal 
Server Error)
[Sat Jun 18 18:59:11.336576 2016] [wsgi:error] [pid 748083] ipa: DEBUG: WSGI 
wsgi_execute PublicError: Traceback (most recent call last):
[Sat Jun 18 18:59:11.336895 2016] [wsgi:error] [pid 748083]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, in 
wsgi_execute
[Sat Jun 18 18:59:11.337011 2016] [wsgi:error] [pid 748083] result = 
self.Command[name](*args, **options)
[Sat Jun 18 18:59:11.337086 2016] [wsgi:error] [pid 748083]   File 
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 446, in __call__
[Sat Jun 18 18:59:11.337156 2016] [wsgi:error] [pid 748083] ret = 
self.run(*args, **options)
[Sat Jun 18 18:59:11.337241 2016] [wsgi:error] [pid 748083]   File 
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 763, in run
[Sat Jun 18 18:59:11.337311 2016] [wsgi:error] [pid 748083] return 
self.execute(*args, **options)
[Sat Jun 18 18:59:11.337373 2016] [wsgi:error] [pid 748083]   File 
"/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 819, in execute
[Sat Jun 18 18:59:11.337417 2016] [wsgi:error] [pid 748083] 
result=self.Backend.ra.find(options)
[Sat Jun 18 18:59:11.337455 2016] [wsgi:error] [pid 748083]   File 
"/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 1861, in 
find
[Sat Jun 18 18:59:11.337493 2016] [wsgi:error] [pid 748083] detail=e.msg)
[Sat Jun 18 18:59:11.337566 2016] [wsgi:error] [pid 748083]   File 
"/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 1331, in 
raise_certificate_operation_error
[Sat Jun 18 18:59:11.337653 2016] [wsgi:error] [pid 748083] raise 
errors.CertificateOperationError(error=err_msg)
[Sat Jun 18 18:59:11.337717 2016] [wsgi:error] [pid 748083] 
CertificateOperationError: Certificate operation cannot be completed: Unable to 
communicate with CMS (Internal Server Error)
[Sat Jun 18 18:59:11.337770 2016] [wsgi:error] [pid 748083]
[Sat Jun 18 18:59:11.338805 2016] [wsgi:error] [pid 748083] ipa: INFO: 
[jsonserver_session] ad...@pipebreaker.pl: cert_find(version=u'2.164'): 
CertificateOperationError

How to fix those?


You'll need to look at the dogtag debug log for the reason it threw a 500,
it's in /var/log/pki-tomcat/ca or something close to that.



   I've looked into the logs but I'm not wiser.  Is there a setting to get
rid of java traceback from logs and get more useful messages?  There seem
to be a problem with SSL connection to port 636, maybe because it seems to use
expired certificate?


Not that I know of. The debug log is sure a firehose but you've 
identified the problem.



$ echo | openssl s_client  -connect okda.pipebreaker.pl:636  | openssl x509 
-noout
depth=1 O = PIPEBREAKER.PL, CN = Certificate Authority
verify return:1
depth=0 O = PIPEBREAKER.PL, CN = okda.pipebreaker.pl
verify error:num=10:certificate has expired
notAfter=Nov 17 12:19:28 2015 GMT
verify return:1
depth=0 O = PIPEBREAKER.PL, CN = okda.pipebreaker.pl
notAfter=Nov 17 12:19:28 2015 GMT
verify return:1
DONE


Run getcert list and look at the expiration dates. What you want to do 
is kill ntpd, set the date back to say a week before the oldest date, 
restart the dirsrv, restart the pki-tomcat/pki-cad service then restart 
certmonger. This should force a renewal attempt.


Use getcert and syslog to watch progress. It may require a few restarts 
of certmonger to get all the certs renewed.


Ideally that all happens fairly gracefully so then you move forward in 
time again, run ipactl restart and things work as usual.


rob





Log from /var/log/pki/pki-tomcat/ca/system:

0.localhost-startStop-1 - [18/Jun/2016:18:54:09 CEST] [8] [3] In Ldap (bound) 
connection pool to host okda.pipebreaker.pl port 636, Cannot connect to LDAP 
server. Error: netscape.ldap.LDAPException: IO Error creating JSS SSL Socket 
(-1)



Log from /var/log/pki/pki-tomcat/ca/debug:

[18/Jun/2016:18:54:03][localhost-startStop-1]: 

[18/Jun/2016:18:54:03][localhost-startStop-1]: =  DEBUG SUBSYSTEM 
INITIALIZED   ===
[18/Jun/2016:18:54:03][localhost-startStop-1]: 

[18/Jun/2016:18:54:03][localhost-startStop-1]: CMSEngine: restart at 
autoShutdown? false

Re: [Freeipa-users] Multiple issues (weblogin, DNS) with 4.3.1

2016-06-20 Thread Tomasz Torcz
On Sat, Jun 18, 2016 at 11:02:23PM -0400, Rob Crittenden wrote:
> > 
> >Most of the functions work, but 5) I cannot get 
> > Authentication→Certificates
> > list:
> > 
> > On okda, going to Certificates list yields ”Certificate operation cannot be 
> > completed: Unable to communicate with CMS (Internal Server Error)”
> > and error_log contains:
> > [Sat Jun 18 18:59:10.523796 2016] [wsgi:error] [pid 748083] 
> > falsefalsefalsefalsefalsetruefalsefalsefalsefalsefalsefalse
> > [Sat Jun 18 18:59:11.244206 2016] [wsgi:error] [pid 748083] ipa: DEBUG: 
> > HTTP Response code: 500
> > [Sat Jun 18 18:59:11.248305 2016] [wsgi:error] [pid 748083] ipa: ERROR: 
> > ipaserver.plugins.dogtag.ra.find(): Unable to communicate with CMS 
> > (Internal Server Error)
> > [Sat Jun 18 18:59:11.336576 2016] [wsgi:error] [pid 748083] ipa: DEBUG: 
> > WSGI wsgi_execute PublicError: Traceback (most recent call last):
> > [Sat Jun 18 18:59:11.336895 2016] [wsgi:error] [pid 748083]   File 
> > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, in 
> > wsgi_execute
> > [Sat Jun 18 18:59:11.337011 2016] [wsgi:error] [pid 748083] result = 
> > self.Command[name](*args, **options)
> > [Sat Jun 18 18:59:11.337086 2016] [wsgi:error] [pid 748083]   File 
> > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 446, in __call__
> > [Sat Jun 18 18:59:11.337156 2016] [wsgi:error] [pid 748083] ret = 
> > self.run(*args, **options)
> > [Sat Jun 18 18:59:11.337241 2016] [wsgi:error] [pid 748083]   File 
> > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 763, in run
> > [Sat Jun 18 18:59:11.337311 2016] [wsgi:error] [pid 748083] return 
> > self.execute(*args, **options)
> > [Sat Jun 18 18:59:11.337373 2016] [wsgi:error] [pid 748083]   File 
> > "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 819, in 
> > execute
> > [Sat Jun 18 18:59:11.337417 2016] [wsgi:error] [pid 748083] 
> > result=self.Backend.ra.find(options)
> > [Sat Jun 18 18:59:11.337455 2016] [wsgi:error] [pid 748083]   File 
> > "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 1861, 
> > in find
> > [Sat Jun 18 18:59:11.337493 2016] [wsgi:error] [pid 748083] 
> > detail=e.msg)
> > [Sat Jun 18 18:59:11.337566 2016] [wsgi:error] [pid 748083]   File 
> > "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 1331, 
> > in raise_certificate_operation_error
> > [Sat Jun 18 18:59:11.337653 2016] [wsgi:error] [pid 748083] raise 
> > errors.CertificateOperationError(error=err_msg)
> > [Sat Jun 18 18:59:11.337717 2016] [wsgi:error] [pid 748083] 
> > CertificateOperationError: Certificate operation cannot be completed: 
> > Unable to communicate with CMS (Internal Server Error)
> > [Sat Jun 18 18:59:11.337770 2016] [wsgi:error] [pid 748083]
> > [Sat Jun 18 18:59:11.338805 2016] [wsgi:error] [pid 748083] ipa: INFO: 
> > [jsonserver_session] ad...@pipebreaker.pl: cert_find(version=u'2.164'): 
> > CertificateOperationError
> > 
> >How to fix those?
> 
> You'll need to look at the dogtag debug log for the reason it threw a 500,
> it's in /var/log/pki-tomcat/ca or something close to that.


  I've looked into the logs but I'm not wiser.  Is there a setting to get
rid of java traceback from logs and get more useful messages?  There seem
to be a problem with SSL connection to port 636, maybe because it seems to use
expired certificate?

$ echo | openssl s_client  -connect okda.pipebreaker.pl:636  | openssl x509 
-noout
depth=1 O = PIPEBREAKER.PL, CN = Certificate Authority
verify return:1
depth=0 O = PIPEBREAKER.PL, CN = okda.pipebreaker.pl
verify error:num=10:certificate has expired
notAfter=Nov 17 12:19:28 2015 GMT
verify return:1
depth=0 O = PIPEBREAKER.PL, CN = okda.pipebreaker.pl
notAfter=Nov 17 12:19:28 2015 GMT
verify return:1
DONE



Log from /var/log/pki/pki-tomcat/ca/system:

0.localhost-startStop-1 - [18/Jun/2016:18:54:09 CEST] [8] [3] In Ldap (bound) 
connection pool to host okda.pipebreaker.pl port 636, Cannot connect to LDAP 
server. Error: netscape.ldap.LDAPException: IO Error creating JSS SSL Socket 
(-1)



Log from /var/log/pki/pki-tomcat/ca/debug:

[18/Jun/2016:18:54:03][localhost-startStop-1]: 

[18/Jun/2016:18:54:03][localhost-startStop-1]: =  DEBUG SUBSYSTEM 
INITIALIZED   ===
[18/Jun/2016:18:54:03][localhost-startStop-1]: 

[18/Jun/2016:18:54:03][localhost-startStop-1]: CMSEngine: restart at 
autoShutdown? false
[18/Jun/2016:18:54:03][localhost-startStop-1]: CMSEngine: autoShutdown crumb 
file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[18/Jun/2016:18:54:03][localhost-startStop-1]: CMSEngine: about to look for 
cert for auto-shutdown support:auditSigningCert cert-pki-ca
[18/Jun/2016:18:54:03][localhost-startStop-1]: CMSEngine: found 
cert:auditSigningCert cert-pki-ca
[18/Jun/2016:18:54:03][localhost-startStop-1]: CMSEngine: done init id=debug

Re: [Freeipa-users] Multiple issues (weblogin, DNS) with 4.3.1

2016-06-18 Thread Rob Crittenden

Tomasz Torcz wrote:

On Fri, Jun 17, 2016 at 11:32:22AM +0200, Petr Vobornik wrote:

On 27.5.2016 14:28, Tomasz Torcz wrote:

Hi,

   In my home environment I'm using two-server FreeIPA configuration on Fedora.
Initially installed on fedora 19 in November 2013, it have been upgraded every
Fedora release. It generally works OK, but somewhat degrades during operation.
Recently I've jumped to F24 in hope my problems will be resolved, but they 
weren't.
Thus this email and plea for assistance.

   I'm using freeipa-server-4.3.1-1.fc24.x86_64. One of the servers is called
kaitain.pipebreaker.pl, the other okda.pipebreaker.pl.

   Currently I encounter following main problems:
1) named is not servicing all the records from LDAP
2) can't login to WebUI on kaitain.pipebreaker.pl
3) can't login to WebUI on okda.pipebreaker.pl
4) pycparser.lextab/lextab.py/yacctab.py permission errors



Switch IPA framework to debug mode as described below. It should show
more information.


Httpd error_log should at least show which operation encountered the
Gateway timeout. If not, then put IPA framework into debug mode:

http://www.freeipa.org/page/Troubleshooting#Administration_Framework



   Thanks Petr! While editing /etc/ipa/defualt.conf to enable debug
I've noticed my previous errors.  Few weeks ago I was having problems
with certmonger not re-requesting certificates. In order to point
certmonger to the other IPA server, I've edited host= line
in default.conf.
   After all I must have mixed things up, and _both_ mine IPA servers
had the other host entered in host= line. After entering correct
names, I can log into both web uis.

   Most of the functions work, but 5) I cannot get Authentication→Certificates
list:

on kaitain, after going into Authentication -> Certificates list I got
ethernal spinning in browser, and error_log contains:
[Sat Jun 18 18:46:07.665264 2016] [wsgi:error] [pid 12629] ipa: DEBUG: WSGI 
wsgi_dispatch.__call__:
[Sat Jun 18 18:46:07.665458 2016] [wsgi:error] [pid 12629] ipa: DEBUG: WSGI 
jsonserver_session.__call__:
[Sat Jun 18 18:46:07.665637 2016] [wsgi:error] [pid 12629] ipa: DEBUG: found 
session cookie_id = 47c42943141700c4968c2c2f3f050848
[Sat Jun 18 18:46:07.666035 2016] [wsgi:error] [pid 12629] ipa: DEBUG: found 
session data in cache with id=47c42943141700c4968c2c2f3f050848
[Sat Jun 18 18:46:07.666169 2016] [wsgi:error] [pid 12629] ipa: DEBUG: 
jsonserver_session.__call__: session_id=47c42943141700c4968c2c2f3f050848 
start_timestamp=2016-06-18T18:42:34 access_timestamp=2016-06-18T18:46:07 
expiration_timestamp=2016-06-18T19:06:01
[Sat Jun 18 18:46:07.666268 2016] [wsgi:error] [pid 12629] ipa: DEBUG: storing ccache 
data into file "/var/run/ipa_memcached/krbcc_12629"
[Sat Jun 18 18:46:07.667531 2016] [wsgi:error] [pid 12629] ipa: DEBUG: 
set_session_expiration_time: duration_type=inactivity_timeout duration=1200 
max_age=1466354363.67 expiration=1466269567.67 (2016-06-18T19:06:07)
[Sat Jun 18 18:46:07.938034 2016] [wsgi:error] [pid 12629] ipa: DEBUG: Created 
connection context.ldap2_139873368474448
[Sat Jun 18 18:46:07.938202 2016] [wsgi:error] [pid 12629] ipa: DEBUG: WSGI 
jsonserver.__call__:
[Sat Jun 18 18:46:07.938293 2016] [wsgi:error] [pid 12629] ipa: DEBUG: WSGI 
WSGIExecutioner.__call__:
[Sat Jun 18 18:46:07.938652 2016] [wsgi:error] [pid 12629] ipa: DEBUG: raw: 
cert_find(version=u'2.164')
[Sat Jun 18 18:46:07.938900 2016] [wsgi:error] [pid 12629] ipa: DEBUG: 
cert_find(exactly=False, all=False, raw=False, version=u'2.164')
[Sat Jun 18 18:46:07.939225 2016] [wsgi:error] [pid 12629] ipa: DEBUG: raw: 
ca_is_enabled(version=u'2.164')
[Sat Jun 18 18:46:07.939574 2016] [wsgi:error] [pid 12629] ipa: DEBUG: 
ca_is_enabled(version=u'2.164')
[Sat Jun 18 18:46:08.079826 2016] [wsgi:error] [pid 12629] ipa: DEBUG: 
ipaserver.plugins.dogtag.ra.find()
[Sat Jun 18 18:46:08.080263 2016] [wsgi:error] [pid 12629] ipa: DEBUG: 
ipaserver.plugins.dogtag.ra.find(): request: 
[Sat Jun 18 18:46:08.080339 2016] [wsgi:error] [pid 12629] 
falsefalsefalsefalsefalsetruefalsefalsefalsefalsefalsefalse



On okda, going to Certificates list yields ”Certificate operation cannot be 
completed: Unable to communicate with CMS (Internal Server Error)”
and error_log contains:
[Sat Jun 18 18:59:10.100983 2016] [wsgi:error] [pid 748083] ipa: DEBUG: WSGI 
wsgi_dispatch.__call__:
[Sat Jun 18 18:59:10.101728 2016] [wsgi:error] [pid 748083] ipa: DEBUG: WSGI 
jsonserver_session.__call__:
[Sat Jun 18 18:59:10.102146 2016] [wsgi:error] [pid 748083] ipa: DEBUG: found 
session cookie_id = b5e06452ed9aa125f497913ce7703e2d
[Sat Jun 18 18:59:10.103128 2016] [wsgi:error] [pid 748083] ipa: DEBUG: found 
session data in cache with id=b5e06452ed9aa125f497913ce7703e2d
[Sat Jun 18 18:59:10.103506 2016] [wsgi:error] [pid 748083] ipa: DEBUG: 
jsonserver_session.__call__: session_id=b5e06452ed9aa125f497913ce7703e2d 
start_timestamp=2016-06-18T18:53:51 access_timestamp=2016-06-18T18:59:10 
expiration_timestamp=2016-06-18T19:18:05
[Sat Jun 18 

Re: [Freeipa-users] Multiple issues (weblogin, DNS) with 4.3.1

2016-06-18 Thread Tomasz Torcz
On Fri, Jun 17, 2016 at 11:32:22AM +0200, Petr Vobornik wrote:
> On 27.5.2016 14:28, Tomasz Torcz wrote:
> > Hi,
> > 
> >   In my home environment I'm using two-server FreeIPA configuration on 
> > Fedora.
> > Initially installed on fedora 19 in November 2013, it have been upgraded 
> > every
> > Fedora release. It generally works OK, but somewhat degrades during 
> > operation.
> > Recently I've jumped to F24 in hope my problems will be resolved, but they 
> > weren't.
> > Thus this email and plea for assistance.
> > 
> >   I'm using freeipa-server-4.3.1-1.fc24.x86_64. One of the servers is called
> > kaitain.pipebreaker.pl, the other okda.pipebreaker.pl.
> > 
> >   Currently I encounter following main problems:
> > 1) named is not servicing all the records from LDAP
> > 2) can't login to WebUI on kaitain.pipebreaker.pl
> > 3) can't login to WebUI on okda.pipebreaker.pl
> > 4) pycparser.lextab/lextab.py/yacctab.py permission errors
> 
> 
> Switch IPA framework to debug mode as described below. It should show
> more information.
> 
> 
> Httpd error_log should at least show which operation encountered the
> Gateway timeout. If not, then put IPA framework into debug mode:
> 
> http://www.freeipa.org/page/Troubleshooting#Administration_Framework


  Thanks Petr! While editing /etc/ipa/defualt.conf to enable debug
I've noticed my previous errors.  Few weeks ago I was having problems
with certmonger not re-requesting certificates. In order to point 
certmonger to the other IPA server, I've edited host= line
in default.conf.
  After all I must have mixed things up, and _both_ mine IPA servers
had the other host entered in host= line. After entering correct
names, I can log into both web uis.

  Most of the functions work, but 5) I cannot get Authentication→Certificates
list:

on kaitain, after going into Authentication -> Certificates list I got
ethernal spinning in browser, and error_log contains:
[Sat Jun 18 18:46:07.665264 2016] [wsgi:error] [pid 12629] ipa: DEBUG: WSGI 
wsgi_dispatch.__call__:
[Sat Jun 18 18:46:07.665458 2016] [wsgi:error] [pid 12629] ipa: DEBUG: WSGI 
jsonserver_session.__call__:
[Sat Jun 18 18:46:07.665637 2016] [wsgi:error] [pid 12629] ipa: DEBUG: found 
session cookie_id = 47c42943141700c4968c2c2f3f050848
[Sat Jun 18 18:46:07.666035 2016] [wsgi:error] [pid 12629] ipa: DEBUG: found 
session data in cache with id=47c42943141700c4968c2c2f3f050848
[Sat Jun 18 18:46:07.666169 2016] [wsgi:error] [pid 12629] ipa: DEBUG: 
jsonserver_session.__call__: session_id=47c42943141700c4968c2c2f3f050848 
start_timestamp=2016-06-18T18:42:34 access_timestamp=2016-06-18T18:46:07 
expiration_timestamp=2016-06-18T19:06:01
[Sat Jun 18 18:46:07.666268 2016] [wsgi:error] [pid 12629] ipa: DEBUG: storing 
ccache data into file "/var/run/ipa_memcached/krbcc_12629"
[Sat Jun 18 18:46:07.667531 2016] [wsgi:error] [pid 12629] ipa: DEBUG: 
set_session_expiration_time: duration_type=inactivity_timeout duration=1200 
max_age=1466354363.67 expiration=1466269567.67 (2016-06-18T19:06:07)
[Sat Jun 18 18:46:07.938034 2016] [wsgi:error] [pid 12629] ipa: DEBUG: Created 
connection context.ldap2_139873368474448
[Sat Jun 18 18:46:07.938202 2016] [wsgi:error] [pid 12629] ipa: DEBUG: WSGI 
jsonserver.__call__:
[Sat Jun 18 18:46:07.938293 2016] [wsgi:error] [pid 12629] ipa: DEBUG: WSGI 
WSGIExecutioner.__call__:
[Sat Jun 18 18:46:07.938652 2016] [wsgi:error] [pid 12629] ipa: DEBUG: raw: 
cert_find(version=u'2.164')
[Sat Jun 18 18:46:07.938900 2016] [wsgi:error] [pid 12629] ipa: DEBUG: 
cert_find(exactly=False, all=False, raw=False, version=u'2.164')
[Sat Jun 18 18:46:07.939225 2016] [wsgi:error] [pid 12629] ipa: DEBUG: raw: 
ca_is_enabled(version=u'2.164')
[Sat Jun 18 18:46:07.939574 2016] [wsgi:error] [pid 12629] ipa: DEBUG: 
ca_is_enabled(version=u'2.164')
[Sat Jun 18 18:46:08.079826 2016] [wsgi:error] [pid 12629] ipa: DEBUG: 
ipaserver.plugins.dogtag.ra.find()
[Sat Jun 18 18:46:08.080263 2016] [wsgi:error] [pid 12629] ipa: DEBUG: 
ipaserver.plugins.dogtag.ra.find(): request: 
[Sat Jun 18 18:46:08.080339 2016] [wsgi:error] [pid 12629] 
falsefalsefalsefalsefalsetruefalsefalsefalsefalsefalsefalse



On okda, going to Certificates list yields ”Certificate operation cannot be 
completed: Unable to communicate with CMS (Internal Server Error)”
and error_log contains:
[Sat Jun 18 18:59:10.100983 2016] [wsgi:error] [pid 748083] ipa: DEBUG: WSGI 
wsgi_dispatch.__call__:
[Sat Jun 18 18:59:10.101728 2016] [wsgi:error] [pid 748083] ipa: DEBUG: WSGI 
jsonserver_session.__call__:
[Sat Jun 18 18:59:10.102146 2016] [wsgi:error] [pid 748083] ipa: DEBUG: found 
session cookie_id = b5e06452ed9aa125f497913ce7703e2d
[Sat Jun 18 18:59:10.103128 2016] [wsgi:error] [pid 748083] ipa: DEBUG: found 
session data in cache with id=b5e06452ed9aa125f497913ce7703e2d
[Sat Jun 18 18:59:10.103506 2016] [wsgi:error] [pid 748083] ipa: DEBUG: 
jsonserver_session.__call__: session_id=b5e06452ed9aa125f497913ce7703e2d 
start_timestamp=2016-06-18T18:53:51 

Re: [Freeipa-users] Multiple issues (weblogin, DNS) with 4.3.1

2016-06-17 Thread Petr Vobornik
On 27.5.2016 14:28, Tomasz Torcz wrote:
> Hi,
> 
>   In my home environment I'm using two-server FreeIPA configuration on Fedora.
> Initially installed on fedora 19 in November 2013, it have been upgraded every
> Fedora release. It generally works OK, but somewhat degrades during operation.
> Recently I've jumped to F24 in hope my problems will be resolved, but they 
> weren't.
> Thus this email and plea for assistance.
> 
>   In the meantime there was a problem with expired certificates, but it solved
> with the help of rcrit on IRC.
> 
>   I'm using freeipa-server-4.3.1-1.fc24.x86_64. One of the servers is called
> kaitain.pipebreaker.pl, the other okda.pipebreaker.pl.
> 
>   Currently I encounter following main problems:
> 1) named is not servicing all the records from LDAP
> 2) can't login to WebUI on kaitain.pipebreaker.pl
> 3) can't login to WebUI on okda.pipebreaker.pl
> 4) pycparser.lextab/lextab.py/yacctab.py permission errors
> 
>   More details:
> -
> ad 1) named problems
>   Recently I've added new  host entry to my zone (.pipebreaker.pl). It is
>  visible in CLI, but named doesn't resolve it:
> 
> $ ipa dnsrecord-find pipebreaker.pl microstation 
>   Record name: microstation
>    record: 2001:6a0:200:d1::2
> 
> Number of entries returned 1
> 
> 
> $ host microstation ; host microstation.pipebreaker.pl
> Host microstation not found: 3(NXDOMAIN)
> Host microstation.pipebreaker.pl not found: 3(NXDOMAIN)
> 
>   Entries added previously resolve fine.  I see no errors reported
>  in named-pkcs11.service logs.
>   
> -
> 
> ad 2) can't login to webui at kaitain
>   When I open a WebUI while having valid ticket, I'm shown my user page,
> i.e. https://kaitain.pipebreaker.pl/ipa/ui/#/e/user/details/zdzichu is opened.
>   But when I logout from WebUI and try to login as admin, I receive:
>  
>  The password or username you entered is incorrect.
>   
>   The password is certainly correct, I can use it for 'kinit admin' 
> successfully. 
>  /var/log/httpd/error log contains:
> 
> [Fri May 27 14:17:37.104341 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] mod_wsgi (pid=1882): Exception 
> occurred processing WSGI script '/usr/share/ipa/wsgi.py'.
> [Fri May 27 14:17:37.106932 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] Traceback (most recent call last):
> [Fri May 27 14:17:37.106985 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File "/usr/share/ipa/wsgi.py", line 
> 63, in application
> [Fri May 27 14:17:37.107436 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] return 
> api.Backend.wsgi_dispatch(environ, start_response)
> [Fri May 27 14:17:37.107461 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 261, in 
> __call__
> [Fri May 27 14:17:37.107769 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] return self.route(environ, 
> start_response)
> [Fri May 27 14:17:37.107786 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 273, in route
> [Fri May 27 14:17:37.107808 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] return app(environ, start_response)
> [Fri May 27 14:17:37.107829 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 943, in 
> __call__
> [Fri May 27 14:17:37.107848 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] self.kinit(user, 
> self.api.env.realm, password, ipa_ccache_name)
> [Fri May 27 14:17:37.107887 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 965, in kinit
> [Fri May 27 14:17:37.107918 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] raise 
> CCacheError(message=unicode(e))
> [Fri May 27 14:17:37.136615 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] CCacheError: Major (851968): 
> Unspecified GSS failure.  Minor code may provide more information, Minor 
> (2529639107): No credentials cache found
> 
>   What cache is it talking about?  How can I refresh it?
> 


Switch IPA framework to debug mode as described below. It should show
more information.

> -
> 
> 
> ad 3) cannot login to webui on okda
>
>   When I go to https://okda.pipebreaker.pl/ipa/ui/ (the other server), I see 
> "Loading…" screen
>  for couple of seconds, and afterwards "Gateway timeout" message. Everything
>  seems to be running on this server:
> 
> root@okda ~$ ipactl status
> WARNING: yacc table file version is out of 

Re: [Freeipa-users] Multiple issues (weblogin, DNS) with 4.3.1 @ Fedora 24

2016-06-17 Thread Tomasz Torcz
On Mon, May 30, 2016 at 01:45:40PM +0200, Petr Spacek wrote:
> Fedora 24 is broken at the moment so there is nothing you can do before it is
> fixed & released.
> 
> Sorry.

  Petr, could you be more specific what is broken?  We just signed F24 to be
released in current state. There were no FreeIPA builds for Fedora since
March this year, and I'm little afraid about this.

-- 
Tomasz Torcz"Funeral in the morning, IDE hacking
xmpp: zdzich...@chrome.plin the afternoon and evening." - Alan Cox



signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Multiple issues (weblogin, DNS) with 4.3.1 @ Fedora 24

2016-05-30 Thread Petr Spacek
On 27.5.2016 14:28, Tomasz Torcz wrote:
> Hi,
> 
>   In my home environment I'm using two-server FreeIPA configuration on Fedora.
> Initially installed on fedora 19 in November 2013, it have been upgraded every
> Fedora release. It generally works OK, but somewhat degrades during operation.
> Recently I've jumped to F24 in hope my problems will be resolved, but they 
> weren't.
> Thus this email and plea for assistance.
> 
>   In the meantime there was a problem with expired certificates, but it solved
> with the help of rcrit on IRC.
> 
>   I'm using freeipa-server-4.3.1-1.fc24.x86_64. One of the servers is called
> kaitain.pipebreaker.pl, the other okda.pipebreaker.pl.
> 
>   Currently I encounter following main problems:
> 1) named is not servicing all the records from LDAP
> 2) can't login to WebUI on kaitain.pipebreaker.pl
> 3) can't login to WebUI on okda.pipebreaker.pl
> 4) pycparser.lextab/lextab.py/yacctab.py permission errors
> 
>   More details:
> -
> ad 1) named problems
>   Recently I've added new  host entry to my zone (.pipebreaker.pl). It is
>  visible in CLI, but named doesn't resolve it:
> 
> $ ipa dnsrecord-find pipebreaker.pl microstation 
>   Record name: microstation
>    record: 2001:6a0:200:d1::2
> 
> Number of entries returned 1
> 
> 
> $ host microstation ; host microstation.pipebreaker.pl
> Host microstation not found: 3(NXDOMAIN)
> Host microstation.pipebreaker.pl not found: 3(NXDOMAIN)
> 
>   Entries added previously resolve fine.  I see no errors reported
>  in named-pkcs11.service logs.
>   
> -
> 
> ad 2) can't login to webui at kaitain
>   When I open a WebUI while having valid ticket, I'm shown my user page,
> i.e. https://kaitain.pipebreaker.pl/ipa/ui/#/e/user/details/zdzichu is opened.
>   But when I logout from WebUI and try to login as admin, I receive:
>  
>  The password or username you entered is incorrect.
>   
>   The password is certainly correct, I can use it for 'kinit admin' 
> successfully. 
>  /var/log/httpd/error log contains:
> 
> [Fri May 27 14:17:37.104341 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] mod_wsgi (pid=1882): Exception 
> occurred processing WSGI script '/usr/share/ipa/wsgi.py'.
> [Fri May 27 14:17:37.106932 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] Traceback (most recent call last):
> [Fri May 27 14:17:37.106985 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File "/usr/share/ipa/wsgi.py", line 
> 63, in application
> [Fri May 27 14:17:37.107436 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] return 
> api.Backend.wsgi_dispatch(environ, start_response)
> [Fri May 27 14:17:37.107461 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 261, in 
> __call__
> [Fri May 27 14:17:37.107769 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] return self.route(environ, 
> start_response)
> [Fri May 27 14:17:37.107786 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 273, in route
> [Fri May 27 14:17:37.107808 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] return app(environ, start_response)
> [Fri May 27 14:17:37.107829 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 943, in 
> __call__
> [Fri May 27 14:17:37.107848 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] self.kinit(user, 
> self.api.env.realm, password, ipa_ccache_name)
> [Fri May 27 14:17:37.107887 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 965, in kinit
> [Fri May 27 14:17:37.107918 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] raise 
> CCacheError(message=unicode(e))
> [Fri May 27 14:17:37.136615 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] CCacheError: Major (851968): 
> Unspecified GSS failure.  Minor code may provide more information, Minor 
> (2529639107): No credentials cache found
> 
>   What cache is it talking about?  How can I refresh it?
> 
> -
> 
> 
> ad 3) cannot login to webui on okda
>
>   When I go to https://okda.pipebreaker.pl/ipa/ui/ (the other server), I see 
> "Loading…" screen
>  for couple of seconds, and afterwards "Gateway timeout" message. Everything
>  seems to be running on this server:
> 
> root@okda ~$ ipactl status
> WARNING: yacc table file version is out of date
> Directory Service: RUNNING
> krb5kdc Service: RUNNING
> kadmin Service: RUNNING
> 

[Freeipa-users] Multiple issues (weblogin, DNS) with 4.3.1

2016-05-27 Thread Tomasz Torcz
Hi,

  In my home environment I'm using two-server FreeIPA configuration on Fedora.
Initially installed on fedora 19 in November 2013, it have been upgraded every
Fedora release. It generally works OK, but somewhat degrades during operation.
Recently I've jumped to F24 in hope my problems will be resolved, but they 
weren't.
Thus this email and plea for assistance.

  In the meantime there was a problem with expired certificates, but it solved
with the help of rcrit on IRC.

  I'm using freeipa-server-4.3.1-1.fc24.x86_64. One of the servers is called
kaitain.pipebreaker.pl, the other okda.pipebreaker.pl.

  Currently I encounter following main problems:
1) named is not servicing all the records from LDAP
2) can't login to WebUI on kaitain.pipebreaker.pl
3) can't login to WebUI on okda.pipebreaker.pl
4) pycparser.lextab/lextab.py/yacctab.py permission errors

  More details:
-
ad 1) named problems
  Recently I've added new  host entry to my zone (.pipebreaker.pl). It is
 visible in CLI, but named doesn't resolve it:

$ ipa dnsrecord-find pipebreaker.pl microstation 
  Record name: microstation
   record: 2001:6a0:200:d1::2

Number of entries returned 1


$ host microstation ; host microstation.pipebreaker.pl
Host microstation not found: 3(NXDOMAIN)
Host microstation.pipebreaker.pl not found: 3(NXDOMAIN)

  Entries added previously resolve fine.  I see no errors reported
 in named-pkcs11.service logs.
  
-

ad 2) can't login to webui at kaitain
  When I open a WebUI while having valid ticket, I'm shown my user page,
i.e. https://kaitain.pipebreaker.pl/ipa/ui/#/e/user/details/zdzichu is opened.
  But when I logout from WebUI and try to login as admin, I receive:
 
 The password or username you entered is incorrect.
  
  The password is certainly correct, I can use it for 'kinit admin' 
successfully. 
 /var/log/httpd/error log contains:

[Fri May 27 14:17:37.104341 2016] [wsgi:error] [pid 1882] [remote 
2001:470:71:68d:216:eaff:fec2:68b4:28] mod_wsgi (pid=1882): Exception occurred 
processing WSGI script '/usr/share/ipa/wsgi.py'.
[Fri May 27 14:17:37.106932 2016] [wsgi:error] [pid 1882] [remote 
2001:470:71:68d:216:eaff:fec2:68b4:28] Traceback (most recent call last):
[Fri May 27 14:17:37.106985 2016] [wsgi:error] [pid 1882] [remote 
2001:470:71:68d:216:eaff:fec2:68b4:28]   File "/usr/share/ipa/wsgi.py", line 
63, in application
[Fri May 27 14:17:37.107436 2016] [wsgi:error] [pid 1882] [remote 
2001:470:71:68d:216:eaff:fec2:68b4:28] return 
api.Backend.wsgi_dispatch(environ, start_response)
[Fri May 27 14:17:37.107461 2016] [wsgi:error] [pid 1882] [remote 
2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 261, in __call__
[Fri May 27 14:17:37.107769 2016] [wsgi:error] [pid 1882] [remote 
2001:470:71:68d:216:eaff:fec2:68b4:28] return self.route(environ, 
start_response)
[Fri May 27 14:17:37.107786 2016] [wsgi:error] [pid 1882] [remote 
2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 273, in route
[Fri May 27 14:17:37.107808 2016] [wsgi:error] [pid 1882] [remote 
2001:470:71:68d:216:eaff:fec2:68b4:28] return app(environ, start_response)
[Fri May 27 14:17:37.107829 2016] [wsgi:error] [pid 1882] [remote 
2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 943, in __call__
[Fri May 27 14:17:37.107848 2016] [wsgi:error] [pid 1882] [remote 
2001:470:71:68d:216:eaff:fec2:68b4:28] self.kinit(user, self.api.env.realm, 
password, ipa_ccache_name)
[Fri May 27 14:17:37.107887 2016] [wsgi:error] [pid 1882] [remote 
2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 965, in kinit
[Fri May 27 14:17:37.107918 2016] [wsgi:error] [pid 1882] [remote 
2001:470:71:68d:216:eaff:fec2:68b4:28] raise CCacheError(message=unicode(e))
[Fri May 27 14:17:37.136615 2016] [wsgi:error] [pid 1882] [remote 
2001:470:71:68d:216:eaff:fec2:68b4:28] CCacheError: Major (851968): Unspecified 
GSS failure.  Minor code may provide more information, Minor (2529639107): No 
credentials cache found

  What cache is it talking about?  How can I refresh it?

-


ad 3) cannot login to webui on okda
   
  When I go to https://okda.pipebreaker.pl/ipa/ui/ (the other server), I see 
"Loading…" screen
 for couple of seconds, and afterwards "Gateway timeout" message. Everything
 seems to be running on this server:

root@okda ~$ ipactl status
WARNING: yacc table file version is out of date
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful

 There are no logs generated in