Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it
raphael.ouazana(a)linagora.com wrote:
> Fixing these issues, I saw that set_parent will be very similar to
> set_chase. Do you think I should create a new gatherer instead of ?
I don't see so much similarity: set_chase() is intended to use the
gatherer to fetch objects and extract a value from them, including
"closure" (recursion). Sublevel does not require fetching, and takes a
negative digit as extra argument, rather than an attribute type, so
you'd need to add an outer test before calling set_chase() anyway,
extend the interface of set_chase() to allow an AttributeDescription and
an integer, and so on, while you don't need any callback capability to
fetch an object or expand values or so. I'd keep it simple as it is now.
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
Re: (ITS#4864) -r option "redirects" to logfile, breaks replication
by ando＠sys-net.it
chris.eubank(a)gov.bc.ca wrote:
> Full_Name: Chris Eubank
> Version: 2.3.31 (Jan 7 2007 08:51:37)
> OS: Solaris 10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (142.32.230.251)
>
>
> If the -r option is used with the 'slurpd' daemon it breaks the replication
> function and sends the replication data to the specified logfile instead.
What does this mean? According to the documentation, -r must point to
slapd's replog file, namely the file where replications are logged by
the producer. Of course, if you point it to a file that is not a valid
replication log, the behavior will be unexpected.
> This behaviour is not documented in the manpage for slurpd.
Please describe what behavior you obtain and how it differs from
documented. Note that regular users are not supposed to use the -r
switch, since slurpd typically knows where to get the replog file.
Also, note that slurpd is deprecated; syncrepl should be used instead.
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
Re: (ITS#4857) Subtree accesslog support
by Frank.Swasey＠uvm.edu
This is a cryptographically signed message in MIME format.
--------------ms080906050304010303040408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 3/7/07 5:29 PM, 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.
If that's the only original motivation... then I'd like to hijack this
to get the ability to expire different subtree's out of the log at
different rates... can I do that?
--
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)
--------------ms080906050304010303040408
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
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMwOTE0MDYxMFowIwYJKoZIhvcNAQkEMRYEFCiK
6zalxLVu83Mrwb6GWBRfSXOYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr
BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu
ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu
ZyBDQQIQCr2sqJ24rccJsrOwGIGh1TCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQCr2sqJ24rccJsrOwGIGh1TAN
BgkqhkiG9w0BAQEFAASCAQCc8+iSw5QIRwppDoDmleLlwBqS/QpcRbyraKL58bvYQh2GFw+o
9W7fBsV7Kt6Vt4AqaWkn+5RZ4NqlIeOIzck/utkki59zSci3mcOUOZ0DHQsmWGmyiSPPohzN
CtupvRWo5viTrBr5fPAWeAiTlNfg4B2G3Ic81e2VPixWUScgLy8TlvFJmopH3yK64lqkAU7E
71L3SXe5n2ZB3O2WLsPtlVHTp9fo+AbU+/WYEMbpgR5vkAxYM6noOyhw3+W632b0hnKICtbP
6HGjZ7EZt1VyowOk95Q5x01EIo6wOBOAkOUQ/Ax+ZatZTosxpuFL87kMv1M+DuyQNzljK29V
GQwtAAAAAAAA
--------------ms080906050304010303040408--
16 years, 8 months
Re: (ITS#4862) Doxygen support
by ghenry＠suretecsystems.com
<quote who="ando(a)sys-net.it">
> Full_Name: Pierangelo Masarati
> Version: HEAD (almost irrelevant)
> OS: irrelevant
> URL: ftp://ftp.openldap.org/incoming/openldap-doxygen.tar.gz
> Submission from: (NULL) (81.72.89.40)
> Submitted by: ando
>
>
> I've updated a simple doxygen configuration file that allows to create a
> (hopefully) complete and useful browsable tree of OpenLDAP software. The
> current configuration is quite redundant, since it includes sources in the
> tree,
> and may take a while to process. It needs "doxygen" and "dot" (the latter
> can
> be disabled by setting HAVE_DOT to "no", if unavailable, at the expense of
> loosing the graphical description of relations between data types and
> files).
>
> To "install":
> - cd into the root of the source tree
> - untar openldap-doxygen.tar.gz
>
> this puts a couple .html files in doc/devel, and Doxyfile in the root of
> the
> source tree. Edit this to customize.
>
> Finally, run doxygen from the root of the source tree (and be patient).
>
> Documents will be installed in doc/source_html. Edit Doxyfile to
> customize.
> Enjoy.
>
> p.
Wow! That rules and looks great.
Brilliant work.
Thoughts on polishing this up and adding something to the main site with
an announcement sometime?
"OpenLDAP goes Doxygen" ;-)
Gavin.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
16 years, 8 months
(ITS#4862) Doxygen support
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version: HEAD (almost irrelevant)
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/openldap-doxygen.tar.gz
Submission from: (NULL) (81.72.89.40)
Submitted by: ando
I've updated a simple doxygen configuration file that allows to create a
(hopefully) complete and useful browsable tree of OpenLDAP software. The
current configuration is quite redundant, since it includes sources in the tree,
and may take a while to process. It needs "doxygen" and "dot" (the latter can
be disabled by setting HAVE_DOT to "no", if unavailable, at the expense of
loosing the graphical description of relations between data types and files).
To "install":
- cd into the root of the source tree
- untar openldap-doxygen.tar.gz
this puts a couple .html files in doc/devel, and Doxyfile in the root of the
source tree. Edit this to customize.
Finally, run doxygen from the root of the source tree (and be patient).
Documents will be installed in doc/source_html. Edit Doxyfile to customize.
Enjoy.
p.
16 years, 8 months
(ITS#4861) Issue with referrals in proxy backends
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version: re23 + patches from HEAD
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (131.175.154.35)
Submitted by: ando
I've received reports of issues with referrals returned from a third-party DSA
to OpenLDAP's proxy backends. Apparently, in some cases the response contained
referrals with a return code different from LDAP_REFERRAL. Although I can't
prove it (it seems to be non-deterministic), I've strenghtened the proxy
backends code so that it rejects those responses instead of sending them thru
send_ldap_result(), which triggers an assertion.
p.
16 years, 8 months
Re: (ITS#4860) Sets' enhancement
by raphael.ouazana＠linagora.com
On Jeu 8 mars 2007 01:00, Pierangelo Masarati wrote:
> 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.
Fixing these issues, I saw that set_parent will be very similar to
set_chase. Do you think I should create a new gatherer instead of ?
Regards,
Raphael Ouazana.
16 years, 8 months
