hence failed?
Thanks,
Russ.
On Aug 27, 2015, at 7:06 PM, Russell Beall
mailto:be...@usc.edu>> wrote:
Thanks for that. I had looked into that but it was a bit heavyweight compared
to what we are trying to do. I was hoping there was an easy way to simply have
the command-line ignore the cond
, Alexander Jung
mailto:alexander.w.j...@gmail.com>> wrote:
Hi,
we use http://cnmonitor.sourceforge.net/ to keep an eye on our ldap servers,
including replication.
Works nicely and sends mail if something goes amiss.
Mit freundlichen Grüßen,
Alexander Jung
2015-08-21 4:35 GMT+02:00 R
Hello,
I have deployed a MMR cluster with a recent (about April) version of 389 from
the CentOS 6 repository.
Following example 2 of this document, I have tried to set up a monitoring
script on each node to verify that replication is correctly succeeding:
http://directory.fedoraproject.org/docs
I had this problem a while back and updated the number of locks, but I couldn't
get the number of locks to actually change for real until I reimported the
database. I continued to get lock-related issues, even though I think the
reported number of locks did change, until the database was reimpo
On Mar 3, 2014, at 11:01 AM, Rich Megginson
mailto:rmegg...@redhat.com>> wrote:
On 03/03/2014 11:38 AM, Russell Beall wrote:
On Mar 3, 2014, at 6:39 AM, Rich Megginson
mailto:rmegg...@redhat.com>> wrote:
On 02/28/2014 05:26 PM, Russell Beall wrote:
This has led me to finally
On Mar 3, 2014, at 6:39 AM, Rich Megginson
mailto:rmegg...@redhat.com>> wrote:
On 02/28/2014 05:26 PM, Russell Beall wrote:
This has led me to finally discover the true bottleneck in the indexing of one
particular attribute. The attribute is a custom attribute similar to memberOf.
hould show
those unindexed internal searches, which should show up using logconv.pl
Thanks,
Russ.
On Feb 27, 2014, at 1:19 PM, Rich Megginson
mailto:rmegg...@redhat.com>> wrote:
On 02/27/2014 12:49 PM, Russell Beall wrote:
Hi Rich,
Thanks for the data. I've been continuing to exp
o index).
Does this information point to anything that I should look into further?
Thanks,
Russ.
On Feb 27, 2014, at 1:19 PM, Rich Megginson
mailto:rmegg...@redhat.com>> wrote:
On 02/27/2014 12:49 PM, Russell Beall wrote:
Hi Rich,
Thanks for the data. I've been continuing to exper
Thanks,
Russ.
On Feb 19, 2014, at 4:08 PM, Rich Megginson
mailto:rmegg...@redhat.com>> wrote:
On 02/19/2014 04:56 PM, Russell Beall wrote:
Hi all,
We've just set up monster-sized server nodes to run 389 as a replacement to Sun
DS. I've been running my tests and I am pleased to
nd then keep the aci entry at the root suffix
independent so it can be set separately for multiple downstream replicants.
That way we could possibly subdivide the service accounts across different
nodes. Is that possible?
Thanks,
Russ.
==========
Russell Beall
Systems Prog
On Oct 23, 2013, at 3:29 PM, Rich Megginson wrote:
> Unless you are actually using attribute encryption, you don't have to worry
> about this at all.
Ok, as long as there are no side effects such as an encrypted changelog or
passwords encrypted by those keys. I think I got mixed messages whe
I am working out the best way to enable SSL in a new 389 directory suite setup.
I found that when updating the SSL certificate, there are problems with the
symmetric keys used for attribute encryption. The instructions simply say to
delete those entries and have the directory create new keys o
Hi,
I am trying to port a plugin from our Sun DS to 389. I worked through a number
of API differences and got it to compile. When I tried to run a test I keep
getting segmentation faults in the pthread library regardless of how I compile
or link the code. I boiled it down to the following si
e root ACI attribute from replicating, and then
set an individualized ACI attribute at the root of each replicant to serve
different subsets of services?
Thanks very much,
Russ.
On Jul 9, 2013, at 3:08 AM, Ludwig Krispenz wrote:
>
> On 07/09/2013 12:01 AM, Russell Beall wrote:
>&
d help you to investigate the usage
> of your acis and which acis lead to the decision and which otehr acis are
> processed before, so it could help in redesigning your acis, what you
> probably need to do.
>
> Regards,
> Ludwig
>
> On 07/04/2013 12:06 AM, Russell B
I did a lot of work experimenting with 389 for use as a replacement to Sun
SJES. Worked really well when I focused my efforts on the backend processing
we do with Directory Manager, except for a few performance issues which are
being addressed in bug reports.
I thought sure I had done at least
Hi,
I have a quick question about fractional replication.
There is an attribute which allows for excluding attributes as needed.
nsds5replicatedattributelist: (objectclass=*) $ EXCLUDE attribute1, attribute2,
…
The documentation appears to require that the filter always be set to
(objectclas
can be very seriously impacted when the cache is not
tuned well and doesn't have enough space for decent response time.
Regards,
Russ.
==
Russell Beall
Programmer Analyst IV
Enterprise Identity Management
University of Southern California
be...@us
I have not tried modrdn.
Very early in my testing I thought I was seeing unbounded growth by performing
endless deletes (and re-adds). That, I found out through your much-appreciated
responses to this list, was causing an explosion in tombstone entries and thus
the server was exploding in actu
t;
> Yes, please.
Ok.
Russ.
>
>>
>> Thanks,
>> Russ.
>>
>> ==
>> Russell Beall
>> Programmer Analyst IV
>> Enterprise Identity Management
>> University of Southern California
>> be...@usc.edu
>>
elieving it then has a right to 72GB of working memory.
With 12GB set, the server quickly eats up the 32GB RAM, and goes well into the
16GB of swap before finally crashing.
Is this something I should just go ahead and file as a bug?
Thanks,
Russ.
==========
Russell Beall
P
I had very few OS-related issues setting up on CentOS 6.2. I set a node up in
this OS alongside a node in RedHat 6.2 and the settings for the directoryserver
are identical. I was pleased at the very large quantity of documentation at
the redhat site which describes every aspect of the product
On Apr 23, 2012, at 10:28 AM, Rich Megginson wrote:
> That's very interesting. Does Sun DS have some sort of tuning parameter for
> number of values? That is, they may have some threshold for number of values
> in an attribute - once the number hits that threshold, they may switch to
> using
I've been running some more tests before setting up the ticket, but I think I
have enough information now. The uniqueMember attribute has extra processing
overhead, but the necessary optimization might apply across the board for all
attributes. I found also that adding large sets of values for
ion on a 600K-entry directory by following the
documentation steps. I had to make a special configuration to handle very
large entries, but other than that, replication has been working fine for me.
Regards,
Russ.
======
Russell Beall
Programmer Analyst IV
Enterp
298
> 90 1 0 9 0 0| 040M| 60B 310B| 0 0 | 389 296
> 88 1 0 11 0 0| 040M| 60B 310B| 0 0 | 358 319
> 76 0 0 23 1 0| 041M| 60B 310B| 0 0 | 403 303
>
> @+
>
>
>
> Le 19 avril 2012 18
across 110,000 records in about 40 minutes (20
minutes each way -- with 389).
Russ.
On Apr 19, 2012, at 10:18 AM, Rich Megginson wrote:
> On 04/19/2012 10:50 AM, Russell Beall wrote:
>>
>> Thanks for the tips. I scanned the dse.ldif for those plugins and I found
>> def
other
attributes runs pretty quick.
Regards,
Russ.
On Apr 19, 2012, at 2:20 AM, Andrey Ivanov wrote:
> Hi Russel,
>
>
> Le 18 avril 2012 23:06, Russell Beall a écrit :
> On Apr 18, 2012, at 11:15 AM, Rich Megginson wrote:
>> Yeah, this particular operation has not been
On Apr 18, 2012, at 11:15 AM, Rich Megginson wrote:
> You mean, with SunDS? On Linux or Solaris?
The Sun DS instance I'm talking about is on Sun v440 machines.
The 389 instance is on relatively new servers with RedHat Linux 6.
> Yeah, this particular operation has not been optimized. I belie
ou=groups.
Thanks,
Russ.
======
Russell Beall
Programmer Analyst IV
Enterprise Identity Management
University of Southern California
be...@usc.edu
==
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailma
believe it was. I'll have to hit
it again over time and see what happens.
Thanks again,
Russ.
On Apr 16, 2012, at 2:51 PM, Rich Megginson wrote:
> On 04/16/2012 03:22 PM, Russell Beall wrote:
>>
>>
>> On Apr 16, 2012, at 1:50 PM, Rich Megginson wrote:
>>
>&
ttach valgrind to the ns-slapd process so I
can see if there is some kind of huge leak?
Thanks very much,
Russ.
==
Russell Beall
Programmer Analyst IV
Enterprise Identity Management
University of Southern California
be...@usc.edu
==
-
32 matches
Mail list logo
