| My website | https://cichy1173.eu |
| GitHub | https://github.com/cichy1173 |
| Polski blog | https://blog.cichy1173.eu |
| Codeberg | https://codeberg.org/cichy1173 |
| My website | https://cichy1173.eu |
| GitHub | https://github.com/cichy1173 |
| Polski blog | https://blog.cichy1173.eu |
| Codeberg | https://codeberg.org/cichy1173 |
Od jakiegoś czasu eksperymentuję z Fedora CoreOS. Jest to minimalny, dedykowany system atomowy pomyślany z myślą o utrzymywaniu kontenerów (Docker/Podman/Kubernetes). Na start oferuje właśnie zainstalowanego Podmana i Dockera. Tworzenie instancji polega na pisaniu dokumentów Butane (yaml), w których opisujemy deklaratywnie co chcemy, aby system miał na start -- podobnie to wygląda jak w Cloud Init. Następnie dokument jest przetwarzany do Ignition, czyli dokumentu JSON, który faktycznie wykorzystywaniu jest do provisionu. Ignition wpisujemy jako właśnie User Data.
https://mastodon.social/@cichy1173/116625329344164380
Ze względu na swoją niezmienną naturę Fedora CoreOS świetnie wpisuję się w moją filozofię podchodzenia do VM/instancji, gdzie nie dokonujemy ciągłej konfiguracji poprzez Ansible, a wszystko powinno zostać skonfigurowane na inicie, właśnie tutaj w formie Ignition (trochę takie podejście jak do Auto Scaling Group w AWS-ie). Tym samym fajnie Fedora CoreOS wpisuje mi się w użycie Terraforma, gdzie nawet mamy dedykowany provider do automatycznego przepisywania Butane na Ignition.
Właśnie fakt, że "silniki" konteneryzacji są na start dostępne w systemie, to od razu możemy zająć się opisaniem samych kontenerów. Ja korzystam chyba z najbardziej dedykowanego podejścia w CoreOS, czyli z quadletów Podmana. Kontenery są opisywane jako serwisy systemd. Też fajnym jest to, że można ustawić flagę auto-update, aby automatycznie aktualizować obraz. Przykład quadletu:
- path: /etc/containers/systemd/zabbix-proxy.container mode: 0644 contents: inline: | [Unit] Description=Zabbix Proxy After=network-online.target Wants=network-online.target [Container] Image=docker.io/zabbix/zabbix-proxy-sqlite3:alpine-7.0-latest PublishPort=10051:10051/tcp PodmanArgs=--memory=${proxy_memory_limit} Volume=/etc/zabbix/ssl:/etc/zabbix/ssl:ro,Z Volume=/var/lib/zabbix/db_data:/var/lib/zabbix/db_data:Z Environment=ZBX_HOSTNAME=${hostname} Environment=ZBX_SERVER_HOST=${zbx_server_host} Environment=ZBX_PROXYMODE=${zbx_proxy_mode} Environment=ZBX_PROXYOFFLINEBUFFER=${proxy_offline_buffer_hours} Environment=ZBX_TLSCAFILE=/etc/zabbix/ssl/ca.crt Environment=ZBX_TLSCERTFILE=/etc/zabbix/ssl/zabbix_proxy.crt Environment=ZBX_TLSKEYFILE=/etc/zabbix/ssl/zabbix_proxy.key Environment=ZBX_TLSCONNECT=cert AutoUpdate=registry [Service] Restart=always RestartSec=10s OOMPolicy=continue [Install] WantedBy=multi-user.target default.targetDo tego sam system aktualizuje się automatycznie. Fedora wydaje nowy "snapshot" systemu, który jest pobierany i po prostu podmieniany. Dlatego Core zawsze mamy zaktualizowany z minimalnym wpływem na działanie środowiska. Warto jednak odnotować, że aktualizacja wymaga rebootu. Z tego też powodu możemy sobie ustawić okno serwisowe.
- path: /etc/zincati/config.d/55-updates-strategy.toml mode: 0644 contents: inline: | [updates] strategy = "periodic" [[updates.periodic.window]] days = [ "${zincati_window_days}" ] start_time = "${zincati_window_start}" length_minutes = ${zincati_window_length}Aktualnie Fedora CoreOS wykorzystuję do VM-ek z Zabbix Proxy (działają w Zabbix Proxy Group) na Proxmox (choć z Proxmox będę migrował za jakiś czas). Fedora CoreOS fajnie mi się tutaj wpisała w moje podejście do tego typu hostów i całkiem spory stack z paroma maszynami wirtualnymi serwującymi Proxy znacznie mi się zmniejszył i uprościło mi się zarządzanie. Finalnie stack środowiska wygląda tak:
locals { fcos_zabbix_proxies = { "zabbix-proxy-fcos-1" = { ipv4_address = "192.168.1.192/24", zincati_window_days = "Fri" } "zabbix-proxy-fcos-2" = { ipv4_address = "192.168.1.120/24", zincati_window_days = "Sat" } "zabbix-proxy-fcos-3" = { ipv4_address = "192.168.1.210/24", zincati_window_days = "Sun" } }}module "fcos_zabbix_proxy" { for_each = local.fcos_zabbix_proxies source = "git::https://codeberg.org/cichy1173/cichyform.git//Proxmox/zabbix-proxy-fcos?ref=zabbix-proxy-fcos-v1.2.0" proxy_hostname = each.key zabbix_server_host = var.zabbix_ip ca_cert_pem = data.bitwarden_secret.ca-crt.value ca_key_pem = data.bitwarden_secret.ca-key.value username = "grzegorz" ssh_public_key = chomp(data.local_file.ssh_public_key.content) node_name = "shrek" ipv4_address = each.value.ipv4_address zincati_window_days = each.value.zincati_window_days cpu_cores = 1 memory_dedicated = 1024}Jakby ktoś chciał zobaczyć, to sam moduł Terraform jest publiczny >>tutaj<<. Nadal się uczę o CoreOS, więc na bieżąco dodaję nowości.
Ostatnio kupiłem sobie płyty z muzyką i je sobie zripowałem, aby móc wygodnie odtwarzać w aucie. Pomyślałem, że płyty CD/DVD nadal mogą ciekawym nośnikiem. Czy widzicie jakieś ich wykorzystanie/zastosowanie w homelabie?
RE: https://mastodon.social/@cichy1173/116685375423086884
Pobawiłem się jeszcze chwilę i okazuje się, że #zincati pozwala na ustalenie okna serwisowego, co chętnie zaaplikowałem do swojego modułu. No przyznam szczerze, jeszcze nigdy ustawienie okna patchingowego nie było dla mnie tak proste :-). Ustawiłem sobie okno w weekend, ale każde #zabbixproxy ma patching innego dnia.
#fedoracoreos #fedoracore #fcos #coreos
RE: https://mastodon.social/@cichy1173/116625329344164380
Pierwszy update kontenerów i samego systemu za mną #FCOS
Update systemowy odbył się automatycznie, bez żadnych problemów, jedynie dostałem alarm z Zabbixa, że host został zrestartowany.
Dzisiaj miałem update #zabbix proxy do 7.0.27. Rano się obudziłem i już klaster pracował na nowej wersji obrazu. Bez żadnych dodatkowych tooli.
```
Jun 03 00:02:16 zabbix-proxy-fcos-3 podman[24617]: 2026-06-03 00:02:16.331519234 +0000 UTC m=+0.022892655 image pull 9a499fc
```
#fedoracoreos #coreos
So my systems recently updated to rsync 3.4.3, and as soon as that happened my backup system - which does incremental backups using multiple --compare-dest= arguments - started to fail on anything but a full backup.
Revert to 3.4.1 and it works.
So I go look at the source in GitHub to see what might have changed, because there doesn't seem to be anything relevant in the changelog.
Since 3.4.1, 36 commits by "tridge and claude"
Oh for fuck's sakes.
It's actually interesting that as many as 2/3 of people opened #GNOMEDisks and initially formatted the flash drive correctly, but didn't realize they still needed to create a new partition in the chosen format (fat32). I guess Windows habits won out over the GNOME Disks interface here (or the Disks interface is not just user-friendly enough).