Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it
raphael.ouazana(a)linagora.com wrote:
I see at least 2 issues in this patch:
1) the use of dnParent() in place on malloc'd data would lead to memory
corruption, because at some point the value of the set will be freed,
but the bv_val of that value would no longer point to the beginning of a
malloc()'ed block. You should rather use AC_MEMCPY() to move the
parent's DN at the beginning of the malloc()'ed memory block.
2) when trimming a set of DNs to some ancestor, DNs with common
ancestors could result in duplicate set values. I'm not sure this
currently has any adverse effect on set evaluation, but I'd consider it
bad anyway. You should eliminate duplicates, in case any arises.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 8 months
(ITS#4860) Sets' enhancement
by raphael.ouazana＠linagora.com
Full_Name: Raphael Ouazana
Version: HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/raphael-ouazana-070307.patch
Submission from: (NULL) (82.225.231.106)
Hi,
This patch creates a new operator for sets : /-
It allows to get the nth parent of all the elements of a set.
For example, if user is cn=user,ou=people,dc=example,dc=com :
user/-1 : resolves to set {ou=people,dc=example,dc=com}
user/-2 : resolves to set {dc=example,dc=com}
Of course it works the same for sets of more than 1 element.
It is very useful when ACLs depends on hierarchy.
Legal notice :
This patch file is derived from OpenLDAP Software. All of the modifications to
OpenLDAP Software represented in this following patch were developed by Raphael
Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to
any
license of Linagora.
The attached modifications to OpenLDAP Software are subject to the following
notice:
Copyright 2007 Raphael Ouazana, Linagora
Redistribution and use in source and binary forms, with or without
modification,
are permitted only as authorized by the OpenLDAP Public License.
16 years, 8 months
Re: (ITS#4857) Subtree accesslog support
by quanah＠stanford.edu
--On Wednesday, March 07, 2007 2:32 PM -0800 Quanah Gibson-Mount
<quanah(a)stanford.edu> wrote:
>
>
> --On Wednesday, March 07, 2007 2:28 PM -0800 Howard Chu <hyc(a)symas.com>
> wrote:
>
>>
>> ---- <quanah(a)stanford.edu> wrote:
>>> What I want to do, is put subtree based accesslog's on my replica
>>> servers. We have multiple downstream systems that pull data from the
>>> directory. This would allow them to "sit and listen" to the changes
>>> made in their subtrees of interest, using the syncrepl protocol.
>>
>> Uh huh. That's what search filters are for. If that's the only motivation
>> for this ITS, then we can close it right now.
>>
>> ldapsearch -b cn=log
>> (reqDN:dnsubtreematch:=ou=accounts,dc=stanford,dc=edu)
>
> That doesn't do a never ending search that catches every write as it
> occurs.
Although I guess a syncrepl search could use the filter ;)
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
16 years, 8 months
Re: (ITS#4857) Subtree accesslog support
by quanah＠stanford.edu
--On Wednesday, March 07, 2007 2:28 PM -0800 Howard Chu <hyc(a)symas.com>
wrote:
>
> ---- <quanah(a)stanford.edu> wrote:
>> What I want to do, is put subtree based accesslog's on my replica
>> servers. We have multiple downstream systems that pull data from the
>> directory. This would allow them to "sit and listen" to the changes
>> made in their subtrees of interest, using the syncrepl protocol.
>
> Uh huh. That's what search filters are for. If that's the only motivation
> for this ITS, then we can close it right now.
>
> ldapsearch -b cn=log
> (reqDN:dnsubtreematch:=ou=accounts,dc=stanford,dc=edu)
That doesn't do a never ending search that catches every write as it occurs.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
16 years, 8 months
Re: (ITS#4857) Subtree accesslog support
by hyc＠symas.com
---- <quanah(a)stanford.edu> wrote:
> What I want to do, is put subtree based accesslog's on my replica servers.
> We have multiple downstream systems that pull data from the directory.
> This would allow them to "sit and listen" to the changes made in their
> subtrees of interest, using the syncrepl protocol.
Uh huh. That's what search filters are for. If that's the only motivation for this ITS, then we can close it right now.
ldapsearch -b cn=log (reqDN:dnsubtreematch:=ou=accounts,dc=stanford,dc=edu)
-- Howard Chu
Chief Architect, Symas Corp. Director,
Highland Sun
http://www.symas.com
http://highlandsun.com/hyc
Symas: Premier OpenSource Development and
Support
16 years, 8 months
Re: (ITS#4857) Subtree accesslog support
by quanah＠stanford.edu
--On Wednesday, March 07, 2007 5:09 PM +0000 Frank.Swasey(a)uvm.edu wrote:
> This is a cryptographically signed message in MIME format.
>
> --------------ms050409020803020407000508
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
> On 3/6/07 6:31 PM, quanah(a)stanford.edu wrote:
>> I was looking at adding access log configurations to my main database
>> that would log operations based on subtree. For example, I'd like to
>> have all operations on "cn=accounts,dc=stanford,dc=edu" go into one
>> accesslog, and operations on "cn=people,dc=stanford,dc=edu" go into
>> another accesslog. My root is "dc=stanford,dc=edu". There doesn't seem
>> to be a way with the way accesslog is currently designed to do this. I
>> believe it would be a useful feature.
>
> I have wished for a similar capability. However, have always been
> stopped from proceeding to look at modifying the code because all my
> consumers need to replicate the full database.
>
> However, it would be nice to be able to break things apart and have
> them expire out of the accesslog at different times. For instance, our
> sendmail spam blocking rules live for a max of several hours and so I
> could expire those from the accesslog after 8 hours, but the core
> (people, groups, accounts) I'd like to keep for a couple days to make
> certain they get to the replica servers.
>
> Is that the same kind of thing you are thinking of Quanah?
Hi Frank,
Actually, no, it isn't. ;)
What I want to do, is put subtree based accesslog's on my replica servers.
We have multiple downstream systems that pull data from the directory.
This would allow them to "sit and listen" to the changes made in their
subtrees of interest, using the syncrepl protocol.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
16 years, 8 months
Re: (ITS#4857) Subtree accesslog support
by hyc＠symas.com
Frank.Swasey(a)uvm.edu wrote:
> This is a cryptographically signed message in MIME format.
>
> --------------ms050409020803020407000508
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
> On 3/6/07 6:31 PM, quanah(a)stanford.edu wrote:
>> I was looking at adding access log configurations to my main database that would
>> log operations based on subtree. For example, I'd like to have all operations
>> on "cn=accounts,dc=stanford,dc=edu" go into one accesslog, and operations on
>> "cn=people,dc=stanford,dc=edu" go into another accesslog. My root is
>> "dc=stanford,dc=edu". There doesn't seem to be a way with the way accesslog is
>> currently designed to do this. I believe it would be a useful feature.
>
> I have wished for a similar capability. However, have always been
> stopped from proceeding to look at modifying the code because all my
> consumers need to replicate the full database.
Usually when you have a logging requirement, you need to see everything...
Breaking out options by subtree does seem to be a pretty common need
though. It strikes me that we need to solve this once, generically,
instead of doing it over and over again in each overlay. That sounds an
awful lot like getting full subentry support implemented, or at least a
generic subtree search specification handler.
> However, it would be nice to be able to break things apart and have
> them expire out of the accesslog at different times. For instance, our
> sendmail spam blocking rules live for a max of several hours and so I
> could expire those from the accesslog after 8 hours, but the core
> (people, groups, accounts) I'd like to keep for a couple days to make
> certain they get to the replica servers.
>
> Is that the same kind of thing you are thinking of Quanah?
>
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/
16 years, 8 months
Re: (ITS#4858) sasl_client_init Problem
by hyc＠symas.com
The OpenLDAP ITS is for tracking issues in OpenLDAP software. Your
problem appears to be in a package produced by someone else; you should
contact whoever provided that package for support. We have no way of
knowing what build or configuration options someone else used to create
their package, so we cannot track down problems in their package.
Note that OpenLDAP 2.1 was moved to Historic status a number of years
ago. You should consider using a more recent version. Symas Corporation
provides professional support for OpenLDAP 2.3 packaged for HPUX and
many other platforms.
m.birkenkamp(a)e-fact-gmbh.de wrote:
> Full_Name: Marcel Birkenkamp
> Version: 2.1.22
> OS: HP UX 11.11
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (84.63.24.153)
>
>
> Hi,
>
> i have a Problem, i've implemented a c program using OpenLDAP to connect to an
> ActiveDirectory for uservalidation, the Problem is that whenever i use one of
> the OpenLDAP functions (i.e. ldap_init, ldap_initialize) i get the following
> error: "/usr/lib/dld.sl: Unresolvable symbol: sasl_client_init (code) from
> /opt/iexpress/openldap/lib/libldap.sl - IOT trap". I've reinstalled OpenLDAP but
> the Problem persists.
> Does anyone have an idea what might be causing this or how i can find out where
> this Problem originates?
>
> thanks in advance
>
> Marcel
>
>
> .
>
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/
16 years, 8 months
Re: (ITS#4857) Subtree accesslog support
by Frank.Swasey＠uvm.edu
This is a cryptographically signed message in MIME format.
--------------ms050409020803020407000508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 3/6/07 6:31 PM, quanah(a)stanford.edu wrote:
> I was looking at adding access log configurations to my main database that would
> log operations based on subtree. For example, I'd like to have all operations
> on "cn=accounts,dc=stanford,dc=edu" go into one accesslog, and operations on
> "cn=people,dc=stanford,dc=edu" go into another accesslog. My root is
> "dc=stanford,dc=edu". There doesn't seem to be a way with the way accesslog is
> currently designed to do this. I believe it would be a useful feature.
I have wished for a similar capability. However, have always been
stopped from proceeding to look at modifying the code because all my
consumers need to replicate the full database.
However, it would be nice to be able to break things apart and have
them expire out of the accesslog at different times. For instance, our
sendmail spam blocking rules live for a max of several hours and so I
could expire those from the accesslog after 8 hours, but the core
(people, groups, accounts) I'd like to keep for a couple days to make
certain they get to the replica servers.
Is that the same kind of thing you are thinking of Quanah?
--
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)
--------------ms050409020803020407000508
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJDzCC
AuIwggJLoAMCAQICEAq9rKiduK3HCbKzsBiBodUwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDcxNzE2NTcyNloX
DTA3MDcxNzE2NTcyNlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEG
CSqGSIb3DQEJARYURnJhbmsuU3dhc2V5QHV2bS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQCzhSmesaR8qf2y5cNt0qa27m42Kq3Bwubs28CzSxR1uRUaRZUfL/C2FEFV
kKSat6da5b19UEWxM1giaWvLeDtQE5Tok8GhN8LNgScTiSEM6gFWnL0o7A9W7oAj42dfFvBV
md7/u7nSJoAP3Wt9cU3TBJBh99U89EzIYLNik8iVhzbwfNmisxmuR5870AHURoR1sN/X4jWx
q5114Rv8r60+bVitlXL7P20Z2S9+va9+a7+C1P/yJLPq1GK8+X9uaoUaGHlapBeBYNu3QWQG
Q+mF+QuidS01jbaburvJxUm7dVO3QRt1PovVhlidv89eqcH8n4h7xSG1IG3teNJkschdAgMB
AAGjMTAvMB8GA1UdEQQYMBaBFEZyYW5rLlN3YXNleUB1dm0uZWR1MAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAblV8ye5ZLs/y3DX0W3NU67N2T6tOSZ1609L+BRWB/Md7RDFd
Cm8AXFIldDLzkyPFqs9WpgAQLvZ0gRXQ8aqwYEBB3WlZzkpUS+YTuY6X9wjcroMjHCyWNpq0
/joDumCNSEWiZJ6AZMRom9Z/P6foBxXmgCBKVq/O0mGqgArlxdkwggLiMIICS6ADAgECAhAK
vayonbitxwmys7AYgaHVMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK
ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u
YWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjA3MTcxNjU3MjZaFw0wNzA3MTcxNjU3MjZa
MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFEZy
YW5rLlN3YXNleUB1dm0uZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs4Up
nrGkfKn9suXDbdKmtu5uNiqtwcLm7NvAs0sUdbkVGkWVHy/wthRBVZCkmrenWuW9fVBFsTNY
Imlry3g7UBOU6JPBoTfCzYEnE4khDOoBVpy9KOwPVu6AI+NnXxbwVZne/7u50iaAD91rfXFN
0wSQYffVPPRMyGCzYpPIlYc28HzZorMZrkefO9AB1EaEdbDf1+I1sauddeEb/K+tPm1YrZVy
+z9tGdkvfr2vfmu/gtT/8iSz6tRivPl/bmqFGhh5WqQXgWDbt0FkBkPphfkLonUtNY22m7q7
ycVJu3VTt0EbdT6L1YZYnb/PXqnB/J+Ie8UhtSBt7XjSZLHIXQIDAQABozEwLzAfBgNVHREE
GDAWgRRGcmFuay5Td2FzZXlAdXZtLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA
A4GBAG5VfMnuWS7P8tw19FtzVOuzdk+rTkmdetPS/gUVgfzHe0QxXQpvAFxSJXQy85MjxarP
VqYAEC72dIEV0PGqsGBAQd1pWc5KVEvmE7mOl/cI3K6DIxwsljaatP46A7pgjUhFomSegGTE
aJvWfz+n6AcV5oAgSlavztJhqoAK5cXZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF
ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw
ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh
dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X
DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV
c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J
8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I
BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f
BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h
aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl
TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU
nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d
qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw
ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB
AhAKvayonbitxwmys7AYgaHVMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMwNzE3MDkyMFowIwYJKoZIhvcNAQkEMRYEFO+D
/RPLcK9KWgTC5ESQ348qOn2BMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr
BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu
ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu
ZyBDQQIQCr2sqJ24rccJsrOwGIGh1TCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQCr2sqJ24rccJsrOwGIGh1TAN
BgkqhkiG9w0BAQEFAASCAQBWlKbCnxB4o7stfK+pDIAWxonGW8d4AKZr0IU/76SqFqlSQQAx
sBSrw2Dg+NHLPsTlBlqe6tseFGjg3EL2436XOY75dbResLsyVffIxE25bVu12P6TpXe6d4xv
B6/EvCxlJAjk0UP/ahjmxRCEofnPZybSfd2XIvgbfCstuV8U7ioJolTJZnTq4NhLcliSelyN
AjLuBLWGlQj7FxoP7I4KQruZftPu5GVgrj1gpYCUWG457agxEi8w/0mDPUh6gtp5wcN6t+NH
6lYkBoDgb1HuHCrg6Wq/PInNYIxipqcs2Ls7YtR2OpjVJry+8nGlw/N6ueZZWqdSFlQghAk2
xkDXAAAAAAAA
--------------ms050409020803020407000508--
16 years, 8 months
(ITS#4859) sasl_client_init Problem
by m.birkenkamp＠e-fact-gmbh.de
Full_Name: Marcel Birkenkamp
Version: 2.1.22
OS: HP UX 11.11
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (84.63.24.153)
Hi,
i have a Problem, i've implemented a c program using OpenLDAP to connect to an
ActiveDirectory for uservalidation, the Problem is that whenever i use one of
the OpenLDAP functions (i.e. ldap_init, ldap_initialize) i get the following
error: "/usr/lib/dld.sl: Unresolvable symbol: sasl_client_init (code) from
/opt/iexpress/openldap/lib/libldap.sl - IOT trap". I've reinstalled OpenLDAP but
the Problem persists.
Does anyone have an idea what might be causing this or how i can find out where
this Problem originates?
thanks in advance
Marcel
16 years, 8 months
