openldap-bugs

openldap-bugs@openldap.org

1 participants
20955 discussions

Re: (ITS#4857) Subtree accesslog support
by hyc＠symas.com 07 Mar '07

07 Mar '07

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/

1 0

Re: (ITS#4858) sasl_client_init Problem
by hyc＠symas.com 07 Mar '07

07 Mar '07

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/

1 0

Re: (ITS#4857) Subtree accesslog support
by Frank.Swasey＠uvm.edu 07 Mar '07

07 Mar '07

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--

1 0

(ITS#4859) sasl_client_init Problem
by m.birkenkamp＠e-fact-gmbh.de 07 Mar '07

07 Mar '07

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

1 0

(ITS#4858) sasl_client_init Problem
by m.birkenkamp＠e-fact-gmbh.de 07 Mar '07

07 Mar '07

1 0

(ITS#4857) Subtree accesslog support
by quanah＠stanford.edu 06 Mar '07

06 Mar '07

Full_Name: Quanah Gibson-Mount Version: 2.3/2.4/HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) 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. --Quanah

1 0

Re: slapd segfaults with certain ACL's (ITS#4854)
by ando＠sys-net.it 06 Mar '07

06 Mar '07

hjensen(a)gmx.de wrote: > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 16384 (LWP 16160)] > 0x4043e049 in free () from /lib/libc.so.6 > (gdb) bt > #0 0x4043e049 in free () from /lib/libc.so.6 > #1 0x40069ef8 in ber_memfree_x () from /usr/lib/liblber-2.3.so.0 > #2 0x0809d4b6 in ch_free () > #3 0x080be84d in str2anlist () > #4 0x080ab33e in parse_acl () > #5 0x08070c5c in config_generic () > #6 0x0807b0f6 in config_set_vals () > #7 0x0807cdd9 in read_config_file () > #8 0x08075d1d in config_include () > #9 0x0807b0f6 in config_set_vals () > #10 0x0807cdd9 in read_config_file () > #11 0x0807667b in read_config () > #12 0x0806ffce in main () OK, then it should be fixed; you can pull servers/slapd/ad.c from the CVS under the OPENLDAP_REL_ENG_2_3 tag and rebuild. Note that this confirms that your schema is missing either or both the offending objectClasses mozillaAbPersonAlpha, evolutionPerson. Please test and feedback. 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 ------------------------------------------

1 0

Re: slapd segfaults with certain ACL's (ITS#4854)
by hjensen＠gmx.de 06 Mar '07

06 Mar '07

Hello, here the additional information: configure command line: ./configure --prefix=/usr \ --sysconfdir=/etc \ --libexecdir=/usr/sbin \ --localstatedir=/var/openldap \ --disable-nls \ --enable-debug \ --enable-syslog \ --with-threads \ --with-tls \ --with-cyrus-sasl \ --enable-spasswd \ --enable-dynamic \ --enable-ipv6 \ --enable-modules \ --enable-crypt \ --enable-rewrite \ --enable-ldbm \ --enable-ldbm-api=berkeley \ --enable-ldbm-type=btree \ --enable-bdb \ --enable-hdb \ --enable-ldap \ --enable-meta \ --enable-monitor \ --enable-dnssrv \ --enable-null \ --enable-perl \ --with-dyngroup \ --with-proxycache \ --enable-wrappers \ --enable-slurpd \ --enable-aci \ --enable-shared Backtrace of the segfault: (gdb) run Starting program: /ports/openldap/work/src/openldap-2.3.34/servers/slapd/.libs/slapd [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 16160)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 16160)] 0x4043e049 in free () from /lib/libc.so.6 (gdb) bt #0 0x4043e049 in free () from /lib/libc.so.6 #1 0x40069ef8 in ber_memfree_x () from /usr/lib/liblber-2.3.so.0 #2 0x0809d4b6 in ch_free () #3 0x080be84d in str2anlist () #4 0x080ab33e in parse_acl () #5 0x08070c5c in config_generic () #6 0x0807b0f6 in config_set_vals () #7 0x0807cdd9 in read_config_file () #8 0x08075d1d in config_include () #9 0x0807b0f6 in config_set_vals () #10 0x0807cdd9 in read_config_file () #11 0x0807667b in read_config () #12 0x0806ffce in main () Regards, Henry

1 0

Re: (ITS#4856) Back-SQL + Subtree search hits 'assert(0)'
by ando＠sys-net.it 05 Mar '07

05 Mar '07

Kevin Vargo wrote: > Hi Pierangelo, Please keep replies in CC to the ITS system. > Thanks for the quick response. I just want to make sure I understand: you're saying that removing the assertion (as I did) is the correct solution? Well, removing the assert(0) prevents the crash; the right fix is to disallow the "subtree shortcut" in slapd.conf (slapd-sql(5)), which causes the extra filtering on the DN to take place, so no false hits show up. But yes, the assert(0) was overparanoid, and I removed it from the code. 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 ------------------------------------------

1 0

Re: (ITS#4856) Back-SQL + Subtree search hits 'assert(0)'
by ando＠sys-net.it 05 Mar '07

05 Mar '07

vargok(a)yahoo.com wrote: > Full_Name: K Vargo > Version: 2.3.32 > OS: Linux (RH-EL4) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.237.233.195) > > > Given a Base-DN, Subtree scoped ldapsearch, while the database contains > non-DN-matching items runs up against the 'assert(0)' in Back-SQL/search.c > +2186. > > Based on how the selection works, there doesn't appear to be a reason for the > assertion. The FIXME does not indicate WHY the dnIsSuffix should never fail: > the comparison in dnIsSuffix tries to compare incompatible-dn records and fails > -- as it should. > > Removing the assertion provides for the expected behavior in my simple case. > Basically, it appears that a Base-DN is not being pre-filtered by the Back-SQL > selection search, so it needs to be filtered by the dnIsSuffix check. > > While I could certainly see that my metadata is not correct (stock metadata from > 2.3 + changes from 200511/msg00504.html) I'm not sure an assert(0) is > appropriate. > > Additionally, there's no indication that back-sql can't support data with > multiple DNs. Actually, your assumption is partially incorrect, since back-sql doesn't do prefiltering of the DN if the search is rooted at the database's suffix (it's called the "subtree shortcut") unless you tell it otherwise, by using "use_subtree_shortcut no" (the docs state it's the default; this is wrong). I admit assert(0) there is a bit too strong, but I believe it was put there to catch this type of problems. I think the "right" solution, apart from fixing the docs, consists in removing the assertion. 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 ------------------------------------------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs