Full_Name: Fawad Lateef Version: 2.4.10 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/fawadlateef-contrib-updopstoweb-080714.tgz Submission from: (NULL) (202.133.78.60) Contributing an overlay which submits modification in LDAP to a web-page through libcurl. Description: ------------ This package contains a slapd overlay, updopstoweb, that provides support for monitoring add/modify/delete operations performed on LDAP and sends the information related to operation going to be performed on LDAP to a web-site through libcurl api. It also provides support for specifying an IP address which will not be monitored, e.g. if you want to monitor operations from remote system then you can specify local-host IP and then it will ignore local-host operations. Monitoring of operations is based on dn, attributes and object classes which are provided through entries in slapd.conf file. Web-site URL and IP address for ignoring operations from are also provided to overlay through slapd.conf file. Although all these parameters can be provided at run-time through back-config. The overlay is tested on openldap-2.4.10 although it can work on any version of openldap-2.4 For details please consult README provided in the package
moved from Incoming to Contrib
fawadlateef@gmail.com wrote: > Contributing an overlay which submits modification in LDAP to a web-page through > libcurl. Thanks for the contribution. Without having looked too much into the solution you designed, however, I believe you moved too much effort at the DSA side. An alternative approach to your problem consists in using the RFC4533 LDAP Sync to design a client that is persistently returned any change in data matching a search request, letting the client adapt the results into the desired form for the web page. The client could be easily embedded in a web server, e.g. using the scripting capabilities that most web servers have, or even coded using those scripting capabilities, provide they support the capability to implement the LDAP extensions used by RFC 4533. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando@sys-net.it -----------------------------------
ando@sys-net.it wrote: > fawadlateef@gmail.com wrote: > >> Contributing an overlay which submits modification in LDAP to a web-page through >> libcurl. > > Thanks for the contribution. Without having looked too much into the > solution you designed, however, I believe you moved too much effort at > the DSA side. An alternative approach to your problem consists in using > the RFC4533 LDAP Sync to design a client that is persistently returned > any change in data matching a search request, letting the client adapt > the results into the desired form for the web page. The client could be > easily embedded in a web server, e.g. using the scripting capabilities > that most web servers have, or even coded using those scripting > capabilities, provide they support the capability to implement the LDAP > extensions used by RFC 4533. Actually, even without RFC4533, all that's needed is to use slapo-accesslog and let the web server query the log DB whenever a user accesses the page. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Monday, July 14, 2008 9:04 PM +0000 hyc@symas.com wrote: > ando@sys-net.it wrote: >> fawadlateef@gmail.com wrote: >> >>> Contributing an overlay which submits modification in LDAP to a >>> web-page through libcurl. >> >> Thanks for the contribution. Without having looked too much into the >> solution you designed, however, I believe you moved too much effort at >> the DSA side. An alternative approach to your problem consists in using >> the RFC4533 LDAP Sync to design a client that is persistently returned >> any change in data matching a search request, letting the client adapt >> the results into the desired form for the web page. The client could be >> easily embedded in a web server, e.g. using the scripting capabilities >> that most web servers have, or even coded using those scripting >> capabilities, provide they support the capability to implement the LDAP >> extensions used by RFC 4533. > > Actually, even without RFC4533, all that's needed is to use > slapo-accesslog and let the web server query the log DB whenever a user > accesses the page. -- Along Pierangelo's answer, I'll note that Net::LDAPapi perl module can be an LDAP sync client, and thus used to drive any number of things based off changes made to an accesslog DB. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Thanks for your replies. By looking at RFC4533 AND slapo-accesslog I __don't__ think they can be used against what my contributed overlay can do. The overlay actually monitors add/delete/modify operations based on attributes/dn/classobject and if they matches it triggers event to the URL (like interrupt). Now the thing is: in our case, the web-page is not used to display modifications to users or on the browser __rather__ it perform some operations on other enterprise applications based on the event triggered from LDAP overlay hence polling kind of mechanism can't work for us. We are going to use this overlay in our open-source-product "Zivios - Open Source Enterprise Management". Zivios will be used for management of all enterprise applications (like OpenLDAP, Kerberos, Mail-Server, Network Time Server etc) from a single web-based panel, so all modifications done through Zivios on LDAP will be made/reflected on other applications/servers at the same time. Now if somebody perform some operation on OpenLDAP directly (means by skipping Zivios) then Zivios should be triggered for such a change and then it can act on other servers accordingly. Thus event received by Zivios is __not__ for displaying data; rather its for doing some background processing although this overlay can be used to display LDAP operations on web too. Please suggest me someother way which can work on scenario mentioned above if my overlay isn't good enough. Let me know if overlay name or description isn't clear and is creating misundestanding about the functionality of the overlay. -- Fawad Lateef
--On Tuesday, July 15, 2008 6:43 AM +0000 fawadlateef@gmail.com wrote: > Thanks for your replies. > > By looking at RFC4533 AND slapo-accesslog I __don't__ think they can > be used against what my contributed overlay can do. > > The overlay actually monitors add/delete/modify operations based on > attributes/dn/classobject and if they matches it triggers event to the > URL (like interrupt). The accesslog DB writes out to the database add/delete/modify events, which logs attributes/dn/objectclasses. You could use any ldap sync listener to react to those, and do whatever it is you choose to have it do. This is exactly what Stanford University has used Net::LDAPapi to do, where it watches for group membership changes, and then performs actions on other enterprise applications based on those changes. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
fawadlateef@gmail.com wrote: > > By looking at RFC4533 AND slapo-accesslog I __don't__ think they can > be used against what my contributed overlay can do. Judging from your description using syncrepl is __exactly__ what you need. Especially since some HTTP requests might get lost. > Now the thing is: in our case, the web-page is not used to display > modifications to users or on the browser __rather__ it perform some > operations on other enterprise applications based on the event > triggered from LDAP overlay hence polling kind of mechanism can't work > for us. Use syncrepl's refreshAndPersist mode. Also write your sync component in such a fashion that if connection is down for some times you can catch up with changes happened in between. Ciao, Michael.
functionality already provided via other methods