:35 GMT+02:00 Russell Beall be...@usc.edumailto:be...@usc.edu:
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
failed?
Thanks,
Russ.
On Aug 27, 2015, at 7:06 PM, Russell Beall
be...@usc.edumailto: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
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:
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
On Mar 3, 2014, at 6:39 AM, Rich Megginson
rmegg...@redhat.commailto: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
On Mar 3, 2014, at 11:01 AM, Rich Megginson
rmegg...@redhat.commailto:rmegg...@redhat.com wrote:
On 03/03/2014 11:38 AM, Russell Beall wrote:
On Mar 3, 2014, at 6:39 AM, Rich Megginson
rmegg...@redhat.commailto:rmegg...@redhat.com wrote:
On 02/28/2014 05:26 PM, Russell Beall wrote:
This has
unindexed internal searches, which should show up using logconv.pl
Thanks,
Russ.
On Feb 27, 2014, at 1:19 PM, Rich Megginson
rmegg...@redhat.commailto: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 experiment and work
this information point to anything that I should look into further?
Thanks,
Russ.
On Feb 27, 2014, at 1:19 PM, Rich Megginson
rmegg...@redhat.commailto: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 experiment
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 Programmer IV
Enterprise
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
On Oct 23, 2013, at 3:29 PM, Rich Megginson rmegg...@redhat.com 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
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 Beall wrote:
I did a lot of work experimenting with 389 for use as a replacement to Sun
SJES. Worked really
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
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...@usc.edu
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
Programmer Analyst IV
.
==
Russell Beall
Programmer Analyst IV
Enterprise Identity Management
University of Southern California
be...@usc.edu
==
On Apr 24, 2012, at 6:53 AM, Rich Megginson wrote:
The thing in common is this - when the cache usage
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
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
/nss.conf: Permission
denied
I have played with that file's permissions, even setting them as 777, but
nothing changes. It is currently owned by user fedora-ds group fedora-ds
and permissions are set to 400.
Thank you again.
Regards,
Alberto.
Russell Beall wrote:
I had very few OS
-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
Enterprise Identity Management
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
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
of 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 be...@usc.edu a écrit :
On Apr 18, 2012, at 11:15 AM, Rich Megginson wrote:
Yeah, this particular operation has not been optimized. I
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
definitions for them all
| 041M| 60B 310B| 0 0 | 403 303
@+
Le 19 avril 2012 18:50, Russell Beall be...@usc.edu a écrit :
Thanks for the tips. I scanned the dse.ldif for those plugins and I found
definitions for them all, but they all have nsslapd-pluginEnabled: off.
There is something
.
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/mailman/listinfo
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
==
--
389
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:
I would still like to know which parameters you set
On Apr 16, 2012, at 1:50 PM, Rich Megginson wrote:
I would still like to know which parameters you set and the values you used.
When I first tried this, the change log was set to unlimited, (the default),
and the purge delay was set to 7 days I think. I reduced the purge delay to
about 15
29 matches
Mail list logo
