Hi, Many thanks to Alexander Bokovoy and Pierre Rogier: * I've just upgraded with the proposed single command, everything work like a charm. * This is a DS used as part of miniature (and not critical) freeipa instance.
Answering some of my questions that weren't so clear I wasn't sure if exporting to LDIF was planned from a live DS or directly from offline data: * As Piere suspected I wrote about LDIF commands, when meant LDAP tools. * Alexander's answer clarified this for me -- its first step was stopping "dirsrv@....service" I.e: offline export, no authentication is relevant (no kinit vs. DS authentication) Last but not least, I've looked at the new documentation PR by Piere and it's very good and detailed. Thanks again, I'm totally good and ready for future releases ;-) -- Oron Peled On Thursday, 26 June 2025 17:28:43 IDT Pierre Rogier wrote: > 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 > > > > > -- Oron Peled Voice: +972-4-8228492 "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." --Robert Wilensky, University of California
-- _______________________________________________ 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
