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) On Thu, Jun 26, 2025 at 9:56 AM Alexander Bokovoy <aboko...@redhat.com> 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- -- 389 Directory Server Development Team
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
