On 09/03/2015 02:57 PM, Simo Sorce wrote:
On Thu, 2015-09-03 at 10:57 +0200, Martin Basti wrote:
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.
I bet on py3 changes, somethign cause data to stay as int instead of
being converted to string I would guess.
I have not updated python-ldap so that is unlikely.


It is already fixed, it was py3 change

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

Reply via email to