https://bugzilla.redhat.com/show_bug.cgi?id=857688 (Fedora)
Description of problem: ipa-client-install fails with the following error: Traceback (most recent call last): File "/sbin/ipa-client-install", line 1789, in <module> sys.exit(main()) File "/sbin/ipa-client-install", line 1775, in main rval = install(options, env, fstore, statestore) File "/sbin/ipa-client-install", line 1531, in install configure_ipa_conf(fstore, cli_basedn, cli_realm, cli_domain, cli_server) File "/sbin/ipa-client-install", line 503, in configure_ipa_conf ipaconf.newConf(target_fname, opts) File "/usr/lib/python2.7/site-packages/ipaclient/ipachangeconf.py", line 450, in newConf output = self.dump(options) File "/usr/lib/python2.7/site-packages/ipaclient/ipachangeconf.py", line 156, in dump output += self.dump(o['value'], level+1) File "/usr/lib/python2.7/site-packages/ipaclient/ipachangeconf.py", line 164, in dump output += self.indent[level]+o['name']+self.dassign+o['value']+self.deol TypeError: cannot concatenate 'str' and 'DN' objects Version-Release number of selected component (if applicable): freeipa-client-3.0.0-0.5.fc18.x86_64 This is running against a RHEL 6.3 IPA server How reproducible: run ipa-client-install, accept auto discovered defaults, wait for failure Actual results: The host entry is created on the IPA server, however the client is not configured properly. Let me know what other information you may need. Additional info:
This is a regression in 3.0 development. Pushed as a one-liner change.
master: 79b89f4[[BR]] ipa-3-0: 54bb250
I'm going to reopen this because the fix looks wrong and there seems to be other issues as well.
The fix was to convert self.basedn to a str.
self.basedn = str(realm_to_suffix(self.realm))
but this violates our current guidelines for dn usage. dn's are always supposed to be DN objects, virtually everything now accepts them. DN objects work correctly when used in a string context.
Also there is this code in the module:
basedn = get_ipa_basedn(lh) self.basedn = basedn
I'm not sure what get_ipa_basedn() returns, it appears somehow this function was missed in the DN conversion work, but it should be returning a DN object, not a string.
The real problem is not the fact self.basedn is a DN object, but rather the incorrect use of the concatenation operator in ipachangeconf.dump().
output += self.indent[level]+o['name']+self.dassign+o['value']+self.deol
In Python the plus operator means concatenation and you can only concatenate similar objects. What the dump() function is doing is forming a string, therefore it should be using string operations. I had to fix similar things in many places. It seems as if the early IPA developers mistakenly used concatenation for forming strings in many places rather than string formatting (Python != Java). Concatenation only works when everything is a string and there is no such guarantee, it was a lucky accident it worked.
What we need to do is assure Python automatically converts the objects to a string if it's not one already. This automatic conversion does not occur with concatenation but it does with string formatting. Thus the right way to form a string with multiple components whose object type is not known is to use a format string and provide the objects. For example:
output = foo + bar
should instead be:
output = '%s%s' % (foo, bar)
The reason this works is because '%s%s' is a string and the %s format conversion specifiers tells Python it needs to call str() on the object being substituted. Thus you're guaranteed the lhs will be a string and that the objects used to form it will be converted to a string first.
Thus there are several issues which need addressing:
My previous intentions were to produce a hotfix for next release since there was Fedora user having this issue. But what you propose is perfectly sound and will be more consistent with DN usage. Moving to RC2 bucket.
attachment freeipa-mkosek-316-improve-dn-usage-in-ipa-client-install.patch
Patch freeipa-mkosek-316-improve-dn-usage-in-ipa-client-install.patch sent for review
master: 1a74017[[BR]] ipa-3-0: c398d0b
Metadata Update from @mkosek: - Issue assigned to mkosek - Issue set to the milestone: FreeIPA 3.0 RC2
Login to comment on this ticket.