Re: (ITS#8338) LMDB build fail by using MinGW
by hyc＠symas.com
ray2501(a)gmail.com wrote:
> Full_Name: Danilo Chang
> Version:
> OS: Windows 7
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (61.66.209.161)
>
>
> ITS#8324 "incremental DB file growth for Windows add APIs" add APIs defined in
> <wdm.h> and <ntifs.h> but not define NTSTATUS type in LMDB mdb.c, result in
> build fail by using MinGW or MinGW-w64.
>
> Please add NTSTATUS type definition in LMDB mdb.c.
>
> Below is a quick fix:
> typedef LONG NTSTATUS;
>
>
Seems you have a very old version of MinGW. Builds fine for me using MSYS2 as
well as MSYS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 11 months
(ITS#8338) LMDB build fail by using MinGW
by ray2501＠gmail.com
Full_Name: Danilo Chang
Version:
OS: Windows 7
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (61.66.209.161)
ITS#8324 "incremental DB file growth for Windows add APIs" add APIs defined in
<wdm.h> and <ntifs.h> but not define NTSTATUS type in LMDB mdb.c, result in
build fail by using MinGW or MinGW-w64.
Please add NTSTATUS type definition in LMDB mdb.c.
Below is a quick fix:
typedef LONG NTSTATUS;
7 years, 11 months
Re: (ITS#7100) slapo-dds: entryTTL not decreasing
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms070404020000010803010601
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
ondra(a)mistotebe.net wrote:
> when watching the entries, they seem to be updating in real time for me=
> as expected, do you have a cache of some sort between you and the serve=
r?
Ah, sorry!
web2ldap has a short-time cache and I have to investiate why the URL argu=
ment
read_nocache=3D1 currently doesn't have any effect. :-/
Ok, your fix seems perfectly right.
Ciao, Michael.
--------------ms070404020000010803010601
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw
FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp
Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb
BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0
cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX
8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR
+yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp
9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0
AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu
9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw
CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU
ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw
HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG
CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v
cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB
dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg
dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g
Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w
LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB
BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j
bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j
ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j
Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E
vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el
8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i
nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT
jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw
CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG
A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp
bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi
p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f
tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW
oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/
43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB
rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc
4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG
AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G
CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw
UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw
Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB
AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0
BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN
BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb
WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4
OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0
KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0
4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0
IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6
fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt
jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4
8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI
XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB
ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t
IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD
BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1
MTIxNjE1MTczMVowLwYJKoZIhvcNAQkEMSIEIC6fWNjcqiPmnbSv0ZBciEkxY7yK5wypFDoy
5rFc29yQMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy
bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQCVWQT/K8Pu5yMaLZVS
tAseReEGBO1o1hu/1MHsup+WHyzyv20GdHickBH8E8dNo9pWLN37Zx/8akxd0ose2tFMdnJE
/VH3HdTItKFQdcjR7/iUsELefikY1GhfDF4stCCIrmzMDai8bgrnsZwiGbs/EN5rPakAvxKI
b8OKvbjLD2cXGHitZ/t5J4bOk7we5cHyaynbIj3AwOzTroGCrF9PUlfvqR9MPdjRiCreUvju
w9a8h3SQIhMpwpDMaYbO4v/Udqf2ytBrN8Gi4SX+u67BzIkA7sPZ+3c688X+90NCay525lMp
h1OLWeW6TJhbaaqBoTJ6zJNKcIBExIA91RIMAAAAAAAA
--------------ms070404020000010803010601--
7 years, 11 months
Re: (ITS#8291) ./run -b hdb test007 fails
by michael＠stroeder.com
michael(a)stroeder.com wrote:
> But ./run -b mdb test062 fails with:
> ldapsearch should have failed with Critical extension is unavailable (12)!
> ./scripts/test062-config-delete: line 164: kill: (18467) - No such process
>
> Likely the latter is unrelated.
test062 fails *sometimes* also with upstream git master (see ITS#8151).
So your solution for test007 seems to be ok.
Ciao, Michael.
7 years, 11 months
Re: (ITS#8291) ./run -b hdb test007 fails
by michael＠stroeder.com
ondra(a)mistotebe.net wrote:
> looks like an issue similar to the one fixed in
> ITS#7256, this time it is only BerkeleyDB 4.8 that seems to complain
> (have not tested with 4.7).
>
> Can you test with the latest commit at branch ITS8291 in my github repo
> (https://github.com/mistotebe/openldap)?
I've tested your branch ITS8291 with this commit:
commit 47b7a1e29586793e87cacfa10fc50e2fc9d44b5f
Author: Ondřej Kuzník <ondra(a)mistotebe.net>
Date: Wed Dec 16 13:47:17 2015 +0100
ITS#8291 Reopen cursor after delete
./run -b hdb test007 works perfectly now.
But ./run -b mdb test062 fails with:
ldapsearch should have failed with Critical extension is unavailable (12)!
./scripts/test062-config-delete: line 164: kill: (18467) - No such process
Likely the latter is unrelated.
Ciao, Michael.
7 years, 11 months
Re: (ITS#7100) slapo-dds: entryTTL not decreasing
by ondra＠mistotebe.net
On Sat, Dec 12, 2015 at 06:50:12PM +0000, michael(a)stroeder.com wrote:
> ondra(a)mistotebe.net wrote:
>> On Tue, Jul 22, 2014 at 07:38:26PM +0000, michael(a)stroeder.com wrote:
>>> Would be nice if this gets ever fixed to match the RFC.
>>
>> Hi, can you test the changes in branch ITS7100 at
>> https://github.com/mistotebe/openldap?
>
> Sorry for following up so late.
>
> I've tested your branch.
>
> 2. entryTTL seems now to be decreased
>
> It seems that when re-reading an entry the entryTTL is not always computed on
> the fly. Rather the value is decreased every ~6 seconds (not matching dds-interval).
Hi,
when watching the entries, they seem to be updating in real time for me
as expected, do you have a cache of some sort between you and the server?
Cheers,
Ondrej
7 years, 11 months
Re: (ITS#8291) ./run -b hdb test007 fails
by ondra＠mistotebe.net
On Sat, Dec 12, 2015 at 07:11:43PM +0000, michael(a)stroeder.com wrote:
> ondra(a)mistotebe.net wrote:
> > On Tue, Oct 27, 2015 at 09:50:10AM +0000, michael(a)stroeder.com wrote:
> >> Strange: testrun/test.out has zero bytes. :-/
> >> But the DB files are created.
> >>
> >> Other tests with -b hdb seem to work ok.
> >> Maybe it's just the test script?
> >
> > I've let slapmodify honour logging settings in branch ITS8291 at
> > https://github.com/mistotebe/openldap, could you paste the output of
> > test.out with that enabled and possibly loglevel set to -1?
>
> See test.out here:
>
> http://www.stroeder.com/temp/openldap-its8291-test_out.gz
Hi,
thanks for the logs, looks like an issue similar to the one fixed in
ITS#7256, this time it is only BerkeleyDB 4.8 that seems to complain
(have not tested with 4.7).
Can you test with the latest commit at branch ITS8291 in my github repo
(https://github.com/mistotebe/openldap)?
Thanks,
Ondrej
7 years, 11 months
RE: (ITS#8337) olcDbChecksum not allowed in olcHdbConfig/olcBdbConfig
by kenneth.penza＠gov.mt
>From: Howard Chu [mailto:hyc@symas.com]=20
>Sent: Saturday, 12 December 2015 17:15
>To: Penza Kenneth at MITA; openldap-its(a)OpenLDAP.org
>Subject: Re: (ITS#8337) olcDbChecksum not allowed in olcHdbConfig/olcBdbCo=
nfig
>
>kenneth.penza(a)gov.mt wrote:
>> Full_Name: Kenneth Penza
>> Version: 2.4.43
>> OS: CentOS 7.1
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (46.11.36.84)
>>
>>
>> olcDbChecksum is not accepted for BDB and HDB backends (whilst its=20
>> documented in the manual pages). Below please find files and steps to re=
produce.
>
>Thanks for the report, fixed now in git master.
>>
>> File attached:
>>
>> configbdb.ldif - ldif file to create config database with BDB backend=20
>> and checksum enabled. Uploaded in=20
>> ftp://ftp.openldap.org/incoming/kenneth-penza-151212-configbdb.ldif
>>
>> confighdb.ldif - ldif file to create config database with HDB backend=20
>> and checksum enabled. Uploaded in=20
>> ftp://ftp.openldap.org/incoming/kenneth-penza-151212-confighdb.ldif
>>
>> Test case:
>>
>> mkdir -p /tmp/dummyconfig/slapd.d.{b,h}db cd /tmp/dummyconfig
>>
>> slapadd -v -F slapd.d.bdb -n 0 -l configbdb.ldif slapadd -v -F=20
>> slapd.d.hdb -n 0 -l confighdb.ldif
>>
>>
>> For BDB it reports:
>>
>> 566c3f04 Entry (olcDatabase=3D{2}bdb,cn=3Dconfig), attribute=20
>> 'olcDbChecksum' not allowed
>> slapadd: dn=3D"olcDatabase=3D{2}bdb,cn=3Dconfig" (line=3D1070): (65) att=
ribute=20
>> 'olcDbChecksum' not allowed
>>
>> For HDB it reports:
>>
>> 566c41e2 Entry (olcDatabase=3D{2}hdb,cn=3Dconfig), attribute=20
>> 'olcDbChecksum' not allowed
>> slapadd: dn=3D"olcDatabase=3D{2}hdb,cn=3Dconfig" (line=3D1070): (65) att=
ribute=20
>> 'olcDbChecksum' not allowed
>>
>> Kenneth
>>
>>
>
>
>--=20
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
I have pulled the sources that had the fix from the git repository and reco=
mpiled openldap. Following the patch, config creation worked fine.
To verify that it is working as expected, I tested with the olcDbChecksum s=
et to true/false and verified the checksum flag of the database created as =
per below output.
For both BDB/HDB backends, olcDbChecksum set to true, removed all files und=
er /var/lib/ldap/* and started server to re-create database.
[root@host01 ldap]# db_dump /var/lib/ldap/dn2id.bdb=20
VERSION=3D3
format=3Dbytevalue
type=3Dbtree
chksum=3D1
duplicates=3D1
dupsort=3D1
db_pagesize=3D4096
HEADER=3DEND
DATA=3DEND
[root@host01 ldap]#=20
For both BDB/HDB backends, olcDbChecksum set to false, removed all files un=
der /var/lib/ldap/* and started server to re-create database.
[root@host01 ldap]# db_dump /var/lib/ldap/dn2id.bdb=20
VERSION=3D3
format=3Dbytevalue
type=3Dbtree
duplicates=3D1
dupsort=3D1
db_pagesize=3D4096
HEADER=3DEND
DATA=3DEND
[root@host01 ldap]#=20
>From the output above, it is working as expected. Thanks for your prompt su=
pport and patch.
Regards
Kenneth
7 years, 11 months
Re: (ITS#7992) lmdb: Windows: assume file paths are UTF-8, encode to UTF-16 for WinAPI and enable compiling when UNICODE is defined
by h.b.furuseth＠usit.uio.no
On 20/11/15 02:16, hyc(a)symas.com wrote:
>> Also use CreateFileW to open files so that one can use exotic characters in
>> paths. The library interface is not modified, but the code makes an assumption
>> that paths passed to lmdb functions are encoded as UTF-8. The UTF-8 encoded
>> paths are encoded to UTF-16 which is then passed to CreateFileW.
>
> This patch is now in git mdb.master.
Needs cleanup:
utf8_to_utf16() ignores errors in malloc/MultiByteToWideChar().
utf8_to_utf16()'s callers ignore error returns.
utf8_to_utf16() can return EILSEQ, an errno code not listed in
mdb_strerror(). It should return a Windows error code or a new
MDB_<SOMETHING> code.
(LMDB returns LDMB codes or system error codes. The latter are
errno codes on Unix and Windows codes on Windows - except
mdb_strerror's hardcoded errno codes which we plan to get rid of.)
7 years, 11 months
