Re: [Freeipa-users] Confused/lost at promoting a replica into a master
David Copperfield wrote: I think the problem is figured out, though solution is not easy. Would some one please open a bug for this problem. Another close question to ask: Does this means the IPA PKI/CA system is still in its beta/alpha stage, and better avoid in production IPA deployment? I've see messages, Q/A in mail list of 389 Directory Server and freeIPA much, much more often than the Dogtag. If so, I can use --selfsign to install IPA masters and replicas now, and wait until the Dogtag is mature enough. because this IPA solution is the core of our business authentication and authorization, and so I have been asked several times to make it reliable and easy to maintain. Otherwise the admin. official would rather to keep existing Kerberos+OpenLDAP solution which is time proven. As Rich pointed out, there are per-instance specific versions of the scripts. This is related to the templates you saw in the rpm. CAs are not sexy which may be why the dogtag list is low volume. I get the feeling that many people just get by with self-signed certificates that are managed by hand. There is a fair bit of discussion in the freenode #dogtag IRC channel from time to time. There is no way to migrate from one CA type to another within IPA (without re-installing IPA). rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
On 04/30/2012 07:50 PM, David Copperfield wrote:
I think the problem is figured out, though solution is not easy. Would
some one please open a bug for this problem.
Another close question to ask: Does this means the IPA PKI/CA system
is still in its beta/alpha stage, and better avoid in production IPA
deployment?
I don't know about from an IPA perspective, but DogTag has been in heavy
duty commercial deployment for over a decade.
I've see messages, Q/A in mail list of 389 Directory Server and
freeIPA much, much more often than the Dogtag. If so, I can use
--selfsign to install IPA masters and replicas now, and wait until the
Dogtag is mature enough. because this IPA solution is the core of our
business authentication and authorization, and so I have been asked
several times to make it reliable and easy to maintain. Otherwise the
admin. official would rather to keep existing Kerberos+OpenLDAP
solution which is time proven.
Now the problem debugging is attached below:
[root@ipaclient09 scripts-EXAMPLE-COM]# sh -x ./db2ldif -n ipaca
...
+ ./ns-slapd db2ldif -D /etc/dirsrv/slapd-EXAMPLE-COM -a
/var/lib/dirsrv/slapd-EXMAPLE-COM/ldif/EXAMPLE-COM-ipaca-2012_04_30_183403.ldif
-n ipaca
[30/Apr/2012:18:34:03 -0700] - /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif:
nsslapd-maxdescriptors: nsslapd-maxdescriptors: invalid value "8192",
maximum file descriptors must range from 1 to 1024 (the current
process limit). Server will use a setting of 1024.
[30/Apr/2012:18:34:03 -0700] - Config Warning: -
nsslapd-maxdescriptors: invalid value "8192", maximum file descriptors
must range from 1 to 1024 (the current process limit). Server will
use a setting of 1024.
[30/Apr/2012:18:34:03 -0700] - ERROR: Could not find backend 'ipaca'
but when I run ns-slapd directly, with config using backed
slapd-PKI-IPA, then it works and a ldif backup file is created.
[root@ipaclient09 scripts-EXAMPLE-COM]# /usr/sbin/ns-slapd db2ldif -D
/etc/dirsrv/slapd-PKI-IPA -a
/var/lib/dirsrv/slapd-PKI-IPA/ldif/PKI-IPA-ipaca-2012_04_30_182524.ldif -n
ipaca
ldiffile:
/var/lib/dirsrv/slapd-PKI-IPA/ldif/PKI-IPA-ipaca-2012_04_30_182524.ldif
[30/Apr/2012:18:37:54 -0700] - export ipaca: Processed 63 entries (100%).
[30/Apr/2012:18:37:54 -0700] - All database threads now stopped
[root@ipaclient09 scripts-PEGACLOUDS-COM]# ls -alF
/var/lib/dirsrv/slapd-PKI-IPA/ldif/PKI-IPA-ipaca-2012_04_30_182524.ldif
-rw---. 1 pkisrv dirsrv 125567 Apr 30 18:37
/var/lib/dirsrv/slapd-PKI-IPA/ldif/PKI-IPA-ipaca-2012_04_30_182524.ldif
[root@ipaclient09 scripts-EXAMPLE-COM]#
It is because slapi-PKI-IPA is a separate 389 instance, and the scripts
are very much instance specific - you cannot use the scripts in
/var/lib/dirsrv/slapd-DOMAIN to manage /etc/dirsrv/slapd-PKI-IPA, nor
can you use the scripts in /usr/lib64/dirsrv/slapd-PKI-IPA to manage
/etc/dirsrv/slapd-DOMAIN
And inside the script db2ldif, it is found that codes are hard-coded
to the user/group/netgroup LDAP backend already, and breaks
backup/restore for PKI-IPA LDAP.
See above
[root@ipaclient09 scripts-EXAMPLE-COM]# grep PKI
/var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif
[root@ipaclient09 scripts-EXAMPLE-COM]# grep EXAMPLE
/var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif
echo /var/lib/dirsrv/slapd-EXAMPLE-COM/ldif/EXAMPLE-COM-`date
+%Y_%m_%d_%H%M%S`.ldif
echo
/var/lib/dirsrv/slapd-EXAMPLE-COM/ldif/EXAMPLE-COM-${be}-`date
+%Y_%m_%d_%H%M%S`.ldif
./ns-slapd db2ldif -D /etc/dirsrv/slapd-EXAMPLE-COM "$@"
./ns-slapd db2ldif -D /etc/dirsrv/slapd-EXAMPLE-COM -a $ldif_file "$@"
[root@ipaclient09 scripts-EXAMPLE-COM]#
--David
*From:* David Copperfield
*To:* Rich Megginson
*Cc:* "freeipa-users@redhat.com"
*Sent:* Monday, April 30, 2012 6:01 PM
*Subject:* Re: [Freeipa-users] Confused/lost at promoting a replica
into a master
Hi Rich and all,
the '-n ipaca' option doesn't work for CA certificate LDAP backend.
[root@ipslave scripts-PEGACLOUDS-COM]# pwd
/var/lib/dirsrv/scripts-PEGACLOUDS-COM
[root@ipaslave scripts-PEGACLOUDS-COM]# ls ../
scripts-PEGACLOUDS-COM slapd-PEGACLOUDS-COM slapd-PKI-IPA
[root@ipaslave scripts-PEGACLOUDS-COM]# ./db2ldif -n ipaca
Exported ldif file:
/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-ipaca-2012_04_30_175927.ldif
...
[30/Apr/2012:17:59:27 -0700] - ERROR: Could not find backend 'ipaca'.
[root@ipaslave scripts-PEGACLOUDS-COM]#
--David
*From:* Rich Megginson
*To:* David Copperfield
*Cc:* "freeipa-users@redhat.com"
*Sent:* Monday, April 30, 2012 5:38 PM
*Subject:* Re: [Freeipa-users] Confused/lost at promoting a replica
into a master
On 04/30/2012 05:52 PM, David Copperfield wrote:
Hi Rich and all,
Thank you a lot for pointing out the place of the
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
On 04/30/2012 07:01 PM, David Copperfield wrote:
Hi Rich and all,
the '-n ipaca' option doesn't work for CA certificate LDAP backend.
[root@ipslave scripts-PEGACLOUDS-COM]# pwd
/var/lib/dirsrv/scripts-PEGACLOUDS-COM
[root@ipaslave scripts-PEGACLOUDS-COM]# ls ../
scripts-PEGACLOUDS-COM slapd-PEGACLOUDS-COM slapd-PKI-IPA
[root@ipaslave scripts-PEGACLOUDS-COM]# ./db2ldif -n ipaca
Exported ldif file:
/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-ipaca-2012_04_30_175927.ldif
...
[30/Apr/2012:17:59:27 -0700] - ERROR: Could not find backend 'ipaca'.
[root@ipaslave scripts-PEGACLOUDS-COM]#
Right. Sorry, forgot to mention that the CA instance puts its scripts
in the "standard" place under /usr/lib64/dirsrv/slapd-PKI-IPA
--David
*From:* Rich Megginson
*To:* David Copperfield
*Cc:* "freeipa-users@redhat.com"
*Sent:* Monday, April 30, 2012 5:38 PM
*Subject:* Re: [Freeipa-users] Confused/lost at promoting a replica
into a master
On 04/30/2012 05:52 PM, David Copperfield wrote:
Hi Rich and all,
Thank you a lot for pointing out the place of the scripts.
The scripts are found at the place specified and trued, they are
working great in general, but there are still some places needs help:
1, there are no manual or help regarding the command options. Not
sure where the normal usage could be looked up.
[root@ipamaster scripts-PEGACLOUDS-COM]# man db2ldif
No manual entry for db2ldif
[root@ipamaster scripts-PEGACLOUDS-COM]# ./db2ldif --help
Usage: db2ldif {-n backend_instance}* | {-s includesuffix}*
[{-x excludesuffix}*] [-a outputfile]
[-N] [-r] [-C] [-u] [-U] [-m] [-M] [-1]
Note: either "-n backend_instance" or "-s includesuffix" is required.
[root@ipamaster scripts-PEGACLOUDS-COM]#
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Command_Line_Scripts.html
In general - you can use the .pl scripts when the server is running,
the non-.pl <http://non-.pl> scripts when the server is down. So, use
ldif2db.pl <http://ldif2db.pl> to do an online import.
Also, with ipa, you can use -n userRoot or -n ipaca depending on if
this is the ipa instance or the CA instance.
2, what is the 'official' way increase file descriptors for IPA & 389
Directory server??
[root@ipamaster scripts-PEGACLOUDS-COM]# ./db2ldif -s
'dc=pegaclouds,dc=com'
Exported ldif file:
/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-pegaclouds-2012_04_30_164542.ldif
[30/Apr/2012:16:45:42 -0700] -
/etc/dirsrv/slapd-PEGACLOUDS-COM/dse.ldif: nsslapd-maxdescriptors:
nsslapd-maxdescriptors: invalid value "8192", maximum file
descriptors must range from 1 to 1024 (the current process limit).
Server will use a setting of 1024.
[30/Apr/2012:16:45:42 -0700] - Config Warning: -
nsslapd-maxdescriptors: invalid value "8192", maximum file
descriptors must range from 1 to 1024 (the current process limit).
Server will use a setting of 1024.
...
db2ldif doesn't use file descriptors in the same way as the server
does when it is using them to listen and service incoming connections
- just ignore that message
3, the ldif2db command will abort when IPA(Directory Server) is running.
I have to stop IPA first, then run ldif2db, and fireup IPA at the
end. It may not be a bad thing to avoid potential data base
corruption. But please confirm whether this is a feature or a bug.
[root@ipamaster scripts-PEGACLOUDS-COM]# ./ldif2db -s
'dc=pegaclouds,dc=com' -i
/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-pegaclouds-2012_04_30_163506.ldif
importing data ...
...
[30/Apr/2012:16:50:00 -0700] - Backend Instance: userRoot
[30/Apr/2012:16:50:00 -0700] - Unable to import the database because
it is being used by another slapd process.
[30/Apr/2012:16:50:00 -0700] - Shutting down due to possible
conflicts with other slapd processes
Use ldif2db.pl
Thanks.
--David
*From:* Rich Megginson <mailto:rmegg...@redhat.com>
*To:* David Copperfield <mailto:cao2...@yahoo.com>
*Cc:* E Deon Lackey <mailto:dlac...@redhat.com>;
"freeipa-users@redhat.com" <mailto:freeipa-users@redhat.com>
<mailto:freeipa-users@redhat.com>
*Sent:* Monday, April 30, 2012 4:23 PM
*Subject:* Re: [Freeipa-users] Confused/lost at promoting a replica
into a master
On 04/30/2012 04:58 PM, David Copperfield wrote:
Hi,
>
> Currently, there is no disaster recovery or backup information.
There are a couple of RFEs open to develop this information. My
understanding (and this is something that
> Dmitri or one of the engineers can explain better) is that the
best thing to do is to back up the DS instances us
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
On 04/30/2012 06:47 PM, David Copperfield wrote:
Hi Rich,
Thanks. Those are really helpful.
Though I think I've to learn the underlying 389 Directory Server part
and become an expert as well. :)
Shouldn't be necessary, long term. The goal of IPA is to hide most of
those 389-ish things from you.
--David
*From:* Rich Megginson
*To:* David Copperfield
*Cc:* "freeipa-users@redhat.com"
*Sent:* Monday, April 30, 2012 5:38 PM
*Subject:* Re: [Freeipa-users] Confused/lost at promoting a replica
into a master
On 04/30/2012 05:52 PM, David Copperfield wrote:
Hi Rich and all,
Thank you a lot for pointing out the place of the scripts.
The scripts are found at the place specified and trued, they are
working great in general, but there are still some places needs help:
1, there are no manual or help regarding the command options. Not
sure where the normal usage could be looked up.
[root@ipamaster scripts-PEGACLOUDS-COM]# man db2ldif
No manual entry for db2ldif
[root@ipamaster scripts-PEGACLOUDS-COM]# ./db2ldif --help
Usage: db2ldif {-n backend_instance}* | {-s includesuffix}*
[{-x excludesuffix}*] [-a outputfile]
[-N] [-r] [-C] [-u] [-U] [-m] [-M] [-1]
Note: either "-n backend_instance" or "-s includesuffix" is required.
[root@ipamaster scripts-PEGACLOUDS-COM]#
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Command_Line_Scripts.html
In general - you can use the .pl scripts when the server is running,
the non-.pl <http://non-.pl> scripts when the server is down. So, use
ldif2db.pl <http://ldif2db.pl> to do an online import.
Also, with ipa, you can use -n userRoot or -n ipaca depending on if
this is the ipa instance or the CA instance.
2, what is the 'official' way increase file descriptors for IPA & 389
Directory server??
[root@ipamaster scripts-PEGACLOUDS-COM]# ./db2ldif -s
'dc=pegaclouds,dc=com'
Exported ldif file:
/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-pegaclouds-2012_04_30_164542.ldif
[30/Apr/2012:16:45:42 -0700] -
/etc/dirsrv/slapd-PEGACLOUDS-COM/dse.ldif: nsslapd-maxdescriptors:
nsslapd-maxdescriptors: invalid value "8192", maximum file
descriptors must range from 1 to 1024 (the current process limit).
Server will use a setting of 1024.
[30/Apr/2012:16:45:42 -0700] - Config Warning: -
nsslapd-maxdescriptors: invalid value "8192", maximum file
descriptors must range from 1 to 1024 (the current process limit).
Server will use a setting of 1024.
...
db2ldif doesn't use file descriptors in the same way as the server
does when it is using them to listen and service incoming connections
- just ignore that message
3, the ldif2db command will abort when IPA(Directory Server) is running.
I have to stop IPA first, then run ldif2db, and fireup IPA at the
end. It may not be a bad thing to avoid potential data base
corruption. But please confirm whether this is a feature or a bug.
[root@ipamaster scripts-PEGACLOUDS-COM]# ./ldif2db -s
'dc=pegaclouds,dc=com' -i
/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-pegaclouds-2012_04_30_163506.ldif
importing data ...
...
[30/Apr/2012:16:50:00 -0700] - Backend Instance: userRoot
[30/Apr/2012:16:50:00 -0700] - Unable to import the database because
it is being used by another slapd process.
[30/Apr/2012:16:50:00 -0700] - Shutting down due to possible
conflicts with other slapd processes
Use ldif2db.pl
Thanks.
--David
*From:* Rich Megginson <mailto:rmegg...@redhat.com>
*To:* David Copperfield <mailto:cao2...@yahoo.com>
*Cc:* E Deon Lackey <mailto:dlac...@redhat.com>;
"freeipa-users@redhat.com" <mailto:freeipa-users@redhat.com>
<mailto:freeipa-users@redhat.com>
*Sent:* Monday, April 30, 2012 4:23 PM
*Subject:* Re: [Freeipa-users] Confused/lost at promoting a replica
into a master
On 04/30/2012 04:58 PM, David Copperfield wrote:
Hi,
>
> Currently, there is no disaster recovery or backup information.
There are a couple of RFEs open to develop this information. My
understanding (and this is something that
> Dmitri or one of the engineers can explain better) is that the
best thing to do is to back up the DS instances using db2ldif and
then spin up a new server/replica instance and
> import the backed up data using ldif2db.
Thanks for pointing out a way to do partial backup/restore.
But the command db2ldif, or its sibling command ldif2db can not be
located on IPA master/replica.
look in /var/lib/dirsrv/scripts-YOURDOMAIN-YOURTLD
The IPA servers only install 389-ds-base and 389-ds-base-libs RPMs.
and the two commands doesn't show up anywhere.
Could anyone elaborat
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
I think the problem is figured out, though solution is not easy. Would some one
please open a bug for this problem.
Another close question to ask: Does this means the IPA PKI/CA system is still
in its beta/alpha stage, and better avoid in production IPA deployment?
I've see messages, Q/A in mail list of 389 Directory Server and freeIPA much,
much more often than the Dogtag. If so, I can use --selfsign to install IPA
masters and replicas now, and wait until the Dogtag is mature enough. because
this IPA solution is the core of our business authentication and authorization,
and so I have been asked several times to make it reliable and easy to
maintain. Otherwise the admin. official would rather to keep existing
Kerberos+OpenLDAP solution which is time proven.
Now the problem debugging is attached below:
[root@ipaclient09 scripts-EXAMPLE-COM]# sh -x ./db2ldif -n ipaca
...
+ ./ns-slapd db2ldif -D /etc/dirsrv/slapd-EXAMPLE-COM -a
/var/lib/dirsrv/slapd-EXMAPLE-COM/ldif/EXAMPLE-COM-ipaca-2012_04_30_183403.ldif
-n ipaca
[30/Apr/2012:18:34:03 -0700] - /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif:
nsslapd-maxdescriptors: nsslapd-maxdescriptors: invalid value "8192", maximum
file descriptors must range from 1 to 1024 (the current process limit). Server
will use a setting of 1024.
[30/Apr/2012:18:34:03 -0700] - Config Warning: - nsslapd-maxdescriptors:
invalid value "8192", maximum file descriptors must range from 1 to 1024 (the
current process limit). Server will use a setting of 1024.
[30/Apr/2012:18:34:03 -0700] - ERROR: Could not find backend 'ipaca'
but when I run ns-slapd directly, with config using backed slapd-PKI-IPA, then
it works and a ldif backup file is created.
[root@ipaclient09 scripts-EXAMPLE-COM]# /usr/sbin/ns-slapd db2ldif -D
/etc/dirsrv/slapd-PKI-IPA -a
/var/lib/dirsrv/slapd-PKI-IPA/ldif/PKI-IPA-ipaca-2012_04_30_182524.ldif -n ipaca
ldiffile:
/var/lib/dirsrv/slapd-PKI-IPA/ldif/PKI-IPA-ipaca-2012_04_30_182524.ldif
[30/Apr/2012:18:37:54 -0700] - export ipaca: Processed 63 entries (100%).
[30/Apr/2012:18:37:54 -0700] - All database threads now stopped
[root@ipaclient09 scripts-PEGACLOUDS-COM]# ls -alF
/var/lib/dirsrv/slapd-PKI-IPA/ldif/PKI-IPA-ipaca-2012_04_30_182524.ldif
-rw---. 1 pkisrv dirsrv 125567 Apr 30 18:37
/var/lib/dirsrv/slapd-PKI-IPA/ldif/PKI-IPA-ipaca-2012_04_30_182524.ldif
[root@ipaclient09 scripts-EXAMPLE-COM]#
And inside the script db2ldif, it is found that codes are hard-coded to the
user/group/netgroup LDAP backend already, and breaks backup/restore for PKI-IPA
LDAP.
[root@ipaclient09 scripts-EXAMPLE-COM]# grep PKI
/var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif
[root@ipaclient09 scripts-EXAMPLE-COM]# grep EXAMPLE
/var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif
echo /var/lib/dirsrv/slapd-EXAMPLE-COM/ldif/EXAMPLE-COM-`date
+%Y_%m_%d_%H%M%S`.ldif
echo /var/lib/dirsrv/slapd-EXAMPLE-COM/ldif/EXAMPLE-COM-${be}-`date
+%Y_%m_%d_%H%M%S`.ldif
./ns-slapd db2ldif -D /etc/dirsrv/slapd-EXAMPLE-COM "$@"
./ns-slapd db2ldif -D /etc/dirsrv/slapd-EXAMPLE-COM -a $ldif_file "$@"
[root@ipaclient09 scripts-EXAMPLE-COM]#
--David
From: David Copperfield
To: Rich Megginson
Cc: "freeipa-users@redhat.com"
Sent: Monday, April 30, 2012 6:01 PM
Subject: Re: [Freeipa-users] Confused/lost at promoting a replica into a master
Hi Rich and all,
the '-n ipaca' option doesn't work for CA certificate LDAP backend.
[root@ipslave scripts-PEGACLOUDS-COM]# pwd
/var/lib/dirsrv/scripts-PEGACLOUDS-COM
[root@ipaslave scripts-PEGACLOUDS-COM]# ls ../
scripts-PEGACLOUDS-COM slapd-PEGACLOUDS-COM slapd-PKI-IPA
[root@ipaslave scripts-PEGACLOUDS-COM]# ./db2ldif -n ipaca
Exported ldif file:
/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-ipaca-2012_04_30_175927.ldif
...
[30/Apr/2012:17:59:27 -0700] - ERROR: Could not find backend 'ipaca'.
[root@ipaslave scripts-PEGACLOUDS-COM]#
--David
From: Rich Megginson
To: David Copperfield
Cc: "freeipa-users@redhat.com"
Sent: Monday, April 30, 2012 5:38 PM
Subject: Re: [Freeipa-users] Confused/lost at promoting a replica into a master
On 04/30/2012 05:52 PM, David Copperfield wrote:
Hi Rich and all,
>
>
>
>Thank you a lot for pointing out the place of the scripts.
>
>
>
>The scripts are found at the place specified and trued, they are working great
>in general, but there are still some places needs help:
>
>
>
>1, there are no manual or help regarding the command options. Not sure where
>the normal usage could be looked up.
>
>
>[root@ipamaster scripts-PEGACLOUDS-COM]# man db2ldif
>No manual entry for db2ldif
>
>[root@ipamaster scripts-PEGACLOUDS-COM]# ./db2ldif --help
>Usage: db2ldif {-n backend_instance}* | {-s includesuffix}*
> [{-x excludesuffix}*] [
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
Hi Rich and all,
the '-n ipaca' option doesn't work for CA certificate LDAP backend.
[root@ipslave scripts-PEGACLOUDS-COM]# pwd
/var/lib/dirsrv/scripts-PEGACLOUDS-COM
[root@ipaslave scripts-PEGACLOUDS-COM]# ls ../
scripts-PEGACLOUDS-COM slapd-PEGACLOUDS-COM slapd-PKI-IPA
[root@ipaslave scripts-PEGACLOUDS-COM]# ./db2ldif -n ipaca
Exported ldif file:
/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-ipaca-2012_04_30_175927.ldif
...
[30/Apr/2012:17:59:27 -0700] - ERROR: Could not find backend 'ipaca'.
[root@ipaslave scripts-PEGACLOUDS-COM]#
--David
From: Rich Megginson
To: David Copperfield
Cc: "freeipa-users@redhat.com"
Sent: Monday, April 30, 2012 5:38 PM
Subject: Re: [Freeipa-users] Confused/lost at promoting a replica into a master
On 04/30/2012 05:52 PM, David Copperfield wrote:
Hi Rich and all,
>
>
>
>Thank you a lot for pointing out the place of the scripts.
>
>
>
>The scripts are found at the place specified and trued, they are working great
>in general, but there are still some places needs help:
>
>
>
>1, there are no manual or help regarding the command options. Not sure where
>the normal usage could be looked up.
>
>
>[root@ipamaster scripts-PEGACLOUDS-COM]# man db2ldif
>No manual entry for db2ldif
>
>[root@ipamaster scripts-PEGACLOUDS-COM]# ./db2ldif --help
>Usage: db2ldif {-n backend_instance}* | {-s includesuffix}*
> [{-x excludesuffix}*] [-a outputfile]
> [-N] [-r] [-C] [-u] [-U] [-m] [-M] [-1]
>Note: either "-n backend_instance" or "-s includesuffix" is required.
>[root@ipamaster scripts-PEGACLOUDS-COM]#
>
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Command_Line_Scripts.html
In general - you can use the .pl scripts when the server is running,
the non-.pl scripts when the server is down. So, use ldif2db.pl to do an
online import.
Also, with ipa, you can use -n userRoot or -n ipaca depending on if
this is the ipa instance or the CA instance.
>
>2, what is the 'official' way increase file descriptors for IPA & 389
>Directory server??
>
>
>[root@ipamaster scripts-PEGACLOUDS-COM]# ./db2ldif -s 'dc=pegaclouds,dc=com'
>Exported ldif file:
/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-pegaclouds-2012_04_30_164542.ldif
>[30/Apr/2012:16:45:42 -0700] -
/etc/dirsrv/slapd-PEGACLOUDS-COM/dse.ldif:
nsslapd-maxdescriptors: nsslapd-maxdescriptors: invalid
value "8192", maximum file descriptors must range from 1 to
1024 (the current process limit). Server will use a setting
of 1024.
>[30/Apr/2012:16:45:42 -0700] - Config Warning: -
nsslapd-maxdescriptors: invalid value "8192", maximum file
descriptors must range from 1 to 1024 (the current process
limit). Server will use a setting of 1024.
>...
>
db2ldif doesn't use file descriptors in the same way as the server
does when it is using them to listen and service incoming
connections - just ignore that message
>
>3, the ldif2db command will abort when IPA(Directory Server) is running.
>
>
>
> I have to stop IPA first, then run ldif2db, and fireup IPA at the end. It may
>not be a bad thing to avoid potential data base corruption. But please confirm
>whether this is a feature or a bug.
>
>
>
>[root@ipamaster scripts-PEGACLOUDS-COM]# ./ldif2db -s 'dc=pegaclouds,dc=com'
>-i
>/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-pegaclouds-2012_04_30_163506.ldif
>
>importing data ...
>...
>[30/Apr/2012:16:50:00 -0700] - Backend Instance: userRoot
>[30/Apr/2012:16:50:00 -0700] - Unable to import the database
because it is being used by another slapd process.
>[30/Apr/2012:16:50:00 -0700] - Shutting down due to possible
conflicts with other slapd processes
>
Use ldif2db.pl
>
>Thanks.
>
>
>--David
>
>
>
>
>
> From: Rich Megginson
>To: David Copperfield
>Cc: E Deon Lackey ; "freeipa-users@redhat.com"
>
>Sent: Monday, April 30, 2012 4:23 PM
>Subject: Re: [Freeipa-users] Confused/lost at promoting a replica into a master
>
>
>On 04/30/2012 04:58 PM, David Copperfield wrote:
>Hi,
>>
>>>
>>
>>> Currently, there is no disaster recovery or backup information. There are a
>>> couple of RFEs open to develop this information. My understanding (and this
>>> is something that
>>> Dmitri or one of the engineers can
explain better) is that the best thing to do
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
Hi Rich,
Thanks. Those are really helpful.
Though I think I've to learn the underlying 389 Directory Server part and
become an expert as well. :)
--David
From: Rich Megginson
To: David Copperfield
Cc: "freeipa-users@redhat.com"
Sent: Monday, April 30, 2012 5:38 PM
Subject: Re: [Freeipa-users] Confused/lost at promoting a replica into a master
On 04/30/2012 05:52 PM, David Copperfield wrote:
Hi Rich and all,
>
>
>
>Thank you a lot for pointing out the place of the scripts.
>
>
>
>The scripts are found at the place specified and trued, they are working great
>in general, but there are still some places needs help:
>
>
>
>1, there are no manual or help regarding the command options. Not sure where
>the normal usage could be looked up.
>
>
>[root@ipamaster scripts-PEGACLOUDS-COM]# man db2ldif
>No manual entry for db2ldif
>
>[root@ipamaster scripts-PEGACLOUDS-COM]# ./db2ldif --help
>Usage: db2ldif {-n backend_instance}* | {-s includesuffix}*
> [{-x excludesuffix}*] [-a outputfile]
> [-N] [-r] [-C] [-u] [-U] [-m] [-M] [-1]
>Note: either "-n backend_instance" or "-s includesuffix" is required.
>[root@ipamaster scripts-PEGACLOUDS-COM]#
>
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Command_Line_Scripts.html
In general - you can use the .pl scripts when the server is running,
the non-.pl scripts when the server is down. So, use ldif2db.pl to do an
online import.
Also, with ipa, you can use -n userRoot or -n ipaca depending on if
this is the ipa instance or the CA instance.
>
>2, what is the 'official' way increase file descriptors for IPA & 389
>Directory server??
>
>
>[root@ipamaster scripts-PEGACLOUDS-COM]# ./db2ldif -s 'dc=pegaclouds,dc=com'
>Exported ldif file:
/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-pegaclouds-2012_04_30_164542.ldif
>[30/Apr/2012:16:45:42 -0700] -
/etc/dirsrv/slapd-PEGACLOUDS-COM/dse.ldif:
nsslapd-maxdescriptors: nsslapd-maxdescriptors: invalid
value "8192", maximum file descriptors must range from 1 to
1024 (the current process limit). Server will use a setting
of 1024.
>[30/Apr/2012:16:45:42 -0700] - Config Warning: -
nsslapd-maxdescriptors: invalid value "8192", maximum file
descriptors must range from 1 to 1024 (the current process
limit). Server will use a setting of 1024.
>...
>
db2ldif doesn't use file descriptors in the same way as the server
does when it is using them to listen and service incoming
connections - just ignore that message
>
>3, the ldif2db command will abort when IPA(Directory Server) is running.
>
>
>
> I have to stop IPA first, then run ldif2db, and fireup IPA at the end. It may
>not be a bad thing to avoid potential data base corruption. But please confirm
>whether this is a feature or a bug.
>
>
>
>[root@ipamaster scripts-PEGACLOUDS-COM]# ./ldif2db -s 'dc=pegaclouds,dc=com'
>-i
>/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-pegaclouds-2012_04_30_163506.ldif
>
>importing data ...
>...
>[30/Apr/2012:16:50:00 -0700] - Backend Instance: userRoot
>[30/Apr/2012:16:50:00 -0700] - Unable to import the database
because it is being used by another slapd process.
>[30/Apr/2012:16:50:00 -0700] - Shutting down due to possible
conflicts with other slapd processes
>
Use ldif2db.pl
>
>Thanks.
>
>
>--David
>
>
>
>
>
> From: Rich Megginson
>To: David Copperfield
>Cc: E Deon Lackey ; "freeipa-users@redhat.com"
>
>Sent: Monday, April 30, 2012 4:23 PM
>Subject: Re: [Freeipa-users] Confused/lost at promoting a replica into a master
>
>
>On 04/30/2012 04:58 PM, David Copperfield wrote:
>Hi,
>>
>>>
>>
>>> Currently, there is no disaster recovery or backup information. There are a
>>> couple of RFEs open to develop this information. My understanding (and this
>>> is something that
>>> Dmitri or one of the engineers can
explain better) is that the best thing to do
is to back up the DS instances using db2ldif
and then spin up a new server/replica
instance and
>>> import the backed up data using
ldif2db.
>>
>>Thanks for pointing out a way to do partial
backup/restore.
>>
>>But the command db2ldif, or its sibling
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
On 04/30/2012 05:52 PM, David Copperfield wrote:
Hi Rich and all,
Thank you a lot for pointing out the place of the scripts.
The scripts are found at the place specified and trued, they are
working great in general, but there are still some places needs help:
1, there are no manual or help regarding the command options. Not sure
where the normal usage could be looked up.
[root@ipamaster scripts-PEGACLOUDS-COM]# man db2ldif
No manual entry for db2ldif
[root@ipamaster scripts-PEGACLOUDS-COM]# ./db2ldif --help
Usage: db2ldif {-n backend_instance}* | {-s includesuffix}*
[{-x excludesuffix}*] [-a outputfile]
[-N] [-r] [-C] [-u] [-U] [-m] [-M] [-1]
Note: either "-n backend_instance" or "-s includesuffix" is required.
[root@ipamaster scripts-PEGACLOUDS-COM]#
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Command_Line_Scripts.html
In general - you can use the .pl scripts when the server is running, the
non-.pl scripts when the server is down. So, use ldif2db.pl to do an
online import.
Also, with ipa, you can use -n userRoot or -n ipaca depending on if this
is the ipa instance or the CA instance.
2, what is the 'official' way increase file descriptors for IPA & 389
Directory server??
[root@ipamaster scripts-PEGACLOUDS-COM]# ./db2ldif -s
'dc=pegaclouds,dc=com'
Exported ldif file:
/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-pegaclouds-2012_04_30_164542.ldif
[30/Apr/2012:16:45:42 -0700] -
/etc/dirsrv/slapd-PEGACLOUDS-COM/dse.ldif: nsslapd-maxdescriptors:
nsslapd-maxdescriptors: invalid value "8192", maximum file descriptors
must range from 1 to 1024 (the current process limit). Server will
use a setting of 1024.
[30/Apr/2012:16:45:42 -0700] - Config Warning: -
nsslapd-maxdescriptors: invalid value "8192", maximum file descriptors
must range from 1 to 1024 (the current process limit). Server will
use a setting of 1024.
...
db2ldif doesn't use file descriptors in the same way as the server does
when it is using them to listen and service incoming connections - just
ignore that message
3, the ldif2db command will abort when IPA(Directory Server) is running.
I have to stop IPA first, then run ldif2db, and fireup IPA at the
end. It may not be a bad thing to avoid potential data base
corruption. But please confirm whether this is a feature or a bug.
[root@ipamaster scripts-PEGACLOUDS-COM]# ./ldif2db -s
'dc=pegaclouds,dc=com' -i
/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-pegaclouds-2012_04_30_163506.ldif
importing data ...
...
[30/Apr/2012:16:50:00 -0700] - Backend Instance: userRoot
[30/Apr/2012:16:50:00 -0700] - Unable to import the database because
it is being used by another slapd process.
[30/Apr/2012:16:50:00 -0700] - Shutting down due to possible conflicts
with other slapd processes
Use ldif2db.pl
Thanks.
--David
*From:* Rich Megginson
*To:* David Copperfield
*Cc:* E Deon Lackey ; "freeipa-users@redhat.com"
*Sent:* Monday, April 30, 2012 4:23 PM
*Subject:* Re: [Freeipa-users] Confused/lost at promoting a replica
into a master
On 04/30/2012 04:58 PM, David Copperfield wrote:
Hi,
>
> Currently, there is no disaster recovery or backup information.
There are a couple of RFEs open to develop this information. My
understanding (and this is something that
> Dmitri or one of the engineers can explain better) is that the best
thing to do is to back up the DS instances using db2ldif and then
spin up a new server/replica instance and
> import the backed up data using ldif2db.
Thanks for pointing out a way to do partial backup/restore.
But the command db2ldif, or its sibling command ldif2db can not be
located on IPA master/replica.
look in /var/lib/dirsrv/scripts-YOURDOMAIN-YOURTLD
The IPA servers only install 389-ds-base and 389-ds-base-libs RPMs.
and the two commands doesn't show up anywhere.
Could anyone elaborate how to use the two template commands, or
please point me to the document or http link(s) is enough. Thanks a lot.
[root@ipamaster script-templates]# rpm -qa | grep 389
389-ds-base-1.2.9.14-1.el6_2.2.x86_64
389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64
[root@ipamaster script-templates]# rpm -ql 389-ds-base
389-ds-base-libs | grep -P 'db2ldif|ldif2db'
/usr/share/dirsrv/script-templates/template-db2ldif
/usr/share/dirsrv/script-templates/template-db2ldif.pl
/usr/share/dirsrv/script-templates/template-ldif2db
/usr/share/dirsrv/script-templates/template-ldif2db.pl
[root@ipamaster script-templates]#
--David
___
Freeipa-users mailing list
Freeipa-users@redhat.com <mailto:Freeipa-users@redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users
_
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
Hi Rich and all,
Thank you a lot for pointing out the place of the scripts.
The scripts are found at the place specified and trued, they are working great
in general, but there are still some places needs help:
1, there are no manual or help regarding the command options. Not sure where
the normal usage could be looked up.
[root@ipamaster scripts-PEGACLOUDS-COM]# man db2ldif
No manual entry for db2ldif
[root@ipamaster scripts-PEGACLOUDS-COM]# ./db2ldif --help
Usage: db2ldif {-n backend_instance}* | {-s includesuffix}*
[{-x excludesuffix}*] [-a outputfile]
[-N] [-r] [-C] [-u] [-U] [-m] [-M] [-1]
Note: either "-n backend_instance" or "-s includesuffix" is required.
[root@ipamaster scripts-PEGACLOUDS-COM]#
2, what is the 'official' way increase file descriptors for IPA & 389 Directory
server??
[root@ipamaster scripts-PEGACLOUDS-COM]# ./db2ldif -s 'dc=pegaclouds,dc=com'
Exported ldif file:
/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-pegaclouds-2012_04_30_164542.ldif
[30/Apr/2012:16:45:42 -0700] - /etc/dirsrv/slapd-PEGACLOUDS-COM/dse.ldif:
nsslapd-maxdescriptors: nsslapd-maxdescriptors: invalid value "8192", maximum
file descriptors must range from 1 to 1024 (the current process limit). Server
will use a setting of 1024.
[30/Apr/2012:16:45:42 -0700] - Config Warning: - nsslapd-maxdescriptors:
invalid value "8192", maximum file descriptors must range from 1 to 1024 (the
current process limit). Server will use a setting of 1024.
...
3, the ldif2db command will abort when IPA(Directory Server) is running.
I have to stop IPA first, then run ldif2db, and fireup IPA at the end. It may
not be a bad thing to avoid potential data base corruption. But please confirm
whether this is a feature or a bug.
[root@ipamaster scripts-PEGACLOUDS-COM]# ./ldif2db -s 'dc=pegaclouds,dc=com' -i
/var/lib/dirsrv/slapd-PEGACLOUDS-COM/ldif/PEGACLOUDS-COM-pegaclouds-2012_04_30_163506.ldif
importing data ...
...
[30/Apr/2012:16:50:00 -0700] - Backend Instance: userRoot
[30/Apr/2012:16:50:00 -0700] - Unable to import the database because it is
being used by another slapd process.
[30/Apr/2012:16:50:00 -0700] - Shutting down due to possible conflicts with
other slapd processes
Thanks.
--David
From: Rich Megginson
To: David Copperfield
Cc: E Deon Lackey ; "freeipa-users@redhat.com"
Sent: Monday, April 30, 2012 4:23 PM
Subject: Re: [Freeipa-users] Confused/lost at promoting a replica into a master
On 04/30/2012 04:58 PM, David Copperfield wrote:
Hi,
>
>>
>
>> Currently, there is no disaster recovery or backup information. There are a
>> couple of RFEs open to develop this information. My understanding (and this
>> is something that
>> Dmitri or one of the engineers can explain better)
is that the best thing to do is to back up the DS
instances using db2ldif and then spin up a new
server/replica instance and
>> import the backed up data using ldif2db.
>
>Thanks for pointing out a way to do partial
backup/restore.
>
>But the command db2ldif, or its sibling command ldif2db
can not be located on IPA master/replica.
look in /var/lib/dirsrv/scripts-YOURDOMAIN-YOURTLD
The IPA servers only install 389-ds-base and 389-ds-base-libs RPMs. and the two
commands doesn't show up anywhere.
>
>Could anyone elaborate how to use the two template
commands, or please point me to the document or http
link(s) is enough. Thanks a lot.
>
>
>[root@ipamaster script-templates]# rpm -qa | grep 389
>389-ds-base-1.2.9.14-1.el6_2.2.x86_64
>389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64
>
>[root@ipamaster script-templates]# rpm -ql 389-ds-base
389-ds-base-libs | grep -P 'db2ldif|ldif2db'
>/usr/share/dirsrv/script-templates/template-db2ldif
>/usr/share/dirsrv/script-templates/template-db2ldif.pl
>/usr/share/dirsrv/script-templates/template-ldif2db
>/usr/share/dirsrv/script-templates/template-ldif2db.pl
>[root@ipamaster script-templates]#
>
>--David
>
>
>
>
>___
Freeipa-users mailing list Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
On 04/30/2012 04:58 PM, David Copperfield wrote: Hi, > > Currently, there is no disaster recovery or backup information. There are a couple of RFEs open to develop this information. My understanding (and this is something that > Dmitri or one of the engineers can explain better) is that the best thing to do is to back up the DS instances using db2ldif and then spin up a new server/replica instance and > import the backed up data using ldif2db. Thanks for pointing out a way to do partial backup/restore. But the command db2ldif, or its sibling command ldif2db can not be located on IPA master/replica. look in /var/lib/dirsrv/scripts-YOURDOMAIN-YOURTLD The IPA servers only install 389-ds-base and 389-ds-base-libs RPMs. and the two commands doesn't show up anywhere. Could anyone elaborate how to use the two template commands, or please point me to the document or http link(s) is enough. Thanks a lot. [root@ipamaster script-templates]# rpm -qa | grep 389 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 [root@ipamaster script-templates]# rpm -ql 389-ds-base 389-ds-base-libs | grep -P 'db2ldif|ldif2db' /usr/share/dirsrv/script-templates/template-db2ldif /usr/share/dirsrv/script-templates/template-db2ldif.pl /usr/share/dirsrv/script-templates/template-ldif2db /usr/share/dirsrv/script-templates/template-ldif2db.pl [root@ipamaster script-templates]# --David ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
Hi, > > Currently, there is no disaster recovery or backup information. There are a > couple of RFEs open to develop this information. My understanding (and this > is something that > Dmitri or one of the engineers can explain better) is that the best thing to do is to back up the DS instances using db2ldif and then spin up a new server/replica instance and > import the backed up data using ldif2db. Thanks for pointing out a way to do partial backup/restore. But the command db2ldif, or its sibling command ldif2db can not be located on IPA master/replica. The IPA servers only install 389-ds-base and 389-ds-base-libs RPMs. and the two commands doesn't show up anywhere. Could anyone elaborate how to use the two template commands, or please point me to the document or http link(s) is enough. Thanks a lot. [root@ipamaster script-templates]# rpm -qa | grep 389 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 [root@ipamaster script-templates]# rpm -ql 389-ds-base 389-ds-base-libs | grep -P 'db2ldif|ldif2db' /usr/share/dirsrv/script-templates/template-db2ldif /usr/share/dirsrv/script-templates/template-db2ldif.pl /usr/share/dirsrv/script-templates/template-ldif2db /usr/share/dirsrv/script-templates/template-ldif2db.pl [root@ipamaster script-templates]# --David___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
Hi Deon, Dmitri, and all,
>
> >> Hi follks,
> >
> >> I'm completely lost at reading the IPA document on how to promote a IPA
> >>replica into master IPA. When I'm try to follow the steps listed in the
> >>chapter '16.8.1 Promoting a Replica with a Dogtag Certificate System CA' at
> >>the link
> >>http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/promoting-replica.html#promoting-pki,
> >> the last steps 'g' said:
> >>
> >> g. Disable the redirect settings for CRL generation requests:
> >> master.ca.agent.host=hostname
> >> master.ca.agent.port=port number
> >>
> >> The above instructions don't give any hints of 'hostname', or 'port
> >> number'. users don't have any clues about them, should them be this
> >> replica's name, or the original master's name? and what is the por
> >> t number? it is a TCP port, or a UDP port?
> >
> >The replica is configured to check for information from the master CA -- in
> >this case, asking the master CA to generate a CRL. Those parameters tell the
> >replica where to look. Part of promoting the replica is telling it *not* to
> >look for a master CA. So, those parameters should be blanked or removed.
> >
> >I can definitely make that more clear.
>
>
>
>
> Have you used a --selfsign option when you installed the first server?
> If you did, you installed the server without CA. This is an advanced option
> for those who know why they do not want the CA at all.
> The standard, default way is to not provide --selfsign flag.
> This will install CA on the first replica. On the other replicas you can have
> a CA at your discretion. Or add it later if you did not install it at the
> beginning.
> HTH.
>
>
It's my pleasure to clarify here: no '--selfsign' option was used to create IPA
master, or the first replica, or other replica siblings. But the Dogtag
installation results are:
IPA master has the dogtag systems installed, and the
'/var/lib/pki-ca/conf/CS.conf' file created. Inside there was not
'master.ca.agent.{host,port} statement.
IPA replica (first replica and its siblings): NO dogtag certificate system was
automatically installed. Even no /var/lib/pki-ca/ directory.
By the way, on the document page, the commands 'service pki-ca stop' and
'service pki-ca start' was wrong too -- as there was only 'pki-cad' service,
not 'pki-ca'. :)
So, please have the migration page updated and submit it here so that users can
follow the updated version and give you more feedback immediately. it looks
like a win-win solution.
--David___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
David Copperfield wrote:
Hi Deon and all,
>> Hi follks,
>>
>> I'm completely lost at reading the IPA document on how to promote a
IPA replica into master IPA. When I'm try to follow the steps listed in
the chapter '16.8.1 Promoting a Replica with a Dogtag Certificate System
CA' at the link
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/promoting-replica.html#promoting-pki,
the last steps 'g' said:
>>
>> g. Disable the redirect settings for CRL generation requests:
>> master.ca.agent.host=hostname
>> master.ca.agent.port=port number
>>
>> The above instructions don't give any hints of 'hostname', or 'port
number'. users don't have any clues about them, should them be this
replica's name, or the original master's name? and what is the por
>> t number? it is a TCP port, or a UDP port?
>
>The replica is configured to check for information from the master CA
-- in this case, asking the master CA to generate a CRL. Those
parameters tell the replica where to look. Part of promoting the replica
is telling it *not* to look for a master CA. So, those parameters should
be blanked or removed.
>
>I can definitely make that more clear.
Sure, please elabroate -- I'll still half undertstand only :) This part
is pretty confusing by itself.
First, when a IPA replica is first installed, the dogtag certification
system is not installed at all, so the directory /var/lib/pki-ca/conf
doesn't exist on IPA slave at all. The directory shows after
only after 'ipa-ca-install' command is run on the replica.
After running the command 'ipa-ca-install', in the configuration file
'/var/lib/pki-ca/conf/CS.conf', there are no 'ca.crl.*' statements on
IPA replica at all; there are no master.ca.agent.{host/port} s
tatement either.
What we really need to clarify here, from users' respective, are
elaborated below(may not be completed):
1, how to promote a IPA replica into a IPA master?
All replicas are equal with the exception that:
* some may have a CA and others may not
* some may have a DNS server and others may not
The only distinction that the initial CA installation has is that it is
the one that generates the CRL.
2, What's the effect on other sibling IPA replicas? -- do we need to
break original replication agreement with old IPA master? and create new
aggrement with new server? If so, how to do it?
No, nothing changes, this is all MMR.
3, How to check/verify that new IPA replica is really promoted into new
IPA master?
You would verify that the CRL is being generated on the master you
choose (/var/log/pki-ca/debug).
4, how to check/verify that old IPA Master is stopped its orignal master
function? disowning the master CA in the PKI hierarchy as claimed?
Verify that it is no longer generating a CRL (/var/log/pki-ca/debug)
4, what's the operations on the original IPA master?
4.1 case #1, what is the 'official' steps to remove/decommission
original IPA master? -- what's the steps besides final
'ipa-master-install --uninstall'?
If you are decommissioning an instance then you'll want to break all
replication agreements it has.
4.2 case #2, if the original IPA server is broken completely and all IPA
replica could not reach it? -- Then what's are the steps to promote a
IPA replica? Do we need the orignal /root/cacert.p12?
No, use the documented steps. The only thing to do is to generate the
CRL on a different host.
4.3 case #2, if the original IPA server is only temporarily unreachable?
-- then after an IPA replica is promoted into new IPA master, how to
depromote the orignal IPA master to replica after it is up?
You would just reverse the CRL generation. Note that if the server is
down for longer than the changelog then you'll want to re-initialize bot
the the CA and IPA LDAP databases from one of the other masters.
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
On 04/30/2012 03:02 PM, David Copperfield wrote:
> Hi Deon and all,
>
> >> Hi follks,
> >>
> >> I'm completely lost at reading the IPA document on how to promote
> a IPA replica into master IPA. When I'm try to follow the steps listed
> in the chapter '16.8.1 Promoting a Replica with a Dogtag Certificate
> System CA' at the link
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/promoting-replica.html#promoting-pki,
> the last steps 'g' said:
> >>
> >>g. Disable the redirect settings for CRL generation requests:
> >> master.ca.agent.host=hostname
> >> master.ca.agent.port=port number
> >>
> >> The above instructions don't give any hints of 'hostname', or 'port
> number'. users don't have any clues about them, should them be this
> replica's name, or the original master's name? and what is the por
> >> t number? it is a TCP port, or a UDP port?
> >
> >The replica is configured to check for information from the master CA
> -- in this case, asking the master CA to generate a CRL. Those
> parameters tell the replica where to look. Part of promoting the
> replica is telling it *not* to look for a master CA. So, those
> parameters should be blanked or removed.
> >
> >I can definitely make that more clear.
Have you used a --selfsign option when you installed the first server?
If you did, you installed the server without CA. This is an advanced
option for those who know why they do not want the CA at all.
The standard, default way is to not provide --selfsign flag.
This will install CA on the first replica. On the other replicas you can
have a CA at your discretion. Or add it later if you did not install it
at the beginning.
HTH.
>
> Sure, please elabroate -- I'll still half undertstand only :) This
> part is pretty confusing by itself.
>
> First, when a IPA replica is first installed, the dogtag certification
> system is not installed at all, so the directory /var/lib/pki-ca/conf
> doesn't exist on IPA slave at all. The directory shows after
> only after 'ipa-ca-install' command is run on the replica.
>
> After running the command 'ipa-ca-install', in the configuration file
> '/var/lib/pki-ca/conf/CS.conf', there are no 'ca.crl.*' statements on
> IPA replica at all; there are no master.ca.agent.{host/port} s
> tatement either.
>
> What we really need to clarify here, from users' respective, are
> elaborated below(may not be completed):
>
> 1, how to promote a IPA replica into a IPA master?
>
> 2, What's the effect on other sibling IPA replicas? -- do we need to
> break original replication agreement with old IPA master? and create
> new aggrement with new server? If so, how to do it?
>
> 3, How to check/verify that new IPA replica is really promoted into
> new IPA master?
>
> 4, how to check/verify that old IPA Master is stopped its orignal
> master function? disowning the master CA in the PKI hierarchy as claimed?
>
> 4, what's the operations on the original IPA master?
> 4.1 case #1, what is the 'official' steps to remove/decommission
> original IPA master? -- what's the steps besides final
> 'ipa-master-install --uninstall'?
> 4.2 case #2, if the original IPA server is broken completely and all
> IPA replica could not reach it? -- Then what's are the steps to
> promote a IPA replica? Do we need the orignal /root/cacert.p12?
> 4.3 case #2, if the original IPA server is only temporarily
> unreachable? -- then after an IPA replica is promoted into new IPA
> master, how to depromote the orignal IPA master to replica after it is up?
>
> >>
> >> As a serious evaluator of IPA, I have to think more above just for
> fun. So it is a natural thought to think about disaster recovery and
> smooth/continuous operations(simulation and real case): how to back up
> data,
> >
> >Currently, there is no disaster recovery or backup information. There
> are a couple of RFEs open to develop this information. My
> understanding (and this is something that Dmitri or one of the
> engineers can explain better) is that the best thing to do is to back
> up the DS instances using db2ldif and then spin up a new
> server/replica instance and import the backed up data using ldif2db.
> >
> >
>
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
Hi Deon and all,
>> Hi follks,
>>
>> I'm completely lost at reading the IPA document on how to promote a IPA
>>replica into master IPA. When I'm try to follow the steps listed in the
>>chapter '16.8.1 Promoting a Replica with a Dogtag Certificate System CA' at
>>the link
>>http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/promoting-replica.html#promoting-pki,
>> the last steps 'g' said:
>>
>> g. Disable the redirect settings for CRL generation requests:
>> master.ca.agent.host=hostname
>> master.ca.agent.port=port number
>>
>> The above instructions don't give any hints of 'hostname', or 'port number'.
>> users don't have any clues about them, should them be this replica's name,
>> or the original master's name? and what is the por
>> t number? it is a TCP port, or a UDP port?
>
>The replica is configured to check for information from the master CA -- in
>this case, asking the master CA to generate a CRL. Those parameters tell the
>replica where to look. Part of promoting the replica is telling it *not* to
>look for a master CA. So, those parameters should be blanked or removed.
>
>I can definitely make that more clear.
Sure, please elabroate -- I'll still half undertstand only :) This part is
pretty confusing by itself.
First, when a IPA replica is first installed, the dogtag certification system
is not installed at all, so the directory /var/lib/pki-ca/conf doesn't exist on
IPA slave at all. The directory shows after
only after 'ipa-ca-install' command is run on the replica.
After running the command 'ipa-ca-install', in the configuration file
'/var/lib/pki-ca/conf/CS.conf', there are no 'ca.crl.*' statements on IPA
replica at all; there are no master.ca.agent.{host/port} s
tatement either.
What we really need to clarify here, from users' respective, are elaborated
below(may not be completed):
1, how to promote a IPA replica into a IPA master?
2, What's the effect on other sibling IPA replicas? -- do we need to break
original replication agreement with old IPA master? and create new aggrement
with new server? If so, how to do it?
3, How to check/verify that new IPA replica is really promoted into new IPA
master?
4, how to check/verify that old IPA Master is stopped its orignal master
function? disowning the master CA in the PKI hierarchy as claimed?
4, what's the operations on the original IPA master?
4.1 case #1, what is the 'official' steps to remove/decommission original IPA
master? -- what's the steps besides final 'ipa-master-install --uninstall'?
4.2 case #2, if the original IPA server is broken completely and all IPA
replica could not reach it? -- Then what's are the steps to promote a IPA
replica? Do we need the orignal /root/cacert.p12?
4.3 case #2, if the original IPA server is only temporarily unreachable? --
then after an IPA replica is promoted into new IPA master, how to depromote the
orignal IPA master to replica after it is up?
>>
>> As a serious evaluator of IPA, I have to think more above just for fun. So
>> it is a natural thought to think about disaster recovery and
>> smooth/continuous operations(simulation and real case): how to back up data,
>
>Currently, there is no disaster recovery or backup information. There are a
>couple of RFEs open to develop this information. My understanding (and this is
>something that Dmitri or one of the engineers can explain better) is that the
>best thing to do is to back up the DS instances using db2ldif and then spin up
>a new server/replica instance and import the backed up data using ldif2db.
>
>___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Confused/lost at promoting a replica into a master
On 4/27/2012 10:20 PM, David Copperfield wrote: Hi follks, I'm completely lost at reading the IPA document on how to promote a IPA replica into master IPA. When I'm try to follow the steps listed in the chapter '16.8.1 Promoting a Replica with a Dogtag Certificate System CA' at the link http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/promoting-replica.html#promoting-pki, the last steps 'g' said: g. Disable the redirect settings for CRL generation requests: master.ca.agent.host=hostname master.ca.agent.port=port number The above instructions don't give any hints of 'hostname', or 'port number'. users don't have any clues about them, should them be this replica's name, or the original master's name? and what is the por t number? it is a TCP port, or a UDP port? Hi, Guolin, The replica is configured to check for information from the master CA -- in this case, asking the master CA to generate a CRL. Those parameters tell the replica where to look. Part of promoting the replica is telling it *not* to look for a master CA. So, those parameters should be blanked or removed. I can definitely make that more clear. As a serious evaluator of IPA, I have to think more above just for fun. So it is a natural thought to think about disaster recovery and smooth/continuous operations(simulation and real case): how to back up data, Currently, there is no disaster recovery or backup information. There are a couple of RFEs open to develop this information. My understanding (and this is something that Dmitri or one of the engineers can explain better) is that the best thing to do is to back up the DS instances using db2ldif and then spin up a new server/replica instance and import the backed up data using ldif2db. how to promote replica into master, etc. But this document just post quite way too much challenges for me. :) What challenges? Can you elaborate? Or, even better, file a bug so that I can make the docs better! (I'm the doc writer.) One thing that would be helpful to me is to know what kinds of scenarios you need covered; then I can work with engineering to get something into the documentation. Thank you very much for your feedback! Deon ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Confused/lost at promoting a replica into a master
Hi follks, I'm completely lost at reading the IPA document on how to promote a IPA replica into master IPA. When I'm try to follow the steps listed in the chapter '16.8.1 Promoting a Replica with a Dogtag Certificate System CA' at the link http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/promoting-replica.html#promoting-pki, the last steps 'g' said: g. Disable the redirect settings for CRL generation requests: master.ca.agent.host=hostname master.ca.agent.port=port number The above instructions don't give any hints of 'hostname', or 'port number'. users don't have any clues about them, should them be this replica's name, or the original master's name? and what is the por t number? it is a TCP port, or a UDP port? As a serious evaluator of IPA, I have to think more above just for fun. So it is a natural thought to think about disaster recovery and smooth/continuous operations(simulation and real case): how to back up data, how to promote replica into master, etc. But this document just post quite way too much challenges for me. :) Any one who have successfuly passed this test, please shed a light here. Thanks a lot. --Guolin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
