Aby se to dalo nechat běžet pořád, ne jen spouštět večer na notebooku. Obojí počítá jen s domácí sítí — appka nemá přihlašování a ani jedno nasazení ji nijak nezabezpečuje.
Proxmox
Jeden příkaz na uzlu, jako root — tak, jak se to u community-scripts čeká:
Založí kontejner (Debian 13, neprivilegovaný, DHCP), počká na síť, stáhne vydanou binárku, ověří kontrolní součet a zapíše systemd službu. Aktualizace je ten samý příkaz s CTID=123 MODE=update.
Instalátor, který běží uvnitř kontejneru, je ve skriptu vložený jako text v heredocu. Jinak to nejde: přes rouru z curlu není na disku hostitele žádný soubor, který by šel poslat dovnitř. Duplicita tím nevzniká — vypsat se dá zpátky přes bash pve-kostky.sh instalator, když ho chce někdo pustit v kontejneru, který si založil sám.
Úložiště se nehádá.local-lvm na ZFS instalacích neexistuje a pct create by spadlo až po půlce práce. Teď se vybere první aktivní úložiště pro kontejnery, a když se nějaké vnutí přes STORAGE=, ověří se, že vůbec existuje.
Podoba je odkoukaná od community-scripts.org, ale nic z jejich frameworku se nestahuje. Jejich build.func si instalační skript hledá natvrdo ve vlastním repozitáři:
Ta adresa se nedá přebít, takže skript v cizím repozitáři by kontejner vytvořil a pak spadl.
Docker
cd deploy && docker compose up -d
Staví se ze zdrojáků, ne z binárky — image pak jde sestavit pro amd64 i arm64 a nezávisí na tom, jestli release pro danou architekturu proběhl. Zamčené závislosti z minulého PR dělají sestavení opakovatelné. Běží pod nerootovým uživatelem, databáze v pojmenovaném svazku.
Compose používá síť hostitele, a to je podstatné. V bridge režimu vidí kontejner uvnitř adresu 172.17.0.2, tabule ji poctivě nabídne a udělá na ni QR kód — jenže z telefonu je nedosažitelná.
Aplikace se měnit nemusela
DICE_DB, DICE_PORT a DICE_HOST pokrývají obojí. V LXC má kontejner vlastní adresu v LAN, takže hledání adres i QR kód fungují beze změny. Řádkové bufferování z minulého PR se sem trefilo: bez něj by v journalctl ani v docker logs po startu nebylo nic.
Ověřeno
Docker — skutečně postaveno a spuštěno:
appka běží jako uid=1000(kostky), databáze na svazku patří jí
bridge režim ověřen empiricky, ne odhadnut: bez DICE_HOST tabule nabídne 172.17.0.3, s DICE_HOST=192.168.1.10 správnou adresu
LXC instalátor — projet v debian:13 se zástupným systemctl:
zjištění posledního tagu z Gitea API, stažení a ověření součtu proti skutečnému releasu v1.1.0
založení uživatele, rozmístění souborů, zápis unit souboru, čekání na odpověď
projeto znovu po vložení do heredocu, s instalátorem vytaženým zpátky ven — chová se stejně
Roura z curlu: skript stažený ze skutečné adresy v Gitee projde bash -n a bash -c "$(curl …)" se chová správně, včetně vnořeného instalátoru.
Čím jsem si jistý míň: proti skutečnému Proxmoxu jsem to nespustil — nemám ho. Ověřená je syntaxe a logika, ne chování pct create, pveam a pvesm na živém uzlu. Systemd unit běžela jen pod atrapou.
Jedna věc k releasu
Dnes se nainstaluje v1.1.0, protože novější tag není. To vydání ještě nemá --version, /export, waitress ani verzované schéma. Na to jsem při zkoušce narazil doslova — instalátor původně končil voláním kostky --version, což na v1.1.0 místo výpisu nastartovalo server a skript zůstal viset. Verze se teď čte ze souboru, ne z binárky.
Aby se to dalo nechat běžet pořád, ne jen spouštět večer na notebooku. Obojí počítá **jen s domácí sítí** — appka nemá přihlašování a ani jedno nasazení ji nijak nezabezpečuje.
## Proxmox
Jeden příkaz na uzlu, jako root — tak, jak se to u community-scripts čeká:
```bash
bash -c "$(curl -fsSL https://gitea.spacilovi.eu/david-spacil/dice-counter/raw/branch/main/deploy/pve-kostky.sh)"
```
Založí kontejner (Debian 13, neprivilegovaný, DHCP), počká na síť, stáhne vydanou binárku, **ověří kontrolní součet** a zapíše systemd službu. Aktualizace je ten samý příkaz s `CTID=123 MODE=update`.
Instalátor, který běží uvnitř kontejneru, je ve skriptu vložený jako text v heredocu. Jinak to nejde: přes rouru z curlu není na disku hostitele žádný soubor, který by šel poslat dovnitř. Duplicita tím nevzniká — vypsat se dá zpátky přes `bash pve-kostky.sh instalator`, když ho chce někdo pustit v kontejneru, který si založil sám.
**Úložiště se nehádá.** `local-lvm` na ZFS instalacích neexistuje a `pct create` by spadlo až po půlce práce. Teď se vybere první aktivní úložiště pro kontejnery, a když se nějaké vnutí přes `STORAGE=`, ověří se, že vůbec existuje.
Podoba je odkoukaná od community-scripts.org, ale **nic z jejich frameworku se nestahuje**. Jejich `build.func` si instalační skript hledá natvrdo ve vlastním repozitáři:
```bash
_install_script="$(curl -fsSL \
"https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/install/${var_install}.sh")"
```
Ta adresa se nedá přebít, takže skript v cizím repozitáři by kontejner vytvořil a pak spadl.
## Docker
```bash
cd deploy && docker compose up -d
```
Staví se ze zdrojáků, ne z binárky — image pak jde sestavit pro amd64 i arm64 a nezávisí na tom, jestli release pro danou architekturu proběhl. Zamčené závislosti z minulého PR dělají sestavení opakovatelné. Běží pod nerootovým uživatelem, databáze v pojmenovaném svazku.
**Compose používá síť hostitele, a to je podstatné.** V bridge režimu vidí kontejner uvnitř adresu `172.17.0.2`, tabule ji poctivě nabídne a udělá na ni QR kód — jenže z telefonu je nedosažitelná.
## Aplikace se měnit nemusela
`DICE_DB`, `DICE_PORT` a `DICE_HOST` pokrývají obojí. V LXC má kontejner vlastní adresu v LAN, takže hledání adres i QR kód fungují beze změny. Řádkové bufferování z minulého PR se sem trefilo: bez něj by v `journalctl` ani v `docker logs` po startu nebylo nic.
---
## Ověřeno
**Docker — skutečně postaveno a spuštěno:**
- appka běží jako `uid=1000(kostky)`, databáze na svazku patří jí
- `/`, `/board`, `/static`, `/export` odpovídají, healthcheck hlásí `healthy`
- **bridge režim ověřen empiricky**, ne odhadnut: bez `DICE_HOST` tabule nabídne `172.17.0.3`, s `DICE_HOST=192.168.1.10` správnou adresu
**LXC instalátor — projet v `debian:13` se zástupným `systemctl`:**
- zjištění posledního tagu z Gitea API, stažení a ověření součtu proti skutečnému releasu v1.1.0
- založení uživatele, rozmístění souborů, zápis unit souboru, čekání na odpověď
- projeto znovu po vložení do heredocu, s instalátorem vytaženým zpátky ven — chová se stejně
**Roura z curlu:** skript stažený ze skutečné adresy v Gitee projde `bash -n` a `bash -c "$(curl …)"` se chová správně, včetně vnořeného instalátoru.
**Čím jsem si jistý míň:** proti skutečnému Proxmoxu jsem to nespustil — nemám ho. Ověřená je syntaxe a logika, ne chování `pct create`, `pveam` a `pvesm` na živém uzlu. Systemd unit běžela jen pod atrapou.
## Jedna věc k releasu
Dnes se nainstaluje **v1.1.0**, protože novější tag není. To vydání ještě nemá `--version`, `/export`, waitress ani verzované schéma. Na to jsem při zkoušce narazil doslova — instalátor původně končil voláním `kostky --version`, což na v1.1.0 místo výpisu nastartovalo server a skript zůstal viset. Verze se teď čte ze souboru, ne z binárky.
Aby se to dalo nechat běžet pořád, ne jen spouštět večer na notebooku.
pve-kostky.sh se pouští na uzlu Proxmoxu, založí kontejner a předá řízení
lxc-install.sh, který uvnitř stáhne vydanou binárku, ověří kontrolní součet
a zapíše službu. Ty dva jsou oddělené schválně: instalátor o Proxmoxu nic
neví, takže se dá pustit i v kontejneru, který sis založil sám. Podoba je
odkoukaná od community-scripts.org, ale nic z jejich frameworku se nestahuje
— jejich build.func si instalační skript hledá natvrdo ve vlastním
repozitáři, takže mimo něj nefunguje.
Docker se staví ze zdrojáků, ne z binárky: image pak jde sestavit pro obě
architektury a nezávisí na tom, jestli release proběhl. Zamčené závislosti
z minula dělají sestavení opakovatelné.
Compose používá síť hostitele, a to je podstatné. V bridge režimu vidí
kontejner uvnitř adresu 172.17.0.2, tabule ji poctivě nabídne a udělá na ni
QR kód — jenže z telefonu je nedosažitelná. Ověřeno, ne odhadnuto; kdo bridge
potřebuje, musí nastavit DICE_HOST.
Aplikace sama nepotřebovala změnit nic. DICE_DB, DICE_PORT a DICE_HOST
pokrývají obojí a v LXC má kontejner vlastní adresu v LAN, takže hledání
adres i QR kód fungují beze změny.
Instalace teď vypadá tak, jak se u community-scripts čeká:
bash -c "$(curl -fsSL .../deploy/pve-kostky.sh)"
Dva soubory to neuměly. Přes rouru z curlu není na disku hostitele žádný
soubor, který by šel poslat do kontejneru, takže se instalátor přesunul
dovnitř skriptu jako text v heredocu. Duplicita tím nevzniká — vypsat se dá
zpátky přes `bash pve-kostky.sh instalator`, když ho chce někdo pustit
v kontejneru, který si založil sám.
Argumenty se rourou předávají mizerně, tak jde všechno i proměnnou:
CTID=123 MODE=update. Ze staženého souboru funguje i pozičně.
Ke stejné příležitosti: úložiště se přestalo hádat. local-lvm na ZFS
instalacích neexistuje a pct create by spadlo až po půlce práce; teď se
vybere první aktivní, a když se nějaké vnutí, ověří se, že vůbec existuje.
pveam nabízí amd64 i arm64 vedle sebe a výběr přes `sort -V | tail -1` padl
na tu abecedně poslední — tedy arm64 i na x86 uzlu. Šablona, která na uzlu
už ležela, se pak nenašla a skript začal stahovat 120 MB nepoužitelného
archivu.
Architektura se teď bere z dpkg --print-architecture a nejdřív se kouká, co
na uzlu už je; stahuje se, až když tam nic nesedí. Neúspěšné stažení navíc
skript zastaví, místo aby se šlo zakládat kontejner ze šablony, která není.
Ke stejné příležitosti Ctrl+C: bez trapu zabil jen rozdělaný podproces
a skript pokračoval dál — v hlášení od uživatele je vidět, jak po přerušeném
stahování vesele oznámil hotovou šablonu a pustil se do pct create.
Debian 13 veze systemd 257 a ten v neprivilegovaném LXC bez nestingu
nedostane, co potřebuje — Proxmox na to při startu sám upozorňuje hláškou
"Systemd 257 detected. You may need to enable nesting."
Appka i tak nastartovala, ale spoléhat se na to nemá cenu. Stejnou výchozí
hodnotu mají i community-scripts a sami varují, že moderní distribuce se
systemd nesting potřebují.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Aby se to dalo nechat běžet pořád, ne jen spouštět večer na notebooku. Obojí počítá jen s domácí sítí — appka nemá přihlašování a ani jedno nasazení ji nijak nezabezpečuje.
Proxmox
Jeden příkaz na uzlu, jako root — tak, jak se to u community-scripts čeká:
Založí kontejner (Debian 13, neprivilegovaný, DHCP), počká na síť, stáhne vydanou binárku, ověří kontrolní součet a zapíše systemd službu. Aktualizace je ten samý příkaz s
CTID=123 MODE=update.Instalátor, který běží uvnitř kontejneru, je ve skriptu vložený jako text v heredocu. Jinak to nejde: přes rouru z curlu není na disku hostitele žádný soubor, který by šel poslat dovnitř. Duplicita tím nevzniká — vypsat se dá zpátky přes
bash pve-kostky.sh instalator, když ho chce někdo pustit v kontejneru, který si založil sám.Úložiště se nehádá.
local-lvmna ZFS instalacích neexistuje apct createby spadlo až po půlce práce. Teď se vybere první aktivní úložiště pro kontejnery, a když se nějaké vnutí přesSTORAGE=, ověří se, že vůbec existuje.Podoba je odkoukaná od community-scripts.org, ale nic z jejich frameworku se nestahuje. Jejich
build.funcsi instalační skript hledá natvrdo ve vlastním repozitáři:Ta adresa se nedá přebít, takže skript v cizím repozitáři by kontejner vytvořil a pak spadl.
Docker
Staví se ze zdrojáků, ne z binárky — image pak jde sestavit pro amd64 i arm64 a nezávisí na tom, jestli release pro danou architekturu proběhl. Zamčené závislosti z minulého PR dělají sestavení opakovatelné. Běží pod nerootovým uživatelem, databáze v pojmenovaném svazku.
Compose používá síť hostitele, a to je podstatné. V bridge režimu vidí kontejner uvnitř adresu
172.17.0.2, tabule ji poctivě nabídne a udělá na ni QR kód — jenže z telefonu je nedosažitelná.Aplikace se měnit nemusela
DICE_DB,DICE_PORTaDICE_HOSTpokrývají obojí. V LXC má kontejner vlastní adresu v LAN, takže hledání adres i QR kód fungují beze změny. Řádkové bufferování z minulého PR se sem trefilo: bez něj by vjournalctlani vdocker logspo startu nebylo nic.Ověřeno
Docker — skutečně postaveno a spuštěno:
uid=1000(kostky), databáze na svazku patří jí/,/board,/static,/exportodpovídají, healthcheck hlásíhealthyDICE_HOSTtabule nabídne172.17.0.3, sDICE_HOST=192.168.1.10správnou adresuLXC instalátor — projet v
debian:13se zástupnýmsystemctl:Roura z curlu: skript stažený ze skutečné adresy v Gitee projde
bash -nabash -c "$(curl …)"se chová správně, včetně vnořeného instalátoru.Čím jsem si jistý míň: proti skutečnému Proxmoxu jsem to nespustil — nemám ho. Ověřená je syntaxe a logika, ne chování
pct create,pveamapvesmna živém uzlu. Systemd unit běžela jen pod atrapou.Jedna věc k releasu
Dnes se nainstaluje v1.1.0, protože novější tag není. To vydání ještě nemá
--version,/export, waitress ani verzované schéma. Na to jsem při zkoušce narazil doslova — instalátor původně končil volánímkostky --version, což na v1.1.0 místo výpisu nastartovalo server a skript zůstal viset. Verze se teď čte ze souboru, ne z binárky.Instalace teď vypadá tak, jak se u community-scripts čeká: bash -c "$(curl -fsSL .../deploy/pve-kostky.sh)" Dva soubory to neuměly. Přes rouru z curlu není na disku hostitele žádný soubor, který by šel poslat do kontejneru, takže se instalátor přesunul dovnitř skriptu jako text v heredocu. Duplicita tím nevzniká — vypsat se dá zpátky přes `bash pve-kostky.sh instalator`, když ho chce někdo pustit v kontejneru, který si založil sám. Argumenty se rourou předávají mizerně, tak jde všechno i proměnnou: CTID=123 MODE=update. Ze staženého souboru funguje i pozičně. Ke stejné příležitosti: úložiště se přestalo hádat. local-lvm na ZFS instalacích neexistuje a pct create by spadlo až po půlce práce; teď se vybere první aktivní, a když se nějaké vnutí, ověří se, že vůbec existuje.