[Freeipa-users] Confused/lost at promoting a replica into a master

Tue May 1 02:38:12 UTC 2012

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 at 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 at 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 at 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 at 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 at ipaclient09 scripts-EXAMPLE-COM]# grep PKI 
> /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif
> [root at 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 at ipaclient09 scripts-EXAMPLE-COM]#
>
> --David
>
>
>
>
>
> ------------------------------------------------------------------------
> *From:* David Copperfield <cao2dan at yahoo.com>
> *To:* Rich Megginson <rmeggins at redhat.com>
> *Cc:* "freeipa-users at redhat.com" <freeipa-users at 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 at ipslave scripts-PEGACLOUDS-COM]# pwd
> /var/lib/dirsrv/scripts-PEGACLOUDS-COM
> [root at ipaslave scripts-PEGACLOUDS-COM]# ls ../
> scripts-PEGACLOUDS-COM  slapd-PEGACLOUDS-COM  slapd-PKI-IPA
>
> [root at 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 at ipaslave scripts-PEGACLOUDS-COM]#
>
> --David
>
>
> ------------------------------------------------------------------------
> *From:* Rich Megginson <rmeggins at redhat.com>
> *To:* David Copperfield <cao2dan at yahoo.com>
> *Cc:* "freeipa-users at redhat.com" <freeipa-users at 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 at ipamaster scripts-PEGACLOUDS-COM]# man db2ldif
>> No manual entry for db2ldif
>>
>> [root at 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 at 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 at 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 at 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 <rmeggins at redhat.com> <mailto:rmeggins at redhat.com>
>> *To:* David Copperfield <cao2dan at yahoo.com> <mailto:cao2dan at yahoo.com>
>> *Cc:* E Deon Lackey <dlackey at redhat.com> <mailto:dlackey at redhat.com>; 
>> "freeipa-users at redhat.com" <mailto:freeipa-users at redhat.com> 
>> <freeipa-users at redhat.com> <mailto:freeipa-users at 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 at 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 at 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 at ipamaster script-templates]#
>>>
>>> --David
>>>
>>>
>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com  <mailto:Freeipa-users at redhat.com>
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>>
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>
> https://www.redhat.com/mailman/listinfo/freeipa-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120430/f74d6509/attachment.htm>