On 09/02/2015 10:37 PM, Simo Sorce wrote:
On Wed, 2015-09-02 at 15:22 -0400, Simo Sorce wrote:
On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote:
On 08/26/2015 11:27 PM, Simo Sorce wrote:
This patchset implements https://fedorahosted.org/freeipa/ticket/2888
and introduces a number of required  changes and dependencies to achieve
this goal.
This work requires the custodia project to securely transfer keys
between ipa servers.

This work is not 100% complete, it still misses the ability to install
kra instances and the ability to install a CA (via ipa-ca-install) with
externally signed certs.

However it is massive enough that warrants review and pushing, the resat
of the changes can be applied later as this work should not disrupt the
classic install methods.

In order to build my previous patches (530-533) are needed as well as a
number of updated components.

I used the following coprs for testing:
abbra/sssd-kkdcproxy (for sssd 1.13.1)
lkrispen/389-ds-current (for 389 >
vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7)
mkosek/freeipa-4.2-fedora-22 (misc)
fedora/updates-testing (python-gssapi 1.1.2)

Ludwig's copr is necessary to have a functional DNA plugin in replicas,
eventually his patches should be committed in 389-ds-base when
it will be released.

We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580
that may cause installation issues in some case (re-install of a

The domain must be raised to level 1 in order to use replica promotion.

In order to promote a replica the server must be first joined as a
regular client to the domain.

This is the flow I usually use for testing:

# ipa-client-install
# kinit admin
# ipa-replica-install --promote --setup-ca
<perform operations like add user, get keytabs, get certificates,

These patches are also available in this git tree rebnase on current


I'm running in a issue when upgrading RPMs:

2015-08-31T10:53:32Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
     return_value = self.run()
line 48, in run
line 1596, in upgrade
line 1508, in upgrade_configuration
"/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line
57, in upgrade_instance
"/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line
51, in __gen_keys
   File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in
     ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0])
   File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in
     conn.modify_s(dn, mods)
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
364, in modify_s
     return self.result(msgid,all=1,timeout=self.timeout)
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
465, in result
     resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
469, in result2
     resp_type, resp_data, resp_msgid, resp_ctrls =
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
476, in result3
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
483, in result4
     ldap_result =
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
106, in _ldap_call
     result = func(*args,**kwargs)

2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed,
exception: NO_SUCH_OBJECT: {'desc': 'No such object'}
2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT
No such object
Have you found out what this was about ?

I just found a different probelm affecting ipa-server-upgrade on my
master, it tracebacks trying to update the schema, which is odd:

2015-09-02T19:06:39Z DEBUG   [5/8]: updating schema
2015-09-02T19:06:39Z DEBUG flushing 
ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket from SchemaCache
2015-09-02T19:06:39Z DEBUG retrieving schema for SchemaCache 
conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f7900550ab8>
2015-09-02T19:06:40Z DEBUG Processing schema LDIF file 
2015-09-02T19:06:40Z DEBUG Traceback (most recent call last):
   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
417, in start_creation
     run_step(full_msg, method)
   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
407, in run_step
"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 
299, in __update_schema
     dm_password='', ldapi=True) or self.modified
   File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", 
line 131, in update_schema
     for oids_set in _get_oid_dependency_order(new_schema, cls):
   File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", 
line 59, in _get_oid_dependency_order
     unordered_oids = set(tree)
   File "/usr/lib64/python2.7/site-packages/ldap/cidict.py", line 27, in 
     return self.data[lower(key)]
   File "/usr/lib64/python2.7/string.py", line 228, in lower
     return s.lower()
AttributeError: 'int' object has no attribute 'lower'

Any ideas about this ?
FYI: replicated this on the second replica too...

I can plod through by manually hacking the script to skip the schema
update check, but this never happened before, did some patch recently
land that changed how schemas are handled ?


We did not change schemaupdater code.
I saw this issue yesterday for first time.
I have to inspect this, python-ldap may be broken or some py3 cahnges could break it.


Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to