Why: local devcontainer runs should not depend on a password for maintenance commands such as starting mysql.
Impact: Ubuntu dev containers grant passwordless sudo to all users, and devcontainer.sh now supplies passwd/group/shadow entries for numeric uid/gid mappings when needed.
Before/After: mapped uid 1000 and unknown numeric users could fail sudo; now both can run sudo -n in the devcontainer path.
Technical Overview: Add a final sudoers rule to the active Ubuntu 20.04, 22.04, 24.04, and 26.04 development base images so every user known inside the image gets NOPASSWD sudo.
Teach devtools/devcontainer.sh to normalize RSYSLOG_CONTAINER_UID into real docker -u arguments, preserving the empty value that selects the image default user.
When a numeric uid:gid mapping is used, copy passwd, group, and shadow from the image into temporary files and add a synthetic user/group for missing ids. Bind those files read-only into the container so sudo can resolve and validate the invoking account.
Validate the wrapper with shell syntax checks, shellcheck, an arbitrary uid userdb smoke test, sudoers validation, and a rebuilt Ubuntu 26.04 image sudo/mysql smoke test.
With the help of AI-Agents: Codex
Why:
Container image CI validates the PPA-backed container package family, not
ordinary source changes, and it must not mix Ubuntu archive rsyslog
modules with Adiscon PPA core packages.
Impact:
Container CI now runs only for container workflow/package changes or a
manual dispatch. Container builds fail if the selected PPA cannot be
refreshed or if rsyslog packages would come from Ubuntu's archive.
Before/After:
Before, the workflow produced no-op results for unrelated PRs and apt
could continue after a PPA refresh warning; after, the workflow is
path-scoped and rsyslog packages are pinned to the selected Adiscon PPA.
Technical Overview:
Restrict the pull_request trigger to packaging/docker/rsyslog and this
workflow file, matching the purpose of the container smoke tests.
Remove the changed-files no-op gate because the workflow is no longer a
broad branch-protection placeholder.
Keep the short SHA output out of the shell script body by passing it via
the smoke-test step environment.
Pass the selected PPA origin into the minimal image build and install an
apt preferences file that prefers rsyslog packages from that origin and
rejects rsyslog packages from Ubuntu.
Use APT::Update::Error-Mode=any for all PPA-dependent image layers so a
PPA refresh problem fails before apt can use stale or fallback indexes.
With the help of AI-Agents: Codex
Why:
Keep CI current with the Ubuntu toolchain that developers and future
runners will increasingly see. Ubuntu 26.04 brings newer compiler,
libc, curl, CMake, and clang analyzer behavior, so it is useful as an
early warning lane before broader CI migration.
Impact:
Only the clang static analyzer job moves to Ubuntu 26.04 for now. The
rest of CI stays on the existing images. Follow-up commits are expected
to move additional CI jobs after this canary lane has proven stable.
Before/After:
Before, the static analyzer used the Ubuntu 24.04 dev image. After, it
uses the Ubuntu 26.04 image and the current clang analyzer toolchain.
Technical Overview:
Duplicate the Ubuntu 24.04 dev base image definition for 26.04 and keep
its DockerHub tag as rsyslog/rsyslog_dev_base_ubuntu:26.04.
Use the 24.04 OBS package repository where 26.04 packages are not yet
published, and update bootstrap details for current Ubuntu behavior.
Set the 26.04 container analyzer defaults to the installed clang 21
scan-build tools and llvm-symbolizer.
Switch only the GitHub Actions clang static analyzer job to the new
26.04 image.
Fix the 26.04 image helper script so cleanup does not hide test failure,
and remove a stale sudoers entry for a user that is not created.
Docker Definitions:
Add packaging/docker/dev_env/ubuntu/base/26.04 as the new Ubuntu 26.04
base image directory. It contains the Dockerfile, build helper,
tag-previous helper, and the ClickHouse TLS/config files copied from the
24.04 environment so the new image has the same test support surface.
The Dockerfile remains a direct 24.04 derivative, with only the changes
needed for Ubuntu 26.04 package availability, current tool behavior, and
the clang static analyzer canary.
Static Analyzer Findings:
The newer analyzer found several real defensive gaps. These are fixed
with normal runtime checks and error handling rather than suppressions:
path rewriting now updates the intended byte, empty TCP worksets are
rejected before dereference, template creation errors are propagated,
decrypt reads handle EOF and stream errors cleanly, and statefile,
journal, DTLS socket, and Kubernetes metadata paths now guard invalid
or missing values.
The newer Ubuntu headers also exposed portability issues in libcurl
calls. Those were not analyzer bugs, but the 26.04 toolchain correctly
requires long or size-typed arguments for several curl options. The
affected HTTP, ClickHouse, Elasticsearch, Kubernetes, HTTPFS, and fmhttp
paths now pass the expected types.
One report led to hygiene rather than a proven runtime bug: omfwd now
stores errno immediately after sendto so later logging cannot obscure
the original send failure.
The remaining analyzer reports were reviewed as false positives and are
suppressed narrowly for clang analyzer builds only. KSI state restore
and IV seeding are serialized by module_lock, and omprog status reads
are bounded by the preceding poll timeout. The suppression sites include
inline comments explaining those assumptions.
Docker image:
rsyslog/rsyslog_dev_base_ubuntu:26.04
sha256:576d27bf5c9c783989caf8aeeae0c6bce1434b547b09fdf1ae956033058144f5
Validation:
devtools/format-code.sh --git-changed
Docker image rebuild and post-build tool/user checks.
sh -n packaging/docker/dev_env/ubuntu/base/26.04/build.sh
git diff --check
static analyzer in rsyslog/rsyslog_dev_base_ubuntu:26.04
with SCAN_BUILD=scan-build, SCAN_BUILD_CC=clang, and
SCAN_BUILD_REPORT_DIR=scan-build-report.
The run starts from make clean inside the dev container and reports:
scan-build: No bugs found.
static analyzer result: 0
With the help of AI-Agents: Codex, Rawls
Why:
Container image CI validates the PPA-backed container package family, not
ordinary source changes, and it must not mix Ubuntu archive rsyslog
modules with Adiscon PPA core packages.
Impact:
Container CI now runs only for container workflow/package changes or a
manual dispatch. Container builds fail if the selected PPA cannot be
refreshed or if rsyslog packages would come from Ubuntu's archive.
Before/After:
Before, the workflow produced no-op results for unrelated PRs and apt
could continue after a PPA refresh warning; after, the workflow is
path-scoped and rsyslog packages are pinned to the selected Adiscon PPA.
Technical Overview:
Restrict the pull_request trigger to packaging/docker/rsyslog and this
workflow file, matching the purpose of the container smoke tests.
Remove the changed-files no-op gate because the workflow is no longer a
broad branch-protection placeholder.
Keep the short SHA output out of the shell script body by passing it via
the smoke-test step environment.
Pass the selected PPA origin into the minimal image build and install an
apt preferences file that prefers rsyslog packages from that origin and
rejects rsyslog packages from Ubuntu.
Use APT::Update::Error-Mode=any for all PPA-dependent image layers so a
PPA refresh problem fails before apt can use stale or fallback indexes.
With the help of AI-Agents: Codex
Why:
Users need official rsyslog container images on ARM64 systems, including
SBCs and ARM64 cloud instances.
Impact:
Manual container releases can now publish amd64 and arm64 manifests.
Before/After:
Before, release publishing produced single-architecture Docker images.
After, release publishing uses Buildx for linux/amd64 and linux/arm64.
Technical Overview:
Add Buildx release targets for all published container image variants.
Keep local Docker builds single-platform by default.
Add an optional DOCKER_BUILD_PLATFORM knob for CI validation builds.
Pass release platforms through release-images.sh with --platforms.
Update container CI to build each image variant for amd64 and arm64.
Document the multi-platform release flow and manifest-based latest tags.
Validation:
bash packaging/docker/rsyslog/release-images.sh --help
bash -n packaging/docker/rsyslog/release-images.sh
Closes: https://github.com/rsyslog/rsyslog/issues/6738
Why:
The collector image documentation said omkafka was available, but
its package was never installed in the image.
Impact:
Collector containers now ship rsyslog-kafka and the docs describe
that Kafka use still requires mounted custom config.
Before/After:
Before the collector image lacked omkafka; after it ships the
module and documents the supported config boundary.
Technical Overview:
Install rsyslog-kafka in the collector Dockerfile together with the
existing collector-focused packages.
Update the collector container reference and Docker Hub metadata to
state that omkafka is included for custom rules.
Clarify that environment variables only control the packaged
collector snippets and do not provide a built-in Kafka forwarding
interface.
Closes https://github.com/rsyslog/rsyslog/issues/6471
With the help of AI-Agents: Codex
Why:
The PR review correctly pointed out that one Docker build
argument was passed but never consumed. Keeping it produces
unnecessary builder noise and weakens the change.
Impact:
Container builds no longer pass an unused build argument.
Before/After:
Before: docker build received an unused RSYSLOG_PPA_CHANNEL arg.
After: docker build only receives the consumed PPA arg.
Technical Overview:
Remove RSYSLOG_PPA_CHANNEL from PPA_BUILD_ARGS in the Docker
Makefile.
Keep RSYSLOG_APT_PPA as the single build argument that controls
the selected package source inside the minimal image build.
This preserves the stable-by-default and daily override
behavior without Docker warnings about unconsumed arguments.
With the help of AI-Agents: Codex
Why:
Operators rebuilding user-facing images after a stable rsyslog
release should not silently pull packages from daily-stable.
The workflow needs a stable-first default with an explicit
opt-in path for daily builds.
Impact:
Container builds and release pushes now use v8-stable by
default and can switch to daily-stable explicitly.
Before/After:
Before: rsyslog image builds always installed from daily-stable.
After: builds default to v8-stable and daily-stable is opt-in.
Technical Overview:
Add PPA_CHANNEL to the container Makefile and validate the
accepted channel values.
Pass the selected Adiscon PPA into the minimal image build as
an explicit Docker build argument.
Keep release_build, release_push, and release_publish aligned
with the selected release channel.
Add a release-images.sh wrapper that uses stable by default and
exposes explicit long options plus a --daily shortcut.
Update the Docker documentation to describe the stable default,
the daily override, and the wrapper workflow.
With the help of AI-Agents: Codex
Why:
The service-input hardening pass needs imczmq to reject malformed
configuration early and CI to have the dependencies needed to cover
that path reliably.
Impact:
Invalid imczmq topic and socktype settings now fail closed, and the
Ubuntu 24.04 check lanes install the missing libevent dependency.
Before/After:
Before, imczmq mutated owned topic state, leaked topic strings, and
accepted oversize topics until listener setup; after, config parsing
validates and preserves topic state up front and CI can exercise it.
Technical Overview:
Add a topic validator that rejects per-topic entries longer than the
fixed subscription buffer before runtime setup.
Convert imczmq config string extraction to checked allocations and
reject unsupported socktype values explicitly.
Stop mutating the owned topics pointer while iterating subscriptions,
so listener setup works from stable config state.
Free topics during config teardown to close the matching lifecycle gap.
Register a direct N1 regression for oversize topics and extend its
module search path to include the contrib build output.
Install libevent-dev in the Ubuntu 24.04 check workflow and the
matching dev container source so imhiredis coverage is available.
With the help of AI-Agents: Codex
Why: The Alpine dev image build script should show the exact image tag
to push after a successful local build.
Impact: `packaging/docker/dev_env/alpine/build.sh` now prints a push
command after the image build completes.
Before/After: Before, the script stopped after `docker build`; after, it
prints the matching `docker push` target for the Alpine image.
Technical Overview:
Keep the Alpine container build flow unchanged.
Add a short post-build message that matches the container tag used by the
script.
Make the push target explicit so local image publication is unambiguous.
With the help of AI-Agents: Codex
Why: Add Alpine coverage for the compile workflow and container.
Impact: run_checks now exercises an Alpine dev image in the compile matrix.
Before/After: Before, Alpine builds were not checked; after, the
compile job runs inside the Alpine dev container.
Technical Overview:
Update `.github/workflows/run_checks.yml` to add an Alpine matrix entry
and watch the Alpine dev container tree.
Refresh `packaging/docker/dev_env/alpine/Dockerfile` and
`setup-system.sh` for the current build image and package set.
Keep the Alpine dev container working from `/rsyslog` so the existing
devcontainer scripts can run the configure/build path unchanged.
Align the Alpine configure options with the packages available in the
container and keep the setup helper in sync.
With the help of AI-Agents: Codex
Summary
Ensures Docker images include timezone data for correct timestamp
handling in containerized environments. This improves reliability
and avoids subtle issues with missing timezone info in logs.
Impact: Containers now have timezone data available; image size
increases slightly.
Before: minimal and standard images installed rsyslog packages
without tzdata, which could lead to missing timezone information
at runtime.
After: tzdata is installed alongside rsyslog packages in both
images, ensuring consistent timezone support.
References
Refs: #6623
Why:
The container family needed a practical least-privilege step without
breaking the collector role or the existing ROSI and third-party tutorial
story around privileged listener ports.
Impact: Base images now default to non-root; collector-side roles stay root.
Before/After: The whole family ran as root by default; minimal and
standard now default to syslog:adm, while collector, dockerlogs, and etl
stay root for compatibility.
Technical Overview:
The minimal image now makes its shipped writable paths explicit and sets
USER syslog:adm by default. The standard image temporarily switches back
to root for package installation, then returns to syslog:adm for runtime.
Collector, dockerlogs, and etl now explicitly keep USER root. The
collector and etl roles still bind privileged listener ports, and the
collector contract is preserved to avoid breaking ROSI Collector and
related tutorials. Dockerlogs also stays root because common deployments
rely on Docker daemon or socket access.
The container docs and image READMEs now describe this split runtime
contract. The container CI workflow checks that minimal and standard
start with UID 101 while the specialized roles continue validating with
their existing startup assumptions.
With the help of AI-Agents: Codex
Why:
Recent review feedback treated `packaging/docker/rsyslog/host/` as a
missing image variant because its README read like an image-specific
artifact. The current tree needs a sharper boundary between published
images and auxiliary packaging material.
Impact: No behavior change; documentation now states the support scope.
Before/After: `host/` looked like an image variant; it now reads as
auxiliary host-side material outside the published image family.
Technical Overview:
The top-level rsyslog container README now states explicitly that the
published image family in this subtree is limited to the five variants
built by the Makefile.
The `host/README.md` file now says this directory is not a built or
published Docker image target. It explains that the contents are
host-side forwarding configuration material and points readers back to
the main container README for the actual supported image list.
With the help of AI-Agents: Codex
Why: Docker Hub repository descriptions are part of the user-facing
container story, but updating them manually is repetitive and easy to
let drift from the repo docs.
Impact: no container image behavior changes; this adds a local helper
for dry-run or explicit metadata sync against Docker Hub.
Before/After: Docker Hub description updates relied on ad hoc local API
calls; the repo now contains a reusable metadata file and sync script.
Technical Overview:
The new `dockerhub_metadata.json` file stores the current short and long
repository descriptions for the user-facing rsyslog images.
The new `sync_dockerhub_metadata.py` script reads credentials from
`DOCKERHUB_USERNAME` / `DOCKERHUB_PASSWORD` or the local Docker config,
defaults to a dry run, and only writes when `--apply` is passed.
The container packaging README now documents that this subtree owns the
Docker Hub metadata source of truth and the helper workflow.
With the help of AI-Agents: Codex
Why: the `rsyslog-etl` image is a specialized Vespa-oriented pipeline
and should not be presented as a broadly supported general-purpose
container role.
Impact: no image behavior changes; the docs and packaging README now say
explicitly that the ETL image is experimental.
Before/After: the repository described ETL as a user-facing image but
left its support level implicit; it now states that the image is
experimental and specialized.
Technical Overview:
The ETL container page now includes an explicit warning that the image is
experimental and should be treated as a specialized example role.
The user-image overview now labels `rsyslog/rsyslog-etl` as
experimental, and the packaging-local ETL README uses the same wording
for consistency with the Dockerfile metadata.
With the help of AI-Agents: Codex
Why: release-tagged container images should only be published after the
matching rsyslog packages are available in the correct Adiscon PPA.
Impact: manual release flows now use fixed stable and daily-stable
channels, derive the stable container tag automatically from
`RSYSLOG_VERSION`, and update `latest` only when explicitly requested.
Before/After: release-tagged image publishing was a manual sequence
without a package-availability gate or an explicit `latest` decision;
it is now an explicit release workflow with a lightweight PPA readiness
check and fixed channel rules.
Technical Overview:
The Docker image Makefile now adds explicit manual release targets:
`release_build`, `release_push`, and `release_publish`.
The stable channel uses `ppa:adiscon/v8-stable` and derives the image
tag from `RSYSLOG_VERSION` using `8.yymm.0` -> `20yy-mm`. The
daily-stable channel uses `ppa:adiscon/daily-stable` and the fixed image
tag `daily-stable`.
Before any release build or push proceeds, a disposable Ubuntu container
checks that the selected channel exposes the requested rsyslog release
series. The real image build remains the source of truth for package
completeness.
`release_publish` updates `latest` only when `PUSH_LATEST=yes` is set.
The operator README now documents the channel rules, the stable tag
mapping, and the manual release workflow consistently with the Makefile.
AGENTS.md adds the same container guidance for future AI-driven changes.
With the help of AI-Agents: Codex
Why: the container image family needs an explicit versioning contract
before release publishing is automated, and the current default tag
looks too much like a real release.
Impact: local builds now default to a non-release tag, publish flows
require an explicit stable version, and the version contract is
documented for both users and AI agents.
Before/After: local `make all` no longer emits release-like image
tags by default; release-style tags must now be requested
intentionally.
Technical Overview:
Change the Docker image Makefile default VERSION from a release-like
value to `dev-local`.
Keep explicit `VERSION=...` overrides for local release rehearsals and
for CI or release automation.
Add a publish guard that rejects empty, dev-local, `dev-*`, and
`ci-*` versions for push and latest-tag targets.
Document the container version and publishing contract in a new
`packaging/docker/rsyslog/README.md`.
Add repository-level AI guidance so future agents keep local container
build defaults clearly non-release.
Clarify in the container CI workflow that `ci-<sha>` is a validation
version and that release workflows must inject a stable version
explicitly.
With the help of AI-Agents: Codex
Why: the image family has a few easy-to-fix issues that reduce
trust in the current packaging and make future automation less
clean.
Impact: image metadata is now populated consistently, the ETL
image no longer exports unused file-output env vars, and the
minimal image drops an unnecessary editor package.
Before/After: placeholder or missing OCI metadata and minor image
rough edges are replaced with cleaner, more accurate image
artifacts.
Technical Overview:
Add OCI image labels to the minimal, standard, collector,
dockerlogs, and etl Dockerfiles.
Teach the Docker image Makefile to pass build date and VCS
revision into docker build so the new labels carry useful values
in normal local builds.
Remove vim-tiny from the minimal image so the base runtime stays
closer to an actual minimal container.
Remove WRITE_ALL_FILE and WRITE_JSON_FILE from the etl image
because the shipped ETL config does not consume them.
Validate the updated family by rebuilding all rsyslog Docker
images with the packaging Makefile.
With the help of AI-Agents: Codex
Why
Native post-quantum TLS support should be usable and testable on newer
distro baselines without adding provider-mode compatibility work for
older platforms.
Impact
Rsyslog now has native-PQ smoke tests, clearer TLS diagnostics, updated
CI baselines and helper images, and a new post-quantum tutorial for
supported distros.
Before/After
Before: Fedora CI still targeted Fedora 41, PQ-capable TLS settings had
no dedicated rsyslog tests or user-facing tutorial, and stricter clang
builds could fail on warning-group handling.
After: CI targets Fedora 43, native PQ usage is documented and smoke-
tested, helper images include the required tools, and the branch builds
and tests cleanly with the newer compiler/container combinations.
Technical Overview
The CI matrix now replaces the Fedora 41 lane with Fedora 43 and adds a
matching Fedora 43 development image.
The Debian 13 and Fedora 43 development containers now install the
GnuTLS CLI utilities needed for native PQ capability checks.
The OpenSSL TLS config path logs clearer messages when a command or
value is unavailable on the native OpenSSL build.
The GnuTLS TLS config path reports unsupported priority-string options
more explicitly.
Two new shell tests add native PQ smoke coverage for OpenSSL and GnuTLS
using the existing gnutlsPriorityString control surface.
Those tests self-skip unless the local native TLS libraries expose the
required hybrid group support.
The imtcp parameter docs and omfwd docs now explain the native-only PQ
support policy and include example configurations.
A new tutorial documents native PQ usage for OpenSSL and GnuTLS on
supported newer distro versions.
The shared runtime warning policy in rsyslog.h now tolerates clang
handling of unknown warning groups so older and newer clang lanes remain
warning-free under the existing finalize_it error-handling pattern.
Testbench follow-ups harden omfwd-lb-susp with isolated retry attempts,
skip rcvr_fail_restore on ARM where it is timing-flaky, and keep local
SC2181 suppressions where if-exec rewrites would reduce shell-script
usability.
The Fedora 43 Dockerfile now cleans the dnf cache after install and
locally suppresses the non-useful DL3041 package-version pinning warning.
Older distro versions remain intentionally unsupported for PQ in this
phase because we expect users to move to newer baselines first.
If there is demand later, older-version support can be considered in a
separate effort.
With the help of AI-Agents: Codex
Why: Enable automated deployment of rsyslog documentation to GitHub
Pages with Google Analytics, using the same build setup as production.
Impact: New workflow, build script, and Docker image updates; removes
cleanup_pr_preview job from doc_build.yml.
Before: Documentation deploy was manual; PR preview folders lingered
on gh-pages after PR close.
After: Push to main triggers build and deploy to /doc/ with GA; root
redirects to /doc/; robots.txt restricts crawling to /doc/ only;
PR preview cleanup removed in favor of Pages artifact deploy.
Technical Overview:
- Add .github/workflows/doc_deploy_main.yml: triggers on push to main,
master, pr/publish-doc or workflow_dispatch; builds in Docker with
rsyslog_dev_doc_base_ubuntu:22.04; deploys under /doc/ via
upload-pages-artifact; runs container as -u "$(id -u):$(id -g)";
adds root index.html redirect, robots.txt (Allow /doc/, Sitemap).
- Add doc/tools/inside_docker_doc_html.sh: uses pre-built venv from
image; sets RSYSLOG_DOC_VERSION/RSYSLOG_DOC_RELEASE_TYPE; runs
sphinx-build with Furo/sitemap; applies Mermaid fix.
- doc/source/conf.py: support RSYSLOG_DOC_VERSION and
RSYSLOG_DOC_RELEASE_TYPE env vars; format rst_prolog for non-git
builds; use release_type in release string (Gemini feedback).
- Add doc/tools/pages-root-index.html (redirect / to /doc/),
doc/tools/pages-robots.txt (Allow /doc/, Disallow /, Sitemap).
- packaging/docker/dev_env/ubuntu/doc_base/22.04: add python3-venv;
pre-build /opt/rsyslog-doc-venv from doc/requirements.txt; build.sh
runs from repo root for COPY.
- doc/Makefile.am: add inside_docker_doc_html.sh, pages-root-index.html,
pages-robots.txt to EXTRA_DIST.
- doc_build.yml: remove cleanup_pr_preview job.
Requires GOOGLE_ANALYTICS_ID repository secret.
* build: default-enable impstats-push and align CI containers
Enable impstats-push by default and keep configure strict when dependencies are missing.
Update CI/container definitions for distro differences (CentOS/OpenEuler/Ubuntu and workflow overrides), add explicit --disable-impstats-push where impstats is disabled, and fix impstats protobuf generation for distcheck/VPATH builds.
Why:
Reduce CI image transfer and startup time without removing required
runtime dependencies.
Impact:
Smaller ubuntu 24.04 dev image; build.sh container test still passes.
Before/After:
24.04 image went from 3.73 GB to 3.48 GB (~242.6 MiB smaller).
Technical Overview:
Keep dependency package set intact and focus on artifact cleanup.
Add apt list/cache cleanup to apt install layers.
Remove temporary build trees and pip cache artifacts.
Delete selected source-built static archives in the same RUN steps
that install them so they do not inflate final image layers.
Keep toolchain-required archives intact to avoid linker regressions.
Retain build.sh behavior and validate by running full build.sh flow.
With the help of AI-Agents: Codex
Adds first-class integration with VictoriaMetrics to simplify ops
dashboards and move toward project-supported telemetry without
sidecar collectors.
Impact: New optional feature (off by default). No behavior change
unless configured via push.* parameters.
Before: impstats could only log locally or emit text formats.
After: impstats can push counters to Prometheus-compatible endpoints.
Technical: implement a native Prometheus Remote Write path in
impstats, encoding counters to protobuf and compressing with snappy
over HTTP via libcurl. Replace interim text parsing with a new
statsobj v14 API (GetAllCounters) that iterates raw uint64 counters,
keeps atomic reads for IntCtr and best-effort reads for Int. Add
metric builder with Prometheus-compliant sanitization and the naming
pattern <origin>_<name>_<counter>_total. Provide TLS knobs (CA, mTLS,
insecureSkipVerify), static/dynamic labels, timeout, and optional
batching by bytes/series. Build is gated behind
--enable-impstats-push with protobuf-c/snappy/curl checks. Ship docs,
basic/VM integration tests, and a GitHub Actions workflow using a
VictoriaMetrics service; TSAN jobs disable impstats-push.
Configuration: push.url, push.labels, push.timeout.ms,
push.label.{instance,job,origin,name}, push.tls.{cafile,certfile,
keyfile,insecureSkipVerify}, push.batch.{maxBytes,maxSeries}.
With the Help of AI Agents: ChatGPT codex 5.2
Keep SNMP test coverage working on newer Python versions and improve
omsnmp consistency across config styles.
Before: Debian 13/sid SNMP tests were disabled due to python3-pysnmp4
breakage with Python 3.12+; omsnmp legacy selector config diverged from
newActInst setup.
After: Debian 13/sid images install python3-pip and upgrade pysnmp/pyasn1
via pip; omsnmp legacy path requests 2 templates and sets the SNMPv1
source template like the modern path.
Also ensure omsnmp uses heap-backed peername/community buffers for
snmp_open() and frees instance-owned config strings in freeInstance().
Drop test-snmp-debian13.sh from git tracking (kept as a local helper).
closes: https://github.com/rsyslog/rsyslog/issues/5999
Co-authored-by: alorbach <alorbach@adiscon.com>
The imtcp module was only loaded when ENABLE_TCP=on, but the TLS input
(port 6514) also requires imtcp. This caused TLS to fail when
ENABLE_TCP=off even if ENABLE_TLS=on.
Fix by always loading imtcp unconditionally. The module is lightweight
and harmless if unused, and individual inputs remain independently
controlled by ENABLE_TCP and ENABLE_TLS. This avoids complex shell
expressions that don't work in rsyslog backticks (which only support
simple commands like echo $VAR).
Impact: Users can now enable TLS without enabling plain TCP, allowing
secure log collection without exposing the unencrypted port 514.
Before: ENABLE_TCP=off + ENABLE_TLS=on → TLS fails (module not loaded)
After: ENABLE_TCP=off + ENABLE_TLS=on → TLS works, port 514 not exposed
Add OpenSSL-based TLS support to the rsyslog collector Docker
image, enabling secure log collection over encrypted connections
while maintaining full backward compatibility.
Changes:
- Install rsyslog-openssl package for TLS support
- Add TLS TCP input on port 6514 (RFC 5425)
- Configure OpenSSL StreamDriver with per-input certificate
settings to avoid warnings when TLS is disabled
- Add ENABLE_TLS environment variable (default: off)
- Add TLS certificate path environment variables
- Expose port 6514/tcp for TLS connections
Backward Compatibility:
- TLS disabled by default - no impact on existing deployments
- All existing environment variables and configurations unchanged
- Plain TCP/UDP/RELP inputs remain fully functional
- No warnings generated when TLS is disabled
Impact:
- Enables secure log collection for users requiring encryption
- Zero breaking changes - existing configs work unchanged
- Opt-in feature via ENABLE_TLS=on and certificate configuration
Co-authored-by: alorbach <alorbach@adiscon.com>
Interfacing to vespa.ai and the vespa engine.
This is a first and definitely incomplete PoC, it just lays out
the core ideas and plumbing.
I think it should ideally be ready-to-roll for the public vespa
cloud interface.
Add an openEuler 24.03 LTS development container and wire it into CI to
validate builds on that platform.
Why: expand RPM-based coverage and catch distro-specific build issues
early.
Impact: CI-only. No runtime or API changes.
Before: no openEuler container or CI job; build breakage went unnoticed.
After: dedicated container and matrix entry compile and run unit tests
on openEuler.
Notes: module and test coverage may differ on openEuler; track gaps in
follow-up issues.
This parses the LEEF message (if it is) and creates a JSON subtree.
The current implementation is PoC and will be provided to gather
early review.
Changes, including breaking changes, may happen in future versions of
this module.
there was "workaround" introduced in the container which prevented
to detect some issues in libgrypt-related code. This was probably done
to get newer version in dev env without the need to adapt code to
broken libgrypt API level in new version.
That prevented issues in https://github.com/rsyslog/rsyslog/pull/5406
to be deteced.
