conntrack-tools

Overview

conntrack-tools is the userspace companion set for Linux connection tracking. It provides a command-line interface for inspecting and managing the kernel connection tracking table, and a daemon for state synchronization and related stateful firewall use cases. In practice, it gives administrators a way to work with conntrack state from userspace instead of relying on older /proc interfaces. (netfilter.org)

For a Linux distribution, this package exists so the userspace tools and their packaged metadata can be built, updated, and verified in a controlled way. NiceOS packages should treat this repository as the packaging source of truth, not as a mirror of the full upstream source tree.

Purpose and typical use cases

Typical uses include:

• listing tracked connections
• filtering, searching, or deleting specific conntrack entries
• monitoring connection-tracking events
• working with state tables used by firewall and network automation workflows
• using conntrackd where state synchronization or related HA scenarios are needed

Typical users include:

• system administrators
• network and firewall operators
• developers who work on packet filtering or netfilter-related tooling
• CI/CD maintainers who validate packaging changes and build results
• security engineers who need to inspect conntrack state during incident response or troubleshooting

Upstream project

The upstream project is maintained in the Netfilter ecosystem. Its official project pages and documentation describe the purpose of the tools, the man pages, and the user manual. The project homepage is the best first reference for package maintainers, while the documentation pages are useful when checking CLI behavior or packaging expectations. (netfilter.org)

If a maintainer needs to confirm command behavior, supported options, or documentation scope, use the upstream man pages and manual rather than relying on distribution summaries. (conntrack-tools.netfilter.org)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source manifests and related source metadata
• METADATA/ — package metadata used by the dist-git workflow
• SBOM/ — software bill of materials material, when present in the repository layout

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files under SOURCES/, which record what should be fetched and verified during packaging workflows.

Source storage and integrity policy

NiceOS maintainers should treat the SOURCES/ manifests as the authoritative record for source inputs. The repository is expected to contain metadata about upstream sources, not the full upstream payload itself.

Before updating the package, verify that:

• the new upstream release still matches the project’s packaging assumptions
• the source manifest entries in SOURCES/ are updated consistently
• any local patches still apply cleanly
• documentation paths, man pages, or install paths have not changed in a way that affects the spec file
• build-time dependencies or optional features have not shifted in a way that changes the RPM build outcome

If upstream changes the source layout or release process, NiceOS maintainers should verify whether additional packaging adjustments are needed before relying on the update.

NiceOS maintenance notes

Before submitting an update, check:

• whether the spec file still reflects the upstream build system and installed artifacts
• whether %check or other verification steps are still meaningful and pass cleanly
• whether any generated files in the packaging tree need regeneration
• whether the package still installs the expected binaries, man pages, and documentation
• whether upstream documentation or CLI output changed enough to require packaging notes
• whether downstream patches can be dropped, refreshed, or need review

Risks to consider during updates:

• changes in upstream build tooling or autotools configuration
• changes in man page names, installation paths, or helper scripts
• behavior differences in connection tracking commands that may affect automated tests or operator playbooks
• packaging regressions caused by stale manifests or mismatched source metadata

Build and verification checklist

For a normal RPM maintainer workflow, verify the following before landing an update:

1. Refresh the source metadata in SOURCES/ if upstream inputs changed.
2. Confirm the spec file still points to the expected build artifacts and subpackages.
3. Run the RPM build in a clean environment.
4. Review build logs for warnings that indicate packaging drift.
5. Inspect the resulting files to confirm the binaries, man pages, and docs are installed in the right locations.
6. If tests are available, run them and confirm they still reflect the packaged functionality.
7. Check for unwanted file-list changes, new runtime dependencies, or missing ownership entries.
8. Review whether any generated packaging metadata needs updating before commit.

If a particular verification step depends on upstream behavior that is not obvious from the packaging tree, NiceOS maintainers should verify it against upstream documentation before relying on the result.

References

• conntrack-tools project homepage
• conntrack manual page
• conntrack-tools user manual
• Netfilter documentation index
• conntrack-tools release information

Russian documentation

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

Dist-git repository notes

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