To be honest error log messages should not be expected to be static. As work is done to
the server logging messages are added/removed and/or changed all the time, and that's
not going to change. Now I know when we added the "wtime" and
"optime" to the access logging that did cause some issues for Admins who parse
our access logs. We could have done better with communicating this change (live and
learn). But at the same time this new logging is tremendously useful, and has helped many
customers troubleshoot various performance issues. So while these changes can be
disruptive we felt the pro's outweighed the cons.
Honestly, part of the thing here is we don't have a clearly defined "what is
API" and "what is not". Because of this, I think sometimes people then
assume our log format while it hasn't changed in sometime, is "API stable"
when really, it's a communication tool that we can and will change if we need to
communicate more clearly with a human.
Similar, when we change things in pblock or other slapd-plugin.h functions, it's a bit
hit-miss, because some are only used internally, some are externally used. It's hard
to know what we might affect here ....
>
> 2) UNIX socket of the server was moved to /run/slapd-instance.socket, a new keyword
in .inf file for dscreate ("ldapi") has appeared.
> Works fine, but it had an impact on our scripts that use ldapi socket path.
In this case using /var/run was outdated and was causing issues with systemd/tmpfiles on
RHEL, and moving it to /run was the correct thing to do. What I don't understand is
why adding the option to set the LDAPI path in the INF file is a problem. Can you
elaborate on that please?
>
> 3) A new default plugin requirement, the plugin being written in Rust - probably its
introduction is FIPS-related (Issue 3584 - Fix PBKDF2_SHA256 hashing in FIPS mode).
This was a very important fix to get into 1.4.4, usually big changes do not land in 1.4.4
anymore, but this one needed to get in.
This change was about the C code, not Rust code if I recall correctly, since that's
the inbuilt PBKDF2_SHA256 module, not the pwdchan one with openldap compat. The RUST
pbkdf2 module has existed since early 1.4.4 and that's needed for openldap migration
which we at SUSE enable by default (I don't think RH do yet).
> See my comment
https://github.com/389ds/389-ds-base/issues/5008#issuecomment-983759224. Rust becomes a
requirement for building the server, which is fine, but then it should be enabled by
default in "./configure". Without it the server does not compile the new plugin
and complains about it when starting:
> [01/Dec/2021:12:54:04.460194603 +0100] - ERR - symload_report_error - Could not open
library "/Local/dirsrv/lib/dirsrv/plugins/libpwdchan-plugin.so" for plugin
PBKDF2
Yes I do understand this frustration, and it is now fixed for non-rust builds.
I think this error specifically came about if you did a rust build, then you took rust
away, it created some leftovers in dse.ldif I think (?).
In our specfile we do enable Rust by default (and have for over a year now), so I guess
you don't use our specfile (389-ds-base/rpm/389-ds-base.spec.in) as a reference for
building your server. Also we have discussed moving to Rust on the public devel mailing
list for along time now, so if you are not on this list (389-devel) then I strongly
suggest you, or anyone who builds the server for themselves, to subscribe to it. Again,
we probably could have communicated this more "loudly".
I seem to recall we decided on 2.x as rust on by default, 1.4.4 shouldn't require it
anyway.
-------------------------------------------------------------------------------------------
Just to add to the previous mail - there is another phenomenon linked apparently to the
new plugin - at each start of the server two error messages about plugins with NULL
identities are displayed:
...
[03/Dec/2021:14:41:38.945576751 +0100] - INFO - main - 389-Directory/1.4.4.17
B2021.337.1333 starting up
[03/Dec/2021:14:41:38.946206385 +0100] - INFO - main - Setting the maximum file
descriptor limit to: 64000
[03/Dec/2021:14:41:38.951185055 +0100] - ERR - allow_operation - Component identity is
NULL
[03/Dec/2021:14:41:38.951846429 +0100] - ERR - allow_operation - Component identity is
NULL
[03/Dec/2021:14:41:39.546909815 +0100] - INFO - PBKDF2_SHA256 - Based on CPU performance,
chose 2048 rounds
[03/Dec/2021:14:41:39.566959933 +0100] - INFO - ldbm_instance_config_cachememsize_set -
force a minimal value 512000
----------------------------------------------------------------------------------------------
Yes we are aware of this useless error message popping up. I thought we removed it
already, if not we will be doing that very soon.
> ...
>
> Thank you and keep up the good work, we use 389ds in production since 2007 and we are
quite happy with it :)
Great to hear, and it is always nice working with you Andrey. You never get too upset
about most issues :-)
Anyway as for 1.4.4 we are not planning any other major changes with it. Any
performance/stability improvements will be backported, but that should be it at this stage
of 1.4.4 (well there are some nice UI changes coming). But 2.x is very dynamic, and 2.1
will be a big change with our move to LMDB.
Please feel free to continue this conversation. Maybe others on this list have some
input/comments as well. We always appreciate feedback, good or bad, and we try to work
with everyone and their needs.
Thanks!
--
Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management
SUSE Labs, Australia