 | Nix Milan | 116 Members |
| https://milano.nix.pizza/ | 9 Servers |
| Nix Milan | 116 Members |
| https://milano.nix.pizza/ | 9 Servers |
| Sender | Message | Time |
|---|---|---|
| 16 Mar 2026 | ||
 Lollo | Però sadly non ha ancora abbastanza features per sostituire nextcloud per dire | 23:11:04 |
| 17 Mar 2026 | ||
 Nonno Felice | Sembra bello ma a me servirebbe anche un minimo di gestione utenti | 05:59:41 |
 Alessandro 🤔➖☀️🖌 | https://github.com/9001/copyparty#user-changeable-passwords Qualcosina sembra esserci | 06:11:33 |
| Nonno Felice | Ho letto meglio il README e sembra ci sia la gestione dei permessi su file e directory | 06:15:27 |
| Nonno Felice | Può essere un buon candidato | 06:15:58 |
 Edoardo Piccolotto | Ne ho sentito parlare bene, ma non l'ho mai provato. Me lo segno per una guida. | 06:32:59 |
 Andrea Ciceri | Opencloud altrimenti, c'é il modulo su NixOS https://opencloud.eu/ | 07:11:33 |
| Nonno Felice | Avevo visto questo ma mi ero perso la parte di self hosting | 07:13:52 |
| Andrea Ciceri | Io lo self-hosto ma ho avuto qualche problema a capire come configurarlo. Tra l'altro con lo uso con kanidm per gli utenti | 07:14:55 |
| Andrea Ciceri | Se vuoi ti mando la mia config | 07:15:05 |
| Nonno Felice | Che vita da kanidm | 07:15:19 |
| Nonno Felice | Kanidm è tipo Keycloak / Zitadel? | 07:15:48 |
| Andrea Ciceri | Sì, più minimale ma ti lascia dichiarare tutto da modulo; utenti, client, etc... | 07:28:49 |
 Francesco | Le password e i secret come vengono gestiti? | 07:48:54 |
| Andrea Ciceri | Per le password degli utenti se ricordo correttamente con un comando cli generavo un qrcode/url che poi davo all'utente per settare la sua password (e passkey o otp). Pero' gli utenti e i ruoli sono dichiarati nella config. La password dell'utente admin la ho dichiarata con agenix.Per i segreti dei client mi sa che facevo sempre imperativamente con la cli, e poi li mettevo in agenix per essere usati dai vari servizi. Pero' forse si possono generare separatamente e "provisionare" direttamente a kanidm | 10:48:26 |
| Andrea Ciceri | https://github.com/oddlama/kanidm-provision Comunque non e' kanidm a permetterti di fare tutto dichiarativamente, e' oddlama che ha scritto in tool apposta che poi viene usato nel modulo nixos | 10:49:50 |
| Andrea Ciceri | Tra l'altro mi sa che me lo consiglio qualcuno di questo gruppo, non ricordo chi pero' | 10:50:37 |
| 18 Mar 2026 | ||
| Edoardo Piccolotto |  Download Giusto per ridere... | 11:46:53 |
 gecko | Ah che bello, ora ho woodpecker-ci attacato a GitHub e che autoscala gli agenti su hetzner su macchine badass. Also atticd. Son un bimbo felice ora. | 21:38:08 |
| 19 Mar 2026 | ||
| Andrea Ciceri | sono curioso di sapere meglio come lo hai implementato, ho fatto molti esperimenti analoghi. | 11:21:56 |
| gecko | Ho messo woodpecker-server sul mio server insieme all'autoscaler configurato per tirare su istanze sul cloud di Hetzner on demand (default 0 agenti). Ho installato l'app GitHub così ho i pallini verdi sui commit. Sullo stesso server ho messo atticd usando come backing storage un bucket S3 di Hetzner e poi mi creo grossomodo una cache per progetto. Nella CI metto come segreto un token di GitHub (che uso per ghcr, il container registry di GitHub) e il token per poter pullare e pushare sulla cache atticd. Non ho un forge (Gitea, Gitlab o simili) perché mi va bene usare GitHub. Non ho un container registry perché i container devo usarli in giro per il mondo e la mia speranza è che ghcr abbia una CDN fatta benino. C'è qualcosa in particolare che ti interessa? | 15:15:01 |
| 20 Mar 2026 | ||
| Andrea Ciceri | I vari repo sono tutti flake, giusto? E la CI dei progetti e' semplicemente buildare tutti gli output? Ogni job (triggerato da push o eventi simili su GitHub suppongo) crea una istanza su hetnzer nel senso di un host cloud (una vps proprio) con su nix che esegue un comando per buildare i vari output quindi? Quindi 1 job = 1 comando che builda tutti gli output? Chiedo perche' in passato facevo una cosa simile usando nix-fast-build (tra l'altro supporta attic nativamente) che in output ti da un json con lo stato (build fallita o meno) per ogni output del flake, e poi partendo da quel json popolavo i vari checks di GitHub (le varie spunte verdi di fianco al commit, una per ogni output).Il problema e' nix-fast-build loggava tutto assieme e non si capiva niente quando qualcosa falliva, quindi poi ho deciso di creare un job per ogni output del flake ed eseguirli in parallelo sulla stessa macchina (stesso nix store e demone) cosi' da non avere il rischio che la stessa cosa venga buildata due volte (nix ti dice tipo "waiting for lock blah blah" e aspetta che la stessa derivazione venga buildata in un altro job), almeno cosi' ho i log separati per output. Anche questa soluzione non mi soddisfa appieno pero'.Comunque parlando di cache ho appena scoperto questa: https://github.com/Mic92/niks3 Altra cosa che ho fatto (altro ambito qui) e' stata decidere di usare un singolo server bare metal corazzato di hetzner invece, non scala come soluzione ma avere un unico store sull'ssd condiviso tra tutti i repo dell'organizzazione velocizzava parecchio le build. Se uno ha clienti diversi e non vuole "mischiare gli store" non va bene come soluzione poi. | 09:43:35 |
| gecko | Francamente io tendo a non usare le feature della CI. Faccio uno scriptone che posso eventualmente migrare ad altri sistemi di CI. Per ora listo alcuni package del flake che mi interessano e li buildo. Il mio goal in realtà è produrre e pushare immagini di container, per cui la cache mi serve più che altro come cosa privata della CI. Su Hetzner ti tira su una VM, sì. La VM runna una ubuntu che runna l'agente di woodpecker. Poi quello spawna un'immagine in un container che gli dico io ( nix:latest tipo).Per il check, se exit code è 1, viene verde. Non ho investigato robe più sofisticate. | 11:36:58 |
| gecko | * Francamente io tendo a non usare le feature della CI. Faccio uno scriptone che posso eventualmente migrare ad altri sistemi di CI. Per ora listo alcuni package del flake che mi interessano e li buildo. Il mio goal in realtà è produrre e pushare immagini di container, per cui la cache mi serve più che altro come cosa privata della CI. Su Hetzner ti tira su una VM, sì. La VM runna una ubuntu che runna l'agente di woodpecker. Poi quello spawna un'immagine in un container che gli dico io ( nix:latest tipo).Per il check, se exit code è 0, viene verde. Non ho investigato robe più sofisticate. | 13:27:45 |
| Andrea Ciceri | Ovviamente ognuno ha le sue esigenze e scende ai propri compromessi ma secondo me una cosa molta ganza di nix e' che la CI puo' essere super generalista e agnostica, nel senso di qualcosa che prende e builda ignorantemente gli output del flake (o attrset nel default.nix) producendo "checks CI" (nell'accezione alla GitHub) con i log per ogni output. Quindi a chi lavora sul repo non gliene frega niente di creare e lavorare su vari file yaml o script, semplicemente definisce derivazioni in output. Inoltre cosi' hai anche completamente riproducilita' di quello che avviene in CI localmente, che e' una cosa abbastanza rognosa di solito (a me capita di fare duemila commit "CI: please work" continuamente amendando)Poi a volte in CI uno vuole avere side effects, quindi questo modello si rompe. TIpo Hercules CI usa gli effects che sembrano derivazioni ma non sono sandboxate e hanno accesso a segreti configurati a livello di runner (buildbot-nix li supporta quindi potrebbe diventare una sorta di standard). Altrimenti uno potrebbe decidere di usare le impure derivations. | 15:44:23 |
| gecko | Ci penso, ma qui devo pushare dei container. Quella logica in qualche modo la devo encodare. Non voglio solo buildare derivazioni e cacharle, almeno in questo caso. | 16:51:16 |
 Marco Turchetto | Hydra fa una cosa carina, tagghi una derivation come da eseguire, e hydra la builda e poi la esegue. Chiaramente l'ambiente e i segreti disponibili sono affari tuoi. | 17:09:45 |
| Marco Turchetto | * Hydra fa una cosa carina, pero' la fa male. Tagghi una derivation come da eseguire, e hydra la builda e poi la esegue. Chiaramente l'ambiente e i segreti disponibili sono affari tuoi. | 17:10:01 |
| Marco Turchetto | Manca sempre un modo per descrivere i segreti e i permessi di esecuzione di queste derivation speciali, e li secondo me non e' compito di nix farlo. | 17:13:35 |
| 29 Feb 2024 | ||
 @admin:nixos.org changed the history visibility to "world_readable" from "shared". | 12:19:16 | |