Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

nextcloud.openmetrics.allowedClients is silently ignored unless nextcloud.configs is set

Aperta
  • Qualcosa non va?
#887 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@JanWelker ci sta già lavorando.

Dal 21/9/2026.

  • #888 di @JanWelker — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
78/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
helm, kubernetes
Ambito
devops, infrastructure

Direzione di ricerca

Read charts/nextcloud/templates/_helpers.tpl and templates/config.yaml, focusing on the defaultConfigs guard and ConfigMap rendering. Render the chart with openmetrics.allowedClients set while nextcloud.configs is empty, then verify that helm-metrics.config.php is mounted and the setting is available to Nextcloud without unrelated configuration.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Describe the bug

nextcloud.openmetrics.allowedClients renders OPENMETRICS_ALLOWED_CLIENTS into the app
container, but nothing in the pod ever reads it. The only reader is
files/defaultConfigs/helm-metrics.config.php.tpl, and the defaultConfigs files are only
mounted when nextcloud.configs is non-empty
(_helpers.tpl#L431);
templates/config.yaml renders no ConfigMap at all otherwise.

So with the chart's default nextcloud.configs: {}, setting allowedClients does nothing:
Nextcloud keeps its built-in default of 127.0.0.1 only, and Prometheus is refused with 403.

This is the same gate reported in #761, but it bites differently here. The argument there for
keeping it — "normally you do not need the defaultConfig, because the files are already part of
the container image" — does not hold for helm-metrics.config.php. Like imaginary.config.php,
it is a chart file, not one of nextcloud/docker's.
There is no image copy to fall back on, so nextcloud.openmetrics.allowedClients cannot work on
its own under any configuration.

It also affects the chart's own defaults: prometheus.serviceMonitor selects the app Service as
well as the exporter Service, so an out-of-the-box metrics.enabled: true +
prometheus.serviceMonitor.enabled: true install scrapes /metrics on the app pod, gets a 403,
and sits with a permanently down target firing TargetDown.

Steps to reproduce
nextcloud:
  openmetrics:
    allowedClients:
      - "127.0.0.1"
      - "10.244.0.0/16"   # your pod CIDR
metrics:
  enabled: true
prometheus:
  serviceMonitor:
    enabled: true

$ kubectl exec deploy/nextcloud -c nextcloud -- sh -c 'echo $OPENMETRICS_ALLOWED_CLIENTS'
127.0.0.1,10.244.0.0/16

$ kubectl exec deploy/nextcloud -c nextcloud -- ls /var/www/html/config/
apache-pretty-urls.config.php  apcu.config.php  apps.config.php  autoconfig.php
config.php  config.sample.php  redis.config.php  reverse-proxy.config.php
s3.config.php  smtp.config.php  swift.config.php  upgrade-disable-web.config.php
# no helm-metrics.config.php

$ kubectl exec deploy/nextcloud -c nextcloud -- sh -c 'cd /var/www/html && php occ config:system:get openmetrics_allowed_clients'
# unset

$ # from a pod whose IP is inside the CIDR above
$ curl -o /dev/null -w '%{http_code}\n' http://<nextcloud-pod-ip>:80/metrics
403

Adding any entry to nextcloud.configs makes it work, which is the tell.

Expected behaviour

Setting nextcloud.openmetrics.allowedClients configures openmetrics_allowed_clients, without
also having to set an unrelated value.

Possible fix

Drop the {{- if .Values.nextcloud.configs }} guard around the defaultConfigs loop in
_helpers.tpl and around the ConfigMap in config.yaml, as #761 asks. At minimum,
helm-metrics.config.php and imaginary.config.php need to mount whenever they are enabled,
since neither exists in the container image.

Versions
  • Chart 9.3.0 (the guard is still on main)
  • Nextcloud 34.0.4, apache flavor
  • Kubernetes 1.37.0, kube-prometheus-stack
Lingua principale
Go Template
Stelle
536
Fork
316
Merge medio
4g 16h
PR unite (30g)
2

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nextcloud/helm

Tutte le issue di nextcloud/helm

Issue simili

Altre issue su DevOps

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.