Hi all,
FYI: I created a pull request for the migration how to
in https://github.com/389ds/389ds.github.io/pull/21
Feel free to comment on it.
Most point mentioned by Oron should be covered except:
* SOHO specific information:
Because I do not know how 389 ds is deployed in such environment
but I expect that the database is relatively small so the single command method should work
* The following question:
LDIF authentication -- is it just usual kinit? or some DS specific parameter/command?
I am not understanding that question.
And I suspect that there is a typo and that it is about LDAP authentication (i.e authenticating through LDAP protocol) which is one of the basic service that a LDAP server provides) But I do not see the link with kinit except that the server is usually started by systemd when booting)
FYI: I created a pull request for the migration how to
in https://github.com/389ds/389ds.github.io/pull/21
Feel free to comment on it.
Most point mentioned by Oron should be covered except:
* SOHO specific information:
Because I do not know how 389 ds is deployed in such environment
but I expect that the database is relatively small so the single command method should work
* The following question:
LDIF authentication -- is it just usual kinit? or some DS specific parameter/command?
I am not understanding that question.
And I suspect that there is a typo and that it is about LDAP authentication (i.e authenticating through LDAP protocol) which is one of the basic service that a LDAP server provides) But I do not see the link with kinit except that the server is usually started by systemd when booting)
On Thu, Jun 26, 2025 at 9:56 AM Alexander Bokovoy <abokovoy@xxxxxxxxxx> wrote:
On Срд, 25 чэр 2025, Oron Peled wrote:
>Hi,
>
>I've played with LDIF export/import years before IPA, but there's still big knowledge gap.
>A SOHO installation is not rare and we need a detailed howto for in-place migration (with obvious downtime)
>This documentation is more critical because upstream (RHEL) doesn't support this path.
>
>Example stuff:
> * Checking used backend (like was provided in this mail thread)
> * Listing which services should be down (i.e: ldif offline export, or online DS with other IPA parts down)
> * LDIF authentication -- is it just usual kinit? or some DS specific parameter/command?
> * What's the path of the database? (only for DS-offline export if that's the recommended path)
> * Precise commands with parameters and options for export and import
> * Sanity checks before/after migration
>
>Also:
> * This howto should be published well before migration
>(so it's indexed by search engines before people start searching in amok after instances get broken)
> * Most of this information is very useful for general backup/recovery in any SOHO installation
>Therefore it's best to prepare it as such and use DB switchover as an example use-case
> * A link to a preliminary draft may be published here, so we can carefully try it and provide feedback and improvements.
>(e.g: someone on this thread had an issue with finding the instance name...)
>
>Thank you all for the hard work, it's fully understood that such a switchover isn't trivial upgrade.
I just migrated my Fedora 42 deployment that was running since 2013 from
bdb to mdb backend by using a single command, as described in the Change
itself:
# systemctl stop dirsrv@INSTANCE-NAME
# dsctl INSTANCE-NAME dblib bdb2mdb
cleanup dbmapdir=/var/lib/dirsrv/slapd-INSTANCE-NAME/db dbhome=/dev/shm/slapd-INSTANCE-NAME dblib=bdb
Required space for LDIF files is about 6.7 MB
Required space for DBMAP files is about 109.3 MB
Required number of dbi is 256
Backends exportation 0.000000% (changelog)
ldiffile: /var/lib/dirsrv/slapd-INSTANCE-NAME/ldif/__dblib-changelog.ldif
Backends exportation 0.205885% (ipaca)
ldiffile: /var/lib/dirsrv/slapd-INSTANCE-NAME/ldif/__dblib-ipaca.ldif
Exporting changelog /var/lib/dirsrv/slapd-INSTANCE-NAME/db/ipaca/replication_changelog.db to /var/lib/dirsrv/slapd-INSTANCE-NAME/ldif/__dblib-ipaca.cl5.dbtxt
Backends exportation 28.257699% (userroot)
ldiffile: /var/lib/dirsrv/slapd-INSTANCE-NAME/ldif/__dblib-userroot.ldif
Exporting changelog /var/lib/dirsrv/slapd-INSTANCE-NAME/db/userRoot/replication_changelog.db to /var/lib/dirsrv/slapd-INSTANCE-NAME/ldif/__dblib-userroot.cl5.dbtxt
Backends exportation 100%
Updating dse.ldif file
Backends importation 0.000000% (changelog)
Backends importation 0.205885% (ipaca)
Importing changelog /var/lib/dirsrv/slapd-INSTANCE-NAME/db/ipaca/replication_changelog.db from /var/lib/dirsrv/slapd-INSTANCE-NAME/ldif/__dblib-ipaca.cl5.dbtxt
Backends importation 28.257699% (userroot)
Importing changelog /var/lib/dirsrv/slapd-INSTANCE-NAME/db/userRoot/replication_changelog.db from /var/lib/dirsrv/slapd-INSTANCE-NAME/ldif/__dblib-userroot.cl5.dbtxt
Backends importation 100%
Migration from Berkeley database to lmdb is done.
# systemctl start dirsrv@INSTANCE-NAME
We cannot really automate it as export of the database will require
enough space to handle it. You can adjust optiosn to bdb2mdb subcommand
to specify a temporary location for that but the command needs to be run
by the administrators manually.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
389 Directory Server Development Team
389 Directory Server Development Team
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
