[389-users] Sync from RDBMS to LDAP

2014-04-22 Thread Fong, Trevor
Hi Everyone, We are in the process of migrating from an old OpenLDAP service to 389-DS. We currently synchronise users and attributes from an Oracle DB to OpenLDAP service using an aging set of custom scripts and DB triggers. We would like to do something similar for 389-DS but using a

Re: [389-users] Sync from RDBMS to LDAP

2014-04-28 Thread Fong, Trevor
*Bump* Surely we can't be the only ones who want to this? Trev From: Fong, Trevor Sent: April-22-14 3:33 PM To: '389-users@lists.fedoraproject.org' Subject: Sync from RDBMS to LDAP Hi Everyone, We are in the process of migrating from an old OpenLDAP service to 389-DS. We currently synchronise

Re: [389-users] Sync from RDBMS to LDAP

2014-04-29 Thread Fong, Trevor
from RDBMS to LDAP Sorry that kind of thing is always a custom scripting job. -- Sent from my HP Pre3 On Apr 28, 2014 13:27, Fong, Trevor trevor.f...@ubc.camailto:trevor.f...@ubc.ca wrote: *Bump* Surely we can't be the only ones who want to this? Trev From

[389-users] Yum Update vs Yum Upgrade

2014-05-20 Thread Fong, Trevor
Hi Everyone, After taking over the LDAP service from a colleague, I updated the 389 DS service to the latest release by issuing a yum update Then when searching around the 389-ds documentation, I came across the install page that said that I must use yum upgrade ... and not update. My

Re: [389-users] Yum Update vs Yum Upgrade

2014-05-22 Thread Fong, Trevor
where the -obsoletes flag says to remove packages that have been made obsolete by the upgrade (say you're upgrading from 5.9 to 6.5). Cheers! David On May 20, 2014, at 10:00, Rich Megginson rmegg...@redhat.commailto:rmegg...@redhat.com wrote: On 05/20/2014 10:58 AM, Fong, Trevor wrote: Hi

[389-users] db2index Not Stopping

2014-05-30 Thread Fong, Trevor
Hi Everyone, Searches and any kind of access to a particular ou seem to be hanging (yep, even tried deleting it and it's children) so I ran db2index and left it running all night. It's still running 20 hours later - is that normal? If it's not, is it OK to kill the process? What would you

[389-users] Trouble with Replication - Initializing Consumers

2014-09-24 Thread Fong, Trevor
Hi Everyone, I'm having trouble initializing consumers for replication. On 2 of the 3 consumers, I get the following message after trying to re-initialize the consumers from the 389-console: NSMMReplicationPlugin - replica_replace_ruv_tombstone: failed to update replication update vector

Re: [389-users] Trouble with Replication - Initializing Consumers

2014-09-24 Thread Fong, Trevor
And nope, reindexing with /usr/lib64/dirsrv/slapd-instance/db2index.pl -v -D cn=Directory Manager -w xxx -n userRoot didn't help either. Trev From: 389-users-boun...@lists.fedoraproject.org [mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of Fong, Trevor Sent: Wednesday, September

Re: [389-users] Trouble with Replication - Initializing Consumers

2014-09-25 Thread Fong, Trevor
...@lists.fedoraproject.org] On Behalf Of Fong, Trevor Sent: Wednesday, September 24, 2014 4:21 PM To: 389-users@lists.fedoraproject.org Subject: Re: [389-users] Trouble with Replication - Initializing Consumers Hi Noriko, Thanks for your response. We’re running 389-Directory/1.2.11.29

Re: [389-users] Switching from 389-ds-base 1.2.11 to 1.3.3

2014-11-27 Thread Fong, Trevor
? Thanks, Trev From: Fong, Trevor Fong trevor.f...@ubc.camailto:trevor.f...@ubc.ca Reply-To: 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org Date: Wednesday, November 26, 2014 at 3:07 PM To: 389-users

Re: [389-users] 389-ds and Multi CPU's

2014-12-08 Thread Fong, Trevor
-users@lists.fedoraproject.org 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org, Trevor Fong trevor.f...@ubc.camailto:trevor.f...@ubc.ca Subject: Re: [389-users] 389-ds and Multi CPU's On 12/08/2014 02:08 PM, Fong, Trevor wrote: Hi Everyone, We’ve inherited a 389-ds

Re: [389-users] 389-ds and Multi CPU's

2014-12-09 Thread Fong, Trevor
and Multi CPU's On 12/08/2014 05:43 PM, Fong, Trevor wrote: Hi Mike, It's Mark :-) I get that a lot for some reason. Thanks for the reply. The typical result of the result is: [08/Dec/2014:07:08:04 -0800] conn=130262 op=1 RESULT err=0 tag=101 nentries=5 etime=0 Yeah this looks fine

Re: [389-users] 389-ds and Multi CPU's

2014-12-11 Thread Fong, Trevor
Last message got embargoed for being over-length. Trimming this mail. Trev From: Fong, Trevor Fong trevor.f...@ubc.camailto:trevor.f...@ubc.ca Date: Thursday, December 11, 2014 at 9:03 AM To: mreyno...@redhat.commailto:mreyno...@redhat.com mreyno...@redhat.commailto:mreyno...@redhat.com, 389

Re: [389-users] 389-ds and Multi CPU's

2014-12-11 Thread Fong, Trevor
@lists.fedoraproject.org 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org Subject: Re: [389-users] 389-ds and Multi CPU's On 12/09/2014 05:58 PM, Fong, Trevor wrote: Hi Mark, I’ve afraid adding nsIndexIDListScanLimit to cn=objectclass,cn=index,cn=userRoot,cn=ldbm database

Re: [389-users] DNA Plugin Causes 389-DS to Crash if Large Number of Candidates

2015-07-16 Thread Fong, Trevor
BTW, we were able to artificially make it work by changing the dnaFilter to the emplid of our test user: dnaFilter: ((employeeNumber=12345)(objectclass=posixAccount)) Trev From: Trevor Fong trevor.f...@ubc.camailto:trevor.f...@ubc.ca Date: Thursday, July 16, 2015 at 4:47 PM To:

Re: [389-users] DNA Plugin Causes 389-DS to Crash if Large Number of Candidates

2015-07-17 Thread Fong, Trevor
:19 PM To: 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org Subject: Re: [389-users] DNA Plugin Causes 389-DS to Crash if Large Number of Candidates On 07/16/2015 05:47 PM, Fong, Trevor wrote: Hi

[389-users] DNA Plugin Causes 389-DS to Crash if Large Number of Candidates

2015-07-16 Thread Fong, Trevor
Hi Guys, We’re running 389-ds 1.2.11.29-1.el6 and are experimenting with the DNA plugin. When trying to set an existing account’s uidNumber to the magic regen number of 9, we get the error message in the errors log: Allocation of a new value for range cn=uid numbers,cn=distributed

Re: [389-users] DS crashed /killed by OS

2015-10-22 Thread Fong, Trevor
Hi German, Thanks for your suggestion. I’m happy to confirm that setting userRoot’s nsslapd-cachememsize: 429496730 (1/15th of previous value of 6 GB) has addressed the memory issue for now, and % Mem for the ns-slapd process seems to be at a manageable level. Thanks very much, Trev On

Re: [389-users] DS crashed /killed by OS

2015-10-20 Thread Fong, Trevor
Hi German, Thanks very much for your reply. Just to make sure I have it straight, I’ve currently got userRoot’s nsslapd-cachememsize = 6 GB on at 16GB machine. I should change that to nsslapd-cachememsize = 6 GB / 15 = 429496730 Do I have that right? Thanks again, Trev On 2015-10-20, 10:23

[389-users] ACI's on DB Linked Directories

2016-03-29 Thread Fong, Trevor
Hi Everyone, A question about how to best go about doing access control on db-linked directories. Given the below 2-directory setup (Dir1 has a db link set up to Dir2, and vice versa), is the shown ACI setup possible/advisable? If not, what’s the best way to make it work?: Dir1:

[389-users] Re: ACI's on DB Linked Directories

2016-03-31 Thread Fong, Trevor
Hi William, Thanks very much for your reply. On 2016-03-29, 4:23 PM, "William Brown" <wibr...@redhat.com> wrote: >On Tue, 2016-03-29 at 22:49 +, Fong, Trevor wrote: >> Hi Everyone, >> >> A question about how to best go about doing access contr

[389-users] Re: elapsed time gremlin

2017-02-17 Thread Fong, Trevor
Can we set nsIDListScanLimit=7 (or whatever) for a service account instead of changing the system nsslapd-idlistscanlimit setting? Thanks, Trev From: Anthony Winstanley Reply-To: "389-users@lists.fedoraproject.org" <389-users@lists.fedoraproject.org> Date: Friday,

[389-users] Re: Replication Delay

2018-05-18 Thread Fong, Trevor
Tue, 2018-02-20 at 23:36 +, Fong, Trevor wrote: >> Hi William, >> >> Thanks a lot for your reply. >> >> That's correct - replication schedule is not enabled. >> No - there are definitely changes to replicate - I know, I made th

[389-users] Experiences with Large Groups (>100k Members)

2018-04-26 Thread Fong, Trevor
Hi Everyone, I was wondering what experiences people have had with large groups (> 100k members) in 389 DS? Particularly interested in loading, managing and syncing them. WRT syncing – how do people efficiently sync large groups? Most sync utilities sync at the attribute level; if the changed

[389-users] Re: Experiences with Large Groups (>100k Members)

2018-04-26 Thread Fong, Trevor
-ds and migrated along with changes. Replication (master/master) is solid, keeps up with day to day changes fine, very stable. Overall no issues for 10+ years using it with steady growth. We are moving away to another solution but by not because of 389ds. Good luck. -Trevor From: Fong, Trevor [ma

[389-users] Replication Delay

2018-02-16 Thread Fong, Trevor
Hi Everyone, I’ve set up a new 389 DS cluster (389-Directory/1.3.6.1 B2018.016.1710) and have set up a replication agreement from our old cluster (389-Directory/1.2.11.15 B2014.300.2010) to a master node in the new cluster. Problem is that updates in the old cluster take up to 15 mins to make

[389-users] Re: Replication Delay

2018-02-20 Thread Fong, Trevor
t;will...@blackhats.net.au> wrote: On Sat, 2018-02-17 at 01:49 +, Fong, Trevor wrote: > Hi Everyone, > > I’ve set up a new 389 DS cluster (389-Directory/1.3.6.1 > B2018.016.1710) and have set up a replication agreement from our old > cluster (389-D

[389-users] Re: Experiences with Large Groups (>100k Members)

2018-04-26 Thread Fong, Trevor
difference. Still interested in other people’s experience with large groups. From: "Fong, Trevor" <trevor.f...@ubc.ca> Reply-To: "389-users@lists.fedoraproject.org" <389-users@lists.fedoraproject.org> Date: Thursday, April 26, 2018 at 11:06 AM To: "389-user

[389-users] Dynamic Group Query Not Returning Members

2019-03-13 Thread Fong, Trevor
Hi There, I'm trying to set up dynamic groups with 389 DS (1.3.7.5 B2018.184.1411) but my queries against it don't seem to be returning any members. I have a user set up like this: objectClass: eduPerson objectClass: inetLocalMailRecipient objectClass: inetOrgPerson objectClass: inetUser

[389-users] Setting Up 389 DS for Load Balancing with SSL Wildcard Certs

2019-07-26 Thread Fong, Trevor
Hi Everyone, I've configured 2 new 389 DS hubs (eg new1.example.com, new2.example.com) and have connected them to our main 389 DS cluster. They each have their own self-signed certificate, and replication is working well. I now want to load-balance these 2 nodes under their own VIP/hostname:

[389-users] Re: Setting Up 389 DS for Load Balancing with SSL Wildcard Certs

2019-07-29 Thread Fong, Trevor
rt dn: cn=RSA,cn=encryption,cn=config changetype: modify replace: nsSSLPersonalitySSL nsSSLPersonalitySSL: *.example.com - CA 6. Restart 389 DS systemctl restart dirsrv.target Thanks, Trev On 2019-07-26, 5:49 PM, "William Brown" wrote: > On 27 Jul 2019, at

[389-users] Re: Re-initialization Failure: Bulk Import Abandoned, Thread Monitoring Returned -23

2020-09-18 Thread Fong, Trevor
Thanks William. Just wanted to make an update to report that recovery via ldif2db was successful last night. Thanks, Trev On 2020-09-17, 7:37 PM, "William Brown" wrote: > I don't want to do an db2ldif during production time since it will put the db into read-only mode. > The

[389-users] Re-initialization Failure: Bulk Import Abandoned, Thread Monitoring Returned -23

2020-09-17 Thread Fong, Trevor
Hi Everyone, I'm having an issue re-initializing our secondary muti-master replicated 389 DS provider node via 389-Console > replication agreement > "Initialize Consumer". It eventually aborts the update with an error "import userRoot: Thread monitoring returned: -23" Would anyone know how to

[389-users] Re: Re-initialization Failure: Bulk Import Abandoned, Thread Monitoring Returned -23

2020-09-17 Thread Fong, Trevor
Hi William, Thanks for your suggestion about db2ldif. Doesn't db2ldif put the server into read-only mode? We would want to avoid that as that is our primary provider. Thanks, Trev On 2020-09-17, 4:52 PM, "William Brown" wrote: Hi there, > On 18 Sep 2020, a

[389-users] Re: Re-initialization Failure: Bulk Import Abandoned, Thread Monitoring Returned -23

2020-09-17 Thread Fong, Trevor
y provider with it. Thanks, Trev From: "Fong, Trevor" Reply-To: "389-users@lists.fedoraproject.org" <389-users@lists.fedoraproject.org> Date: Thursday, September 17, 2020 at 7:02 PM To: "389-users@lists.fedoraproject.org" <389-users@lists.fedoraproject.org> Subj

[389-users] Re: Re-initialization Failure: Bulk Import Abandoned, Thread Monitoring Returned -23

2020-09-17 Thread Fong, Trevor
, "William Brown" wrote: Yes, I think it does. So in that case it would be good to check the replication configurations and connectivity between the servers is good to eliminate that as a possible cause. > On 18 Sep 2020, at 10:02, Fong, Trevor wrote: >

[389-users] Re: Re-initialization Failure: Bulk Import Abandoned, Thread Monitoring Returned -23

2020-09-17 Thread Fong, Trevor
e/memoryusage#DB_and_entry_cache_RAM_usage https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/configuration_command_and_file_reference/database_plug_in_attributes#nsslapd_cache_autosize Thanks, M. On Thu, Sep 17, 2020 at 4:10 PM Fong, Trevor mailto:trevor.f...@ubc.ca&

[389-users] Provider Node Not Restarting Following Failed Schema Update

2020-06-25 Thread Fong, Trevor
Hi There, We tried to dynamically a new schema dynamically using /usr/lib64/dirsrv/slapd-eldapp1/schema-reload.pl Unfortunately, (and unknown to us at the time) the objectClass definition misspelt a couple of the attribute names. The schema reload process should have picked that up and refused

[389-users] Re: unattended request cert process

2020-12-02 Thread Fong, Trevor
Hi abosch, Have you looked at preconfiguring the cert db's with a wildcard cert from a CA to avoid the request/sign dance? Trev On 2020-12-02, 1:04 AM, "Angel Bosch Mora" wrote: [CAUTION: Non-UBC Email] > depending on your version of 389, look at "dsctl tls > import-ca"