Oliver Burtchen wrote:
Hi Dmitri,
hi Rob,

first of all, thanks for your support and the detailed answers. It makes it clearer to me what the goal of freeipa is. I think it would fit exactly my needs for a new soho installation (managing round about 20 clients, some laptops and often changing employees), if some issues can be solved. I'll try to answer to you both together.

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 started to fiddle around with the installation process, because it breaks by bug a) after solving it I saw bug b), and so on.. ;-) After that, I came to the conclusion it would be better to setup dns and dogtag by hand. But it would be great just to use ipa-server-install. So here are my observations with hopefully helpful solution-hints, as I wrote them down for myself.

By the way, thanks for the great work to the FreeIPA-Team so far.

Bugs and solution-hints:

The installation-process of pki/dogtag (pkicreate/pkisilent) throws an exception and breaks down documented in the logs, if the locale is different from „en“. This is not because of missing translations, but because of a wrong use of java-load-resources (filenames) in the pki-sources, so it does not find the english fallbacks (which are the only ones for now, what is okay). As I described in this bugreport https://bugzilla.redhat.com/show_bug.cgi?id=441974#c34 it is very obviously and easy to fix, but now pending for 2 years.

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.

And the dogtag Known Issues: Problems and Solutions – page

just says: „Change LC_CTYPE to en_US before starting and everything will work“.

Okay, I understand. Sounds a little bit like what I heard often: Change OS_TYPE to MS before starting and everything will work. Just kidding. ;-)

But it should not be difficult to change a handfull of filenames, so this great peace of software would work all over the world, not just in the english locale. I don't want to comment this any further. ;-)

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?

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

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.

Thoughts and wishes which could be realized with no big effort:

Email for zone-manager in bind-setup should be asked/customizeable (r...@domain.name is IMHO not a good choice). Maybe this option/answer should also be used as „o=IPA,e=mana...@domain.name“ 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

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,e=mana...@domain.name". 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?

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:

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:


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,

This is great feedback, thanks!


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

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.


Best regards,

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,
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.


Freeipa-users mailing list

Reply via email to