[Freeipa-users] Using already running dogtag-instance possible?

Fri Apr 16 13:43:52 UTC 2010

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 
> (root at domain.name is IMHO not a good choice). Maybe this option/answer should 
> also be used as „o=IPA,e=manager at 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 
root at 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,e=manager at 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?

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