[EMAIL PROTECTED] writes:
As I recall, the only reason we needed the waking counter here was to
make sure we never filled the pipe buffer, which would cause a
single-threaded server to deadlock. We can simply set the pipe to
nonblocking instead, and eliminate the counter.
Sounds good...
The
Note: This ITS need not hold up 2.4.7; the tests fail in 2.4.6 too.
I wrote:
./run -b ldif test004-modify gets noSuchObject when it attempts to
delete cn=James A Jones 2,ou=Information Technology Division,
ou=People,dc=example,dc=com.
The same happens in test008-concurrency. The ldapsearch
[EMAIL PROTECTED] writes:
There are lots of existing ways of searching an admin guide.
First, most web search engines can be told to localize their search to
a set of pages. For instance:
http://www.google.com/search?q=site:www.openldap.org/doc/admin24+rwm
Not everyone knows how to do
If the clients and servers are on the same machine, the servers
could listen to 'ldapi://URL-escaped unique socket path'
instead of to 'ldap://host:unique port/'. E.g. the users could
use 'ldapi://escape $HOME/ldapi' or '%2Ftmp%2Fldapi%2Fescape $USER'.
However you'd need to upgrade OpenLDAP
Full_Name: Hallvard B Furuseth
Version: HEAD
OS: Linux
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
./run -b ldif test034-translucent crashes in str2entry2() at:
entry.c:298:if( ad_prev-ad_type-sat_equality
because ad_prev == NULL - which got through due to
I wrote:
I think setkey() is more readable than setkey_x(). If anything,
it already has too many arguments to be very readable.
Er, I meant the old setkey(), with fewer arguments:-) Oh well,
it doesn't matter greatly either way. Unless - do we care about
binary compatibility with 2.4.7
[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
As a followup, I should point out that this behaviour worked in at least
2.2 and 2.3.
Yes, I recall changing this in the 2.4 code; I guess I didn't update
the manpage.
Not sure which of this discussion should go where - I saw it first in
the
Howard Chu writes:
Hm... Where were you when we were originally discussing these changes?
http://www.openldap.org/lists/openldap-devel/200611/msg00013.html
http://www.openldap.org/lists/openldap-devel/200611/msg00022.html
Absent. I did look at it though, but I didn't realize how far the
I wrote:
As far as I can tell Logschema doesn't support full LDIF modify though.
reqMod is unordered, so one cannot make two modifications to the same
attribute. E.g. delete: foo followed by replace: foo.
Sorry, followed by add: foo makes more sense. E.g.
delete sn: chu
addsn: Chu
--
Howard Chu writes:
Hallvard B Furuseth wrote:
Changing the -devel thread's example a bit, I'd say 2.3 accepted one
dangerous bug, one unambigious but possibly misleading format (a modify
record both with and witout add/delete/replace: attribute lines), and
one safe format (changetype: modify
Thinking a bit more... I wrote:
But I agree those attribute names make things icky.
Attributes named add/delete/replace are not the only problem
cases. A program which generates LDIF must also take care with
attributes named control and changetype. And with OpenLDAP,
increment. Which may be a
Full_Name: Hallvard B Furuseth
Version: HEAD, RE24
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
ldapsearch rev 1.241 allow continuous mode introduced one bug and one
probably-byg:
* ldapsearch -f/dev/null returns an uninitialized value 'rc'. Fixing.
* last instead
[EMAIL PROTECTED] writes:
The query ((sn=XX*)(givenName=*))can not find the entry below.
Does it help to stop slapd, run sbin/slapindex, and restart slapd?
You need to do that if you edit slapd.conf's index statements,
and possibly when you upgrade.
--
Hallvard
Full_Name: Hallvard B Furuseth
Version: HEAD, RE24
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
overlays/dyngroup.c:dgroup_cf() has some strange LDAP_MOD_DELETE code:
app = (adpair **)on-on_bi.bi_private;
for (...; ...; ..., app = ap-ap_next) {
ap =
[EMAIL PROTECTED] writes:
(...) There are tons of (sysadmin side) ways to make
sure the right library is loaded, so I vote against supporting this
feature. Of course, I'm fine about documenting that --with-uniquename
is not supported.
configure should in any case check for
Howard Chu writes:
The outcome of the original discussion, which Kurt again reminded me
of today, was that ldapmodify should quit its guessing games and just
accept valid LDIF input.
All I see in the -devel discussion is about bugs in the parser. I see
nothing about removing the default
[EMAIL PROTECTED] writes:
It is now fixed in HEAD; please test. Please, also check and test for
any side-effect introduced by the fix, as it impacts all calls to
str2entry (many, I believe).
Tested, works fine so far. Haven't looked much for those side effects
though. Would need to dig in
Full_Name: Hallvard B Furuseth
Version: HEAD
OS: Linux
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
back-relay's be_extended could send a result, but be_extended should
only set/return it and leave it to the frontend to send it.
Just fixed by Pierangelo.
Looking at the
Full_Name: Hallvard B Furuseth
Version: HEAD
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
I'll be upgrading back-null a bit. At the moment just support for
Back-config, Modify-Increment Extension and empty rootpw.
Maybe grow it to a useful template of a nontrivial
Full_Name: Hallvard B Furuseth
Version: HEAD
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
If a referral object's ref DN differs from the entry DN, and
you update a subordinate of the referral object, the DN part
of the referral from back-bdb is wrong.
bash$ cat
I wrote:
!be_issuffix( op-o_bd,op-o_req_ndn )
which looks to me like a test for whether this function is _not_ to be
called for this database.
No, that's a test if the DN is the exact suffix, not if it has the
suffix. Anyway, for what it's worth make test succeeds with an
assert(0)
Other bugs:
* be-be_chk_referrals:
back-bdb and back-ldif can send errors from be-be_chk_referrals.
As far as I can tell that is wrong:
It should return an LDAP result code, but only send it if it is
LDAP_REFERRAL. backend_check_referrals() will send other errors,
and success means
Full_Name: Hallvard B Furuseth
Version: HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (129.240.203.232)
Submitted by: hallvard
back-config crashes if I delete some attribute, even some which
does not exist, and then olcAttributeOptions:
bash$ cat slapd.conf
[EMAIL PROTECTED] writes:
The slapd/modrdn.c check for affectsMultipleDSAs is insufficient, it
requires newSuperior to be in the same backend. That does not catch
moving cn=x,cn=y to another database's suffix cn=z,cn=y.
I don't see how it can miss this.
It checks if newSuperior is in
[EMAIL PROTECTED] writes:
Probably should look at adding the dest_dn to the op struct, so each
backend doesn't have to rebuild it.
Third-party overlays which modify newrdn or newSuperior would become
incorrect, so maybe this change should wait for OpenLDAP 2.5.
--
Hallvard
Ralf Haferkamp writes:
There are multiple ways to fix this, I guess. I am not sure which one
to take:
1. Make slap_mods_opattrs() create a LDAP_MOD_ADD operation, when the
attributes don't exist in the entry.
It'd be better to fix bconfig's LDAP_MOD_REPLACE. That should work
like
[EMAIL PROTECTED] writes:
slapadd: schema_init.c:3669: csnNormalize: Assertion `val-bv_len ==
(sizeof(mmddHHMMSS.uuZ#SS#SID#ss)-1)' failed.
That assert() was added to trap incorrect values, since they should
never happen run-time.
Bad idea. slapd crashes if you search for
[EMAIL PROTECTED] writes:
Specifically, the workaround is to compile the code with the upstream
libtool instead of with Debian's libtool, since upstream libtool
imports all module symbols into the global namespace. Debian's
libtool has been modified to not do this because it causes all sorts
[EMAIL PROTECTED] writes:
There are more ways (than slapindex) to break file ownership.
There is, and we should probably also do that, but slapindex is far and
away the most common and it would be cool if we could catch the problem
before it happens instead of just warning afterwards.
[EMAIL PROTECTED] writes:
# TRY TO SOLVE ISSUES ?
threads 32
idletimeout 30
You are likely making your problem worse by increasing the number of
threads. I always advise a setting of threads 8 in a high read,
low-to-medium write scenario. The more threads you have, the worse
Full_Name: Hallvard B Furuseth
Version: RE23
OS: Linux
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
/configure \
--disable-dynamic --disable-aci --enable-crypt --enable-lmpasswd \
--enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers \
--enable-backends
[EMAIL PROTECTED] writes:
When slapcat is writing it's output to disk, it ignores any errors
(with slapcat -l output_file or slapcat output_file). If an error is
encountered, such as No space left on device, slapcat then exits
normally with a return code of 0.
Eh. API design bug.
Full_Name: Hallvard B Furuseth
Version: HEAD, RE23, RE24
OS: Linux
URL: http://folk.uio.no/hbf/OpenLDAP/back-ldif.c
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
Here are a bunch of back-ldif bugs some questions. I have code for most
of it, but need advice/discussion on
Full_Name: Hallvard B Furuseth
Version: HEAD, RE23, RE24
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
A somewhat belated ITS: ldapadd of
dn: o=foo
objectClass: organization
complains that naming attribute 'o' is not present in entry.
RFC 2251 required this, but
Full_Name: Hallvard B Furuseth
Version: HEAD, RE23, RE24
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
Some slapd source files include libldap/ldap-int.h, which contains
#ifdef LDAP_R_COMPILE
in structs. slapd links libldap_r but does not define
Pierangelo Masarati writes:
Patched in HEAD; please test. p.
test.conf:
include servers/slapd/schema/core.schema
databasebdb
suffix o=foo
directory /tmp/db
test.ldif:
dn: o=foo
objectClass: organization
$
Rein Tollevik writes:
On Tue, 18 Mar 2008, Hallvard B Furuseth wrote:
(...)
short is signed by definition.
More the good reason why it should be cast to an unsigned then, as
that is what htons() expects.
Yup.
No, I don't have a test case. This is a fairly insignificant bugfix I
commited
[EMAIL PROTECTED] writes:
overlays/dynlist.c lines 371-376 sets REP_ENTRY_MUSTBEFREED in rs-sr_flags
without duplicating the entry, if REP_ENTRY_MODIFIABLE was set.
Thus the entry gets freed twice. Breaks test044-dynlist with back-ldif.
Actually obeying rs-sr_flags seems to be a more general
Pierangelo Masarati writes:
Hallvard B Furuseth wrote:
But I don't see how the be_release() code can work now. It sounds like
be-be_release() functions must check (how?) that the entry was created
by 'be', and otherwise pass it on to the next overlay/backend or
otherwise to entry_free().
[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
The database backend back_perl expects LDIF entries beginning with
dn: and ending with an empty line. (...)
Wrong. (...) all records must end with LF or CR/LF.
You two seem to be saying the same thing: An entry should end with a
line
Full_Name: Hallvard B Furuseth
Version: HEAD, 2.3, 2.4
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
back-bdb/add.c has several code paths where the parent entry
p is not released - it does goto return_results; without
first doing
if ( p p != slap_entry_root )
Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE).
I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though.
(For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if
and only if rs.sr_entry-e_private != NULL. Which is possibly true with
back-bdb
[EMAIL PROTECTED] writes:
bdb_unlocked_cache_return_entry_r(bdb-bi_cache, p );
(...)
Releasing entries is somewhat irrelevant, since all locks are released when
the transaction commits. Note that this function is a no-op in proto-bdb.h.
All of those statements are just relics from
[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
- back-ldif escapes the directory separator as \hex value. But
Windows uses \ as directory separator, so that doesn't help. It
needs another escape character.
To avoid double hex-escaping of DNs that contain \, we can
[EMAIL PROTECTED] writes:
attributetype ( 1.3.6.1.4.1.22558.2.1.1
NAME 'o4vdescription'
DESC 'RFC2256: descriptive information'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
)
If I leave out
Full_Name: Hallvard B Furuseth
Version: HEAD, RE23, RE24
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
slap_send_ldap_result() does not initialize rs-sr_tag and
rs-sr_msgid if rs-sr_err == SLAPD_ABANDON || op-o_abandon.
It does call send_ldap_response() which calls
Howard Chu writes:
[EMAIL PROTECTED] wrote:
Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE).
I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though.
(For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if
and only if rs.sr_entry-e_private
[EMAIL PROTECTED] writes:
OK, reverted the trylock (which was put there in rev 1.376). I
unfortunately don't remember what prompted that commit; certainly
there was no ITS associated with it.
It was committed 9 minutes before this message:
Not a bug. A search which dereferences aliases, checks the filter
against the _aliased_ entry, not against the _alias_ entry.
So, try ldapsearch -a always uid=wilfinge.
--
Hallvard
[EMAIL PROTECTED] writes:
Sorry for the noise - I would've started on the mailing list, but
I was given erroneous advise on howto achive a goal - and after
reading the relevant rfc - thought it might indeed do what I wanted.
Definitely take this to a mailinglist. openldap-technical, I guess.
On Thu, April 17, 2008 02:12, Howard Chu wrote:
fails on test005
Did before too, I think. Probably can´t test this week, sorry.
The full patch is... closer to allowing work on a full ./run -b ldif all.
[EMAIL PROTECTED] writes:
Although I don't see any particular issue in implementing this
enhancement, ldap* tools are essentially intended to implement the basic
LDAP features at the operation level.
True, ldapdelete -r is a bit of an aberration in that regard.
You can easily obtain what
Full_Name: Hallvard B Furuseth
Version:
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
I suggest the Issue Tracking link on on http://www.openldap.org is
renamed to Bugs or Bugs/patches. A user problem is after all an
issue too, and obviously they don't all read the
Pavel Kislinger writes:
This is an imperfection of back-sql. It doesn't exist any way
how to say to slapd, which attributes are base64 encoded.
No. base64 has nothing to do with attribute definitions, nor with
anything else in LDAP except the LDIF file format. (Some backends make
use of the
[EMAIL PROTECTED] writes:
Man page slapd-perl does not contain ANY information on 'bind' method.
Wow. That doc is 9 years old and you are the first to notice.
Thanks for the report.
Also it is not clear: Is there any possibility for perl backend to get
connection information, for example IP
I wrote:
+ * bind DN, or for anonymous bind
Duh, sorry. Anonymous bind is handled by the frontend, of course.
--
Hallvard
Full_Name: Hallvard B Furuseth
Version: HEAD
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
One problem with back-config is that comments in slapd.conf
are lost when converting to cn=config, and cn=config does
not offer attributes in which to put comments. So I
[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
However the attribute for general notes ('info') should probably be
treated as X-ORDERED 'VALUES', I haven't checked if it's inconvenient
to do that with a preexisting attribute without that feature. The
valsort overlay does, but I don'
[EMAIL PROTECTED] writes:
This looks like a pretty major compiler bug, assuming the trace is
correct.
Not necessarily, valid optimizations can rearrange memory beyond a
debugger's ability to figure out what's going on. Still, this does
look like a strange optimization if it's a valid one.
Full_Name: Hallvard B Furuseth
Version: HEAD
OS: Linux
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
If objectclass B is a subclass of A, and an entry contains objectclass B
but not A, slapd returns attributeOrValueExists to a request to add A.
OTOH it allows
[EMAIL PROTECTED] writes:
The issue right now is caused by the fact that comparing present
values with the asserted one causes objectSubClassMatch() to check for
match including superiors.
This looks like a bug to me. objectClass has EQUALITY matching rule
objectIdentifierMatch, which does
[EMAIL PROTECTED] writes:
This looks like a bug to me. objectClass has EQUALITY matching rule
objectIdentifierMatch, which does not follow the object class
inheritance chain. (...)
What makes slapd work is that it also disobeys RFC 4512 section 3.3:
Oops, I meant the opposite: It's 1st bug
[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
RE24 configured with --quiet --without-threads --enable-ldap 'CFLAGS=-O0 -g'
Sorry, that's RE24 + the ITS#5519 (--without-thread miscompiles) patch:
cvs diff -r1.34 -r1.35 -I'[$]OpenLDAP[$:]' libraries/libldap_r/thr_stub.c
Probably, sync
Full_Name: Hallvard B Furuseth
Version: RE24
OS:
URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080527.tgz.1
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
slapd crashes in test035 after 10 runs:
daemon.c:979: assert( SLAP_SOCK_IS_ACTIVE( s ));
RE24 +
[EMAIL PROTECTED] writes:
I couldn't reproduce this issue with HEAD; do you confirm it's a re24 only?
Still happens in HEAD as well as RE24. Not RE23 though.
--
Hallvard
I haven't follwed this ITS, but a few notes anyway:
[EMAIL PROTECTED] writes:
monitorCounter
monitorCounter does not have an equality matching rule,
Yes it does. back-monitor/init.c line 1710. What are you looking at?
(Hmm, I too had the impression it had no EQUALITY rule...)
Well, pre-2.4.9 versions would reject the Add operation... Is it
2.4.10 built from the OpenLDAP source, or some prepackaged binary?
Maybe an overlay or something interferes with auto-adding the naming
attrs? Please post your slapd.conf too, after removing passwords etc.
--
Hallvard
[EMAIL PROTECTED] writes:
You are right: if I just grant 'auth' access to 'authzTo' the proxy
authorisation succeeds. The philisophy makes sense so I will try to
come up with a suitable patch to the Admin Guide describing how to use
it. At the moment the only note about this is in the ACL
Please post your ldap.conf and slapd.conf, minus any passwords.
The pastebin URL contains the post SSL negotiation debug
lines from slapd -d -1.
No need to pastebin data as short as that.
--
Hallvard
Howard Chu:
Indeed, the idea of multiple suffixes is that you're using suffixes
with no subordinate relation. However in that case, there is no
logical reason to keep them all within the same database either. They
represent totally independent namespaces then, and keeping them in a
single
[EMAIL PROTECTED] writes:
The following attribute type declaration references 'managedInfo'
which is not declared:
( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List of URIs a
proxy is serving; can be modified run-time' SUP managedInfo )
Please mention where the code is which
[EMAIL PROTECTED] writes:
I suspect something like: if back-monitor and/or back-ldap are built as
modules, and loaded in the wrong order (back-ldap first, back_monitor
then), 'olmDbURIList' is likely to be registered __before__
'managedInfo'.
So, a manpage fix something like this?
If
Howard Chu writes:
Sounds like this works as designed. The docs tell you that
either CACERT or CACERTDIR must be explicitly configured.
Maybe, but in that case the bug is that configuring them to an
irrelevant certificate works as a use the OpenSSL defaults flag.
Which is weird at best. And
Might be better to insert the following at the end of
libraries/liblutil/utils.c:lutil_progname():
#if something
{
size_t len = strlen( progname );
if ( len 4 strcasecmp( progname + len - 4, .exe ) == 0 )
progname[len - 4] = '\0';
[EMAIL PROTECTED] writes:
I note as well that properly deploying release signing requires
more than script modification. For instance, one does need to
consider that the host to sign the releases might itself been
taken over and the implications of such a takeover.
For that part, signatures
[EMAIL PROTECTED] writes:
On Aug 4, 2008, at 2:06 PM, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
I note as well that properly deploying release signing requires
more than script modification. For instance, one does need to
consider that the host to sign the releases might itself been
[EMAIL PROTECTED] writes:
It would be smarter to just standardize OID macros for each of these
OIDs, the way X.500 did, and not require the humans reading these
specs to memorize these numeric OIDs...
Yup. slapd/schema/syntaxes.schema?
Syntax names like olsDirectoryString or just
Presumably a dup of ITS#5464.
Workaround: Compile with CPPFLAGS=-D_GNU_SOURCE.
--
Hallvard
[EMAIL PROTECTED] writes:
Reconsidering... I guess we could add checks for the presence of the
required header files and libraries. I'm reluctant to do a full
AC_CHECK_HEADER here because that will only succeed if we enable C++
in the configure script, and right now the extra overhead of
[EMAIL PROTECTED] tests]$ *** glibc detected ***
/home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted
double-linked list: 0x0d28a430 ***
This message comes from glibc malloc. Its data structures are
corrupted.
I couldn't figure out much from the the valgrind
Looking at liblutil/utils.c:lutil_gettime() led me to
Beware of QueryPerformanceCounter()
http://www.virtualdub.org/blog/pivot/entry.php?id=106
Is warning relevant to slapd? I don't know Windows programming at all.
--
Hallvard
[EMAIL PROTECTED] writes:
error while loading shared libraries:
/home/michael/src/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/libldap_r/.libs/libldap_r-2.4-releng.so.2:
invalid ELF header
Hopefully a PEBKAC. Loading libraries built for another architecture,
or something like that.
--
[EMAIL PROTECTED] writes:
utf-8.c:char * (ldap_utf8_strchr)( const char *str, const char *chr )
I.e., string, character, as normal libc functions.
However, at line 125 in charray.c, it is called as:
if ( ldap_utf8_strchr( brkstr, s ) != NULL ) {
This order appears to be
[EMAIL PROTECTED] writes:
Yes. The calling order was incorrect. It is supposed to be
ldap_utf8_strchr(s, brkstr).
No. Try this with the new code:
env LDAPHOST='host1 host2' valgrind clients/tools/ldapwhoami -x
It returns writes past malloced areas in ldap_str2charray().
options.c calls
Duh, perhaps I should have paid attention to the committed patch
instead of your description of the problem...
The patch breaks in a different way than I said.
Replace ldap_utf8_strchr with ldap_utf8_strpbrk and it should work.
I probably can't test it today.
--
Hallvard
This fix introduced some garbage in debugging output.
It's cleaned up in cvs HEAD and the upcoming OpenLDAP 2.4.12.
--
Regards,
Hallvard
For reference: There's more about this in ITS#5340.
Somewhat confused discussion, unfortunately.
--
Hallvard
Belatead followup:
This description of REP_ENTRY_MUSTRELEASE was still wrong. See ITS#5728:
BDB didn't set the flag, ITS#3671 just gave the impression it would.
Also code much take care to call overlay_entry_release_ov() instead of
be_entry_release_r() when appropriate, as in ITS#5451.
--
Full_Name: Hallvard B Furuseth
Version: HEAD
OS:
URL: http://folk.uio.no/hbf/OpenLDAP/limits.txt
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
I want to give part of a database different limits than the rest.
Here a suggested patch, currently a quick hack for inspection. It
Full_Name: Hallvard B Furuseth
Version: HEAD, RE24
OS: Linux x86_64
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
$ clients/tools/ldapwhoami -x -h ldap:389
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
$ clients/tools/ldapwhoami -x -h ldap
anonymous
[EMAIL PROTECTED] writes:
Why are you reporting this? -h has always been documented to only
accept a hostname,
No. Look at man ldap_init:
(...) each host may optionally by of the form host:port. If
present, the :port overrides the port parameter (...)
So sometimes this option is
I wrote:
Here a suggested patch, currently a quick hack for inspection.
I forgot slap.h. Added it now. And manpage while I'm at it.
This needs an API change: Currently slapd/limits.c:limits_gets()
takes the bound DN as an argument. The change needs a function
which fetches the bound or
Full_Name: Hallvard B Furuseth
Version: HEAD, RE24
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
overlays/collect.c:struct collect_info.ci_ad is a C99 flexible array member.
Rewriting to use a C89 struct hack variant for C89 except gcc.
That may be formally
Full_Name: Hallvard B Furuseth
Version: HEAD, RE24
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
libraries/liblutil/tavl.c:tavl_find3(NULL,,, ret)
returns an undefined value and sets ret = undefined.
I don't know if that can happen; it would be if
Full_Name: Hallvard B Furuseth
Version: HEAD, RE24
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
All bitstring bits are significant, but schema_init.c:nameUIDPretty()
strips initial zeros from the bitstring in syntax Name and Optional UID.
It was incompletely fixed
Full_Name: Hallvard B Furuseth
Version: HEAD, RE24
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
overlays/constraint.c:constraint_violation() uses and maybe returns an
undefined value in 'rc' if the filter is bad (nop.ors_filter == NULL).
I have no idea what rc
[EMAIL PROTECTED] writes:
My point is about tickets opened with only partial information, answered
with a request for clarification that never comes in: 5712, 5652, 5651, ...
Hm, you've marked ITS#5651 Feedback even though it contains no feedback
request. If you sent one privately, I suggest
Can you post a slapd.conf and the necessary file files which cause
this? Or an URL to them? Remember to remove passwords.
Since you say slapd won't restart, I assume it does start the first
time. When slapd starts up and writes such a bad schema directory,
do the missing attributes show up
The problem is the 8-bit Latin-1 character in the certificate's DESC.
It works if you convert the schema file to UTF-8.
Slapd should have refused to start with a non-UTF-8 attribute DESC.
Possibly that should wait for OpenLDAP 2.5 though, and just log a
warning for now.
--
Hallvard
I wrote:
Possibly that should wait for OpenLDAP 2.5 though, and just log a
warning for now.
...though -f file -F dir should fail, of course.
--
Hallvard
1 - 100 of 554 matches
Mail list logo
