https://bugs.openldap.org/show_bug.cgi?id=9017
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |TEST
Status|IN_PROGRESS |RESOLVED
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9017
--- Comment #20 from kriszyp(a)gmail.com <kriszyp(a)gmail.com> ---
> You ought to be able to use int64_t instead, or any other explicitly
> 64-bit signed integer type.
Yes, that (#define MDB_OFF_T int64_t) compiles and works fine in all
my tests (including with >2GB dbs). I assume you can commit/fix this
(or do we want me to make a patch)?
Thanks,
Kris
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8125
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |CONFIRMED
Ever confirmed|0 |1
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9017
--- Comment #19 from Howard Chu <hyc(a)openldap.org> ---
openldap-its(a)openldap.org wrote:
> https://bugs.openldap.org/show_bug.cgi?id=9017
>
> --- Comment #18 from kriszyp(a)gmail.com <kriszyp(a)gmail.com> ---
>> I've committed your first two patches as-is,
> Thank you so much, appreciate the review and including this code. I
> hope it helps other Windows users leverage the awesome LMDB
> performance and integrity!
>
>> and taken a different approach for the off_t issue.
> Unfortunately, this commit didn't work for me. LMDB no longer compiles
> when using LARGE_INTEGER for offsets. Perhaps ULONG would work better?
> I get the following compilation errors (or is there possibly something
> I need to define to address this?):
>
> \dependencies\lmdb\libraries\liblmdb\mdb.c(3739): error C2440: '=':
> cannot convert from 'pgno_t' to 'LA
> RGE_INTEGER' [\build\node-lmdb.vcxproj]
> \dependencies\lmdb\libraries\liblmdb\mdb.c(3744): error C2088: '!=':
> illegal for union [C:\dev\node-lmd
> b\build\node-lmdb.vcxproj]
> \dependencies\lmdb\libraries\liblmdb\mdb.c(3767): error C2088: '&':
> illegal for union [
> \build\node-lmdb.vcxproj]
Apparently LARGE_INTEGER isn't an integer at all, it appears to be a
structure.
You ought to be able to use int64_t instead, or any other explicitly
64-bit signed integer type.
Since offsets can be forward or backward from a designated reference
point, off_t and MDB_OFF_T must be a signed type. size_t is explicitly
unsigned, so it is an error to use that for this purpose. It's also only
32 bits wide on a 32bit machine, so it'd be unsuitable for larger DBs.
The use of MDB_OFF_T/off_t for env->me_size is a bit bogus, since a
file size should be unsigned. But we don't have address spaces large
enough yet for the difference between 2^63 and 2^64 to matter. (And
also, the me_size field has actually never been used. Probably should
just be deleted...)
>> Do you still want the corresponding patch in 0.9? And can you please remind
>> me where the 0.9 patch is? Thanks.
> I could if you want, but you convinced me that using mdb.master and
> focusing 1.0 was the way to go, so that's what we have been using for
> the last few months (with my patches applied locally), and it has been
> working great on our servers. I don't need an 0.9 patch, but I could
> work on creating one if you think it is important.
No, that's fine.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9017
--- Comment #18 from kriszyp(a)gmail.com <kriszyp(a)gmail.com> ---
> I've committed your first two patches as-is,
Thank you so much, appreciate the review and including this code. I
hope it helps other Windows users leverage the awesome LMDB
performance and integrity!
> and taken a different approach for the off_t issue.
Unfortunately, this commit didn't work for me. LMDB no longer compiles
when using LARGE_INTEGER for offsets. Perhaps ULONG would work better?
I get the following compilation errors (or is there possibly something
I need to define to address this?):
\dependencies\lmdb\libraries\liblmdb\mdb.c(3739): error C2440: '=':
cannot convert from 'pgno_t' to 'LA
RGE_INTEGER' [\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(3744): error C2088: '!=':
illegal for union [C:\dev\node-lmd
b\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(3767): error C2088: '&':
illegal for union [
\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(3768): error C2088: '>>':
illegal for union [C:\dev\node-lmd
b\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(3832): error C2088: '+':
illegal for union [
\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(3667): error C2440:
'initializing': cannot convert from 'int
' to 'LARGE_INTEGER' [\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(3680): error C2440:
'initializing': cannot convert from 'int
' to 'LARGE_INTEGER' [\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(4333): error C2440: '=':
cannot convert from 'size_t' to 'LA
RGE_INTEGER' [\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(4334): error C2088: '+':
illegal for union [
\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(4335): error C2088: '-':
illegal for union [
\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(4336): error C2088: '+=':
illegal for union [C:\dev\node-lmd
b\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(4346): error C2440: '=':
cannot convert from 'LARGE_INTEGER'
to 'DWORD' [\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(4369): error C2440: '=':
cannot convert from 'LARGE_INTEGER'
to 'DWORD' [\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(5319): error C2440: '=':
cannot convert from 'DWORD' to 'LAR
GE_INTEGER' [\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(5324): error C2440: '=':
cannot convert from 'size_t' to 'LA
RGE_INTEGER' [\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(5325): error C2088: '<':
illegal for union [
\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(5327): error C2440:
'function': cannot convert from 'LARGE_I
NTEGER' to 'LONG' [\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(5327): warning C4024:
'SetFilePointer': different types for
formal and actual parameter 2 [\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(5328): error C2440: 'type
cast': cannot convert from 'LARGE_
INTEGER' to 'DWORD' [\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(5335): error C2088: '-':
illegal for union [
\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(5336): error C2088: '/':
illegal for union [
\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(5344): error C2440:
'function': cannot convert from 'LARGE_I
NTEGER' to 'SIZE_T' [\build\node-lmdb.vcxproj]
\dependencies\lmdb\libraries\liblmdb\mdb.c(5344): warning C4024:
'MapViewOfFileEx': different types for
formal and actual parameter 5 [\build\node-lmdb.vcxproj]
(and it all compiles fine when I use size_t
> Do you still want the corresponding patch in 0.9? And can you please remind
> me where the 0.9 patch is? Thanks.
I could if you want, but you convinced me that using mdb.master and
focusing 1.0 was the way to go, so that's what we have been using for
the last few months (with my patches applied locally), and it has been
working great on our servers. I don't need an 0.9 patch, but I could
work on creating one if you think it is important.
> And please don't send HTML emails, plaintext only.
My apologies. Missed some settings, I despise that HTML cruft as well.
Thanks,
Kris
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8847
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|IN_PROGRESS |CONFIRMED
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8783
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9017
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |IN_PROGRESS
Ever confirmed|0 |1
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9017
--- Comment #17 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• da0527ac
by Kris Zyp at 2020-04-24T14:44:33+01:00
ITS#9017 LMDB: improve Windows sync commit perf
• 147582b5
by Kris Zyp at 2020-04-24T14:47:32+01:00
ITS#9017 LMDB: allow using fixed file size on Windows
• b77c2ba7
by Howard Chu at 2020-04-24T15:03:33+01:00
ITS#9017 LMDB: fix off_t usage on Windows
Commits:
• 1f026685
by Howard Chu at 2020-04-24T15:07:33+01:00
ITS#9017 doxygen comment for MDB_FIXEDSIZE
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9017
--- Comment #16 from Howard Chu <hyc(a)openldap.org> ---
kriszyp(a)gmail.com wrote:
> Sorry, I should have added a little more detail. Specifically, I was seeing the `pos` variable in `mdb_page_flush` going over 2^31, and this being manifested in
> failed shift right here (resulting in 2^32 -1):
I've committed your first two patches as-is, and taken a different approach
for the off_t issue. (size_t is only 32bit on a 32bit Windows system, so it's
inappropriate.)
Do you still want the corresponding patch in 0.9? And can you please remind
me where the 0.9 patch is? Thanks.
And please don't send HTML emails, plaintext only.
>
> https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L3711
>
> Â
>
> Thanks,
> Kris
>
> Â
>
> *From: *Howard Chu <mailto:hyc@symas.com>
> *Sent: *February 20, 2020 9:08 PM
> *To: *kriszyp(a)gmail.com <mailto:kriszyp@gmail.com>
> *Cc: *openldap-its(a)OpenLDAP.org <mailto:openldap-its@openldap.org>
> *Subject: *Re: (ITS#9017) Improving performance of commit sync in Windows
>
> Â
>
> Howard Chu wrote:
>
>> There should be an off64_t type instead.
>
> Â
>
> Â
>
>> But it looks to me like only the env->me_size field could ever overflow,
>
>> and using size_t for that should be fine. The other uses are for the meta page, which is always either offset 0 or
>
>> offset 4096 (with 4KB pagesize), and the lockfile, which is always smaller than 2GB.
>
> Â
>
> Ignore that, I was looking at the 0.9 branch when I wrote that.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8783
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8591
Ryan Tandy <ryan(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |CONFIRMED
Ever confirmed|0 |1
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8591
--- Comment #2 from Ryan Tandy <ryan(a)openldap.org> ---
Created attachment 720
--> https://bugs.openldap.org/attachment.cgi?id=720&action=edit
backtrace
Reproduced on Debian unstable (sid) with OpenLDAP 2.4.49 and Perl 5.30.
Attaching a better backtrace.
I note that it doesn't happen every time, sometimes it does start up fine.
So the crash is here:
https://sources.debian.org/src/perl/5.30.0-10/util.c/#L5415
(gdb) p my_perl
$1 = (PerlInterpreter *) 0x0
(gdb) p &my_perl->Ixsubfilename
$2 = (const char **) 0x5d8
When it doesn't crash, my_perl is equal to PL_curinterp.
(gdb) p my_perl
$1 = (PerlInterpreter *) 0x7fffa8106560
(gdb) p PL_curinterp
$2 = (PerlInterpreter *) 0x7fffa8106560
(gdb) p my_perl == PL_curinterp
$3 = 1
my_perl seems to come from Perl_get_context():
https://sources.debian.org/src/perl/5.30.0-10/util.c/?hl=3339#L3339
The corresponding pthread_setspecific() happens inside perl_back_initialize.
#0 __GI___pthread_setspecific (key=3, value=value@entry=0x7fffa8106560) at
pthread_setspecific.c:33
#1 0x00007fffb5aac68e in S_init_tls_and_interp (my_perl=0x7fffa8106560) at
perl.c:92
#2 perl_alloc () at perl.c:200
#3 0x00007ffff71aa70a in perl_back_initialize (bi=0x7ffff71b1220 <bi>)
Later, Perl_eval_pv invokes a DynaLoader to load the eval'ed code. This
module's startup is where Perl_xs_handshake is called, to check for
compatibility between the library's global Perl context (Perl_get_context())
and the one passed in from the application (implicit argument to
Perl_eval_pv()). Normally these would just be the same.
Anyway, this looks like a pretty simple bug in back_perl: we're just missing a
PERL_SET_CONTEXT() in perl_cf(), so it crashes if called from a different
thread than perl_back_initialize(). We should audit and make sure every
back_perl entry point calls it.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8591
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=9237
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8707
Ryan Tandy <ryan(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=9240
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8619
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |OL_2_5_REQ
Target Milestone|--- |2.5.0
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=6035
--- Comment #11 from Ryan Tandy <ryan(a)openldap.org> ---
Commits:
7ce47405 by Ryan Tandy at 2020-04-16T09:51:28-07:00
ITS#6035 Fix test076 to specify SASL mech
Still not ideal though. DIGEST-MD5 seems to be a Linux-centric (or maybe
cyrus-sasl-centric) default. May need to make this opt-in, like test028.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=5573
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |TEST
Keywords|OL_2_5_REQ |
Status|IN_PROGRESS |RESOLVED
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• 96fedda6
by Quanah Gibson-Mount at 2020-04-22T18:59:38+00:00
ITS#5573 - Expose contextCSN, entryCSN in subschema entry
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=5500
--- Comment #5 from Karl O. Pinc <kop(a)karlpinc.com> ---
Here are portions of a current slapd.conf file to provide some idea of
the comments that "need" preserving. (Note also the use of newlines
and whitespace to make values readable. But that's another
enhancement request.)
This config applies to a very dated version of openldap. While
one might want to argue that documentation on, say, creating
a crypted password, belongs elsewhere, the only time anyone
needs to make a crypted password was to edit this config file.
So why have a separate document?
include /etc/openldap/schema/core.schema
# Cosine is the X500 telephone schema, but we need attributes in there
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
# We don't want nis, but we do need it's attributes
include /etc/openldap/schema/nis.schema
#include /etc/openldap/schema/redhat/rfc822-MailMember.schema
#include /etc/openldap/schema/redhat/autofs.schema
#include /etc/openldap/schema/redhat/kerberosobject.schema
# Here's where inetMailRecipient is defined
include /etc/openldap/schema/misc.schema
# TROW specific stuff
include /etc/openldap/schema/trow.schema
# PWM specific stuff
include /etc/openldap/schema/pwm.schema
# eduPerson
include /etc/openldap/schema/eduperson.schema
# Amavisd-new stuff
include /etc/openldap/schema/amavisd-new.schema
TLSCipherSuite !ADH:MEDIUM:HIGH:!SSLv2:@STRENGTH
#
# The next three lines allow use of TLS for connections using a dummy test
# certificate, but you should generate a proper certificate by changing to
# /usr/share/ssl/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it.
#
# Used the procedure below (openssl-0.9.6b-35.7) to make a
# self-signed certificate for trixie.trow.com rsa key 1024 bits, expires
# 365 days from Jul 23, 2003. (Karl)
#
#TLSCACertificateFile /var/openssl/demoCA/cacert.pem
#TLSCertificateFile /etc/openldap/ssl.crt/trixie.crt
#TLSCertificateKeyFile /etc/openldap/ssl.key/trixie-rsa-1024.key
#
# Self signed cert expires 2037.
#
TLSCertificateFile /etc/openldap/certificates/trixie-trow-com-cert.pem
TLSCertificateKeyFile /etc/openldap/certificates/trixie-trow-com-key.pem
# Nice as it is to be logging, Sam, it uses up a lot of resources.
# Turn off logging.
# loglevel 0
# Log search filter processing, config file parsing, access control processing
# (useful for debugging access rules)
#loglevel 224
# Log configuration file parsing (and errors!)
#loglevel 64
loglevel 256
# To generate a crypted password, try:
# perl -e 'print("rootpw {crypt}" . crypt("secretpassword","sa") . "\n");'
# "secretpassword" is the password, "sa" is the salt.
# (FYI, the salt used in /etc/passwd is the first 2 chars of the
# encrypted password.)
# We should really be using something better than crypt
# to protect our password database!
#rootpw {crypt}elLJ3HpZEUmIA
#
# To generate a md5 password, try:
# perl -e 'print("rootpw {crypt}"
# . crypt("secretpassword", "\$1\$somesalt")
# . "\n");'
# (Yes, {crypt} is correct -- system crypt() call handles md5.)
# "secretpassword" is the password, "$1$somesalt" is the salt.
# (should be 8 chars in addition to the leading $1$).
# (FYI, the salt used in /etc/shadow is from the beginning of the
# encrypted password up to and including the third dollar sign.
# In the program above, all dollar signs should be written with
# a preceeding backslash.)
# Slave server replication. (for this database)
# (This is all probably unnecessary, because we're not making
# dynamic changes to the datbase anyhow.)
#
# Um, we could use kerberos instead of having a plaintext password
# here. I can't say for sure, but it occurs to me that the
# kerberos keys can't be stored in the filesystem and protected
# better than by simply makeing them unreadable to anybody but root.
# As long as this file is only readable by root (and we're not
# worried about network sniffing) this should be sufficient.
# Need to turn this off in order to replicate to Openldap 2.3 and 2.4.
# Operational attributes are blown away by oracle2ldap daily anyway.
lastmod off
#
# Need to set a limit here as a lot of children accumulate over time
# and they each use close to 50MB of RAM. 3/30/04 Sam
#
threads 20
defaultaccess none
# Evaluated in order.
# CAREFUL, collating sequence could mean weird < compares.
# Give the standard sort of unix access. Everybody can read
# most stuff, but can't see the password. (Besides, more restrictive
# access doesn't work.)
# Be persnickity and do some filtering.
# (except that we're filtering them out when we load the database)
# access to filter="(&(objectclass=posixaccount)(uid<1000))" none
# access to filter="(&(objectclass=posixgroup)(memberuid<900))" none
# Order of access controls is very important! First "access ..." match wins!
# Without a <control> after the <who>, it's only <what> that determines
# the match.
# As many of the 2.1 rules use the "by * + break" construct it might
# be possible to enhance performance by re-ordering the rules so that
# the most common matches are done early, but care is in (*ahem*) order.
# The uid of password maintainers _must_ be the primary uid!
# Some programs use the rootdn (Manager) to obtain global read/write
# access. The only problem with this is oracle2ldap, where
# if the database gets changed while oracle2ldap has the
# database in read-only mode, the changes will be lost when
# the database is replaced with the new database.
#
# Shipinet and GADS need to read the entire DB.
# At the top to speed things up as ACL processing is hugely inefficient in this
# version of LDAP.
#
access to *
by dn.exact="cn=shipinet,ou=Service,dc=trow,dc=com" read
by dn.exact="cn=gadirsync,ou=Service,dc=trow,dc=com" read
by * + break
#
# Allow any authenticated users to see the intrinsic root dn.
#
access to dn.base=""
by users read
by * + break
#
#Oracle Self Service
#
access to dn.subtree="ou=People,dc=trow,dc=com"
attrs=entry,preferredUid,oraclePClass,oracleId,preferredEmail,gec
os,cn
by dn.exact="cn=selfservice,ou=Service,dc=trow,dc=com" read
by * + break
access to dn.subtree="ou=People,dc=trow,dc=com"
attrs=objectClass
by dn.exact="cn=selfservice,ou=Service,dc=trow,dc=com" search
by * + break
#
# Other global access
#
# (This is not really necessary and slows things down a _mite_, but is kind.)
# Shipinet does need these -- I think.
access to dn="^dc=trow,dc=com$"
by * read
#
# Control access to the Service branch of the ldap database.
#
# Allow the "syscheck" service to read itself.
access to dn.base="cn=syscheck,ou=Service,dc=trow,dc=com"
by self read
by * + break
# PWM LDAP connection health checks.
# Remove 'pwmGUID' once the three instances are using their own GUID attrs.
access to dn.regex="^cn=pwmhealth[^,]*,ou=Service,dc=trow,dc=com$"
attrs=entry,userPassword,pwmGUID,pwmLiveGUID,pwmTestGUID,pwmDevGUID
by dn.exact="cn=pwm,ou=Service,dc=trow,dc=com" write
by * + break
access to dn.regex="^cn=pwmhealth[^,]*,ou=Service,dc=trow,dc=com$"
by dn.exact="cn=pwm,ou=Service,dc=trow,dc=com" read
by * + break
# Apparently PWM needs to read its own objectClasses.
access to dn.base="cn=pwm,ou=Service,dc=trow,dc=com"
attrs=entry,objectClass
by self read
by * + break
# Folks in Network Services can write, service DNs can bind.
access to dn.subtree=ou=Service,dc=trow,dc=com
by dn.exact="uid=swilson,ou=People,dc=trow,dc=com" write
by dn.exact="uid=jswan,ou=People,dc=trow,dc=com" write
by dn.exact="uid=fdavidson,ou=People,dc=trow,dc=com" write
by anonymous auth
#
# Contral access to the group branch.
#
access to dn.subtree="ou=Group,dc=trow,dc=com"
by dn.exact="cn=nss_ldap,ou=Service,dc=trow,dc=com" read
by dn.exact="uid=swilson,ou=People,dc=trow,dc=com" write
by dn.exact="uid=jswan,ou=People,dc=trow,dc=com" write
by dn.exact="uid=fdavidson,ou=People,dc=trow,dc=com" write
by * compare
#
# The rest of this is access to the People branch.
#
#
# Binding
#
# These access lists disable binding to subsets of the directory.
#
# Accounts must be active for the user to bind.
#
# When firstActivated is missing, the account's not yet activated.
# If the deactivated attribute is present then the account's
# been deactivated.
access to dn.subtree="ou=People,dc=trow,dc=com"
filter=(|(!(firstActivated=*))(deactivated=*))
attrs=entry
by anonymous none
by * + break
#
# Configure the Service dn-s access to the People subtree.
#
# Try to put services that need to sync with LDAP, thus reading the whole
direct
ory (or a large
# part) as near the top of this section as possible, as complex ACL processing
a
gainst a large
# number of entries degrades performance substantially.
#
# Uniflow printing system.
#
access to dn.subtree="ou=People,dc=trow,dc=com"
filter=(&(objectClass=AICPerson)(firstActivated=*)(!(deactivated=*)))
attrs=entry,preferredUid,preferredEmail,organizationalStatus,gecos,consti
tuency,objectClass,telephoneNumber,AICDepartment
by dn.exact="cn=uniflow,ou=Service,dc=trow,dc=com" read
by * + break
#
# nss_ldap (the glibc library and pam)
#
# (objectclass could probably be just search, or we could take the objectclass
# filter out of /etc/ldap.conf and add the filter here and allow no access
# to objectclass.)
access to dn.subtree="ou=People,dc=trow,dc=com"
attrs=dn,entry,cn,uid,uidNumber,gidNumber,homeDirectory,userPassword,logi
nShell,gecos,description,shadowLastChange,shadowMin,shadowMax,shadowWarning,shad
owInactive,shadowExpire,shadowFlag,description,objectclass,preferredUid,makeWWW,
useEmail,useDialup,firstActivated,deactivated
by dn.exact="cn=nss_ldap,ou=Service,dc=trow,dc=com" read
by * + break
#
# postfix (mail mta, really just some of it's various processes)
#
access to dn.subtree="ou=People,dc=trow,dc=com"
attrs=dn,entry,cn,uid,uidNumber,gidNumber,homeDirectory,gecos,mailrouting
address,maillocaladdress,preferredemail,rejectMail
by dn.exact="cn=postfix,ou=Service,dc=trow,dc=com" read
by * + break
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8614
--- Comment #9 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
(In reply to Howard Chu from comment #8)
> For this particular example, just delete "slapd(8) must be compiled with
> thread support, and "
Sure... this wasn't a question of how to change the text, but a note that we
need to take a thorough look through the documentation when making this change.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8772
--- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
82c8d3eb by Ryan Tandy at 2020-04-22T16:18:50+00:00
ITS#8772 Remove --with-threads=mach option
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8224
Ryan Tandy <ryan(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|IN_PROGRESS |RESOLVED
Keywords|OL_2_5_REQ |
Resolution|--- |TEST
--- Comment #3 from Ryan Tandy <ryan(a)openldap.org> ---
Commits:
82c8d3eb by Ryan Tandy at 2020-04-22T16:18:50+00:00
ITS#8772 Remove --with-threads=mach option
- - - - -
eadba4d0 by Ryan Tandy at 2020-04-22T16:18:50+00:00
ITS#8224 Use AS_HELP_STRING to indent configure options consistently
- - - - -
a2882e5e by Ryan Tandy at 2020-04-22T16:18:50+00:00
ITS#8224 Simplify --disable-slapd logic
- - - - -
5144fba8 by Ryan Tandy at 2020-04-22T16:18:50+00:00
ITS#8224 Simplify slapd minimal built-in backend check
--enable-slapd=auto is now implicitly handled the same as =yes.
- - - - -
2678a32a by Ryan Tandy at 2020-04-22T16:18:50+00:00
ITS#8224 Consolidate configure options validation
- - - - -
0c4ee60a by Ryan Tandy at 2020-04-22T11:31:01-07:00
ITS#8224 Regenerate configure
- - - - -
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8614
--- Comment #8 from Howard Chu <hyc(a)openldap.org> ---
(In reply to Quanah Gibson-Mount from comment #7)
> Need to check the various man pages etc about threads. For example,
> slapd-ldap(5) has:
>
> Note: When looping back to the same instance of slapd(8), each
> connection requires a new thread; as a consequence, slapd(8) must
> be
> compiled with thread support, and the threads parameter may need
> some
> tuning; in those cases, one may consider using slapd-relay(5)
> instead,
> which performs the relayed operation internally and thus reuses
> the
> same connection.
>
>
> slapd always will have thread support in 2.5+, so the wording needs
> adjustment.
For this particular example, just delete "slapd(8) must be compiled with thread
support, and "
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=5500
--- Comment #4 from Karl O. Pinc <kop(a)karlpinc.com> ---
The problem with adding an attribute is that this means that
comments are per-entry, and cannot be associated with specific
attribute values.
Having to write comments on an entry that apply to a specific
attribute value means having to describe the attribute's value within
the comment. Most of my comments have to do with particular attribute
values, so this would be awkward -- both for writer and reader.
Below is an alternative design. It supports commenting both
entries and attributes and working with commented ldif files in
an "expected" way. The downside is that this design does not
provide a "natural" user interface. Generic LDAP clients would
not readily associate comment text with the entries or attributes
commented. The OpenLDAP client tools would need to be used to
produce and consume "commented ldif" files.
No reason why this alternative design could not be implemented
alongside the design previously proposed.
Have a cn=comment,cn=config subtree. The dn is
index=X,attribute=Y,EntryUUID=Z,cn=comment,cn=config. (Where index is
the index of the commented attribute when an attribute is
multi-valued.) Keep all the comments there.
Index and attribute would be optional in the dn; when omitted the
comment is on the entry.
Pass a flag to ldapmodify and ldapadd so that comments are preserved
on input, and a flag for ldapsearch to output such comments.
The flag would only work on the cn=config DIT.
Comments appearing in an ldif before a dn are attached to the entry.
Comments appearing before an attribute are attached to the attribute.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8614
--- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Need to check the various man pages etc about threads. For example,
slapd-ldap(5) has:
Note: When looping back to the same instance of slapd(8), each
connection requires a new thread; as a consequence, slapd(8) must be
compiled with thread support, and the threads parameter may need some
tuning; in those cases, one may consider using slapd-relay(5) instead,
which performs the relayed operation internally and thus reuses the
same connection.
slapd always will have thread support in 2.5+, so the wording needs adjustment.
--
You are receiving this mail because:
You are on the CC list for the bug.