Good Morning All,
I need to capture the following stats for a serving LDAP.
total_connections
bytes_sent
completed_operations
initiated_operations
referrals_sent
entries_sent
bind_operations
unbind_operations
add_operations
delete_operations
modify_operations
compare_operations
search_operations
write_waiters
read_waiters
I have switched on the monitor mode on LDAP but not sure how can I get these statistics from that.
Is there a way that I can capture these stats?
Many Thanks in advance!!
Regards
Rahul Manchanda ------------------------------------------------------------------------ ---------------------------------- Andes , Selfcare Platform Build Team tel: (+91) (20) 66018100 extn: 6178; e-mail: rahul.manchanda@bt.com
rahul.manchanda@bt.com wrote:
Good Morning All,
I need to capture the following stats for a serving LDAP.
total_connections
bytes_sent
completed_operations
initiated_operations
referrals_sent
entries_sent
bind_operations
unbind_operations
add_operations
delete_operations
modify_operations
compare_operations
search_operations
write_waiters
read_waiters
I have switched on the monitor mode on LDAP but not sure how can I get these statistics from that.
Is there a way that I can capture these stats?
You need to look for the operational attributes. Use the '+' attribute annotation to view them.
It's all quite well documented here: http://www.openldap.org/doc/admin24/monitoringslapd.html
On Tuesday, 20 April 2010 06:31:07 rahul.manchanda@bt.com wrote:
Good Morning All,
I need to capture the following stats for a serving LDAP.
total_connections
bytes_sent
completed_operations
initiated_operations
referrals_sent
entries_sent
bind_operations
unbind_operations
add_operations
delete_operations
modify_operations
compare_operations
search_operations
write_waiters
read_waiters
I have switched on the monitor mode on LDAP but not sure how can I get these statistics from that.
I use a perl script with Xymon/Hobbit, that collects all the relevant entries in RRD files, and also does some replication monitoring (but doesn't support MMR yet). The default graph only displays some of them:
http://staff.telkomsa.net/~bgmilne/xymon/ol/
Regards, Buchan
Thanks a lot.
But could you please send me the bb-openldap.pl as I am getting 403 forbidden error while accessing the link.
Many Thanks in advance.
Regards Rahul Manchanda ---------------------------------------------------------------------------------------------------------- Andes , Selfcare Platform Build Team tel: (+91) (20) 66018100 extn: 6178; e-mail: rahul.manchanda@bt.com Address: Tech Mahindra, Sharada Center, Erandwana Pune-4
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Tuesday, April 20, 2010 2:52 PM To: openldap-technical@openldap.org Cc: Manchanda,RK,Rahul,DKE C Subject: Re: Monitoring OpenLDAP Performance
On Tuesday, 20 April 2010 06:31:07 rahul.manchanda@bt.com wrote:
Good Morning All,
I need to capture the following stats for a serving LDAP.
total_connections
bytes_sent
completed_operations
initiated_operations
referrals_sent
entries_sent
bind_operations
unbind_operations
add_operations
delete_operations
modify_operations
compare_operations
search_operations
write_waiters
read_waiters
I have switched on the monitor mode on LDAP but not sure how can I get these statistics from that.
I use a perl script with Xymon/Hobbit, that collects all the relevant entries in RRD files, and also does some replication monitoring (but doesn't support MMR yet). The default graph only displays some of them:
http://staff.telkomsa.net/~bgmilne/xymon/ol/
Regards, Buchan
Hi Folks,
Please point me to the correct place to ask my query if this is not where I should be doing so.
History: We have a series of Drupal based web sites that we are working towards creating a single sign-on setup using LDAP and the Drupal LDAP modules. This all works fine and this is not a Drupal question. . .
We are in a department at a university where there is a centrally managed LDAP server that we can query against. We would like to allow some users of our who are not part of the university (they are not staff, students, or faculty) and the central IT guys do not want to add non-university members to their LDAP directory. Makes sense and is completely fair.
We thought that we would setup our own LDAP server to query against. We can set up Drupal to query multiple LDAP servers. So we could set it to request information from our LDAP server and if it does not find a match, then it can look to the university's server and return log in credentials.
Problem: Some of the users who are in the university's LDAP server may require to have other attributes assigned to them that only we are aware of. We do not want multiple accounts (ie userA on our server and userA on the university's server) just to assign more attributes to the user.
We thought that a translucent overlay in our LDAP server might be our solution, but it seems that we would not be able to create our own users on this server, but only assign the added attributes...
Question: Is there a way that we can setup an LDAP server to allow us to have our own accounts as well as look upstream to the master server and return log in credentials with some of our own attributes assigned if it does not find a local account? It would, of course, have to not allow log in if the account is not present in either server.
I also have some questions about setting up translucent overlay, but will leave these off until I know if I need it.
Thanks in advance for any suggestions, advice.
Cheers, Gervais
Hi Folks,
Please point me to the correct place to ask my query if this is not where I should be doing so.
History: We have a series of Drupal based web sites that we are working towards creating a single sign-on setup using LDAP and the Drupal LDAP modules. This all works fine and this is not a Drupal question. . .
We are in a department at a university where there is a centrally managed LDAP server that we can query against. We would like to allow some users of our who are not part of the university (they are not staff, students, or faculty) and the central IT guys do not want to add non-university members to their LDAP directory. Makes sense and is completely fair.
We thought that we would setup our own LDAP server to query against. We can set up Drupal to query multiple LDAP servers. So we could set it to request information from our LDAP server and if it does not find a match, then it can look to the university's server and return log in credentials.
Problem: Some of the users who are in the university's LDAP server may require to have other attributes assigned to them that only we are aware of. We do not want multiple accounts (ie userA on our server and userA on the university's server) just to assign more attributes to the user.
We thought that a translucent overlay in our LDAP server might be our solution, but it seems that we would not be able to create our own users on this server, but only assign the added attributes...
Question: Is there a way that we can setup an LDAP server to allow us to have our own accounts as well as look upstream to the master server and return log in credentials with some of our own attributes assigned if it does not find a local account? It would, of course, have to not allow log in if the account is not present in either server.
Setup: a) a local database b) another local database, with slapo-translucend
store in (a) local-only users; use (b) to add local attributes to remote users. Glue (a) and (b) together; for example,
# local users database hdb suffix "ou=local,dc=example,dc=com" subordinate # ...
# remote users with local attrs database hdb suffix "dc=example,dc=com" # ... overlay translucent # ...
Requests for "ou=local,dc=example,dc=com" will be dealt with locally; requests for "dc=example,dc=com" will be dealt with by both databases seamlessly, in a single operation.
p.
On Wed, Apr 21, 2010 at 6:43 AM, Buchan Milne bgmilne@staff.telkomsa.net wrote:
On Tuesday, 20 April 2010 15:44:36 rahul.manchanda@bt.com wrote:
Thanks a lot.
But could you please send me the bb-openldap.pl as I am getting 403 forbidden error while accessing the link.
Fixed.
cool , thanks
Thanks, Buchan
openldap-technical@openldap.org