Reinhard Nappert wrote: > Yes, this works! How about existing replication agreements? > I'm not sure. They may "just work" too. > -----Original Message----- > From: fedora-directory-users-bounces at redhat.com > [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Rich > Megginson > Sent: Friday, April 04, 2008 12:09 PM > To: General discussion list for the Fedora Directory server project. > Subject: Re: Isit possibleto migrateBerkeley > 4.2(32bit)based directory to 4.2 (64bit) > > Reinhard Nappert wrote: > >> No, it does not. It looks like you need a value. >> >> > What if you shutdown, delete that entry completely from dse.ldif, then > restart? > >> So, I installed a 64 bit version from scratch, took that generated >> value in the migrated dse.ldif and started the server. This works, >> however it is kind of ugly. Now, this brings up another question: If I >> > > >> do something like that (with perl?), do I screw up my replication >> > agreements? > >> -Reinhard >> >> -----Original Message----- >> From: fedora-directory-users-bounces at redhat.com >> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Rich >> Megginson >> Sent: Friday, April 04, 2008 10:19 AM >> To: General discussion list for the Fedora Directory server project. >> Subject: Re: Is it possibleto migrateBerkeley >> 4.2(32bit) based directory to 4.2 (64bit) >> >> Reinhard Nappert wrote: >> >> >>> Rick, >>> >>> It looks like it is ok just using the same old data and point to the >>> db directory. However, I experienced one hick-up. During the >>> migration >>> >>> >> >> >>> of the config data (dse.ldif) within migrate-ds.pl, the migration of >>> the nsstate attribute for the uniqueid generator fails. When starting >>> > > >>> the directory, I get: >>> [03/Apr/2008:15:46:26 -0400] uuid - read_state: failed to get >>> generator's state >>> [03/Apr/2008:15:46:26 -0400] uuid - uuid_init: failed to get >>> generator's state >>> [03/Apr/2008:15:46:26 -0400] uniqueid generator - uniqueIDGenInit: >>> generator ini >>> tialization failed >>> >>> Do you have any idea? >>> >>> >>> >> Yes. Unfortunately, that attribute contains raw binary data that may >> not be 64-bit clean. If you shutdown the server, delete that >> attribute, and start the server, does it work? >> >> >>> -Reinhard >>> >>> -----Original Message----- >>> From: fedora-directory-users-bounces at redhat.com >>> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Rich >>> Megginson >>> Sent: Thursday, April 03, 2008 1:30 PM >>> To: General discussion list for the Fedora Directory server project. >>> Subject: Re: Is it possible to >>> >>> >> migrateBerkeley >> >> >>> 4.2(32bit) based directory to 4.2 (64bit) >>> >>> Reinhard Nappert wrote: >>> >>> >>> >>>> Thanks Rick, >>>> >>>> You are saying, I have to export it at first. >>>> >>>> Initially, I just built 1.1 in 32bit mode (with the identical db >>>> library). With that, I even was just using the same directory and it >>>> > > >>>> worked fine. So, I guess I have to go the export/import way. >>>> >>>> >>>> >>>> >>> I'm just really not sure. I don't think we write any longs or other >>> 64-bit values to the database with 1.1. So it may just work and be >>> fine. >>> >>> >>> >>>> Cheers, >>>> -Reinhard >>>> >>>> -----Original Message----- >>>> From: fedora-directory-users-bounces at redhat.com >>>> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Rich >>>> > > >>>> Megginson >>>> Sent: Thursday, April 03, 2008 12:12 PM >>>> To: General discussion list for the Fedora Directory server project. >>>> Subject: Re: Is it possible to migrate >>>> Berkeley >>>> 4.2(32bit) based directory to 4.2 (64bit) >>>> >>>> Reinhard Nappert wrote: >>>> >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> Does anyone know, if that works? >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Are you talking about the migration script migrate-ds-admin.pl? If >>>> so, then yes. You will first have to export your databases to ldif >>>> e.g. for a Fedora DS 1.0.4 installation: >>>> cd /opt/fedora-ds/slapd-instance/db >>>> ../db2ldif -n userRoot -a `pwd`/userRoot.ldif ../db2ldif -n >>>> NetscapeRoot -a `pwd`/NetscapeRoot.ldif ... repeat for each database >>>> > > >>>> instance >>>> >>>> The migration script will look for a file called >>>> /opt/fedora-ds/slapd-instance/db/<db instance name>.ldif and use >>>> that >>>> >>>> >> >> >>>> rather than the binary files. >>>> >>>> You should also run the migration script with the -x option to force >>>> > > >>>> it to use cross platform mode. >>>> >>>> >>>> >>>> >>>>> Thanks, >>>>> -Reinhard >>>>> >>>>> >>>>> >>>>> >> --------------------------------------------------------------------- >> >> >>>>> - >>>>> -- >>>>> >>>>> -- >>>>> Fedora-directory-users mailing list >>>>> Fedora-directory-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>>>> >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> Fedora-directory-users mailing list >>>> Fedora-directory-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>>> >>>> >>>> >>>> >>> -- >>> Fedora-directory-users mailing list >>> Fedora-directory-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> >>> >>> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> >> > > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20080404/121e2905/attachment.bin
