Re: (ITS#8140) ssf is hard coded to log as zero, even if it is non-zero
by hyc＠symas.com
quanah(a)openldap.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: RE24
> OS: Linux 2.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.111.52.177)
>
>
> bind.c hard codes the output of the ssf= line in some of the stats logging to be
> zero, even if the connection actually has a higher ssf. For example:
Works as designed. The Bind op itself didn't provide any security, so it
contributed 0 to the session's ssf. The preceding StartTLS request actually
established a security layer, and it correctly logs the ssf from that.
Closing this ITS.
>
> May 11 02:28:06 ldap01 slapd[33839]: conn=153267 fd=86 TLS established
> tls_ssf=256 ssf=256 tls_proto=TLSv1 tls_cipher=AES256-SHA
> May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND
> dn="uid=zimbra,cn=admins,cn=zimbra" method=128
> May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND
> dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0%%0
> May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 RESULT tag=97 err=0 text=
>
>
> Note how we have mech=SIMPLE, ssf=0
>
> Since we ran startTLS, and it was established, we clearly do NOT have an ssf of
> zero. the ssf=0 bit is *hard coded* in bind.c in the fe_op_bind_success
> function:
>
> /* log authorization identity */
> Statslog( LDAP_DEBUG_STATS,
> "%s BIND dn=\"%s\" mech=%s ssf=0\n",
> op->o_log_prefix,
> op->o_conn->c_dn.bv_val, op->orb_mech.bv_val, 0, 0 );
>
>
> There's a similar block in do_bind for anonymous binds as well:
>
> if ( !BER_BVISEMPTY( &op->o_conn->c_dn ) ) {
> /* log authorization identity demotion */
> Statslog( LDAP_DEBUG_STATS,
> "%s BIND anonymous mech=implicit ssf=0\n",
> op->o_log_prefix, 0, 0, 0, 0 );
> }
>
> It likely should be changed to use:
>
> op->o_conn->c_ssf
>
>
>
--
-- 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, 10 months
(ITS#8140) ssf is hard coded to log as zero, even if it is non-zero
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: RE24
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.52.177)
bind.c hard codes the output of the ssf= line in some of the stats logging to be
zero, even if the connection actually has a higher ssf. For example:
May 11 02:28:06 ldap01 slapd[33839]: conn=153267 fd=86 TLS established
tls_ssf=256 ssf=256 tls_proto=TLSv1 tls_cipher=AES256-SHA
May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND
dn="uid=zimbra,cn=admins,cn=zimbra" method=128
May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND
dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0%%0
May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 RESULT tag=97 err=0 text=
Note how we have mech=SIMPLE, ssf=0
Since we ran startTLS, and it was established, we clearly do NOT have an ssf of
zero. the ssf=0 bit is *hard coded* in bind.c in the fe_op_bind_success
function:
/* log authorization identity */
Statslog( LDAP_DEBUG_STATS,
"%s BIND dn=\"%s\" mech=%s ssf=0\n",
op->o_log_prefix,
op->o_conn->c_dn.bv_val, op->orb_mech.bv_val, 0, 0 );
There's a similar block in do_bind for anonymous binds as well:
if ( !BER_BVISEMPTY( &op->o_conn->c_dn ) ) {
/* log authorization identity demotion */
Statslog( LDAP_DEBUG_STATS,
"%s BIND anonymous mech=implicit ssf=0\n",
op->o_log_prefix, 0, 0, 0, 0 );
}
It likely should be changed to use:
op->o_conn->c_ssf
7 years, 10 months
Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com
--On Monday, May 11, 2015 7:32 PM +0000 quanah(a)zimbra.com wrote:
> The existing entry drift seems to be related to the locked up replication
> that occured because of a bug in openssl. So the real issue is just the
> entries that weren't created, which is a current known limitation of
> syncrepl refresh that needs fixing.
Howard suggests that at least in the delta-syncrepl case, we can modify
syncprov to use the accesslog as the memory for its syncprov session log
rather than the session log used with standard syncrepl.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 10 months
Re: (ITS#8138) regarding some issues with SIDs
by quanah＠zimbra.com
--On Monday, May 11, 2015 8:35 AM +0000 nehadixit89(a)gmail.com wrote:
> Full_Name: neha dixit
> Version: 2.3
OpenLDAP 2.3 is not a supported piece of software. This ITS will be
closed. In addition, the ITS system is for reporting bugs, not general
usage questions. Please upgrade to a supported OpenLDAP release, and if
you have questions, follow up on the openldap-technical mailing list.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 10 months
Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com
--On Friday, May 08, 2015 7:56 PM +0000 quanah(a)zimbra.com wrote:
>
>
> --On May 4, 2015 at 8:00:45 PM +0000 openldap-its(a)OpenLDAP.org wrote:
>
>
> In addition to the missing entries, multiple differences exist for
> existing entries as well. At this point, it seems that replication with
> 2.4.41 is entirely unsafe.
The existing entry drift seems to be related to the locked up replication
that occured because of a bug in openssl. So the real issue is just the
entries that weren't created, which is a current known limitation of
syncrepl refresh that needs fixing.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 10 months
(ITS#8139) regarding some issues with SIDs
by nehadixit89＠gmail.com
Full_Name: neha dixit
Version: 2.3
OS: cent os 5.4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (122.160.18.128)
our previous employee has integrated samba with ldap and server is working
fine.
but now when i create new user using smbldap tools ,i m able to see them by
getent command.My main concern is that when i tried to logon on windows with the
same credentials and it prompts with error that device attached to this system
fails .
also when i check the issue in logs then it show that user sid is different
with primary group sid.also sid is changed in smbldap.conf file.
i m unable to troubleshoot that.i would be highly pleased if u solve my problem.
7 years, 10 months
(ITS#8138) regarding some issues with SIDs
by nehadixit89＠gmail.com
Full_Name: neha dixit
Version: 2.3
OS: cent os 5.4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (122.160.18.128)
our previous employee has integrated samba with ldap and server is working
fine.
but now when i create new user using smbldap tools ,i m able to see them by
getent command.My main concern is that when i tried to logon on windows with the
same credentials and it prompts with error that device attached to this system
fails .
also when i check the issue in logs then it show that user sid is different
with primary group sid.also sid is changed in smbldap.conf file.
i m unable to troubleshoot that.i would be highly pleased if u solve my problem.
7 years, 10 months
Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com
--On May 4, 2015 at 8:00:45 PM +0000 openldap-its(a)OpenLDAP.org wrote:
In addition to the missing entries, multiple differences exist for existing
entries as well. At this point, it seems that replication with 2.4.41 is
entirely unsafe.
@@ -187797,6 +187797,7 @@
zimbraAccountStatus: active
zimbraAuthTokens: 1001665890|1430683289367|8.6.0_GA_1153
zimbraAuthTokens: 1429612485|1430681470808|8.6.0_GA_1153
+zimbraAuthTokens: 1452180966|1430677629732|8.6.0_GA_1153
zimbraAuthTokens: 1844325568|1430677341824|8.6.0_GA_1153
zimbraAuthTokens: 1880697989|1430683571359|8.6.0_GA_1153
zimbraAuthTokens: 1954510867|1430680813216|8.6.0_GA_1153
@@ -187808,7 +187809,7 @@
zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62
zimbraCreateTimestamp: 20150427191452Z
zimbraId: c4cc5985-1727-4446-a196-1cbef2fd9e8a
-zimbraLastLogonTimestamp: 20150501182221Z
+zimbraLastLogonTimestamp: 20150501182703Z
zimbraMailDeliveryAddress: xyz(a)somewhere.com
zimbraMailHost: zm-mbs18.neonova.net
zimbraMailQuota: 16106127360
@@ -557800,6 +557801,7 @@
zimbraAuthTokens: 1153410464|1430794333078|8.6.0_GA_1153
zimbraAuthTokens: 1153875370|1430796671000|8.6.0_GA_1153
zimbraAuthTokens: 115391065|1430806341396|8.6.0_GA_1153
+zimbraAuthTokens: 1157520768|1430548147751|8.6.0_GA_1153
zimbraAuthTokens: 1187850134|1430806463699|8.6.0_GA_1153
zimbraAuthTokens: 1192041973|1430794095671|8.6.0_GA_1153
zimbraAuthTokens: 1200977988|1430807243978|8.6.0_GA_1153
@@ -557812,6 +557814,7 @@
zimbraAuthTokens: 1229145474|1430807429549|8.6.0_GA_1153
zimbraAuthTokens: 1230922062|1430797919322|8.6.0_GA_1153
zimbraAuthTokens: 1240838648|1430793498690|8.6.0_GA_1153
+zimbraAuthTokens: 1245512453|1430548279974|8.6.0_GA_1153
zimbraAuthTokens: 1256797348|1430790405205|8.6.0_GA_1153
zimbraAuthTokens: 125774918|1430789944147|8.6.0_GA_1153
zimbraAuthTokens: 1257992365|1430800900512|8.6.0_GA_1153
@@ -557821,6 +557824,7 @@
zimbraAuthTokens: 1291211579|1430793942471|8.6.0_GA_1153
zimbraAuthTokens: 1294660932|1430796182543|8.6.0_GA_1153
zimbraAuthTokens: 1299240495|1430807682002|8.6.0_GA_1153
+zimbraAuthTokens: 1303662472|1430548232316|8.6.0_GA_1153
zimbraAuthTokens: 1309389194|1430801132708|8.6.0_GA_1153
zimbraAuthTokens: 1316038520|1430802345713|8.6.0_GA_1153
zimbraAuthTokens: 1323416810|1430775076568|8.6.0_GA_1153
@@ -557888,6 +557892,7 @@
zimbraAuthTokens: 1546458862|1430782672619|8.6.0_GA_1153
zimbraAuthTokens: 155006363|1430792026242|8.6.0_GA_1153
zimbraAuthTokens: 1554772102|1430787555656|8.6.0_GA_1153
+zimbraAuthTokens: 1555500886|1430548271932|8.6.0_GA_1153
zimbraAuthTokens: 1560251088|1430793442122|8.6.0_GA_1153
zimbraAuthTokens: 1560280871|1430777440334|8.6.0_GA_1153
zimbraAuthTokens: 1561800299|1430806414358|8.6.0_GA_1153
@@ -557929,6 +557934,7 @@
zimbraAuthTokens: 1713221378|1430795062424|8.6.0_GA_1153
zimbraAuthTokens: 1714081224|1430794690175|8.6.0_GA_1153
zimbraAuthTokens: 1719102352|1430787580315|8.6.0_GA_1153
+zimbraAuthTokens: 1721546851|1430548275954|8.6.0_GA_1153
zimbraAuthTokens: 1722045342|1430794777719|8.6.0_GA_1153
zimbraAuthTokens: 1728013476|1430807125376|8.6.0_GA_1153
zimbraAuthTokens: 1730079937|1430800179238|8.6.0_GA_1153
@@ -557939,6 +557945,7 @@
zimbraAuthTokens: 1745425399|1430796457601|8.6.0_GA_1153
zimbraAuthTokens: 1752670040|1430789168438|8.6.0_GA_1153
zimbraAuthTokens: 1760000546|1430796630874|8.6.0_GA_1153
+zimbraAuthTokens: 1760771363|1430548094582|8.6.0_GA_1153
zimbraAuthTokens: 1764080232|1430788720545|8.6.0_GA_1153
zimbraAuthTokens: 1764393930|1430769111435|8.6.0_GA_1153
zimbraAuthTokens: 1767121722|1430800106951|8.6.0_GA_1153
@@ -557961,9 +557968,11 @@
zimbraAuthTokens: 1818662300|1430785463584|8.6.0_GA_1153
zimbraAuthTokens: 1819397934|1430784129509|8.6.0_GA_1153
zimbraAuthTokens: 1825833485|1430792892690|8.6.0_GA_1153
+zimbraAuthTokens: 1826263844|1430548283971|8.6.0_GA_1153
zimbraAuthTokens: 1826635337|1430783161924|8.6.0_GA_1153
zimbraAuthTokens: 1828370704|1430798363104|8.6.0_GA_1153
zimbraAuthTokens: 184971068|1430794694175|8.6.0_GA_1153
+zimbraAuthTokens: 1852733329|1430548280003|8.6.0_GA_1153
zimbraAuthTokens: 1854808177|1430794699578|8.6.0_GA_1153
zimbraAuthTokens: 1856036969|1430801152796|8.6.0_GA_1153
zimbraAuthTokens: 1856540960|1430796150392|8.6.0_GA_1153
@@ -558010,6 +558019,7 @@
zimbraAuthTokens: 2030397720|1430788935660|8.6.0_GA_1153
zimbraAuthTokens: 2033511890|1430788572002|8.6.0_GA_1153
zimbraAuthTokens: 2035641769|1430800861823|8.6.0_GA_1153
+zimbraAuthTokens: 20415307|1430547981772|8.6.0_GA_1153
zimbraAuthTokens: 2042478638|1430807440122|8.6.0_GA_1153
zimbraAuthTokens: 2053877671|1430796197464|8.6.0_GA_1153
zimbraAuthTokens: 2059018018|1430796466336|8.6.0_GA_1153
@@ -558060,6 +558070,7 @@
zimbraAuthTokens: 335636684|1430792575890|8.6.0_GA_1153
zimbraAuthTokens: 335985202|1430801830053|8.6.0_GA_1153
zimbraAuthTokens: 345836372|1430800522916|8.6.0_GA_1153
+zimbraAuthTokens: 353782778|1430548279978|8.6.0_GA_1153
zimbraAuthTokens: 357224412|1430799078650|8.6.0_GA_1153
zimbraAuthTokens: 359847881|1430806579447|8.6.0_GA_1153
zimbraAuthTokens: 364380894|1430784519780|8.6.0_GA_1153
@@ -558086,6 +558097,7 @@
zimbraAuthTokens: 464892423|1430792026225|8.6.0_GA_1153
zimbraAuthTokens: 465832041|1430796118188|8.6.0_GA_1153
zimbraAuthTokens: 470587431|1430790706176|8.6.0_GA_1153
+zimbraAuthTokens: 488520030|1430548271921|8.6.0_GA_1153
zimbraAuthTokens: 493433000|1430789116600|8.6.0_GA_1153
zimbraAuthTokens: 49927151|1430800597298|8.6.0_GA_1153
zimbraAuthTokens: 505233009|1430803732532|8.6.0_GA_1153
@@ -558119,6 +558131,7 @@
zimbraAuthTokens: 624216082|1430790986205|8.6.0_GA_1153
zimbraAuthTokens: 627453014|1430802588253|8.6.0_GA_1153
zimbraAuthTokens: 63479916|1430800763552|8.6.0_GA_1153
+zimbraAuthTokens: 636439348|1430548271924|8.6.0_GA_1153
zimbraAuthTokens: 638569970|1430766646718|8.6.0_GA_1153
zimbraAuthTokens: 642528535|1430793436206|8.6.0_GA_1153
zimbraAuthTokens: 653581266|1430803568548|8.6.0_GA_1153
@@ -558131,12 +558144,14 @@
zimbraAuthTokens: 674880688|1430790542019|8.6.0_GA_1153
zimbraAuthTokens: 678557445|1430792426265|8.6.0_GA_1153
zimbraAuthTokens: 688306806|1430789944170|8.6.0_GA_1153
+zimbraAuthTokens: 692909864|1430548275944|8.6.0_GA_1153
zimbraAuthTokens: 695873279|1430791878331|8.6.0_GA_1153
zimbraAuthTokens: 702220076|1430791770891|8.6.0_GA_1153
zimbraAuthTokens: 702905805|1430793051338|8.6.0_GA_1153
zimbraAuthTokens: 703978454|1430801188894|8.6.0_GA_1153
zimbraAuthTokens: 704499344|1430797009784|8.6.0_GA_1153
zimbraAuthTokens: 709844890|1430790284534|8.6.0_GA_1153
+zimbraAuthTokens: 712623687|1430548275943|8.6.0_GA_1153
zimbraAuthTokens: 714322774|1430801693731|8.6.0_GA_1153
zimbraAuthTokens: 714539921|1430794312192|8.6.0_GA_1153
zimbraAuthTokens: 719501426|1430806353190|8.6.0_GA_1153
@@ -906794,14 +906809,20 @@
uid: something
userPassword:: a hash
zimbraAccountStatus: active
+zimbraAuthTokens: 1076665182|1430495517704|8.6.0_GA_1153
+zimbraAuthTokens: 1194289445|1430495472230|8.6.0_GA_1153
+zimbraAuthTokens: 1400191457|1430488755054|8.6.0_GA_1153
zimbraAuthTokens: 1446436024|1430910444064|8.6.0_GA_1153
zimbraAuthTokens: 1494232116|1430754183294|8.6.0_GA_1153
zimbraAuthTokens: 1548373083|1430859654841|8.6.0_GA_1153
+zimbraAuthTokens: 1549007812|1430488727192|8.6.0_GA_1153
zimbraAuthTokens: 1586033245|1430759173317|8.6.0_GA_1153
zimbraAuthTokens: 1751858048|1430924809541|8.6.0_GA_1153
+zimbraAuthTokens: 1800356229|1430488677708|8.6.0_GA_1153
zimbraAuthTokens: 2062630693|1430852313888|8.6.0_GA_1153
zimbraAuthTokens: 480907313|1430754137307|8.6.0_GA_1153
zimbraAuthTokens: 718652654|1430852353198|8.6.0_GA_1153
+zimbraAuthTokens: 800231695|1430488640026|8.6.0_GA_1153
zimbraAuthTokens: 911489049|1430919384737|8.6.0_GA_1153
zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62
zimbraCreateTimestamp: 20150407152511Z
@@ -2342424,13 +2342445,11 @@
uid: something
userPassword:: a hash
zimbraAccountStatus: active
-zimbraAuthTokens: 1032074923|1430678006084|8.6.0_GA_1153
-zimbraAuthTokens: 1359481243|1430678139287|8.6.0_GA_1153
zimbraAuthTokens: 1367205599|1430685608493|8.6.0_GA_1153
zimbraAuthTokens: 146136864|1430743294805|8.6.0_GA_1153
-zimbraAuthTokens: 1583721154|1430678002509|8.6.0_GA_1153
zimbraAuthTokens: 1938799710|1430831569979|8.6.0_GA_1153
-zimbraAuthTokens: 326869791|1430678012645|8.6.0_GA_1153
+zimbraAuthTokens: 1986204084|1430485163391|8.6.0_GA_1153
+zimbraAuthTokens: 701958474|1430488599819|8.6.0_GA_1153
zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62
zimbraCreateTimestamp: 20150311184123Z
zimbraCsrfTokenData: data
@@ -2977160,8 +2977179,8 @@
uid: something
userPassword: a hash
zimbraAccountStatus: active
-zimbraAuthTokens: 1592805688|1430678263487|8.6.0_GA_1153
zimbraAuthTokens: 1840536155|1430747750113|8.6.0_GA_1153
+zimbraAuthTokens: 297688289|1430677809486|8.6.0_GA_1153
zimbraAuthTokens: 447463167|1430585978383|8.6.0_GA_1153
zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62
zimbraCreateTimestamp: 20150407152611Z
@@ -4051413,7 +4051432,6 @@
uid: something
userPassword:: a hash
zimbraAccountStatus: active
-zimbraAuthTokens: 1906714231|1430457251759|8.6.0_GA_1153
zimbraAuthTokens: 637421329|1430881121421|8.6.0_GA_1153
zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62
zimbraCreateTimestamp: 20150324191333Z
@@ -5306187,7 +5306205,6 @@
userPassword:: a hash
zimbraAccountStatus: active
zimbraAuthTokens: 1215263276|1430662360810|8.6.0_GA_1153
-zimbraAuthTokens: 2103162606|1430678212226|8.6.0_GA_1153
zimbraAuthTokens: 31692696|1430712827710|8.6.0_GA_1153
zimbraAuthTokens: 496395190|1430702599395|8.6.0_GA_1153
zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62
@@ -7689287,6 +7689304,7 @@
userPassword:: a hash
zimbraAccountStatus: active
zimbraAuthTokens: 1361047436|1430788305556|8.6.0_GA_1153
+zimbraAuthTokens: 1379747754|1430499334346|8.6.0_GA_1153
zimbraAuthTokens: 1584426902|1430875712010|8.6.0_GA_1153
zimbraAuthTokens: 1927293924|1430875661923|8.6.0_GA_1153
zimbraAuthTokens: 979685923|1430788353488|8.6.0_GA_1153
@@ -8198997,8 +8199015,10 @@
uid: something
userPassword:: a hash
zimbraAccountStatus: active
+zimbraAuthTokens: 111522850|1430323733525|8.6.0_GA_1153
zimbraAuthTokens: 1643425923|1430886776671|8.6.0_GA_1153
zimbraAuthTokens: 1728545135|1430720880858|8.6.0_GA_1153
+zimbraAuthTokens: 757970470|1430493817783|8.6.0_GA_1153
zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62
zimbraCreateTimestamp: 20150415194756Z
zimbraId: 5147a109-a13b-4264-985e-c1e4999261da
@ -9048815,7 +9048835,6 @@
uid: something
userPassword:: a hash
zimbraAccountStatus: active
-zimbraAuthTokens: 820727281|1430672042988|8.6.0_GA_1153
zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62
zimbraCreateTimestamp: 20150311185757Z
zimbraCsrfTokenData:
69643d33363a65643532303936632d636336392d346136362d626137342d3937366538643337616365363b6578703d31333a313432383738303434383930303b7369643d31303a2d3730363739343338353b:f0a19918939e46e2a5a1b69ba91
710de:1428780448900
@@ -12477050,12 +12477043,12 @@
createTimestamp: 20141208203040Z
creatorsName: uid=zimbra,cn=admins,cn=zimbra
displayName: something
-entryCSN: 20150426144745.317031Z#000000#001#000000
+entryCSN: 20150501183105.859472Z#000000#002#000000
entryUUID: d1d1f11e-1364-1034-8f85-d75f97c57676
givenName: something
mail: someone(a)somewhere.net
modifiersName: uid=zimbra,cn=admins,cn=zimbra
-modifyTimestamp: 20150426144745Z
+modifyTimestamp: 20150501183105Z
objectClass: amavisAccount
objectClass: inetOrgPerson
objectClass: zimbraAccount
(etc)
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 10 months
Re: (ITS#8127) 32 bit windows build fails with mingw
by hyc＠symas.com
ebackes(a)symas.com wrote:
> Hello, Frank.
>
>> thanks for your patch. But since I am compilling 32 Bit, it doesn't work.
>> I modified your patch to
>> #define ftello ftell
>> Then it works.
>
> Hm; that should work on 32bit windows. (it does for me!)
As I already noted, ftelli64's availability depends on the version of the
MSVCRT DLL on the system. Frank's MinGW is apparently too old to contain the
ftelli64 symbol in the libmsvcrt import library.
> Using
> ftell() will limit you to 2GB files. Then again, that particular case
> is only for proress-reporting. If your LDIF to be slapadd'd is less
> than 2GB, it won't matter.
>
>> But I still have the GetFileSizeEx problem.
>> I use MinGW-5.1.6 and here is my installed.ini:
>
> I'll have to try that. In the mean time, I've had more success
> building with the version from winbuilds.org.
Always quote specific version numbers.
The MSYS I use is
MINGW32_NT-6.1 VIEL64 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys
I'm using MinGW from mingw-w64 (builds both 32 and 64 bit binaries) version
1.0.8.
http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/
--
-- 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, 10 months
Re: (ITS#8127) 32 bit windows build fails with mingw
by hyc＠symas.com
Frank.Offermanns(a)caseris.de wrote:
> Dies ist eine mehrteilige Nachricht im MIME-Format.
> --=_alternative 00233070C1257E3D_=
> Content-Type: text/plain; charset="US-ASCII"
>
> Hi,
>
> thanks for your patch. But since I am compilling 32 Bit, it doesn't work.
> I modified your patch to
> #define ftello ftell
> Then it works.
But that will only work for input LDIF files smaller than 4GB.
A better fix is now committed in git master.
>
> But I still have the GetFileSizeEx problem.
GetFileSizeEx is a part of the Win32 API since Windows XP.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364957%28v=vs....
Sounds like your MinGW is too old or needs a fix. There is nothing to fix in
OpenLDAP source for this problem.
This ITS is now resolved.
> I use MinGW-5.1.6 and here is my installed.ini:
> [settings]
> mirror=
> installtype=current
>
> [components]
> runtime=mingwrt-3.17-mingw32-dev.tar.gz
> w32api=w32api-3.14-mingw32-dev.tar.gz
> binutils=binutils-2.20-1-mingw32-bin.tar.gz
> core=gcc-core-3.4.5-20060117-3.tar.gz
> gpp=gcc-g++-3.4.5-20060117-3.tar.gz
> g77=
> ada=
> java=
> objc=gcc-objc-3.4.5-20060117-3.tar.gz
> make=make-3.81-20090914-mingw32-bin.tar.gz
> runtimeDLL=mingwrt-3.17-mingw32-dll.tar.gz
>
> Regards,
> Frank
>
>
--
-- 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, 10 months
