Description of problem: When trying to install ovirt-server ace spits chips when trying to set ipa-defaultoptions --maxusername=12. Even when I enter this command on my ipa-server itself it faults. ovirt-server is on a separate host. Version-Release number of selected component (if applicable): ipa-admintools-1.2.2-2.fc12.i686 How reproducible: Every time Steps to Reproduce: 1. install default IPA server with any domain name and ensure system is running 2. ipa-defaultoptions --maxusername=12 [root@ipa ~]# ipa-defaultoptions --maxusername=12 Traceback (most recent call last): File "/usr/share/ipa/ipaserver/ipaxmlrpc.py", line 179, in _marshaled_dispatch response = self._dispatch(method, params) File "/usr/share/ipa/ipaserver/ipaxmlrpc.py", line 212, in _dispatch ret = func(*args) File "/usr/lib/python2.6/site-packages/ipaserver/funcs.py", line 2196, in update_ipa_config classes = self.__get_objectclasses(opts) File "/usr/lib/python2.6/site-packages/ipaserver/funcs.py", line 350, in __get_objectclasses for i in range(len(objectclasses)): TypeError: object of type 'NoneType' has no len()
*** This bug has been marked as a duplicate of bug 518544 ***
Hi, I have the same error on fedora core 12 during the ovirt-installation (with ace). The command "ipa-defaultoptions --maxusername=12" does not work and return the python error listed above. I don't think it's a duplicate of bug 518544. RPM : ipa-client-1.2.2-1.fc12.x86_64 device-mapper-multipath-libs-0.4.9-5.fc12.x86_64 ipa-python-1.2.2-1.fc12.x86_64 ipa-server-1.2.2-1.fc12.x86_64 ipa-server-selinux-1.2.2-1.fc12.x86_64 ipa-admintools-1.2.2-1.fc12.x86_64
ace log (ovirt-installer) : debug: //freeipa::bundled/Single_exec[ipa_modify_username_length]: Executing '/usr/sbin/ipa-defaultoptions --maxusername=12' debug: Executing '/usr/sbin/ipa-defaultoptions --maxusername=12' err: //freeipa::bundled/Single_exec[ipa_modify_username_length]/returns: change from notrun to 0 failed: /usr/sbin/ipa-defaultoptions --maxusername=12 returned 1 instead of 0 at /usr/share/ace/modules/ovirt/manifests/freeipa.pp:75
No, this isn't a duplicate, at least not of 518544. This is caused by a change in 389-ds-base where it isn't returning the full schema when querying cn=schema. This is causing our validation of the objectclasses stored in cn=ipaconfig to blow up.
Created attachment 384702 [details] Temporary workaround This is a temporary workaround that skips validating the objectclasses if the schema can't be loaded. This should get you going anyway until the 389 team can fix the underlying bug.
Ok, turns out that the change was the schema attributes are now operational so we have to request them explicitly, new patch coming shortly.
Created attachment 384711 [details] Better fix I'll see about getting this committed upstream and an update published in Fedora.
ipa-1.2.2-3.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/ipa-1.2.2-3.fc12
ipa-1.2.2-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/ipa-1.2.2-2.fc11
ipa-1.2.2-3.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
ipa-1.2.2-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.