Michael Ströder
2015-06-26 08:10:52 UTC
HI!
I'm currently working on implementing a generic back-sock listener in Python
and two special instances of it. Mainly the current use-case is overlay usage
intercepting bind requests.
Of course I'd like to monitor the back-sock listeners (internal state like
counters etc.), probably via LDAP ideally with access control enforced by
slapd itself.
Accessing the monitoring data could be done via search operations but I'd like
to avoid mandating a generic "sockops search" overlay configuration just for
monitoring data because every search request would be passed to the external
listener even though the listener does not handle them (except for the
monitoring data).
I could add additional backends with own suffixes pointing to the same
back-sock listener. But having two or three separate listeners would require
configuring the same number of database sections. Also having to implement to
much access control in the database listeners is also not ideal.
It would be really nice if requests going to a back-sock listener configured
as overlay could be pre-filtered by slapd configuration.
Something like
sockops search
ldap:///cn=sock-listener-monitor,dc=example,dc=com??base?(objectClass=monitorSubEntry)
Would pass the search request only to the external listener of the search
operation matches all parameters in the given LDAP URL. This would be also
handy for other operations.
What do you think?
Ciao, Michael.
P.S.: These ITS would also improve back-sock (overlay) usage:
(ITS#8172) RFE: back-sock CONTINUE to get modified parameters
(ITS#8177) RFE: back-sock to receive controls
(ITS#8178) back-sock: Timeout to avoid locking
I'm currently working on implementing a generic back-sock listener in Python
and two special instances of it. Mainly the current use-case is overlay usage
intercepting bind requests.
Of course I'd like to monitor the back-sock listeners (internal state like
counters etc.), probably via LDAP ideally with access control enforced by
slapd itself.
Accessing the monitoring data could be done via search operations but I'd like
to avoid mandating a generic "sockops search" overlay configuration just for
monitoring data because every search request would be passed to the external
listener even though the listener does not handle them (except for the
monitoring data).
I could add additional backends with own suffixes pointing to the same
back-sock listener. But having two or three separate listeners would require
configuring the same number of database sections. Also having to implement to
much access control in the database listeners is also not ideal.
It would be really nice if requests going to a back-sock listener configured
as overlay could be pre-filtered by slapd configuration.
Something like
sockops search
ldap:///cn=sock-listener-monitor,dc=example,dc=com??base?(objectClass=monitorSubEntry)
Would pass the search request only to the external listener of the search
operation matches all parameters in the given LDAP URL. This would be also
handy for other operations.
What do you think?
Ciao, Michael.
P.S.: These ITS would also improve back-sock (overlay) usage:
(ITS#8172) RFE: back-sock CONTINUE to get modified parameters
(ITS#8177) RFE: back-sock to receive controls
(ITS#8178) back-sock: Timeout to avoid locking