Description of problem: When using the engine-manage-domains tool and providing the list of LDAP servers with the -ldapServers option the list of Kerberos servers given by the DNS are ignored, thus an incorrect /etc/ovirt-engine/krb5.conf file is created. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. Setup a system where the names of the LDAP and Kerberos servers are different. 2. Run the engine-manage-domains tool with the -ldapServers option specifying the names of the LDAP servers. Actual results: The generated /etc/ovirt-engine/krb5.conf file is incorrect, it contains the names of the LDAP servers instead of the names of the Kerberos servers. Something like this: [realms] THE.REALM = { kdc = the.ldap.server } Expected results: The file should contain something like this: [realms] THE.REALM = { kdc = the.kerberos.server } Additional info: The workaround is to manually modify the generated /etc/ovirt-engine/krb5.conf file, but it will be overwritten the next time that the engine-manage-domains tool runs. Thanks to Jonas Israelsson for finding and reporting this.
I posted a patch which adds "--resolve-kdc" argument which forces KDC servers to be resolved. With this patch engine-manage-domains has this behavior: 1) Add domain without --ldap-servers and without --resolve-kdc - LDAP servers are resolved from DNS and same servers are used as KDC servers in krb5.conf 2) Add domain with --ldap-servers and without --resolve-kdc - LDAP servers are set by user and same servers are used as KDC servers krb5.conf 3) Add domain without --ldap-servers and with --resolve-kdc - LDAP servers are resolved from DNS and separately KDC servers are resolved from DNS (LDAP server don't have to be same as KDC servers) 4) Add domain with --ldap-servers and with --resolve-kdc - LDAP servers are set by user and separately KDC servers are resolved from DNS (LDAP server don't have to be same as KDC servers) The same is used when editing a domain. Arthur, do you agree with this approach?
This is an automated message. Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.
Too much automation, merged only to master.
This is an automated message oVirt 3.4.1 has been released: * should fix your issue * should be available at your local mirror within two days. If problems still persist, please make note of it in this bug report.