389-ds-base

#48969 nsslapd-auditfaillog always has an explicit path
Closed: wontfix Opened by nhosoi.

Closed: wontfix
Reopen Issue

In the current implementation, nsslapd-auditfaillog is not set, by default. Internally, the value is NULL, which let audit fail log share the same audit log file with nsslapd-auditlog.

Once, some path is set to nsslapd-auditfaillog, it is not allowed to delete or set NULL or empty to it. That is, there is no way to go back to the default behaviour.

There is another issue for the default value. Since search for nsslapd-auditfaillog under cn=config does not return anything, it is hard to find out where the failed logs are written.

Thank you for reviewing the patch, William!

Pushed to master:
fda0043..ef2c3c4 master -> master
commit ef2c3c4cc6f966935dbe367dd0d882ae81de3cc4

{{{
Description: commit ef2c3c4cc6f966935dbe367dd0d882ae81de3cc4
introduced a RESOURCE_LEAK.
auditlog.c:180: leaked_storage: Variable "audit_config" going
out of scope leaks the storage it points to.
}}}

Pushed to master:
32ee33b..b0fc822 master -> master
commit b0fc82233a5ea929c5fad835f9e825a8f0b97968

Pushed to 389-ds-base-1.3.5:
cf5683a..fc1310e 389-ds-base-1.3.5 -> 389-ds-base-1.3.5
commit fc1310e352e124d66d58d0a3e86d45c5573cbfb2

Metadata Update from @nhosoi:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.3.5.13

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2028

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)
Metadata
None
None
None
Normal
ack
QE
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.