3:38 p.m.
There are three options between back-ldap, back-meta, and back-asyncmeta
that seem to have an incorrect defintion for cn=config and/or a
documentation bug.
For back-ldap:
idle-timeout -> The man page says takes an integer, but is defined as a
string. However, I think the man page for this parameter is incorrect, and
in fact it takes a possible string as defined in the back-meta/async manual
pages for this same parameter. (I.e, it can have a format of something like
1d15h5s)
For back-ldap, back-meta, and back-asyncmeta:
network-timeout -> This takes an integer, but is defined as a string. The
back-ldap, back-meta, and back-asyncmeta man pages says it uses the same
format as idle-timeout, but the function that parses the value does not
agree with assertion. It appears to take only accept an integer.
For back-meta and back-asyncmeta:
bind-timeout -> This is clearly described in the man page as a taking an
integer value, but it is defined as a string. Any objection to me changing
it to be an integer type?
Thanks!
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
1:44 p.m.
Quanah Gibson-Mount wrote:
There are three options between back-ldap, back-meta, and
back-asyncmeta that
seem to have an incorrect defintion for cn=config and/or a documentation bug.
For back-ldap:
idle-timeout -> The man page says takes an integer, but is defined as a
string. However, I think the man page for this parameter is incorrect, and in
fact it takes a possible string as defined in the back-meta/async manual pages
for this same parameter. (I.e, it can have a format of something like 1d15h5s)
I don't see this. The man page says "<time>". It looks correct to me.
For back-ldap, back-meta, and back-asyncmeta:
network-timeout -> This takes an integer, but is defined as a string. The
back-ldap, back-meta, and back-asyncmeta man pages says it uses the same
format as idle-timeout, but the function that parses the value does not agree
with assertion. It appears to take only accept an integer.
Looks to me like it uses lutil_parse_time, same as idle-timeout.
But in back-meta network-timeout is displayed as an integer, while
idle-timeout uses lutil_unparse_time. network-timeout probably should be using
unparse_time as well.
For back-meta and back-asyncmeta:
bind-timeout -> This is clearly described in the man page as a taking an
integer value, but it is defined as a string. Any objection to me changing it
to be an integer type?
I guess that's OK.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:49 p.m.
On 06/14/2018 10:44 PM, Howard Chu wrote:
Quanah Gibson-Mount wrote:
> idle-timeout -> The man page says takes an integer, but is defined as
> a string. However, I think the man page for this parameter is
> incorrect, and in fact it takes a possible string as defined in the
> back-meta/async manual pages for this same parameter. (I.e, it can
> have a format of something like 1d15h5s)
I don't see this. The man page says "<time>". It looks correct to me.
Wouldn't it be better to consequently convert time strings such as
1d15h5s to integer seconds during migration of static config to dynamic
config? IMO for LDAP-on-the-wire those values should always be integer
representing seconds (or milli-seconds if needed).
I mean back-config content is meant to be machine-processable and
cleaner syntax would reduce unneeded complexity.
Ciao, Michael.
2:58 p.m.
Michael Ströder wrote:
On 06/14/2018 10:44 PM, Howard Chu wrote:
> Quanah Gibson-Mount wrote:
>> idle-timeout -> The man page says takes an integer, but is defined as
>> a string. However, I think the man page for this parameter is
>> incorrect, and in fact it takes a possible string as defined in the
>> back-meta/async manual pages for this same parameter. (I.e, it can
>> have a format of something like 1d15h5s)
>
> I don't see this. The man page says "<time>". It looks correct to
me.
Wouldn't it be better to consequently convert time strings such as
1d15h5s to integer seconds during migration of static config to dynamic
config? IMO for LDAP-on-the-wire those values should always be integer
representing seconds (or milli-seconds if needed).
I mean back-config content is meant to be machine-processable and
cleaner syntax would reduce unneeded complexity.
The complexity is already there, and obviously somebody thought it was
desirable for these things to be human-readable. We're doing them no favors by
converting to straight integers.
Of course, I would have preferred something like DD+HH:MM:SS instead of this
XdYhZs format, but no, we're not going to change the expected input syntax
after the fact.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3:04 p.m.
On 06/14/2018 11:58 PM, Howard Chu wrote:
Michael Ströder wrote:
> On 06/14/2018 10:44 PM, Howard Chu wrote:
>> Quanah Gibson-Mount wrote:
>>> idle-timeout -> The man page says takes an integer, but is defined as
>>> a string. However, I think the man page for this parameter is
>>> incorrect, and in fact it takes a possible string as defined in the
>>> back-meta/async manual pages for this same parameter. (I.e, it can
>>> have a format of something like 1d15h5s)
>>
>> I don't see this. The man page says "<time>". It looks
correct to me.
>
> Wouldn't it be better to consequently convert time strings such as
> 1d15h5s to integer seconds during migration of static config to dynamic
> config? IMO for LDAP-on-the-wire those values should always be integer
> representing seconds (or milli-seconds if needed).
>
> I mean back-config content is meant to be machine-processable and
> cleaner syntax would reduce unneeded complexity.
The complexity is already there, and obviously somebody thought it was
desirable for these things to be human-readable. We're doing them no
favors by converting to straight integers.
It's not only about the complexity in OpenLDAP software itself. All
3rd-party components which want to make use of back-config for automated
configuration have to deal with it. And that's not going to happen.
Ciao, Michael.
3:17 p.m.
--On Thursday, June 14, 2018 10:44 PM +0100 Howard Chu <hyc(a)symas.com>
wrote:
> For back-ldap:
>
> idle-timeout -> The man page says takes an integer, but is defined as a
> string. However, I think the man page for this parameter is incorrect,
> and in fact it takes a possible string as defined in the
> back-meta/async manual pages for this same parameter. (I.e, it can have
> a format of something like 1d15h5s)
I don't see this. The man page says "<time>". It looks correct to me.
Yeah, I think my eyes were glazing over at that point and I read "time" as
"seconds". ;)
> For back-ldap, back-meta, and back-asyncmeta:
>
> network-timeout -> This takes an integer, but is defined as a string.
> The back-ldap, back-meta, and back-asyncmeta man pages says it uses the
> same format as idle-timeout, but the function that parses the value
> does not agree with assertion. It appears to take only accept an
> integer.
Looks to me like it uses lutil_parse_time, same as idle-timeout.
But in back-meta network-timeout is displayed as an integer, while
idle-timeout uses lutil_unparse_time. network-timeout probably should be
using unparse_time as well.
Fixed in my latest commit.
> For back-meta and back-asyncmeta:
>
> bind-timeout -> This is clearly described in the man page as a taking an
> integer value, but it is defined as a string. Any objection to me
> changing it to be an integer type?
Fixed in latest commit.
Please review (link at the end). The following illustrates the choices I
made. The ones marked "DELETE" will be removed under a later ITS I need to
file. I'm still unsure what to do with olcTLSCertificateKey since it uses
a private OID for its SYNTAX which doesn't seem to have an associated
equality matching rule.
---------------- servers/slapd/bconfig.c -----------------------
olcConfigFile -- Changed to case exact match
olcConfigDir -- Changed to case exact match
olcArgsFile -- Changed to case exact match
olcLogFile -- case exact match
olcModulePath -- case exact match
olcPasswordCryptSaltFormat -- case ignore match
olcPidFile -- case exact match
olcPluginLogFile -- case exact match
olcRootPw -- octetStringMatch
olcSaslAuxprops -- case ignore match
olcSaslHost -- case ignore match
olcSaslRealm -- case exact match
olcSaslSecProps -- case exact match
olcSizeLimit -- case exact match
olcSubordinate -- case exact match
olcTCPBuffer -- case exact match
olcTimeLimit -- case exact match
olcTLSCACertificateFile -- case exact match
olcTLSCACertificatePath -- case exact match
olcTLSCertificateFile -- case exact match
olcTLSCertificateKey -- ??? (Private SYNTAX OID) Shouldn't the SYNTAX be
1.3.6.1.4.1.1466.115.121.1.8? And use certificateExactMatch?
olcTLSCertificateKeyFile -- case exact match
olcTLSCipherSuite -- case exact match
olcTLSCRLCheck -- case exact match
olcTLSCRLFile -- case exact match
olcTLSRandFile -- case exact match
olcTLSVerifyClient -- case exact match (Shouldn't this be an enum, like
olcMemberOfDangling ?)
olcTLSDHParamFile -- case exact match
olcTLSECName -- case exact match
olcTLSProtocolMin -- case exact match
---------------- BACKENDS -----------------------
--- back-asyncmeta
olcDbURI -- case exact match
olcDbStartTLS -- case exact match
olcDbACLPasswd -- DELETE
olcDbIDAssertBind -- case ignore match
olcDbTFSupport -- case ignore match
olcDbTimeout -- case ignore match
olcDbIdleTimeout -- case ignore match
olcDbNetworkTimeout -- case ignore match
olcDbCancel -- case ignore match
olcDbQuarantine -- case ignore match
olcDbDefaultTarget -- case ignore match
olcDbDnCacheTtl -- case ignore match
olcDbBindTimeout -- integer match
olcDbOnErr -- case ignore match
olcDbNretries -- case ignore match
olcDbClientPr -- case ignore match
olcDbKeepalive -- case ignore match
--- back-bdb/hdb
olcDbCheckpoint -- case ignore match
olcDbCryptFile -- case exact match
olcDbCryptKey -- case exact match
olcDbConfig -- IA5 case ignore match
olcDbLockDetect -- case ignore match
olcDbMode -- case ignore match
--- back-ldap
olcDbURI -- case exact match
olcDbStartTLS -- case exact match
olcDbACLPasswd -- DELETE
olcDbACLBind -- case ignore match
olcDbIDAssertPasswd -- DELETE
olcDbIDAssertBind -- case ignore match
olcDbIDAssertMode -- DELETE
olcDbTFSupport -- case ignore match
olcDbTimeout -- case ignore match
olcDbIdleTimeout -- case ignore match
olcDbConnTtl -- case ignore match
olcDbNetworkTimeout -- case ignore match
olcDbCancel -- case ignore match
olcDbQuarantine -- case ignore match
olcDbOnErr -- case ignore match
olcDbKeepalive -- case ignore match
--- back-mdb
olcDbDirectory -- Changed to case exact match
olcDbCheckpoint -- case ignore match
olcDbMode -- case ignore match
--- back-meta
olcDbURI -- case exact match
olcDbStartTLS -- case exact match
olcDbACLPasswd -- DELETE
olcDbIDAssertBind -- case ignore match
olcDbTFSupport -- case ignore match
olcDbTimeout -- case ignore match
olcDbIdleTimeout -- case ignore match
olcDbConnTtl -- case ignore match
olcDbNetworkTimeout -- case ignore match
olcDbCancel -- case ignore match
olcDbQuarantine -- case ignore match
olcDbDefaultTarget -- case ignore match
olcDbDnCacheTtl -- case ignore match
olcDbBindTimeout -- integer match
olcDbOnErr -- case ignore match
olcDbNretries -- case ignore match
olcDbClientPr -- case ignore match
olcDbKeepalive -- case ignore match
--- back-sql
olcDbHost -- case exact match
olcDbName -- case exact match
olcDbUser -- case exact match
olcDbPass -- case exact match
olcSqlConcatPattern -- case exact match
olcSqlSubtreeCond -- case exact match
olcSqlChildrenCond -- case exact match
olcSqlDnMatchCond-- case exact match
olcSqlOcQuery -- case exact match
olcSqlAtQuery -- case exact match
olcSqlInsEntryStmt -- case exact match
olcSqlUpperFunc -- case exact match
olcSqlStrcastFunc -- case exact match
olcSqlDelEntryStmt -- case exact match
olcSqlRenEntryStmt -- case exact match
olcSqlDelObjclassesStmt -- case exact match
olcSqlBaseObject -- case exact match
olcSqlLayer -- case exact match
olcSqlFetchAttrs -- case ignore match
olcSqlAliasingKeyword -- case exact match
olcSqlAliasingQuote -- case ignore match
olcSqlIdQuery -- case exact match
---------------- OVERLAYS -----------------------
--- accesslog.c
logpurge -- case ignore match
logold -- case exact match
--- auditlog.c
olcAuditLogFile -- case exact match
--- autoca.c
olcACAuserClass -- case ignore match
olcACAserverClass -- case ignore match
--- dds.c
olcDDSmaxTtl -- case ignore match
olcDDSminTtl -- case ignore match
olcDDSdefaultTtl -- case ignore match
olcDDSinterval -- case ignore match
olcDDStolerance -- case ignore match
--- dyngroup.c
olcDGAttrPair -- case ignore match
--- memberof.c
olcMemberOfDangling -- case ignore match
olcMemberOfGroupOC -- case ignore match
olcMemberOfMemberAD -- case ignore match
olcMemberOfMemberOfAD -- case ignore match
olcMemberOfDanglingError -- case ignore match
--- pcache.c
olcProxyCache -- case ignore match
olcPcachePosition -- case ignore match
olcPcacheMaxQueries -- case ignore match
--- rwm.c
olcRwmTFSupport -- case ignore match
--- syncprov.c
olcSpCheckpoint -- case ignore match
--- translucent.c
olcTranslucentLocal -- case ignore match
olcTranslucentRemote -- case ignore match
---------------- CONTRIB -----------------------
--- adremap.c
olcADremapDowncase -- case ignore match
olcADremapDNmap -- case ignore match
--- autogroup.c
olcAGmemberOfAd -- case ignore match
--- smbk5pwd.c
olcSmbK5PwdEnable -- case ignore match
<https://github.com/quanah/openldap-scratch/tree/its8286>
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
1918
days inactive
1944
days old
5 comments
3 participants
participants (3)
-
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount