389-users July 2019

389-users@lists.fedoraproject.org

12 participants
25 discussions

Re: 389-DS Downgrade Breaks dirsrv.target
by William Brown 17 Jul '19

17 Jul '19

Dirsrv.target was a "mistake" added by someone at RH. I removed it a few years ago, and it probably just got to you now. It should never have been added, and existed because I think people didn't really know how systemd dependencies worked. It caused no end of issues because people didn't enable the dirsrv.target, and doing a "systemctl enable dirsrv@instance" enabled into the dirsrv.target, so many people complained they couldn't autostart their instances in RH/Fedora. It really served no benefit because we can resolve all the needed deps in a .service file, and we can more easily be part of the default system targets. As a result, all dirsrv@instances when "enabled" should be part of multi-user.target instead from now on on RH/SUSE. Sorry about the confusion here, we should have advertised this better. > On 16 Jul 2019, at 22:17, Paul Whitney <paul.whitney(a)chesapeake-it.com> wrote: > > Good morning William, > > Sorry for the delayed response, when I run "systemctl start dirsrv.target" there is no delay and returns me to the prompt. In the logs (/var/log/messages) I see positive response indicating that the target has reached its destination. But when I check for the slapd process, they are non-existent. > > When I start the slapd processes through "systemctl start dirsrv@config" the slapd starts fine. If I attempt to stop using "systemctl stop dirsrv.target", nothing happens. It continues to run. I compared the systemd files between a working server and the none working server. The only thing I found was the missing symbolic links in > > Paul M. Whitney, RHCSA, CISSP > Chesapeake IT Consulting, Inc. > 2680 Tobacco Rd > Chesapeake Beach, MD 20732 > > Work: 443-492-2872 > Cell: 410.493.9448 > Email: paul.whitney(a)chesapeake-it.com > CONFIDENTIALITY NOTICE > The information contained in this facsimile or electronic message is confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this facsimile message to the intended recipient, you are hereby notified that any dissemination, or copying of this communication is strictly prohibited. If this message contains non-public personal information about any consumer or customer of the sender or intended recipient, you are further prohibited under penalty of law from using or disclosing the information to any third party by provisions of the federal Gramm-Leach-Bliley Act. If you have received this facsimile or electronic message in error, please immediately notify us by telephone and return or destroy the original message to assure that it is not read, copied, or distributed by others. > > > From: William Brown <wbrown(a)suse.de> > Sent: Thursday, July 11, 2019 8:49 PM > To: 389-users(a)lists.fedoraproject.org > Subject: [389-users] Re: 389-DS Downgrade Breaks dirsrv.target > > > > > On 12 Jul 2019, at 00:04, Paul Whitney <paul.whitney(a)chesapeake-it.com> wrote: > > > > When attempting to downgrade 389-ds-base from version 1.3.8.4-23 to version 1.3.7.5-18 I discovered that the systemctl cannot start dirsrv.target. I am able to start the individual instances however. Any suggestions on how to resolve this? > > > > I am only downgrading: > > • 389-ds-base > > • 389-ds-base-libs > > • 389-ds-base devel > > • 389-ds-base-snmp > > Am I missing another package that should be downgraded? > > That should be enough I think? Can you detail what and how it's "breaking" and what evidence you have about this? That would help us to identify what's going wrong here. > > Thanks, > > > > > > Thanks in advance, > > > > Paul M. Whitney, RHCSA, CISSP > > Chesapeake IT Consulting, Inc. > > 2680 Tobacco Rd > > Chesapeake Beach, MD 20732 > > > > Work: 443-492-2872 > > Cell: 410.493.9448 > > Email: paul.whitney(a)chesapeake-it.com > > CONFIDENTIALITY NOTICE > > The information contained in this facsimile or electronic message is confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this facsimile message to the intended recipient, you are hereby notified that any dissemination, or copying of this communication is strictly prohibited. If this message contains non-public personal information about any consumer or customer of the sender or intended recipient, you are further prohibited under penalty of law from using or disclosing the information to any third party by provisions of the federal Gramm-Leach-Bliley Act. If you have received this facsimile or electronic message in error, please immediately notify us by telephone and return or destroy the original message to assure that it is not read, copied, or distributed by others. > > > > _______________________________________________ > > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > > To unsubscribe send an email to 389-users-leave(a)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… > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)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… > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)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… — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs

1 0

Re: LDAP Groups in sudoers file.
by Abhisheyk Deb 17 Jul '19

17 Jul '19

Hi Paul, Thank you for your reply, apparently the LDAP client was configured using nslcd. We have a similar configuration file called /etc/nslcd.conf and a parameter called nss_initgroups_ignoreusers which I have set to ALLLOCAL. This can be useful in case of unavailability of the LDAP server, which is what I want. The value ALLLOCAL may be used. With that value nslcd builds a full list of non-LDAP users on startup. This is what is written in the man page of nslcd.conf. I have also restarted the nslcd service after the changed configuration. Plus I also changed the value of ALLLOCAL to an exact list of users, even that did not help. Even with all the changes, we are still getting a delay when doing sudo, which means it may not be consulting this file at all. Thank you Abhishek Deb On Wed, Jul 17, 2019 at 4:09 PM Paul Whitney <paul.whitney(a)chesapeake-it.com> wrote: > The one thing I would look at is your /etc/sssd/sssd.conf file. Assuming > you are configured for LDAP, you could exclude the the local admin account > in the [nss] section with the "filter_users" setting. > > Example: > > [nss] > filter_users = root,nagios,local_admin_acct > > That should get SSSD to not look up the user in LDAPS and hopefully > expedite your login. Again, assuming you are using SSSD. > > Paul M. Whitney, RHCSA, CISSP > Chesapeake IT Consulting, Inc. > 2680 Tobacco Rd > Chesapeake Beach, MD 20732 > > Work: 443-492-2872 > Cell: 410.493.9448 > Email: paul.whitney(a)chesapeake-it.com > *CONFIDENTIALITY NOTICE* > The information contained in this facsimile or electronic message is > confidential information intended for the use of the individual or entity > named above. If the reader of this message is not the intended recipient, > or an employee or agent responsible for delivering this facsimile message > to the intended recipient, you are hereby notified that any dissemination, > or copying of this communication is strictly prohibited. If this message > contains non-public personal information about any consumer or customer of > the sender or intended recipient, you are further prohibited under penalty > of law from using or disclosing the information to any third party by > provisions of the federal Gramm-Leach-Bliley Act. If you have received this > facsimile or electronic message in error, please immediately notify us by > telephone and return or destroy the original message to assure that it is > not read, copied, or distributed by others. > > > ------------------------------ > *From:* Abhisheyk Deb <abhisheykdeb(a)gmail.com> > *Sent:* Wednesday, July 17, 2019 1:56 PM > *To:* General discussion list for the 389 Directory server project. > *Subject:* [389-users] LDAP Groups in sudoers file. > > Hi, > > We have a ldap group called *ldapadmin *defined on our LDAP servers > running 389 Directory Server. > > On the LDAP Client side. We have the following line added in > */etc/sudoers* > *%ldapadmin ALL=(ALL:ALL) ALL* > > We are able to login as a LDAP user which is part of the *ldapadmin *group > and are able to get sudo privileges for that user by calling sudo before a > command. > > Now these LDAP Client machines also have a local admin user which has been > added to their local /etc/sudoers file. > > If we get our LDAP Servers down and try to do sudo when we are logged in > as the local admin user, we are seeing a delay before sudo command can > finish. > > When we remove the line *%ldapadmin ALL=(ALL:ALL) ALL *from > */etc/sudoers*, the slowdowns do not happen anymore when we try to do > sudo as the local admin user. > > That means every time we are trying to do sudo, it is reading the sudoers > file and on parsing the file when it comes across the line *%ldapadmin ALL=(ALL:ALL) > ALL*, it is not able to find this group since it is not a local group, > but a group present on a LDAP Server which is currently unavailable. > > My question is why sudo command is trying to do a lookup for *ldapadmin * > group when it is ran by the local admin user? Is there any way to bypass > this check, because our LDAPClients have the need to have a local admin > user. Any help would be appreciated. > > Thank you > Abhishek Deb > > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)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… >

1 0

Re: Recommended SLAPD cache sizes
by Mark Reynolds 16 Jul '19

16 Jul '19

Hi Paul, On 7/16/19 9:16 AM, Paul Whitney wrote: > Is there some formula or recommendation on determining what would be > the optimal cache settings for a directory server (389-ds of course) > with following sizes? I looked at the DS 10 Admin Guide online and am > getting conflicting information. But the manual shows a table and > suggests that the max size for the cn=config dbcache is 512MB. There is no limit on the cache size value besides what you are limited to by a unsigned long integer. Do you have a link to where it says 512 MB is a maximum? > But I tried with 5GB and it appears to work fine with it, although > over time start to see negative values (prob not enough cache) and > roevicts while running the dbmon.sh script. > > __db files = ~6GB > groupRoot = 1.5GB > userRoot = 20GB > > What values would yield best performance for: > > cn=config dbcache? currently set to 5GB but are still seeing lots of > roevicts. As much > > userRoot entry cache? currently set to 21GB (hit ratio so far at 95%) > > groupRoot entry cache? currently set to 2GB (hit ration so far at 96%) > > Virtual machine configured with 8CPU, 128GB RAM. Load is in the low > 20's with occasional spikes to high 20's. If you have 128 GB available to you then I would continue to increase the cache sizes until you get to 99% hit ratio for the two entry caches, and the db cache. Also make sure the DN and NDN caches also have a 99% cache hit ratio: https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/h… https://www.port389.org/docs/389ds/design/normalized-dn-cache.html I would also look into running the DB on a RAM disk since you have the resources to do so: https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/h… HTH, Mark > > Paul M. Whitney, RHCSA, CISSP > Chesapeake IT Consulting, Inc. > 2680 Tobacco Rd > Chesapeake Beach, MD 20732 > > Work: 443-492-2872 > Cell: 410.493.9448 > Email: paul.whitney(a)chesapeake-it.com > <mailto:paul.whitney@chesapeake-it.com> > *CONFIDENTIALITY NOTICE* > The information contained in this facsimile or electronic message is > confidential information intended for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, or an employee or agent responsible for delivering this > facsimile message to the intended recipient, you are hereby notified > that any dissemination, or copying of this communication is strictly > prohibited. If this message contains non-public personal information > about any consumer or customer of the sender or intended recipient, > you are further prohibited under penalty of law from using or > disclosing the information to any third party by provisions of the > federal Gramm-Leach-Bliley Act. If you have received this facsimile or > electronic message in error, please immediately notify us by telephone > and return or destroy the original message to assure that it is not > read, copied, or distributed by others. > > > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)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… -- 389 Directory Server Development Team

2 1

Re: 389-DS Downgrade Breaks dirsrv.target
by William Brown 16 Jul '19

16 Jul '19

> On 12 Jul 2019, at 00:04, Paul Whitney <paul.whitney(a)chesapeake-it.com> wrote: > > When attempting to downgrade 389-ds-base from version 1.3.8.4-23 to version 1.3.7.5-18 I discovered that the systemctl cannot start dirsrv.target. I am able to start the individual instances however. Any suggestions on how to resolve this? > > I am only downgrading: > • 389-ds-base > • 389-ds-base-libs > • 389-ds-base devel > • 389-ds-base-snmp > Am I missing another package that should be downgraded? That should be enough I think? Can you detail what and how it's "breaking" and what evidence you have about this? That would help us to identify what's going wrong here. Thanks, > > Thanks in advance, > > Paul M. Whitney, RHCSA, CISSP > Chesapeake IT Consulting, Inc. > 2680 Tobacco Rd > Chesapeake Beach, MD 20732 > > Work: 443-492-2872 > Cell: 410.493.9448 > Email: paul.whitney(a)chesapeake-it.com > CONFIDENTIALITY NOTICE > The information contained in this facsimile or electronic message is confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this facsimile message to the intended recipient, you are hereby notified that any dissemination, or copying of this communication is strictly prohibited. If this message contains non-public personal information about any consumer or customer of the sender or intended recipient, you are further prohibited under penalty of law from using or disclosing the information to any third party by provisions of the federal Gramm-Leach-Bliley Act. If you have received this facsimile or electronic message in error, please immediately notify us by telephone and return or destroy the original message to assure that it is not read, copied, or distributed by others. > > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)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… — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs

2 1

Recommended SLAPD cache sizes
by Paul Whitney 16 Jul '19

16 Jul '19

Is there some formula or recommendation on determining what would be the optimal cache settings for a directory server (389-ds of course) with following sizes? I looked at the DS 10 Admin Guide online and am getting conflicting information. But the manual shows a table and suggests that the max size for the cn=config dbcache is 512MB. But I tried with 5GB and it appears to work fine with it, although over time start to see negative values (prob not enough cache) and roevicts while running the dbmon.sh script. __db files = ~6GB groupRoot = 1.5GB userRoot = 20GB What values would yield best performance for: cn=config dbcache? currently set to 5GB but are still seeing lots of roevicts. As much userRoot entry cache? currently set to 21GB (hit ratio so far at 95%) groupRoot entry cache? currently set to 2GB (hit ration so far at 96%) Virtual machine configured with 8CPU, 128GB RAM. Load is in the low 20's with occasional spikes to high 20's. Paul M. Whitney, RHCSA, CISSP Chesapeake IT Consulting, Inc. 2680 Tobacco Rd Chesapeake Beach, MD 20732 Work: 443-492-2872 Cell: 410.493.9448 Email: paul.whitney(a)chesapeake-it.com<mailto:paul.whitney@chesapeake-it.com> CONFIDENTIALITY NOTICE The information contained in this facsimile or electronic message is confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this facsimile message to the intended recipient, you are hereby notified that any dissemination, or copying of this communication is strictly prohibited. If this message contains non-public personal information about any consumer or customer of the sender or intended recipient, you are further prohibited under penalty of law from using or disclosing the information to any third party by provisions of the federal Gramm-Leach-Bliley Act. If you have received this facsimile or electronic message in error, please immediately notify us by telephone and return or destroy the original message to assure that it is not read, copied, or distributed by others.

1 0

Anonymous bind and automount
by Andry Michaelidou 12 Jul '19

12 Jul '19

Hello all, We are trying to disabe anonymous binds to our 389-DS ldap servers, but it seems like my automount setting are not working. Is it possible to have automount working with anonymous bind not enabled? Thank you in advance, Andry Michaelidou University of Cyprus

2 1

389-DS Downgrade Breaks dirsrv.target
by Paul Whitney 11 Jul '19

11 Jul '19

When attempting to downgrade 389-ds-base from version 1.3.8.4-23 to version 1.3.7.5-18 I discovered that the systemctl cannot start dirsrv.target. I am able to start the individual instances however. Any suggestions on how to resolve this? I am only downgrading: * 389-ds-base * 389-ds-base-libs * 389-ds-base devel * 389-ds-base-snmp Am I missing another package that should be downgraded? Thanks in advance, Paul M. Whitney, RHCSA, CISSP Chesapeake IT Consulting, Inc. 2680 Tobacco Rd Chesapeake Beach, MD 20732 Work: 443-492-2872 Cell: 410.493.9448 Email: paul.whitney(a)chesapeake-it.com<mailto:paul.whitney@chesapeake-it.com> CONFIDENTIALITY NOTICE The information contained in this facsimile or electronic message is confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this facsimile message to the intended recipient, you are hereby notified that any dissemination, or copying of this communication is strictly prohibited. If this message contains non-public personal information about any consumer or customer of the sender or intended recipient, you are further prohibited under penalty of law from using or disclosing the information to any third party by provisions of the federal Gramm-Leach-Bliley Act. If you have received this facsimile or electronic message in error, please immediately notify us by telephone and return or destroy the original message to assure that it is not read, copied, or distributed by others.

1 0

Startup issue
by Harlan.Whitley＠us.fujitsu.com 10 Jul '19

10 Jul '19

When attempting to start 389 I get the following error. [root@ openldap]# systemctl status dirsrv(a)slapd.service ● dirsrv(a)slapd.service - 389 Directory Server slapd. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Active: failed (Result: resources) Jul 10 09:19:21local systemd[1]: Unit dirsrv(a)slapd.service entered failed state. Jul 10 09:19:21 local systemd[1]: dirsrv(a)slapd.service failed. Jul 10 09:33:32 local systemd[1]: Failed to load environment files: No such file or directory Jul 10 09:33:32 local systemd[1]: dirsrv(a)slapd.service failed to run 'start-pre' task: No such file or directory Jul 10 09:33:32 local systemd[1]: Failed to start 389 Directory Server slapd.. Jul 10 09:33:32 local systemd[1]: dirsrv(a)slapd.service failed. Jul 10 09:39:47 local systemd[1]: Failed to load environment files: No such file or directory Jul 10 09:39:47 local systemd[1]: dirsrv(a)slapd.service failed to run 'start-pre' task: No such file or directory Jul 10 09:39:47 loccal systemd[1]: Failed to start 389 Directory Server slapd.. Jul 10 09:39:47 local systemd[1]: dirsrv(a)slapd.service failed. Any ideas on the reason? Thanks, Harlan Whitley Unix System Administration

3 2

Imported existing user hashes
by Matt Shields 10 Jul '19

10 Jul '19

We're looking at migrating our Solarwinds Serv-U users into 389-ds. We can export the user's password hashes which use the following format. - user password = mytestpass - pick two alpha salt (i.e. Bq) - new user password = prepend the salt to the user's password (i.e. Bqmytestpass) - MD5 new user password and convert to upper case = 1C3D9DB22AC6CC3A216E1FA566A642B1 - prepend salt to the MD5 = Bq1C3D9DB22AC6CC3A216E1FA566A642B1 https://support.solarwinds.com/SuccessCenter/s/article/Manually-generate-en… How can I import and use the existing hashes. I really do not want to ask every single user for a new password, this would take forever. I came across this article (https://www.redpill-linpro.com/techblog/2016/08/16/ldap-password-hash.html) which seemed like I could convert the above hash to {MD5}$1$Bq$1C3D9DB22AC6CC3A216E1FA566A642B1 but that didn't seem to work. Any ideas?

2 1

Announcing 389 Directory Server 1.4.1.5
by Mark Reynolds 08 Jul '19

08 Jul '19

389 Directory Server 1.4.1.5 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.1.5 Fedora packages are available on Fedora 30 and rawhide. https://koji.fedoraproject.org/koji/taskinfo?taskID=36139436 <https://koji.fedoraproject.org/koji/taskinfo?taskID=36139436> - Rawhide https://koji.fedoraproject.org/koji/taskinfo?taskID=36137973 <https://koji.fedoraproject.org/koji/taskinfo?taskID=36137973> - Fedora 30 Bodhi https://bodhi.fedoraproject.org/updates/FEDORA-2019-cc5eaae53e <https://bodhi.fedoraproject.org/updates/FEDORA-2019-cc5eaae53e> The new packages and versions are: * 389-ds-base-1.4.1.5-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.4.1.5.tar.bz2> Highlights in 1.4.1.5 * Bug fixes Installation and Upgrade See Download <https://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install the server use *dnf install 389-ds-base* To install the Cockpit UI plugin use *dnf install cockpit-389-ds* After rpm install completes, run *dscreate interactive* For upgrades, simply install the package. There are no further steps required. There are no upgrade steps besides installing the new rpms See Install_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html> for more information about the initial installation and setup See Source <https://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access. New UI Progress (Cockpit plugin) The new UI is broken up into a series of configuration tabs. Here is a table showing the current progress Configuration Tab Finished Written in ReactJS Server Tab Yes No Security Tab No (coming soon) No Database Tab Yes Yes Replication Tab Yes No Schema Tab Yes No Plugin Tab Yes Yes Monitor Tab Yes Yes Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.o… If you find a bug, or would like to see a new feature, file it in our Pagure project: https://pagure.io/389-ds-base * Bump version to 1.4.1.5 * Issue 50431 - Fix regression from coverity fix (crash in memberOf plugin) * Issue 49239 - Add a new CI test case * Issue 49997 - Add a new CI test case * Issue 50177 - Add a new CI test case, also added fixes in lib389 * Issue 49761 - Fix CI test suite issues * Issue 50474 - Unify result codes for add and modify of repl5 config * Issue 50472 - memory leak with encryption * Issue 50462 - Fix Root DN access control plugin CI tests * Issue 50462 - Fix CI tests * Issue 50217 - Implement dsconf security section * Issue 48851 - Add more test cases to the match test suite. * Issue 50378 - ACI’s with IPv4 and IPv6 bind rules do not work for IPv6 clients * Issue 50439 - fix waitpid issue when pid does not exist * Issue 50454 - Fix Cockpit UI branding * Issue 48851 - investigate and port TET matching rules filter tests(index) * Issue 49232 - Truncate the message when buffer capacity is exceeded -- 389 Directory Server Development Team

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users July 2019