I wonder if it is possible to change an attribute syntax, in this case
"destinationIndicator" attribute. The cities in my country has special
characters (particulary ' ñ ') and the directory server mark the attribute
value with syntax violation.
In case of change possibility, how can I change it? Can this change
affect to another object/attribute?
I am adding a second DNS/IP to my directory server. Is there a way to
import a certificate and key into the directory that I've already
created and had signed by GeoTrust? It seems like certutil -A would add
this to the database. Has anyone done this, what format should I get
the get cert and key in?
i have 8 LDAP servers, what is the easiest method to move the
configuration server to another node?
i have ldap1,ldap2,ldap3,ldap4, and so on
atm ldap1 is the config server, but i want to cancel ldap1, and set
ldap2 to hold the information about the ldap server tree.
Will shut down ldap1 in a week or so.
Senior Systems Administrator
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 minutes. and about 10 minutes for the change log entry age. These were changed using the console and then the server was restarted. I'm not sure of this exactly because those settings were deleted when I deleted the replication agreement and stopped the changelogging.
>>>> The consumer has processed all updates and also seems to exhibit overconsumption of memory.
>>> Do you see any issue if you don't use replication at all? That is, is this issue related to replication?
>> Yes, I haven't seen it jump up all the way yet, but it is up to 13GB after only a few loops.
>> This was without replication enabled.
>> When I re-enabled replication just now to see if the excess entries would be replicated to the consumer, I see that thousands of entries are being sent over during consumer initialization. It just finished replicating and sent 7639 entries. There are only about 800 valid entries. Searching from the base suffix for all available current DN values on the master results in only "# numEntries: 855"
> I wonder if they are tombstone entries? Are you doing ldapdelete operations at all?
Could be. Yes, the entries are deleted using ldapdelete over a file of DN values. I was incorrect when I mentioned that I was using ldapmodify in this case.
I'm not very familiar with the concept of "tombstone" but I used dbscan to look over the id2entry file, and it contains all 7639 entries that were being sent over. If the tombstone issue is causing the server to hold onto duplicate entries, then maybe I just have to run deletions in a different way...
>> After restarting the master and doing another consumer initialization, there seems to remain a record of these excess entries and the consumer is being initialized with them even though the change log is currently empty at 16K.
> Consumer initialization does not use the changelog - it reads the entries directly from the database and sends them to the consumer.
>> Perhaps there is a problem with the way I am deleting and adding entries and they are being duplicated behind the scenes somehow??? I'm just using a db2ldif export of those entries and running ldapadd over that file...
>>>> Are there any pointers related to this?
>>> Are you seeing https://fedorahosted.org/389/ticket/51 ?
>>> When you start to see memory growth, are you using all of your cache?
>> I am not using MMR (pretty sure unless that came enabled by default), nor am I using GSSAPI.
>> The memory usage pushes well beyond the cache size.
> The thing about ticket 51 (not sure if it is in the ticket, perhaps it is in the linked bugzilla bug) is that the memory growth is only seen _if the entry cache is maxed out_. That is, if you are able to keep the entry cache max size well above the actual amount of data used, you do not see the memory growth. We have also run valgrind but have not seen any "real" memory leaks. Note that entries stored in the entry cache will be reported as "leaks" because we do not free the entry cache at shutdown. Our best guess for the memory growth issues in ticket 51 is that either there is a very subtle memory leak related to entry "churn" as entries are evicted and stored in the entry cache, or the memory fragmentation that results from that churn.
Initially, the entry cache was set to 12G, far in excess of the database in its reduced form.
>>>> If there is no information about this, is there a documentation page that might instruct me in the correct way to attach valgrind to the ns-slapd process so I can see if there is some kind of huge leak?
>>> AFAIK you can't attach valgrind to a running process.
>>> try this:
>>> service dirsrv stop
>>> ( . /etc/sysconfig/dirsrv ; . /etc/sysconfig/dirsrv-INSTANCENAME ; valgrind -q --tool=memcheck --leak-check=yes --leak-resolution=high --num-callers=50 --log-file=/var/log/dirsrv/slapd-INSTANCENAME/valgrind.log /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-INSTANCENAME -i /var/run/dirsrv/slapd-INSTANCENAME.pid -w /var/run/dirsrv/slapd-INSTANCENAME.startpid -d 0 ) &
>>> valgrind will log to /var/log/dirsrv/slapd-INSTANCENAME/valgrind.log
>>> Note that running your server with valgrind will really cripple the performance - may be unusable in a production environment - you may also run afoul of selinux
>>> valgrind will not report memory leaks until you shutdown the server (just kill -15 <pid of ns-slapd or valgrind>)
>> I'll give this a shot and see what happens.
>> Looks like we already have some kind of handle to the situation since the excess entries are already being reported by the entry caches.
> ? Not sure what you mean here.
This means that the server is creating and holding onto excess entries, and the server is reporting this fact. This would be a different type of leak than lost memory where valgrind would be needed to see.
>> Thanks so much for your advices!
I have been working with 389 as a potential replacement for Sun DS and I have found it to be an excellent choice in every aspect except the final tests I have been running.
I am running with the current version for RedHat 6, but not the latest from the rmeggins repo:
Name : 389-ds
Arch : noarch
Version : 1.2.2
Name : 389-ds-base
Arch : x86_64
Version : 18.104.22.168
I have searched through all the release notes and part of the 389-users list archive for clues as to the possible memory leaks and/or patches in the latest releases, but no information has been forthcoming.
The behavior I am seeing is a total memory consumption occurring over a large quantity of ldapmodify operations. To test this, I reduced the size of the directory from 10GB down to about 1.7GB. Then I set up a loop that would run an ldapmodify that would delete of most of those entries followed by an ldamodify that would add all those deleted back in (and then repeat indefinitely).
The directory starts out by loading all the entries into the cache and using a few GB of ram to hold everything. Eventually, this loop causes the entire 32GB of ram to be consumed even though the total size of the directory does not change (e.g. currententrycachesize: 1791096898).
Replication is enabled to a consumer and the change log is up to 7.4 GB, and it doesn't seem to want to clean out the change log even with short purge times and short entry lifetimes configured, so perhaps something is at issue here. The consumer has processed all updates and also seems to exhibit overconsumption of memory.
Are there any pointers related to this?
If there is no information about this, is there a documentation page that might instruct me in the correct way to attach valgrind to the ns-slapd process so I can see if there is some kind of huge leak?
Thanks very much,
Programmer Analyst IV
Enterprise Identity Management
University of Southern California
Hallo, i have strange problem. I setup sync betwen windows AD and 389-DS.
If I synchronize from cn=Users,cn=skola,cn=local (AD side) to ou=People,cn=skola,cn=local (389-DS side) everything works. It is mean, that users from AD (cn=Users,cn=skola,cn=local) are populated to 389-DS (ou=People,cn=skola,cn=local) correctly.
But I have a lot of users in AD in other organizational unit - CN=Students,dc=skola,dc=local.
When I setup Windows sync agreenment and change cn=Users,cn=skola,cn=local to CN=Students,dc=skola,dc=local and sync it to location ou=People,cn=skola,cn=local in 389-DS nothing is synced. Why?
I make object OU=Users in 389-DS directory tree and setup sync between cn=Users,cn=skola,cn=local (AD side) to ou=Users,cn=skola,cn=local (389-DS side). Nothing is synced...
Thanky you for your help.
What command can return the version number as listed
On the attached UI screens? Preferably the version corresponding to the release numbering as seen on web pages.
Right-click on the Server Group/Directory Server in the 389-console showed
Build number: 2011.244.2040
the 389-console's Help/About menu command showed
"About 389 Directory Server 1.2.6" in the popup dialog title
"Using Console Framework 1.1.7"
In the body of the dialog
We have noticed two problems in the multiimaster replication environment of 389-1.2.0 code base. Can you please provide any insight on these issues.
When the replica is modified (role change from HUB to Supplier), the replica id is updated from 65535 to newly given replica id in the dse.ldif file. But the RUV entry in the db/memory still having the old replica id (i.e 65535 ) instead of newly provided replica id .This caused the problem of supplier and consumer still having the old replica ID.
The reproducer details are given below:
1. Create the Supplier instance
2. From admin GUI , check "Enable Changelog" of Supplier Settings
3. Specify the location of update history log in "Replication Changelog"
4. Check "Enables Replica" of Replica Settings
5. Select "Hub" in Replica Role and click Save ---> nsDS5ReplicaId:65535 is added in dse.ldif file. // this is expected
6. Select "Single Master" in Replica Role and specify 13089 in ReplicaID box, and click Save. ---> nsDS5ReplicaId:13089 is added in dse.ldif file. // this is expected
7. Create the Consumer instance
8. Create the entry for Supplier DN (cn=replication manager,cn=config)
9. Specify the entry created at step #2 above for Supplier DN box in replication configuration.
10. Select "Dedicated Consumer" as the replica role, and click Save ---> nsDS5ReplicaId:65535 is added in dse.ldif file. // this is expected
11. Create replication agreement between Supplier and Consumer.
12. Initialize the Consumer in Supplier.
13. Search the replication infromation (RUV) in Supplier ---> no replica ID hit // This is normal
14. Search the replication information (RUV) in Consumer ---> no replica ID hit // This is normal
15. Add an entry for Supplier
16. Search the replication information (RUV) in Supplier ---> replica ID:65535 is hit // This is NOT normal. The replica id 13089 should be hit because of the step #6 above
// This as if the memory content is not change while dse.ldif is changed.
17. Search the replication information (RUV) in Consumer ---> replica ID:65535 is hit // This is NOT normal. // 13089 should be hit because of the step #6 above
// This as if the memory content is not change while dse.ldif is changed.
In the above setup we have noticed below issue also.
When we perform a MOD operation on supplier, Multiple MOD operations are logged in the access log for same modify operation (i.e single operation). For instance, the mod operation for uid=0060628 below was requested only once, but multiple MOD entries were logged in access log. And also modification update from Supplier to Consumer is taking around 10 min.
[02/Apr/2012:22:56:24 +0900] conn=84924065 op=68 MOD
[02/Apr/2012:22:56:24 +0900] conn=84924065 op=72 MOD
[02/Apr/2012:23:07:53 +0900] conn=84925508 op=1951 MOD
[02/Apr/2012:23:07:53 +0900] conn=84925508 op=2314 MOD
[02/Apr/2012:23:18:23 +0900] conn=84927516 op=69 MOD
[02/Apr/2012:23:18:23 +0900] conn=84927516 op=73 MOD
Thanks in Advance,