Re: [Freeipa-users] CA Replication Installation Failing - SOLVED!

[Les Stott]

Guys,

Thanks for your help. You pointed me in the right direction (checking the 
apache logs).

In the end, it was missing modules in httpd.conf on the Master.

I saw this error in /var/log/httpd/error_log

[Wed Feb 04 21:26:00 2015] [warn] proxy: No protocol handler was valid for the 
URL /ca/admin/ca/getStatus. If you are using a DSO version of mod_proxy, make 
sure the proxy submodules are included in the configuration using LoadModule.
[Wed Feb 04 21:26:00 2015] [warn] proxy: No protocol handler was valid for the 
URL /ca/admin/ca/getCertChain. If you are using a DSO version of mod_proxy, 
make sure the proxy submodules are included in the configuration using 
LoadModule.

These modules were not being loaded...

LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so

Now it works.

(well I have a different issue now with setting up a second replica ca, but 
that's another story and better in a new thread)

Thanks,

Les

> -Original Message-
> From: Rob Crittenden [mailto:rcrit...@redhat.com]
> Sent: Thursday, 5 February 2015 2:24 AM
> To: Les Stott; freeipa-users@redhat.com
> Cc: Ade Lee
> Subject: Re: [Freeipa-users] CA Replication Installation Failing
> 
> Les Stott wrote:
> > Has anyone got any ideas on this?
> >
> > I am stuck with not being able to deploy a CA Replica and this is halting
> rollout of the project.
> >
> > Help please...
> >
> > Regards,
> 
> What is the version of IPA on the master you are connecting to?
> 
> Can you confirm on the existing master that /etc/httpd/conf.d/ipa-pki-
> proxy.conf has /ca/ee/ca/profileSubmit in it:
> 
>  # matches for ee port
>  ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/
> updateNumberRange|^/ca/ee/ca/getCRL|^/ca/ee/ca/profileSubmit">
> 
> rob
> 
> >
> > Les
> >
> >> -Original Message-
> >> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> >> boun...@redhat.com] On Behalf Of Les Stott
> >> Sent: Friday, 30 January 2015 4:48 PM
> >> To: freeipa-users@redhat.com
> >> Subject: Re: [Freeipa-users] CA Replication Installation Failing
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> >>> boun...@redhat.com] On Behalf Of Les Stott
> >>> Sent: Wednesday, 10 December 2014 6:22 PM
> >>> To: freeipa-users@redhat.com
> >>> Subject: Re: [Freeipa-users] CA Replication Installation Failing
> >>>
> >>>
> >>>
>  -Original Message-
>  From: Ade Lee [mailto:a...@redhat.com]
>  Sent: Wednesday, 10 December 2014 5:05 AM
>  To: Les Stott
>  Cc: freeipa-users@redhat.com
>  Subject: Re: [Freeipa-users] CA Replication Installation Failing
> 
>  On Tue, 2014-12-09 at 07:48 +, Les Stott wrote:
> >
> >
> >
> 
> >>>
> __
>  
> > From: freeipa-users-boun...@redhat.com
> > [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal
> > [d...@redhat.com]
> > Sent: Tuesday, December 09, 2014 3:49 PM
> > To: freeipa-users@redhat.com
> > Subject: Re: [Freeipa-users] CA Replication Installation Failing
> >
> >
> >
> > On 12/08/2014 11:04 PM, Les Stott wrote:
> >
> >> Does anyone have any ideas on the below errors when trying to add
> >> CA replication to an existing replica?
> >>
> >>
> >
> >> People who might be able to help are or PTO right now.
> >>
> >> Is your installation older than 2 years?
> >
> > No, December 2013 was when it was originally built.
> >
> >> Did you generate a new replica package or use the original one?
> >
> > I used the original replica file for serverb, based on
> > instructions i came across. I can try regenerating the replica file.
> >
> > Interestingly, now that you mention it, servera had to be restored
> > a couple of months back. Perhaps this is an issue and regenerating
> > the replica file for serverb will be required.
> >
> > I will try this.
> >
> 
>  I think that this is a safe bet to be the problem.
> 
>  The error in the log snippet you posted says:
> 
>   The pkcs12 file is not correct.
> 
>  This indicates that the clone CA was unable to decode the pkcs12
>  file in the replica.  Perhaps the certs changed -- or the DM
>  password
> >> changed?
> 
>  Ade
> >>>
> >>> I regenerated the replica file and retired the CA replica setup, but
> >>> it failed at the same point with the same error.
> >>>
> >>> I am thinking that the next step is to uninstall the ipa replica to
> >>> cleanup, remove all traces and re-add as a replica on serverb.
> >>>
> >>> I wonder if the cert that its having an issue with is the one on
> >>> serverB under /etc/ipa/ca.crt which is fr

[Freeipa-users] ipa replica (centos 6.5) integrate with AD 2008

[alireza baghery]

hi
i integrated ipa (centos 6.5) with AD windows server 2008 and anything do
work
i install replica server as follow:
   #(ipaserve ipa): replica- prepare ipareplica. example. com - - ip-
address  192. 168. 1. 2
  scp /var/lib/ipa/replica- info- ipareplica. example. com. gpg
root@ipareplica: /var/lib/ipa/
  ipa- replica- install  --setup- dns - -forwarder=IP-AD
/var/lib/ipa/replica- info- ipareplica. example. com. gpg
but ipareplica do not work
i turn off ipa sserver (master) but clients do not work with replica.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] Automember enrolledby

[Mark Esman]

Thanks for the info Rob,

Well, that's a big bummer. I am trying to write kickstart scripts
with different IPA usernames such that they will automatically enroll
machines into specific hostgroups (with associated 
permissions/roles/etc). Thanks for updating the ticket...


I don't know if there's going to be a port/update for Centos 7 for
freeipa 4, but even the "automember-rebuild" feature wouldn't really
be a viable option for my situation.

Anyone else run into similar situations and have any ideas?

Mark

On 2/4/2015 5:21 PM, Rob Crittenden wrote:

Mark Esman wrote:

Hello all,

I'm having a little trouble with the automember function using
"enrolledby" attribute. I have tried a number of different regex's
to define the username and automagically enroll the host into the
specified host group:

   .*ipainstaller.*  
   ".*ipainstaller.*"  
   '.*ipainstaller.*'  
   etc.

After client install, the server command:

server#> ipa host-find machine.example.com --all

shows: enrolledby_user: ipainstaller  
but the machine is not enrolled in the assigned host group.

My server is Centos 7 with ipa-server.x86_64 3.3.3-28.0.1.el7.centos.3
from the updates repo.

I found this link, but it doesn't look like any work has been
done on this issue. https://fedorahosted.org/freeipa/ticket/3598

Has anyone seen this issue and/or have a workaround?



automember is executed when new entries are added. The enrolled_by isn't
set at the same time the host is added so it isn't triggering the rule.

IPA 4.0 added an automember-rebuild which would pick this up but you'd
need to run this periodically.

I updated the ticket with this information as well.

rob



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] Automember enrolledby

[Rob Crittenden]

Mark Esman wrote:
> Hello all,
> 
> I'm having a little trouble with the automember function using
> "enrolledby" attribute. I have tried a number of different regex's
> to define the username and automagically enroll the host into the
> specified host group:
> 
>   .*ipainstaller.*  
>   ".*ipainstaller.*"  
>   '.*ipainstaller.*'  
>   etc.
> 
> After client install, the server command:
> 
> server#> ipa host-find machine.example.com --all
> 
> shows: enrolledby_user: ipainstaller  
> but the machine is not enrolled in the assigned host group.
> 
> My server is Centos 7 with ipa-server.x86_64 3.3.3-28.0.1.el7.centos.3
> from the updates repo.
> 
> I found this link, but it doesn't look like any work has been
> done on this issue. https://fedorahosted.org/freeipa/ticket/3598
> 
> Has anyone seen this issue and/or have a workaround?
>

automember is executed when new entries are added. The enrolled_by isn't
set at the same time the host is added so it isn't triggering the rule.

IPA 4.0 added an automember-rebuild which would pick this up but you'd
need to run this periodically.

I updated the ticket with this information as well.

rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] AD/IPA login compatibility

[Hugh]

On 1/29/2015 4:26 PM, Dmitri Pal wrote:
> How are the domains connected? Do you use trust or sync?

Trust. We wanted to have just one account and not need to install
additional software on the AD servers if possible.

>> 1) Is it possible to log into a workstation that's been joined to a
>> domain with IPA credentials?
>>
> 
> You mean can I access a Windows workstation joined to AD domain by user
> from IPA domain?
> No it is not implemented. It will require Global Catalog support in IPA.

Out of curiosity, then why can we do this with the regular Kerberos?

> If you just want to use IPA for windows you for now have to use the same
> Kerberos setup on Windows workstations as you have in the old domain.

Do you mean use regular MIT Kerberos instead of FreeIPA, or configure
the Kerberos portion of FreeIPA like we had it in our old domain?

On a semi-related note, is there a way to be able to log into a Linux
workstation with an AD account without having to specify the AD domain?
In other words, ssh to a server with  instead of
.

Thanks again in advance,

Hugh

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

[Freeipa-users] Automember enrolledby

[Mark Esman]

Hello all,

I'm having a little trouble with the automember function using
"enrolledby" attribute. I have tried a number of different regex's
to define the username and automagically enroll the host into the
specified host group:

  .*ipainstaller.*  
  ".*ipainstaller.*"  
  '.*ipainstaller.*'  
  etc.

After client install, the server command:

server#> ipa host-find machine.example.com --all

shows: enrolledby_user: ipainstaller  
but the machine is not enrolled in the assigned host group.

My server is Centos 7 with ipa-server.x86_64 
3.3.3-28.0.1.el7.centos.3 from the updates repo.


I found this link, but it doesn't look like any work has been
done on this issue. https://fedorahosted.org/freeipa/ticket/3598

Has anyone seen this issue and/or have a workaround?

Thanks,

Mark

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] CA Replication Installation Failing

[Ade Lee]

Actually, it looks like it fails even earlier than getting the domain
info - that is, when the replica contacts the master and tries to get
its cert chain.

I think that you have modified the logs slightly?  There are a couple of
things that don't make sense. See annotated log below --


On Wed, 2015-02-04 at 09:19 -0500, Ade Lee wrote:
> >From the snippet of log below, it looks like the replica CA is trying to
> contact the master CA to obtain the security domain information and is
> failing to get a valid response.
> 
> The message about "spaces and parsing" is basically the replica saying
> that it cannot understand the response -- or lack of one from the master
> CA.  As this is an old version of IPA and Dogtag, it is trying to
> contact the master CA on port 9443.
> 
> Things to look into:
> 1) Is the CA on the master up?  Is port 9443 open on the master 
>(firewalls on master or replica)?  You could test this by using a 
>browser/curl on the replica to go to
>https://:9443/ca/admin/ca/getDomainXML
> 
> 2) Is selinux preventing the access?  You might want to set it in 
>permissive mode on either master or replica.
> 
> 3) Do you see activity in the master's debug log?
> 
> This looks to me like a different error from what was described before.
> Its failing much earlier now.
> 
> Ade
> 
> On Fri, 2015-01-30 at 05:48 +, Les Stott wrote:
> > 
> > > -Original Message-
> > > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> > > boun...@redhat.com] On Behalf Of Les Stott
> > > Sent: Wednesday, 10 December 2014 6:22 PM
> > > To: freeipa-users@redhat.com
> > > Subject: Re: [Freeipa-users] CA Replication Installation Failing
> > > 
> > > 
> > > 
> > > > -Original Message-
> > > > From: Ade Lee [mailto:a...@redhat.com]
> > > > Sent: Wednesday, 10 December 2014 5:05 AM
> > > > To: Les Stott
> > > > Cc: freeipa-users@redhat.com
> > > > Subject: Re: [Freeipa-users] CA Replication Installation Failing
> > > >
> > > > On Tue, 2014-12-09 at 07:48 +, Les Stott wrote:
> > > > >
> > > > >
> > > > >
> > > >
> > > __
> > > > 
> > > > > From: freeipa-users-boun...@redhat.com
> > > > > [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal
> > > > > [d...@redhat.com]
> > > > > Sent: Tuesday, December 09, 2014 3:49 PM
> > > > > To: freeipa-users@redhat.com
> > > > > Subject: Re: [Freeipa-users] CA Replication Installation Failing
> > > > >
> > > > >
> > > > >
> > > > > On 12/08/2014 11:04 PM, Les Stott wrote:
> > > > >
> > > > > > Does anyone have any ideas on the below errors when trying to add
> > > > > > CA replication to an existing replica?
> > > > > >
> > > > > >
> > > > >
> > > > > > People who might be able to help are or PTO right now.
> > > > > >
> > > > > > Is your installation older than 2 years?
> > > > >
> > > > > No, December 2013 was when it was originally built.
> > > > >
> > > > > > Did you generate a new replica package or use the original one?
> > > > >
> > > > > I used the original replica file for serverb, based on instructions
> > > > > i came across. I can try regenerating the replica file.
> > > > >
> > > > > Interestingly, now that you mention it, servera had to be restored a
> > > > > couple of months back. Perhaps this is an issue and regenerating the
> > > > > replica file for serverb will be required.
> > > > >
> > > > > I will try this.
> > > > >
> > > >
> > > > I think that this is a safe bet to be the problem.
> > > >
> > > > The error in the log snippet you posted says:
> > > >
> > > >  The pkcs12 file is not correct.
> > > >
> > > > This indicates that the clone CA was unable to decode the pkcs12 file
> > > > in the replica.  Perhaps the certs changed -- or the DM password 
> > > > changed?
> > > >
> > > > Ade
> > > 
> > > I regenerated the replica file and retired the CA replica setup, but it 
> > > failed at
> > > the same point with the same error.
> > > 
> > > I am thinking that the next step is to uninstall the ipa replica to 
> > > cleanup,
> > > remove all traces and re-add as a replica on serverb.
> > > 
> > > I wonder if the cert that its having an issue with is the one on serverB 
> > > under
> > > /etc/ipa/ca.crt which is from Dec 2013.
> > > 
> > > I will try that in a couple of days as I have to schedule this work in as 
> > > its in
> > > production.
> > > 
> > > Regards,
> > > 
> > > Les
> > > 
> > > 
> > > > > > May be the problem is that the cert that is in that package
> > > > > > already
> > > > > expired?
> > > > >
> > > > > original replica file was created on Dec 16 2013. Cert is not set to
> > > > > expire until 2015-12-17.
> > > > >
> > > > > > Just a thought...
> > > > > >
> > > > > > The simplest workaround IMO would be to prepare Server C, install
> > > > > > it
> > > > > with CA and then decommission replica B.
> > > > > > Do not forget to clean replication agreements on master.
> > > > > >
> > > > > > But that would be work around, would

Re: [Freeipa-users] CA Replication Installation Failing

[Rob Crittenden]

Les Stott wrote:
> Has anyone got any ideas on this?
> 
> I am stuck with not being able to deploy a CA Replica and this is halting 
> rollout of the project. 
> 
> Help please...
> 
> Regards,

What is the version of IPA on the master you are connecting to?

Can you confirm on the existing master that
/etc/httpd/conf.d/ipa-pki-proxy.conf has /ca/ee/ca/profileSubmit in it:

 # matches for ee port


rob

> 
> Les
> 
>> -Original Message-
>> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
>> boun...@redhat.com] On Behalf Of Les Stott
>> Sent: Friday, 30 January 2015 4:48 PM
>> To: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] CA Replication Installation Failing
>>
>>
>>
>>> -Original Message-
>>> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
>>> boun...@redhat.com] On Behalf Of Les Stott
>>> Sent: Wednesday, 10 December 2014 6:22 PM
>>> To: freeipa-users@redhat.com
>>> Subject: Re: [Freeipa-users] CA Replication Installation Failing
>>>
>>>
>>>
 -Original Message-
 From: Ade Lee [mailto:a...@redhat.com]
 Sent: Wednesday, 10 December 2014 5:05 AM
 To: Les Stott
 Cc: freeipa-users@redhat.com
 Subject: Re: [Freeipa-users] CA Replication Installation Failing

 On Tue, 2014-12-09 at 07:48 +, Les Stott wrote:
>
>
>

>>> __
 
> From: freeipa-users-boun...@redhat.com
> [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal
> [d...@redhat.com]
> Sent: Tuesday, December 09, 2014 3:49 PM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] CA Replication Installation Failing
>
>
>
> On 12/08/2014 11:04 PM, Les Stott wrote:
>
>> Does anyone have any ideas on the below errors when trying to
>> add CA replication to an existing replica?
>>
>>
>
>> People who might be able to help are or PTO right now.
>>
>> Is your installation older than 2 years?
>
> No, December 2013 was when it was originally built.
>
>> Did you generate a new replica package or use the original one?
>
> I used the original replica file for serverb, based on
> instructions i came across. I can try regenerating the replica file.
>
> Interestingly, now that you mention it, servera had to be restored
> a couple of months back. Perhaps this is an issue and regenerating
> the replica file for serverb will be required.
>
> I will try this.
>

 I think that this is a safe bet to be the problem.

 The error in the log snippet you posted says:

  The pkcs12 file is not correct.

 This indicates that the clone CA was unable to decode the pkcs12
 file in the replica.  Perhaps the certs changed -- or the DM password
>> changed?

 Ade
>>>
>>> I regenerated the replica file and retired the CA replica setup, but
>>> it failed at the same point with the same error.
>>>
>>> I am thinking that the next step is to uninstall the ipa replica to
>>> cleanup, remove all traces and re-add as a replica on serverb.
>>>
>>> I wonder if the cert that its having an issue with is the one on
>>> serverB under /etc/ipa/ca.crt which is from Dec 2013.
>>>
>>> I will try that in a couple of days as I have to schedule this work in
>>> as its in production.
>>>
>>> Regards,
>>>
>>> Les
>>>
>>>
>> May be the problem is that the cert that is in that package
>> already
> expired?
>
> original replica file was created on Dec 16 2013. Cert is not set
> to expire until 2015-12-17.
>
>> Just a thought...
>>
>> The simplest workaround IMO would be to prepare Server C,
>> install it
> with CA and then decommission replica B.
>> Do not forget to clean replication agreements on master.
>>
>> But that would be work around, would not solve this specific
> problem, it will kill it.
>
> I actually do have serverc and serverd. I planned to have CA
> replication on at least 2 other servers, but held off on trying on
> serverc due to issues with serverb.
>
> I'll report back what i find after regenerating the replica file
> and re-trying to setup CA replication.
>
>>
>> After a bit of a hiatus I have revisited this issue and I still have it.
>>
>> Just to re-iterate the problem...
>>
>> Trying to setup a ca replica on an already installed replica fails in rhel 
>> 6.6,
>> ipa-3.0.0.42, pki 9.0.3-38.
>>
>> /usr/sbin/ipa-ca-install -p xx -w xx -U /var/lib/ipa/replica-info-
>> myhost.mydomain.com.gpg
>>
>> It fails showing "CRITICAL failed to configure ca instance"
>> Configuring certificate server (pki-cad): Estimated time 3 minutes 30
>> seconds
>>   [1/16]: creating certificate server user
>>   [2/16]: creating pki-ca instance
>>   [3/16]: configuring certificate server instance
>>
>> Your system may be partly configured.
>> Run 

Re: [Freeipa-users] CA Replication Installation Failing

[Ade Lee]

>From the snippet of log below, it looks like the replica CA is trying to
contact the master CA to obtain the security domain information and is
failing to get a valid response.

The message about "spaces and parsing" is basically the replica saying
that it cannot understand the response -- or lack of one from the master
CA.  As this is an old version of IPA and Dogtag, it is trying to
contact the master CA on port 9443.

Things to look into:
1) Is the CA on the master up?  Is port 9443 open on the master 
   (firewalls on master or replica)?  You could test this by using a 
   browser/curl on the replica to go to
   https://:9443/ca/admin/ca/getDomainXML

2) Is selinux preventing the access?  You might want to set it in 
   permissive mode on either master or replica.

3) Do you see activity in the master's debug log?

This looks to me like a different error from what was described before.
Its failing much earlier now.

Ade

On Fri, 2015-01-30 at 05:48 +, Les Stott wrote:
> 
> > -Original Message-
> > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> > boun...@redhat.com] On Behalf Of Les Stott
> > Sent: Wednesday, 10 December 2014 6:22 PM
> > To: freeipa-users@redhat.com
> > Subject: Re: [Freeipa-users] CA Replication Installation Failing
> > 
> > 
> > 
> > > -Original Message-
> > > From: Ade Lee [mailto:a...@redhat.com]
> > > Sent: Wednesday, 10 December 2014 5:05 AM
> > > To: Les Stott
> > > Cc: freeipa-users@redhat.com
> > > Subject: Re: [Freeipa-users] CA Replication Installation Failing
> > >
> > > On Tue, 2014-12-09 at 07:48 +, Les Stott wrote:
> > > >
> > > >
> > > >
> > >
> > __
> > > 
> > > > From: freeipa-users-boun...@redhat.com
> > > > [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal
> > > > [d...@redhat.com]
> > > > Sent: Tuesday, December 09, 2014 3:49 PM
> > > > To: freeipa-users@redhat.com
> > > > Subject: Re: [Freeipa-users] CA Replication Installation Failing
> > > >
> > > >
> > > >
> > > > On 12/08/2014 11:04 PM, Les Stott wrote:
> > > >
> > > > > Does anyone have any ideas on the below errors when trying to add
> > > > > CA replication to an existing replica?
> > > > >
> > > > >
> > > >
> > > > > People who might be able to help are or PTO right now.
> > > > >
> > > > > Is your installation older than 2 years?
> > > >
> > > > No, December 2013 was when it was originally built.
> > > >
> > > > > Did you generate a new replica package or use the original one?
> > > >
> > > > I used the original replica file for serverb, based on instructions
> > > > i came across. I can try regenerating the replica file.
> > > >
> > > > Interestingly, now that you mention it, servera had to be restored a
> > > > couple of months back. Perhaps this is an issue and regenerating the
> > > > replica file for serverb will be required.
> > > >
> > > > I will try this.
> > > >
> > >
> > > I think that this is a safe bet to be the problem.
> > >
> > > The error in the log snippet you posted says:
> > >
> > >  The pkcs12 file is not correct.
> > >
> > > This indicates that the clone CA was unable to decode the pkcs12 file
> > > in the replica.  Perhaps the certs changed -- or the DM password changed?
> > >
> > > Ade
> > 
> > I regenerated the replica file and retired the CA replica setup, but it 
> > failed at
> > the same point with the same error.
> > 
> > I am thinking that the next step is to uninstall the ipa replica to cleanup,
> > remove all traces and re-add as a replica on serverb.
> > 
> > I wonder if the cert that its having an issue with is the one on serverB 
> > under
> > /etc/ipa/ca.crt which is from Dec 2013.
> > 
> > I will try that in a couple of days as I have to schedule this work in as 
> > its in
> > production.
> > 
> > Regards,
> > 
> > Les
> > 
> > 
> > > > > May be the problem is that the cert that is in that package
> > > > > already
> > > > expired?
> > > >
> > > > original replica file was created on Dec 16 2013. Cert is not set to
> > > > expire until 2015-12-17.
> > > >
> > > > > Just a thought...
> > > > >
> > > > > The simplest workaround IMO would be to prepare Server C, install
> > > > > it
> > > > with CA and then decommission replica B.
> > > > > Do not forget to clean replication agreements on master.
> > > > >
> > > > > But that would be work around, would not solve this specific
> > > > problem, it will kill it.
> > > >
> > > > I actually do have serverc and serverd. I planned to have CA
> > > > replication on at least 2 other servers, but held off on trying on
> > > > serverc due to issues with serverb.
> > > >
> > > > I'll report back what i find after regenerating the replica file and
> > > > re-trying to setup CA replication.
> > > >
> 
> After a bit of a hiatus I have revisited this issue and I still have it.
> 
> Just to re-iterate the problem...
> 
> Trying to setup a ca replica on an already installed replica fails in rhel 
> 6.6, ipa-3.0.0.42, pki 9

Re: [Freeipa-users] basic question on DNS configuration

[Roberto Cornacchia]

Thank you Craig and Martin for your useful input.

You both definitely recommend not to use example.com for the internal IPA
DNS.

I was in any case going to avoid .local suffix and any invented top-level
domain, after some reading on this topic.

Using a subdomain like internal.example.com seems reasonable.
I was under the impression that the freeIPA domain needed to be a top-level
one, but maybe I was wrong here? Can I still keep example.com outside and
have freeIPA manage internal.example.com?



On 4 February 2015 at 10:34, Martin Basti  wrote:

>  On 03/02/15 16:52, Craig White wrote:
>
>  *From:* freeipa-users-boun...@redhat.com [
> mailto:freeipa-users-boun...@redhat.com ]
> *On Behalf Of *Roberto Cornacchia
> *Sent:* Tuesday, February 03, 2015 5:20 AM
> *To:* freeipa-users@redhat.com
> *Subject:* [Freeipa-users] basic question on DNS configuration
>
>
>
> Hi guys,
>
>
>
> I can't wait to get freeIPA installed in our small enterprise, but I'd
> first like to get a couple of basic things straight.
>
>
>
> My first doubt is about the DNS configuration. Currently, we use a setting
> that I guess is rather common for small enterprises:
>
>
>
> We own an example.com domain which is managed by the DNS of an external
> provider.
>
>
>
> A couple of subdomains point to public IP addresses outside our local
> network (e.g. www.example.com is hosted at our internet provider,
> server1.example.com points at a server hosted in a datacenter, etc).
>
>
>
> All the remaining subdomain (*.example.com) point at one IP which
> corresponds to our local router.
>
> Then we use some simple forwarding rules to forward on to machines that
> are behind the router (service1.example.com, desktop1.example.com,
> desktop2.example.com, etc).
>
>
>
> Internally, because the enterprise is rather small, we are not using a
> DNS, but simply /etc/hosts files on each machine. When they can't resolve
> whatever.example.com, then the request goes to the external DNS.
>
>
>
> (sorry about the long-ish background information, probably this
> configuration is commonly named somehow, but I don't know how)
>
>
>
> Now, a first simple question for you guys would be:
>
> When installing freeIPA, with DNS, is the network configuration above
> still advisable? Can there be any problem? Or should I rather use a
> different domain for the internal network (I would really NOT like this
> option, but I'm very interested to know why I should, if that is the case).
>
>
>
>
>
> A second basic question is:
>
> Would you see any potential problem in installing freeIPA on a FC21 Server
> which currently hosts Atlassian Jira + Atlassian Stash (therefore git
> repositories) + the required mysql databases?
>
> My guess would be that they would not interfere, as:
>
> - httpd (and related ports) is currently unused)
>
> - Both Jira and Stash use thier own tomcat installation on custom ports
>
> - mysql shouldn't be a problem?
>
> - The machine isn't overloaded at all (4-5 developers use those services)
>
>
>
> Am I overlooking something? Obviously I'd rather have a dedicated freeIPA
> server, but if the above mentioned coexistence isn't a problem, then this
> would be more cost-effective.
>
>
>
> Thank you very much for your help, I'm looking forward to this upgrade.
>
> Roberto
>
> I would recommend that you create a ‘local’ domain for your internal LAN
> though you certainly can use your domain name for both the internal LAN and
> the external world. Obviously you would have to create ‘manual’ entries in
> DNS for the external servers (like www.example.com) so your internal LAN
> systems can resolve it. If you have a ‘local’ domain for your internal LAN,
> there aren’t name collisions, no need to manually maintain DNS entries for
> off-LAN servers and no confusion of essentially faking your LAN systems
> into believing that the IPA server is authoritative for example.com
> domain when the rest of the world thinks otherwise. The choice is yours.
>
>
>
> As for using F21 – you get the latest version of FreeIPA which is
> something I wish I had here.
>
>
>
> Git / Stash / Jira represent a fairly hefty memory footprint even if there
> isn’t that much CPU load. If you have the RAM and cpu cores to handle
> tossing FreeIPA onto the stack, go for it. You probably will want a replica
> too as the replica keeps your LAN running if the primary server is
> unavailable for whatever reason and it minimizes backup needs substantially.
>
>
>
> Craig
>
>
>
>
>  Hello,
>
> For using 'local.' domain please read following message, to avoid issues
> on Fedora:
> https://www.redhat.com/archives/freeipa-users/2015-February/msg00010.html
>
> You cant use 'example.com' zone for internal IPA DNS.
>
> You can create your internal sub zone, like 'internal.example.com', '
> corp.example.com', where IPA managed hosts will be added. It is preferred
> solution instead of creating '.local' hostnames.  Then you can set up
> global forwarder on IPA DNS to your external DNS, where other name

Re: [Freeipa-users] basic question on DNS configuration

[Martin Basti]

On 04/02/15 11:39, Roberto Cornacchia wrote:

Thank you Craig and Martin for your useful input.

You both definitely recommend not to use example.com 
 for the internal IPA DNS.


I was in any case going to avoid .local suffix and any invented 
top-level domain, after some reading on this topic.


Using a subdomain like internal.example.com 
 seems reasonable.
I was under the impression that the freeIPA domain needed to be a 
top-level one, but maybe I was wrong here? Can I still keep 
example.com  outside and have freeIPA manage 
internal.example.com ?


IPA DNS is designed only for internal network, so having an internal 
subdomain is good use case. You can keep example.com outside of IPA DNS, 
you just need to configure proper forwarder address pointing to external 
DNS.


Martin^2





On 4 February 2015 at 10:34, Martin Basti > wrote:


On 03/02/15 16:52, Craig White wrote:


*From:*freeipa-users-boun...@redhat.com

[mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Roberto
Cornacchia
*Sent:* Tuesday, February 03, 2015 5:20 AM
*To:* freeipa-users@redhat.com 
*Subject:* [Freeipa-users] basic question on DNS configuration

Hi guys,

I can't wait to get freeIPA installed in our small enterprise,
but I'd first like to get a couple of basic things straight.

My first doubt is about the DNS configuration. Currently, we use
a setting that I guess is rather common for small enterprises:

We own an example.com  domain which is
managed by the DNS of an external provider.

A couple of subdomains point to public IP addresses outside our
local network (e.g. www.example.com  is
hosted at our internet provider, server1.example.com
 points at a server hosted in a
datacenter, etc).

All the remaining subdomain (*.example.com )
point at one IP which corresponds to our local router.

Then we use some simple forwarding rules to forward on to
machines that are behind the router (service1.example.com
, desktop1.example.com
, desktop2.example.com
, etc).

Internally, because the enterprise is rather small, we are not
using a DNS, but simply /etc/hosts files on each machine. When
they can't resolve whatever.example.com
, then the request goes to the
external DNS.

(sorry about the long-ish background information, probably this
configuration is commonly named somehow, but I don't know how)

Now, a first simple question for you guys would be:

When installing freeIPA, with DNS, is the network configuration
above still advisable? Can there be any problem? Or should I
rather use a different domain for the internal network (I would
really NOT like this option, but I'm very interested to know why
I should, if that is the case).

A second basic question is:

Would you see any potential problem in installing freeIPA on a
FC21 Server which currently hosts Atlassian Jira + Atlassian
Stash (therefore git repositories) + the required mysql databases?

My guess would be that they would not interfere, as:

- httpd (and related ports) is currently unused)

- Both Jira and Stash use thier own tomcat installation on custom
ports

- mysql shouldn't be a problem?

- The machine isn't overloaded at all (4-5 developers use those
services)

Am I overlooking something? Obviously I'd rather have a dedicated
freeIPA server, but if the above mentioned coexistence isn't a
problem, then this would be more cost-effective.

Thank you very much for your help, I'm looking forward to this
upgrade.

Roberto

I would recommend that you create a ‘local’ domain for your
internal LAN though you certainly can use your domain name for
both the internal LAN and the external world. Obviously you would
have to create ‘manual’ entries in DNS for the external servers
(like www.example.com ) so your internal
LAN systems can resolve it. If you have a ‘local’ domain for your
internal LAN, there aren’t name collisions, no need to manually
maintain DNS entries for off-LAN servers and no confusion of
essentially faking your LAN systems into believing that the IPA
server is authoritative for example.com 
domain when the rest of the world thinks otherwise. The choice is
yours.

As for using F21 – you get the latest version of FreeIPA which is
something I wish I had here.

Git / Stash / Jira represent a fairly hefty memory footprint even
if th

Re: [Freeipa-users] basic question on DNS configuration

[Martin Basti]

On 03/02/15 16:52, Craig White wrote:


*From:*freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Roberto 
Cornacchia

*Sent:* Tuesday, February 03, 2015 5:20 AM
*To:* freeipa-users@redhat.com
*Subject:* [Freeipa-users] basic question on DNS configuration

Hi guys,

I can't wait to get freeIPA installed in our small enterprise, but I'd 
first like to get a couple of basic things straight.


My first doubt is about the DNS configuration. Currently, we use a 
setting that I guess is rather common for small enterprises:


We own an example.com  domain which is managed by 
the DNS of an external provider.


A couple of subdomains point to public IP addresses outside our local 
network (e.g. www.example.com  is hosted at 
our internet provider, server1.example.com 
 points at a server hosted in a 
datacenter, etc).


All the remaining subdomain (*.example.com ) point 
at one IP which corresponds to our local router.


Then we use some simple forwarding rules to forward on to machines 
that are behind the router (service1.example.com 
, desktop1.example.com 
, desktop2.example.com 
, etc).


Internally, because the enterprise is rather small, we are not using a 
DNS, but simply /etc/hosts files on each machine. When they can't 
resolve whatever.example.com , then the 
request goes to the external DNS.


(sorry about the long-ish background information, probably this 
configuration is commonly named somehow, but I don't know how)


Now, a first simple question for you guys would be:

When installing freeIPA, with DNS, is the network configuration above 
still advisable? Can there be any problem? Or should I rather use a 
different domain for the internal network (I would really NOT like 
this option, but I'm very interested to know why I should, if that is 
the case).


A second basic question is:

Would you see any potential problem in installing freeIPA on a FC21 
Server which currently hosts Atlassian Jira + Atlassian Stash 
(therefore git repositories) + the required mysql databases?


My guess would be that they would not interfere, as:

- httpd (and related ports) is currently unused)

- Both Jira and Stash use thier own tomcat installation on custom ports

- mysql shouldn't be a problem?

- The machine isn't overloaded at all (4-5 developers use those services)

Am I overlooking something? Obviously I'd rather have a dedicated 
freeIPA server, but if the above mentioned coexistence isn't a 
problem, then this would be more cost-effective.


Thank you very much for your help, I'm looking forward to this upgrade.

Roberto

I would recommend that you create a ‘local’ domain for your internal 
LAN though you certainly can use your domain name for both the 
internal LAN and the external world. Obviously you would have to 
create ‘manual’ entries in DNS for the external servers (like 
www.example.com ) so your internal LAN systems 
can resolve it. If you have a ‘local’ domain for your internal LAN, 
there aren’t name collisions, no need to manually maintain DNS entries 
for off-LAN servers and no confusion of essentially faking your LAN 
systems into believing that the IPA server is authoritative for 
example.com domain when the rest of the world thinks otherwise. The 
choice is yours.


As for using F21 – you get the latest version of FreeIPA which is 
something I wish I had here.


Git / Stash / Jira represent a fairly hefty memory footprint even if 
there isn’t that much CPU load. If you have the RAM and cpu cores to 
handle tossing FreeIPA onto the stack, go for it. You probably will 
want a replica too as the replica keeps your LAN running if the 
primary server is unavailable for whatever reason and it minimizes 
backup needs substantially.


Craig




Hello,

For using 'local.' domain please read following message, to avoid issues 
on Fedora:

https://www.redhat.com/archives/freeipa-users/2015-February/msg00010.html

You cant use 'example.com' zone for internal IPA DNS.

You can create your internal sub zone, like 'internal.example.com', 
'corp.example.com', where IPA managed hosts will be added. It is 
preferred solution instead of creating '.local' hostnames.  Then you can 
set up global forwarder on IPA DNS to your external DNS, where other 
names than 'internal.example.com' will be resolved.


If I understand correctly, it is internal network, so you do not need 
public resolvable domain names.


--
Martin Basti

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] autofs - nfsnobody

[dbischof]

Hi Gerardo,

On Tue, 3 Feb 2015, Gerardo Cuppari wrote:

Hello there again! I'm bothering you again because I am having some 
problems with autofs/NFS and IPA. All files created from a regular user 
(enrolled client) gets the nfsnobody user and group. Folder gets auto 
mounted.


just a guess: I had this symptom with a non-Redhat, self-configured 
client. It turned out, that it was required to set


---
Domain = my.domain.de
---

in /etc/idmapd.conf

Maybe worth a try.


Thanks in advance!

Here is what I did to configure it at server (server.estudio) and client 
(pc01.estudio):


SERVER
=

ipa service-add nfs/server.estudio
ipa-getkeytab -s server.estudio -p nfs/server.estudio -k /etc/krb5.keytab
ipa-client-automount

mkdir /export
chmod 777 /export
echo /export *(rw,sync,sec=sys:krb5:krb5i:krb5p) >> /etc/exports

reboot

**

CLIENT


ipa-getkeytab -s server.estudio -p host/server.estudio@ESTUDIO -k
/etc/krb5.keytab
ipa-client-automount

reboot

echo aaa >> /export/aaa

[user@pc01 /]$ ls -la /export
total 12
drwxrwxrwx.  2 root  root  4096 feb  3 13:36 .
dr-xr-xr-x. 21 root  root  4096 feb  3 13:36 ..
-rw-rw-r--.  1 nfsnobody nfsnobody4 feb  3 13:36 aaa




Mit freundlichen Gruessen/With best regards,

--Daniel.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] JSON error enrolling host (Fedora 21 / IPA 4.1.2)

[Martin Basti]

Hello,

well it depends what exactly you did and what helped. I see Alexander 
gave you some hints about mDNS.


If it was DNSSEC error you should see validation error messages in 
journalctl -u named-pkcs11 before you disabled DNSSEC validation.


Martin^2

On 02/02/15 16:34, Gerardo Cuppari wrote:

Hi Martin, thanks for your replies!

Please, don't tell me I am getting all these errors because of the 
".local" domain! If so, I will surelly kill someone haha


I checked /etc/named.conf and changed to "no" dnssec-validation and 
here is what you requested:


[root@pc01 ~]# dig server.estudio.local

; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> server.estudio.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31554
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;server.estudio.local.  IN  A

;; ANSWER SECTION:
server.estudio.local.   1200  IN  A   192.168.56.2

;; AUTHORITY SECTION:
estudio.local.  86400 IN  NS  server.estudio.local.

;; Query time: 0 msec
;; SERVER: 192.168.56.2#53(192.168.56.2)
;; WHEN: lun feb 02 12:29:17 ART 2015
;; MSG SIZE  rcvd: 79

**

[root@pc01 ~]# dig -t ptr 2.56.168.192.in-addr.arpa

; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> -t ptr 
2.56.168.192.in-addr.arpa

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36167
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;2.56.168.192.in-addr.arpa. IN  PTR

;; ANSWER SECTION:
2.56.168.192.in-addr.arpa. 86400 IN PTR server.estudio.local.

;; AUTHORITY SECTION:
56.168.192.in-addr.arpa. 86400  IN  NS  server.estudio.local.

;; ADDITIONAL SECTION:
server.estudio.local.   1200IN  A   192.168.56.2

;; Query time: 0 msec
;; SERVER: 192.168.56.2#53(192.168.56.2)
;; WHEN: lun feb 02 12:34:27 ART 2015
;; MSG SIZE  rcvd: 118


2015-02-02 12:17 GMT-03:00 Martin Basti >:


On 02/02/15 16:07, Martin Basti wrote:

On 02/02/15 14:13, Gerardo Cuppari wrote:

Hello! I am trying to enroll one host to my IPA server (4.1.2)
and I am having one problem: the ipa-client-install script keeps
giving me errors at the "forwarding ping to json server" step.

My configuration is:
- server.estudio.local192.168.56.2Fedora Server 21ipa 4.1.2
- pc01.estudio.local192.168.56.106Fedora Works. 21

Both have firewalld down (just to test) and can reach each
other. I've been trying to get this working without success
(solved other minor issues) and so I'm asking for your help.
The only way I can make it work is by adding the --force switch
to ipa-client-install script but, that way, it just disregards
errors.

Thanks in advance!!!

Here are my tests:

SERVER
==
[root@server ~]# ipa ping
---
IPA server version 4.1.2. API version 2.109
---

CLIENT
==
[root@pc01 ~]# dig server

; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> server
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29286
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;server.IN  A

;; Query time: 10 msec
;; SERVER: 192.168.56.2#53(192.168.56.2)
;; WHEN: lun feb 02 09:51:07 ART 2015
;; MSG SIZE  rcvd: 35

***

[root@pc01 ~]# nslookup server
Server: 192.168.56.2
Address:192.168.56.2#53

Name:   server.estudio.local
Address: 192.168.56.2

***

Here I disable chronyd so I can run the script without NTP sync
errors:

[root@pc01 ~]# systemctl disable chronyd
Removed symlink
/etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@pc01 ~]# service chronyd stop
Redirecting to /bin/systemctl stop  chronyd.service

***

Without having "server.estudio.local" on /etc/hosts file:

[root@pc01 ~]# ipa-client-install --enable-dns-updates
--mkhomedir --ssh-trust-dns
Skip server.estudio.local: cannot verify if this is an IPA server
Provide your IPA server name (ex: ipa.example.com
):
Skip server.estudio.local: cannot verify if this is an IPA server
Failed to verify that server.estudio.local is an IPA Server.
This may mean that the remote server is not up or is not
reachable due to network or firewall settings.
  

Re: [Freeipa-users] IPA-adtrust and addition of replicas

[Alexander Bokovoy]

On Tue, 03 Feb 2015, William wrote:



>
>Maybe something to test?
You can create a user on the replica without ipa-adtrust-install and
watch after replication on whether ipaNTSecurityIdentifier appeared in
the user's object in LDAP.



I was thinking more unit test or beaker test actually, but I'm sure I
could do a setup by hand and test it later.

Having a beaker test would be good. I was just thinking about proving
that the flow is indeed what we are discussing. ;)




>> >This should be configured on replicas added to the network if adtrust
>> >has been run already. Perhaps this is something to consider also?
>> >Consistency through out the domain is a good thing.
>> Exactly. Good suggestion. One thing we need to solve here is that
>> enabling sidgen and other components will require installing Samba
>> libraries. This is something to consider -- do we want these libraries
>> (not daemons) installed on every master?
>
>Well, ipa-adtrust is a seperate package already isn't it? If you were in
>the position to be setting up an adtrust on freeipa, you would document
>that it should be installed on all hosts anyway, so then the adtrust
>package would pull in the adtrust libs.
>
>Once the adtrust is installed, be it trust controller or agent, perhaps
>this should be added into the domain services tree under cn=etc. That
>way, after the adtrust is run, you can see a list of hosts that do not
>yet have it installed, so that the trust agent can be configured on all
>other replicas. Additionally, adding a new replica could be hinted that
>if this exists to configure itself as a trust agent automatically as
>part of ipa-replica-install.
>
>Does that sound like a reasonable suggestion?
Yes, this is what ipa-adtrust-install implements right now. My issue
with this approach is the fact that we don't want to run
smbd/winbindd/etc for trust agent case. Yet, ipa-adtrust-install forces
packages to be installed and services to be active.


Kind of what I meant but kind of not. I meant a more generic "some
adtrust agent or controller" flag, rather than the services. The per
host flag is to enable the detection of masters that lack adtrust agent
or controller, rather than to detect if the domain has had adtrust run
at all.

My thought was more like:

If I have three ipa masters, A B C. I have trust controller on A, and I
am installing trust agent on B, I should post install receive a message:

ipa-adtrust-install --agent:
... Install happens here ...
The following masters are not agents or controllers. These should be
promoted.
* C

To of course, prompt me to run adtrust-install on C.

Then I add some host D, it should as part of ipa-replica-install be
configured as a trust agent.

This way the domain stays consistent and I am informed of the state of
the network.

This also means there should be a strategy for promotion of the agent to
a controller, and also in the decommissioning code to remove both agent
and installers correctly (If not already implemented)

Makes sense. This will need to be added into a design page -- I'll work
on that next week. There will be series of RFE tickets to correspond to
work outlined in those design pages and this is a perfect example of an
RFE.





We can start with disabling ADTRUST and EXTID services on trust agents
(these are smb and winbind in ipactl speak) and, maybe, rename them to
something less confusing. Then we can decide whether not installing
samba server packages would really be needed.


Sounds like a good plan. Would this become a special case of
ipa-adtrust-install? Or an option that is prompted for similar to the
slapi-nis question.

For most cases like this we have CLI option and ask for an answer
interactively in case option wasn't provided explicitly and we are not
running in unattended mode.

In case of a slapi-nis it is driven by --enable-compat option of
ipa-adtrust-install. The general calling pattern in ipa-adtrust-install
is something like this:
   if not options.unattended and not options.enable_compat:
   options.enable_compat = enable_compat_tree()

where enable_compat_tree() does ask user for a confirmation.


--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] Minimum Disk Size

[Innes, Duncan]

Our standard RHEL6 OS install worked perfectly well for testing IPA with
larger user/host numbers:

part /boot --fstype=ext4 --size=256 --ondisk=sda --fsoptions noatime
part pv.01 --size=1000 --grow --ondisk=sda
volgroup vg_root pv.01
logvol /  --vgname=vg_root --name=lv_root   --size=3072
--fstype=ext4 --fsoptions noatime
logvol swap   --vgname=vg_root --name=lv_swap   --size=1024
--fstype=swap
logvol /opt   --vgname=vg_root --name=lv_opt--size=1024
--fstype=ext4 --fsoptions noatime
logvol /var   --vgname=vg_root --name=lv_var--size=1024
--fstype=ext4 --fsoptions noatime
logvol /var/log   --vgname=vg_root --name=lv_vlog   --size=1024
--fstype=ext4 --fsoptions noatime
logvol /var/log/audit --vgname=vg_root --name=lv_vaudit --size=512
--fstype=ext4 --fsoptions noatime
logvol /tmp   --vgname=vg_root --name=lv_tmp--size=1024
--fstype=ext4 --fsoptions noatime,nodev,nosuid,noexec
logvol /home  --vgname=vg_root --name=lv_home   --size=1024
--fstype=ext4 --fsoptions noatime,nodev

Then to load test and move into production, we simply added an extra
partition for /var/lib/dirsrv:

logvol /var/lib/dirsrv --vgname=vg_root --name=lv_ldap --size=4096
--fstype=ext4 --fsoptions noatime

Which still uses less than 1Gb with nearly 1500 users and around 700
hosts:

# df -P
Filesystem1024-blocksUsed Available Capacity
Mounted on
/dev/mapper/vg_root-lv_root   3030800 1478012   1395504  52% /
tmpfs 1962324   4   1962320   1%
/dev/shm
/dev/sda1  245679   69576162996  30%
/boot
/dev/mapper/vg_root-lv_home999320   29724917168   4%
/home
/dev/mapper/vg_root-lv_opt 9993201328945564   1%
/opt
/dev/mapper/vg_root-lv_tmp 999320   44312902580   5%
/tmp
/dev/mapper/vg_root-lv_var 999320  296952649940  32%
/var
/dev/mapper/vg_root-lv_ldap   3997376  640084   3147580  17%
/var/lib/dirsrv
/dev/mapper/vg_root-lv_vlog   1515376  514128922612  36%
/var/log
/dev/mapper/vg_root-lv_vaudit  499656   29608443836   7%
/var/log/audit
# 

HTH

D

-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dan Mossor
Sent: 04 February 2015 01:04
To: FreeIPA List
Subject: [Freeipa-users] Minimum Disk Size

What would be the minimum recommended disk size for a virtual FreeIPA
server on a network consisting of less than 30 users and 100 hosts?

Regards,
Dan
--
Dan Mossor
Systems Engineer at Large
Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure
Apprentice
FAS: dmossor IRC: danofsatx
San Antonio, Texas, USA

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

This message has been checked for viruses and spam by the Virgin Money
email scanning system powered by Messagelabs.

This message has been checked for viruses and spam by the Virgin Money email 
scanning system powered by Messagelabs.

This e-mail is intended to be confidential to the recipient. If you receive a 
copy in error, please inform the sender and then delete this message.

Virgin Money plc - Registered in England and Wales (Company no. 6952311). 
Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. 
Virgin Money plc is authorised by the Prudential Regulation Authority and 
regulated by the Financial Conduct Authority and the Prudential Regulation 
Authority.

The following companies also trade as Virgin Money. They are both authorised 
and regulated by the Financial Conduct Authority, are registered in England and 
Wales and have their registered office at Jubilee House, Gosforth, Newcastle 
upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 
3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482).

For further details of Virgin Money group companies please visit our website at 
virginmoney.com

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project