openldap-devel

openldap-devel@openldap.org

1420 discussions

cn=config schema, matching rules and UX with web2ldap
by Michael Ströder 30 May '18

30 May '18

HI! I'd like to highlight a bit why I'm nitpicking on schema definitions for back-config and how careful schema crafting can help to have a better UX with less effort (even though I'm personally using back-config read-only for monitoring). The goals of web2dap are: 1. guide the user to do it right rather than enforce stuff unless "stuff" is really well-known and thus can be handled strictly 2. no overzealous actions, don't surprise the user, be trustworthy 3. do as much as possible just by looking at the subschema So why is the syntax or a known attribute constraint important for that? Internally web2ldap uses plugin classes which are registered to - a syntax or - list of attribute types or - combinations of attribute types and structural object classes. Lots of plugin classes cover handling of well-defined application schema, some proprietary stuff, and weird quirks for broken schema. The classes are organized in plugin modules described here: https://www.web2ldap.de/features.html#plugin This all turned out to be quite powerful. Details upon request. Now why this long story? Of course there's also a plugin module for OpenLDAP-specific schema, especially for slapo-accesslog but also some stuff for cn=config (remember my presentation at ODD in Tübingen long time ago?). https://fossies.org/linux/web2ldap/web2ldap/app/plugins/openldap.py So here's a simple example for the case-exact vs. case-insensitive discussion: For attribute 'olcMemberOfDangling' I could add such a class: class OlcMemberOfDangling(SelectList): oid = 'OlcMemberOfDangling-oid' desc = 'Behavior in case of dangling references during modification' attr_value_dict = { u'':u'-/-', u'ignore':u'ignore', u'drop':u'drop', u'error':u'error', } syntax_registry.registerAttrType( OlcMemberOfDangling.oid,[ '1.3.6.1.4.1.4203.1.12.2.3.3.18.1', # olcMemberOfDangling ] ) As you can imagine the dict keys in attr_value_dict are the real values, the values are the UI description. Now if the existing entry contains a mixed-case value exactly this value is added to the select list to preserve this exact value in any case. Example: dn: olcOverlay={7}memberof,olcDatabase={2}mdb,cn=config olcMemberOfDangling: IGNore The select list in the UI would contain: ignore drop error IGNore Hmm, that likely looks confusing to the user in the UI. So I could define a lower-case sanitizing like this: class OlcMemberOfDangling(SelectList): [..class attrs like above..] simpleSanitizers = ( str.lower, ) But in this case the existing value would be altered and sent along with the modify request thus also confusing the user because the altering was not result of his/her action. So it boils down that being more strict with values can lead to a better user experience. In this case I'd recommend that slapd would always *sanitize* the value to lower-case. I'd be glad if OpenLDAP developers could consider those aspects in the future. Bear in mind that the above is just one very simple example. web2ldap has also base classes for attribute type names or object class names where it displays direct links into the schema browsers. Hence I proposed to declare some cn=config attributes as OID syntax. Interested readers can directly play with web2ldap and Æ-DIR's cn=config: https://demo.ae-dir.com/web2ldap/dit?ldapi://%2Fopt%2Fae-dir%2Frun%2Fslapd%… Sorry, read-only, but you can display the input forms and see what's displayed along the attributes. There is more you could do in later releases beyond 2.5. For inspiration here's the plugin module for OpenDJ's cn=config: https://fossies.org/linux/web2ldap/web2ldap/app/plugins/opends.py It can make heavy use of web2ldap's DynamicDNSelectList because many config values are just references to other entries. Ciao, Michael.

1 0

ITS#8286 pending questions
by Quanah Gibson-Mount 30 May '18

30 May '18

I've done a first pass through the source tree adding missing matching rules to the olc* attributes to address ITS#8286 (<https://github.com/quanah/openldap-scratch/tree/its8286>). However, many of the attributes are string types, and can either be case exact/ignore match. The following is a list of those attributes, and my best guess at which they should be. Once I have a definitive answer on these, I'll commit them: ---------------- servers/slapd/bconfig.c ----------------------- olcInclude -- case ignore match? olcLogFile -- case ignore match? olcModulePath -- case ignore match? olcOverlay -- case ignore match? olcPasswordCryptSaltFormat -- case ignore match? olcPidFile -- case ignore match? olcPluginLogFile -- case ignore match? olcReferral -- case ignore match? olcRootPw -- case exact match? olcSaslAuxprops -- case ignore match? olcSaslHost -- case exact match? olcSaslRealm -- case exact match? olcSaslSecProps -- case exact match? olcSizeLimit -- case ignore match? olcSubordinate -- case ignore match? olcTCPBuffer -- case ignore match? olcTimeLimit -- case ignore match? olcTLSCACertificateFile -- case ignore match? olcTLSCACertificatePath -- case ignore match? olcTLSCertificateFile -- case ignore match? olcTLSCertificatePath -- case ignore match? olcTLSCertificateKey -- ??? (Private OID) olcTLSCertificateKeyFile -- case ignore match? olcTLSCipherSuite -- case ignore match? olcTLSCRLCheck -- case ignore match? olcTLSCRLFile -- case ignore match? olcTLSRandFile -- case ignore match? olcTLSVerifyClient -- case ignore match? olcTLSDHParamFile -- case ignore match? olcTLSSECName -- case ignore match? olcTLSProtocolMin -- case ignore match? ---------------- BACKENDS ----------------------- --- back-asyncmeta olcDbURI -- case ignore match? olcDbStartTLS -- case ignore match? (also, seems to be misnamed and missing the "ldaps" option) olcDbACLPasswd -- case exact match? olcDbIDAssertBind -- case ignore match? olcDbTFSupport -- case ignore match? olcDbTimeout -- case ignore match? olcDbIdleTimeout -- case ignore match? olcDbCancel -- case ignore match? olcDbQuarantine -- case ignore match? olcDbDefaultTarget -- case ignore match? olcDbDnCacheTtl -- case ignore match? olcDbBindTimeout -- case ignore 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 ignore match? olcDbCryptKey -- case ignore match? olcDbConfig -- IA5 case ignore match? olcDbLockDetect -- case ignore match? olcDbMode -- case ignore match? --- back-ldap olcDbURI -- case ignore match? olcDbStartTLS -- case ignore match? (also, seems to be misnamed? old config parameter was just "tls") olcDbACLPasswd -- case exact match? olcDbACLBind -- case ignore match? olcDbIDAssertPasswd -- case exact match? olcDbIDAssertBind -- case ignore match? olcDbIDAssertMode -- 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? olcDbOnErr -- case ignore match? olcDbKeepalive -- case ignore match? --- back-mdb olcDbCheckpoint -- case ignore match? olcDbMode -- case ignore match? --- back-meta olcDbURI -- case ignore match? olcDbStartTLS -- case ignore match? (also, seems to be misnamed? old config parameter was just "tls") olcDbACLPasswd -- case exact match? 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 -- case ignore match? olcDbOnErr -- case ignore match? olcDbNretries -- case ignore match? olcDbClientPr -- case ignore match? olcDbKeepalive -- case ignore match? --- back-sql olcDbHost -- case ignore match? olcDbName -- case ignore match? olcDbUser -- case ignore match? olcDbPass -- case exact match? olcSqlConcatPattern -- case ignore match? olcSqlSubtreeCond -- case ignore match? olcSqlChildrenCond -- case ignore match? olcSqlDnMatchCond-- case ignore match? olcSqlOcQuery -- case ignore match? olcSqlAtQuery -- case ignore match? olcSqlInsEntryStmt -- case ignore match? olcSqlUpperFunc -- case ignore match? olcSqlStrcastFunc -- case ignore match? olcSqlDelEntryStmt -- case ignore match? olcSqlRenEntryStmt -- case ignore match? olcSqlDelObjclassesStmt -- case ignore match? olcSqlBaseObject -- case ignore match? olcSqlLayer -- case ignore match? olcSqlFetchAttrs -- case ignore match? olcSqlAliasingKeyword -- case ignore match? olcSqlAliasingQuote -- case ignore match? olcSqlIdQuery -- case ignore match? ---------------- OVERLAYS ----------------------- --- accesslog.c logpurge -- case ignore match? logold -- case ignore match? --- auditlog.c olcAuditLogFile -- case ignore 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? olcSmbK5PwdMustChange -- case ignore match? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 5

Binary log format
by Howard Chu 26 Apr '18

26 Apr '18

So, thinking along the lines of a binary log format for StatsLog, to avoid the syslog overhead, the first obvious idea was to just dump timestamped BER messages into a logfile, and have a separate postprocessor command produce human readable text. Thinking further about this, we could just dump PCAP format - and use tcpdump, WireShark, or whatever favorite tool to render the log. If all we want is a timestamped log of messages that slapd has processed, we can do that right now and won't have to invest any effort at all into postprocessors. That still leaves a question of what to do with Debug messages that also go to syslog - it's easier to identify problems if the error message appears somewhere close to the log of the original request. So we'd need a tool to interleave these in order, if we had to pull messages both from the binary log and from syslog. Or, we could define a new custom packet type for these Debug/diagnostic messages, and just spit them out into the PCAP file too. This might require us to write a custom parser plugin for WireShark or whatever, to render these messages. That's still not a big deal, compared to inventing our own entire log postprocessing framework. Thoughts, suggestions? -- -- 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 2

Beginner projects
by Lawrence, Andy 21 Apr '18

21 Apr '18

Hi, Me and one of my colleagues are interested in contributing to OpenLDAP. Do you have any interesting projects that new comers such as myself could work on? With best regards, Dr Andrew Lawrence Siemens Rail Automation Holdings Limited MO MM R&D UK IXL 17 Langley Park Way Chippenham SN15 1GG, United Kingdom mailto:andrew.lawrence@siemens.com www.siemens.com/rail-automation<http://www.siemens.com/rail-automation> www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife> www.siemens.com/ingenuityforlife Siemens Rail Automation Holdings Limited - registered office: Faraday House, Sir William Siemens Square, Frimley Camberley GU16 8QD. Registered No. 00016033

3 5

Re: RE24 testing call (2.4.46) LMDB RE0.9 testing call (0.9.22)
by Howard Chu 12 Mar '18

12 Mar '18

Quanah Gibson-Mount wrote: > This is expected to be the final testing call for 2.4.45, with an anticipated > release, depending on feedback, during the week of 2018/03/12. 2.4.46, not 2.4.45 make test passed here on Linux x86-64 > > For this release the primary focus was addressing replication issues found in > OpenLDAP, affecting both syncrepl and delta-syncrepl, whether as > provider/consumer or MMR-based configurations. > > Generally, get the code for RE24: > > <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> > > > Configure & build. > > Execute the test suite (via make test) after it is built. Optionally, cd > tests && make its run through the regression suite. > > Thanks! > > OpenLDAP 2.4.46 Engineering > Fixed libldap connection delete callbacks when TLS fails to start (ITS#8717) > Fixed libldap to not reuse tls_session if TLS hostname check fails (ITS#7373) > Fixed libldap cross-compiling with OpenSSL 1.1 (ITS#8687) > Fixed libldap OpenSSL 1.1.1 compatibility with BIO_method (ITS#8791) > Fixed libldap MozNSS CA certificate hash matching (ITS#7374) > Fixed libldap MozNSS with PEM certs when also using an NSS cert db (ITS#7389) > Fixed libldap MozNSS initialization (ITS#8484) > Fixed libldap GnuTLS with GNUTLS_E_AGAIN (ITS#8650) > Fixed libldap memory leak with cancel operations (ITS#8782) > Fixed slapd Eventlog registry key creation on 64-bit Windows (ITS#8705) > Fixed slapd to maintain SSF across SASL binds (ITS#8796) > Fixed slapd syncrepl deadlock when updating cookie (ITS#8752) > Fixed slapd syncrepl callback to always be last in the stack (ITS#8752) > Fixed slapd telephoneNumberNormalize when the value is spaces and hyphens > (ITS#8778) > Fixed slapd CSN queue processing (ITS#8801) > Fixed slapd-ldap TLS connection timeout with high latency connections > (ITS#8720) > Fixed slapd-ldap to ignore unknown schema when omit-unknown-schema is set > (ITS#7520) > Fixed slapd-mdb with an optimization for long lived read transactions > (ITS#8226) > Fixed slapd-meta assert when olcDbRewrite is modified (ITS#8404) > Fixed slapd-sock with LDAP_MOD_INCREMENT operations (ITS#8692) > Fixed slapo-accesslog cleanup to only occur on failed operations (ITS#8752) > Fixed slapo-dds entryTTL to actually decrease as per RFC 2589 (ITS#7100) > Fixed slapo-syncprov memory leak with delete operations (ITS#8690) > Fixed slapo-syncprov to not clear pending operation when checkpointing > (ITS#8444) > Fixed slapo-syncprov to correctly record contextCSN values in the > accesslog (ITS#8100) > Fixed slapo-syncprov not to log checkpoints to accesslog db (ITS#8607) > Fixed slapo-syncprov to process changes from this SID on REFRESH (ITS#8800) > Fixed slapo-syncprov session log parsing to not block other operations > (ITS#8486) > Build Environment > Fixed Windows build with newer MINGW version (ITS#8697) > Fixed compiler warnings and removed unused variables (ITS#8578) > Contrib > Fixed ldapc++ Control structure (ITS#8583) > Documentation > Delete stub manpage for back-ldbm (ITS#8713) > Fixed ldap_bind(3) to mention the LDAP_SASL_SIMPLE mechanism (ITS#8121) > Fixed slapd-config(5) typo for olcTLSCipherSuite (ITS#8715) > Fixed slapo-syncprov(5) indexing requirements (ITS#5048) > > LMDB 0.9.22 Engineering > Fix regression with new db from 0.9.19 (ITS#8760) > Fix liblmdb to build on Solaris (ITS#8612) > Fix delete behavior with DUPSORT DB (ITS#8622) > Fix mdb_cursor_get/mdb_cursor_del behavior (ITS#8722) > > --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/

1 0

slapd's crypt usage is single threaded?
by Jesse Hathaway 16 Feb '18

16 Feb '18

>From our testing it appears that slapd's usage of the crypt function, to check a user's password on a bind request, is single threaded, rather than being distributed across all of slapds thread. We encountered this problem when bumping the number of hashing rounds for our password hashes from 5,000 to 500,000 as was suggested by our security team. Is it expected that the hashing of a users password would be bound to one thread? We ran our tests on a default install of of slapd 2.4.44 on Debian Jessie box with 8 cores. # Running script with butter user and 10,000,000 rounds of hashing: $ pidstat -t -p $(pgrep slapd) 5 3 <snip> Average: UID TGID TID %usr %system %guest %CPU CPU Command Average: 108 28458 - 100.00 0.00 0.00 100.00 - slapd Average: 108 - 28458 0.00 0.00 0.00 0.00 - |__slapd Average: 108 - 28459 0.00 0.00 0.00 0.00 - |__slapd Average: 108 - 28460 0.00 0.00 0.00 0.00 - |__slapd Average: 108 - 10679 0.00 0.00 0.00 0.00 - |__slapd Average: 108 - 10680 0.00 0.00 0.00 0.00 - |__slapd Average: 108 - 17988 0.00 0.00 0.00 0.00 - |__slapd Average: 108 - 17993 0.00 0.00 0.00 0.00 - |__slapd Average: 108 - 17998 0.00 0.00 0.00 0.00 - |__slapd Average: 108 - 18007 22.53 0.00 0.00 22.53 - |__slapd Average: 108 - 19109 16.80 0.00 0.00 16.80 - |__slapd Average: 108 - 19110 0.07 0.00 0.00 0.07 - |__slapd Average: 108 - 19111 0.00 0.00 0.00 0.00 - |__slapd Average: 108 - 19112 60.73 0.00 0.00 60.73 - |__slapd Average: 108 - 19113 0.00 0.00 0.00 0.00 - |__slapd Average: 108 - 27438 0.00 0.00 0.00 0.00 - |__slapd Average: 108 - 27439 0.00 0.00 0.00 0.00 - |__slapd Average: 108 - 27440 0.00 0.00 0.00 0.00 - |__slapd Average: 108 - 27441 0.00 0.00 0.00 0.00 - |__slapd # Running script with bubbles user and 5,000 rounds of hashing: $ pidstat -t -p $(pgrep slapd) 5 3 <snip> Average: UID TGID TID %usr %system %guest %CPU CPU Command Average: 108 28458 - 109.59 0.87 0.00 110.46 - slapd Average: 108 - 28458 0.00 0.00 0.00 0.00 - |__slapd Average: 108 - 28459 0.80 2.80 0.00 3.60 - |__slapd Average: 108 - 28460 8.79 0.07 0.00 8.86 - |__slapd Average: 108 - 10679 7.00 0.07 0.00 7.06 - |__slapd Average: 108 - 10680 8.19 0.07 0.00 8.26 - |__slapd Average: 108 - 17988 3.80 0.07 0.00 3.86 - |__slapd Average: 108 - 17993 3.73 0.00 0.00 3.73 - |__slapd Average: 108 - 17998 7.46 0.00 0.00 7.46 - |__slapd Average: 108 - 18007 7.66 0.00 0.00 7.66 - |__slapd Average: 108 - 19109 8.93 0.07 0.00 8.99 - |__slapd Average: 108 - 19110 4.73 0.07 0.00 4.80 - |__slapd Average: 108 - 19111 9.33 0.00 0.00 9.33 - |__slapd Average: 108 - 19112 9.26 0.13 0.00 9.39 - |__slapd Average: 108 - 19113 2.40 0.00 0.00 2.40 - |__slapd Average: 108 - 27438 8.13 0.07 0.00 8.19 - |__slapd Average: 108 - 27439 1.87 0.07 0.00 1.93 - |__slapd Average: 108 - 27440 7.79 0.00 0.00 7.79 - |__slapd Average: 108 - 27441 7.00 0.00 0.00 7.00 - |__slapd # Test ldif: $ cat example.ldif dn: o=example o: example objectclass: organization dn: ou=people, o=example ou: people objectclass: organizationalunit dn: ou=groups, o=example ou: groups objectclass: organizationalunit dn: cn=butter, ou=people, o=example objectclass: inetOrgPerson cn: butter sn: butter # {CRYPT}$6$rounds=10000000$ykk4zGD3ODNR$iMP/zYeisoWTYgxLtPv1qzoo/dVrYQLAb9sKlRMBgPTfFrr9lTzEEkJ9NcFdGI/MiRxHSx/1x3rnw3RkNRMer/ # 'everyone loves butter' userPassword:: e0NSWVBUfSQ2JHJvdW5kcz0xMDAwMDAwMCR5a2s0ekdEM09ETlIkaU1QL3pZZWlzb1dUWWd4THRQdjFxem9vL2RWcllRTEFiOXNLbFJNQmdQVGZGcnI5bFR6RUVrSjlOY0ZkR0kvTWlSeEhTeC8xeDNybnczUmtOUk1lci8= uid: butter dn: cn=bubbles, ou=people, o=example objectclass: inetOrgPerson cn: bubbles sn: bubbles # {CRYPT}$6$rounds=5000$vY9dl4.rTyasVXCH$nlSXEZFnMn31NThCBWmfDy8EhaaZz6amUI8iukO8dpAnxMUaKK/78FqMVSi5iRbMvwkS6RNYhh4WhNzxDe.8r0 # 'everyone loves bubbles' userPassword:: e0NSWVBUfSQ2JHJvdW5kcz01MDAwJHZZOWRsNC5yVHlhc1ZYQ0gkbmxTWEVaRm5NbjMxTlRoQ0JXbWZEeThFaGFhWno2YW1VSThpdWtPOGRwQW54TVVhS0svNzhGcU1WU2k1aVJiTXZ3a1M2Uk5ZaGg0V2hOenhEZS44cjA= uid: bubbles dn: cn=admin,o=example objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e1NTSEF9SmFDaTRvZkRqQ2F3RHR2VVJQZWdleFoxZHFWNWRENUo= structuralObjectClass: organizationalRole # Test script: $ cat whoamis #!/bin/bash USER=$1 trap cleanup SIGINT cleanup() { kill -9 $(jobs -p) exit 1 } while true; do if [[ $(jobs | wc -l) -lt 8 ]]; then ldapwhoami -x -D cn=${USER},ou=people,o=example -H ldap://localhost -w "everyone loves ${USER}" >/dev/null & else wait -n fi done

3 3

Test, pelase ignore
by Quanah Gibson-Mount 12 Feb '18

12 Feb '18

Just testing whether or not mailman is working, since commit messages are not delivering. -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

2 more commits for review (LMDB 0.9.22)
by Quanah Gibson-Mount 11 Feb '18

11 Feb '18

ITS#8699 -- This appears to be specifically fixing an issue found in the 0.9.21 release (47ca2f7095f2aa6e395b7a5cfec46bce35a5d623) ITS#8722 -- The original fix (f34b61f9471d1c03fe0517b9d817c50c920e378a) looks like it applies to 0.9. Later commit added new XCURSOR_REFRESH (7ead4169b6cdf67f72956a2835ff6e6bd6905256) and then the original fix was reworked to use it (8c2c5e2b4bf2e4504694aa9684922d505af9ba75). I assume we would just want f34b61f9471d1c03fe0517b9d817c50c920e378a for 0.9.22? Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Commit review for OL 2.4.46/LMDB 0.9.22
by Quanah Gibson-Mount 09 Feb '18

09 Feb '18

LMDB 0.9.22 -------------------------- ITS#8612 - Fix build on Solaris (bb8502f08800a44a6b91a94d6478aa7101c4cc77) ITS#8760 - Fix regression introduced in 0.9.19 (4d5e2d2a2ac38b9d56b6ba73187c325024718167) OpenLDAP 2.4.46 -------------------------- 3d5a7545b950afa81b45e2a7d82593d7de2beff1 (No its, fixes minor build issue) ITS#8778 - Fix telephoneNumberNormalize (57253688b381375ae8b5a1ffce7a2d2d369bb743) ITS#8782 - Fix memleak in cancel operations (f82ca15a1862749e13a989599d7f4c52c7648957) ITS#8484 - Fix MozNSS initialization (1863245f49f69ea282f42bf4ab417329ef0b3655) ITS#8796 - Fix SSF being reset across SASL binds (52f7daab0101648d1713cbc7764a6c209d103cb4) ITS#8791 - Fix OpenSSL 1.1.1 BIO_method compatibility (e5ee07785e9d820ec8db08187aa39697584ca1b7, f09ffffcbd5a0e2c345ef2563d3d4d64bd049550f09ffffcbd5a0e2c345ef2563d3d4d64bd049550, 650b4822ce2916ae16e4bfae18bd6af97451c2f4) ITS#8100 - Fix delta-syncrepl with empty accesslog (ca7f697e14087234e44c96fb7edd81cfb14183dc) ITS#8607 - Fix checkpoints so they aren't recorded in the accesslog (0eb577632f291db3e4f89cf4b496822b9766f7cc) ITS#8800 - Fix syncreplication for MMR so master does not skip its own changes when REFRESHing from an old db (4d1077ffa4ff336ab7b01d1908dd018fc34a301e) ITS#8801 - Fix CSN queue processing (0c1ebd178cafd8add90e6561ff798a2df4e6db67) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Jitterbugs to Bugzilla migration dev instance for testing
by Quanah Gibson-Mount 31 Jan '18

31 Jan '18

For the last several months I've been working on migrating the OpenLDAP project infrastructure to new systems. The server housing git-master was the first to be migrated, and was done late last year. The final server to be migrated is a bit more challenging, as it contains all of the public facing aspects of the project (ftp, git (RO), ITS (jitterbugs), FAQ, wiki, mailman, etc). As a part of the transition to the new hardware, the plan is to retire jitterbugs and migrate it to bugzilla. As a part of this process, I've been working on a development instance so I could work out the details of how I anticipate the migrated bug system to look. I would like to invite list members to look at the new system and provide feedback. It can be found at: <https://quanah.ddns.net/bugzilla> Please note that the dev system is not hooked up to an MTA, so any time it reports that it is sending an email it is not doing so (Instead it writes to a file on disk that I can use to ensure that the generated emails are correct). If you want to know what sort of email was generated by an action, let me know and I will look it up. Also note that the code to do the initial import has to pick a single email address to record as the person who created the bug (and all follow ups). In part because none of those accounts exist in the DB. I've ensured that the "From" information is preserved, and as time allows and accounts are created, I will work on updating the underlying database to correct the information on who filed the old bug reports. New bug reports will of course be tied to the actual account of the individual who files them. So for all currently existing bugs, I am recorded as the individual who filed the bug report. ----------- Difference highlights ----------- a) Integration with GitHub authentication When someone arrives at the splash screen, they have a choice -- They can either create a new local account (via the "New Account" link), or they can click the "Sign in" button to create an account that is linked via GitHub. I will be working on customizing this front page so that it's more apparent that you can create an account using the "Sign in" button, as that's not clear right now. b) product/component design Bugzilla is organized around the concept of Products and components that make up that product. The jitterbugs system really had no organizing concept. In the process of migrating, I've reworked the jitterbugs categories into components of related products where applicable, and "type" based categories are now migrated to an appropriate severity type. The Bugzilla instance has the following Products: JLDAP (Components: JDBC, JLDAP) LMDB (Component: liblmdb) OpenLDAP (Components: backends, build, contrib, documentation, libraries, overlays, slapd) Website (Component: website) Jitterbugs was comprised of the following categories: Build (Now OpenLDAP/build) Contrib (Now OpenLDAP/contrib) Development (Now a severity of "development") Documentation (Now OpenLDAP/documentation) Historical (Not tracked as a separate item, unnecessary) Incoming (Not tracked as a separate item, unnecessary) Software Bugs (Not tracked as a separate item, unnecessary) Software Enhancements (Now a severity of "enhancement") Web (Now Website/website) The re-organization allows a better ability to track bugs while retaining useful type information. With the product/component focus, reports can now be better directed into the appropriate location. c) Groups support -- Bugzilla has an excellent concept of groups, and the ability to give different groups different permissions. This could allow, for example, a group of privileged users who have the capability to help triage bugs. Currently there is only a single group for the developers, while any other account is a "normal" user account. The ability to have groups allows us to make it possible for people to file "private" bugs that are easily found by the development group, including the ability for those bugs to go to a developers only list. The way the system is currently set up, it will (fake) email a private list for all private bugs & private comments, and (fake) mail all public bugs/comments to openldap-its(a)openldap.org. This allows us to preserve the long time functionality of public notifications via openldap-its(a)openldap.org while adding the ability for the dev team to immediately be updated to new private bugs & comments. d) Milestones -- Bugzilla allows the creation and use of milestones. This is extremely helpful for both the developers and end users, as it becomes possible to easily query these milestones for information on such things as what was in a release, what will be in the next release, and what is slated for future development. For example, the "Search" link can be used to generate the following queries: All bugs released with OpenLDAP 2.4.45: <https://quanah.ddns.net/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_st atus=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFI ED&product=OpenLDAP&query_format=advanced&resolution=---&resolution=FIXED&r esolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSF ORME&resolution=PARTIAL&resolution=SUSPENDED&resolution=FEEDBACK&resolution =TEST&target_milestone=2.4.45> All bugs currently scheduled for OpenLDAP 2.4.46: <https://quanah.ddns.net/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_st atus=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFI ED&product=OpenLDAP&query_format=advanced&resolution=---&resolution=FIXED&r esolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSF ORME&resolution=PARTIAL&resolution=SUSPENDED&resolution=FEEDBACK&resolution =TEST&target_milestone=2.4.46> All bugs currently scheduled for inclusion with the OpenLDAP 2.5 initial release: <https://quanah.ddns.net/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_st atus=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFI ED&product=OpenLDAP&query_format=advanced&resolution=---&resolution=FIXED&r esolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSF ORME&resolution=PARTIAL&resolution=SUSPENDED&resolution=FEEDBACK&resolution =TEST&target_milestone=OpenLDAP_2_5> Note that this is all work I've entered by hand, so various bugs may be missing from the above queries. e) versions -- Bugzilla has a clear concept of versions for each product. This means now that people can select (when filing a bug) what version they are reporting against. You could always enter this information in by hand in jitterbugs, but the major difference here now is that it is possible to use this to generate queries. So you could, for example, do a search to find all bugs reported against 2.4.43. <https://quanah.ddns.net/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_st atus=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFI ED&list_id=124&product=OpenLDAP&query_format=advanced&resolution=---&resolu tion=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resol ution=WORKSFORME&resolution=PARTIAL&resolution=SUSPENDED&resolution=FEEDBAC K&resolution=TEST&version=2.4.43> f) bug states -- Jitterbugs was fairly limited in the state options that could be chosen (Open, Active, Suspended, Feedback, Test, Release, Partial, Closed). This was certainly customizable (and had been customized beyond the defaults), but lacks a level of granularity available with Bugzilla. With Bugzilla, there is always a primary state, and potentially a secondary state. These states are: UNCONFIRMED -> Newly filed bug that has not been acted upon by the project. All bug reports start in this state CONFIRMED -> Someone in the project has confirmed this is a valid report. IN_PROGRESS -> Someone in the project is actively working on the report. RESOLVED -> Issue has some type of secondary resolution. These are: FIXED -> Issue is fixed and integrated into the release branch for the next upcoming release INVALID -> Bug report is invalid WONTFIX -> There are no plans to fix this report (Generally to be used with bug reports for historic releases) DUPLICATE -> Duplicate of an existing bug (Which is entered as a part of the process. See <https://quanah.ddns.net/bugzilla/show_bug.cgi?id=8765> for an example) WORKSFORME -> Developer(s) unable to reproduce the problem report PARTIAL -> Some of the work in the bug was completed. Other work is still pending. My long term goal is to move all unfinished work for all of the resolved/partial bugs into new bugs to be tracked separately, and then close these out with a See Also reference (More on "See Also" further down) SUSPENDED -> Developer(s) have suspended working on this issue FEEDBACK -> Developer(s) are soliciting feedback from the reporter before continuing to work on the issue TEST -> Developer(s) have committed VERIFIED -> Issue is considered complete. It has the same secondary resolutions as RESOLVED. One slight difference noted below FIXED -> Issue is fixed, and is part of a released version of OpenLDAP Note that for the bugs that have been imported, some of these states may not be accurate due to the limitations of how items can be mapped. g) attachment support -- Currently we require people to upload patches, etc, to the OpenLDAP FTP site. Bugzilla allows attachments to be made directly as a part of submitting or updating a bug. This should allow the FTP server to only be used for large files (such as core dumps), and mostly retired. It also makes it simpler to ensure patches are kept with bug reports (We've lost patches people have provided in the past via URLs that no longer exist). It is possible to make attachments "private" as well, to help protect sensitive data. h) git integration -- One of the things on my to-do list post migration is to set up git integration. This means that when a developer makes a commit that references an existing bug report, that commit will automatically be added as a comment to the bug. This will make it easy for people who are interested in what the fix to an issue was to find said commit and examine the change(s). i) Potential future plans -- Mozilla has developed an addon service for Bugzilla that allows GitHub PR reports to be attached to open bug reports (https://github.com/mozilla/github-bugzilla-pr-linker ). I could see how this would be useful to have, as many people do their development work on GitHub and are annoyed at the process of having to directly provide a patch to the project. For developers, I'm also looking at a utility that allows those in the development group to manipulate bugs via the git command line (https://github.com/mozilla/git-bz-moz/blob/master/git-bz.txt). My goal is to have this working prior to a migration occurring. j) Major differences -- Currently correspondance between those who report a bug and the project team is done via email, using TO or CC the openldap-its(a)openldap.org email list. This has been problematic over the course of time, whether from Spam getting into the system (largely mitigated now via making the list moderated), replies not making it into the ITS system due to a failure to CC the openldap-its(a)openldap.org email list, or people who reported the issue never receiving a reply (thus not knowing the issue was being worked on) because the reply was only sent to the openldap-its(a)openldap.org email list. It is possible to setup an email->BZ gateway, but the format is a bit arcane, and I'd like to avoid that if possible. I would love to get feedback from those folks on the list as to their thoughts about this. k) URL field -- Bugzilla has a URL field that can be filled out to point to a URL containing additional relevant information. (Example: <https://quanah.ddns.net/bugzilla/show_bug.cgi?id=8766>) l) See Also field -- With Bugzilla, it is possible to provide references to other related bugzilla bug reports, including in Bugzilla instances run by other organizations. Examples: <https://quanah.ddns.net/bugzilla/show_bug.cgi?id=6138> (See Also's to related bugs in the OpenLDAP BZ) <https://quanah.ddns.net/bugzilla/show_bug.cgi?id=6304> (See Also to RedHat's BZ) Thanks for your time, and I look forward to the feedback. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel