Fixes to make the YaST modules work #48
Conversation
pzirnik
commented
Feb 26, 2019
pzirnik
commented
- add pkcs12 password to dialog
- fix dialog from fully qualified "domain name" to "host name"
- add info text to dialog that root dn does not append suffix per default
- make pk12util use the password to extract the certificate
- install CA certificate to system trust ring
- create ldap client configuration that commandline ldap tools work
- get server certificate nickname and create valid ldif to use the certificate
- comment out debug printout of kdb5_ldap_util command
- use directory server hostname in ldap request in kerberos setup not fqdn
- move creation of krb5.conf and kdc.conf prior trying to use kdb5_ldap_util
- add pkcs12 password to dialog - fix dialog from fully qualified "domain name" to "host name" - add info text to dialog that root dn does not append suffix per default - make pk12util use the password to extract the certificate - install CA certificate to system trust ring - create ldap client configuration that commandline ldap tools work - get server certificate nickname and create valid ldif to use the certificate - comment out debug printout of kdb5_ldap_util command - use directory server hostname in ldap request in kerberos setup not fqdn - move creation of krb5.conf and kdc.conf prior trying to use kdb5_ldap_util
- fix install missing krb5-plugin-kdb-ldap - fix enable dirsrv service - fix enable kdc service - fix enable kadmin service
…n.servide can use After=dirsrv.target
|
I think that #49 is going to replace/conflict with most of this due to the changes in how TLS is enabled in 389-ds due to upstream changes. 389-ds is becoming "more opinionated" and the name of the cert should actually be Server-Cert. So. I think allowing this name as a flexible option is actually going to be a conflict in the future. Perhaps a better direction for us to take, is to have the yast module accept the cert and key as PEM files, then we create the pkcs12 with the correct naming schemes for import. Given that cert management is difficult to painful at the best of times, especially with pkcs12 files, this would certainly help users have an easier time with 389-ds setups. EDIT: Upstream plans to have their CLI tools take PEM files to transform and insert into the cert db, so perhaps once those are implemented we can take advantage of those? |
Aligning with upstream sounds like the best approach. As little conversions as possible will increase the reliability and predictability of using this module. That was the original aim for this PR anyway AFAIK. |
|
Sounds good. Thanks for the PR, and I hope we can use some of your work in the future :) |
The kudos for that PR belong to @pzirnik who has imho made a great effort in also resolving some krb server related issues. As the #49 do not address krb related issues, @jreidinger could perhaps check if some of the changes from this PR (#48) might be reusable to fix some of the krb setup problems? |
|
@hcderaad well, I am not maintainer of this module and neither yast team. it used to be maintained by Howard and I think that now @Firstyear maintains it, or am I wrong? |
|
@hcderaad I think that some of the changes here are still applicable, so let's rework it to make it work in light of #49. I think that "technically" I'm the "official" maintainer now, as I'm hired by SUSE Labs to work on 389 Directory Server, which by virtue means I inherit this code too. But I'd appreciate all the help I can get here please! Thanks, |
|
On Tue, 2 Apr 2019, Firstyear wrote:
@hcderaad I think that some of the changes here are still applicable, so let's rework it to make it work in light of #49.
I think that "technically" I'm the "official" maintainer now, as I'm hired by SUSE Labs to work on 389 Directory Server, which by virtue means I inherit this code too. But I'd appreciate all the help I can get here please! Thanks,
I will rework my kerberos changes based on latest and do a new pull request,
if this is ok ?
regards,
Tami
…--
Paul "Tami" Zirnik, Senior Support Specialist, SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
Maxfeldstr.5, D-90409 Nuremberg, T: +49-911-74053-377 F: +49-911-74053-679
|
|
@pzirnik Sounds great to me, I look forward to seeing the reworked PR. Also happy to discuss any ideas or questions you have. Thanks! |
@Firstyear Excellent news, welcome on board :-) Very much looking forward to some improvements on this component. If there is anything to test, please drop me a line! |
|
I prepared a patchset to fix the SLE-15-GA branch both for ldap and kerberos. |
|
Hope everything is going well :) I'm reviewing old and open PRs in YaST modules (both, maintained by us and by other teams, like this) and just wondering if it is time for closing this PR or instead you plan to continue moving it forward. Thanks! |
|
I think we can close this as we agreed we'd make a reworked pr if needed. :) |
