Fedora Info

Friday, July 10, 2026

[389-users] Re: Question about 389-ds versions for RHEL

On Wed, Jul 08, 2026 at 05:58:32PM +0200, Viktor Ashirov via 389-users wrote: > > RHEL 10. Running "dnf copr enable @389ds/389-directory-server" results > > in an error: > > Error: It wasn't possible to enable this project. > > Repository 'epel-10-x86_64' does not exist in project > > '@389ds/389-directory-server'. > > > Thanks for bringing this to our attention. I will update the COPR repos and > the instructions on the download page. Thank you! -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

Thursday, July 9, 2026

[389-users] Re: high memory usage in 2.7.0

Thank you, Victor, this is super helpful, i've added them to my Dockerfile.

-morgan

On Jul 7, 2026, at 03:32, Viktor Ashirov via 389-users <389-users@lists.fedoraproject.org> wrote:

Hi,

On Thu, Jul 2, 2026 at 11:36 PM Morgan Jones via 389-users <389-users@lists.fedoraproject.org> wrote:

Hello,

I am struggling to determine why 389-Directory/2.7.0 B2026.064.0000 is using a crippling amount of memory.

I'm not married to 2.7.0, just looking for something stable and actively supported but not too new.

We're running it in Docker on almalinux:9.

If you're running it in Docker, make sure the server uses jemalloc and THP is disabled:
ENV THP_DISABLE=1 LD_PRELOAD=/usr/lib64/dirsrv/lib/libjemalloc.so.2

If I set nsslapd-cache-autosize to much over 5 ns-slapd consumes memory and is killed by the OOM. I have increased docker's memory limit to that of the host but if it's smaller the same happens, sometimes just sooner as the OOM sees the process exceed Docker's limits.

The server has 16gb of ram, I have turned off the NDN cache.

ns-slapd is using 14gb of ram not leaving much for the OS. nsslapd-cache-autosize is set to 5, where is all of the memory going??

Here's the current state of the cache:

# docker exec -it sdp389ds dsconf localhost monitor dbmon
DB Monitor Report: 2026-07-02 17:24:32
--------------------------------------------------------
Database Cache:
- Cache Hit Ratio: 89%
- Free Space: 101.89 MB
- Free Percentage: 51.3%
- RO Page Drops: 14972351
- Pages In: 15086991
- Pages Out: 405261

Backends:
- dc=philasd,dc=org (userRoot):
- Entry Cache Hit Ratio: 13%
- Entry Cache Count: 38259
- Entry Cache Free Space: 6.8 KB
- Entry Cache Free Percentage: 0.0%
- Entry Cache Average Size: 15.42 KB
- DN Cache Hit Ratio: 97%
- DN Cache Count: 336275
- DN Cache Free Space: 37.42 MB
- DN Cache Free Percentage: 58.5%
- DN Cache Average Size: 82.0 B

#

Any advice would be appreciated, I have to be missing something simple here!

Thank you,

-morgan
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

--

Viktor

--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

-- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Re: high memory usage in 2.7.0

Hello Marc, Thanks for this, it took a minute to test this thoroughly but early results are great. Details are below but I tried 5gb dbcachesize and ns-slapd is now using about 50% of memory. I will read deeper on manual tuning but is the general conclusion here that cache auto tuning either isn't reliable in docker or maybe just in 2.x? Regarding version, we are a large educational institution and this is our core authentication platform, we value stability over features: does 3.2.1 make sense to run in production? We tend to prefer to stay a version behind, we want the stable but still supported version. I confirmed THP is disabled and I presume you meant dbcachesize vs cache-memsize though maybe things are different in 3.x, we're (now) on 2.8.0. Here are the settings I'm testing with: morganj@dev-ds-1-app-5:~$ docker exec -it 389ds dsconf localhost backend config get|grep cache nsslapd-import-cachesize: 16777216 nsslapd-dbcachesize: 5000000000 nsslapd-import-cache-autosize: -1 nsslapd-cache-autosize: 0 nsslapd-cache-autosize-split: 25 morganj@dev-ds-1-app-5:~$ and the results after our test run, which, if it's of intersting, is a single run of Google Cloud Directory Sync (GCDS): DB Monitor Report: 2026-07-09 11:41:30 -------------------------------------------------------- Database Cache: - Cache Hit Ratio: 96% - Free Space: 0 B - Free Percentage: 0.0% - RO Page Drops: 0 - Pages In: 349752 - Pages Out: 1521 Normalized DN Cache: - Cache Hit Ratio: 67% - Free Space: 0 B - Free Percentage: 0.0% - DN Count: 124830 - Evictions: 1692281 Backends: - dc=domain,dc=org (userRoot): - Entry Cache Hit Ratio: 35% - Entry Cache Count: 167919 - Entry Cache Free Space: 14.93 KB - Entry Cache Free Percentage: 0.0% - Entry Cache Average Size: 16.39 KB - DN Cache Hit Ratio: 74% - DN Cache Count: 335647 - DN Cache Free Space: 293.5 MB - DN Cache Free Percentage: 91.7% - DN Cache Average Size: 82.0 B total used free shared buff/cache available Mem: 15902 7110 1353 2 7618 8791 Swap: 2559 0 2559 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND morganj 1179397 0.0 0.0 5692 2140 pts/0 S+ 09:55 0:00 tee -a ns-slapd_mem2.out morganj 1412010 0.0 0.0 6544 2472 pts/0 S+ 11:41 0:00 grep -E slap|VSZ root 2808191 6.0 50.9 12506904 8294800 ? Sl Jul08 87:12 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-localhost -d 266354688 thank you! -morgan > On Jul 6, 2026, at 08:25, Marc Sauton <msauton@redhat.com> wrote: > > about entry cache use and configuration: > the auto tuning is expected to provide with the most optimized configuration. > but in this case, it may be interesting to try different manual > configuration to change the dynamics in order to eother workaround an > eventual memory leak, or minimize memory fragmentation. > > for example: > > dsconf SOME-INSTANCE-NAME backend config get | grep cache > dsconf SOME-INSTANCE-NAME backend config set --cache-autosize=0 > dsconf SOME-INSTANCE-NAME backend suffix set > --cache-memsize=5000000000 userRoot # example 5 GB for userRoot > dsconf SOME-INSTANCE-NAME backend config get | grep cache > > or with the Cockpit web UI: > https://localhost/389-console > root > password > > Database tab > "Global Database Configuration" > > > about THP, it should be disabled for the ns-slapd process, to verify, try: > grep THP /proc/$(pidof ns-slapd)/status > > > about 389-ds versions: > > per the page at https://www.port389.org/ , the last release is: > 2026-04-29: Released 389-ds-base 3.2.1 > as well as per https://lists.fedoraproject.org/archives/list/389-announce@lists.fedoraproject.org/2026/4/ > https://lists.fedoraproject.org/archives/list/389-announce@lists.fedoraproject.org/thread/ADCDPLPTVSXYSF57UEL7QICWU3UB6MRL/ > Announcing 389 Directory Server 3.2.1 (F45/Rawhide) > and > https://github.com/389ds/389-ds-base/ > ( note there are 3.3 and 3.2.2 for devel ) > > > I can only speak for Fedora, CentOS, and RHEL. I will let others on > this list to comment about Alma, I would expect no issues, but I do > not know the available versions on Alma. > > Cordially, > Marc S. > > > On Fri, Jul 3, 2026 at 1:41 PM Morgan Jones <mjones6@morganjones.org> wrote: >> >> Hello Marc, >> >> Thanks for the quick reply. My responses are inline. >> >>> On Jul 3, 2026, at 05:51, Marc Sauton <msauton@redhat.com> wrote: >>> >>> Hello, >>> The memory increase could be fragmentation. >>> It looks like the entry cache may be too small at around 600MB, you >>> could try tune it up to 1GB or 2GB, up to 5GB, the DB size may be >>> around 5GB. >> >> Well, I had to set auto sizing to 5% to get it to run without crashing so, yeah, the cache is tiny >> >> Do you mean turn off auto sizing and set the entry cache manually? >> >> If I understand you correctly it's a good guess, we're 6gb. Is 16gb of ram not sufficient for a 6gb database? >> >> [root@cb5c999df0ed db]# ls >> DBVERSION __db.001 __db.002 __db.003 log.0000000119 userRoot >> [root@cb5c999df0ed db]# du -sh >> 6.0G . >> [root@cb5c999df0ed db]# du -sh userRoot >> 5.7G userRoot >> [root@cb5c999df0ed db]# >> >> >>> You could also verify if THP is disabled for the LDAP process, >> >> I just read about this last night and it's set to madvise--is that sufficient? I can set to never and test if you're not sure. >> >> [root@cb5c999df0ed /]# cat /sys/kernel/mm/transparent_hugepage/enabled >> always [madvise] never >> [root@cb5c999df0ed /]# >> >>> Note the version 2.7 is from 2025 and there has been a number of >>> serious fixes since then, I would consider to upgrade, add some more >>> recent replicas. >> >> We're still testing so i can switch to any version, I'm trying to stick with whatever is the most current/stable version, is 2.7.0 not the newest 2.x version? Should we be considering 3.x? >> >> And either way is Alma 9 the right base? >> >> thank you! >> >> -morgan >> >>> Thanks, >>> Marc S. >>> >>> On Thu, Jul 2, 2026 at 9:35 PM Morgan Jones via 389-users >>> <389-users@lists.fedoraproject.org> wrote: >>>> >>>> Hello, >>>> >>>> I am struggling to determine why 389-Directory/2.7.0 B2026.064.0000 is using a crippling amount of memory. >>>> >>>> I'm not married to 2.7.0, just looking for something stable and actively supported but not too new. >>>> >>>> We're running it in Docker on almalinux:9. >>>> >>>> If I set nsslapd-cache-autosize to much over 5 ns-slapd consumes memory and is killed by the OOM. I have increased docker's memory limit to that of the host but if it's smaller the same happens, sometimes just sooner as the OOM sees the process exceed Docker's limits. >>>> >>>> The server has 16gb of ram, I have turned off the NDN cache. >>>> >>>> ns-slapd is using 14gb of ram not leaving much for the OS. nsslapd-cache-autosize is set to 5, where is all of the memory going?? >>>> >>>> Here's the current state of the cache: >>>> >>>> # docker exec -it 389ds dsconf localhost monitor dbmon >>>> DB Monitor Report: 2026-07-02 17:24:32 >>>> -------------------------------------------------------- >>>> Database Cache: >>>> - Cache Hit Ratio: 89% >>>> - Free Space: 101.89 MB >>>> - Free Percentage: 51.3% >>>> - RO Page Drops: 14972351 >>>> - Pages In: 15086991 >>>> - Pages Out: 405261 >>>> >>>> Backends: >>>> - dc=domain,dc=org (userRoot): >>>> - Entry Cache Hit Ratio: 13% >>>> - Entry Cache Count: 38259 >>>> - Entry Cache Free Space: 6.8 KB >>>> - Entry Cache Free Percentage: 0.0% >>>> - Entry Cache Average Size: 15.42 KB >>>> - DN Cache Hit Ratio: 97% >>>> - DN Cache Count: 336275 >>>> - DN Cache Free Space: 37.42 MB >>>> - DN Cache Free Percentage: 58.5% >>>> - DN Cache Average Size: 82.0 B >>>> >>>> # >>>> >>>> >>>> Any advice would be appreciated, I have to be missing something simple here! >>>> >>>> Thank you, >>>> >>>> -morgan >>>> -- >>>> _______________________________________________ >>>> 389-users mailing list -- 389-users@lists.fedoraproject.org >>>> To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org >>>> Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new >>> >> > -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

Wednesday, July 8, 2026

[Test-Announce] Fedora 45 Rawhide 20260709.n.0 nightly compose nominated for testing

Announcing the creation of a new nightly release validation test event for Fedora 45 Rawhide 20260709.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20260630.n.0: anaconda-45.9-1.fc45.src, 20260709.n.0: anaconda-45.11-1.fc45.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/45 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260709.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260709.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260709.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260709.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260709.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260709.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260709.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://forge.fedoraproject.org/quality/relvalconsumer -- _______________________________________________ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-leave@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/test-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Re: Question about 389-ds versions for RHEL

Hi,

On Wed, Jul 8, 2026 at 5:11 PM Bryan K. Walton via 389-users <389-users@lists.fedoraproject.org> wrote:

Thank you for the reply, Antonis. It is nice to know that I'm not the
only worried about this. Not only is there a question about the status
of the packages in the repo. The instructions on:
https://www.port389.org/docs/389ds/download.html don't even work for
RHEL 10. Running "dnf copr enable @389ds/389-directory-server" results
in an error:
Error: It wasn't possible to enable this project.
Repository 'epel-10-x86_64' does not exist in project '@389ds/389-directory-server'.

Thanks for bringing this to our attention. I will update the COPR repos and the instructions on the download page.

-Bryan

On Tue, Jul 07, 2026 at 06:39:35PM +0300, Antonis Kopsaftis via 389-users wrote:
> Hello,
>
> I had similar concerns over the past year.
> The packages available through the various repos are either old or generally
> not updated.
> The packages which are included in the distros are fine, but no package for
> cockpit is available.
>
> So we choose to setup a separate VM with the same OS with our new LDAP
> servers. In our case it was Oracle Linux 9.x
>
> We followed the instructions on
> https://www.port389.org/docs/389ds/development/building.html
> and manage to compile various 2.x versions of 389DS.
> The we took the created rpms and installed 389DS on our servers. After a
> couple of months of testing, we are running in production.
>
> We also tried to compile various 3.x versions, but we did not succeed. The
> binaries were compiled successfully but the rpm packaging failed.
>
> My personal opinion is that the development of the project is focuses for
> Fedora OS and not RHEL clones.

Indeed, we focus on Fedora and RHEL.

The core server (389-ds-base package) is available in the AppStream repos of RHEL and its clones, so you can install it directly with `dnf install 389-ds-base`. This version is very well tested, it goes through extensive QE cycles as part of the RHEL release process, and receives regular bug fixes and security updates throughout the RHEL lifecycle. However, the COPR versions have not received nearly the same level of testing as the RHEL version. They are community-provided builds that may work well, but they come without the same quality assurance guarantees.

> So as RHEL clones have older version of various packages (e.g various python
> modules), the build is not always successfully in RHEL clones.
>
> Antonis
>
> On 7/7/2026 4:40 μ.μ., Bryan K. Walton via 389-users wrote:
> > Hi,
> >
> > I have a few questions about the 389-ds versions available for RHEL.
> >
> > On https://www.port389.org/docs/389ds/download.html it states that to
> > install the cockpit-389-ds package, we must use the copr repo.
> > When we enable that repo on RHEL 8, the newest version of 389-ds-base and
> > cockpit-389-ds available to us is 2.2.9. This seems to correspond with
> > this page:
> > https://copr.fedorainfracloud.org/coprs/g/389ds/389-directory-server/builds/
> >
> > That pages shows that the most recent successful build was version
> > 2.2.9-2. However, digging around the copr servers, I see an epel 8
> > version 2.5.2 available here:
> > https://download.copr.fedorainfracloud.org/results/%40389ds/389-directory-server-2.5/epel-8-x86_64/08189134-389-ds-base/
> >
> > Questions:
> > 1. Is that 2.5.2 version bad?
> > 2. Is the 2.2.9 version really the lastest supported version for RHEL 8?
> > 3. If we upgrade our server to RHEL 10, I see that epel 10 has version
> > 3.2.0 of 389-ds-base in it. How do we get a newer version of
> > cockpit-389-ds for use with the newer versions of 389-ds-base?
> >
> > Thanks,
> > Bryan Walton
>
> --
> _______________________________________________
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org
> Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

--
Bryan K. Walton 319-337-3877
Senior Linux Systems Administrator Leepfrog Technologies, Inc
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

Viktor

[389-users] Re: Question about 389-ds versions for RHEL

Thank you for the reply, Antonis. It is nice to know that I'm not the only worried about this. Not only is there a question about the status of the packages in the repo. The instructions on: https://www.port389.org/docs/389ds/download.html don't even work for RHEL 10. Running "dnf copr enable @389ds/389-directory-server" results in an error: Error: It wasn't possible to enable this project. Repository 'epel-10-x86_64' does not exist in project '@389ds/389-directory-server'. -Bryan On Tue, Jul 07, 2026 at 06:39:35PM +0300, Antonis Kopsaftis via 389-users wrote: > Hello, > > I had similar concerns over the past year. > The packages available through the various repos are either old or generally > not updated. > The packages which are included in the distros are fine, but no package for > cockpit is available. > > So we choose to setup a separate VM with the same OS with our new LDAP > servers. In our case it was Oracle Linux 9.x > > We followed the instructions on > https://www.port389.org/docs/389ds/development/building.html > and manage to compile various 2.x versions of 389DS. > The we took the created rpms and installed 389DS on our servers. After a > couple of months of testing, we are running in production. > > We also tried to compile various 3.x versions, but we did not succeed. The > binaries were compiled successfully but the rpm packaging failed. > > My personal opinion is that the development of the project is focuses for > Fedora OS and not RHEL clones. > So as RHEL clones have older version of various packages (e.g various python > modules), the build is not always successfully in RHEL clones. > > Antonis > > On 7/7/2026 4:40 μ.μ., Bryan K. Walton via 389-users wrote: > > Hi, > > > > I have a few questions about the 389-ds versions available for RHEL. > > > > On https://www.port389.org/docs/389ds/download.html it states that to > > install the cockpit-389-ds package, we must use the copr repo. > > When we enable that repo on RHEL 8, the newest version of 389-ds-base and > > cockpit-389-ds available to us is 2.2.9. This seems to correspond with > > this page: > > https://copr.fedorainfracloud.org/coprs/g/389ds/389-directory-server/builds/ > > > > That pages shows that the most recent successful build was version > > 2.2.9-2. However, digging around the copr servers, I see an epel 8 > > version 2.5.2 available here: > > https://download.copr.fedorainfracloud.org/results/%40389ds/389-directory-server-2.5/epel-8-x86_64/08189134-389-ds-base/ > > > > Questions: > > 1. Is that 2.5.2 version bad? > > 2. Is the 2.2.9 version really the lastest supported version for RHEL 8? > > 3. If we upgrade our server to RHEL 10, I see that epel 10 has version > > 3.2.0 of 389-ds-base in it. How do we get a newer version of > > cockpit-389-ds for use with the newer versions of 389-ds-base? > > > > Thanks, > > Bryan Walton > > -- > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org > Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new -- Bryan K. Walton 319-337-3877 Senior Linux Systems Administrator Leepfrog Technologies, Inc -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

Tuesday, July 7, 2026

[389-users] Re: Question about 389-ds versions for RHEL

Hello, I had similar concerns over the past year. The packages available through the various repos are either old or generally not updated. The packages which are included in the distros are fine, but no package for cockpit is available. So we choose to setup a separate VM with the same OS with our new LDAP servers. In our case it was Oracle Linux 9.x We followed the instructions on https://www.port389.org/docs/389ds/development/building.html and manage to compile various 2.x versions of 389DS. The we took the created rpms and installed 389DS on our servers. After a couple of months of testing, we are running in production. We also tried to compile various 3.x versions, but we did not succeed. The binaries were compiled successfully but the rpm packaging failed. My personal opinion is that the development of the project is focuses for Fedora OS and not RHEL clones. So as RHEL clones have older version of various packages (e.g various python modules), the build is not always successfully in RHEL clones. Antonis On 7/7/2026 4:40 μ.μ., Bryan K. Walton via 389-users wrote: > Hi, > > I have a few questions about the 389-ds versions available for RHEL. > > On https://www.port389.org/docs/389ds/download.html it states that to > install the cockpit-389-ds package, we must use the copr repo. > When we enable that repo on RHEL 8, the newest version of 389-ds-base and > cockpit-389-ds available to us is 2.2.9. This seems to correspond with > this page: > https://copr.fedorainfracloud.org/coprs/g/389ds/389-directory-server/builds/ > > That pages shows that the most recent successful build was version > 2.2.9-2. However, digging around the copr servers, I see an epel 8 > version 2.5.2 available here: > https://download.copr.fedorainfracloud.org/results/%40389ds/389-directory-server-2.5/epel-8-x86_64/08189134-389-ds-base/ > > Questions: > 1. Is that 2.5.2 version bad? > 2. Is the 2.2.9 version really the lastest supported version for RHEL 8? > 3. If we upgrade our server to RHEL 10, I see that epel 10 has version > 3.2.0 of 389-ds-base in it. How do we get a newer version of > cockpit-389-ds for use with the newer versions of 389-ds-base? > > Thanks, > Bryan Walton -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new