Re: Isit possibleto migrateBerkeley 4.2(32bit)based directory to 4.2 (64bit)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx
[mailto:fedora-directory-users-bounces@xxxxxxxxxx] 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@xxxxxxxxxx
[mailto:fedora-directory-users-bounces@xxxxxxxxxx] 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@xxxxxxxxxx
[mailto:fedora-directory-users-bounces@xxxxxxxxxx] 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@xxxxxxxxxx
[mailto:fedora-directory-users-bounces@xxxxxxxxxx] 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users


--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users

<<attachment: smime.p7s>>

--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux