Am Freitag, 16. April 2010 15:43:52 schrieb Rob Crittenden: > ... > > Just to remember, I'm using the latest IPA V2 from the repository > > http://jdennis.fedorapeople.org/ipa-devel/fedora/12/... I found that in > > the docs and hope its the best source. And I'm using a clean F12 > > installation with all updates. > > I don't know about "best" but it is basically our daily builds. So buyer > beware :-)
I'm aware of this. ;-) > ... > Hmm, it seems like this should have been fixed in > https://bugzilla.redhat.com/show_bug.cgi?id=442310 . > I think the best thing to do would be to open a new bug and reference > this old one. Bug 441974 is currently closed so is likely not on > anyone's radar. Okay, I reported a new one: https://bugzilla.redhat.com/show_bug.cgi?id=583177 It's just I'm not a fan of flooding bugzilla with same reports. > ... > Yes, I wasn't aware of this restriction myself. I think it is definitely > something that should be addressed. We are trying to be UTF-8 friendly > in v2 and currently have 8 or 9 translations of the IPA management > framework (though no German translation yet). > > For a short-term fix would it be acceptable if we set LC_CTYPE to en_US > when installing dogtag? I agree with it as a work around. Best practice IMHO would be: Insert a "LANG=en_US" at top in /etc/init.d/pki-cad an run pkicreate/pkisilent/pkiremove/... as # LANG=en_US pkicreate ... in ipa-server-install and friends. > > > b) > > Using „ipa-server-install --setup-dns“, the SOA Records in DNS are wrong. > > > > There are missing trailing dots for server-name und email, at > > reverse-zone also in the zone-name. To look at this, just use dig and dig > > -x on domain, changing it directly in ldap corrects it.. > > > > Should be easy to fix in ipaserver/install/bindinstance.py > > Martin, can you look into this? I filed > https://bugzilla.redhat.com/show_bug.cgi?id=583023 > ... > > c) > > manpage ipa-server-install(1): there is no short-option -U for > > --uninstall, it's bogus with --unattended > > Gah, good catch. I pushed this as a one-liner fix. Great, thanks. Btw, is it better to report such things in bugzilla, here on the list, or both? As I said, I'm not a fan of flooding bugzilla. > > > Thoughts and wishes which could be realized with no big effort: > > > > d) > > Email for zone-manager in bind-setup should be asked/customizeable > > ([email protected] is IMHO not a good choice). Maybe this option/answer > > should also be used as „o=IPA,[email protected]“ in base-subject for > > certificates, when –subject is not set by user. > > We do something similar when installing dogtag. We set -admin_email to > r...@localhost. > > I filed https://bugzilla.redhat.com/show_bug.cgi?id=583027 Thanks! > > > e) > > To me, ipa is more an organisational unit, not the organisation of an > > individual soho ipa installation. IMHO a better choice for the default > > subject (if not given by option) used by certificates would be „o=Local > > Security Domain,ou=IPA,[email protected]". This could be academic > > ;-) , but it's easier to find the certs in an certificate manager > > (firefox for example), and it is clearer that there is no official/global > > IPA CA or trust center with the name IPA. > > Yeah, my picking o=IPA was truly arbitrary. I'm open to further > suggestions. By "Local Security Domain" do you mean substitute the > domain name for this or literally use that string? Well, I looked around a little bit, there seams no reserved or common dn/subject-name or something like this for local/private installs of a ca. I only found a rfc about reserved domain names for local installs: http://tools.ietf.org/html/rfc2606 So my best guesses, if we don't want to ask the user for the organization name (but asking would be great): literally use "o=Local Security Domain,ou=FreeIPA,e=..." or literally use "o=Localhost Security Domain,ou=FreeIPA,e=..." or "o=<domain> Security Domain,ou=FreeIPA,e=..." where in the last example <domain> should be replaced with the FQDN (without server) or the uppercase kerberos realm. Best regards, Oli > > > f) > > The default valid-range in dogtag for ca-signing cert is 2 years, others > > are a half year. This is a little bit short. Signing certs for a ca are > > normaly good for 10 years, and if I think about the release-schedule und > > updates of fedora, the cert for clients/servers should be valid for at > > least 1 ½ year in this context. > > I'll let the dogtag guys comment on this. I agree that 2 years for a CA > sounds a bit short. > > > Thoughts and wishes for the future: > > > > g) > > Currently only SHA1withRSA is used/supported by the pkisilent > > installation, but it is a little bit outdated. Despite this, the > > dogtag-system supports the successors like SHA256, etc. out of the box. > > There was a discussion about it here: > > > > https://www.redhat.com/archives/pki-users/2010-April/msg00007.html > > > > Currently you have to renewal your initial certs with dogtag by hand, to > > get this modern hash-alg. It would be nice, if ipa-server-install would > > give an option to choose the hash-alg as soon, as pkisilent does. > > Yes, I think that if they add this capability we would want to take > advantage of it. > > > Okay, hope it was not to much for one posting, > > best regards, > > Oli > > This is great feedback, thanks! > > rob > > > Am Dienstag, 13. April 2010 19:58:23 schrieb Rob Crittenden: > >> Oliver Burtchen wrote: > >>> Hi Rob, > >>> > >>> thanks for the answer. I know about the externel CA-Cert possibility of > >>> ipa- server- install. But it does not what I want. > >>> > >>> I did setup a dogtag ca and a fedora-ds (389). It would be nice, if > >>> freeipa could just use them. I find it a little bit inconsitent that > >>> dogtag tries to be a central service, and freeipa claims to be the > >>> same, setting up a new one. > >> > >> Well, it gets tricky because we need an RA certificate in IPA and there > >> is no automated way to get this with an existing dogtag installation. > >> This is why making IPA a subordinate CA is suggested, so you can > >> continue with your existing central authority. > >> > >> I'm sure it's possible to wedge in an existing dogtag instance, it would > >> just take a bit of work and lots of code reading. Among the things you'd > >> have to do are: > >> > >> - change the dogtag ports in IPA > >> - have your CA issue an RA certificate and trust that user in the > >> existing CA > >> - load that RA cert and private key into /etc/httpd/alias using the > >> right nickname > >> - set the right CA type in /etc/ipa/default.conf on the IPA server > >> > >> Perhaps some other things I'm missing. I'm not sure how cloning will > >> work in this case. > >> > >>> BTW.: Freeipa setup tells me, that it should be the only 389-instance, > >>> and exist gracefully. Well, my dogtag and bind setup with 389-backend > >>> works quiet well, i just want freeipa to use them. > >> > >> IPA is really geared for configuration on a fresh install. We have to > >> touch so many things the installation is difficult as it is. Having to > >> integrate with a lot of existing services makes this doubly more > >> difficult. You can always disable the check (only via code now, no > >> arguments for this). > >> > >>> Is there a possibility to setup freeipa this way? Thanks for the all in > >>> one setup, but it means I cannot run an other ldap (389) > >>> server(-instance) on a machine where freeipa is running. Is this right? > >> > >> You can't if it is already installed, at least not without a small code > >> change. > >> > >> We have to use the 80/20 rule here and try to have some control over the > >> initial environment before trying the installation. It is probably > >> possible to do what you want given time and patience but we are unlikely > >> to do this in the near future. > >> > >> rob > >> > >>> Best regards, > >>> Oli > >>> > >>> Am Freitag, 9. April 2010 23:42:54 schrieb Rob Crittenden: > >>>> Oliver Burtchen wrote: > >>>>> Hi @all, > >>>>> > >>>>> is it possible to use an already configured und running > >>>>> dogtag-instance for freeipa V2 in the installation process? I would > >>>>> like to give ipa-server- install just the params for the > >>>>> dogtag-instance/server to use, and skip its own creation-process > >>>>> (pkisilence ...). > >>>>> > >>>>> Or are there arguments for an extra CA used by freeipa? > >>>>> > >>>>> Background: I customized dogtag for my needs (using SHA256, default > >>>>> to 10 year validity of ca-SigningCert, organization and location > >>>>> defaults, etc. ). > >>>>> > >>>>> Best regards, > >>>>> Oli > >>>> > >>>> Probably the best way to do it would be to use the external CA install > >>>> option (--external-ca). This is a two-step installation process. The > >>>> first step generates a CSR for the IPA CA. You take this CSR to your > >>>> existing CA and issue a subordinate CA certificate that will be used > >>>> by IPA. Then you continue the IPA Installation and it sets up a > >>>> separate dogtag instance with this subordinate CA. > >>>> > >>>> It might be possible to wedge in an existing dogtag install into IPA > >>>> in another way but I haven't yet tried it. > >>>> > >>>> rob > -- Oliver Burtchen, Berlin _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
