Re: (ITS#8962) Dead links in FAQ page "Where can I find listings of schema items?"

2019-06-06 Thread michael
On 6/7/19 1:49 AM, qua...@symas.com wrote:
> --On Friday, January 25, 2019 9:25 PM + mich...@stroeder.com wrote:
> 
>> All links herein are dead:
>> https://www.openldap.org/faq/data/cache/220.html
>>
>> I'd suggest to remove this FAQ page completely.
> 
> I tried, but unfortunatley the FAQ software breaks Apache when you try and 
> delete an answer.  I think the better solution is just to remove the FAQ 
> software completely.

The FAQ contains the only documentation for set-based ACLs.

So it's not an option to just shutdown FAQ-O-MATIC.

Ciao, Michael.





Re: (ITS#8988) Undefined Behavior in slapadd

2019-06-06 Thread noloader
On Thu, Jun 6, 2019 at 7:39 PM Quanah Gibson-Mount  wrote:
>
> --On Thursday, March 07, 2019 10:10 AM + noloa...@gmail.com wrote:
>
> > Full_Name: JW
> > Version: 2.4.47
> > OS: Linux (Fedora 29, x86_64, fully patched)
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (151.196.22.177)
> >
> > I added -fsanitize=undefined to CFLAGS.
>
> In this case, the compiler is the problem.

I'm pretty sure the compiler is correct.

The instrumentation does not produce false positives. It operates on
real data and simply does not produce false positives.

> LMDB is 100% correct regarding
> alignment on all supported CPUs (which is most of them).  The x86 family
> fully supports unaligned access, so LMDB makes use of this.

It is not the processor; it is the C language. The C language does not allow it.

> On other CPUs,
> which do not support unaligned access (e.g., SPARC), LMDB doesn't use them.

The undefined behavior exists even after disabling the unaligned
accesses with custom patches. For example, there is still undefined
behavior even after changes like this:

-#if defined(__i386) || defined(__x86_64)
-#define MISALIGNED_OK 1
-#else
#define ALIGNER (sizeof(size_t)-1)
-#endif

We also fixed COPY_PGNO but the undefined behavior remained.

The GCC Compile Farm (https://cfarm.tetaneutral.net/machines/list/)
has three SPARC machines. SPARC does not tolerate unaligned accesses
well, especially due to the optimized 64-bit move instruction.
OpenLDAP might consider testing on the SPARC machines.

In the bigger picture, OpenLDAP is causing other program and library
testing to fail testing. When we test other programs and libraries
that depend upon OpenLDAP in a similar fashion, the undefined behavior
in OpenLDAP surfaces in the other program and libraries. It is making
a lot of extra work for folks who perform extra testing.

I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an
important project, and the undefined behavior is causing too many
tangential problems.

Jeff





Re: (ITS#8946) openldap bug

2019-06-06 Thread quanah
Hello,

There is no bug here.  Your configuration is invalid.  If you need help 
with configuring OpenLDAP, then please use the 
openldap-techni...@openldap.org mailing list.

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:







Re: (ITS#8962) Dead links in FAQ page "Where can I find listings of schema items?"

2019-06-06 Thread quanah
--On Friday, January 25, 2019 9:25 PM + mich...@stroeder.com wrote:

> All links herein are dead:
> https://www.openldap.org/faq/data/cache/220.html
>
> I'd suggest to remove this FAQ page completely.

I tried, but unfortunatley the FAQ software breaks Apache when you try and 
delete an answer.  I think the better solution is just to remove the FAQ 
software completely.

--Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:







Re: (ITS#8988) Undefined Behavior in slapadd

2019-06-06 Thread quanah
--On Thursday, March 07, 2019 10:10 AM + noloa...@gmail.com wrote:

> Full_Name: JW
> Version: 2.4.47
> OS: Linux (Fedora 29, x86_64, fully patched)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (151.196.22.177)
>
>
> I added -fsanitize=undefined to CFLAGS.

Hello,

In this case, the compiler is the problem.  LMDB is 100% correct regarding 
alignment on all supported CPUs (which is most of them).  The x86 family 
fully supports unaligned access, so LMDB makes use of this.  On other CPUs, 
which do not support unaligned access (e.g., SPARC), LMDB doesn't use them.

This ITS will be closed.

--Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:







ITS#8994 published: SECURITY: OpenLdap (SyncRepl + Mirror Mode) issue

2019-06-06 Thread openldap-its
Private ITS#8994 is now publicly readable

URL: http://www.OpenLDAP.org/its/?findid=8994




ITS#8993 published: SECURITY: OpenLdap (SyncRepl + Mirror Mode) issue

2019-06-06 Thread openldap-its
Private ITS#8993 is now publicly readable

URL: http://www.OpenLDAP.org/its/?findid=8993




Re: (ITS#9029) MDB_MAP_FULL error after removing some records from DB

2019-06-06 Thread adubovkin
WW91J3JlIHJpZ2h0LiBJZiBJIHN0YXJ0IHdpdGggYSBtYXAgc2l6ZSBvZiAxME1CIEkgY2FuJ3Qg
cmVwcm9kdWNlIGl0IGFueW1vcmUgd2l0aCBteSB0ZXN0Lg0KVGhhbmtzIGZvciBjbGFyaWZ5aW5n
IGl0Lg0KDQpCZXN0IHdpc2hlcywNCkFsZXhleQ0KDQrvu79PbiA2LzUvMTksIDEyOjI5IFBNLCAi
UXVhbmFoIEdpYnNvbi1Nb3VudCIgPHF1YW5haEBzeW1hcy5jb20+IHdyb3RlOg0KDQogICAgLS1P
biBXZWRuZXNkYXksIEp1bmUgMDUsIDIwMTkgNzo1MyBQTSArMDAwMCBBbGV4ZXkgRHVib3ZraW4g
DQogICAgPGFkdWJvdmtpbkBsaW5rZWRpbi5jb20+IHdyb3RlOg0KICAgIA0KICAgID4gVGhhbmsg
eW91IQ0KICAgID4gQWxleGV5DQogICAgDQogICAgSGkgQWxleGV5LA0KICAgIA0KICAgIEFzIEhv
d2FyZCBhbHJlYWR5IG5vdGVkIGluIGhpcyByZXNwb25zZSB0byB0aGUgSVRTLCB0aGVyZSBpcyBu
byANCiAgICBkZW1vbnN0cmF0ZWQgYnVnIGhlcmUuICBJdCB3b3VsZCBhcHBlYXIgeW91J3ZlIHJ1
biBvdXQgb2YgZnJlZSBwYWdlcyBnaXZlbiANCiAgICB0aGUgbWFwc2l6ZSB5b3Ugc3RhcnRlZCB3
aXRoLiAgQXMgbm90ZWQgaW4gdGhlIGRvY3VtZW50YXRpb24sIHRoZSBnZW5lcmFsIA0KICAgIGV4
cGVjdGF0aW9uIGlzIG9uZSBzZXRzIGEgdmVyeSBsYXJnZSBtYXBzaXplIGZyb20gdGhlIHN0YXJ0
LiAgSG9wZSB0aGF0IA0KICAgIGhlbHBzIQ0KICAgIA0KICAgIC0tUXVhbmFoDQogICAgDQogICAg
DQogICAgDQogICAgLS0NCiAgICANCiAgICBRdWFuYWggR2lic29uLU1vdW50DQogICAgUHJvZHVj
dCBBcmNoaXRlY3QNCiAgICBTeW1hcyBDb3Jwb3JhdGlvbg0KICAgIFBhY2thZ2VkLCBjZXJ0aWZp
ZWQsIGFuZCBzdXBwb3J0ZWQgTERBUCBzb2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUDoNCiAg
ICA8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0
dHAlM0ElMkYlMkZ3d3cuc3ltYXMuY29tJmFtcDtkYXRhPTAyJTdDMDElN0NhZHVib3ZraW4lNDBs
aW5rZWRpbi5jb20lN0NjODkxMDQyNzM3OTQ0NjEzZWYyZDA4ZDZlOWVjMmJmOSU3QzcyZjk4OGJm
ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzElN0M2MzY5NTM1OTc4OTk3NDAxOTAmYW1w
O3NkYXRhPVRQcUVDY0lwJTJGcGFNQlJwSHlpOW03ZDk1R084NXk0ZEIzTU4xYUw1c1dsVSUzRCZh
bXA7cmVzZXJ2ZWQ9MD4NCiAgICANCiAgICANCg0K