audit

Overview

audit is the user space part of the Linux Audit System. It provides the tooling and daemons used to collect, store, search, and report audit events generated by the kernel. In a Linux distribution, this package is typically used to make the audit framework available to administrators and other tools that rely on system audit logs.

The package is mainly relevant when a system needs audit logging for operational review, compliance workflows, incident investigation, or security monitoring. NiceOS maintainers should treat it as infrastructure software rather than a desktop application.

Purpose and typical use cases

Typical use cases include:

• collecting kernel audit events on servers and workstations
• searching audit logs after an incident or configuration change
• producing summaries and reports from audit records
• integrating audit data into monitoring, compliance, or incident-response workflows
• writing or running audit-related plugins and helper tools

Typical users include:

• system administrators
• security engineers and incident responders
• compliance and audit teams
• CI/CD or image-build maintainers who need to verify audit-related system behavior
• developers working on tools that consume audit records or interact with the audit stack

Upstream project

The upstream project is the Linux Audit userspace repository maintained by the Linux Audit project on GitHub. It contains the user space tools, libraries, and related project material for the Linux Audit System. The upstream repository and its releases are the primary reference points for package updates and regression checks. (github.com)

Upstream documentation describes the audit framework as the user space side of a system that records security-relevant events from the kernel and provides tools for searching and reporting those events. NiceOS maintainers should verify any packaging assumptions against the current upstream tree when preparing an update. (github.com)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source-control metadata and manifests used to track upstream source integrity
• METADATA/ — repository metadata used by the packaging workflow
• SBOM/ — software bill of materials material, when present for the package workflow

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source integrity information in SOURCES manifests so that maintainers can verify what should be fetched without committing bulky upstream tarballs into dist-git.

Source storage and integrity policy

The package source policy is to keep large upstream archives out of Git while preserving integrity-tracking metadata in SOURCES manifests. This keeps the repository small and reviewable while still allowing maintainers to confirm which upstream inputs are expected.

Before accepting an update, NiceOS maintainers should verify that:

• the manifest entries in SOURCES match the intended upstream inputs
• the spec file points to the correct upstream release or tagged source
• any vendored or generated files are still appropriate
• no unexpected new files were introduced into the source set

Do not rely on the Git repository alone as a complete copy of upstream sources.

NiceOS maintenance notes

Before updating this package, check the following:

• review upstream release notes and changelog entries for behavior changes that might affect packaging
• verify whether the build system or configuration flags changed
• confirm whether any generated files in the source tree need to be refreshed
• check whether man pages, configuration examples, rules, or other shipped assets changed
• review install paths and runtime directories for packaging impact
• test whether the update changes the expected location or handling of state files, logs, or sockets
• confirm that any subpackages still split cleanly and that file ownership remains correct

Risks to consider:

• audit-related updates may change log formats, defaults, or command behavior
• changes in generated files may require regeneration during the build process or in SOURCES
• configuration or runtime-directory changes can affect service startup and test expectations
• tooling that consumes audit output may need compatibility review after an update

If a packaging detail is unclear from the current source set, NiceOS maintainers should verify it before relying on it.

Build and verification checklist

For RPM maintenance, a reasonable checklist is:

• inspect the upstream diff or release notes for behavior changes
• compare the spec file against the new upstream source tree
• verify that SOURCES manifests match the intended source inputs
• confirm that any generated files are updated if the build expects them
• run a local build in a clean environment
• review build logs for new warnings, missing files, or changed install paths
• run package file listing checks to confirm ownership and permissions
• verify that installed binaries, libraries, man pages, and configuration files are placed as expected
• run smoke tests for the main command-line tools if available in the build environment
• check that any service units, runtime directories, or tmpfiles rules still align with the package layout
• review subpackage boundaries after the build

References

• Linux Audit userspace repository
• Linux Audit releases
• Linux Audit project overview
• Linux Audit documentation and specifications

Russian documentation

See README_RU.md for the Russian version of this documentation.

Dist-git repository notes

• Package repository: rpms/audit
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.