Re: error while adding entry using ldap.jar JAVA API
by Sumith Narayanan
I am already on db-4.4.20 , do I need to downgrade that ?
Thanks, Sumith
On Fri, Apr 11, 2008 at 12:49 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>
wrote:
> --On Friday, April 11, 2008 12:32 PM -0700 Sumith Narayanan <
> sumith.narayanan(a)gmail.com> wrote:
>
> Thanks,
> >
> >
> > I could download BDB4.2.52+5 patches from
> >
> >
> >
> > http://www.oracle.com/technology/software/products/berkeley-db/db/index.h
> > tml
> >
> >
> > Where can I get all the 6 paches ?
> >
>
> <
> http://www.stanford.edu/services/directory/openldap/configuration/patches...
> >
>
> Also , I how should I apply patch , in the oracle website , I just see
> > the code that need to be added as a patch ? Do I manually make changes
> > ?
> > Please suggest the best approach
> >
>
> I suggest familiarizing your self with the "patch" command.
>
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
15 years, 1 month
Re: error while adding entry using ldap.jar JAVA API
by Sumith Narayanan
Thanks,
I could download BDB4.2.52+5 patches from
http://www.oracle.com/technology/software/products/berkeley-db/db/index.html
Where can I get all the 6 paches ?
Also , I how should I apply patch , in the oracle website , I just see the
code that need to be added as a patch ? Do I manually make changes ? Please
suggest the best approach
Thanks, Sumith.
On Fri, Apr 11, 2008 at 12:17 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>
wrote:
> --On Friday, April 11, 2008 12:04 PM -0700 Sumith Narayanan <
> sumith.narayanan(a)gmail.com> wrote:
>
>
> >
> >
> > This statement can be misleading for running OpenLDAP 2.3.x since BDB
> > 4.6.x can only be used with OpenLDAP 2.4.x.
> >
> >
> >
> > Sorry, i am confused, so which is the latest stable version that I
> > should
> > be using ?
> >
> >
> > Keep replies on the list.
> > > >
> > >
> > The latest stable version of what? OpenLDAP? BDB? Java?
> > > >
> > >
> >
> > OpenLDAP and BDB..
> >
>
> For OpenLDAP 2.3, I've used BDB 4.2.52+6 patches quite stably for a long
> time.
>
> The openldap website still lists OpenLDAP 2.3.39 as the "stable" tagged
> release. I use OpenLDAP 2.3.41 myself, since it has fixes I require.
>
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
15 years, 1 month
Re: error while adding entry using ldap.jar JAVA API
by Sumith Narayanan
>
> This statement can be misleading for running OpenLDAP 2.3.x since BDB
> > 4.6.x can only be used with OpenLDAP 2.4.x.
> >
>
>
> Sorry, i am confused, so which is the latest stable version that I should
> be using ?
>
>>Keep replies on the list.
>>The latest stable version of what? OpenLDAP? BDB? Java?
OpenLDAP and BDB..
thanks, Sumith.
On Fri, Apr 11, 2008 at 10:46 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>
wrote:
> --On Friday, April 11, 2008 8:41 AM -0700 Sumith Narayanan <
> sumith.narayanan(a)gmail.com> wrote:
>
> This statement can be misleading for running OpenLDAP 2.3.x since BDB
> > > 4.6.x can only be used with OpenLDAP 2.4.x.
> > >
> >
> >
> > Sorry, i am confused, so which is the latest stable version that I
> > should
> > be using ?
> >
>
> Keep replies on the list.
>
> The latest stable version of what? OpenLDAP? BDB? Java?
>
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
15 years, 1 month
Odd delta-sync replication issue (OpenLDAP 2.3.41)
by Quanah Gibson-Mount
I have a replica spitting out the following error in its logs (master and
replica running OpenLDAP 2.3.41):
Apr 11 13:28:03 123-ldap-3 slapd[21846]: syncrepl_message_to_op: rid 100
be_modify uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu (20)
It's syncrepl cookie is:
contextCSN: 20080410145621Z#000000#00#000000
Looking at the accesslog on the master, I see (for this time period):
dn: reqStart=20080410145621.000001Z,cn=accesslog
objectClass: auditModify
structuralObjectClass: auditModify
reqStart: 20080410145621.000001Z
reqEnd: 20080410145621.000003Z
reqType: modify
reqSession: 190486
reqAuthzID: uid=zimbra,cn=admins,cn=zimbra
reqDN: uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu
reqResult: 0
reqMod: zimbraPasswordLockoutFailureTime:+ 20080410145621Z
reqMod: zimbraPasswordLockoutFailureTime:- 20080410145230Z
reqMod: entryCSN:= 20080410145621Z#000000#00#000000
reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra
reqMod: modifyTimestamp:= 20080410145621Z
entryUUID: 06ac9202-9b5a-102c-8816-1596598f2bf0
creatorsName: cn=accesslog
createTimestamp: 20080410145621Z
entryCSN: 20080410145621Z#000000#00#000000
modifiersName: cn=accesslog
modifyTimestamp: 20080410145621Z
dn: reqStart=20080410145621.000027Z,cn=accesslog
objectClass: auditModify
structuralObjectClass: auditModify
reqStart: 20080410145621.000027Z
reqEnd: 20080410145621.000028Z
reqType: modify
reqSession: 190494
reqAuthzID: uid=zimbra,cn=admins,cn=zimbra
reqDN: uid=yyyy_07,ou=people,dc=123,dc=abc,dc=edu
reqResult: 0
reqMod: zimbraPasswordLockoutFailureTime:+ 20080410145621Z
reqMod: entryCSN:= 20080410145621Z#000001#00#000000
reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra
reqMod: modifyTimestamp:= 20080410145621Z
entryUUID: 06ee59c6-9b5a-102c-8817-1596598f2bf0
creatorsName: cn=accesslog
createTimestamp: 20080410145621Z
entryCSN: 20080410145621Z#000001#00#000000
modifiersName: cn=accesslog
modifyTimestamp: 20080410145621Z
So as I understand (delta)syncrepl, the replica knows it already received
the update for uid=xxxxx, and yet it is still trying to process that
update, rather than the next one for uid=yyyy_07.
The entry on the replica has:
dn: uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu
zimbraPasswordLockoutFailureTime: 20080410145515Z
zimbraPasswordLockoutFailureTime: 20080410145516Z
zimbraPasswordLockoutFailureTime: 20080410145519Z
zimbraPasswordLockoutFailureTime: 20080410145539Z
zimbraPasswordLockoutFailureTime: 20080410145547Z
zimbraPasswordLockoutFailureTime: 20080410145548Z
zimbraPasswordLockoutFailureTime: 20080410145621Z
So it's clear that the update took on the replica. So why is it trying to
re-replicate an event it already got, and *knows* it already got, since it
updated its cookie?!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 1 month
Re: error while adding entry using ldap.jar JAVA API
by Quanah Gibson-Mount
--On Friday, April 11, 2008 8:41 AM -0700 Sumith Narayanan
<sumith.narayanan(a)gmail.com> wrote:
>> This statement can be misleading for running OpenLDAP 2.3.x since BDB
>> 4.6.x can only be used with OpenLDAP 2.4.x.
>
>
> Sorry, i am confused, so which is the latest stable version that I should
> be using ?
Keep replies on the list.
The latest stable version of what? OpenLDAP? BDB? Java?
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 1 month
Backup and bdb-logfile removal
by Peter Mogensen
Hi,
I've been going all documentation I can find (FAQ/bdb-docs..) and I
still have some doubt whether I understand this correctly.
I run frequent dumps with slapcat to backup the database, but I still
need to cleanup the BDB logfiles and it would also be nice get faster
back online after a crash than you can from LDIF.
So I understand how to create a hot backup by copying the database files
(db_archive -s) and then the log files (db_archive -l) and runing
db_recover -c.
I can see that I can delete unused log files (db_archive [no options])
from the backup. But when is it safe to remove log files from the active
environment?
db_archive on the active environment lists fewer files than on the
backup (predictable enough).
The docs say that running db_archive -d can make recovery impossible.
OK... so I don't do that.
But what is required of my hot backup snapshot to know that I can delete
log files from the active environment? (and which?) and still not
influence the posibility for recovery.
Could anyone list a step-by-step procedure to create a snapshot for
backup and prune the log files from the active environment?
btw: openldap 2.3.30/ bdb 4.2.52 (debian) ... but I guess that's not so
important here.
regards,
Peter
PS: I expect still to do occasional slapcats just as an extra security
measure.
15 years, 1 month
slapd crashes due to assertion failure
by John Morrissey
We recently upgraded from 2.3.30 to 2.3.41. Ever since, slapd has died about
once a week due to an assertion failure. A backtrace is below, but I forgot
to disable optimization in the build, so there's been some inlining.
The only assertions in connection_close() are:
assert( connections != NULL );
assert( c != NULL );
[...]
assert( c->c_struct_state == SLAP_C_USED );
assert( c->c_conn_state == SLAP_C_CLOSING );
I'm not sure if this gives enough to go on, but I've rebuilt with
optimization disabled and have a debugger attached for the next time it
fails.
Program received signal SIGABRT, Aborted.
[Switching to Thread -1884128336 (LWP 26138)]
0xb7b98947 in raise () from /lib/tls/libc.so.6
#0 0xb7b98947 in raise () from /lib/tls/libc.so.6
#1 0xb7b9a0c9 in abort () from /lib/tls/libc.so.6
#2 0xb7b9205f in __assert_fail () from /lib/tls/libc.so.6
#3 0x0806d052 in connection_close (c=<value optimized out>)
at /var/jwm/openldap/servers/slapd/connection.c:680
#4 0x0806d67d in connection_operation (ctx=0x8fb272c8, arg_v=0x993a830)
at /var/jwm/openldap/servers/slapd/connection.c:1722
#5 0xb7f14e7f in ldap_int_thread_pool_wrapper (xpool=0x814d358)
at /var/jwm/openldap/libraries/libldap_r/tpool.c:478
#6 0xb7ca70bd in start_thread () from /lib/tls/libpthread.so.0
#7 0xb7c3c01e in clone () from /lib/tls/libc.so.6
john
--
John Morrissey _o /\ ---- __o
jwm(a)horde.net _-< \_ / \ ---- < \,
www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
15 years, 1 month
paged results vs socket send buffer size
by Hallvard B Furuseth
We are getting some clients which will occationally retrieve ~2.5M data
in one search operation. If I understand correctly, that can block the
thread running the search operation until the client-side socket accepts
the data. So I'm wondering what to do, unless I misunderstand the above
completely:
Are paged results reliable now? Browsing the mailinglists I see a lot
of older problems with them. Also, what limit is reasonable to use?
I imagine it makes sense to try to keep a page below the socket send
buffer size.
Threads might be safer too, in case many slow clients do this at once.
Regarding the send buffer size, "/sbin/sysctl net.ipv4.tcp_wmem"
currently says the default is 16384 bytes, while tcp_rmem (socket read
buffer size) is 87380 bytes. How do I pick good defaults for these? We
care about LDAP read operation speed but not write operation speed, so
maybe it'd make sense to swap these two numbers at least for slapd.
Current stats: Dedicated LDAP server host, Linux x86_64. Max 8192
connections (ulimit -n 8192), 8G memory. 60-90 new connections and
300-500 requests per second. 1G *.bdb files for 340000 entries in 5
databases.
--
Hallvard
15 years, 1 month
Group ACLs and indirection
by Simon Wilkinson
Hi,
Just wondering, before I go and delve into the code, whether there
was a way of doing group based ACLs in the same way as dnattr allows
indirection on the user DN.
Essentially, I'd like an object to contain an attribute holding the
DN of the group permitted to access that object, and then be able to
do access control based on the user being a member of the group
pointed to by that DN.
I can find an email from Kurt in 1999, suggesting a groupattr
directive be implemented, and welcoming contributions. Would a
contribution of this still be welcomed 9 years later?
Cheers,
Simon.
15 years, 1 month
Problem with back-ldap and slapo-rwn
by Torsten Schlabach (Tascel eG)
Dear list!
We are trying something we thought should be simple:
We have got
Server A: Holds an LDAP database
Server B: Is supposed to act as a proxy to A
Both are OpenLDAP, A is 2.2; B is 2.4.
What we want to achieve is that server B will just proxy everything from
server A except that some attribute names shall be rewritten, i.e. B is
queried for a different attribute name as the actual name on A.
Here is what we did:
database ldap
suffix "o=world"
uri "ldap://ldap.our.tld/"
overlay rwm
rwm-map attribute authzTo saslAuthzTo
The problem with that setup is that it will crash server B.
In some example we found somthing like this:
database ldap
suffix "o=world"
uri "ldap://ldap.our.tld/"
overlay rwm
rwm-map attribute authzTo saslAuthzTo
rwm-map attribute *
So as soon as we add that wildcard line, slapd (on server B) will no
longer crash, but unfortunately, it is not going to find anything anymore.
Could anyone help out with an example?
Regards,
Torsten
15 years, 1 month
