asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder
hyc(a)symas.com wrote in ITS#8240:
> Our patch response was too hasty. There is no OpenLDAP bug here, the real
> issue is production binaries being built with asserts enabled instead of
> compiling with -DNDEBUG. That's an issue for packagers and distros to resolve.
> Closing this ITS, not an OpenLDAP bug.
Maybe I missed something. But this is the first time I've heard about -DNDEBUG
being mandatory when compiling binary packages for production use. Does it
have other effects?
And what are general rules for assert statements in OpenLDAP code?
In my own (Python) code assert statements are supposed to be only triggered if
something goes wrong *internally* (type issues etc.). If somebody manages to
trigger an assert statement with invalid input from "outside" I always
consider this to be a serious bug revealing insufficient error handling even
though e.g. web2ldap just logs the exception but won't crash. YMMV, but please
clarify.
I also wonder whether there are more mandatory rules for building packages and
where I can find them.
Please don't get me wrong: My inquiry is in good faith to avoid unnecessary
ITS based on misunderstanding.
Ciao, Michael.
1 year, 7 months
RE24 testing call #1 (2.4.46) LMDB RE0.9 testing call #1 (0.9.22)
by Quanah Gibson-Mount
Hello everyone,
At this point, I believe we're ready to being testing for a 2.4.46 release.
The primary focus on this release has been to fix several long standing
issues with replication, both for "standard" and "delta" based syncrepl.
These fixes have been tested against databases and workloads known to
trigger the problems that were encountered. Special thanks to Paul B.
Henson for doing additional validation for those issues that were
discovered in his deployment.
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-accesslog to not expire the last entry in the database
(ITS#8100)
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 initialize an empty accesslog db if configured
(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)
Thanks,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 11 months
slapd's crypt usage is single threaded?
by Jesse Hathaway
>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
5 years, 3 months
Test, pelase ignore
by Quanah Gibson-Mount
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>
5 years, 3 months
2 more commits for review (LMDB 0.9.22)
by Quanah Gibson-Mount
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>
5 years, 3 months
Commit review for OL 2.4.46/LMDB 0.9.22
by Quanah Gibson-Mount
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>
5 years, 3 months
Jitterbugs to Bugzilla migration dev instance for testing
by Quanah Gibson-Mount
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>
5 years, 4 months
