docs(skills): grafana skill without versions, dates or run ids

Only what stays true across updates: services, data paths, the data owner,
how to fix an ownership problem, how to check the result. Versions and the
update path are the workflow's job.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

config/skills/grafana.md

@@ -1,43 +1,25 @@
-# Grafana — VM103 (odczyt 2026-09-17)
+# Grafana i InfluxDB — VM103
 
-Usługi: `grafana` (obraz `grafana/grafana`, **bez tagu** — tylko digest w compose), `influxdb` (osobny cykl, nie ruszać przy update grafany).
-Domena `grafana.mariuszpacek.pl`, port 3000. Healthcheck: brak.
-Dane: `/var/lib/grafana` ← bind `/srv/appdata/grafana/data`; `/etc/grafana` ← bind `/srv/appdata/grafana/etc`; influxdb dane ← `/srv/appdata/grafana/influxdb`.
-Obecna wersja działająca: `13.1.3` (odczyt `docker exec grafana-grafana-1 grafana-server -v` — brak etykiety OCI wersji na obrazie, `image_version.sh` zwraca `no_version_label`).
+Projekt compose `grafana`, dwie usługi z osobnym cyklem aktualizacji: `grafana` i `influxdb`. Aktualizując jedną, nie ruszaj drugiej.
 
-## Źródła
-| README obrazu | https://github.com/grafana/grafana/blob/main/packaging/docker/README.md |
-| Wydania | https://github.com/grafana/grafana/releases |
-| Release notes | https://grafana.com/docs/grafana/latest/whatsnew/ |
-| Zgłoszenia | https://github.com/grafana/grafana/issues |
-| Przewodnik upgrade | https://grafana.com/docs/grafana/latest/upgrade-guide/ |
+## Grafana
+Obraz `grafana/grafana`, domena `grafana.mariuszpacek.pl`, port 3000, bez healthchecka.
+Dane: `/var/lib/grafana` ← `/srv/appdata/grafana/data`, `/etc/grafana` ← `/srv/appdata/grafana/etc`.
+Obraz nie ma etykiety OCI z wersją: wersję czyta się z tagu, a gdy compose ma sam digest, bez tagu — `grafana-server -v` w kontenerze. Nie zgaduj wersji.
+Źródła: [wydania](https://github.com/grafana/grafana/releases), [co nowego](https://grafana.com/docs/grafana/latest/whatsnew/), [przewodnik upgrade](https://grafana.com/docs/grafana/latest/upgrade-guide/), [obraz Docker](https://github.com/grafana/grafana/blob/main/packaging/docker/README.md).
+Odbiór: kontener działa na przypiętym obrazie; HTTPS na `/` daje 302 na `/login` (to nie błąd); dashboardy się ładują, a źródło danych InfluxDB odpowiada bez błędu.
 
-## Wersje
-Tagi: `image_tags.sh grafana/grafana --pattern '^[0-9.]+$' --current 13.1.3`. Auto: `patch`.
-Obraz bez tagu w compose → przed jakąkolwiek automatyczną akcją repin/update wymaga jawnego wpisania tagu (nie `latest`).
+## InfluxDB
+Obraz `influxdb`, port `192.168.0.139:18086`, domena `influxdb.mariuszpacek.pl`. Piszą do niej m.in. Telegraf, traefik, OPNsense i czujniki domowe; czyta Grafana.
+Dane: `/var/lib/influxdb` ← `/srv/appdata/grafana/influxdb` (kilkadziesiąt GB), właściciel `1000:1000`, tryb `700`. Usługa działa z `user: "1000:1000"` w compose — to musi zostać przy każdej aktualizacji.
+Źródła: [release notes](https://docs.influxdata.com/influxdb/v1/about_the_project/release-notes/), [upgrade](https://docs.influxdata.com/influxdb/v1/administration/upgrading/), [backup i restore](https://docs.influxdata.com/influxdb/v1/administration/backup_and_restore/).
 
-## Przed zmianą
-brak
+Kopia: codzienny vzdump VM103 obejmuje dysk z `/srv/appdata`; workflow sprawdza jego świeżość i kopiuje compose przed zmianą. Nie wymagaj dodatkowej kopii `influxd backup`.
 
-## Odbiór (limit 5 min)
-`verify.sh` running + image + HTTPS 302 (root przekierowuje na `/login`, curl bez `-L` — to nie błąd). Dashboardy się ładują, źródło danych InfluxDB odpowiada (panel z danymi, nie błąd datasource).
+Znany typ problemu: nowy obraz działa jako inny użytkownik niż właściciel danych albo część plików należy do roota. Objaw: pętla restartów z `permission denied` na `/var/lib/influxdb/...` albo błędy 500 przy zapisie do pojedynczych shardów.
+Naprawa: sprawdź właściciela (`hl run influxdb --user root -- stat -c %u:%g /var/lib/influxdb`), ustaw `user:` na tego właściciela, a pliki z innym właścicielem popraw punktowo (`hl run influxdb --user root -- find /var/lib/influxdb -not -user 1000 -exec chown 1000:1000 {} +`), potem `hl restart influxdb`. Nie rób `chown -R` całego drzewa i nie uruchamiaj usługi jako root. Zmiana `user` i `hl run` wymagają sesji z pełnym dostępem: w zwykłej sesji nie szukaj obejść, tylko od razu odpowiedz `gave_up` z tym opisem.
+Nie zmieniaj typu indeksu ani konfiguracji, jeśli nowa wersja tego nie wymaga.
 
-## STOP
-`no_version_label` przy `image_version.sh` — wersję potwierdź ręcznie (`grafana-server -v`) przed repinem, nie zgaduj z tagu.
-
-## Powrót
-`rollback.sh grafana --from <backup_dir> --service grafana`.
-
-## InfluxDB 1.x (stan VM103: 2026-09-23)
-Aktualnie `influxdb:1.12.4` z `user: "1000:1000"` w compose (2026-09-23: 1.8.10 → 1.11.8, run `d42540b6`; 1.11.8 → 1.12.4, run `ed69ed8b`). Dane: `/srv/appdata/grafana/influxdb` → `/var/lib/influxdb`, ~21 GB, właściciel `1000:1000` (mariuszp), tryb `700`. Wzorzec tagów pusty: kandydat to najnowszy tag kształtu `N.N.N` z następnej linii `major.minor`, jeden krok na run (następne: `1.13.1`, potem `2.0.x`). Tagi `-alpine`, `-rc` i `3.x-core` odpadają same. Port `192.168.0.139:18086`, pisze do niej Telegraf.
-Źródła: [release notes v1](https://docs.influxdata.com/influxdb/v1/about_the_project/release-notes/), [upgrade 1.11](https://docs.influxdata.com/influxdb/v1/administration/upgrading/), [backup/restore](https://docs.influxdata.com/influxdb/v1/administration/backup_and_restore/).
-
-Kopia: codzienny vzdump VM103 (02:00) obejmuje oba dyski, także ten z `/srv/appdata`; workflow sprawdza jego świeżość i kopiuje compose przed zmianą. Dodatkowa kopia `influxd backup -portable` nie jest wymagana — jej brak to nie powód do STOP.
-
-Znany problem (test 2026-09-23): obraz `1.11.x` działa jako użytkownik `influxdb` (uid 1500) i nie zmienia właściciela danych, więc wpada w pętlę restartów z `mkdir /var/lib/influxdb/meta: permission denied`, zanim dotknie danych.
-Naprawa (zrobiona): `user: "1000:1000"` w compose (właściciel katalogu danych), a pliki pozostawione przez 1.8.10 jako root dostały właściciela punktowo: `hl run influxdb --user root -- find /var/lib/influxdb -not -user 1000 -exec chown 1000:1000 {} +`, potem `hl restart influxdb`. Bez tego część shardów (`fields.idx.tmp`) zwraca 500 przy zapisie. Nie rób `chown -R` całego drzewa i nie uruchamiaj jako root. Przy kolejnych aktualizacjach 1.11.x zostaw `user:` bez zmian. Zmiana `user` przechodzi tylko w sesji z pełnym dostępem: w zwykłej sesji nie szukaj obejść, od razu odpowiedz `gave_up` z tym opisem, żeby właściciel włączył „Repair with full access”.
-Nie zmieniaj typu indeksu ani innej konfiguracji.
-
-Odbiór: kontener `running` na przypiętym obrazie, bez restartów; `/ping` → 204 z nagłówkiem `X-Influxdb-Version: 1.11.x`; `hl exec influxdb -- influx -execute 'SHOW DATABASES'` pokazuje m.in. `telegraf`; `hl exec influxdb -- influx -database telegraf -execute 'SHOW MEASUREMENTS LIMIT 5'` zwraca serie (stare dane są czytelne); w logach brak błędów TSM/WAL/shard. Nowe punkty od Telegrafa po restarcie potwierdzają zapis. Panele Grafany sprawdza właściciel.
-STOP: skok do `2.x` bez zatwierdzonego planu migracji (inny model danych i uwierzytelniania: `influxd upgrade`, buckety, tokeny, DBRP, źródło danych Grafany, wszyscy piszący); po starcie nowej wersji bazy lub serie znikają albo logi pokazują błędy odczytu shardów/TSM — wtedy nie naprawiaj na siłę, tylko opisz i zostaw decyzję o rollbacku właścicielowi.
-Powrót: rollback przywraca compose sprzed aktualizacji; do `1.8.10` (root) właściciel plików nie przeszkadza. Gdyby po rollbacku 1.8.10 nie czytał danych zapisanych przez 1.11, ratunkiem jest vzdump.
+Odbiór: kontener działa na przypiętym obrazie bez restartów; `/ping` → 204, a nagłówek `X-Influxdb-Version` pokazuje nową wersję; wszystkie bazy są widoczne i czytelne (`SHOW DATABASES`, `SHOW MEASUREMENTS`); w logach nie ma błędów shardów, TSM, WAL ani uprawnień; po restarcie przychodzą nowe punkty (np. do bazy `traefik`), co potwierdza zapis. Panele Grafany sprawdza właściciel.
+STOP: po starcie nowej wersji znikają bazy lub serie albo logi pokazują błędy odczytu danych — nie naprawiaj na siłę, opisz i zostaw decyzję o rollbacku właścicielowi.
+Powrót: rollback przywraca compose sprzed aktualizacji. Jeśli starsza wersja nie czyta danych zapisanych przez nowszą, ratunkiem jest vzdump.