SEARCH
NEW RPMS
DIRECTORIES
ABOUT
FAQ
VARIOUS
BLOG

BotDetect - Real-Time Bot Detection API
 
 

MAN page from OpenSuSE 389-ds-2.2.8~git37.fdb3bae-1.12.x86_64.rpm

OPENLDAP_TO_DS

Section: Generated Python Manual (1)
Updated: 2023-08-15
Index 

NAME

openldap_to_ds 

SYNOPSIS

openldap_to_ds[-h] [-v] [--confirm] [--ignore-overlay [IGNORE_OVERLAY ...]] [--ignore-schema-oid [IGNORE_SCHEMA_OID ...]] [--ignore-attribute [IGNORE_ATTRIBUTE ...]] [-D BINDDN] [-w BINDPW] [-W] [-y PWDFILE] [-Z] instance slapd_config [slapd_ldif ...] 

DESCRIPTION

Migrate from OpenLDAP to 389 Directory Server.

This command automates the process of converting an OpenLDAP server to a 389 Directory Serverinstance. This is a "best effort" as OpenLDAP and 389 Directory Server are not identical,so some features still may require hand migration, or can not be migrated at all. This toolintends to migrate the majority of major content such as database data, index configuration,schema and some overlays (plugins).

Content we can migrate:

* Schema* Database content (from ldif backup)* Database indexes* MemberOf Overlay (memberof)* Referential Integrity Overlay (refint)* Attribute Unique Overlay (unique)

Some content that can *not* be migrated include some overlays (plugins), access controlsand replication configuration. Examples of plugins that can not be migrated:

* Access/Audit logging (built into 389-ds by default)* Chaining (Requires manual migration, may not be equivalent)* Constraints (No equivalent plugin)* Dynamic Directory Services (Requires manual migration to Class of Service Plugin)* Dynamic Groups/Lists (Requires manual migration to Roles Plugin)* Proxy Cache (No equivalent plugin, 389-ds supports read-only replicas)* Password Policy (Built into 389-ds, requires manual migration)* Rewrite/Remap (No equivalent plugin)* Sync Provider (Requires manual migration to Replication OR Content Sync Plugin)* Value Sorting (No equivalent plugin)

This must be run on the server running the 389 Directory Instance as it requires filesystemaccess. You must run this tool as either root or dirsrv users.

The following is required from your openldap instance:


  * slapd.d configuration directory in ldif/dynamic format
  * (optional) ldif file backup of the database from slapcat

These can be created on the OpenLDAP host and copied to the 389 Directory Server host. Nodestructive actions are applied to the OpenLDAP instance.

If you are already using the ldif/dynamic format from /etc/openldap/slapd.d, you shouldtake a copy of this to use in the migration.


    cp -a /etc/openldap/slapd.d /root/slapd.d

If you are using the slapd.conf configuration file, you can convert this to the dynamicconfiguration without affecting your running instance with:


    slaptest -f /etc/openldap/slapd.conf -F /root/slapd.d

To optionally allow your database content to be migrated you may create an ldif backup of thecontent that 389 Directory Server can import. You must run this for each backend (suffix)of your instance with the command:


    # If using slapd.conf config format
    slapcat -f /etc/openldap/slapd.conf -b SUFFIX -l /root/suffix.ldif
    # If using slapd.d config format
    slapcat -F /etc/openldap/slapd.d -b SUFFIX -l /root/suffix.ldif

You must already have a 389 Directory Server you want to import into. You can createthis with the `dscreate` tool. Data and configuration in this instance WILL bemodified or removed (ie potentially destructive actions).

It is strongly advised you test this tool on a non-production system first to besure the process and changes are understood.

This only needs to be run on the first-instance in a 389 Directory Server topology. Allother replicas should be configured from this instance post migration.

instance
The name of the 389-ds instance to have openldap data migrated into

slapd_config
The path to the openldap slapd.d configuration that will be migrated

slapd_ldif
The path to exported database ldifs to be imported.

 

OPTIONS

-v, --verbose
Display verbose operation tracing during command execution

--confirm
Confirm that you want to apply these migration actions to the 389-ds instance. By default no actions are taken.

--ignore-overlay ,[IGNORE_OVERLAY ...]/
Ignore the following openldap overlays from having their configuration migrated to equivalent 389-ds plugins. Valid options are memberof, refint, unique.

--ignore-schema-oid ,[IGNORE_SCHEMA_OID ...]/
Ignore the following openldap schema attribute or class OIDS from being migrated to 389-ds. This *may* create inconsistent schema which could cause the migration to fail. Use with caution.

--ignore-attribute ,[IGNORE_ATTRIBUTE ...]/
Ignore the following attributes from entries that are loaded from the ldif. For example, you may not want to import userPassword hashes.

-D ,BINDDN/, --binddn ,BINDDN/
The 389 Directory Server account to bind as for executing migration operations

-w ,BINDPW/, --bindpw ,BINDPW/
Password for binddn

-W, --prompt
Prompt for password for the bind DN

-y ,PWDFILE/, --pwdfile ,PWDFILE/
Specifies a file containing the password for the binddn

-Z, --starttls
Connect to 389 Directory Server with StartTLS

 

AUTHOR

Red Hat, Inc., and William Brown <389-develAATTlists.fedoraproject.org>

 

DISTRIBUTION

The latest version of lib389 may be downloaded from


 

Index

NAME
SYNOPSIS
DESCRIPTION
OPTIONS
AUTHOR
DISTRIBUTION

This document was created byman2html,using the manual pages.
 
ICM Bot detect detector