August 2021 - 389-users - Fedora Mailing-Lists

by DUVERT Vincent

Hello, I have a question regarding the licensing of developed 389-ds plugins. The FAQ (https://directory.fedoraproject.org/docs/389ds/FAQ/licensing.html#directo...) indicates that the Directory Server core code is licensed under a GPL + Exception license that allows non-GPL 389-ds plugins to link to 389-ds and to use specific header files. However, the LICENSE file in the current 389-ds-base source does not contain this exception. It was apparently removed by the following commit, when the license was changed to GPLv3+: https://pagure.io/389-ds-base/c/88cae401aee39a19ac6b07c3c36ee8daa07192e7 Does that means that the license exception does not apply to the current version of 389-ds? Regards, Vincent Duvert

3 weeks, 2 days

2
2
0 / 0

Lock table is out of available lock entries

by Kees Bakker

Hi, When my dirsrv was trying to compact the databases I was getting this error [07/Aug/2021:23:59:02.715984489 +0200] - NOTICE - bdb_compact - Compacting databases ... [07/Aug/2021:23:59:02.765932397 +0200] - NOTICE - bdb_compact - Compacting DB start: userRoot [07/Aug/2021:23:59:03.518175414 +0200] - NOTICE - bdb_compact - compactdb: compact userRoot - 417 pages freed [07/Aug/2021:23:59:03.576427786 +0200] - NOTICE - bdb_compact - Compacting DB start: ipaca [07/Aug/2021:23:59:03.659941533 +0200] - NOTICE - bdb_compact - compactdb: compact ipaca - 419 pages freed [07/Aug/2021:23:59:03.718445310 +0200] - NOTICE - bdb_compact - Compacting DB start: changelog [08/Aug/2021:00:00:40.807571334 +0200] - NOTICE - NSMMReplicationPlugin - changelog program - cl5CompactDBs - compacting replication changelogs... [08/Aug/2021:00:00:54.309357211 +0200] - ERR - libdb - BDB2055 Lock table is out of available lock entries [08/Aug/2021:00:00:54.726504736 +0200] - ERR - bdb_compact - compactdb: failed to compact changelog; db error - 12 Cannot allocate memory [08/Aug/2021:00:00:54.801571421 +0200] - ERR - libdb - BDB2055 Lock table is out of available lock entries [08/Aug/2021:00:00:54.876618702 +0200] - ERR - NSMMReplicationPlugin - changelog program - cl5CompactDBs - Failed to compact a797bb0b-be1d11eb-88c0b677-613aa2ad; db error - 12 Cannot allocate memory [08/Aug/2021:00:00:57.253006449 +0200] - NOTICE - bdb_compact - Compacting databases finished. There are about 402k entries in cn=changelog. I have a few questions 1) is it normal to have so many entries in cn=changelog? On another replica I have almost 3M entries Isn't this cleaned up? 2) the number of locks is 50000 (there are two config items). Should I increase that number? If so, increase to what? 3) is there maybe something else going on, causing the exhaustion of the locks? -- Kees Bakker

1 year, 7 months

4
21
0 / 0

WARN - content-sync-plugin

by Orion Poplawski

I've started seeing these messages periodically after some update a while back. Anything to be concerned about or should I just ignore them? [29/Aug/2021:09:41:35.471107696 -0700] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "cn=repl keep alive 24,dc=nwra,dc=com" (op=0x7f32d57f8c00 idx_pl=0) => op not changed in PL [29/Aug/2021:13:07:11.134986267 -0700] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "cn=repl keep alive 24,dc=nwra,dc=com" (op=0x7f32d5701400 idx_pl=0) => op not changed in PL [29/Aug/2021:13:56:35.194828743 -0700] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "cn=repl keep alive 24,dc=nwra,dc=com" (op=0x7f32d56fe600 idx_pl=0) => op not changed in PL [29/Aug/2021:15:37:11.119675538 -0700] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "dc=nwra,dc=com" (op=0x7f32d563cc00 idx_pl=0) => op not changed in PL [29/Aug/2021:18:13:13.204063186 -0700] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "cn=repl keep alive 24,dc=nwra,dc=com" (op=0x7f32bcafbe00 idx_pl=0) => op not changed in PL Thanks. -- Orion Poplawski IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

1 year, 9 months

2
2
0 / 0

What is the preferred way to make config changes

by Kees Bakker

Hi, In one of the GitHub issues [1] it was mentioned that > People "should" be using the python CLI & UI to make these config changes What CLI and/or UI is this? For example, what is the preferred way to change nsslapd-db-deadlock-policy? [1] https://github.com/389ds/389-ds-base/issues/4869 -- Kees Bakker

1 year, 9 months

3
3
0 / 0

Several "DB retried operation targets" messages per day

by Kees Bakker

Hi, (( This was also reported as an issue at github [1], but there isn't much activity there. )) Each day there several messages with "WARN - content-sync-plugin - sync_update_persist_betxn_pre_op ...". It is unclear why they show up. Briefly about the setup. This is in a IPA deployment. We have three masters/replicas in a triangular topology, A-B, B-C, C-A. The systems are called: rotte, linge and iparep4. rotte is CentOS 7, with 389-ds-base-1.3.9.1-13.el7_7.x86_64 linge and iparep4 are CentOS 8 Stream, with 389-ds-base-1.4.3.23-2.module_el8.5.0+835+5d54734c.x86_64 The messages seem to have a relation to DNS updates triggered by a DHCP server. These updates come in on rotte, the CentOS7 system. Next, they get replicated to the two CentOS systems. At least a few times per day, on the two CentOS system I see the following. Even though they are just(?) warnings, I still don't like it. aug 03 15:47:20 iparep4.example.com ns-slapd[485]: [03/Aug/2021:15:47:20.474879344 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "dc=example,dc=com" (op=0x7efdcfc59600 idx_pl=0) => op not changed in PL aug 03 20:31:12 iparep4.example.com ns-slapd[485]: [03/Aug/2021:20:31:12.981645921 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=600749,cn=changelog" (op=0x7efdf8310200 idx_pl=1) => op not changed in PL aug 03 20:31:44 iparep4.example.com ns-slapd[485]: [03/Aug/2021:20:31:44.287299445 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=600773,cn=changelog" (op=0x7efe0a763000 idx_pl=1) => op not changed in PL aug 03 20:36:40 iparep4.example.com ns-slapd[485]: [03/Aug/2021:20:36:40.890527828 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=600785,cn=changelog" (op=0x7efe14014400 idx_pl=1) => op not changed in PL aug 04 00:09:22 iparep4.example.com ns-slapd[485]: [04/Aug/2021:00:09:22.697622835 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "idnsName=rly8a-lyon,idnsname=example.com.,cn=dns,dc=example,dc=com" (op=0x7efe14014200 idx_pl=0) => op not changed in PL aug 04 00:10:24 iparep4.example.com ns-slapd[485]: [04/Aug/2021:00:10:24.370023104 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=601866,cn=changelog" (op=0x7efde0304400 idx_pl=1) => op not changed in PL aug 04 00:27:39 iparep4.example.com ns-slapd[485]: [04/Aug/2021:00:27:39.369751746 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=601970,cn=changelog" (op=0x7efe0a763000 idx_pl=1) => op not changed in PL aug 04 00:28:58 iparep4.example.com ns-slapd[485]: [04/Aug/2021:00:28:58.163832176 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=602032,cn=changelog" (op=0x7efdfbb8d200 idx_pl=1) => op not changed in PL aug 04 03:02:39 iparep4.example.com ns-slapd[485]: [04/Aug/2021:03:02:39.646642606 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "dc=example,dc=com" (op=0x7efe0c265000 idx_pl=0) => op not changed in PL aug 04 05:38:21 iparep4.example.com ns-slapd[485]: [04/Aug/2021:05:38:21.334053200 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "idnsName=ghprobe35792,idnsname=example.com.,cn=dns,dc=example,dc=com" (op=0x7efe9c6d8a00 idx_pl=0) => op not changed in PL Aug 03 11:38:23 linge.example.com ns-slapd[282944]: [03/Aug/2021:11:38:23.090286378 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=359984,cn=changelog" (op=0x7fd390ec3a00 idx_pl=1) => op not changed in PL Aug 03 14:36:39 linge.example.com ns-slapd[282944]: [03/Aug/2021:14:36:39.798593691 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=360832,cn=changelog" (op=0x7fd36532ea00 idx_pl=1) => op not changed in PL Aug 03 15:00:45 linge.example.com ns-slapd[282944]: [03/Aug/2021:15:00:45.104018419 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "dc=example,dc=com" (op=0x7fd39c221800 idx_pl=0) => op not changed in PL Aug 03 17:09:45 linge.example.com ns-slapd[282944]: [03/Aug/2021:17:09:45.881468406 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=361533,cn=changelog" (op=0x7fd35c1f0c00 idx_pl=1) => op not changed in PL Aug 03 17:42:13 linge.example.com ns-slapd[282944]: [03/Aug/2021:17:42:13.223390704 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=361773,cn=changelog" (op=0x7fd39d210800 idx_pl=1) => op not changed in PL Aug 03 19:09:44 linge.example.com ns-slapd[282944]: [03/Aug/2021:19:09:44.298497387 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=362107,cn=changelog" (op=0x7fd390e15200 idx_pl=1) => op not changed in PL Aug 04 01:42:13 linge.example.com ns-slapd[282944]: [04/Aug/2021:01:42:13.581042356 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=364294,cn=changelog" (op=0x7fd375366000 idx_pl=1) => op not changed in PL Aug 04 03:10:25 linge.example.com ns-slapd[282944]: [04/Aug/2021:03:10:25.655556357 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=364690,cn=changelog" (op=0x7fd353072000 idx_pl=1) => op not changed in PL Aug 04 07:08:40 linge.example.com ns-slapd[282944]: [04/Aug/2021:07:08:40.618202412 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=365854,cn=changelog" (op=0x7fd3a062ee00 idx_pl=1) => op not changed in PL Aug 04 10:25:19 linge.example.com ns-slapd[282944]: [04/Aug/2021:10:25:19.410683924 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "idnsname=example.com.,cn=dns,dc=example,dc=com" (op=0x7fd3cc00a200 idx_pl=0) => op not changed in PL [1] https://github.com/389ds/389-ds-base/issues/4842 -- Kees

1 year, 9 months

4
9
0 / 0

ATTENTION - 389-devel mass unsubscribe complete, what's next...

by Mark Reynolds

The 389-devel mailing list purge is now complete. For those who want to remain on the 389 development mailing list you will have to resubscribe. For those who are not familiar with that list, it is just for discussing development and coding changes in the Directory Server. The 389-users list is still where general questions should be posted, but if you're interested in how we are developing the server then you're more than welcome to join this list: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproje... Thanks On 8/19/21 2:16 PM, Mark Reynolds wrote: > > Hello everyone, > > A few months ago there was a SPAM attack on our list and 1800 people > were incorrectly subscribed to this list. I think there were only 300 > people on it prior to this happening. While actions have been taken > to prevent this from happening again, it doesn't help our current > situation. Next week I will be unsubscribing /everyone/. > > Those who are interested in remaining on this list will need to > subscribe again after this mass unsubscribe event. I will send one > more email announcement prior to unsubscribing everyone. > > Sorry for those who never wanted to be on this list, and sorry to > those who want to remain on it. > > -- > Directory Server Development Team -- Directory Server Development Team

1 year, 9 months

1
0
0 / 0

Announcing 389 Directory Server 2.0.8

by Mark Reynolds

389 Directory Server 2.0.8 The 389 Directory Server team is proud to announce 389-ds-base version 2.0.8 Fedora packages are available on Fedora 34 Fedora 34: https://koji.fedoraproject.org/koji/taskinfo?taskID=74413473 <https://koji.fedoraproject.org/koji/taskinfo?taskID=74413473> - Koji https://bodhi.fedoraproject.org/updates/FEDORA-2021-da6419cbea <https://bodhi.fedoraproject.org/updates/FEDORA-2021-da6419cbea> - Bodhi The new packages and versions are: * 389-ds-base-2.0.8-1 Source tarballs are available for download at Download 389-ds-base Source <https://github.com/389ds/389-ds-base/archive/389-ds-base-2.0.8.tar.gz> Highlights in 2.0.8 * 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. 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... <https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject...> If you find a bug, or would like to see a new feature, file it in our GitHub project: https://github.com/389ds/389-ds-base <https://github.com/389ds/389-ds-base> * Bump version to 2.0.8 * Issue 4877 - RFE - EntryUUID to validate UUIDs on fixup (#4878) * Issue 4872 - BUG - entryuuid enabled by default causes replication issues (#4876) * Issue 4851 - Typos in “dsconf pwpolicy set –help” (#4867) * Issue 4763 - Attribute Uniqueness Plugin uses wrong subtree on ModRDN (#4871) * Issue 4736 - lib389 - fix regression in certutil error checking * Issue 4861 - Improve instructions in custom.conf for memory leak detection * Issue 4859 - Don’t version libns-dshttpd * Issue 4169 - Migrate Replication & Schema tabs to PF4 * Issue 4623 - RFE - Monitor the current DB locks ( nsslapd-db-current-locks ) * Issue 4736 - CLI - Errors from certutil are not propagated * Issue 4460 - Fix isLocal and TLS paths discovery (#4850) * Issue 4848 - Force to require nss version greater or equal as the version available at the build time * Issue 4696 - Password hash upgrade on bind (#4840) -- Directory Server Development Team

1 year, 9 months

1
0
0 / 0

Re: How to replicate password lockout attributes from a consumer or hub to a master(s)

by Mark Reynolds

On 8/16/21 12:01 PM, Michael Starling wrote: > > > ------------------------------------------------------------------------ > *From:* Michael Starling <mlstarling31(a)hotmail.com> > *Sent:* Monday, August 16, 2021 10:54 AM > *To:* Pierre Rogier <progier(a)redhat.com>; General discussion list for > the 389 Directory server project. <389-users(a)lists.fedoraproject.org> > *Subject:* [389-users] Re: How to replicate password lockout > attributes from a consumer or hub to a master(s) > > > ------------------------------------------------------------------------ > *From:* Pierre Rogier <progier(a)redhat.com> > *Sent:* Monday, August 16, 2021 6:33 AM > *To:* General discussion list for the 389 Directory server project. > <389-users(a)lists.fedoraproject.org> > *Cc:* Michael Starling <mlstarling31(a)hotmail.com> > *Subject:* Re: [389-users] Re: How to replicate password lockout > attributes from a consumer or hub to a master(s) > > > On Fri, Aug 13, 2021 at 9:42 PM Mark Reynolds <mreynolds(a)redhat.com > <mailto:mreynolds@redhat.com>> wrote: > > > On 8/13/21 2:40 PM, Michael Starling wrote: >> >> >> ------------------------------------------------------------------------ >> *From:* Michael Starling <mlstarling31(a)hotmail.com> >> <mailto:mlstarling31@hotmail.com> >> *Sent:* Friday, August 13, 2021 10:41 AM >> *To:* Mark Reynolds <mreynolds(a)redhat.com> >> <mailto:mreynolds@redhat.com>; General discussion list for the >> 389 Directory server project. <389-users(a)lists.fedoraproject.org> >> <mailto:389-users@lists.fedoraproject.org> >> *Subject:* Re: [389-users] How to replicate password lockout >> attributes from a consumer or hub to a master(s) >> >> >> ------------------------------------------------------------------------ >> *From:* Michael Starling <mlstarling31(a)hotmail.com> >> <mailto:mlstarling31@hotmail.com> >> *Sent:* Thursday, August 12, 2021 3:29 PM >> *To:* Mark Reynolds <mreynolds(a)redhat.com> >> <mailto:mreynolds@redhat.com>; General discussion list for the >> 389 Directory server project. <389-users(a)lists.fedoraproject.org> >> <mailto:389-users@lists.fedoraproject.org> >> *Subject:* Re: [389-users] How to replicate password lockout >> attributes from a consumer or hub to a master(s) >> >> >> ------------------------------------------------------------------------ >> *From:* Mark Reynolds <mreynolds(a)redhat.com> >> <mailto:mreynolds@redhat.com> >> *Sent:* Thursday, August 12, 2021 3:16 PM >> *To:* Michael Starling <mlstarling31(a)hotmail.com> >> <mailto:mlstarling31@hotmail.com>; General discussion list for >> the 389 Directory server project. >> <389-users(a)lists.fedoraproject.org> >> <mailto:389-users@lists.fedoraproject.org> >> *Subject:* Re: [389-users] How to replicate password lockout >> attributes from a consumer or hub to a master(s) >> >> >> On 8/12/21 2:33 PM, Michael Starling wrote: >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Mark Reynolds <mreynolds(a)redhat.com> >>> <mailto:mreynolds@redhat.com> >>> *Sent:* Thursday, August 12, 2021 11:48 AM >>> *To:* General discussion list for the 389 Directory server >>> project. <389-users(a)lists.fedoraproject.org> >>> <mailto:389-users@lists.fedoraproject.org>; Michael Starling >>> <mlstarling31(a)hotmail.com> <mailto:mlstarling31@hotmail.com> >>> *Subject:* Re: [389-users] How to replicate password lockout >>> attributes from a consumer or hub to a master(s) >>> >>> >>> On 8/12/21 10:53 AM, Michael Starling wrote: >>>> Hello. >>>> >>>> I've taken over a large 389-ds environment running on Oracle >>>> Linux 8 and the first task I need to complete is to enable >>>> password lockouts. >>>> >>>> >>>> >>>> I was able to enable password lockouts successfully however it >>>> only works if the client is pointed directly to a master. The >>>> account locks out and the attributes are propagated down to the >>>> hubs and consumers. >>>> >>>> If the client is pointed to a read-only hub or consumer then >>>> the account does not lockout and the password attributes do not >>>> propagate back to the masters. >>>> >>>> *passwordIsGlobalPolicy*: on is set on all masters, hubs and >>>> consumers >>>> >>>> Password policy attributes I expect to replicate: >>>> >>>> *passwordRetryCount* >>>> *accountUnlockTime* >>>> *retryCountResetTime* >>>> >>>> I've tried following the chaining guide below which I think is >>>> what I need to do to get this work as expected, however I've >>>> hit a snag. >>>> >>>> https://directory.fedoraproject.org/docs/389ds/howto/howto-chainonupdate.... >>>> <https://directory.fedoraproject.org/docs/389ds/howto/howto-chainonupdate....> >>>> 389 Directory Server - Howto:ChainOnUpdate >>>> <https://directory.fedoraproject.org/docs/389ds/howto/howto-chainonupdate....> >>>> Introduction. The usual deployment for a large replication >>>> topology will have the client applications reading from hubs or >>>> dedicated consumers in order to spread out the load and >>>> off-load search request processing from the masters. >>>> directory.fedoraproject.org <http://directory.fedoraproject.org> >>>> >>>> The document states the backend must be added to the hub or >>>> consumer, however when I try and add the following LDIF to the >>>> hub I get the "unwilling to perform" error. >>>> >>>> This makes sense because the hub is read-only so I'm confused >>>> as how I can update the config on a read-only hub or consumer? >>>> > Hi Michael, > To complete Mark's answer and try to solve your confusion: > hub and consumer are read-only replicas (i.e backends) > cn=config is another backend that is still writable. > So you should not be able to modify the entries in the replicated suffix ( > and should instead get referrals towards the master(s)) but you > should still be able to modify the config. > Regards, > Pierre > > > Hi Pierre. > > Thanks for confirming what I'm seeing. > > Any idea how to set multiple values in the nsfarmserverurl**attribute*?* > >>>> dn: cn=chainlab,cn=chaining database,cn=plugins,cn=config >>>> objectclass: top >>>> objectclass: extensibleObject >>>> objectclass: nsBackendInstance >>>> cn: chainlab >>>> nsslapd-suffix: dc=domain,dc=com >>>> nsfarmserverurl: ldap://dsa1.domain.com:389 >>>> ldap://dsa2.domain.com:389 ldap://dsa3.domain.com:389 >>>> nsmultiplexorbinddn: uid=repluser,cn=config >>>> nsmultiplexorcredentials: mypassword >>>> nsCheckLocalACI: on >>>> >>>> adding new entry "cn=chainlab,cn=chaining >>>> database,cn=plugins,cn=config" >>>> ldap_add: Server is unwilling to perform (53) >>> >>> This is the doc you want to follow to get this working. But it >>> is complicated... >>> >>> >>> In this case I'm not sure why the error 53 is being returned. >>> There is something about that entry it does not like. So please >>> check the access and errors log from the time of this failure >>> (see /var/log/dirsrv/slapd-YOUR_INSTANCE/). There is usually >>> more info logged when an error 53 happens. >>> >>> >>> Also what version of 389-ds-base are you running? >>> >>> >>> Thanks, >>> Mark >>> >>>> >>>> Hub or Consumer >>>> >>>> Step 1 (Hub and Consumer): the chaining backend must be created >>>> on the hub and consumer: >>>> >>>> |dn: cn=chainbe1,cn=chaining database,cn=plugins,cn=config >>>> objectclass: top objectclass: extensibleObject >>>> objectclass: nsBackendInstance cn: chainbe1 >>>> nsslapd-suffix: <suffix to replicate> >>>> nsfarmserverurl: ldap://supplier1:port supplier2:port ... supplierN:port/ # also, ldaps can be used instead >>>> # of ldap for secure connections - >>>> # requires the secure port >>>> nsmultiplexorbinddn: cn=Replication Manager,cn=config # or whatever the replica bind DN is on the supplier >>>> nsmultiplexorcredentials: password nsCheckLocalACI: on | >>>> >>>> Any help would be greatly appreciated. >>>> >>>> Thanks >>>> >>>> _______________________________________________ >>>> 389-users mailing list --389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> >>>> To unsubscribe send an email to389-users-leave(a)lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> >>>> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://docs.fedoraproject.org/en-US/project/code-of-conduct/> >>>> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines> >>>> List Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fe... <https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...> >>>> Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure <https://pagure.io/fedora-infrastructure> >>> -- >>> Directory Server Development Team >>> >>> Thanks for getting me the right track Mark. Looks like the >>> "nsFarmServerURL" is not correct. >>> >>> Versions: >>> >>> 389-ds-base-libs-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64 >>> 389-ds-base-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64 >>> >>> I thought I was maybe hitting the bug described below so I added >>> a trailing "/" but the issue persists. >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1363970 >>> <https://bugzilla.redhat.com/show_bug.cgi?id=1363970> >>> >>> nsfarmserverurl: ldap://dsa1.domain.com:389 >>> ldap://dsa2.domain.com:389 ldap://dsa3.domain.com:389*/* >>> >>> This is what I see in the logs on the hub when trying to add the >>> LDIF. >>> >>> The idea is for the hub to send these password attributes back >>> to all masters. >>> >>> These are the masters in the environment. >>> ldap://dsa1.domain.com:389 >>> ldap://dsa2.domain.com:389 >>> ldap://dsa3.domain.com:389 >>> [12/Aug/2021:14:12:38.228746875 -0400] - ERR - chaining database >>> - cb_instance_config_initialize -*Error with config attribute >>> nsfarmserverurl : not a valid LDAP URL* >>> [12/Aug/2021:14:12:38.230107318 -0400] - ERR - chaining database >>> - cb_instance_add_config_check_callback - Can't instantiate >>> chaining backend instance chainlab. >>> [12/Aug/2021:14:13:11.436433137 -0400] - ERR - chaining database >>> - cb_instance_config_initialize - Error with config attribute >>> nsfarmserverurl : not a valid LDAP URL >>> [12/Aug/2021:14:13:11.437510161 -0400] - ERR - chaining database >>> - cb_instance_add_config_check_callback - Can't instantiate >>> chaining backend instance chainlab. >>> [12/Aug/2021:14:15:15.652343542 -0400] - ERR - chaining database >>> - cb_instance_config_initialize - Error with config attribute >>> nsfarmserverurl : not a valid LDAP URL >>> [12/Aug/2021:14:15:15.653524818 -0400] - ERR - chaining database >>> - cb_instance_add_config_check_callback - Can't instantiate >>> chaining backend instance chainlab. >>> [12/Aug/2021:14:20:12.212414022 -0400] - ERR - chaining database >>> - cb_instance_config_initialize - Error with config attribute >>> nsfarmserverurl : not a valid LDAP URL >>> [12/Aug/2021:14:20:12.213556900 -0400] - ERR - chaining database >>> - cb_instance_add_config_check_callback - Can't instantiate >>> chaining backend instance chainlab >>> >>> >> Ok, I think its not liking the multiple values in the attribute, >> even though the document says you have multiple urls. I think >> you need to add the config like this: >> >> >> nsfarmserverurl: ldap://dsa1.domain.com:389 >> >> nsfarmserverurl: ldap://dsa2.domain.com:389 >> >> nsfarmserverurl: ldap://dsa3.domain.com:389 >> >> >> Give it a try? >> >> >> HTH, >> >> Mark >> >> >> -- >> Directory Server Development Team >> Looks like it only added the first entry. Do I need to add an entry for each MAster? >> dn: cn=chainlab,cn=chaining database,cn=plugins,cn=config >> objectClass: top >> objectClass: extensibleObject >> objectClass: nsBackendInstance >> cn: chainlab >> nsslapd-suffix: dc=domain,dc=com >> *nsfarmserverurl: ldap://dsa1.domain.com:389* >> nsmultiplexorbinddn: uid=replicator,cn=config >> nsmultiplexorcredentials: >> {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVGRERBNEJDUm1aRFUwT1dOak5DMDVPVFl5TXpJMg0KWlMwNE16ZzFNVFl3TXkweU5tVTROekJtWkFBQ0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQTdhVjl4Z0NZcFkzR21YV2x0c293Mg==}u4FHsJF3AVHAqgtGCMXudA== >> nsbindconnectionslimit: 3 >> nsoperationconnectionslimit: 20 >> nsabandonedsearchcheckinterval: 1 >> nsconcurrentbindlimit: 10 >> nsconcurrentoperationslimit: 2 >> nsproxiedauthorization: on >> nsconnectionlife: 0 >> nsbindtimeout: 15 >> nsreferralonscopedsearch: off >> nschecklocalaci: on >> nsbindretrylimit: 3 >> nsslapd-sizelimit: 2000 >> nsslapd-timelimit: 3600 >> nshoplimit: 10 >> nsmaxresponsedelay: 60 >> nsmaxtestresponsedelay: 15 >> nsusestarttls: off >> Hi Mark. >> I tried adding the subsequent URL's and it doesn't allow multiple entries for this attribute. >> It appears all the URLS need to be part of the one*nsfarmserverurl***attribute*.* >> ** >> *ldap_initialize( ldap://dsa4.domain.com )** >> add nsFarmServerURL: >> ldap://dsa2.domain.com:389 >> modifying entry "cn=chainlab,cn=chaining >> database,cn=plugins,cn=config" >> ldap_modify: Server is unwilling to perform (53)* >> * additional info: Adding attributes is not allowed*** >> ** >> *I believe I have this working now.* >> ** >> *Thank you Mark for getting me pointed in the right direction.* > > Were you able to set multiple urls? Or did you just go with one > for now? > > > Mark > > -- > Directory Server Development Team > > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to > 389-users-leave(a)lists.fedoraproject.org > <mailto:389-users-leave@lists.fedoraproject.org> > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > <https://docs.fedoraproject.org/en-US/project/code-of-conduct/> > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > <https://fedoraproject.org/wiki/Mailing_list_guidelines> > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje... > <https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...> > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > <https://pagure.io/fedora-infrastructure> > > > > -- > -- > Yikes..I figured it out. You only specify the protocol once. > > nsfarmserverurl: *ldap*://dsa1.domain.com:389 dsa2.domain.com:389 > dsa3.domain.com:389/ Actually this is vaguely mentioned in the RHDS 10 admin guide: 2.3.1.2.4. Providing a List of Failover Servers There can be additional LDAP URLs for servers included to use in the case of failure. Add alternate servers to the /|nsFarmServerURL|/ attribute, separated by spaces. nsFarmServerURL: ldap://example.com us.example.com:389 africa.example.com:1000/ In this sample LDAP URL, the database link first contacts the server |example.com| on the standard port to service an operation. If it does not respond, the database link then contacts the server |us.example.com| on port |389|. If this server fails, it then contacts |africa.example.com| on port |1000|. You didn't run into this, but our CLI tools/UI are definitely not handling this correctly either. I will open a bug for that. Thanks, Mark > > > 389 Directory Server Development Team > > _______________________________________________ > 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.fedoraproje... > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Directory Server Development Team

1 year, 9 months

1
0
0 / 0

Re: How to replicate password lockout attributes from a consumer or hub to a master(s)

by Michael Starling

________________________________ From: Michael Starling <mlstarling31(a)hotmail.com> Sent: Monday, August 16, 2021 10:54 AM To: Pierre Rogier <progier(a)redhat.com>; General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org> Subject: [389-users] Re: How to replicate password lockout attributes from a consumer or hub to a master(s) ________________________________ From: Pierre Rogier <progier(a)redhat.com> Sent: Monday, August 16, 2021 6:33 AM To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org> Cc: Michael Starling <mlstarling31(a)hotmail.com> Subject: Re: [389-users] Re: How to replicate password lockout attributes from a consumer or hub to a master(s) On Fri, Aug 13, 2021 at 9:42 PM Mark Reynolds <mreynolds(a)redhat.com<mailto:mreynolds@redhat.com>> wrote: On 8/13/21 2:40 PM, Michael Starling wrote: ________________________________ From: Michael Starling <mlstarling31(a)hotmail.com><mailto:mlstarling31@hotmail.com> Sent: Friday, August 13, 2021 10:41 AM To: Mark Reynolds <mreynolds(a)redhat.com><mailto:mreynolds@redhat.com>; General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org><mailto:389-users@lists.fedoraproject.org> Subject: Re: [389-users] How to replicate password lockout attributes from a consumer or hub to a master(s) ________________________________ From: Michael Starling <mlstarling31(a)hotmail.com><mailto:mlstarling31@hotmail.com> Sent: Thursday, August 12, 2021 3:29 PM To: Mark Reynolds <mreynolds(a)redhat.com><mailto:mreynolds@redhat.com>; General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org><mailto:389-users@lists.fedoraproject.org> Subject: Re: [389-users] How to replicate password lockout attributes from a consumer or hub to a master(s) ________________________________ From: Mark Reynolds <mreynolds(a)redhat.com><mailto:mreynolds@redhat.com> Sent: Thursday, August 12, 2021 3:16 PM To: Michael Starling <mlstarling31(a)hotmail.com><mailto:mlstarling31@hotmail.com>; General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org><mailto:389-users@lists.fedoraproject.org> Subject: Re: [389-users] How to replicate password lockout attributes from a consumer or hub to a master(s) On 8/12/21 2:33 PM, Michael Starling wrote: ________________________________ From: Mark Reynolds <mreynolds(a)redhat.com><mailto:mreynolds@redhat.com> Sent: Thursday, August 12, 2021 11:48 AM To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org><mailto:389-users@lists.fedoraproject.org>; Michael Starling <mlstarling31(a)hotmail.com><mailto:mlstarling31@hotmail.com> Subject: Re: [389-users] How to replicate password lockout attributes from a consumer or hub to a master(s) On 8/12/21 10:53 AM, Michael Starling wrote: Hello. I've taken over a large 389-ds environment running on Oracle Linux 8 and the first task I need to complete is to enable password lockouts. I was able to enable password lockouts successfully however it only works if the client is pointed directly to a master. The account locks out and the attributes are propagated down to the hubs and consumers. If the client is pointed to a read-only hub or consumer then the account does not lockout and the password attributes do not propagate back to the masters. passwordIsGlobalPolicy: on is set on all masters, hubs and consumers Password policy attributes I expect to replicate: passwordRetryCount accountUnlockTime retryCountResetTime I've tried following the chaining guide below which I think is what I need to do to get this work as expected, however I've hit a snag. https://directory.fedoraproject.org/docs/389ds/howto/howto-chainonupdate.... 389 Directory Server - Howto:ChainOnUpdate<https://directory.fedoraproject.org/docs/389ds/howto/howto-chainonupdate....> Introduction. The usual deployment for a large replication topology will have the client applications reading from hubs or dedicated consumers in order to spread out the load and off-load search request processing from the masters. directory.fedoraproject.org<http://directory.fedoraproject.org> The document states the backend must be added to the hub or consumer, however when I try and add the following LDIF to the hub I get the "unwilling to perform" error. This makes sense because the hub is read-only so I'm confused as how I can update the config on a read-only hub or consumer? Hi Michael, To complete Mark's answer and try to solve your confusion: hub and consumer are read-only replicas (i.e backends) cn=config is another backend that is still writable. So you should not be able to modify the entries in the replicated suffix ( and should instead get referrals towards the master(s)) but you should still be able to modify the config. Regards, Pierre Hi Pierre. Thanks for confirming what I'm seeing. Any idea how to set multiple values in the nsfarmserverurl attribute? dn: cn=chainlab,cn=chaining database,cn=plugins,cn=config objectclass: top objectclass: extensibleObject objectclass: nsBackendInstance cn: chainlab nsslapd-suffix: dc=domain,dc=com nsfarmserverurl: ldap://dsa1.domain.com:389 ldap://dsa2.domain.com:389 ldap://dsa3.domain.com:389 nsmultiplexorbinddn: uid=repluser,cn=config nsmultiplexorcredentials: mypassword nsCheckLocalACI: on adding new entry "cn=chainlab,cn=chaining database,cn=plugins,cn=config" ldap_add: Server is unwilling to perform (53) This is the doc you want to follow to get this working. But it is complicated... In this case I'm not sure why the error 53 is being returned. There is something about that entry it does not like. So please check the access and errors log from the time of this failure (see /var/log/dirsrv/slapd-YOUR_INSTANCE/). There is usually more info logged when an error 53 happens. Also what version of 389-ds-base are you running? Thanks, Mark Hub or Consumer Step 1 (Hub and Consumer): the chaining backend must be created on the hub and consumer: dn: cn=chainbe1,cn=chaining database,cn=plugins,cn=config objectclass: top objectclass: extensibleObject objectclass: nsBackendInstance cn: chainbe1 nsslapd-suffix: <suffix to replicate> nsfarmserverurl: ldap://supplier1:port supplier2:port ... supplierN:port/ # also, ldaps can be used instead # of ldap for secure connections - # requires the secure port nsmultiplexorbinddn: cn=Replication Manager,cn=config # or whatever the replica bind DN is on the supplier nsmultiplexorcredentials: password nsCheckLocalACI: on Any help would be greatly appreciated. Thanks _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org<mailto: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.fedoraproje... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Directory Server Development Team Thanks for getting me the right track Mark. Looks like the "nsFarmServerURL" is not correct. Versions: 389-ds-base-libs-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64 389-ds-base-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64 I thought I was maybe hitting the bug described below so I added a trailing "/" but the issue persists. https://bugzilla.redhat.com/show_bug.cgi?id=1363970 nsfarmserverurl: ldap://dsa1.domain.com:389 ldap://dsa2.domain.com:389 ldap://dsa3.domain.com:389/ This is what I see in the logs on the hub when trying to add the LDIF. The idea is for the hub to send these password attributes back to all masters. These are the masters in the environment. ldap://dsa1.domain.com:389 ldap://dsa2.domain.com:389 ldap://dsa3.domain.com:389 [12/Aug/2021:14:12:38.228746875 -0400] - ERR - chaining database - cb_instance_config_initialize - Error with config attribute nsfarmserverurl : not a valid LDAP URL [12/Aug/2021:14:12:38.230107318 -0400] - ERR - chaining database - cb_instance_add_config_check_callback - Can't instantiate chaining backend instance chainlab. [12/Aug/2021:14:13:11.436433137 -0400] - ERR - chaining database - cb_instance_config_initialize - Error with config attribute nsfarmserverurl : not a valid LDAP URL [12/Aug/2021:14:13:11.437510161 -0400] - ERR - chaining database - cb_instance_add_config_check_callback - Can't instantiate chaining backend instance chainlab. [12/Aug/2021:14:15:15.652343542 -0400] - ERR - chaining database - cb_instance_config_initialize - Error with config attribute nsfarmserverurl : not a valid LDAP URL [12/Aug/2021:14:15:15.653524818 -0400] - ERR - chaining database - cb_instance_add_config_check_callback - Can't instantiate chaining backend instance chainlab. [12/Aug/2021:14:20:12.212414022 -0400] - ERR - chaining database - cb_instance_config_initialize - Error with config attribute nsfarmserverurl : not a valid LDAP URL [12/Aug/2021:14:20:12.213556900 -0400] - ERR - chaining database - cb_instance_add_config_check_callback - Can't instantiate chaining backend instance chainlab Ok, I think its not liking the multiple values in the attribute, even though the document says you have multiple urls. I think you need to add the config like this: nsfarmserverurl: ldap://dsa1.domain.com:389 nsfarmserverurl: ldap://dsa2.domain.com:389 nsfarmserverurl: ldap://dsa3.domain.com:389 Give it a try? HTH, Mark -- Directory Server Development Team Looks like it only added the first entry. Do I need to add an entry for each MAster? dn: cn=chainlab,cn=chaining database,cn=plugins,cn=config objectClass: top objectClass: extensibleObject objectClass: nsBackendInstance cn: chainlab nsslapd-suffix: dc=domain,dc=com nsfarmserverurl: ldap://dsa1.domain.com:389 nsmultiplexorbinddn: uid=replicator,cn=config nsmultiplexorcredentials: {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVGRERBNEJDUm1aRFUwT1dOak5DMDVPVFl5TXpJMg0KWlMwNE16ZzFNVFl3TXkweU5tVTROekJtWkFBQ0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQTdhVjl4Z0NZcFkzR21YV2x0c293Mg==}u4FHsJF3AVHAqgtGCMXudA== nsbindconnectionslimit: 3 nsoperationconnectionslimit: 20 nsabandonedsearchcheckinterval: 1 nsconcurrentbindlimit: 10 nsconcurrentoperationslimit: 2 nsproxiedauthorization: on nsconnectionlife: 0 nsbindtimeout: 15 nsreferralonscopedsearch: off nschecklocalaci: on nsbindretrylimit: 3 nsslapd-sizelimit: 2000 nsslapd-timelimit: 3600 nshoplimit: 10 nsmaxresponsedelay: 60 nsmaxtestresponsedelay: 15 nsusestarttls: off Hi Mark. I tried adding the subsequent URL's and it doesn't allow multiple entries for this attribute. It appears all the URLS need to be part of the one nsfarmserverurl attribute. ldap_initialize( ldap://dsa4.domain.com ) add nsFarmServerURL: ldap://dsa2.domain.com:389 modifying entry "cn=chainlab,cn=chaining database,cn=plugins,cn=config" ldap_modify: Server is unwilling to perform (53) additional info: Adding attributes is not allowed I believe I have this working now. Thank you Mark for getting me pointed in the right direction. Were you able to set multiple urls? Or did you just go with one for now? Mark -- Directory Server Development Team _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org<mailto: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.fedoraproje... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- -- Yikes..I figured it out. You only specify the protocol once. nsfarmserverurl: ldap://dsa1.domain.com:389 dsa2.domain.com:389 dsa3.domain.com:389/ 389 Directory Server Development Team

1 year, 9 months

1
0
0 / 0

Re: How to replicate password lockout attributes from a consumer or hub to a master(s)

by Mark Reynolds

On 8/13/21 2:40 PM, Michael Starling wrote: > > > ------------------------------------------------------------------------ > *From:* Michael Starling <mlstarling31(a)hotmail.com> > *Sent:* Friday, August 13, 2021 10:41 AM > *To:* Mark Reynolds <mreynolds(a)redhat.com>; General discussion list > for the 389 Directory server project. <389-users(a)lists.fedoraproject.org> > *Subject:* Re: [389-users] How to replicate password lockout > attributes from a consumer or hub to a master(s) > > > ------------------------------------------------------------------------ > *From:* Michael Starling <mlstarling31(a)hotmail.com> > *Sent:* Thursday, August 12, 2021 3:29 PM > *To:* Mark Reynolds <mreynolds(a)redhat.com>; General discussion list > for the 389 Directory server project. <389-users(a)lists.fedoraproject.org> > *Subject:* Re: [389-users] How to replicate password lockout > attributes from a consumer or hub to a master(s) > > > ------------------------------------------------------------------------ > *From:* Mark Reynolds <mreynolds(a)redhat.com> > *Sent:* Thursday, August 12, 2021 3:16 PM > *To:* Michael Starling <mlstarling31(a)hotmail.com>; General discussion > list for the 389 Directory server project. > <389-users(a)lists.fedoraproject.org> > *Subject:* Re: [389-users] How to replicate password lockout > attributes from a consumer or hub to a master(s) > > > On 8/12/21 2:33 PM, Michael Starling wrote: >> >> >> ------------------------------------------------------------------------ >> *From:* Mark Reynolds <mreynolds(a)redhat.com> >> <mailto:mreynolds@redhat.com> >> *Sent:* Thursday, August 12, 2021 11:48 AM >> *To:* General discussion list for the 389 Directory server project. >> <389-users(a)lists.fedoraproject.org> >> <mailto:389-users@lists.fedoraproject.org>; Michael Starling >> <mlstarling31(a)hotmail.com> <mailto:mlstarling31@hotmail.com> >> *Subject:* Re: [389-users] How to replicate password lockout >> attributes from a consumer or hub to a master(s) >> >> >> On 8/12/21 10:53 AM, Michael Starling wrote: >>> Hello. >>> >>> I've taken over a large 389-ds environment running on Oracle Linux 8 >>> and the first task I need to complete is to enable password lockouts. >>> >>> >>> >>> I was able to enable password lockouts successfully however it only >>> works if the client is pointed directly to a master. The account >>> locks out and the attributes are propagated down to the hubs and >>> consumers. >>> >>> If the client is pointed to a read-only hub or consumer then the >>> account does not lockout and the password attributes do not >>> propagate back to the masters. >>> >>> *passwordIsGlobalPolicy*: on is set on all masters, hubs and consumers >>> >>> Password policy attributes I expect to replicate: >>> >>> *passwordRetryCount* >>> *accountUnlockTime* >>> *retryCountResetTime* >>> >>> I've tried following the chaining guide below which I think is what >>> I need to do to get this work as expected, however I've hit a snag. >>> >>> https://directory.fedoraproject.org/docs/389ds/howto/howto-chainonupdate.... >>> <https://directory.fedoraproject.org/docs/389ds/howto/howto-chainonupdate....> >>> 389 Directory Server - Howto:ChainOnUpdate >>> <https://directory.fedoraproject.org/docs/389ds/howto/howto-chainonupdate....> >>> Introduction. The usual deployment for a large replication topology >>> will have the client applications reading from hubs or dedicated >>> consumers in order to spread out the load and off-load search >>> request processing from the masters. >>> directory.fedoraproject.org >>> >>> The document states the backend must be added to the hub or >>> consumer, however when I try and add the following LDIF to the hub I >>> get the "unwilling to perform" error. >>> >>> This makes sense because the hub is read-only so I'm confused as how >>> I can update the config on a read-only hub or consumer? >>> >>> dn: cn=chainlab,cn=chaining database,cn=plugins,cn=config >>> objectclass: top >>> objectclass: extensibleObject >>> objectclass: nsBackendInstance >>> cn: chainlab >>> nsslapd-suffix: dc=domain,dc=com >>> nsfarmserverurl: ldap://dsa1.domain.com:389 >>> ldap://dsa2.domain.com:389 ldap://dsa3.domain.com:389 >>> nsmultiplexorbinddn: uid=repluser,cn=config >>> nsmultiplexorcredentials: mypassword >>> nsCheckLocalACI: on >>> >>> adding new entry "cn=chainlab,cn=chaining database,cn=plugins,cn=config" >>> ldap_add: Server is unwilling to perform (53) >> >> This is the doc you want to follow to get this working. But it is >> complicated... >> >> >> In this case I'm not sure why the error 53 is being returned. There >> is something about that entry it does not like. So please check the >> access and errors log from the time of this failure (see >> /var/log/dirsrv/slapd-YOUR_INSTANCE/). There is usually more info >> logged when an error 53 happens. >> >> >> Also what version of 389-ds-base are you running? >> >> >> Thanks, >> Mark >> >>> >>> Hub or Consumer >>> >>> Step 1 (Hub and Consumer): the chaining backend must be created on >>> the hub and consumer: >>> >>> |dn: cn=chainbe1,cn=chaining database,cn=plugins,cn=config >>> objectclass: top objectclass: extensibleObject >>> objectclass: nsBackendInstance cn: chainbe1 nsslapd-suffix: <suffix >>> to replicate> >>> nsfarmserverurl: ldap://supplier1:port supplier2:port ... supplierN:port/ # also, ldaps can be used instead >>> # of ldap for secure connections - >>> # requires the secure port >>> nsmultiplexorbinddn: cn=Replication Manager,cn=config # or whatever the replica bind DN is on the supplier >>> nsmultiplexorcredentials: password nsCheckLocalACI: on | >>> >>> Any help would be greatly appreciated. >>> >>> Thanks >>> >>> _______________________________________________ >>> 389-users mailing list --389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> >>> To unsubscribe send an email to389-users-leave(a)lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> >>> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://docs.fedoraproject.org/en-US/project/code-of-conduct/> >>> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines> >>> List Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fe... <https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...> >>> Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure <https://pagure.io/fedora-infrastructure> >> -- >> Directory Server Development Team >> >> Thanks for getting me the right track Mark. Looks like the >> "nsFarmServerURL" is not correct. >> >> Versions: >> >> 389-ds-base-libs-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64 >> 389-ds-base-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64 >> >> I thought I was maybe hitting the bug described below so I added a >> trailing "/" but the issue persists. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1363970 >> <https://bugzilla.redhat.com/show_bug.cgi?id=1363970> >> >> nsfarmserverurl: ldap://dsa1.domain.com:389 >> ldap://dsa2.domain.com:389 ldap://dsa3.domain.com:389*/* >> >> This is what I see in the logs on the hub when trying to add the LDIF. >> >> The idea is for the hub to send these password attributes back to all >> masters. >> >> These are the masters in the environment. >> ldap://dsa1.domain.com:389 >> ldap://dsa2.domain.com:389 >> ldap://dsa3.domain.com:389 >> [12/Aug/2021:14:12:38.228746875 -0400] - ERR - chaining database - >> cb_instance_config_initialize -*Error with config attribute >> nsfarmserverurl : not a valid LDAP URL* >> [12/Aug/2021:14:12:38.230107318 -0400] - ERR - chaining database - >> cb_instance_add_config_check_callback - Can't instantiate chaining >> backend instance chainlab. >> [12/Aug/2021:14:13:11.436433137 -0400] - ERR - chaining database - >> cb_instance_config_initialize - Error with config attribute >> nsfarmserverurl : not a valid LDAP URL >> [12/Aug/2021:14:13:11.437510161 -0400] - ERR - chaining database - >> cb_instance_add_config_check_callback - Can't instantiate chaining >> backend instance chainlab. >> [12/Aug/2021:14:15:15.652343542 -0400] - ERR - chaining database - >> cb_instance_config_initialize - Error with config attribute >> nsfarmserverurl : not a valid LDAP URL >> [12/Aug/2021:14:15:15.653524818 -0400] - ERR - chaining database - >> cb_instance_add_config_check_callback - Can't instantiate chaining >> backend instance chainlab. >> [12/Aug/2021:14:20:12.212414022 -0400] - ERR - chaining database - >> cb_instance_config_initialize - Error with config attribute >> nsfarmserverurl : not a valid LDAP URL >> [12/Aug/2021:14:20:12.213556900 -0400] - ERR - chaining database - >> cb_instance_add_config_check_callback - Can't instantiate chaining >> backend instance chainlab >> >> > Ok, I think its not liking the multiple values in the attribute, even > though the document says you have multiple urls. I think you need to > add the config like this: > > > nsfarmserverurl: ldap://dsa1.domain.com:389 > > nsfarmserverurl: ldap://dsa2.domain.com:389 > > nsfarmserverurl: ldap://dsa3.domain.com:389 > > > Give it a try? > > > HTH, > > Mark > > > -- > Directory Server Development Team > Looks like it only added the first entry. Do I need to add an entry for each MAster? > dn: cn=chainlab,cn=chaining database,cn=plugins,cn=config > objectClass: top > objectClass: extensibleObject > objectClass: nsBackendInstance > cn: chainlab > nsslapd-suffix: dc=domain,dc=com > *nsfarmserverurl: ldap://dsa1.domain.com:389* > nsmultiplexorbinddn: uid=replicator,cn=config > nsmultiplexorcredentials: > {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVGRERBNEJDUm1aRFUwT1dOak5DMDVPVFl5TXpJMg0KWlMwNE16ZzFNVFl3TXkweU5tVTROekJtWkFBQ0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQTdhVjl4Z0NZcFkzR21YV2x0c293Mg==}u4FHsJF3AVHAqgtGCMXudA== > nsbindconnectionslimit: 3 > nsoperationconnectionslimit: 20 > nsabandonedsearchcheckinterval: 1 > nsconcurrentbindlimit: 10 > nsconcurrentoperationslimit: 2 > nsproxiedauthorization: on > nsconnectionlife: 0 > nsbindtimeout: 15 > nsreferralonscopedsearch: off > nschecklocalaci: on > nsbindretrylimit: 3 > nsslapd-sizelimit: 2000 > nsslapd-timelimit: 3600 > nshoplimit: 10 > nsmaxresponsedelay: 60 > nsmaxtestresponsedelay: 15 > nsusestarttls: off > Hi Mark. > I tried adding the subsequent URL's and it doesn't allow multiple entries for this attribute. > It appears all the URLS need to be part of the one*nsfarmserverurl***attribute*.* > ** > *ldap_initialize( ldap://dsa4.domain.com )** > add nsFarmServerURL: > ldap://dsa2.domain.com:389 > modifying entry "cn=chainlab,cn=chaining database,cn=plugins,cn=config" > ldap_modify: Server is unwilling to perform (53)* > * additional info: Adding attributes is not allowed*** > ** > *I believe I have this working now.* > ** > *Thank you Mark for getting me pointed in the right direction.* Were you able to set multiple urls? Or did you just go with one for now? Mark -- Directory Server Development Team

1 year, 9 months

3
3
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users August 2021