feat: add curated telegraf 1.38.2 build for Azure Linux 4.0 (#20399)

[WithEnoughCoffee]

Summary

Telegraf shipped in Azure Linux 3.0 but is missing from 4.0. This restores it as a general-purpose, plugin-driven agent for collecting, processing, aggregating, and writing metrics. Resolves #20399.

Why a curated build

Built upstream-default, telegraf links ~400 plugins and the full transitive dependency tree — a large CVE surface, vendor footprint, and binary for a distro we maintain. Instead we compile a curated ("Balanced", 108 build tags) set: 63 inputs, 15 outputs, 7 processors, 4 aggregators, 12 parsers, 7 serializers. The rest are absent from the binary at build time.

• General-purpose — common system, network, database, container, and cloud inputs/outputs included, useful out of the box.
• Full first-party Azure + GitHub — azure_monitor (in/out), azure_storage_queue, eventhub_consumer, azure_data_explorer, and the github input are all included, since AzL is an Azure/Microsoft + GitHub product and these should work by default.
• Smaller attack/maintenance surface — fewer compiled plugins → fewer linked deps, fewer CVEs, smaller binary. Concretely: 261 modules linked vs 603 vendored (~57% dropped).
• Reviewable & adjustable in one place — the entire plugin policy is a single spec macro (%global buildtags). Adding (or removing) a plugin is a one-line change — append its tag to the macro, e.g.:

       inputs.cpu inputs.disk inputs.diskio inputs.mem inputs.net inputs.netstat \
  +    inputs.redis \

  then re-render and rebuild. No %build/%install/%files changes are needed, so curation stays easy to audit and evolve as requirements change.

Packaging (Fedora Go guidelines)

Uses the go2rpm --profile vendor scaffold as the baseline (Go Vendor Tools, vendored deps, %gobuild with GO_BUILDTAGS/GO_LDFLAGS), so it can be upstreamed to Fedora and matches the vendored-Go pattern AzL already uses (rootlesskit, git-lfs). Divergences are marked # AzL:. The full vendor tree is retained (Fedora requires it); curation only affects what is compiled. The cumulative SPDX License tag is computed with go_vendor_license and enforced by %go_vendor_license_check; bundled(golang(...)) provides are auto-generated.

systemd hardening

A drop-in (50-hardening.conf) sandboxes the unprivileged agent — ProtectSystem=full, ProtectHome, ProtectHostname, ProtectClock, ProtectKernel{Tunables,Modules,Logs}, ProtectControlGroups, RestrictRealtime, HOME=/var/lib/telegraf — adapted from openSUSE. PrivateDevices is intentionally omitted so hardware inputs (smart, smartctl, ipmi_sensor, infiniband) keep /dev access.

Contents

• telegraf.spec — %gometa, curated %global buildtags, Go Vendor Tools license macros, sysusers (no userdel on uninstall), systemd unit + hardening drop-in, logrotate, generated default config, state dir, %check (license check + binary smoke test).
• telegraf-hardening.conf — systemd sandboxing drop-in.
• go-vendor-tools.toml — askalono detector + manual license entries.
• telegraf.comp.toml — upstream source plus the full vendor tarball.
• telegraf.sysusers, generate_source_tarball.sh, locks/telegraf.lock.

Verification

Full mock build passes every phase including %check. Confirmed in mock:

• Binary reports Telegraf 1.38.2; functional collection works (cpu input loads and emits).
• Curated plugins present (azure_monitor in/out, azure_data_explorer, github, eventhub_consumer, docker, prometheus, snmp, …); non-curated absent (cloudwatch, nvidia_smi, vsphere, ecs).
• Install/erase lifecycle: sysusers creates the telegraf user (home /var/lib/telegraf), unit + drop-in install; on erase the user is intentionally retained.
• systemd-analyze verify accepts the unit + drop-in; debuginfo is split into its own subpackage.

Why 1.38.2 (not 1.39.0)

telegraf 1.39.0's go.mod requires Go 1.26; AzL 4.0 currently ships Go 1.25.8, and 1.38.2 is the latest release that builds on it. We can bump to 1.39.0 once AzL golang reaches ≥ 1.26 (which also drops the logzio azure-monitor dependency).

Known follow-up

• The vendor tarball must be uploaded to the lookaside store and the comp.toml source URI updated to the published URL before CI source checks and package builds can fetch it (currently a placeholder).

[Copilot]

Pull request overview

This PR re-introduces Telegraf (missing from Azure Linux 4.0, shipped in 3.0) as a new local component (base/comps/telegraf/). Because Telegraf's default build links ~400 plugins and the full transitive dependency tree, the spec uses a curated ("Balanced") plugin set (~104 Go build tags via GO_BUILDTAGS) to shrink the binary and its CVE/dependency surface, while still vendoring the full tree per Fedora Go packaging guidelines (%gometa, Go Vendor Tools, %gobuild). It adds systemd/sysusers/logrotate integration and a %check that validates the license expression and runs the binary. It resolves #20399.

Changes:

• Adds a hand-maintained local telegraf.spec with a curated %global buildtags plugin policy, Go Vendor Tools license macros, sysusers, systemd unit, logrotate, and default-config generation.
• Adds the component definition (telegraf.comp.toml, manual release), go-vendor-tools.toml, telegraf.sysusers, a reproducible vendor-tarball generator script, and the rendered specs/lock/sources.
• The vendor tarball source URI is currently a 127.0.0.1 placeholder pending lookaside upload (noted as a known follow-up).

Reviewed changes

Copilot reviewed 9 out of 10 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
base/comps/telegraf/telegraf.comp.toml	Local-spec component def, manual release, two source-files (upstream + vendor); vendor URI is a placeholder.
base/comps/telegraf/telegraf.spec	Curated Go build spec (buildtags, license macros, sysusers, systemd, %check).
base/comps/telegraf/go-vendor-tools.toml	askalono detector + manual SPDX entries for files the detector can't classify.
base/comps/telegraf/telegraf.sysusers	Declarative telegraf system user.
base/comps/telegraf/generate_source_tarball.sh	Reproducible go mod vendor tarball generator; comment references a stale macro name.
specs/t/telegraf/*	Rendered spec/sysusers/go-vendor-tools/sources (body matches base sources).
locks/telegraf.lock	Generated input-fingerprint lock.

Key findings: the helper script's comment cross-references a non-existent %{plugin_tags} macro (spec uses %{buildtags}), and the vendor source URI is an unresolved 127.0.0.1 placeholder that blocks CI fetch/build until replaced. Because this introduces a brand-new forked local spec (a long-term maintenance commitment) for a vendored Go package with a large curated plugin policy, license-expression tracking, and an unresolved source URI, it warrants human review.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 12 changed files in this pull request and generated 1 comment.

[tobiasb-ms]

issue(blocking): While having a list of required follow-ups is good, make sure to remove it before we merge.

[tobiasb-ms]

question(blocking): I left a couple specific comments about this, but what are the practical differences between this and how we packaged it for AZL3? I know we've changed to use a fedora-blessed way of packaging, and that seems righteous. And of course we bumped the version. But I think there are more semantic differences here and we need to know what they are and why we're making them before taking this change.

[tobiasb-ms]

question(non-blocking): Just curious -- how would pruning vendor/ break reproducibility. It would still be the same code right? Or what I am I missing?

[WithEnoughCoffee]

The thing is Go's vendoring is all-or-nothing at the module level — build tags exclude packages from compilation but don't affect the module graph or what go mod vendor pulls in. Even if a plugin is disabled │ via tags, its dependencies still appear in go.mod's require list, so they're part of the build list and must be in vendor/. Pruning them would require regenerating modules.txt, which changes the SRPM's cumulative SPDX │ license metadata and bundled golang declarations. That's why we keep the full vendor tree despite the binary not using all of it.

Hand-deleting directories from  vendor/  (without also editing  go.mod / modules.txt ) makes the tree inconsistent, and the build fails immediately with  inconsistent vendoring  /  go mod verify  errors. The │  custom  build tags exclude plugins from compilation, but those modules are still  require d in  go.mod , so they stay in the build list.

Also it makes it easier to add plugins if we find out customers need plugins we don't have in the curated list.

Pruning "properly" means editing the module graph, which can change the binary. To drop them cleanly you'd remove the  require s from  go.mod  and regenerate  modules.txt . That changes the module graph, and under MVS │ that can shift the selected version of a shared transitive dependency still used by a compiled-in plugin — which would actually change the output. So the only safe-and-identical option is "vendor everything, compile a subset."

Auditability. We compute the cumulative SPDX  License:  and the  bundled(golang(...))  provides over the full vendor tree. A pruned tree would make both tag-combination-dependent and fragile to maintain.

Fedora policy requires vendoring the complete dependency set anyway.

[tobiasb-ms]

These are great arguments for why we should not prune. But as I said I'm curious as to why pruning actually changes reproducibility of the vendored tarball. Yes, it would clearly change it but once it's changed, wouldn't the result be just as reproducible?

[tobiasb-ms]

question(non-blocking): Where did this date come from? It seems pretty arbitrary.

[WithEnoughCoffee]

Good catch. it's arbitrary. The only requirement for a reproducible tarball is that the mtime is a fixed constant, so the literal value carries no meaning — which is exactly why it reads as a magic number. I'll switch it to the convention the rest of the repo already uses for vendor/bundle tarballs ( grafana ,  sleef ,  rust-zip ,  python-pdfminer , …): honor  SOURCE_DATE_EPOCH  when the build provides it, and fall back to a documented fixed epoch instead of an unexplained date. Updated in the next push.

[tobiasb-ms]

Will SOURCE_DATE_EPOCH change across run or is that consistent? I agree with having something that is consistent and long-lasting -- doesn't need to change to SOURCE_DATE_EPOCH or anything. Just wanted to make to make sure the date wasn't something actually special.

I'm changing this to non-blocking and you can decide the right way.

[tobiasb-ms]

suggestion(non-blocking): Here and throughout the file, best practice in bash is to use brace expansion (so ${SRC_TARBALL}). Not critical at all, but if you end up making other changes you can consider this.

[tobiasb-ms]

issue(blocking): Add a link to the fedora go guidelines.

[tobiasb-ms]

question(non-blocking): Did we have this in AZL3? If not, why do we need it here?

[WithEnoughCoffee]

No, AZL3 didn't have this — it installed upstream's  telegraf.service  as-is, with no sandboxing. This is a net-new addition for AZL4.

Rationale: telegraf is a long-lived daemon running as an unprivileged user ( User=telegraf ) whose job is only to read host metrics. That's an ideal candidate for systemd sandboxing as defense-in-depth — if a plugin or a vendored dependency is ever compromised, these restrictions limit blast radius (read-only system, no access to  /home , kernel tunables/modules/logs protected, no realtime, etc.). The directives are stock systemd hardening adapted from openSUSE's hardening effort.

It's shipped as a drop-in ( 50-hardening.conf ) rather than a forked unit, so it overlays upstream without diverging the unit file — easy to audit and tweak. It's also deliberately conservative so it doesn't break │ functionality:
•  PrivateDevices  is omitted because the curated build includes hardware inputs ( smart ,  smartctl ,  ipmi_sensor ,  infiniband ) that need  /dev .
•  HOME=/var/lib/telegraf  is set because some plugin SDKs (e.g. the Azure SDK credential cache) write under  $HOME .

it's a security improvement that aligns with AzL's enterprise hardening posture.

[tobiasb-ms]

Possible that I'm being paranoid here but this feels risky. We're changing the thing we deliver to a customer.

I agree in principal about using stricture security settings though.

I'll change this to non-blocking but let's leave the conversation open for others (maybe @reubeno or @ddstreet) to weigh in.

[tobiasb-ms]

issue(blocking): Why wouldn't we use autorelease here?

[WithEnoughCoffee]

A few reasons, and they line up with how AzL already handles this. The spec doesn't actually use  %autorelease  — it has a static  Release: 1%{?dist}  and a literal  %changelog . The  autorelease  calculation mode is specifically for specs that contain the  %autorelease  macro (it forces azldev to preserve and expand it), so pointing it at a static-release spec would be the wrong mode.

Beyond that,  autorelease  isn't really the AzL convention. Across  base/comps  only 2 of ~173 components use it ( samba  and  gvisor-tap-vsock ), and no local spec uses it at all. AzL seems to renders concrete, checked-in specs under  specs/  with explicit Release and changelog values for reproducible, auditable, offline builds — rpmautospec's git-derived  %autorelease %autochangelog  is really an upstream-Fedora dist-git mechanism and isn't how AzL builds locally. Setting  manual  also mirrors the existing precedent: the other AzL-originating local package,  azurelinux-release , uses the exact same setup ( type = "local" ,  release = { calculation = "manual" │ } , a static  Release: , and a hand-written  %changelog ), so I followed that house pattern to keep the curated changelog and release under explicit human control.

Eventually when this package is purposed to Fedora dist-git, the Fedora-native choice is  %autorelease / %autochangelog  (go2rpm emits them), and we can adopt those at submission time — inside the AzL │ monorepo we just match AzL's convention. And if you'd rather have azldev auto-bump the integer on each component-touching commit,  auto  (the default) would probably be what were looking for vs  autorelease .

Happy to switch to that, though  manual  matches  azurelinux-release  and keeps the hand-written changelog authoritative.

[tobiasb-ms]

The argument that the spec doesn't use %autorelease is circular. That's what I'm asking.

2 of 173 components is misleading -- aren't the vast majority of those overlays on a fedora thing? A quick search I just did four four actual spec files in base/comps, two of which currently use %autorelease.

@reubeno may have some opinions about this.

[reubeno]

For any new specs we author, we should use %autorelease.

[tobiasb-ms]

issue(blocking): This isn't in components-publish-channels.toml, so it will be published to the sdk repo, not the base repo.

[binujp]

rpm-layout, build (blocking): Can you please confirm this builds on koji? I also saw Suse was the reference for defaults. We should lean towards fedora/centos/redhat. There homedir is /etc/telegraf.

dnf repoquery -l telegraf | grep -v build-id
Updating and loading repositories:
Repositories loaded.
/etc/logrotate.d/telegraf
/etc/telegraf/telegraf.conf
/etc/telegraf/telegraf.conf.sample
/etc/telegraf/telegraf.d
/etc/telegraf/telegraf.d/.ignore
/usr/bin/telegraf
/usr/lib/telegraf/scripts/init.sh
/usr/lib/telegraf/scripts/telegraf.service
/var/log/telegraf

[WithEnoughCoffee]

Good question — here's the full inventory of what changed from AZL3 (1.31.0-10) and why. I've split it into (A) behavioral/semantic changes that genuinely affect what ships and how it runs (the ones worth scrutinizing), and (B) mechanical/compliance changes from adopting the Fedora Go scaffold.

A. Semantic / behavioral changes (the ones to sign off on)

#	AZL3 (1.31.0)	AZL4 (1.38.2)	Why
1	All ~415 plugins compiled in	Curated "Balanced" ~108 plugins via upstream custom-builder build tags	Headline change. Binary ~250 MB → ~105 MB; cuts the applicable CVE surface from the vendored Go tree. Risk: any plugin not on the list is absent. Set is one auditable %global buildtags macro and is trivially expandable. Confirming the exact set with the MetricsExtension team is the last open item.
2	Default telegraf.conf from full catalog	Default config generated from the curated binary	Config reflects only compiled-in plugins (no dangling references).
3	%postun runs userdel/groupdel — user removed on uninstall	User is never deleted (declarative sysusers.d; no userdel)	Fedora guideline: removing a system user can orphan files under a later-reused UID. Leaves a telegraf user behind after uninstall.
4	telegraf.conf world-readable (0755, root:root)	telegraf.conf 0640 telegraf:telegraf + telegraf.d/ drop-in dir	Tighter perms; ownership set via %attr instead of a %post chown -R.
5	No sandboxing	systemd hardening drop-in (50-hardening.conf)	Sandboxes the agent (PrivateDevices intentionally omitted so hardware inputs still work). Could restrict plugins needing extra access.
6	Plain go build → effectively static, no debuginfo	%gobuild → PIE + hardened flags + debuginfo/debugsource subpackages	Enterprise/Fedora norm; FIPS-consistent. Dynamic binary instead of AZL3's static one.
7	New: /etc/default/telegraf EnvironmentFile	—	Lets operators pass TELEGRAF_OPTS without editing the unit.

B. Mechanical / compliance changes (no behavioral impact)

• 12 inline CVE patches → 0. The 1.31.0→1.38.2 bump supersedes all of Patch0–11 and clears ~45 backported CVEs; ongoing CVE handling moves to vendor-tree bumps.
• License accuracy. AZL3 declared License: MIT (telegraf's own license only). AZL4 ships the real cumulative SPDX expression computed over the entire vendor tree by go-vendor-tools (askalono) and enforced in %check.
• Packaging model. AZL3 was a hand-written local spec; AZL4 is rebased on the canonical go2rpm --profile vendor scaffold (%gometa -L -f, go-vendor-tools, full vendor archive as .tar.bz2), with every AzL deviation marked # AzL: so it stays auditable and upstreamable. Telegraf isn't in Fedora, so it remains a local component.
• Dependency wiring. Explicit shadow-utils/systemd Requires replaced by %{?systemd_requires} / %{?sysusers_requires_compat}; logrotate/procps-ng unchanged.

Net: the only changes that affect runtime behavior are the curated plugin set (#1–2), the no-user-deletion policy (#3), tighter config perms (#4), and the sandboxing drop-in (#5). Everything else is version/toolchain/compliance hygiene. Happy to expand the plugin set or relax any of these if they conflict with a known consumer.

[WithEnoughCoffee]

issue(blocking): While having a list of required follow-ups is good, make sure to remove it before we merge.

Agreed good call out. I will keep that in mind.

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated 1 comment.