Re: [Freeipa-users] Centos7, selinux, certmonger, and openldap
On 08/04/2014 07:06 PM, Nordgren, Bryce L -FS wrote: Hmm, sorry for incomplete instructions then. I updated the instructions to cope with that situation better (details in https://fedorahosted.org/freeipa/ticket/4466#comment:2). Please feel free to report more findings or even better help us enhance the page even further :-) Hmm, I thought it looked like your wiki, but when there was no login in the upper-right corner, I assumed it was an online version of your manual. That always gets me, even when I'm looking at a page I know I created myself. Ah, that's a useful UXD feedback as it seems. BTW, to log in, check Log in / create account with OpenID in the LOWER right corner... In this case, tho, I was definitely not qualified to provide a fix. New to both certmonger and that Mozilla certificate database thing. Don't worry, you will get there. Made a comment on the talk page about the related OpenLDAP selinux issues (more than one cert_t defined). Dunno if you get notifications. Ok. IMO this is a valid bug, system policy should allow certmonger to manage other cert types. Thanks for filing it. Martin -- 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] RHEL 7 Upgrade experience so far
On 08/05/2014 12:03 AM, Erinn Looney-Triggs wrote: On 08/04/2014 01:51 PM, Ade Lee wrote: OK - I suspect you may be running into an issue with serial number generation. Each time we install a clone, we end up allocating a new range of serial numbers for the clone. The idea is to keep separate ranges for each CA replica so that no two replicas can issue certs with the same serial number. The problem is that you've probably retried the install a whole bunch of times and now perhaps the serial number range is too high. This is just a guess - but you can see what ranges have been assigned by looking in : 1, ou-ranges, o=ipaca (on the master directory server) 2. CS.cfg for the master (look for the attributes dbs.* 3. The value of the attribute nextRange on : ou=certificateRepository, o=ipaca and ou=Requests, o=ipaca Please send me that info, and I'll explain how to clean that up. Ade On Mon, 2014-08-04 at 12:10 -0700, Erinn Looney-Triggs wrote: On 08/04/2014 11:48 AM, Ade Lee wrote: OK - so its not really even getting started on the install. My guess is there is some cruft from previous installs/uninstalls that was not cleaned up. Is there anything in the directory server logs on the RHEL7 machine? What operation is being attempted that the server is refusing to perform? Ade Ok I moved on past this issue. Problem was minssf was set to 56 on the RHEL 7 dirsrv instance, setting it to 0 resolved this issue. Thanks for having me check the dir on the RHEL 7 instance I was assuming it was hitting against the RHEL 6.5 instance and was finding basically nothing there. This run looks like it pulled a lot more information in but it still errored out. ipa : DEBUGstderr=pkispawn: WARNING ... unable to validate security domain user/password through REST interface. Interface not available pkispawn: ERROR... Exception from Java Configuration Servlet: Error in confguring system certificatesjava.security.cert.CertificateException: Unable to initialize, java.io.IOException: DerInput.getLength(): lengthTag=127, too big. ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpbTnSRM' returned non-zero exit status 1 From the /var/log/pki/pki-tomcat/ca/debug log on the RHEL 7 instance: [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: initializing with mininum 3 and maximum 15 connections to host ipa2.abaqis.com port 389, secure connection, false, authentication type 1 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: increasing minimum connections by 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new total available connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new number of connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: In LdapBoundConnFactory::getConn() [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: masterConn is connected: true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: conn is connected true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: mNumConns now 2 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS: param=preop.internaldb.post_ldif [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif file = /usr/share/pki/ca/conf/vlv.ldif [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif file copy to /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): LDAP Errors in importing /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allInvalidCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allInValidCertsNotBefore-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allNonRevokedCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allRevokedCaCerts-pki-tomcat, cn=ipaca, cn=ldbm database,
Re: [Freeipa-users] RHEL 7 Upgrade experience so far
On 08/04/2014 10:41 PM, Erinn Looney-Triggs wrote:
On 08/04/2014 08:46 AM, Rob Crittenden wrote:
Erinn Looney-Triggs wrote:
On 08/04/2014 04:01 AM, Martin Kosek wrote:
On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote:
Whether related or not I am getting the following in my
RHEL 6.5 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug
log:
[26/Jul/2014:20:23:23 +] slapi_ldap_bind - Error:
could not send startTLS re quest: error -1 (Can't contact
LDAP server) errno 107 (Transport endpoint is not
connected) [26/Jul/2014:20:23:23 +]
NSMMReplicationPlugin - agmt=cn=masterAgreement1-i
pa2.example.com-pki-ca (ipa2:7389): Replication bind with
SIMPLE auth failed: LD AP error -1 (Can't contact LDAP
server) ((null)) [26/Jul/2014:20:23:37 +]
slapi_ldap_bind - Error: could not send startTLS re quest:
error -1 (Can't contact LDAP server) errno 107 (Transport
endpoint is not connected) [26/Jul/2014:20:23:48 +]
slapi_ldap_bind - Error: could not send startTLS re quest:
error -1 (Can't contact LDAP server) errno 107 (Transport
endpoint is not connected)
And these errors just continue to be logged.
When attempting to run ipa-ca-install -d on the RHEL 7
replica (all other services are on there running fine) I
receive the following:
ipa : CRITICAL failed to configure ca instance
Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF'
returned non-zero exit status 1 ipa : DEBUG
File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 638, in run_script
return_value = main_function()
File /usr/sbin/ipa-ca-install, line 179, in main CA =
cainstance.install_replica_ca(config, postinstall=True)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 1678, in install_replica_ca
subject_base=config.subject_base)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 478, in configure_instance
self.start_creation(runtime=210)
File
/usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 364, in start_creation method()
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 604, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
ipa : DEBUGThe ipa-ca-install command failed,
exception: RuntimeError: Configuration of CA failed
Your system may be partly configured. Run
/usr/sbin/ipa-server-install --uninstall to clean up.
Configuration of CA failed
So this behavior changed after restarting the IPA service
on the RHEL 6.5 system.
So at this point I have a RHEL 6.5 system and a RHEL 7
replica of everything except the CA. The RHEL 6.5 system,
when the IPA service is restarted throws an error, perhaps
from schema change?
Any ideas?
-Erinn
I went in and debugged this a bit further by changing the
verbosity for nsslapd-errorlog-level. It appears that the
rhel 6.5 system is attempting to connect to the RHEL 7 system
on port 7389 and since the RHEL 7 system does not have the CA
installed this would obviously fail. This leads me to believe
that there is cruft in the directory that is pointing to the
wrong place. I don't think this will fix my second group of
errors, but how does one view the replication agreements
specifically for the ca?
As well I omitted to lines from the ipa-ca-install error
which are probably pertinent:
ERROR: Unable to access directory server: Server is
unwilling to perform
ipa : DEBUGstderr=
-Erinn
This is strange. ipa-ca-install/ipa-replica-install --setup-ca
should create the replication agreement pointing at port 389
on RHEL-7.0, given that the 2 originally separated DS databases
were merged.
It looks like this is some replication agreement left over
from previous tests.
Anyway, to list all hosts with PKI, try:
# ipa-csreplica-manage list Directory Manager password:
vm-089.idm.lab.bos.redhat.com: master
vm-086.idm.lab.bos.redhat.com: master
master means that this server has PKI service installed. It
will show different value if there is no PKI service.
To check PKI replication agreements for specific hostname,
run:
# ipa-csreplica-manage list `hostname` Directory Manager
password:
vm-089.idm.lab.bos.redhat.com
Check man ipa-csreplica-manage for advise how to delete or
create the PKI agreements.
HTH, Martin
Yeah here is what I get: ipa-csreplica-manage list Directory
Manager password:
ipa2.example.com: CA not configured ipa.example.com: master
ipa2 is my rhel7 instance, ipa is the rhel 6.5 instance.
ipa-csreplica-manage list ipa2.example.com Directory Manager
password:
Can't contact LDAP server
Which I guess makes sense, however: ipa-csreplica-manage list -v
ipa.example.com Directory Manager password:
ipa2.example.com last init status: None last init ended: None
last update status: -1 - LDAP error: Can't contact LDAP server
last update ended: None ipa2.example.com
Re: [Freeipa-users] IPA Replica does not start Bind but runs Manually
Hi, I got this solved but the replica doesn't do it's forwards on the zone's it need to foreward for, the master with the same settings does. I have done a new install but the same happens. WHat could be wrong here ? Cheers, Matt 2014-08-04 10:13 GMT+02:00 Martin Kosek mko...@redhat.com: On 08/04/2014 09:40 AM, Matt . wrote: Hi, Yes I did in the past. THe DNS tabs are there and named is installed. You probably installed DNS service on another FreeIPA server. However, there is a configuration space telling which server has which services configured. It seems that it does not see your current server as the DNS server. Can I run that over without any issue ? Yes, If it detects that DNS service was already installed there it will error out. Then we will do different route. In any other case I just can reinstall the ipa software on the replica and create a new setup for it... Let's not go this way (yet), simple DNS service installation should be work. Martin -- 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
[Freeipa-users] Building previous release rpms are failing
Hey, I have been trying to build rpms from different releases without much success. I can build 4.0+ rpms but I have not tested them. Going backward like with release-3-3-5, it fails on lint/pylint routine. I comment out the lint call in the Makefile and further along it cannot find some ui files. I got this setup to use docker to generate the rpms. Included below are the sequences and commands. for current release that does build without intervention: # docker run -ti --name freeipa-devel-rpms-container knighcl/freeipa-devel-rpms:fedora-20 release-4-0-1 or for master # docker run -ti --name freeipa-devel-rpms-container knighcl/freeipa-devel-rpms:fedora-20 for previous release # docker run -ti --name freeipa-devel-rpms-container knighcl/freeipa-devel-rpms:fedora-20 release-3-3-5 Once dropped into the terminal upon finishing, I edit the Makefile to comment out the make-lint line within the lint stanza #./make-lint $(LINT_OPTIONS) run 'make rpms' again to get beyond lint errors shown below cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi ./make-lint Traceback (most recent call last): File ./make-lint, line 272, in module sys.exit(main()) File ./make-lint, line 243, in main linter.check(files) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 626, in check self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 712, in check_astroid_module walker.walk(astroid) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 712, in walk cb(astroid) File /usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py, line 135, in visit_function args=(call.args[0].name, )) AttributeError: 'Getattr' object has no attribute 'name' make: *** [lint] Error 1 The final errors from the build are below. I tried to find the jdennis building/ci script to see if there is something I am missing but I am guessing it is on the build system. This was an exercise on building rpms and learning docker to possibly help the developers out with a new process. I do not need to do this successfully but thought you might want to know that something might not be proper. Regards, Curtis rpm 3.3.5 log /usr/bin/mkdir -p '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/dojo' /usr/bin/install -c -m 644 -p dojo.js '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/dojo' make[6]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/dojo' make[5]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/dojo' Making install in freeipa make[5]: Entering directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' ../../util/make-ui.sh Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/compile.sh: line 114: pushd: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa: No such file or directory Invalid build dir: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa make[6]: Entering directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' make[6]: Nothing to be done for `install-exec-am'. ../../util/make-ui.sh Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/compile.sh: line 114: pushd: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa: No such file or directory Invalid build dir: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa /usr/bin/mkdir -p '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/freeipa' /usr/bin/install -c -m 644 -p ./app.js '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/freeipa' /usr/bin/install: cannot stat './app.js': No such file or directory make[6]: *** [install-appDATA] Error 1 make[6]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' make[5]: *** [install-am] Error 2 make[5]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' make[4]: ***
Re: [Freeipa-users] Building previous release rpms are failing
On 08/05/2014 12:05 PM, Curtis L. Knight wrote: Hey, I have been trying to build rpms from different releases without much success. I can build 4.0+ rpms but I have not tested them. Going backward like with release-3-3-5, it fails on lint/pylint routine. I comment out the lint call in the Makefile and further along it cannot find some ui files. You could also run $ make rpms DEVELOPER_MODE=1 to have the lint run, but ignored it's results (though fixing the bug it is better of course). I got this setup to use docker to generate the rpms. Included below are the sequences and commands. for current release that does build without intervention: # docker run -ti --name freeipa-devel-rpms-container knighcl/freeipa-devel-rpms:fedora-20 release-4-0-1 or for master # docker run -ti --name freeipa-devel-rpms-container knighcl/freeipa-devel-rpms:fedora-20 for previous release # docker run -ti --name freeipa-devel-rpms-container knighcl/freeipa-devel-rpms:fedora-20 release-3-3-5 Once dropped into the terminal upon finishing, I edit the Makefile to comment out the make-lint line within the lint stanza #./make-lint $(LINT_OPTIONS) run 'make rpms' again to get beyond lint errors shown below cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi ./make-lint Traceback (most recent call last): File ./make-lint, line 272, in module sys.exit(main()) File ./make-lint, line 243, in main linter.check(files) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 626, in check self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 712, in check_astroid_module walker.walk(astroid) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 712, in walk cb(astroid) File /usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py, line 135, in visit_function args=(call.args[0].name, )) AttributeError: 'Getattr' object has no attribute 'name' make: *** [lint] Error 1 This is new, I created upstream ticket to timely fix it: https://fedorahosted.org/freeipa/ticket/4475 The final errors from the build are below. I tried to find the jdennis building/ci script to see if there is something I am missing but I am guessing it is on the build system. This was an exercise on building rpms and learning docker to possibly help the developers out with a new process. I do not need to do this successfully but thought you might want to know that something might not be proper. Regards, Curtis rpm 3.3.5 log /usr/bin/mkdir -p '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/dojo' /usr/bin/install -c -m 644 -p dojo.js '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/dojo' make[6]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/dojo' make[5]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/dojo' Making install in freeipa make[5]: Entering directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' ../../util/make-ui.sh Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/compile.sh: line 114: pushd: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa: No such file or directory Invalid build dir: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa make[6]: Entering directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' make[6]: Nothing to be done for `install-exec-am'. ../../util/make-ui.sh Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/compile.sh: line 114: pushd: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa: No such file or directory Invalid build dir: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa /usr/bin/mkdir -p '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/freeipa' /usr/bin/install -c -m 644 -p ./app.js
Re: [Freeipa-users] Building previous release rpms are failing
On 08/05/2014 12:32 PM, Martin Kosek wrote: On 08/05/2014 12:05 PM, Curtis L. Knight wrote: ... #./make-lint $(LINT_OPTIONS) run 'make rpms' again to get beyond lint errors shown below cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi ./make-lint Traceback (most recent call last): File ./make-lint, line 272, in module sys.exit(main()) File ./make-lint, line 243, in main linter.check(files) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 626, in check self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 712, in check_astroid_module walker.walk(astroid) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 712, in walk cb(astroid) File /usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py, line 135, in visit_function args=(call.args[0].name, )) AttributeError: 'Getattr' object has no attribute 'name' make: *** [lint] Error 1 This is new, I created upstream ticket to timely fix it: https://fedorahosted.org/freeipa/ticket/4475 Ticket 4475 is now fixed, thanks to Jan Cholasta. ipa-3-3 branch should now build OK again. Martin -- 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] RHEL 7 Upgrade experience so far
On Tue, 2014-08-05 at 09:08 +0200, Martin Kosek wrote: On 08/05/2014 12:03 AM, Erinn Looney-Triggs wrote: On 08/04/2014 01:51 PM, Ade Lee wrote: OK - I suspect you may be running into an issue with serial number generation. Each time we install a clone, we end up allocating a new range of serial numbers for the clone. The idea is to keep separate ranges for each CA replica so that no two replicas can issue certs with the same serial number. The problem is that you've probably retried the install a whole bunch of times and now perhaps the serial number range is too high. This is just a guess - but you can see what ranges have been assigned by looking in : 1, ou-ranges, o=ipaca (on the master directory server) 2. CS.cfg for the master (look for the attributes dbs.* 3. The value of the attribute nextRange on : ou=certificateRepository, o=ipaca and ou=Requests, o=ipaca Please send me that info, and I'll explain how to clean that up. Ade On Mon, 2014-08-04 at 12:10 -0700, Erinn Looney-Triggs wrote: On 08/04/2014 11:48 AM, Ade Lee wrote: OK - so its not really even getting started on the install. My guess is there is some cruft from previous installs/uninstalls that was not cleaned up. Is there anything in the directory server logs on the RHEL7 machine? What operation is being attempted that the server is refusing to perform? Ade Ok I moved on past this issue. Problem was minssf was set to 56 on the RHEL 7 dirsrv instance, setting it to 0 resolved this issue. Thanks for having me check the dir on the RHEL 7 instance I was assuming it was hitting against the RHEL 6.5 instance and was finding basically nothing there. This run looks like it pulled a lot more information in but it still errored out. ipa : DEBUGstderr=pkispawn: WARNING ... unable to validate security domain user/password through REST interface. Interface not available pkispawn: ERROR... Exception from Java Configuration Servlet: Error in confguring system certificatesjava.security.cert.CertificateException: Unable to initialize, java.io.IOException: DerInput.getLength(): lengthTag=127, too big. ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpbTnSRM' returned non-zero exit status 1 From the /var/log/pki/pki-tomcat/ca/debug log on the RHEL 7 instance: [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: initializing with mininum 3 and maximum 15 connections to host ipa2.abaqis.com port 389, secure connection, false, authentication type 1 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: increasing minimum connections by 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new total available connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new number of connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: In LdapBoundConnFactory::getConn() [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: masterConn is connected: true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: conn is connected true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: mNumConns now 2 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS: param=preop.internaldb.post_ldif [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif file = /usr/share/pki/ca/conf/vlv.ldif [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif file copy to /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): LDAP Errors in importing /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allInvalidCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allInValidCertsNotBefore-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allNonRevokedCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca
Re: [Freeipa-users] RHEL 7 Upgrade experience so far
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Here you go: dbs.beginReplicaNumber=1 dbs.beginRequestNumber=1 dbs.beginSerialNumber=1 dbs.enableSerialManagement=true dbs.endReplicaNumber=50 dbs.endRequestNumber=990 dbs.endSerialNumber=ff6 dbs.ldap=internaldb dbs.newSchemaEntryAdded=true dbs.replicaCloneTransferNumber=5 dbs.replicaDN=ou=replica dbs.replicaIncrement=100 dbs.replicaLowWaterMark=20 dbs.replicaRangeDN=ou=replica, ou=ranges dbs.requestCloneTransferNumber=1 dbs.requestDN=ou=ca, ou=requests dbs.requestIncrement=1000 dbs.requestLowWaterMark=200 dbs.requestRangeDN=ou=requests, ou=ranges dbs.serialCloneTransferNumber=1 dbs.serialDN=ou=certificateRepository, ou=ca dbs.serialIncrement=1000 dbs.serialLowWaterMark=200 dbs.serialRangeDN=ou=certificateRepository, ou=ranges Erinn, I still need to see the ldap entries I mentioned above. Those are actually the ones that will need to be changed. Unfortunately, things seem to have gone further south on the RHEL 6.5 CA instance now. This just seems to be my luck on this replica install. From the debug of the ipa-ca-install: ipa : DEBUGStarting external process ipa : DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmp1G6jOw ipa : DEBUGProcess finished, return code=1 ipa : DEBUG stdout=Loading deployment configuration from /tmp/tmp1G6jOw. ERROR: Unable to access security domain: 404 Client Error: Not Found ipa : DEBUGstderr= ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmp1G6jOw' returned non-zero exit status 1 I can see in the apache logs on the RHEL 6.5 instance it errors out: [Mon Aug 04 21:06:02 2014] [error] [client 2001:4870:800e:301:862b:2bff:fe67:704d] File does not exist: /var/www/html/ca This is supposed to be mapped via ajp to localhost:9447 which does appear to be listening. Anyway, I am in the throws of that currently, but let me know if those ranges are out of control big. -Erinn Erinn, I'm a little confused. Perhaps at this point, it would make sense for you to test out your 6.5 instance and confirm that its working/ can issue certs etc. Maybe a restart of IPA on that server could help right things. Could this be caused by https://bugzilla.redhat.com/show_bug.cgi?id=1083878? You could check access log to see what calls are being made by 7.0 replica. This will be fixed in 6.6, I am afraid that for 6.5 you will have to do the update (adding |^/ca/ee/ca/profileSubmit) yourself. Martin You and me both my friend, confusion seems to be par for the course on this particular migration, but hey I am learning a lot and y'all are great help. Actually I think I have figured out why everything went a bit further south, well at least I have a theory I would like to run by you folks. I did a run on the RHEL 7 system of ipa-ca-install that failed probably because of Ade's theory. However, I think at that point the replication agreement was in place and functioning possibly because of the old entries on the RHEL 6.5 system. I then ran a pkidestroy on the RHEL 7 instance to clean things up. I reckon this might have replicated on over because at this point it appears I have no ipaca entries, nor anything functioning in that area on the RHEL 6.5 system. Either that or I have some serious corruption or HW problems. So I am working on a restore from a backup of the directory server info for the CA on the RHEL 6.5 system. All in all, pretty damn funny if that is how it worked out. One way or another the cert info is gone on the RHEL 6.5 system though the cn=config info remains intact. - -Erinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJT4PtuAAoJEFg7BmJL2iPOsr8IAIgS7qnfbXYqJ5bnc2/zXafH w4Y5/zs9JtD19MeA+vFou9D0RlJA4KZ0CDk9gyMnbaM0Yb4H+9rLSF8HIK/B7IzO Cv67gbhDC7ut1L2rBRGMDUzwOlgm3mfukZLRsuWU1age49WayxzLrGLCcBM/8xqf /67etQoNYX4wHYQRPsdnm/8D3RkYPZ3LtxZqkvbxl3LERXhzjsJV5F4Jl7LKK6OE gag0qHIyfzlw7Si/kOzkNusdETRE/ZF4H7/xI/0IbrSIuG8gVovkdVxeBPOCrZ90 w1xlQyArEbIAADhQ5meez4e+MhMGHK+HlKtUHod2iXyWF2GAIR+6v1CMOljSBxs= =13KE -END 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] FreeIPA + Ipsilon
Hi, thanks for the replies.
I am finally managed to install lasso correctly (without lasso-python) but
after the installation of ipsilon-server (ipsilon-server-install --ipa=yes
--secure=no) when I try to connet via browser to:
https://myidp.example.com/idp
I had this error:
[error] mod_wsgi (pid=22357): Target WSGI script '/usr/sbin/ipsilon' cannot
be loaded as Python module.
[error] mod_wsgi (pid=22357): Exception occurred processing WSGI script
'/usr/sbin/ipsilon'.
[error] Traceback (most recent call last):
[error] File /usr/sbin/ipsilon, line 28, in module
[error] from ipsilon.root import Root
[error] File /usr/lib/python2.6/site-packages/ipsilon/root.py, line 26,
in module
[error] from ipsilon.admin.login import LoginPlugins
[error] File /usr/lib/python2.6/site-packages/ipsilon/admin/login.py,
line 48
[error] plugins_by_name = {p.name: p for p in
self._site[FACILITY]['enabled']}
[error] ^
[error] SyntaxError: invalid syntax
with HTTP 500 Internal Server Error (GET /idp HTTP/1.1 500 619)
The line is this one (in
/usr/lib/python2.6/site-packages/ipsilon/admin/login.py):
plugins_by_name = {p.name: p for p in self._site[FACILITY]['enabled']}
The same thing if I try:
ipsilon-client-install --saml-idp-metadata
https://myidp.example.org/idp/saml2/metadata --debug
Thanks in advance.
Luca Tartarini
2014-07-31 13:11 GMT+02:00 Simo Sorce sso...@redhat.com:
On Thu, 2014-07-31 at 09:53 +0200, Luca Tartarini wrote:
Hi,
Thanks for the reply, unfortunately I can not find the package on
Scientific Linux, is there a workaround?
I saw from the lasso mailing list that you built the lasso package
yourself, make sure you built the python bindings, they are part of the
same source tree.
Attached find a .spec file you can use top build lasso on EL6 platforms,
until it will become available officially.
This will build and install the python binding correctly.
Simo.
Thanks.
Luca Tartarini
2014-07-30 15:00 GMT+02:00 Simo Sorce sso...@redhat.com:
On Tue, 2014-07-29 at 15:58 +0200, Martin Kosek wrote:
On 07/29/2014 03:47 PM, Luca Tartarini wrote:
Hi everyone,
I am new in FreeIPA, I am trying to configure FreeIPA with
Ipsilon. The
configuration is the following: Service Provider (host with
Scientific
Linux 6) with ipsilon-client and Identity Provider (another host
with
Scientific Linux 6) with FreeIPA and ipsilon-server, is the
configuration
feasible and/or correct?
If it is, then I am stuck in the installation of ipsilon-client
because
after I installed lasso-2.3.6 and all the ipsilon-client
prerequisites,
when I finally run:
ipsilon-client-install --saml-idp-metadata
https://myidp.example.org/idp/saml2/metadata --saml-auth /wiki
I get this error about lasso:
Traceback (most recent call last):
File /usr/bin/ipsilon-client-install, line 20, in module
from ipsilon.tools.saml2metadata import Metadata
File
/usr/lib/python2.6/site-packages/ipsilon/tools/saml2metadata.py,
line 22, in module
import lasso
File /usr/lib/python2.6/site-packages/lasso.py, line 3, in
module
import _lasso
ImportError: No module named _lasso
Does anyone know if it's a problem about lasso's configuration or I
forgot
something about ipsilon-client?
Thanks in advance.
Luca Tartarini
Not sure, _lasso.so should be provided by lasso-python package:
# rpm -qf /usr/lib64/python2.6/site-packages/_lasso.so
lasso-python-2.4.0-4.el6.x86_64
CCing Simo to advise.
Sounds like lasso-python is missing indeed.
Simo.
--
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] FreeIPA + Ipsilon
On Tue, 2014-08-05 at 17:47 +0200, Luca Tartarini wrote:
Hi, thanks for the replies.
I am finally managed to install lasso correctly (without lasso-python) but
after the installation of ipsilon-server (ipsilon-server-install --ipa=yes
--secure=no) when I try to connet via browser to:
https://myidp.example.com/idp
I had this error:
[error] mod_wsgi (pid=22357): Target WSGI script '/usr/sbin/ipsilon' cannot
be loaded as Python module.
[error] mod_wsgi (pid=22357): Exception occurred processing WSGI script
'/usr/sbin/ipsilon'.
[error] Traceback (most recent call last):
[error] File /usr/sbin/ipsilon, line 28, in module
[error] from ipsilon.root import Root
[error] File /usr/lib/python2.6/site-packages/ipsilon/root.py, line 26,
in module
[error] from ipsilon.admin.login import LoginPlugins
[error] File /usr/lib/python2.6/site-packages/ipsilon/admin/login.py,
line 48
[error] plugins_by_name = {p.name: p for p in
self._site[FACILITY]['enabled']}
[error] ^
[error] SyntaxError: invalid syntax
with HTTP 500 Internal Server Error (GET /idp HTTP/1.1 500 619)
The line is this one (in
/usr/lib/python2.6/site-packages/ipsilon/admin/login.py):
plugins_by_name = {p.name: p for p in self._site[FACILITY]['enabled']}
Uhmm python 2.6, I think it does not support dict comprehension.
You can replace this line with:
dict([p.name, p for p in self._site[FACILITY]['enabled']])
Let me know if that helps.
Simo.
The same thing if I try:
ipsilon-client-install --saml-idp-metadata
https://myidp.example.org/idp/saml2/metadata --debug
Thanks in advance.
Luca Tartarini
2014-07-31 13:11 GMT+02:00 Simo Sorce sso...@redhat.com:
On Thu, 2014-07-31 at 09:53 +0200, Luca Tartarini wrote:
Hi,
Thanks for the reply, unfortunately I can not find the package on
Scientific Linux, is there a workaround?
I saw from the lasso mailing list that you built the lasso package
yourself, make sure you built the python bindings, they are part of the
same source tree.
Attached find a .spec file you can use top build lasso on EL6 platforms,
until it will become available officially.
This will build and install the python binding correctly.
Simo.
Thanks.
Luca Tartarini
2014-07-30 15:00 GMT+02:00 Simo Sorce sso...@redhat.com:
On Tue, 2014-07-29 at 15:58 +0200, Martin Kosek wrote:
On 07/29/2014 03:47 PM, Luca Tartarini wrote:
Hi everyone,
I am new in FreeIPA, I am trying to configure FreeIPA with
Ipsilon. The
configuration is the following: Service Provider (host with
Scientific
Linux 6) with ipsilon-client and Identity Provider (another host
with
Scientific Linux 6) with FreeIPA and ipsilon-server, is the
configuration
feasible and/or correct?
If it is, then I am stuck in the installation of ipsilon-client
because
after I installed lasso-2.3.6 and all the ipsilon-client
prerequisites,
when I finally run:
ipsilon-client-install --saml-idp-metadata
https://myidp.example.org/idp/saml2/metadata --saml-auth /wiki
I get this error about lasso:
Traceback (most recent call last):
File /usr/bin/ipsilon-client-install, line 20, in module
from ipsilon.tools.saml2metadata import Metadata
File
/usr/lib/python2.6/site-packages/ipsilon/tools/saml2metadata.py,
line 22, in module
import lasso
File /usr/lib/python2.6/site-packages/lasso.py, line 3, in
module
import _lasso
ImportError: No module named _lasso
Does anyone know if it's a problem about lasso's configuration or I
forgot
something about ipsilon-client?
Thanks in advance.
Luca Tartarini
Not sure, _lasso.so should be provided by lasso-python package:
# rpm -qf /usr/lib64/python2.6/site-packages/_lasso.so
lasso-python-2.4.0-4.el6.x86_64
CCing Simo to advise.
Sounds like lasso-python is missing indeed.
Simo.
--
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] RHEL 7 Upgrade experience so far
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/04/2014 01:51 PM, Ade Lee wrote: OK - I suspect you may be running into an issue with serial number generation. Each time we install a clone, we end up allocating a new range of serial numbers for the clone. The idea is to keep separate ranges for each CA replica so that no two replicas can issue certs with the same serial number. The problem is that you've probably retried the install a whole bunch of times and now perhaps the serial number range is too high. This is just a guess - but you can see what ranges have been assigned by looking in : 1, ou-ranges, o=ipaca (on the master directory server) 2. CS.cfg for the master (look for the attributes dbs.* 3. The value of the attribute nextRange on : ou=certificateRepository, o=ipaca and ou=Requests, o=ipaca Please send me that info, and I'll explain how to clean that up. Ade Ok, after that brief little side trip down deleting my CA lane, here is what I have for the ranges info: 1. Hmm ok, I'll do the best I can here, LDAP is not yet my forte: dn: ou=ranges,o=ipaca objectClass: organizationalUnit objectClass: top ou: ranges dn: ou=replica,ou=ranges,o=ipaca objectClass: organizationalUnit objectClass: top ou: replica dn: ou=requests,ou=ranges,o=ipaca objectClass: organizationalUnit objectClass: top ou: requests dn: ou=certificateRepository,ou=ranges,o=ipaca objectClass: organizationalUnit objectClass: top ou: certificateRepository dn: cn=1001,ou=requests,ou=ranges,o=ipaca objectClass: pkiRange objectClass: top beginRange: 1001 cn: 1001 endRange: 2000 host: ipa2.example.com SecurePort: 443 dn: cn=1001,ou=certificateRepository,ou=ranges,o=ipaca objectClass: pkiRange objectClass: top beginRange: 1001 cn: 1001 endRange: 2000 host: ipa2.example.com SecurePort: 443 2. dbs.beginReplicaNumber=1 dbs.beginRequestNumber=1 dbs.beginSerialNumber=1 dbs.enableSerialManagement=true dbs.endReplicaNumber=50 dbs.endRequestNumber=990 dbs.endSerialNumber=ff6 dbs.ldap=internaldb dbs.newSchemaEntryAdded=true dbs.replicaCloneTransferNumber=5 dbs.replicaDN=ou=replica dbs.replicaIncrement=100 dbs.replicaLowWaterMark=20 dbs.replicaRangeDN=ou=replica, ou=ranges dbs.requestCloneTransferNumber=1 dbs.requestDN=ou=ca, ou=requests dbs.requestIncrement=1000 dbs.requestLowWaterMark=200 dbs.requestRangeDN=ou=requests, ou=ranges dbs.serialCloneTransferNumber=1 dbs.serialDN=ou=certificateRepository, ou=ca dbs.serialIncrement=1000 dbs.serialLowWaterMark=200 dbs.serialRangeDN=ou=certificateRepository, ou=ranges 3. In ou=ca,ou=ranges,o=ipaca nextRange: 2001 Ditto for ou=certificateRepository,ou=ca,o=ipaca Thanks, - -Erinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJT4SKhAAoJEFg7BmJL2iPOBmUIAKoiE7IOW3ld9ja03L9oOvdc geI56IWSXV2i5p5vln+BWQMvBko724smohWFxCJ88LY4NIXKYIV877+oDUBYX0BO pygaDZp43qTll4mo+0akYk8Ooy/4qpP2a9uslxUH6/KfhmGmo/aF1WPbfmw5t5p3 nfktyOfHp0iaD5nGjfjTlF8jhJ0UQRZxkX49u2zXKMNVZ3Oay7sItziBUtnvXcaD eIeOKjgY3dUuGulqXGqkhSev7ZV5w7WUA8snyDyG/Ls0LZdgYc3+RvdA9DuNxXFL PE36+1tfVIDnVwvwSPz/dKTMs/ThHPBbNQh/7UYVUEe5dVnUIvhVJEHJupFj9xk= =u2/z -END 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] FreeIPA + Ipsilon
On 08/05/2014 07:48 PM, Simo Sorce wrote:
On Tue, 2014-08-05 at 17:47 +0200, Luca Tartarini wrote:
[...]
with HTTP 500 Internal Server Error (GET /idp HTTP/1.1 500 619)
The line is this one (in
/usr/lib/python2.6/site-packages/ipsilon/admin/login.py):
plugins_by_name = {p.name: p for p in self._site[FACILITY]['enabled']}
Uhmm python 2.6, I think it does not support dict comprehension.
You can replace this line with:
dict([p.name, p for p in self._site[FACILITY]['enabled']])
dict((p.name, p) for p in self._site[FACILITY]['enabled'])
(You need the parens around (p.name, p))
--
Petr³
--
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] Replica Cert failed to renew ...
Hmmm so question here .. our domain was originally installed as a 2.x and upgraded to 3.x .. I installed the replicas using the ipa-replica-prepare etc but the CA dirsrv instance was never copied over or started on the replicas (ie no slapd-PKI-* around) .. yet /etc/ipa/defaults.conf points to the replica itself for certmonger - so not sure how that will work given there is no CA copy running on the replica .. In the end the process followed was to change the xmlrpc_uri to the original master and delete and resubit the cert request for Server-Cert for slapd httpd/alias we get an up to date cert ... not sure if anything else broken by doing that though ... I assume maybe the replcia install/mgmt under 2.x was slightly or perhaps majorly different ... rgds Matt On 31/07/2014 6:21 pm, Martin Kosek wrote: (Adding back the users list as this may be interesting for everyone) Ok, the steps suggested below should help. If the DS does not want to start at all because of the expired certificate, you can also edit /etc/dirsrv/slapd-YOUR-REALM/dse.ldif and edit it manually (only when dirsrv service is stopped). Martin On 07/31/2014 09:53 AM, Matt Bryant wrote: Martin, Correct in that the replica does not have a CA and the version being run is $ rpm -qa ipa-server ipa-server-3.0.0-25.el6.x86_64 restarted the services and get Starting dirsrv: SERVER-IPA...[31/Jul/2014:18:00:15 +1000] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's Certificate has expired.) so I think it is just dealing with an expired cert ... so will try the other steps suggested .. rgds Matt Bryant On 31/07/14 17:33, Martin Kosek wrote: On 07/31/2014 07:49 AM, Matt Bryant wrote: All, Got an issue with an IPA replica in that the certs in /etc/httpd/alias /etc/dirsrv/slapd-IPA-REALM have expired. I assume that this replica does not have a CA and we are only dealing with service HTTPD and DIRSRV service certificates. Have tried setting date back before expiry on the replica and doing an 'ipa-getcert resubmit -i id' but that hasn't worked it looks like the CA master is actually rejecting it since the havent set the date back on that server. Error am getting on replica is ... Request ID '20120719044839': status: CA_UNREACHABLE ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates). Isn't this rather a problem that the replica does not trust the master server HTTPD certificate because it's certificates are not valid from replica POV? is there any way of forcing a re-newel or manual process for updating these certs .. ??? If this is just a replica without PKI, I would suggest synchronizing the time back with the master CA server and restarting all the services. If the HTTPD service does not want to start, follow chapter 25.2.2. Starting IdM with Expired Certificates in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/cas.html and then try to resubmit the certificates so that they can be renewed on the master. Do not forget to revert the above configuration changes when you are done. Also, what version of FreeIPA are you running? HTH, Martin -- Matt Bryant Manager - SMB Services | Melbourne IT | Brisbane | Tel +617 3230 7422 | Mob +61431 496663 -- 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] Building previous release rpms are failing
On Tue, Aug 5, 2014 at 7:21 AM, Martin Kosek mko...@redhat.com wrote: On 08/05/2014 12:32 PM, Martin Kosek wrote: On 08/05/2014 12:05 PM, Curtis L. Knight wrote: ... #./make-lint $(LINT_OPTIONS) run 'make rpms' again to get beyond lint errors shown below cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi ./make-lint Traceback (most recent call last): File ./make-lint, line 272, in module sys.exit(main()) File ./make-lint, line 243, in main linter.check(files) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 626, in check self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 712, in check_astroid_module walker.walk(astroid) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 712, in walk cb(astroid) File /usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py, line 135, in visit_function args=(call.args[0].name, )) AttributeError: 'Getattr' object has no attribute 'name' make: *** [lint] Error 1 This is new, I created upstream ticket to timely fix it: https://fedorahosted.org/freeipa/ticket/4475 Ticket 4475 is now fixed, thanks to Jan Cholasta. ipa-3-3 branch should now build OK again. Martin Hey Martin, Tested ipa-3-3 and generated rpms from that branch. Many thanks for the resolution. Just a note, but I verified that ipa-3-2 and ipa-3-1 are in need of the same ipa-3-3 dependency patch. Both also complained that make-lint needed pylint installed which it already was. With the lint failure and rhino patch, ipa-3-2 did generate rpms. With the lint failure and rhino patch, ipa-3-1 did not generate rpms and gave the following logs. Regards, Curtis Report written to /freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui/release/lib/build-report.txt Process finished normally. errors: 0 warnings: 0 build time: 4.62 seconds Invalid option -main Usage: java org.mozilla.javascript.tools.shell.Main [options...] [files] Valid options are: -?, -help Displays help messages. -w Enable warnings. -version 100|110|120|130|140|150|160|170|180 Set a specific language version. -opt [-1|0-9] Set optimization level. -f script-filename Execute script file, or - for interactive. -e script-source Evaluate inline script. -modules [uri] Add a single path or URL element to the CommonJS module search path. (implies -require) -require Enable CommonJS module support. -sandbox Enable CommonJS sandbox mode. (implies -require) -debug Generate debug code. -strictEnable strict mode warnings. -fatal-warningsTreat warnings as errors. -encoding charset Use specified character encoding as default when reading scripts. /freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui/release/lib/freeipa /freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui/build/freeipa /freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui/build/freeipa /usr/bin/mkdir -p '/freeipa/rpmbuild/BUILDROOT/freeipa-3.1.5GIT98f5abe-0.fc20.x86_64/usr/share/ipa/ui/js/freeipa' /usr/bin/install -c -m 644 ./app.js '/freeipa/rpmbuild/BUILDROOT/freeipa-3.1.5GIT98f5abe-0.fc20.x86_64/usr/share/ipa/ui/js/freeipa' /usr/bin/install: cannot stat './app.js': No such file or directory make[6]: *** [install-appDATA] Error 1 make[6]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui/build/freeipa' make[5]: *** [install-am] Error 2 make[5]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui/build/freeipa' make[4]: *** [install-recursive] Error 1 make[4]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui/build' make[3]: *** [install-recursive] Error 1 make[3]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install' make[1]: *** [install] Error 1 make[1]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe' error: Bad exit status from /var/tmp/rpm-tmp.Ex5L4m (%install) RPM build errors: bogus date in %changelog: Thu Aug 17 2012 Martin Kosek mko...@redhat.com - 2.99.0-41 bogus date in %changelog: Fri Jun 21 2012 Sumit Bose sb...@redhat.com - 2.99.0-36 bogus date in %changelog: Fri Jun 21 2012 Rob Crittenden rcrit...@redhat.com - 2.99.0-35 bogus date in %changelog: Fri Jun 21 2012 Petr Vobornik pvobo...@redhat.com - 2.99.0-34 bogus date in %changelog: Wed Mar
Re: [Freeipa-users] Building previous release rpms are failing
Curtis L. Knight wrote: On Tue, Aug 5, 2014 at 7:21 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 08/05/2014 12:32 PM, Martin Kosek wrote: On 08/05/2014 12:05 PM, Curtis L. Knight wrote: ... #./make-lint $(LINT_OPTIONS) run 'make rpms' again to get beyond lint errors shown below cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi ./make-lint Traceback (most recent call last): File ./make-lint, line 272, in module sys.exit(main()) File ./make-lint, line 243, in main linter.check(files) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 626, in check self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 712, in check_astroid_module walker.walk(astroid) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 712, in walk cb(astroid) File /usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py, line 135, in visit_function args=(call.args[0].name, )) AttributeError: 'Getattr' object has no attribute 'name' make: *** [lint] Error 1 This is new, I created upstream ticket to timely fix it: https://fedorahosted.org/freeipa/ticket/4475 Ticket 4475 is now fixed, thanks to Jan Cholasta. ipa-3-3 branch should now build OK again. Martin Hey Martin, Tested ipa-3-3 and generated rpms from that branch. Many thanks for the resolution. Just a note, but I verified that ipa-3-2 and ipa-3-1 are in need of the same ipa-3-3 dependency patch. Both also complained that make-lint needed pylint installed which it already was. With the lint failure and rhino patch, ipa-3-2 did generate rpms. With the lint failure and rhino patch, ipa-3-1 did not generate rpms and gave the following logs. I guess it becomes a bit fuzzy, especially with these versions. We don't usually offer any guarantees that older releases will build against more modern distros, but both 3.1.5 and 3.2.0 crossed that line, with Fedora builds in two releases (F18/19 and F19/20 respectively). Do you have a requirement to use these older releases or are you just offering this data point in case anyone else runs into this? regards 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] RHEL 7 Upgrade experience so far
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ok I am throwing up the white flag on this one and starting anew. Clearly there are several things broken down there in the murky depths, and well I just don't trust my install all that much at this point. Thanks for all the help I really appreciate it. Please remember to take a look at the multiple certs issue for creating a clone in dogtag, as that is a bug for sure. - -Erinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJT4a91AAoJEFg7BmJL2iPOxk8IAIvLoQdw4mkL6CGpzlU8H2go C1OXaS52pd9cX7LLZkNgVYUcaAizyND2cNp7vjwhESRwDcPSBzDWl1jXGhrv/Dp9 TOpP7YvR8WueifgQkqcEVCUf6TEH07v4MXNwkrX6h6eX092583jfXLuzmp3hjO+J cLbWAwuQR5E0xntkfrnWjdjDddWVzUKVUGNO2Da5nIjancGZLaRAgMYIpY3tz0FD F6OVEUQA4eP/xoZlN8bFBLbtLH4n+/pFOF66A0e+9NtXUEtW3Sd+OupTerpDcid9 7YMmJ2kXsyhT3X9Rykm8irMRx6zGNZhf/TUfVg5tLFRzoZ+LvqxY+52SnSL5jwo= =mt1j -END 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
