| |
| |
| |
|
Page: 1 2 3 4
Comments:
<0> ldapmodify
<0> :)
<1> :D
<1> ldapmodify -b -r -f /tmp/entrymods
<1> JoBbZ: all that does it throw me the syntax
<1> :(
<0> k31th: so read the man page...
<1> iv read it
<2> hi hyc
<2> I'm still having fun with bit-ops, and large numbers
<3> ugh
<2> so, for a query of
<2> bin/ldbsearch -Uadministrator%samba2 -H ldap://localhost:2389 '(groupType:1.2.840.113556.1.4.803:=1)' -b dc=tammy,dc=abartlet,dc=net -s sub groupType
<2> which should match # record 22
<2> dn: cn=Account Operators,cn=Builtin,dc=tammy,dc=abartlet,dc=net
<2> groupType: 2147483653
<2> it doesn't
<2> against OpenLDAP
<2> it does however match on smaller numbers, so i can do that against pwdProperties
<2> it might be my slightly older version of OpenLDAP?
<3> what versionare you using?
<2> openldap-servers-2.3.19-4
<2> just trying to build from CVS now
<3> well, no changes to that file since 2.3.14...
<2> hmm
<3> tho it may be compiler dependent
<2> is there a way to get at the configure detection from the binary?
<2> samba has a -B option, which returns build info
<3> nope
<3> we talked about adding that, never did.
<2> I convinced vance to knock up one in Samba, many moons ago. It's mostly a bit of awk
<3> quite a bit of stuff to report, much of it meaningless. not sure how to present it in a useful manner.
<2> yeah, most of our stuff is meaningless, but it helps with this kind of puzzle
<3> anyway, I always build all projects I work with from source.
<3> I suppose that's just defensive behavior now, since I usually find bugs in everything.
<2> :-)
<2> if integerBitAndMatch failed with constraint violation, would it fail the search, or just fail to match?
<3> fail to match
<2> ok, so I really need to make this build, and get out my debugger
<3> search operations basically never fail.
<2> ok
<3> the only failure is if the search base doesn't exist.
<3> otherwise, they succeed (with zero results, etc.)
<2> I wonder if LLONG_MIN and LLONG_MAX are not defined
<3> easy enough to just compile it and see.
<2> hmm, should be. OK, time to build from CVS
<3> run nm on schema_init.o ...
<2> yeah, I'll do that once I get it to build
<2> make depend failed out for some reason. Do I need that, or can I just 'make'?
<3> mmmm, why did it fail?
<3> and where?
<3> it also creates some symlinks that you need.
<3> tho I think they will get created anyway during regular make.
<2> it wasn't a very clean checkout, cvs update from a very long time ago
<3> got merge conflicts?
<2> not that I noticed
<3> well, you can try it, but it sounds suspicious
<2> cd back-ldbm; make -w depend
<2> make[3]: Entering directory `/data/openldap/cvs/servers/slapd/back-ldbm'
<2> make[3]: *** No rule to make target `Makefile.in', needed by `Makefile'. Stop.
<3> oh
<3> just delete the back-ldbm directory
<2> seems to be working now
<2> (building)
<2> hyc: I get only U __strtol_internal
<3> sounds like only 32 bit then
<2> I would have expected to see strtoll
<2> this is on Fedora Core 5, on x86
<3> you could also grep for HAVE_LONG_LONG in include/portable.h
<2> #define HAVE_LONG_LONG 1
<3> and HAVE_STRTOLL while you're at it
<2> #define HAVE_STRTOLL 1
<3> odd
<2> and even #define HAVE_LIMITS_H 1
<2> whould should bring in the MIN/MAX stuff that conditional requires
<3> perhaps strtol_internal is just gcc's own strtoll
<2> what's the best way to get the CPP output for a file in the OpenLDAP tree?
<2> let's see which macros it expands
<3> make AC_CFLAGS=-E
<3> or somesuch
<2> I'll wait for the build to finish, and hack the makefile
<4> When login at the website writed php, can I use LDAP server instead of using account/p***wd in mysql?
<2> hyc: cpp shows we use only strtol
<3> then I guess LLONG_MAX and LLONG_MIN are missing...
<2> they are in my headers
<3> no idea...
<2> ahh, but in inside __USE_ISOC99
<2> btw, do you know of any platforms you care about that don't have a ll?
<2> Samba4 uses 64 bit numbers uncoditionally, with only the need for replacing strtoll occasionally
<2> we expected trouble, but found much less than we expected
<3> I'm a bit surprised at this code
<3> the tests with MAX and MIN seem a bit silly
<2> it looks like some over-parionoid code gone wrong :-)
<3> well, the manpage says those are the values returned for overflow and underflow
<3> but I wonder why we don't just check for errno == ERANGE and leave it at that.
<2> perhaps if errno was left over from a previous error?
<3> so zero it before the call
<2> yeah
<3> well, it seems to be adhering to the letter of the spec
<2> btw, do you have a replacement strtoull and strtoll?
<3> hm, seems so
<2> for platforms that do 64 bit, but don't do these functions
<2> it's one of the things that came up with HP-UX I think
<3> hm, nope. we have lutil_atol but it just calls strtol.
<2> make AC_CFLAGS="-E -std=c99"
<2> seems to 'fix' it on gcc/linux
<2> we then get the right LL MIN/MAX stuff
<3> Interesting. I wonder what other defs are hidden by that...
<2> I suspect this needs a testsuite test, as clearly nobody has needed this in the past :-)
<3> heh
<2> of course, if you want to continue to support 32 bit only platforms, then it's harder, but there are less of them around than you might expect
<2> (as you would need to have the testsuite conditional on the maximum integer size)
<3> right
<3> we're hoping that all the 32 bit stuff goes extinct soon
<2> it is already, as far as Samba4 is concerned
<2> anything that Samba4 builds on (see build.samba.org) has a 64 bit integer
<3> we've been working with a Fortune50 company, just tossed out all of their SunOne servers and replaced with Symas CDS a few weeks ago.
<3> 25 sites around the world switched simultaneously.
<2> nice work!
<3> they're all 32 bit :P
<2> what platform?
<3> they're just beginning to migrate to 64 bit in the next few weeks.
<3> hmmm, some generic x86 Linux
<3> RHEL4 I think
<2> sure, but that has 64 bit integers
<2> we found 'long long' (or equivilant) on every platform we cared about
<3> actually RHEL3 come to think of it. Anyway, their DB size is large enough that they need 64 bit addressing anyway
<3> Since we only build with gcc, and gcc seems to support long long everywhere, yeah, that's covered.
<2> hyc: any ideas about how I can do my bitops based filter, given we don't have long integers support in existing binaries?
<3> well that's puzzling.
<3> that means it's using 32 bit signed int now
<3> so your initial query ought to have worked.
<2> yep
<2> ok, I might revert some things, and double-check that
<3> you might try recompiling your current source with debug, no -O, and singlestep the integerBit* functions
<2> I think I had a mix of positive and negative flags
<2> (that being one of the other inconsistancies I cleaned up while trying to fix this)
<3> ah, that would help
<2> I think it only worked for us by dumb luck :-)
<2> this might explain why I swore I saw it working, then it stopped working :-)
<2> hmm, maybe not.
<2> anyway, it's more complex than just -std=c99, as openldap won't compile with that set
<2> (it fails to find bdb)
<3> great....
<3> well, you probably want to remove that anyway, to make your build as close as possible to the other
<2> indeed
<2> hyc: while i'll work around this myself (I need to use existing binaries, as I'm trying to do a reproducable testsuite for Samba), how should we proceed with the OpenLDAP bug?
<2> will you take it from here, or do I need to do something?
<3> ? what are you calling a bug?
<2> not supporting long long on my platform
<3> oh.
Return to
#ldap
or
Go to some related
logs:
debian QTDIR*
apt-get install latex-package
ubuntu vx1120 resolution
#linux
GTK BADREQUEST
grp xorg modular
username password wildpass
gentoo wiki interactive-boot
+freenx +no screen +debian
#suse
|
|