[Freeipa-users] (no subject)

Thu Mar 15 15:39:11 UTC 2012

I tried the export/import but the import fails. I tried it a couple
different ways, creating a new, empty userRoot directory- and tried
importing to the original userRoot. Both times it failed and removed
the directory userRoot. I still have the orig userRoot dir.

/var/lib/dirsrv/scripts-ABC-XYZ/ldif2db -n userRoot -i /dbexport/output.ldif
importing data ...
[10/Mar/2012:19:09:57 +0000] - I'm resizing my cache now...cache was
419196928 and is now 8000000
[10/Mar/2012:19:09:58 +0000] - All database threads now stopped
[10/Mar/2012:19:09:58 +0000] - I'm resizing my cache now...cache was
419196928 and is now 8000000
[10/Mar/2012:19:09:58 +0000] - WARNING: Import is running with
nsslapd-db-private-import-mem on; No other process is allowed to
access the database
[10/Mar/2012:19:09:58 +0000] - check_and_set_import_cache: pagesize:
4096, pages: 255859, procpages: 56195
[10/Mar/2012:19:09:58 +0000] - WARNING: After allocating import cache
409372KB, the available memory is 614064KB, which is less than the
soft limit 1048576KB. You may want to decrease the import cache size
and rerun import.
[10/Mar/2012:19:09:58 +0000] - Import allocates 409372KB import cache.
[10/Mar/2012:19:09:59 +0000] - import userRoot: Beginning import job...
[10/Mar/2012:19:09:59 +0000] - import userRoot: Index buffering
enabled with bucket size 100
[10/Mar/2012:19:09:59 +0000] - import userRoot: Processing file
"/dbexport/output.ldif"
[10/Mar/2012:19:09:59 +0000] - import userRoot: Finished scanning file
"/dbexport/output.ldif" (328 entries)
[10/Mar/2012:19:09:59 +0000] entryrdn-index - _entryrdn_insert_key:
Same DN (dn: ou=profile,dc=abc,dc=xyz) is already in the entryrdn file
with different ID 146.  Expected ID is 327.
[10/Mar/2012:19:09:59 +0000] - import userRoot: Duplicated DN
detected: "ou=profile,dc=abc,dc=xyz": Entry ID: (327)
[10/Mar/2012:19:09:59 +0000] - import userRoot: Aborting all Import threads...
[10/Mar/2012:19:10:06 +0000] - import userRoot: Import threads aborted.
[10/Mar/2012:19:10:06 +0000] - import userRoot: Closing files...
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/krbPrincipalName.db4:
unable to flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/sn.db4: unable to
flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/uid.db4: unable to
flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/givenName.db4: unable
to flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/displayname.db4: unable
to flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/cn.db4: unable to
flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/telephoneNumber.db4:
unable to flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/entryrdn.db4: unable to
flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/entryusn.db4: unable to
flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/nsuniqueid.db4: unable
to flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/uidnumber.db4: unable
to flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/objectclass.db4: unable
to flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/gidnumber.db4: unable
to flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/parentid.db4: unable to
flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/id2entry.db4: unable to
flush: No such file or directory
[10/Mar/2012:19:10:06 +0000] - libdb: userRoot/aci.db4: unable to
flush: No such file or directory
[10/Mar/2012:19:10:07 +0000] - libdb: userRoot/memberOf.db4: unable to
flush: No such file or directory
[10/Mar/2012:19:10:07 +0000] - libdb: userRoot/member.db4: unable to
flush: No such file or directory
[10/Mar/2012:19:10:07 +0000] - libdb: userRoot/ou.db4: unable to
flush: No such file or directory
/var/lib/dirsrv/slapd-ABC-XYZ/db/userRoot: No such file or directory
[10/Mar/2012:19:10:07 +0000] - All database threads now stopped
[10/Mar/2012:19:10:07 +0000] - import userRoot: Import failed.

On Thu, Mar 15, 2012 at 9:15 AM, Jimmy <g17jimmy at gmail.com> wrote:
> The version 1.2.10.a1 is odd, because it was originally installed
> using yum. I didn't hack it together at all. I'll do the export/import
> and see how it goes.
> -Jimmy
>
> On Wed, Mar 14, 2012 at 7:37 PM, Rich Megginson <rmeggins at redhat.com> wrote:
>> On 03/14/2012 03:59 PM, Rich Megginson wrote:
>>>
>>> On 03/14/2012 03:51 PM, Jimmy Caldwell wrote:
>>>>
>>>> Is this a normal thing to occur during upgrade?
>>>
>>> Unfortunately, in this particular case, yes.
>>>>
>>>> If it was just a fluke
>>>> I can revert to the snapshot from just before the upgrade and try
>>>> again.
>>>
>>> I think you will run into the same exact problem.
>>
>>
>> Another problem - according to http://fpaste.org/nSWh/ you were using
>> 1.2.10.a1 - I'm not sure how that happened - on F-15, none of the alpha
>> versions were pushed to Stable afaik (unlike F-16).  We did not (nor
>> normally do not) test upgrades from alpha versions to "stable" versions.
>>  According to
>> https://admin.fedoraproject.org/updates/FEDORA-2011-13460/389-ds-base-1.2.10-0.1.a1.fc15
>> this was never pushed to Stable, only to Testing.
>>
>>>>
>>>> Sent from my mobile device
>>>>
>>>> On Mar 14, 2012, at 17:44, Rich Megginson<rmeggins at redhat.com>  wrote:
>>>>
>>>>> On 03/14/2012 03:26 PM, Jimmy wrote:
>>>>>>
>>>>>> http://fpaste.org/nSWh/
>>>>>
>>>>> Thanks.  Looks like you are going to have to export your database to
>>>>> ldif, re-import it, and then re-initialize all of your replicas.
>>>>>
>>>>>
>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html
>>>>>
>>>>> For ipa, the scripts are in /var/lib/dirsrv/scripts-YOUR-DOMAIN
>>>>>
>>>>> For ipa, your database is userRoot (so -n userRoot)
>>>>>
>>>>> so first, do db2ldif, then ldif2db, then use ipa-replica-manage to
>>>>> reinitialize all of your replicas
>>>>>>
>>>>>> Here ya go
>>>>>> Jimmy
>>>>>>
>>>>>> On Wed, Mar 14, 2012 at 5:11 PM, Rich Megginson<rmeggins at redhat.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 03/14/2012 03:13 PM, Jimmy wrote:
>>>>>>>>
>>>>>>>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514
>>>>>>>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514
>>>>>>>
>>>>>>> It appears that the entryrdn upgrade didn't work.  Can you sanitize
>>>>>>> your
>>>>>>> /var/log/dirsrv/slapd-DOMAIN/errors file and post it to fpaste.org?
>>>>>>>
>>>>>>>> On Wed, Mar 14, 2012 at 5:06 PM, Rich Megginson<rmeggins at redhat.com>
>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>> On 03/14/2012 03:05 PM, Jimmy wrote:
>>>>>>>>>>
>>>>>>>>>> This doesn't appear to be very good. If I drop the `grep` I see the
>>>>>>>>>> data I would expect to see.
>>>>>>>>>>
>>>>>>>>>> dbscan -f
>>>>>>>>>> /var/lib/dirsrv/slapd-YOUR-DOMAIN/db/userRoot/entryrdn.db4|grep
>>>>>>>>>> cn=etc
>>>>>>>>>> 22:cn=etc
>>>>>>>>>>   ID: 22; RDN: "cn=etc"; NRDN: "cn=etc"
>>>>>>>>>>   ID: 22; RDN: "cn=etc"; NRDN: "cn=etc"
>>>>>>>>>> C22:cn=etc
>>>>>>>>>> C22:cn=etc
>>>>>>>>>> C22:cn=etc
>>>>>>>>>> C22:cn=etc
>>>>>>>>>> C22:cn=etc
>>>>>>>>>> C22:cn=etc
>>>>>>>>>> C22:cn=etc
>>>>>>>>>> C22:cn=etc
>>>>>>>>>>   ID: 22; RDN: "cn=etc"; NRDN: "cn=etc"
>>>>>>>>>>   ID: 22; RDN: "cn=etc"; NRDN: "cn=etc"
>>>>>>>>>>   ID: 22; RDN: "cn=etc"; NRDN: "cn=etc"
>>>>>>>>>>   ID: 22; RDN: "cn=etc"; NRDN: "cn=etc"
>>>>>>>>>> P22:cn=etc
>>>>>>>>>>   ID: 22; RDN: "cn=etc"; NRDN: "cn=etc"
>>>>>>>>>>   ID: 22; RDN: "cn=etc"; NRDN: "cn=etc"
>>>>>>>>>>   ID: 22; RDN: "cn=etc"; NRDN: "cn=etc"
>>>>>>>>>>   ID: 22; RDN: "cn=etc"; NRDN: "cn=etc"
>>>>>>>>>
>>>>>>>>> find /var/lib/dirsrv/slapd-YOUR-DOMAIN/db -name DBVERSION -exec cat
>>>>>>>>> {} \;
>>>
>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>