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:
a)
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
http://pki.fedoraproject.org/wiki/PKI_Known_Issues
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
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.
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
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?
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
_______________________________________________
Freeipa-users mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-users
