GazziNet - Contributi dell'utente [it]

CamperLink

2026-04-06T22:29:44Z

Admin: Creata pagina con "Esempi: https://www.campermjb.com/ducato-l3h3-surf/"

Esempi:

https://www.campermjb.com/ducato-l3h3-surf/

Pagina principale

2026-04-06T22:29:13Z

Admin:

__NOTOC__
<div class="gazzi-wiki-home">
<div class="gazzi-wiki-hero">
<h2>GazziNet Wiki</h2>
<p>Base tecnica interna con appunti operativi, procedure e raccolte tematiche.</p>
</div>

<div class="gazzi-wiki-grid">
<div class="gazzi-wiki-card">
<h3>Sistemi</h3>
<ul>
<li>[[Tips Linux]]</li>
<li>[[Tips Windows]]</li>
<li>[[Tips Database]]</li>
<li>[[Tips Application Server]]</li>
<li>[[Tips Virtualizzatori]]</li>
<li>[[Tips Automation]]</li>
<li>[[Tips Varie]]</li>
</ul>
</div>

<div class="gazzi-wiki-card">
<h3>Rete e sicurezza</h3>
<ul>
<li>[[Sicurezza & Forense]]</li>
<li>[[Operatore]]</li>
</ul>
</div>

<div class="gazzi-wiki-card">
<h3>Dev e piattaforme</h3>
<ul>
<li>[[Container|Container]]</li>
<li>[[Sviluppo]]</li>
<li>[[OBS]]</li>
<li>[[HW]]</li>
<li>[[Codex per struttura wiki e pubblicazione articoli]]</li>
<li>[[Progetti/CartClin]]</li>
</ul>
</div>

<div class="gazzi-wiki-card">
<h3>Supporto</h3>
<ul>
<li>[[Corso]]</li>
</ul>
</div>

<div class="gazzi-wiki-card">
<h3>Progetto Camper</h3>
<ul>
<li>[[CamperLink]]</li>
</ul>
</div>

</div>
</div>

Tips Virtualizzatori

2026-03-29T20:27:02Z

Admin: Fix markup minore nella sezione Proxmox VE

__NOTOC__
Breve raccolta di riferimenti sulla virtualizzazione usati nel contesto GazziNet. La pagina serve come indice rapido per verifiche host, risorse e accesso alle piattaforme dedicate.

== Verifiche rapide ==

=== Risorse host ===
<pre>
uptime
lscpu
free -h
df -h
</pre>

=== Rete e bridge ===
<pre>
ip a
ip r
bridge link
ss -tulpn
</pre>

=== Storage e volumi ===
<pre>
lsblk
pvs
vgs
lvs
</pre>

== Troubleshooting operativo ==
* Verificare sempre se il problema e sull'host, sulla VM o sullo storage sottostante.
* Prima di agire, annotare uso CPU, RAM, spazio, stato rete e saturazione I/O.
* Controllare eventuali snapshot, lock, backup in corso o contenitori storage pieni.

== Piattaforme ==
* [[PROXMOX]]

== Proxmox VE ==

'''Proxmox VE''' e una piattaforma di virtualizzazione basata su Debian che integra:
* '''KVM''' per macchine virtuali complete
* '''LXC''' per container Linux
* gestione storage locale e condiviso
* clustering, migrazione, backup e replica
* interfaccia web e CLI native

=== Quando usarlo ===
Ha senso usare Proxmox VE quando:
* vuoi centralizzare gestione di VM e container
* ti servono snapshot, backup e restore in modo semplice
* vuoi crescere da host singolo a cluster
* vuoi usare storage locali o condivisi con un'interfaccia unificata

=== Requisiti minimi e logica di sizing ===
Per valutazione o lab:
* CPU 64 bit con supporto Intel VT/AMD-V
* almeno 16 GiB di spazio disco per l'host, oltre allo spazio per guest
* almeno una NIC

Per produzione:
* privilegiare hardware server stabile
* prevedere RAM in base ai guest, non solo all'host
* separare se possibile traffico management, storage e migration
* valutare ECC RAM soprattutto se si usa ZFS

== Installazione ==

=== Metodo consigliato: ISO ufficiale ===
L'installazione da ISO e il metodo raccomandato da Proxmox per utenti nuovi ed esistenti.

Flusso tipico:
# scaricare la ISO ufficiale
# preparare la chiavetta di installazione
# avviare il server dalla ISO
# scegliere il disco o i dischi di destinazione
# impostare filesystem/root storage
# configurare hostname, password root, email e rete
# completare installazione e riavviare

Durante il setup l'installer:
* partiziona i dischi locali
* applica configurazioni base come lingua, timezone e rete
* installa Debian e i pacchetti Proxmox VE necessari

=== Metodo alternativo: installazione su Debian ===
Proxmox VE puo anche essere installato sopra un sistema Debian esistente, ma questa via e consigliata solo a utenti avanzati.

Ha senso usarla quando:
* hai gia un'immagine Debian standard gestita da automazione
* vuoi maggiore controllo iniziale sul partizionamento
* vuoi integrare l'host in procedure di bootstrap gia esistenti

Rischi tipici:
* repository sbagliati o incompleti
* pacchetti non allineati
* rete e storage meno prevedibili rispetto all'installer dedicato

=== Installazione automatizzata ===
Proxmox documenta anche l'''Automated Installation''' per deployment unattended.

Serve quando:
* devi installare piu host bare metal in modo coerente
* vuoi preparare una ISO con answer file
* vuoi demandare il post-config a strumenti come Ansible o simili

=== Prime attivita dopo l'installazione ===
Checklist pratica iniziale:
* verificare data/ora e DNS
* applicare aggiornamenti
* controllare bridge di rete
* controllare storage locale configurato dall'installer
* definire repository corretti in base a subscription o no-subscription
* configurare backup prima di creare guest critici
* registrare hostname, IP management, storage e note operative

Comandi rapidi:
<syntaxhighlight lang="bash">
pveversion -v
ip a
bridge link
pvesm status
lsblk
</syntaxhighlight>

== Filesystem e storage: come scegliere ==

La scelta corretta dipende da:
* host singolo o cluster
* storage locale o condiviso
* bisogno di snapshot/cloni
* budget RAM
* necessita di integrita dati e replica
* carico prevalente: VM, container, ISO, template, backup

=== 1. Setup predefinito LVM + LVM-thin ===
L'installer attuale usa come default '''LVM''' sul disco locale.

Schema tipico:
* volume group <code>pve</code>
* logical volume <code>root</code> formattato '''ext4''' per il sistema operativo
* logical volume <code>swap</code>
* logical volume <code>data</code> come '''LVM-thin''' per dischi VM

Vantaggi:
* semplice
* buon default per host singolo
* snapshot e clone efficienti sul thin pool
* basso overhead RAM rispetto a ZFS

Limiti:
* non condiviso tra nodi
* meno funzioni di integrita rispetto a ZFS
* meno flessibile per storage file-level generici rispetto a una directory dedicata

Consigli pratici:
* buona scelta per host piccoli o medi con storage locale
* adatto quando vuoi partire in fretta senza complessita extra
* tenere backup e ISO possibilmente separati dal thin pool se il disco e piccolo

=== 2. Directory storage su ext4 o XFS ===
Lo storage di tipo '''Directory''' usa una directory POSIX su filesystem Linux standard.

Puoi usarlo per:
* immagini VM
* container
* template
* ISO
* backup

Proxmox segnala che:
* una directory puo essere locale oppure un mount standard Linux
* il backend assume compatibilita POSIX
* non offre snapshot a livello storage
* con immagini <code>qcow2</code> esiste il workaround degli snapshot interni al formato

Quando scegliere '''ext4''':
* vuoi il filesystem piu semplice e prevedibile
* l'uso principale e backup, ISO, template o immagini non troppo complesse
* vuoi massima familiarita operativa

Quando scegliere '''XFS''':
* vuoi un filesystem robusto per grandi volumi file-based
* prevedi repository backup o directory storage di grandi dimensioni
* preferisci una soluzione nota per throughput e gestione file grandi

Limite importante:
* se il tuo obiettivo principale sono snapshot e cloni storage-level delle VM, una directory pura non e la scelta migliore

Regola pratica:
* '''ext4/XFS + dir''' vanno molto bene per ISO, template e backup
* per i dischi VM principali, usare spesso '''LVM-thin''' o '''ZFS''' e piu coerente

=== 3. ZFS ===
ZFS combina filesystem e volume manager.

Proxmox ne evidenzia vantaggi importanti:
* protezione da corruzione dati
* compressione
* snapshot
* cloni copy-on-write
* vari livelli RAID
* self-healing
* integrity checking continua
* replica asincrona
* gestione integrata da GUI e CLI

Quando scegliere ZFS:
* vuoi integrita dati e checksum end-to-end
* vuoi snapshot e replica native
* hai abbastanza RAM
* puoi dare a ZFS accesso diretto ai dischi

Attenzioni fondamentali:
* Proxmox raccomanda almeno '''8 GB''' di RAM per iniziare
* e raccomandata '''ECC RAM''' quando possibile
* non usare ZFS sopra controller RAID hardware con cache propria
* meglio HBA o controller in modalita IT

Nota pratica importante:
* nelle installazioni nuove da Proxmox VE 8.1 il limite ARC viene impostato al '''10%''' della RAM fisica, con massimo '''16 GiB''', scritto in <code>/etc/modprobe.d/zfs.conf</code>

Scelte RAID ZFS in installazione:
* '''RAID0''': massima capacita, nessuna ridondanza
* '''RAID1''': mirror, adatto a 2 dischi
* '''RAID10''': buone prestazioni e ridondanza, richiede almeno 4 dischi
* '''RAIDZ-1''': parita singola
* '''RAIDZ-2''': parita doppia
* '''RAIDZ-3''': parita tripla

Consiglio operativo:
* per host piccoli con 2 dischi, il mirror ZFS e spesso la scelta piu pulita
* per host con tanti dischi, RAID10 o RAIDZ-2 sono in genere piu prudenziali di RAIDZ-1
* evitare ZFS se la RAM e molto limitata o se l'hardware e gia vincolato a RAID hardware non bypassabile

=== 4. BTRFS ===
BTRFS esiste nel mondo Linux come filesystem moderno con snapshot e checksum, ma in Proxmox la documentazione e la pratica operativa ruotano molto di piu attorno a '''LVM-thin''' e '''ZFS'''.

Consiglio pragmatico:
* se ti serve una scelta stabile e ben coperta dalla documentazione Proxmox, privilegia '''LVM-thin''' o '''ZFS'''
* usa BTRFS solo se hai gia competenza specifica e una ragione forte per adottarlo

== Raccomandazioni rapide ==

=== Host singolo piccolo o homelab semplice ===
Scelta consigliata:
* installer ISO
* default '''LVM + ext4 root + LVM-thin'''
* directory separata per ISO e backup se possibile

=== Host singolo con priorita a integrita e snapshot ===
Scelta consigliata:
* installer ISO con '''ZFS mirror''' se hai 2 dischi
* ECC RAM se possibile
* niente RAID hardware davanti a ZFS

=== Nodo dedicato soprattutto a backup ===
Scelta consigliata:
* directory storage su '''ext4''' o '''XFS'''
* evitare di mescolare senza controllo backup pesanti e dischi VM critici sullo stesso spazio piccolo

=== Cluster o crescita futura ===
Considerare fin da subito:
* separazione rete management/storage
* strategia storage condiviso o replica
* naming coerente di nodi, bridge e datastore
* policy di backup e restore testato

== Errori comuni ==
* usare ZFS sopra RAID hardware opaco
* sottostimare la RAM necessaria a host e guest
* riempire lo storage locale con backup, ISO e template fino a saturazione
* scegliere directory storage pensando di avere snapshot storage-level nativi
* non documentare bridge, VLAN, datastore e layout dischi
* creare VM critiche prima di aver validato backup e ripristino

== Verifiche utili su host Proxmox ==

=== Versione e stato generale ===
<syntaxhighlight lang="bash">
pveversion -v
uptime
</syntaxhighlight>

=== Rete ===
<syntaxhighlight lang="bash">
ip a
ip r
bridge link
</syntaxhighlight>

=== Storage LVM ===
<syntaxhighlight lang="bash">
lsblk
pvs
vgs
lvs
</syntaxhighlight>

=== Storage Proxmox ===
<syntaxhighlight lang="bash">
pvesm status
cat /etc/pve/storage.cfg
</syntaxhighlight>

=== ZFS ===
<syntaxhighlight lang="bash">
zpool status
zfs list
</syntaxhighlight>

== Fonti ufficiali ==
* [https://pve.proxmox.com/pve-docs-8/chapter-pve-installation.html Installing Proxmox VE]
* [https://pve.proxmox.com/wiki/Quick_installation Quick installation]
* [https://pve.proxmox.com/wiki/Automated_Installation Automated Installation]
* [https://pve.proxmox.com/wiki/Logical_Volume_Manager_%28LVM%29 Logical Volume Manager (LVM)]
* [https://pve.proxmox.com/wiki/Storage Storage]
* [https://pve.proxmox.com/wiki/Storage%3A_Directory Storage: Directory]
* [https://pve.proxmox.com/wiki/ZFS_on_Linux ZFS on Linux]
* [https://pve.proxmox.com/wiki/Installation%3A_Tips_and_Tricks Installation: Tips and Tricks]

== Note d'uso ==
* Separare sempre i problemi di orchestrazione da quelli di singola VM.
* Non saturare lo storage locale con immagini, backup e template senza controllo dello spazio.
* Documentare hostname host, datastore coinvolto e VM interessata prima di aprire ticket o incidente.

Tips Virtualizzatori

2026-03-29T20:24:45Z

Admin: Espansione sezione Proxmox VE con installazione e consigli filesystem

__NOTOC__
Breve raccolta di riferimenti sulla virtualizzazione usati nel contesto GazziNet. La pagina serve come indice rapido per verifiche host, risorse e accesso alle piattaforme dedicate.

== Verifiche rapide ==

=== Risorse host ===
<pre>
uptime
lscpu
free -h
df -h
</pre>

=== Rete e bridge ===
<pre>
ip a
ip r
bridge link
ss -tulpn
</pre>

=== Storage e volumi ===
<pre>
lsblk
pvs
vgs
lvs
</pre>

== Troubleshooting operativo ==
* Verificare sempre se il problema e sull'host, sulla VM o sullo storage sottostante.
* Prima di agire, annotare uso CPU, RAM, spazio, stato rete e saturazione I/O.
* Controllare eventuali snapshot, lock, backup in corso o contenitori storage pieni.

== Piattaforme ==
* [[PROXMOX]]

== Proxmox VE ==

'''Proxmox VE''' e una piattaforma di virtualizzazione basata su Debian che integra:
* '''KVM''' per macchine virtuali complete
* '''LXC''' per container Linux
* gestione storage locale e condiviso
* clustering, migrazione, backup e replica
* interfaccia web e CLI native

=== Quando usarlo ===
Ha senso usare Proxmox VE quando:
* vuoi centralizzare gestione di VM e container
* ti servono snapshot, backup e restore in modo semplice
* vuoi crescere da host singolo a cluster
* vuoi usare storage locali o condivisi con un'interfaccia unificata

=== Requisiti minimi e logica di sizing ===
Per valutazione o lab:
* CPU 64 bit con supporto Intel VT/AMD-V
* almeno 16 GiB di spazio disco per l'host, oltre allo spazio per guest
* almeno una NIC

Per produzione:
* privilegiare hardware server stabile
* prevedere RAM in base ai guest, non solo all'host
* separare se possibile traffico management, storage e migration
* valutare ECC RAM soprattutto se si usa ZFS

== Installazione ==

=== Metodo consigliato: ISO ufficiale ===
L'installazione da ISO e il metodo raccomandato da Proxmox per utenti nuovi ed esistenti.

Flusso tipico:
# scaricare la ISO ufficiale
# preparare la chiavetta di installazione
# avviare il server dalla ISO
# scegliere il disco o i dischi di destinazione
# impostare filesystem/root storage
# configurare hostname, password root, email e rete
# completare installazione e riavviare

Durante il setup l'installer:
* partiziona i dischi locali
* applica configurazioni base come lingua, timezone e rete
* installa Debian e i pacchetti Proxmox VE necessari

=== Metodo alternativo: installazione su Debian ===
Proxmox VE puo anche essere installato sopra un sistema Debian esistente, ma questa via e consigliata solo a utenti avanzati.

Ha senso usarla quando:
* hai gia un'immagine Debian standard gestita da automazione
* vuoi maggiore controllo iniziale sul partizionamento
* vuoi integrare l'host in procedure di bootstrap gia esistenti

Rischi tipici:
* repository sbagliati o incompleti
* pacchetti non allineati
* rete e storage meno prevedibili rispetto all'installer dedicato

=== Installazione automatizzata ===
Proxmox documenta anche l''''Automated Installation''' per deployment unattended.

Serve quando:
* devi installare piu host bare metal in modo coerente
* vuoi preparare una ISO con answer file
* vuoi demandare il post-config a strumenti come Ansible o simili

=== Prime attivita dopo l'installazione ===
Checklist pratica iniziale:
* verificare data/ora e DNS
* applicare aggiornamenti
* controllare bridge di rete
* controllare storage locale configurato dall'installer
* definire repository corretti in base a subscription o no-subscription
* configurare backup prima di creare guest critici
* registrare hostname, IP management, storage e note operative

Comandi rapidi:
<syntaxhighlight lang="bash">
pveversion -v
ip a
bridge link
pvesm status
lsblk
</syntaxhighlight>

== Filesystem e storage: come scegliere ==

La scelta corretta dipende da:
* host singolo o cluster
* storage locale o condiviso
* bisogno di snapshot/cloni
* budget RAM
* necessita di integrita dati e replica
* carico prevalente: VM, container, ISO, template, backup

=== 1. Setup predefinito LVM + LVM-thin ===
L'installer attuale usa come default '''LVM''' sul disco locale.

Schema tipico:
* volume group <code>pve</code>
* logical volume <code>root</code> formattato '''ext4''' per il sistema operativo
* logical volume <code>swap</code>
* logical volume <code>data</code> come '''LVM-thin''' per dischi VM

Vantaggi:
* semplice
* buon default per host singolo
* snapshot e clone efficienti sul thin pool
* basso overhead RAM rispetto a ZFS

Limiti:
* non condiviso tra nodi
* meno funzioni di integrita rispetto a ZFS
* meno flessibile per storage file-level generici rispetto a una directory dedicata

Consigli pratici:
* buona scelta per host piccoli o medi con storage locale
* adatto quando vuoi partire in fretta senza complessita extra
* tenere backup e ISO possibilmente separati dal thin pool se il disco e piccolo

=== 2. Directory storage su ext4 o XFS ===
Lo storage di tipo '''Directory''' usa una directory POSIX su filesystem Linux standard.

Puoi usarlo per:
* immagini VM
* container
* template
* ISO
* backup

Proxmox segnala che:
* una directory puo essere locale oppure un mount standard Linux
* il backend assume compatibilita POSIX
* non offre snapshot a livello storage
* con immagini <code>qcow2</code> esiste il workaround degli snapshot interni al formato

Quando scegliere '''ext4''':
* vuoi il filesystem piu semplice e prevedibile
* l'uso principale e backup, ISO, template o immagini non troppo complesse
* vuoi massima familiarita operativa

Quando scegliere '''XFS''':
* vuoi un filesystem robusto per grandi volumi file-based
* prevedi repository backup o directory storage di grandi dimensioni
* preferisci una soluzione nota per throughput e gestione file grandi

Limite importante:
* se il tuo obiettivo principale sono snapshot e cloni storage-level delle VM, una directory pura non e la scelta migliore

Regola pratica:
* '''ext4/XFS + dir''' vanno molto bene per ISO, template e backup
* per i dischi VM principali, usare spesso '''LVM-thin''' o '''ZFS''' e piu coerente

=== 3. ZFS ===
ZFS combina filesystem e volume manager.

Proxmox ne evidenzia vantaggi importanti:
* protezione da corruzione dati
* compressione
* snapshot
* cloni copy-on-write
* vari livelli RAID
* self-healing
* integrity checking continua
* replica asincrona
* gestione integrata da GUI e CLI

Quando scegliere ZFS:
* vuoi integrita dati e checksum end-to-end
* vuoi snapshot e replica native
* hai abbastanza RAM
* puoi dare a ZFS accesso diretto ai dischi

Attenzioni fondamentali:
* Proxmox raccomanda almeno '''8 GB''' di RAM per iniziare
* e raccomandata '''ECC RAM''' quando possibile
* non usare ZFS sopra controller RAID hardware con cache propria
* meglio HBA o controller in modalita IT

Nota pratica importante:
* nelle installazioni nuove da Proxmox VE 8.1 il limite ARC viene impostato al '''10%''' della RAM fisica, con massimo '''16 GiB''', scritto in <code>/etc/modprobe.d/zfs.conf</code>

Scelte RAID ZFS in installazione:
* '''RAID0''': massima capacita, nessuna ridondanza
* '''RAID1''': mirror, adatto a 2 dischi
* '''RAID10''': buone prestazioni e ridondanza, richiede almeno 4 dischi
* '''RAIDZ-1''': parita singola
* '''RAIDZ-2''': parita doppia
* '''RAIDZ-3''': parita tripla

Consiglio operativo:
* per host piccoli con 2 dischi, il mirror ZFS e spesso la scelta piu pulita
* per host con tanti dischi, RAID10 o RAIDZ-2 sono in genere piu prudenziali di RAIDZ-1
* evitare ZFS se la RAM e molto limitata o se l'hardware e gia vincolato a RAID hardware non bypassabile

=== 4. BTRFS ===
BTRFS esiste nel mondo Linux come filesystem moderno con snapshot e checksum, ma in Proxmox la documentazione e la pratica operativa ruotano molto di piu attorno a '''LVM-thin''' e '''ZFS'''.

Consiglio pragmatico:
* se ti serve una scelta stabile e ben coperta dalla documentazione Proxmox, privilegia '''LVM-thin''' o '''ZFS'''
* usa BTRFS solo se hai gia competenza specifica e una ragione forte per adottarlo

== Raccomandazioni rapide ==

=== Host singolo piccolo o homelab semplice ===
Scelta consigliata:
* installer ISO
* default '''LVM + ext4 root + LVM-thin'''
* directory separata per ISO e backup se possibile

=== Host singolo con priorita a integrita e snapshot ===
Scelta consigliata:
* installer ISO con '''ZFS mirror''' se hai 2 dischi
* ECC RAM se possibile
* niente RAID hardware davanti a ZFS

=== Nodo dedicato soprattutto a backup ===
Scelta consigliata:
* directory storage su '''ext4''' o '''XFS'''
* evitare di mescolare senza controllo backup pesanti e dischi VM critici sullo stesso spazio piccolo

=== Cluster o crescita futura ===
Considerare fin da subito:
* separazione rete management/storage
* strategia storage condiviso o replica
* naming coerente di nodi, bridge e datastore
* policy di backup e restore testato

== Errori comuni ==
* usare ZFS sopra RAID hardware opaco
* sottostimare la RAM necessaria a host e guest
* riempire lo storage locale con backup, ISO e template fino a saturazione
* scegliere directory storage pensando di avere snapshot storage-level nativi
* non documentare bridge, VLAN, datastore e layout dischi
* creare VM critiche prima di aver validato backup e ripristino

== Verifiche utili su host Proxmox ==

=== Versione e stato generale ===
<syntaxhighlight lang="bash">
pveversion -v
uptime
</syntaxhighlight>

=== Rete ===
<syntaxhighlight lang="bash">
ip a
ip r
bridge link
</syntaxhighlight>

=== Storage LVM ===
<syntaxhighlight lang="bash">
lsblk
pvs
vgs
lvs
</syntaxhighlight>

=== Storage Proxmox ===
<syntaxhighlight lang="bash">
pvesm status
cat /etc/pve/storage.cfg
</syntaxhighlight>

=== ZFS ===
<syntaxhighlight lang="bash">
zpool status
zfs list
</syntaxhighlight>

== Fonti ufficiali ==
* [https://pve.proxmox.com/pve-docs-8/chapter-pve-installation.html Installing Proxmox VE]
* [https://pve.proxmox.com/wiki/Quick_installation Quick installation]
* [https://pve.proxmox.com/wiki/Automated_Installation Automated Installation]
* [https://pve.proxmox.com/wiki/Logical_Volume_Manager_%28LVM%29 Logical Volume Manager (LVM)]
* [https://pve.proxmox.com/wiki/Storage Storage]
* [https://pve.proxmox.com/wiki/Storage%3A_Directory Storage: Directory]
* [https://pve.proxmox.com/wiki/ZFS_on_Linux ZFS on Linux]
* [https://pve.proxmox.com/wiki/Installation%3A_Tips_and_Tricks Installation: Tips and Tricks]

== Note d'uso ==
* Separare sempre i problemi di orchestrazione da quelli di singola VM.
* Non saturare lo storage locale con immagini, backup e template senza controllo dello spazio.
* Documentare hostname host, datastore coinvolto e VM interessata prima di aprire ticket o incidente.

Tips Automation

2026-03-28T23:08:31Z

Admin: Aggiunta sezione Pyinfra con link alle pagine correlate

__NOTOC__
= Tips Automation =

Breve raccolta di riferimenti operativi su automazione, scripting e workflow ripetibili usati nel contesto GazziNet.

== Obiettivi tipici ==
* ridurre task manuali ripetitivi
* standardizzare controlli e verifiche
* velocizzare raccolta dati, report e aggiornamenti
* diminuire errori operativi su procedure frequenti

== Approcci comuni ==

=== Shell e script rapidi ===
Adatti a task semplici, verifiche host, raccolta log, sincronizzazioni e controlli periodici.

<pre>
bash script.sh
crontab -e
journalctl -u nome-servizio
</pre>

=== Python ===
Utile quando serve lavorare con API, parsing strutturato, generazione di contenuti, file JSON, flussi condizionali o automazioni piu ricche.

<pre>
python3 script.py
python3 -m venv .venv
pip install -r requirements.txt
</pre>

=== Automazione schedulata ===
Per job periodici usare `cron`, systemd timer o servizi dedicati, evitando task manuali ricorrenti.

<pre>
crontab -l
systemctl list-timers
</pre>

=== Pyinfra ===
Pyinfra e una alternativa open source ad Ansible basata su Python, utile per inventory, deploy e configurazioni ripetibili.

* [[Pyinfra]]
* [[Confronto Ansible vs Pyinfra]]
* [[Esempi Pyinfra]]
* [[Installazione Pyinfra su Fedora]]

== Casi d'uso pratici ==
* controlli periodici su siti, servizi o endpoint
* generazione e pubblicazione di contenuti
* raccolta inventario hardware o software
* aggiornamento di pagine wiki o sistemi documentali
* export dati da API e report automatici

== Sistemi automatici ==
* [[Tips Automation/Apache Airflow]]

== Buone pratiche ==
* separare credenziali, codice e log
* usare file `.env` o meccanismi equivalenti per configurazione e segreti
* tenere traccia di input, output e stato del job
* preferire automazioni idempotenti, o comunque sicure da rilanciare
* aggiungere sempre una verifica finale del risultato

== Riferimenti collegati ==
* [[CheckScript]]
* [[Parallelizzazione comandi]]
* [[Sviluppo]]
* [[Codex per struttura wiki e pubblicazione articoli]]

== Nota finale ==
L'automazione utile non e quella piu complessa, ma quella che riduce lavoro ripetitivo, mantiene il controllo umano e lascia un risultato verificabile.

Installazione Pyinfra su Fedora

2026-03-28T23:06:21Z

Admin: Creazione pagina informativa su pyinfra

= Installazione Pyinfra su Fedora =

Guida pratica per installare '''pyinfra''' su Fedora in modo pulito.

== Requisiti ==
Secondo la documentazione ufficiale:
* Python 3.9 o superiore
* installazione come utente normale, non con `sudo`
* ambiente isolato consigliato

== Verifica Python ==
<pre>
python3 --version
</pre>

== Metodo consigliato: uv ==
La documentazione ufficiale indica `uv` come metodo consigliato.

Installare `uv` se non presente e poi installare pyinfra come tool:
<pre>
uv tool install pyinfra
pyinfra --version
</pre>

== Alternativa: pipx ==
<pre>
pipx install pyinfra
pyinfra --version
</pre>

== Alternativa: virtual environment ==
<pre>
python3 -m venv ~/venv/pyinfra
source ~/venv/pyinfra/bin/activate
pip install pyinfra
pyinfra --version
</pre>

== Verifica rapida ==
Eseguire un test locale:
<pre>
pyinfra @local exec -- echo "hello world"
</pre>

== Verifica remota ==
Test base via SSH:
<pre>
pyinfra my-server.net exec -- uptime
</pre>

== Caso Fedora con pipx ==
Se `pipx` non e presente:
<pre>
sudo dnf install -y pipx
pipx ensurepath
pipx install pyinfra
</pre>

== Caso Fedora con uv ==
Se `uv` non e presente, installarlo secondo le istruzioni ufficiali del progetto e poi:
<pre>
uv tool install pyinfra
</pre>

== Consigli pratici ==
* non installare pyinfra come root
* preferire `uv` o `pipx` per tenere pulito il sistema
* usare `--dry` per i primi test
* tenere inventory e deploy in una repository Git

== Primo mini deploy ==
Inventory:
<pre>
my_hosts = ["localhost"]
</pre>

Deploy:
<pre>
from pyinfra.operations import server

server.shell(
name="Test command",
commands=["hostname"],
)
</pre>

Esecuzione:
<pre>
pyinfra inventory.py deploy.py --dry
pyinfra inventory.py deploy.py
</pre>

== Link ufficiali ==
* [https://docs.pyinfra.com/en/3.x/install.html Installazione]
* [https://docs.pyinfra.com/en/3.x/getting-started.html Getting Started]
* [https://docs.pyinfra.com/en/3.x/ Installation Docs Home]

Esempi Pyinfra

2026-03-28T23:06:21Z

Admin: Creazione pagina informativa su pyinfra

= Esempi Pyinfra =

Pagina operativa con esempi minimi e riusabili per iniziare a usare '''pyinfra'''.

== Struttura minima ==
Esempio di file:
<pre>
inventory.py
deploy.py
</pre>

== Inventory semplice ==
<pre>
web_servers = [
"web-01.example.net",
"web-02.example.net",
]

db_servers = [
("db-01.example.net", {"install_postgres": True}),
]
</pre>

== Deploy semplice ==
<pre>
from pyinfra.operations import apt, server

apt.packages(
name="Install packages",
packages=["vim", "curl"],
update=True,
)

server.shell(
name="Show uptime",
commands=["uptime"],
)
</pre>

Esecuzione:
<pre>
pyinfra inventory.py deploy.py
</pre>

== Esempio con gruppi ==
<pre>
from pyinfra import host, local
from pyinfra.operations import server

if 'web_servers' in host.groups:
local.include('tasks/web.py')

if 'db_servers' in host.groups:
local.include('tasks/database.py')

server.shell(
name="Run everywhere",
commands=["hostname"],
)
</pre>

== Esempio con dati host ==
Inventory:
<pre>
app_servers = [
("app-01.example.net", {"install_nginx": True}),
("app-02.example.net", {"install_nginx": False}),
]
</pre>

Deploy:
<pre>
from pyinfra import host
from pyinfra.operations import apt

if host.data.get("install_nginx"):
apt.packages(
name="Install nginx",
packages=["nginx"],
update=True,
)
</pre>

== Esempio local machine ==
<pre>
pyinfra @local exec -- echo "hello world"
</pre>

== Esempio su container Docker ==
<pre>
pyinfra @docker/ubuntu:22.04 exec -- uname -a
</pre>

== Esempio installazione file ==
<pre>
from pyinfra.operations import files

files.file(
name="Ensure app log exists",
path="/var/log/app.log",
user="app",
group="app",
mode="644",
)
</pre>

== Esempio service management ==
<pre>
from pyinfra.operations import systemd

systemd.service(
name="Ensure nginx is running",
service="nginx",
running=True,
enabled=True,
)
</pre>

== Esempio dry-run ==
<pre>
pyinfra inventory.py deploy.py --dry
</pre>

== Note pratiche ==
* tenere `inventory.py` e `deploy.py` in Git
* usare `host.data` per differenziare host simili
* separare task complessi in file inclusi
* usare `--dry` prima dei deploy reali

== Link ufficiali ==
* [https://docs.pyinfra.com/en/3.x/getting-started.html Getting Started]
* [https://docs.pyinfra.com/en/3.x/inventory-data.html Inventory & Data]
* [https://docs.pyinfra.com/en/3.x/examples/groups_roles.html Groups & Roles]
* [https://docs.pyinfra.com/en/3.x/using-operations.html Using Operations]

Confronto Ansible vs Pyinfra

2026-03-28T23:06:21Z

Admin: Creazione pagina informativa su pyinfra

= Confronto Ansible vs Pyinfra =

'''Ansible''' e '''Pyinfra''' risolvono problemi simili: automazione, provisioning, configurazione e deploy di sistemi remoti. La differenza principale e nel modello operativo e nel linguaggio usato per descrivere i deploy.

== Differenza principale ==
* '''Ansible''': punta soprattutto su playbook in YAML.
* '''Pyinfra''': usa Python per inventory, logica e deploy.

== Modello mentale ==
=== Ansible ===
* playbook
* ruoli
* inventory
* task dichiarativi in YAML
* moduli richiamati da task

=== Pyinfra ===
* inventory Python
* operations Python
* dati host e gruppi
* logica direttamente nel linguaggio
* stato desiderato espresso tramite operations

== Vantaggi di Ansible ==
* molto diffuso
* enorme ecosistema di ruoli e moduli
* YAML spesso e piu leggibile per team operations puri
* documentazione e community molto ampie

== Vantaggi di Pyinfra ==
* meno attrito per chi lavora gia in Python
* condizioni, riuso e composizione piu naturali
* ottimo sia per comandi ad-hoc sia per deploy versionati
* inventory e dati molto flessibili
* puo risultare piu pulito quando la logica supera i limiti pratici del solo YAML

== Svantaggi di Ansible ==
* quando la logica cresce, i playbook possono diventare verbosi
* spesso si finisce per spostare logica in template, plugin o script esterni
* debugging e riuso possono diventare piu dispersi

== Svantaggi di Pyinfra ==
* richiede piu confidenza con Python
* ecosistema meno vasto di Ansible
* alcuni team preferiscono separare nettamente codice e automazione

== Stato desiderato ==
Entrambi supportano un approccio a stato desiderato.

In pyinfra, secondo la documentazione ufficiale, le operations definiscono lo stato richiesto e il tool applica modifiche solo quando necessarie dopo aver verificato la situazione reale del target.

== Esecuzione ==
Secondo la documentazione ufficiale di pyinfra, il tool prepara l'ordine delle operations e poi esegue ciascuna operation in parallelo sui target pertinenti.

Questo significa che l'ordine logico del deploy resta definito, ma l'esecuzione sui target puo essere efficiente.

== Quando scegliere Ansible ==
* team gia standardizzato su YAML
* bisogno di ruoli gia pronti e collaudati
* team operations con poca voglia di scrivere Python
* ambienti enterprise dove Ansible e gia lo standard interno

== Quando scegliere Pyinfra ==
* team tecnico che usa gia Python ogni giorno
* homelab e sysadmin che vogliono logica piu espressiva
* deploy dove condizioni, dati e riuso sono importanti
* ambienti piccoli o medi dove si preferisce meno boilerplate

== Conclusione pratica ==
* '''Scegli Ansible''' se vuoi massima diffusione, standard di mercato e playbook leggibili da team molto eterogenei.
* '''Scegli Pyinfra''' se vuoi automazione piu programmabile, riuso in Python e meno attrito quando la logica cresce.

== Link ufficiali ==
* [https://docs.pyinfra.com/en/3.x/getting-started.html pyinfra Getting Started]
* [https://docs.pyinfra.com/en/3.x/deploy-process.html pyinfra How it Works]
* [https://docs.pyinfra.com/en/3.x/inventory-data.html pyinfra Inventory & Data]
* [https://docs.ansible.com/ansible/latest/getting_started/index.html Ansible Getting Started]

Pyinfra

2026-03-28T23:04:49Z

Admin: Creazione pagina introduttiva su pyinfra con esempi e link ufficiali

= Pyinfra =

'''Pyinfra''' e uno strumento open source di automazione e deploy infrastrutturale scritto in Python. Può essere usato sia per comandi ad-hoc sia per deploy ripetibili definiti in file Python versionabili in Git.

== Concetto base ==
Pyinfra lavora con due elementi principali:
* '''Inventory''': host, gruppi e dati associati agli host.
* '''Operations''': stato desiderato o comandi da applicare ai target.

L'approccio e vicino ad Ansible sul piano operativo, ma invece di descrivere i deploy soprattutto in YAML, pyinfra usa Python.

== Come funziona ==
Secondo la documentazione ufficiale, l'esecuzione avviene in cinque fasi:
# lettura di inventory e data
# connessione ai target
# preparazione con rilevamento cambiamenti e ordine operazioni
# esecuzione delle modifiche
# disconnessione e cleanup

Un punto importante e che pyinfra prepara prima l'ordine delle operazioni e poi le esegue. Questo permette di mantenere l'ordine logico delle operazioni, eseguendo ogni singola operation in parallelo sui target rilevanti.

== Inventory ==
Un inventory pyinfra contiene:
* host
* gruppi
* dati di gruppo
* dati per singolo host

Esempio minimale:
<pre>
web_servers = [
"web-01.example.net",
"web-02.example.net",
]

db_servers = [
("db-01.example.net", {"install_postgres": True}),
]
</pre>

I dati associati agli host o ai gruppi possono essere usati nel deploy Python tramite `host.data`.

== Operations ==
Le operations descrivono cosa deve essere vero sul sistema target. In molti casi non rappresentano un'azione imperativa ma uno '''stato desiderato'''.

Esempio:
<pre>
from pyinfra.operations import apt, files

apt.packages(
name="Install vim",
packages=["vim"],
update=True,
)

files.file(
name="Ensure log file exists",
path="/var/log/app.log",
user="app",
group="app",
mode="644",
)
</pre>

Se il target e gia nello stato richiesto, pyinfra non applica cambiamenti ulteriori.

== Comandi ad-hoc ==
Pyinfra puo essere usato anche direttamente da CLI senza creare un deploy completo.

Esempi:
<pre>
pyinfra @local exec -- echo "hello world"
pyinfra my-server.net exec -- uptime
pyinfra @docker/ubuntu:22.04 exec -- uname -a
</pre>

== Esempio base di deploy ==
Inventory:
<pre>
my_hosts = [
("ubuntu2204", {
"ssh_port": 2222,
"ssh_hostname": "localhost",
"ssh_user": "vagrant",
"_sudo": True,
}),
"my-server.net",
]
</pre>

Deploy:
<pre>
from pyinfra.operations import apt

apt.packages(
name="Ensure vim is installed",
packages=["vim"],
update=True,
)
</pre>

Esecuzione:
<pre>
pyinfra inventory.py deploy.py
</pre>

== Differenze pratiche rispetto ad Ansible ==
* usa '''Python''' invece di fare affidamento principalmente su YAML
* e comodo per chi vuole logica, condizioni e riuso direttamente nel linguaggio
* mantiene il modello inventory + operazioni + stato desiderato
* puo essere piu naturale per team che preferiscono automazione programmabile piuttosto che playbook dichiarativi

== Quando ha senso usarlo ==
* homelab e server Linux
* provisioning e configurazioni ripetibili
* deploy gestiti in Git
* ambienti dove Python e gia parte del flusso operativo

== Limiti da tenere presenti ==
* richiede maggiore familiarita con Python rispetto a strumenti piu dichiarativi
* alcuni team preferiscono YAML per leggibilita immediata lato operations
* va progettato con attenzione quando la logica dipende da fatti che possono cambiare durante il deploy

== Installazione ==
Secondo la documentazione ufficiale, il metodo consigliato e:
<pre>
uv tool install pyinfra
pyinfra --version
</pre>

Alternative supportate: `pipx` oppure `pip` in virtual environment.

== Link ufficiali ==
* [https://pyinfra.com/ Sito ufficiale]
* [https://docs.pyinfra.com/en/3.x/ Documentazione]
* [https://docs.pyinfra.com/en/3.x/getting-started.html Getting Started]
* [https://docs.pyinfra.com/en/3.x/inventory-data.html Inventory & Data]
* [https://docs.pyinfra.com/en/3.x/using-operations.html Using Operations]
* [https://docs.pyinfra.com/en/3.x/deploy-process.html How pyinfra Works]

APPUNTI

2026-03-28T23:00:26Z

Admin: Bonifica contenuti sensibili e procedure di recupero credenziali

Appunti bonificati il 2026-03-28: i dettagli sensibili e le procedure di recupero credenziali sono stati rimossi da questa pagina.

Dati non sensibili:
- LAST DEPLOYED: Sun May 19 22:09:47 2024
- NAMESPACE: default
- STATUS: deployed
- REVISION: 1
- CHART NAME: mariadb
- CHART VERSION: 18.0.6
- APP VERSION: 11.3.2

Nota operativa:
- Le credenziali amministrative, i comandi per il recupero dei secret e i riferimenti infrastrutturali di dettaglio devono restare in runbook interni, password manager o repository privati.
- Per accesso, upgrade o manutenzione usare solo documentazione interna riservata.
- Evitare di pubblicare in wiki pubblico password, token, secret Kubernetes, hostname interni o shell transcript con dati operativi.

Tips Linux/OpenLDAP e SSH

2026-03-25T11:26:53Z

Admin: Creazione sottosezione Tips Linux: OpenLDAP e SSH con configurazione LDAP/SSSD/SSH e sudo

= OpenLDAP e SSH =

Questa pagina documenta una configurazione pratica di integrazione tra OpenLDAP e SSH su Ubuntu, con autenticazione utenti centralizzata e privilegi sudo per utente tecnico.

== Obiettivo ==
* Login SSH con utenza LDAP (es. `gazzinet`)
* Risoluzione utenti via SSSD/NSS
* Elevazione privilegi con `sudo`

== Parametri LDAP usati ==
* URI: `ldap://172.16.1.7:389`
* Base DN: `dc=gazzi,dc=local`
* User search base: `ou=People,dc=gazzi,dc=local`
* Group search base: `ou=Groups,dc=gazzi,dc=local`
* Bind DN tecnico: `uid=ldapbind,ou=People,dc=gazzi,dc=local`

== Pacchetti installati ==
<syntaxhighlight lang="bash">
apt-get update
apt-get install -y sssd-ldap libnss-sss libpam-sss ldap-utils sudo qemu-guest-agent
</syntaxhighlight>

== Configurazione SSSD ==
File: `/etc/sssd/sssd.conf`

<syntaxhighlight lang="ini">
[sssd]
services = nss, pam
config_file_version = 2
domains = GAZZI

[domain/GAZZI]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
access_provider = permit
cache_credentials = True
enumerate = False
use_fully_qualified_names = False
fallback_homedir = /home/%u
default_shell = /bin/bash
ldap_uri = ldap://172.16.1.7:389
ldap_search_base = dc=gazzi,dc=local
ldap_user_search_base = ou=People,dc=gazzi,dc=local
ldap_group_search_base = ou=Groups,dc=gazzi,dc=local
ldap_default_bind_dn = uid=ldapbind,ou=People,dc=gazzi,dc=local
ldap_default_authtok = ********
ldap_user_object_class = inetOrgPerson
ldap_user_name = uid
ldap_group_object_class = groupOfNames
ldap_group_name = cn
ldap_tls_reqcert = never
ldap_id_use_start_tls = False
ldap_auth_disable_tls_never_use_in_production = true
</syntaxhighlight>

Note:
* Il parametro `ldap_auth_disable_tls_never_use_in_production = true` è stato necessario in questo ambiente LDAP non-TLS.
* In produzione consigliata: LDAP su TLS/LDAPS con certificati validi.

== Integrazione NSS/PAM ==
* In `/etc/nsswitch.conf` aggiunto `sss` per `passwd`, `group`, `shadow`
* Home automatica al primo login via `pam_mkhomedir`

== Configurazione SSH ==
File override: `/etc/ssh/sshd_config.d/99-ldap-auth.conf`

<syntaxhighlight lang="text">
UsePAM yes
PasswordAuthentication yes
KbdInteractiveAuthentication yes
PubkeyAuthentication yes
</syntaxhighlight>

== Sudo per utente LDAP ==
File: `/etc/sudoers.d/90-gazzinet-ldap`

<syntaxhighlight lang="text">
gazzinet ALL=(ALL:ALL) ALL
</syntaxhighlight>

== Verifiche effettuate ==
<syntaxhighlight lang="bash">
getent passwd gazzinet
systemctl is-active sssd
sshd -T | grep -E 'usepam|passwordauthentication|kbdinteractiveauthentication'
</syntaxhighlight>

Test operativo finale:
* Login SSH come `gazzinet` riuscito
* `sudo` funzionante con password utente LDAP

[[Category:Tips Linux]]

VerificheRapideLinux

2026-03-20T11:16:41Z

Admin: Creata pagina con "== Verifiche rapide == === Controllo tempo di risposta sito === <pre> curl -k --connect-timeout 30 --max-time 30 --write-out '%{time_total};%{http_code}\n' http://www.gazzi.net/ </pre> === Stato del sistema === <pre> uptime uname -a hostnamectl free -h df -h </pre> === Processi e servizi === <pre> ps -ef | less systemctl --failed systemctl status nome-servizio journalctl -xeu nome-servizio </pre> === Rete e porte === <pre> ip a ip r ss -tulpn ping -c 4 host_o_ip curl..."

== Verifiche rapide ==

=== Controllo tempo di risposta sito ===
<pre>
curl -k --connect-timeout 30 --max-time 30 --write-out '%{time_total};%{http_code}\n' http://www.gazzi.net/
</pre>

=== Stato del sistema ===
<pre>
uptime
uname -a
hostnamectl
free -h
df -h
</pre>

=== Processi e servizi ===
<pre>
ps -ef | less
systemctl --failed
systemctl status nome-servizio
journalctl -xeu nome-servizio
</pre>

=== Rete e porte ===
<pre>
ip a
ip r
ss -tulpn
ping -c 4 host_o_ip
curl -I https://host_o_url
</pre>

Tips Linux

2026-03-20T11:16:34Z

Admin:

__NOTOC__
Breve raccolta di riferimenti operativi Linux usati nel contesto GazziNet. La pagina serve come indice rapido per verifiche, troubleshooting e accesso ai sotto-argomenti gia documentati nel wiki.

[[VerificheRapideLinux]]

=== ACL Linux ===

[[ACL_Linux:_storia,_concetti_e_uso_pratico]]

<pre>
https://wiki.gazzi.net/index.php?title=ACL_Linux:_storia,_concetti_e_uso_pratico
</pre>

== Comandi Linux di base ==

=== Navigazione e file ===
<pre>
pwd
ls -la
cd /percorso
mkdir nome-directory
touch file.txt
cp sorgente destinazione
mv vecchio nuovo
rm file.txt
rm -r directory
cat file.txt
less file.txt
head -n 20 file.txt
tail -n 20 file.txt
</pre>

=== Ricerca rapida ===
<pre>
grep -n parola file.txt
grep -R "pattern" /percorso
find /percorso -name "*.log"
find /percorso -type f -mtime -1
which comando
whereis comando
</pre>

=== Permessi e proprieta ===
<pre>
ls -l
chmod 644 file.txt
chmod +x script.sh
chown utente:gruppo file.txt
id
whoami
</pre>

=== Archivi e trasferimento ===
<pre>
tar -czf archivio.tar.gz directory/
tar -xzf archivio.tar.gz
scp file.txt utente@host:/percorso/
rsync -av origine/ destinazione/
</pre>

== Scheda rapida awk ==
awk e utile quando serve estrarre colonne, filtrare righe o fare piccoli report da output testuali senza aprire editor o scrivere script piu lunghi.

=== Sintassi minima ===
<pre>
awk 'condizione { azione }' file
comando | awk 'condizione { azione }'
</pre>

=== Usi tipici ===

==== Stampare colonne specifiche ====
<pre>
ps -ef | awk '{print $1, $2, $8}'
df -h | awk '{print $1, $5, $6}'
</pre>

==== Saltare l'intestazione ====
<pre>
df -h | awk 'NR>1 {print $1, $5, $6}'
</pre>

==== Filtrare righe che contengono una condizione ====
<pre>
ss -tulpn | awk '/LISTEN/ {print $1, $5, $7}'
ps -ef | awk '/nginx/ && !/awk/ {print $2, $8}'
</pre>

==== Usare un separatore diverso ====
<pre>
awk -F: '{print $1, $7}' /etc/passwd
awk -F= '{print $1, $2}' file.conf
</pre>

==== Fare conteggi e somme ====
<pre>
ps -ef | awk 'END {print NR " righe totali"}'
awk '{somma += $1} END {print somma}' numeri.txt
</pre>

==== Mostrare solo righe sopra una soglia ====
<pre>
df -h | awk 'NR>1 && $5+0 >= 80 {print $1, $5, $6}'
free -m | awk '/Mem:/ {print "RAM usata:", $3 " MB"}'
</pre>

==== Formattare output in modo leggibile ====
<pre>
awk -F: '{printf "utente=%s shell=%s
", $1, $7}' /etc/passwd
</pre>

=== Note pratiche su awk ===
* `NR` indica il numero di riga corrente.
* `$1`, `$2`, `$3` indicano la prima, seconda e terza colonna.
* `-F` imposta il separatore di campo.
* In output da comandi di sistema, awk e molto utile insieme a `grep`, `sort`, `uniq` e `xargs`.
* Se l'output contiene spazi irregolari, verificare prima il separatore reale o usare `printf` invece di `print`.

== Troubleshooting operativo ==

=== Log principali ===
<pre>
journalctl -b
journalctl -p err -b
tail -n 100 /var/log/messages
tail -n 100 /var/log/secure
</pre>

=== Spazio disco e inode ===
<pre>
df -h
df -i
du -sh /var/* | sort -h
find /var/log -type f -size +100M -ls
</pre>

=== Mount e multipath ===
Per ambienti con storage esterno o SAN, usare le procedure dedicate prima di eseguire rescan o interventi sui device.

* [[Rescan MultiPath fisica]]

== Pacchetti e repository ==

=== Verifiche base ===
<pre>
rpm -qa | wc -l
rpm -q nome-pacchetto
which comando
</pre>

=== Riferimenti dedicati ===
* [[Differenze tra le principali distribuzioni Linux]]
* [[PIP]]
* [[EPEL Oracle]]

== Accesso remoto e identita ==
* [[GestioneSSHCertificati]]
* [[LDAP]]
* [[RustDesk]]

== Script e analisi ==
* [[CheckScript]]
* [[AnalisiServer]]
* [[Parallelizzazione comandi]]
* [[Deleted Files|Deleted Files]]

== Configurazione e sistema ==
* [[TimeZone]]

== Note d'uso ==
* Preferire sempre verifiche non invasive prima di riavvii o fix correttivi.
* Se il problema coinvolge storage, autenticazione o rete, documentare subito hostname, orario, sintomo e ultimo cambiamento noto.
* Spostare i casi ricorrenti in pagine dedicate invece di far crescere questa pagina senza struttura.

Tips Linux

2026-03-20T11:14:17Z

Admin:

__NOTOC__
Breve raccolta di riferimenti operativi Linux usati nel contesto GazziNet. La pagina serve come indice rapido per verifiche, troubleshooting e accesso ai sotto-argomenti gia documentati nel wiki.

=== ACL Linux ===

[[ACL_Linux:_storia,_concetti_e_uso_pratico]]

<pre>
https://wiki.gazzi.net/index.php?title=ACL_Linux:_storia,_concetti_e_uso_pratico
</pre>

== Comandi Linux di base ==

=== Navigazione e file ===
<pre>
pwd
ls -la
cd /percorso
mkdir nome-directory
touch file.txt
cp sorgente destinazione
mv vecchio nuovo
rm file.txt
rm -r directory
cat file.txt
less file.txt
head -n 20 file.txt
tail -n 20 file.txt
</pre>

=== Ricerca rapida ===
<pre>
grep -n parola file.txt
grep -R "pattern" /percorso
find /percorso -name "*.log"
find /percorso -type f -mtime -1
which comando
whereis comando
</pre>

=== Permessi e proprieta ===
<pre>
ls -l
chmod 644 file.txt
chmod +x script.sh
chown utente:gruppo file.txt
id
whoami
</pre>

=== Archivi e trasferimento ===
<pre>
tar -czf archivio.tar.gz directory/
tar -xzf archivio.tar.gz
scp file.txt utente@host:/percorso/
rsync -av origine/ destinazione/
</pre>

== Scheda rapida awk ==
awk e utile quando serve estrarre colonne, filtrare righe o fare piccoli report da output testuali senza aprire editor o scrivere script piu lunghi.

=== Sintassi minima ===
<pre>
awk 'condizione { azione }' file
comando | awk 'condizione { azione }'
</pre>

=== Usi tipici ===

==== Stampare colonne specifiche ====
<pre>
ps -ef | awk '{print $1, $2, $8}'
df -h | awk '{print $1, $5, $6}'
</pre>

==== Saltare l'intestazione ====
<pre>
df -h | awk 'NR>1 {print $1, $5, $6}'
</pre>

==== Filtrare righe che contengono una condizione ====
<pre>
ss -tulpn | awk '/LISTEN/ {print $1, $5, $7}'
ps -ef | awk '/nginx/ && !/awk/ {print $2, $8}'
</pre>

==== Usare un separatore diverso ====
<pre>
awk -F: '{print $1, $7}' /etc/passwd
awk -F= '{print $1, $2}' file.conf
</pre>

==== Fare conteggi e somme ====
<pre>
ps -ef | awk 'END {print NR " righe totali"}'
awk '{somma += $1} END {print somma}' numeri.txt
</pre>

==== Mostrare solo righe sopra una soglia ====
<pre>
df -h | awk 'NR>1 && $5+0 >= 80 {print $1, $5, $6}'
free -m | awk '/Mem:/ {print "RAM usata:", $3 " MB"}'
</pre>

==== Formattare output in modo leggibile ====
<pre>
awk -F: '{printf "utente=%s shell=%s
", $1, $7}' /etc/passwd
</pre>

=== Note pratiche su awk ===
* `NR` indica il numero di riga corrente.
* `$1`, `$2`, `$3` indicano la prima, seconda e terza colonna.
* `-F` imposta il separatore di campo.
* In output da comandi di sistema, awk e molto utile insieme a `grep`, `sort`, `uniq` e `xargs`.
* Se l'output contiene spazi irregolari, verificare prima il separatore reale o usare `printf` invece di `print`.

== Troubleshooting operativo ==

=== Log principali ===
<pre>
journalctl -b
journalctl -p err -b
tail -n 100 /var/log/messages
tail -n 100 /var/log/secure
</pre>

=== Spazio disco e inode ===
<pre>
df -h
df -i
du -sh /var/* | sort -h
find /var/log -type f -size +100M -ls
</pre>

=== Mount e multipath ===
Per ambienti con storage esterno o SAN, usare le procedure dedicate prima di eseguire rescan o interventi sui device.

* [[Rescan MultiPath fisica]]

== Pacchetti e repository ==

=== Verifiche base ===
<pre>
rpm -qa | wc -l
rpm -q nome-pacchetto
which comando
</pre>

=== Riferimenti dedicati ===
* [[Differenze tra le principali distribuzioni Linux]]
* [[PIP]]
* [[EPEL Oracle]]

== Accesso remoto e identita ==
* [[GestioneSSHCertificati]]
* [[LDAP]]
* [[RustDesk]]

== Script e analisi ==
* [[CheckScript]]
* [[AnalisiServer]]
* [[Parallelizzazione comandi]]
* [[Deleted Files|Deleted Files]]

== Configurazione e sistema ==
* [[TimeZone]]

== Note d'uso ==
* Preferire sempre verifiche non invasive prima di riavvii o fix correttivi.
* Se il problema coinvolge storage, autenticazione o rete, documentare subito hostname, orario, sintomo e ultimo cambiamento noto.
* Spostare i casi ricorrenti in pagine dedicate invece di far crescere questa pagina senza struttura.

TIPS Linux - Verifiche rapide

2026-03-20T11:07:31Z

Admin: Rollback modifica precedente

ACL Linux: storia, concetti e uso pratico

2026-03-20T11:07:31Z

Admin: Rollback modifica precedente

== Introduzione ==

Le '''ACL''' (''Access Control List'') in Linux estendono il modello classico dei permessi Unix e consentono un controllo accessi piu granulare.

Quando owner, group e others non bastano, le ACL permettono di assegnare regole specifiche a singoli utenti o gruppi mantenendo il principio del minimo privilegio.

== Concetti base ==

Nel modello standard Unix hai tre classi di permessi:
* proprietario
* gruppo
* altri

Con le ACL puoi aggiungere entry dedicate, ad esempio per dare accesso a un utente tecnico senza cambiare proprietario della risorsa.

Comandi principali:
* <code>getfacl</code> per leggere ACL correnti
* <code>setfacl</code> per creare/modificare/rimuovere ACL

== Esempi pratici ==

=== Concedere permessi a un utente specifico ===

<pre>
sudo setfacl -m u:deploy:rwx /srv/progetto/shared
</pre>

=== Definire ACL di default su una directory ===

Le ACL di default vengono ereditate da nuovi file e directory creati al suo interno.

<pre>
sudo setfacl -m d:u:deploy:rwx /srv/progetto/shared
</pre>

=== Verificare ACL effettive ===

<pre>
getfacl /srv/progetto/shared
</pre>

Nota: la voce '''mask''' puo limitare i permessi realmente applicati.

== Relazione con chmod ==

ACL e permessi tradizionali convivono. Dopo modifiche con <code>chmod</code>, e buona pratica controllare sempre il risultato con <code>getfacl</code> per verificare eventuali effetti sulla maschera ACL.

== Quando usare le ACL ==

* ambienti multiutente
* directory condivise con esigenze di accesso diverse
* casi in cui si vogliono evitare permessi eccessivamente ampi (es. <code>777</code>)
* sistemi in cui serve tracciare policy accessi piu rigorose

== Storia delle ACL ==

Timeline essenziale:
* '''Anni 60-70''': concetti ACL gia presenti in sistemi multiutente storici
* '''Anni 90''': sviluppo delle estensioni sicurezza IEEE POSIX 1003.1e
* '''Ottobre 1997''': riferimento tecnico nella bozza POSIX.1e Draft 17
* '''Gennaio 1998''': standardizzazione POSIX.1e ritirata; il modello ACL continua comunque a essere implementato
* '''Novembre 2002''': supporto ACL POSIX incluso nel kernel Linux 2.5.46 (ramo di sviluppo)
* '''Dal 2003 in poi''': adozione ampia nei filesystem Linux usati in produzione

In sintesi, pur senza standard finale ratificato, le ACL sono diventate uno strumento consolidato nell'amministrazione Linux.

== Buone pratiche ==

* applicare ACL solo dove necessario
* documentare le regole nei runbook operativi
* verificare periodicamente configurazioni e ereditarieta
* mantenere un approccio minimo privilegio

== Approfondimento tecnico ACL Linux ==

=== Modello ACL POSIX: entry principali ===

Le ACL POSIX su file/directory usano tipicamente queste entry:
* <code>user::</code> permessi del proprietario
* <code>group::</code> permessi del gruppo proprietario
* <code>other::</code> permessi per tutti gli altri
* <code>user:nome_utente:</code> eccezioni per singolo utente
* <code>group:nome_gruppo:</code> eccezioni per gruppo specifico
* <code>mask::</code> limite massimo effettivo per group e named user/group
* <code>default:...</code> ACL ereditarie (solo su directory)

=== Mask: il punto piu importante da capire ===

La <code>mask</code> limita i permessi effettivi di:
* <code>group::</code>
* tutte le entry <code>user:...</code> nominate
* tutte le entry <code>group:...</code> nominate

Esempio: se una entry dice <code>rwx</code> ma la mask e <code>r-x</code>, il risultato effettivo e <code>r-x</code>.

<pre>
setfacl -m m::rwx /percorso
</pre>

=== ACL access vs ACL default ===

* '''Access ACL''': controlla accesso attuale al file/directory.
* '''Default ACL''': template ereditato da nuovi oggetti creati dentro una directory.

<pre>
setfacl -m u:deploy:rwx /srv/shared
setfacl -m d:u:deploy:rwx /srv/shared
</pre>

=== Interazione con chmod e umask ===

* <code>chmod</code> puo modificare la mask ACL, cambiando i permessi effettivi.
* <code>umask</code> influenza i permessi iniziali alla creazione; se esiste una default ACL, quest'ultima partecipa al risultato finale.

=== Verifica tecnica rapida ===

<pre>
ls -l /percorso
getfacl /percorso
stat /percorso
</pre>

=== Backup e ripristino ACL ===

<pre>
getfacl -R /srv/shared > /root/acl-backup.txt
setfacl --restore=/root/acl-backup.txt
</pre>

=== Operazioni utili avanzate ===

<pre>
setfacl -b /percorso
setfacl -k /directory
setfacl -R -m u:deploy:rwX /srv/shared
</pre>

=== Troubleshooting tipico ===

<pre>
namei -om /percorso/file
</pre>

== Fonti ==

* [https://man7.org/linux/man-pages/man5/acl.5.html man page acl(5)]
* [https://atc.usenix.org/legacy/events/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/index.html USENIX 2003 - POSIX ACLs on Linux]
== Significato dei parametri usati nei comandi ==

=== setfacl ===

<pre>setfacl -m u:deploy:rwx /srv/progetto/shared</pre>

* <code>-m</code>: modifica (add/update) una ACL entry.
* <code>u:deploy:rwx</code>: entry ACL per utente `deploy` con permessi `rwx`.
: `u` = user, `deploy` = utente, `rwx` = read/write/execute.
* <code>/srv/progetto/shared</code>: path target.

<pre>setfacl -m d:u:deploy:rwx /srv/progetto/shared</pre>

* <code>d:</code>: ACL di default (ereditaria, valida su directory).
* <code>u:deploy:rwx</code>: come sopra, ma applicata ai nuovi file/cartelle creati dentro la directory.

<pre>setfacl -m m::rwx /percorso</pre>

* <code>m::rwx</code>: imposta la <code>mask</code> ACL a `rwx`.
: La mask limita i permessi effettivi di group e named user/group.

<pre>setfacl -R -m u:deploy:rwX /srv/shared</pre>

* <code>-R</code>: applicazione ricorsiva su tutto l'albero.
* <code>rwX</code>: `r` read, `w` write, `X` execute solo su directory (e su file che hanno gia execute).

<pre>setfacl -b /percorso</pre>

* <code>-b</code>: rimuove ACL estese, mantenendo i permessi base Unix.

<pre>setfacl -k /directory</pre>

* <code>-k</code>: rimuove solo le ACL di default dalla directory.

<pre>setfacl --restore=/root/acl-backup.txt</pre>

* <code>--restore=FILE</code>: ripristina ACL da backup creato con `getfacl -R`.

=== getfacl ===

<pre>getfacl /srv/progetto/shared</pre>

* stampa ACL (access e default) del path.

<pre>getfacl -R /srv/shared > /root/acl-backup.txt</pre>

* <code>-R</code>: output ricorsivo.
* <code>></code>: redirect su file per backup.

=== ls / stat / namei ===

<pre>ls -l /percorso</pre>

* <code>-l</code>: formato esteso (permessi, owner, group, size, date).
: Se compare `+` nei permessi (es. `drwxr-xr-x+`) sono presenti ACL estese.

<pre>stat /percorso</pre>

* mostra metadata dettagliati del file/directory (mode, uid/gid, inode, timestamp).

<pre>namei -om /percorso/file</pre>

* risolve ogni componente del path e mostra permessi/proprietari passo-passo.
* <code>-o</code>: mostra owner e group.
* <code>-m</code>: mostra i bit di permesso in stile `ls -l`.

=== Promemoria rapido sui simboli permesso ===

* <code>r</code> = read
* <code>w</code> = write
* <code>x</code> = execute/traverse
* <code>X</code> = execute condizionale (utile nelle ricorsioni)

TIPS Linux - Verifiche rapide

2026-03-20T11:05:24Z

Admin: Tag pagina: aggiunta categoria TIPS Linux

null

[[Category:TIPS Linux]]

ACL Linux: storia, concetti e uso pratico

2026-03-20T11:05:24Z

Admin: Aggiornata pagina originale con rimando a Verifiche rapide

null

== Verifiche rapide ==

La checklist operativa e stata spostata in una pagina dedicata:
* [[TIPS Linux - Verifiche rapide]]

TIPS Linux

2026-03-20T10:58:40Z

Admin: Aggiunto link alla pagina Verifiche rapide

\n* [[ACL Linux: storia, concetti e uso pratico]]\n* [[TIPS Linux - Verifiche rapide]]

TIPS Linux - Verifiche rapide

2026-03-20T10:58:40Z

Admin: Nuova pagina separata: verifiche rapide

ACL Linux: storia, concetti e uso pratico

2026-03-20T10:50:47Z

Admin: Aggiunta spiegazione parametri dei comandi ACL

ACL Linux: storia, concetti e uso pratico

2026-03-20T10:33:43Z

Admin: Fix rendering: sostituiti blocchi syntaxhighlight non supportati e ripristinato contenuto

ACL Linux: storia, concetti e uso pratico

2026-03-20T10:32:32Z

Admin: Compatibilita wiki: sostituiti syntaxhighlight con blocchi pre

null

ACL Linux: storia, concetti e uso pratico

2026-03-20T10:28:17Z

Admin: Aggiunto approfondimento tecnico ACL (mask, default ACL, chmod/umask, audit, restore, troubleshooting)

== Introduzione ==

Le '''ACL''' (''Access Control List'') in Linux estendono il modello classico dei permessi Unix e consentono un controllo accessi piu granulare.

Quando owner, group e others non bastano, le ACL permettono di assegnare regole specifiche a singoli utenti o gruppi mantenendo il principio del minimo privilegio.

== Concetti base ==

Nel modello standard Unix hai tre classi di permessi:
* proprietario
* gruppo
* altri

Con le ACL puoi aggiungere entry dedicate, ad esempio per dare accesso a un utente tecnico senza cambiare proprietario della risorsa.

Comandi principali:
* <code>getfacl</code> per leggere ACL correnti
* <code>setfacl</code> per creare/modificare/rimuovere ACL

== Esempi pratici ==

=== Concedere permessi a un utente specifico ===

<syntaxhighlight lang="bash">
sudo setfacl -m u:deploy:rwx /srv/progetto/shared
</syntaxhighlight>

=== Definire ACL di default su una directory ===

Le ACL di default vengono ereditate da nuovi file e directory creati al suo interno.

<syntaxhighlight lang="bash">
sudo setfacl -m d:u:deploy:rwx /srv/progetto/shared
</syntaxhighlight>

=== Verificare ACL effettive ===

<syntaxhighlight lang="bash">
getfacl /srv/progetto/shared
</syntaxhighlight>

Nota: la voce '''mask''' puo limitare i permessi realmente applicati.

== Relazione con chmod ==

ACL e permessi tradizionali convivono. Dopo modifiche con <code>chmod</code>, e buona pratica controllare sempre il risultato con <code>getfacl</code> per verificare eventuali effetti sulla maschera ACL.

== Quando usare le ACL ==

* ambienti multiutente
* directory condivise con esigenze di accesso diverse
* casi in cui si vogliono evitare permessi eccessivamente ampi (es. <code>777</code>)
* sistemi in cui serve tracciare policy accessi piu rigorose

== Storia delle ACL ==

Timeline essenziale:
* '''Anni 60-70''': concetti ACL gia presenti in sistemi multiutente storici
* '''Anni 90''': sviluppo delle estensioni sicurezza IEEE POSIX 1003.1e
* '''Ottobre 1997''': riferimento tecnico nella bozza POSIX.1e Draft 17
* '''Gennaio 1998''': standardizzazione POSIX.1e ritirata; il modello ACL continua comunque a essere implementato
* '''Novembre 2002''': supporto ACL POSIX incluso nel kernel Linux 2.5.46 (ramo di sviluppo)
* '''Dal 2003 in poi''': adozione ampia nei filesystem Linux usati in produzione

In sintesi, pur senza standard finale ratificato, le ACL sono diventate uno strumento consolidato nell'amministrazione Linux.

== Buone pratiche ==

* applicare ACL solo dove necessario
* documentare le regole nei runbook operativi
* verificare periodicamente configurazioni e ereditarieta
* mantenere un approccio minimo privilegio

== Fonti ==

* [https://man7.org/linux/man-pages/man5/acl.5.html man page acl(5)]
* [https://atc.usenix.org/legacy/events/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/index.html USENIX 2003 - POSIX ACLs on Linux]
== Approfondimento tecnico ACL Linux ==

=== Modello ACL POSIX: entry principali ===

Le ACL POSIX su file/directory usano tipicamente queste entry:
* <code>user::</code> permessi del proprietario
* <code>group::</code> permessi del gruppo proprietario
* <code>other::</code> permessi per tutti gli altri
* <code>user:nome_utente:</code> eccezioni per singolo utente
* <code>group:nome_gruppo:</code> eccezioni per gruppo specifico
* <code>mask::</code> limite massimo effettivo per group e named user/group
* <code>default:...</code> ACL ereditarie (solo su directory)

=== Mask: il punto piu importante da capire ===

La <code>mask</code> limita i permessi effettivi di:
* <code>group::</code>
* tutte le entry <code>user:...</code> nominate
* tutte le entry <code>group:...</code> nominate

Esempio: se una entry dice <code>rwx</code> ma la mask e <code>r-x</code>, il risultato effettivo e <code>r-x</code>.

Per ricreare la mask in base alle entry correnti:

<syntaxhighlight lang="bash">
setfacl -m m::rwx /percorso
# oppure ricalcolo automatico durante setfacl senza -n
</syntaxhighlight>

=== ACL access vs ACL default ===

* '''Access ACL''': controlla accesso attuale al file/directory.
* '''Default ACL''': template ereditato da nuovi oggetti creati dentro una directory.

Impostazione tipica su directory condivisa:

<syntaxhighlight lang="bash">
setfacl -m u:deploy:rwx /srv/shared
setfacl -m d:u:deploy:rwx /srv/shared
</syntaxhighlight>

=== Interazione con chmod e umask ===

* <code>chmod</code> puo modificare la mask ACL, cambiando i permessi effettivi.
* <code>umask</code> influenza i permessi iniziali alla creazione; se esiste una default ACL, quest'ultima partecipa al risultato finale.

Dopo operazioni massive con <code>chmod -R</code>, e consigliato ricontrollare con <code>getfacl</code>.

=== Verifica tecnica rapida ===

<syntaxhighlight lang="bash">
# ACL estese presenti?
ls -l /percorso # il '+' nei permessi indica ACL estese

# dettaglio completo
getfacl /percorso

# proprietario/gruppo/mode classico
stat /percorso
</syntaxhighlight>

=== Policy operativa per directory condivise ===

Pattern comune in produzione:
1. Proprietario applicativo stabile (es. utente servizio)
2. Gruppo di lavoro dedicato
3. ACL nominate solo per eccezioni reali
4. Default ACL sulle sole directory che generano nuovi file
5. Audit periodico e rimozione entry obsolete

=== Backup e ripristino ACL ===

Prima di cambi strutturali conviene salvare ACL:

<syntaxhighlight lang="bash">
getfacl -R /srv/shared > /root/acl-backup.txt
setfacl --restore=/root/acl-backup.txt
</syntaxhighlight>

=== Operazioni utili avanzate ===

<syntaxhighlight lang="bash">
# rimuove ACL estese (mantiene permessi base)
setfacl -b /percorso

# rimuove ACL default
setfacl -k /directory

# modifica ricorsiva
setfacl -R -m u:deploy:rwX /srv/shared
</syntaxhighlight>

Nota su <code>X</code>: assegna execute solo a directory (e file che gia avevano execute), utile per evitare execute indiscriminato sui file normali.

=== Filesystem e compatibilita ===

Sui filesystem Linux moderni (ext4, XFS) ACL sono normalmente disponibili. In ambienti particolari verificare:
* opzioni di mount
* supporto lato filesystem remoto
* differenze con modelli ACL non POSIX (es. NFSv4 ACL)

=== Troubleshooting tipico ===

Se "i permessi sembrano giusti ma non funziona":
1. verificare path completo (permessi su ogni directory padre)
2. controllare <code>mask</code>
3. confermare utente/gruppi reali del processo
4. verificare SELinux/AppArmor se presenti
5. testare accesso con utente reale del servizio

Comando utile per path diagnostics:

<syntaxhighlight lang="bash">
namei -om /percorso/file
</syntaxhighlight>

Tips Linux

2026-03-20T10:26:27Z

Admin: /* ACL Linux */

__NOTOC__
Breve raccolta di riferimenti operativi Linux usati nel contesto GazziNet. La pagina serve come indice rapido per verifiche, troubleshooting e accesso ai sotto-argomenti gia documentati nel wiki.

== Verifiche rapide ==

=== Controllo tempo di risposta sito ===
<pre>
curl -k --connect-timeout 30 --max-time 30 --write-out '%{time_total};%{http_code}\n' http://www.gazzi.net/
</pre>

=== Stato del sistema ===
<pre>
uptime
uname -a
hostnamectl
free -h
df -h
</pre>

=== Processi e servizi ===
<pre>
ps -ef | less
systemctl --failed
systemctl status nome-servizio
journalctl -xeu nome-servizio
</pre>

=== Rete e porte ===
<pre>
ip a
ip r
ss -tulpn
ping -c 4 host_o_ip
curl -I https://host_o_url
</pre>

=== ACL Linux ===

[[ACL_Linux:_storia,_concetti_e_uso_pratico]]

<pre>
https://wiki.gazzi.net/index.php?title=ACL_Linux:_storia,_concetti_e_uso_pratico
</pre>

== Comandi Linux di base ==

=== Navigazione e file ===
<pre>
pwd
ls -la
cd /percorso
mkdir nome-directory
touch file.txt
cp sorgente destinazione
mv vecchio nuovo
rm file.txt
rm -r directory
cat file.txt
less file.txt
head -n 20 file.txt
tail -n 20 file.txt
</pre>

=== Ricerca rapida ===
<pre>
grep -n parola file.txt
grep -R "pattern" /percorso
find /percorso -name "*.log"
find /percorso -type f -mtime -1
which comando
whereis comando
</pre>

=== Permessi e proprieta ===
<pre>
ls -l
chmod 644 file.txt
chmod +x script.sh
chown utente:gruppo file.txt
id
whoami
</pre>

=== Archivi e trasferimento ===
<pre>
tar -czf archivio.tar.gz directory/
tar -xzf archivio.tar.gz
scp file.txt utente@host:/percorso/
rsync -av origine/ destinazione/
</pre>

== Scheda rapida awk ==
awk e utile quando serve estrarre colonne, filtrare righe o fare piccoli report da output testuali senza aprire editor o scrivere script piu lunghi.

=== Sintassi minima ===
<pre>
awk 'condizione { azione }' file
comando | awk 'condizione { azione }'
</pre>

=== Usi tipici ===

==== Stampare colonne specifiche ====
<pre>
ps -ef | awk '{print $1, $2, $8}'
df -h | awk '{print $1, $5, $6}'
</pre>

==== Saltare l'intestazione ====
<pre>
df -h | awk 'NR>1 {print $1, $5, $6}'
</pre>

==== Filtrare righe che contengono una condizione ====
<pre>
ss -tulpn | awk '/LISTEN/ {print $1, $5, $7}'
ps -ef | awk '/nginx/ && !/awk/ {print $2, $8}'
</pre>

==== Usare un separatore diverso ====
<pre>
awk -F: '{print $1, $7}' /etc/passwd
awk -F= '{print $1, $2}' file.conf
</pre>

==== Fare conteggi e somme ====
<pre>
ps -ef | awk 'END {print NR " righe totali"}'
awk '{somma += $1} END {print somma}' numeri.txt
</pre>

==== Mostrare solo righe sopra una soglia ====
<pre>
df -h | awk 'NR>1 && $5+0 >= 80 {print $1, $5, $6}'
free -m | awk '/Mem:/ {print "RAM usata:", $3 " MB"}'
</pre>

==== Formattare output in modo leggibile ====
<pre>
awk -F: '{printf "utente=%s shell=%s
", $1, $7}' /etc/passwd
</pre>

=== Note pratiche su awk ===
* `NR` indica il numero di riga corrente.
* `$1`, `$2`, `$3` indicano la prima, seconda e terza colonna.
* `-F` imposta il separatore di campo.
* In output da comandi di sistema, awk e molto utile insieme a `grep`, `sort`, `uniq` e `xargs`.
* Se l'output contiene spazi irregolari, verificare prima il separatore reale o usare `printf` invece di `print`.

== Troubleshooting operativo ==

=== Log principali ===
<pre>
journalctl -b
journalctl -p err -b
tail -n 100 /var/log/messages
tail -n 100 /var/log/secure
</pre>

=== Spazio disco e inode ===
<pre>
df -h
df -i
du -sh /var/* | sort -h
find /var/log -type f -size +100M -ls
</pre>

=== Mount e multipath ===
Per ambienti con storage esterno o SAN, usare le procedure dedicate prima di eseguire rescan o interventi sui device.

* [[Rescan MultiPath fisica]]

== Pacchetti e repository ==

=== Verifiche base ===
<pre>
rpm -qa | wc -l
rpm -q nome-pacchetto
which comando
</pre>

=== Riferimenti dedicati ===
* [[Differenze tra le principali distribuzioni Linux]]
* [[PIP]]
* [[EPEL Oracle]]

== Accesso remoto e identita ==
* [[GestioneSSHCertificati]]
* [[LDAP]]
* [[RustDesk]]

== Script e analisi ==
* [[CheckScript]]
* [[AnalisiServer]]
* [[Parallelizzazione comandi]]
* [[Deleted Files|Deleted Files]]

== Configurazione e sistema ==
* [[TimeZone]]

== Note d'uso ==
* Preferire sempre verifiche non invasive prima di riavvii o fix correttivi.
* Se il problema coinvolge storage, autenticazione o rete, documentare subito hostname, orario, sintomo e ultimo cambiamento noto.
* Spostare i casi ricorrenti in pagine dedicate invece di far crescere questa pagina senza struttura.

Tips Linux

2026-03-20T10:21:59Z

Admin: /* Verifiche rapide */

__NOTOC__
Breve raccolta di riferimenti operativi Linux usati nel contesto GazziNet. La pagina serve come indice rapido per verifiche, troubleshooting e accesso ai sotto-argomenti gia documentati nel wiki.

== Verifiche rapide ==

=== Controllo tempo di risposta sito ===
<pre>
curl -k --connect-timeout 30 --max-time 30 --write-out '%{time_total};%{http_code}\n' http://www.gazzi.net/
</pre>

=== Stato del sistema ===
<pre>
uptime
uname -a
hostnamectl
free -h
df -h
</pre>

=== Processi e servizi ===
<pre>
ps -ef | less
systemctl --failed
systemctl status nome-servizio
journalctl -xeu nome-servizio
</pre>

=== Rete e porte ===
<pre>
ip a
ip r
ss -tulpn
ping -c 4 host_o_ip
curl -I https://host_o_url
</pre>

=== ACL Linux ===
<pre>
https://wiki.gazzi.net/index.php?title=ACL_Linux:_storia,_concetti_e_uso_pratico
</pre>

== Comandi Linux di base ==

=== Navigazione e file ===
<pre>
pwd
ls -la
cd /percorso
mkdir nome-directory
touch file.txt
cp sorgente destinazione
mv vecchio nuovo
rm file.txt
rm -r directory
cat file.txt
less file.txt
head -n 20 file.txt
tail -n 20 file.txt
</pre>

=== Ricerca rapida ===
<pre>
grep -n parola file.txt
grep -R "pattern" /percorso
find /percorso -name "*.log"
find /percorso -type f -mtime -1
which comando
whereis comando
</pre>

=== Permessi e proprieta ===
<pre>
ls -l
chmod 644 file.txt
chmod +x script.sh
chown utente:gruppo file.txt
id
whoami
</pre>

=== Archivi e trasferimento ===
<pre>
tar -czf archivio.tar.gz directory/
tar -xzf archivio.tar.gz
scp file.txt utente@host:/percorso/
rsync -av origine/ destinazione/
</pre>

== Scheda rapida awk ==
awk e utile quando serve estrarre colonne, filtrare righe o fare piccoli report da output testuali senza aprire editor o scrivere script piu lunghi.

=== Sintassi minima ===
<pre>
awk 'condizione { azione }' file
comando | awk 'condizione { azione }'
</pre>

=== Usi tipici ===

==== Stampare colonne specifiche ====
<pre>
ps -ef | awk '{print $1, $2, $8}'
df -h | awk '{print $1, $5, $6}'
</pre>

==== Saltare l'intestazione ====
<pre>
df -h | awk 'NR>1 {print $1, $5, $6}'
</pre>

==== Filtrare righe che contengono una condizione ====
<pre>
ss -tulpn | awk '/LISTEN/ {print $1, $5, $7}'
ps -ef | awk '/nginx/ && !/awk/ {print $2, $8}'
</pre>

==== Usare un separatore diverso ====
<pre>
awk -F: '{print $1, $7}' /etc/passwd
awk -F= '{print $1, $2}' file.conf
</pre>

==== Fare conteggi e somme ====
<pre>
ps -ef | awk 'END {print NR " righe totali"}'
awk '{somma += $1} END {print somma}' numeri.txt
</pre>

==== Mostrare solo righe sopra una soglia ====
<pre>
df -h | awk 'NR>1 && $5+0 >= 80 {print $1, $5, $6}'
free -m | awk '/Mem:/ {print "RAM usata:", $3 " MB"}'
</pre>

==== Formattare output in modo leggibile ====
<pre>
awk -F: '{printf "utente=%s shell=%s
", $1, $7}' /etc/passwd
</pre>

=== Note pratiche su awk ===
* `NR` indica il numero di riga corrente.
* `$1`, `$2`, `$3` indicano la prima, seconda e terza colonna.
* `-F` imposta il separatore di campo.
* In output da comandi di sistema, awk e molto utile insieme a `grep`, `sort`, `uniq` e `xargs`.
* Se l'output contiene spazi irregolari, verificare prima il separatore reale o usare `printf` invece di `print`.

== Troubleshooting operativo ==

=== Log principali ===
<pre>
journalctl -b
journalctl -p err -b
tail -n 100 /var/log/messages
tail -n 100 /var/log/secure
</pre>

=== Spazio disco e inode ===
<pre>
df -h
df -i
du -sh /var/* | sort -h
find /var/log -type f -size +100M -ls
</pre>

=== Mount e multipath ===
Per ambienti con storage esterno o SAN, usare le procedure dedicate prima di eseguire rescan o interventi sui device.

* [[Rescan MultiPath fisica]]

== Pacchetti e repository ==

=== Verifiche base ===
<pre>
rpm -qa | wc -l
rpm -q nome-pacchetto
which comando
</pre>

=== Riferimenti dedicati ===
* [[Differenze tra le principali distribuzioni Linux]]
* [[PIP]]
* [[EPEL Oracle]]

== Accesso remoto e identita ==
* [[GestioneSSHCertificati]]
* [[LDAP]]
* [[RustDesk]]

== Script e analisi ==
* [[CheckScript]]
* [[AnalisiServer]]
* [[Parallelizzazione comandi]]
* [[Deleted Files|Deleted Files]]

== Configurazione e sistema ==
* [[TimeZone]]

== Note d'uso ==
* Preferire sempre verifiche non invasive prima di riavvii o fix correttivi.
* Se il problema coinvolge storage, autenticazione o rete, documentare subito hostname, orario, sintomo e ultimo cambiamento noto.
* Spostare i casi ricorrenti in pagine dedicate invece di far crescere questa pagina senza struttura.

Tips Linux

2026-03-20T10:18:17Z

Admin: /* Verifiche rapide */

__NOTOC__
Breve raccolta di riferimenti operativi Linux usati nel contesto GazziNet. La pagina serve come indice rapido per verifiche, troubleshooting e accesso ai sotto-argomenti gia documentati nel wiki.

== Verifiche rapide ==

=== Controllo tempo di risposta sito ===
<pre>
curl -k --connect-timeout 30 --max-time 30 --write-out '%{time_total};%{http_code}\n' http://www.gazzi.net/
</pre>

=== Stato del sistema ===
<pre>
uptime
uname -a
hostnamectl
free -h
df -h
</pre>

=== Processi e servizi ===
<pre>
ps -ef | less
systemctl --failed
systemctl status nome-servizio
journalctl -xeu nome-servizio
</pre>

=== Rete e porte ===
<pre>
ip a
ip r
ss -tulpn
ping -c 4 host_o_ip
curl -I https://host_o_url
</pre>

== Comandi Linux di base ==

=== Navigazione e file ===
<pre>
pwd
ls -la
cd /percorso
mkdir nome-directory
touch file.txt
cp sorgente destinazione
mv vecchio nuovo
rm file.txt
rm -r directory
cat file.txt
less file.txt
head -n 20 file.txt
tail -n 20 file.txt
</pre>

=== Ricerca rapida ===
<pre>
grep -n parola file.txt
grep -R "pattern" /percorso
find /percorso -name "*.log"
find /percorso -type f -mtime -1
which comando
whereis comando
</pre>

=== Permessi e proprieta ===
<pre>
ls -l
chmod 644 file.txt
chmod +x script.sh
chown utente:gruppo file.txt
id
whoami
</pre>

=== Archivi e trasferimento ===
<pre>
tar -czf archivio.tar.gz directory/
tar -xzf archivio.tar.gz
scp file.txt utente@host:/percorso/
rsync -av origine/ destinazione/
</pre>

== Scheda rapida awk ==
awk e utile quando serve estrarre colonne, filtrare righe o fare piccoli report da output testuali senza aprire editor o scrivere script piu lunghi.

=== Sintassi minima ===
<pre>
awk 'condizione { azione }' file
comando | awk 'condizione { azione }'
</pre>

=== Usi tipici ===

==== Stampare colonne specifiche ====
<pre>
ps -ef | awk '{print $1, $2, $8}'
df -h | awk '{print $1, $5, $6}'
</pre>

==== Saltare l'intestazione ====
<pre>
df -h | awk 'NR>1 {print $1, $5, $6}'
</pre>

==== Filtrare righe che contengono una condizione ====
<pre>
ss -tulpn | awk '/LISTEN/ {print $1, $5, $7}'
ps -ef | awk '/nginx/ && !/awk/ {print $2, $8}'
</pre>

==== Usare un separatore diverso ====
<pre>
awk -F: '{print $1, $7}' /etc/passwd
awk -F= '{print $1, $2}' file.conf
</pre>

==== Fare conteggi e somme ====
<pre>
ps -ef | awk 'END {print NR " righe totali"}'
awk '{somma += $1} END {print somma}' numeri.txt
</pre>

==== Mostrare solo righe sopra una soglia ====
<pre>
df -h | awk 'NR>1 && $5+0 >= 80 {print $1, $5, $6}'
free -m | awk '/Mem:/ {print "RAM usata:", $3 " MB"}'
</pre>

==== Formattare output in modo leggibile ====
<pre>
awk -F: '{printf "utente=%s shell=%s
", $1, $7}' /etc/passwd
</pre>

=== Note pratiche su awk ===
* `NR` indica il numero di riga corrente.
* `$1`, `$2`, `$3` indicano la prima, seconda e terza colonna.
* `-F` imposta il separatore di campo.
* In output da comandi di sistema, awk e molto utile insieme a `grep`, `sort`, `uniq` e `xargs`.
* Se l'output contiene spazi irregolari, verificare prima il separatore reale o usare `printf` invece di `print`.

== Troubleshooting operativo ==

=== Log principali ===
<pre>
journalctl -b
journalctl -p err -b
tail -n 100 /var/log/messages
tail -n 100 /var/log/secure
</pre>

=== Spazio disco e inode ===
<pre>
df -h
df -i
du -sh /var/* | sort -h
find /var/log -type f -size +100M -ls
</pre>

=== Mount e multipath ===
Per ambienti con storage esterno o SAN, usare le procedure dedicate prima di eseguire rescan o interventi sui device.

* [[Rescan MultiPath fisica]]

== Pacchetti e repository ==

=== Verifiche base ===
<pre>
rpm -qa | wc -l
rpm -q nome-pacchetto
which comando
</pre>

=== Riferimenti dedicati ===
* [[Differenze tra le principali distribuzioni Linux]]
* [[PIP]]
* [[EPEL Oracle]]

== Accesso remoto e identita ==
* [[GestioneSSHCertificati]]
* [[LDAP]]
* [[RustDesk]]

== Script e analisi ==
* [[CheckScript]]
* [[AnalisiServer]]
* [[Parallelizzazione comandi]]
* [[Deleted Files|Deleted Files]]

== Configurazione e sistema ==
* [[TimeZone]]

== Note d'uso ==
* Preferire sempre verifiche non invasive prima di riavvii o fix correttivi.
* Se il problema coinvolge storage, autenticazione o rete, documentare subito hostname, orario, sintomo e ultimo cambiamento noto.
* Spostare i casi ricorrenti in pagine dedicate invece di far crescere questa pagina senza struttura.

TIPS Linux

2026-03-20T10:11:53Z

Admin: Aggiunto link a ACL Linux: storia, concetti e uso pratico

\n* [[ACL Linux: storia, concetti e uso pratico]]

ACL Linux: storia, concetti e uso pratico

2026-03-20T10:08:15Z

Admin: Contenuto reso generico: storia e uso ACL Linux

ACL Linux per WordPress e MediaWiki

2026-03-20T10:08:15Z

Admin: Admin ha spostato la pagina ACL Linux per WordPress e MediaWiki a ACL Linux: storia, concetti e uso pratico: Titolo reso generico su ACL Linux

#RINVIA [[ACL Linux: storia, concetti e uso pratico]]

ACL Linux: storia, concetti e uso pratico

2026-03-20T10:08:15Z

Admin: Admin ha spostato la pagina ACL Linux per WordPress e MediaWiki a ACL Linux: storia, concetti e uso pratico: Titolo reso generico su ACL Linux

== Introduzione ==

Le '''ACL''' (''Access Control List'') in Linux servono quando i permessi classici <code>rwx</code> per ''owner/group/others'' non bastano.

In un server con WordPress e MediaWiki, le ACL permettono di assegnare permessi mirati a utenti tecnici (es. deploy) senza aprire tutto con <code>chmod 777</code>.

== Cosa sono le ACL Linux ==

Le ACL estendono il modello Unix tradizionale con regole aggiuntive per utenti e gruppi specifici.

Comandi base:
* <code>getfacl</code>: legge ACL correnti
* <code>setfacl</code>: aggiunge/modifica/rimuove ACL

== Perche sono utili su WordPress e MediaWiki ==

Scenario tipico: web server con utente <code>www-data</code> e uno o piu utenti operativi.
Senza ACL si finisce spesso tra due estremi:
* permessi troppo stretti (operazioni bloccate)
* permessi troppo larghi (rischio sicurezza)

Con ACL si applica il principio del minimo privilegio.

=== Esempio WordPress ===

Consentire a <code>deploy</code> scrittura solo su uploads:

<syntaxhighlight lang="bash">
sudo setfacl -R -m u:deploy:rwx /var/www/wordpress/wp-content/uploads
sudo setfacl -R -m d:u:deploy:rwx /var/www/wordpress/wp-content/uploads
</syntaxhighlight>

La regola <code>d:</code> imposta ACL di default per file/cartelle creati in futuro.

=== Esempio MediaWiki ===

Gestire upload in <code>images</code> con permessi mirati:

<syntaxhighlight lang="bash">
sudo setfacl -R -m u:deploy:rwx /var/www/mediawiki/images
sudo setfacl -R -m d:u:deploy:rwx /var/www/mediawiki/images
</syntaxhighlight>

=== Verifica ===

<syntaxhighlight lang="bash">
getfacl /var/www/wordpress/wp-content/uploads
getfacl /var/www/mediawiki/images
</syntaxhighlight>

Nota: controllare sempre la voce '''mask''', perche puo limitare i permessi effettivi.

== Buone pratiche ==

* evitare <code>777</code>
* applicare ACL solo dove necessario
* usare ACL di default sulle directory con contenuti dinamici
* verificare ACL durante audit periodici
* documentare le regole operative

== Storia delle ACL: quando sono nate ==

Timeline essenziale:
* '''Anni 60-70''': concetti ACL in sistemi multiutente storici
* '''Anni 90''': sviluppo estensioni sicurezza IEEE POSIX 1003.1e
* '''Ottobre 1997''': riferimento tecnico nella bozza POSIX.1e Draft 17
* '''Gennaio 1998''': processo standard POSIX.1e ritirato, ma il modello ACL continua a essere usato
* '''Novembre 2002''': ACL POSIX integrate nel kernel Linux 2.5.46 (ramo di sviluppo)
* '''Dal 2003 in poi''': adozione ampia sui filesystem Linux server (ext*, XFS, altri)

In pratica, anche senza standard finale ratificato, le ACL Linux sono diventate uno strumento stabile e diffuso.

== Fonti ==

* [https://atc.usenix.org/legacy/events/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/index.html USENIX 2003 - POSIX ACLs on Linux]
* [https://man7.org/linux/man-pages/man5/acl.5.html man page acl(5)]
* [https://lwn.net/Articles/660867/ LWN - contesto evoluzione ACL Linux]

ACL Linux: storia, concetti e uso pratico

2026-03-20T10:04:59Z

Admin: Refinement formattazione articolo ACL Linux

ACL Linux: storia, concetti e uso pratico

2026-03-20T10:03:50Z

Admin: Nuovo articolo: ACL Linux, uso pratico su WordPress/MediaWiki e storia

= ACL Linux per WordPress e MediaWiki: guida pratica e storia =

Le '''ACL''' (''Access Control List'') in Linux servono quando i permessi classici ``rwx`` per ''owner/group/others'' non bastano.

In un server con WordPress e MediaWiki, le ACL permettono di assegnare permessi mirati a utenti tecnici (es. deploy) senza aprire tutto con ``chmod 777``.

== Cosa sono le ACL Linux ==

Le ACL estendono il modello Unix tradizionale con regole aggiuntive per utenti e gruppi specifici.

Comandi base:
* ``getfacl``: legge ACL correnti
* ``setfacl``: aggiunge/modifica/rimuove ACL

== Perche sono utili su WordPress e MediaWiki ==

Scenario tipico: web server con utente ``www-data`` e uno o piu utenti operativi.
Senza ACL si finisce spesso tra due estremi:
* permessi troppo stretti (operazioni bloccate)
* permessi troppo larghi (rischio sicurezza)

Con ACL si applica il principio del minimo privilegio.

=== Esempio WordPress ===

Consentire a ``deploy`` scrittura solo su uploads:

<syntaxhighlight lang="bash">
sudo setfacl -R -m u:deploy:rwx /var/www/wordpress/wp-content/uploads
sudo setfacl -R -m d:u:deploy:rwx /var/www/wordpress/wp-content/uploads
</syntaxhighlight>

La regola ``d:`` imposta ACL di default per file/cartelle creati in futuro.

=== Esempio MediaWiki ===

Gestire upload in ``images`` con permessi mirati:

<syntaxhighlight lang="bash">
sudo setfacl -R -m u:deploy:rwx /var/www/mediawiki/images
sudo setfacl -R -m d:u:deploy:rwx /var/www/mediawiki/images
</syntaxhighlight>

=== Verifica ===

<syntaxhighlight lang="bash">
getfacl /var/www/wordpress/wp-content/uploads
getfacl /var/www/mediawiki/images
</syntaxhighlight>

Nota: controllare sempre la voce '''mask''', perche puo limitare i permessi effettivi.

== Buone pratiche ==

* evitare ``777``
* applicare ACL solo dove necessario
* usare ACL di default sulle directory con contenuti dinamici
* verificare ACL durante audit periodici
* documentare le regole operative

== Storia delle ACL: quando sono nate ==

Timeline essenziale:
* '''Anni 60-70''': concetti ACL in sistemi multiutente storici
* '''Anni 90''': sviluppo estensioni sicurezza IEEE POSIX 1003.1e
* '''Ottobre 1997''': riferimento tecnico nella bozza POSIX.1e Draft 17
* '''Gennaio 1998''': processo standard POSIX.1e ritirato, ma il modello ACL continua a essere usato
* '''Novembre 2002''': ACL POSIX integrate nel kernel Linux 2.5.46 (ramo di sviluppo)
* '''Dal 2003 in poi''': adozione ampia sui filesystem Linux server (ext*, XFS, altri)

In pratica, anche senza standard finale ratificato, le ACL Linux sono diventate uno strumento stabile e diffuso.

== Fonti ==

* [https://atc.usenix.org/legacy/events/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/index.html USENIX 2003 - POSIX ACLs on Linux]
* [https://man7.org/linux/man-pages/man5/acl.5.html man page acl(5)]
* [https://lwn.net/Articles/660867/ LWN - contesto evoluzione ACL Linux]

WSO2

2026-03-19T12:13:04Z

Admin: Aggiunte note sistemistiche, installazione e esempio deployment.toml

__NOTOC__
WSO2 e una piattaforma open source usata per integrazione applicativa, gestione API, autenticazione e orchestrazione di servizi. In pratica serve quando piu sistemi devono parlarsi in modo ordinato, sicuro e tracciabile.

== Cos'e WSO2 ==
WSO2 non e un singolo prodotto isolato, ma una famiglia di componenti software pensati per collegare applicazioni, esporre API e gestire identita digitali.

Gli scenari piu tipici sono:
* integrazione tra applicazioni interne ed esterne
* esposizione controllata di API REST o SOAP
* autenticazione centralizzata e Single Sign-On
* mediazione tra protocolli, formati o sistemi diversi
* controllo traffico, sicurezza e monitoraggio delle chiamate

== Come funziona in pratica ==
L'idea di base e mettere un livello intermedio tra client e servizi backend.

Schema logico tipico:
* un client invia una richiesta
* WSO2 riceve la richiesta
* applica policy, autenticazione o trasformazioni
* inoltra la chiamata al backend corretto
* restituisce la risposta nel formato previsto

Questo permette di non esporre direttamente i sistemi interni e di concentrare in un punto unico logiche come sicurezza, rate limiting, routing, logging e trasformazione dei messaggi.

== Componenti piu comuni ==
=== API Manager ===
Usato per pubblicare, proteggere e governare API. Permette di definire:
* autenticazione
* quote e throttling
* analytics
* catalogo API per sviluppatori

=== Micro Integrator / Integration ===
Usato per creare flussi di integrazione tra sistemi. E utile quando bisogna:
* chiamare piu backend in sequenza
* trasformare payload XML o JSON
* instradare richieste in base a condizioni
* collegare database, servizi HTTP, code o sistemi legacy

=== Identity Server ===
Usato per identity and access management. Serve per:
* Single Sign-On
* OAuth2 / OpenID Connect / SAML
* federazione identita
* gestione utenti, ruoli e policy di accesso

== Dove ha senso usarlo ==
WSO2 ha senso quando l'ambiente non e composto da una sola applicazione semplice, ma da piu sistemi che devono interoperare.

Casi tipici:
* portali che parlano con piu backend
* integrazione tra ERP, CRM, applicazioni web e servizi esterni
* centralizzazione login e autorizzazioni
* pubblicazione API verso partner o applicazioni mobile
* riduzione dell'accoppiamento diretto tra frontend e sistemi interni

== Aspetti tecnici sistemistici ==
Dal punto di vista sistemistico, WSO2 viene installato di solito su:
* VM Linux dedicate
* container Docker
* cluster Kubernetes quando serve scalabilita o gestione cloud-native

Nelle installazioni tradizionali su VM, e comune trovare il prodotto sotto percorsi come:
* `/opt/wso2/wso2mi-4.5.0`
* `/opt/wso2/wso2am-4.5.0`

In pratica il layout tipico comprende:
* binari applicativi del prodotto
* file di configurazione `deployment.toml`
* keystore e truststore del runtime
* log applicativi sotto `repository/logs/`
* esecuzione dietro reverse proxy o load balancer

Operativamente, i punti da presidiare sono:
* runtime Java e relativa memoria JVM
* certificati TLS e truststore
* porte esposte solo dove serve
* utente di servizio dedicato
* rotazione log, backup e monitoraggio
* eventuale database esterno per componenti che lo richiedono, come API Manager

== Dove si configura ==
Per i prodotti piu comuni della famiglia WSO2, il file centrale di configurazione e normalmente `deployment.toml`.

Percorsi tipici:
* `MI_HOME/conf/deployment.toml` per Micro Integrator
* `API-M_HOME/repository/conf/deployment.toml` per API Manager

In produzione e buona pratica:
* non pubblicare direttamente tutte le porte del prodotto verso Internet
* mettere WSO2 dietro Nginx, Apache o un load balancer
* centralizzare TLS, logging e controllo accessi
* tenere separati dev, test e produzione

== Esempio minimo di configurazione ==
Esempio illustrativo per una installazione WSO2 Micro Integrator su VM Linux.

<pre>
# /opt/wso2/wso2mi-4.5.0/conf/deployment.toml

[server]
hostname = "mi01.gazzi.local"

[transport.passthru_http]
listener.enable = true
listener.parameters.port = 8280

[transport.passthru_https]
listener.enable = true
listener.parameters.port = 8243
</pre>

Questo esempio mostra solo il minimo per capire la logica:
* `server.hostname` definisce l'hostname esposto dal runtime
* `transport.passthru_http` abilita il listener HTTP
* `transport.passthru_https` abilita il listener HTTPS

In un ambiente reale si aggiungono anche:
* certificati e truststore
* proxy o load balancer davanti al servizio
* parametri JVM
* configurazioni di sicurezza, autenticazione e database secondo il componente usato

== Note sistemistiche pratiche ==
* Se il ruolo della macchina e integrazione interna, spesso si espone solo il reverse proxy e non tutte le porte native WSO2.
* Se si usa API Manager, documentare sempre database, hostname pubblici, keystore e policy gateway.
* Se si usa Micro Integrator, documentare endpoint backend, sequence, proxy service, retry e timeout.
* Prima di aggiornare versione o certificati, prevedere backup config e finestra di rollback.

== Fonti ufficiali ==
* [https://mi.docs.wso2.com/en/latest/reference/config-catalog-mi/ WSO2 Integrator: MI Configuration Catalog]
* [https://apim.docs.wso2.com/en/latest/reference/config-catalog/ WSO2 API Manager Configuration Catalog]

== Vantaggi ==
* separa integrazione e sicurezza dalla logica applicativa dei singoli sistemi
* aiuta a standardizzare accessi e API
* rende piu semplice monitorare il traffico
* facilita riuso e governance delle integrazioni
* evita di duplicare logiche di autenticazione o mediazione in ogni applicazione

== Limiti e attenzione operativa ==
* introduce complessita rispetto a integrazioni dirette molto semplici
* richiede governance chiara su API, versioni e policy
* se configurato male puo diventare un punto critico unico
* va documentato bene: endpoint, credenziali tecniche, mapping e dipendenze

== In sintesi ==
WSO2 e utile come strato di integrazione e governo dei servizi. Non sostituisce le applicazioni di business, ma le collega, le protegge e ne rende piu ordinata l'esposizione verso utenti, frontend o sistemi esterni.

== Note operative ==
* Se usato in un progetto reale, documentare sempre flussi, endpoint, autenticazione e dipendenze.
* Distinguere chiaramente ambiente dev, test e produzione.
* Se la piattaforma viene adottata in modo stabile, creare pagine dedicate per installazione, deployment, backup e troubleshooting.

Sviluppo

2026-03-19T11:34:41Z

Admin: Aggiunto link a WSO2 nella sezione piattaforme

__NOTOC__
Riferimenti rapidi per sviluppo, progetti e materiale tecnico collegato.

== Progetti ==
* [[GestGazziNet]]
* [[Codex per struttura wiki e pubblicazione articoli]]

== Piattaforme ==
* [[WSO2]]

== Attivita tipiche ==
* raccolta requisiti e definizione obiettivo
* sviluppo script o utility
* verifica output e comportamento
* documentazione tecnica minima a fine attivita

== Note operative ==
* Tenere separati progetto, ambiente, credenziali e documentazione.
* Se un progetto cresce, creare una pagina dedicata con installazione, uso, dipendenze e troubleshooting.
* Evitare di lasciare in questa pagina dettagli troppo specifici di un singolo tool o repository.

WSO2

2026-03-19T11:34:41Z

Admin: Creata scheda introduttiva WSO2

Tips Linux

2026-03-19T10:36:13Z

Admin: Aggiunti comandi Linux di base e scheda rapida awk

__NOTOC__
Breve raccolta di riferimenti operativi Linux usati nel contesto GazziNet. La pagina serve come indice rapido per verifiche, troubleshooting e accesso ai sotto-argomenti gia documentati nel wiki.

== Verifiche rapide ==

=== Controllo tempo di risposta sito ===
<pre>
curl -k --connect-timeout 30 --max-time 30 --write-out '%{time_total};%{http_code}\n' http://www.gazzi.net/
</pre>

=== Stato del sistema ===
<pre>
uptime
uname -a
hostnamectl
free -h
df -h
</pre>

=== Processi e servizi ===
<pre>
ps -ef | less
systemctl --failed
systemctl status nome-servizio
journalctl -xeu nome-servizio
</pre>

=== Rete e porte ===
<pre>
ip a
ip r
ss -tulpn
ping -c 4 host_o_ip
curl -I https://host_o_url
</pre>

== Comandi Linux di base ==

=== Navigazione e file ===
<pre>
pwd
ls -la
cd /percorso
mkdir nome-directory
touch file.txt
cp sorgente destinazione
mv vecchio nuovo
rm file.txt
rm -r directory
cat file.txt
less file.txt
head -n 20 file.txt
tail -n 20 file.txt
</pre>

=== Ricerca rapida ===
<pre>
grep -n parola file.txt
grep -R "pattern" /percorso
find /percorso -name "*.log"
find /percorso -type f -mtime -1
which comando
whereis comando
</pre>

=== Permessi e proprieta ===
<pre>
ls -l
chmod 644 file.txt
chmod +x script.sh
chown utente:gruppo file.txt
id
whoami
</pre>

=== Archivi e trasferimento ===
<pre>
tar -czf archivio.tar.gz directory/
tar -xzf archivio.tar.gz
scp file.txt utente@host:/percorso/
rsync -av origine/ destinazione/
</pre>

== Scheda rapida awk ==
awk e utile quando serve estrarre colonne, filtrare righe o fare piccoli report da output testuali senza aprire editor o scrivere script piu lunghi.

=== Sintassi minima ===
<pre>
awk 'condizione { azione }' file
comando | awk 'condizione { azione }'
</pre>

=== Usi tipici ===

==== Stampare colonne specifiche ====
<pre>
ps -ef | awk '{print $1, $2, $8}'
df -h | awk '{print $1, $5, $6}'
</pre>

==== Saltare l'intestazione ====
<pre>
df -h | awk 'NR>1 {print $1, $5, $6}'
</pre>

==== Filtrare righe che contengono una condizione ====
<pre>
ss -tulpn | awk '/LISTEN/ {print $1, $5, $7}'
ps -ef | awk '/nginx/ && !/awk/ {print $2, $8}'
</pre>

==== Usare un separatore diverso ====
<pre>
awk -F: '{print $1, $7}' /etc/passwd
awk -F= '{print $1, $2}' file.conf
</pre>

==== Fare conteggi e somme ====
<pre>
ps -ef | awk 'END {print NR " righe totali"}'
awk '{somma += $1} END {print somma}' numeri.txt
</pre>

==== Mostrare solo righe sopra una soglia ====
<pre>
df -h | awk 'NR>1 && $5+0 >= 80 {print $1, $5, $6}'
free -m | awk '/Mem:/ {print "RAM usata:", $3 " MB"}'
</pre>

==== Formattare output in modo leggibile ====
<pre>
awk -F: '{printf "utente=%s shell=%s
", $1, $7}' /etc/passwd
</pre>

=== Note pratiche su awk ===
* `NR` indica il numero di riga corrente.
* `$1`, `$2`, `$3` indicano la prima, seconda e terza colonna.
* `-F` imposta il separatore di campo.
* In output da comandi di sistema, awk e molto utile insieme a `grep`, `sort`, `uniq` e `xargs`.
* Se l'output contiene spazi irregolari, verificare prima il separatore reale o usare `printf` invece di `print`.

== Troubleshooting operativo ==

=== Log principali ===
<pre>
journalctl -b
journalctl -p err -b
tail -n 100 /var/log/messages
tail -n 100 /var/log/secure
</pre>

=== Spazio disco e inode ===
<pre>
df -h
df -i
du -sh /var/* | sort -h
find /var/log -type f -size +100M -ls
</pre>

=== Mount e multipath ===
Per ambienti con storage esterno o SAN, usare le procedure dedicate prima di eseguire rescan o interventi sui device.

* [[Rescan MultiPath fisica]]

== Pacchetti e repository ==

=== Verifiche base ===
<pre>
rpm -qa | wc -l
rpm -q nome-pacchetto
which comando
</pre>

=== Riferimenti dedicati ===
* [[Differenze tra le principali distribuzioni Linux]]
* [[PIP]]
* [[EPEL Oracle]]

== Accesso remoto e identita ==
* [[GestioneSSHCertificati]]
* [[LDAP]]
* [[RustDesk]]

== Script e analisi ==
* [[CheckScript]]
* [[AnalisiServer]]
* [[Parallelizzazione comandi]]
* [[Deleted Files|Deleted Files]]

== Configurazione e sistema ==
* [[TimeZone]]

== Note d'uso ==
* Preferire sempre verifiche non invasive prima di riavvii o fix correttivi.
* Se il problema coinvolge storage, autenticazione o rete, documentare subito hostname, orario, sintomo e ultimo cambiamento noto.
* Spostare i casi ricorrenti in pagine dedicate invece di far crescere questa pagina senza struttura.

PROXMOX

2026-03-16T15:59:55Z

Admin: Aggiunti modello CPU e dettagli filesystem/storage

__NOTOC__
= PROXMOX =

Scheda tecnica sintetica aggiornata al 16 marzo 2026, limitata a informazioni sistemistiche (hardware e filesystem/storage).

== Versione piattaforma ==
* Proxmox VE 8.4.16 (release 8.4)

== Hardware nodo ==
* Modello CPU: Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz
* CPU totali: 16 core
* Utilizzo CPU rilevato: ~7.42%
* RAM totale: 31.24 GB
* RAM utilizzata: 11.88 GB

== Filesystem e storage ==
* Disco sistema: 19.50 GB totali, 6.65 GB usati
* Tipologia storage Proxmox configurata: `dir`
* Dischi fisici rilevati: 2 x NVMe Intel SSDPE2MX450G7 da ~450 GB ciascuno

{| class="wikitable"
! Storage !! Tipo !! Stato !! Capacita totale !! Utilizzato !! Contenuti
|-
| local || dir || available || 389.26 GB || 229.76 GB || backup, vztmpl, snippets, rootdir, images, iso
|-
| BCK || dir || available || 2672.64 GB || 553.85 GB || vztmpl, import, backup, iso, images, rootdir, snippets
|}

== Check operativi consigliati ==
* Monitorare trend CPU/RAM e crescita storage.
* Tenere sotto controllo saturazione del disco sistema e dei datastore.
* Verificare periodicamente coerenza tra uso reale e policy di retention backup.

== Riferimenti ==
* [[Tips Virtualizzatori]]

PROXMOX

2026-03-16T15:18:56Z

Admin: Rimossa info host/proxmox01; mantenute solo info sistemistiche HW e filesystem

__NOTOC__
= PROXMOX =

Scheda tecnica sintetica aggiornata al 16 marzo 2026, limitata a informazioni sistemistiche (hardware e filesystem/storage).

== Versione piattaforma ==
* Proxmox VE 8.4.16 (release 8.4)

== Hardware nodo ==
* CPU totali: 16 core
* Utilizzo CPU rilevato: ~7.42%
* RAM totale: 31.24 GB
* RAM utilizzata: 11.88 GB

== Filesystem e storage ==
* Disco sistema: 19.50 GB totali, 6.65 GB usati

{| class="wikitable"
! Storage !! Stato !! Capacita totale !! Utilizzato !! Contenuti
|-
| local || available || 389.26 GB || 229.76 GB || backup, vztmpl, snippets, rootdir, images, iso
|-
| BCK || available || 2672.64 GB || 553.85 GB || vztmpl, import, backup, iso, images, rootdir, snippets
|}

== Check operativi consigliati ==
* Monitorare trend CPU/RAM e crescita storage.
* Tenere sotto controllo saturazione del disco sistema e dei datastore.
* Verificare periodicamente coerenza tra uso reale e policy di retention backup.

== Riferimenti ==
* [[Tips Virtualizzatori]]

PROXMOX

2026-03-16T15:15:21Z

Admin: Aggiornata scheda tecnica Proxmox con dettagli infrastrutturali (senza nomi VM)

__NOTOC__
= PROXMOX =

Scheda tecnica operativa Proxmox VE aggiornata al 16 marzo 2026. Dati raccolti da API del nodo in produzione. Per policy i nomi di VM e CT non sono riportati.

== Contesto piattaforma ==
* Host Proxmox: `proxmox01.gazzi.net:8006`
* Versione: Proxmox VE 8.4.16 (release 8.4)
* Cluster: singolo nodo
* Stato nodo: online

== Risorse nodo ==
* CPU totali: 16 core
* Utilizzo CPU rilevato: ~7.42%
* RAM totale: 31.24 GB
* RAM utilizzata: 11.88 GB
* Disco sistema nodo: 19.50 GB totali, 6.65 GB usati

== Inventario workload (anonimizzato) ==
=== Macchine virtuali (QEMU) ===
* Totali: 8
* Running: 7
* Stopped: 1

=== Container (LXC) ===
* Totali: 4
* Running: 3
* Stopped: 1

Nota: i nomi dei workload sono volutamente omessi.

== Storage ==
{| class="wikitable"
! Storage !! Stato !! Capacita totale !! Utilizzato !! Contenuti
|-
| local || available || 389.26 GB || 229.76 GB || backup, vztmpl, snippets, rootdir, images, iso
|-
| BCK || available || 2672.64 GB || 553.85 GB || vztmpl, import, backup, iso, images, rootdir, snippets
|}

== Rete host ==
=== Bridge ===
* vmbr0: static (bridge principale con gateway)
* vmbr1: manual
* vmbr2: manual

=== Interfacce fisiche ===
* eno1: manual
* eno2: manual
* eno3: manual
* eno4: manual

== Check operativi consigliati ==
* Verificare periodicamente trend CPU/RAM e spazio su local e BCK.
* Monitorare workload stopped per evitare impatti su servizi attesi.
* Separare backup, ISO e immagini per evitare crescita non controllata.
* Documentare ogni modifica infrastrutturale direttamente in questa scheda.

== Riferimenti ==
* [[Tips Virtualizzatori]]
* [https://www.gazzi.net/2026/03/16/struttura-proxmox-gazzinet-nodo-risorse-storage-e-rete-senza-nomi-vm/ Articolo WordPress: Struttura Proxmox GazziNet]

Tips Automation

2026-03-16T10:07:51Z

Admin:

__NOTOC__
= Tips Automation =

Breve raccolta di riferimenti operativi su automazione, scripting e workflow ripetibili usati nel contesto GazziNet.

== Obiettivi tipici ==
* ridurre task manuali ripetitivi
* standardizzare controlli e verifiche
* velocizzare raccolta dati, report e aggiornamenti
* diminuire errori operativi su procedure frequenti

== Approcci comuni ==

=== Shell e script rapidi ===
Adatti a task semplici, verifiche host, raccolta log, sincronizzazioni e controlli periodici.

<pre>
bash script.sh
crontab -e
journalctl -u nome-servizio
</pre>

=== Python ===
Utile quando serve lavorare con API, parsing strutturato, generazione di contenuti, file JSON, flussi condizionali o automazioni piu ricche.

<pre>
python3 script.py
python3 -m venv .venv
pip install -r requirements.txt
</pre>

=== Automazione schedulata ===
Per job periodici usare `cron`, systemd timer o servizi dedicati, evitando task manuali ricorrenti.

<pre>
crontab -l
systemctl list-timers
</pre>

== Casi d'uso pratici ==
* controlli periodici su siti, servizi o endpoint
* generazione e pubblicazione di contenuti
* raccolta inventario hardware o software
* aggiornamento di pagine wiki o sistemi documentali
* export dati da API e report automatici

== Sistemi automatici ==
* [[Tips Automation/Apache Airflow]]

== Buone pratiche ==
* separare credenziali, codice e log
* usare file `.env` o meccanismi equivalenti per configurazione e segreti
* tenere traccia di input, output e stato del job
* preferire automazioni idempotenti, o comunque sicure da rilanciare
* aggiungere sempre una verifica finale del risultato

== Riferimenti collegati ==
* [[CheckScript]]
* [[Parallelizzazione comandi]]
* [[Sviluppo]]
* [[Codex per struttura wiki e pubblicazione articoli]]

== Nota finale ==
L'automazione utile non e quella piu complessa, ma quella che riduce lavoro ripetitivo, mantiene il controllo umano e lascia un risultato verificabile.

Tips Automation

2026-03-16T10:07:15Z

Admin:

__NOTOC__
= Tips Automation =

Breve raccolta di riferimenti operativi su automazione, scripting e workflow ripetibili usati nel contesto GazziNet.

== Obiettivi tipici ==
* ridurre task manuali ripetitivi
* standardizzare controlli e verifiche
* velocizzare raccolta dati, report e aggiornamenti
* diminuire errori operativi su procedure frequenti

== Approcci comuni ==

=== Shell e script rapidi ===
Adatti a task semplici, verifiche host, raccolta log, sincronizzazioni e controlli periodici.

<pre>
bash script.sh
crontab -e
journalctl -u nome-servizio
</pre>

=== Python ===
Utile quando serve lavorare con API, parsing strutturato, generazione di contenuti, file JSON, flussi condizionali o automazioni piu ricche.

<pre>
python3 script.py
python3 -m venv .venv
pip install -r requirements.txt
</pre>

=== Automazione schedulata ===
Per job periodici usare `cron`, systemd timer o servizi dedicati, evitando task manuali ricorrenti.

<pre>
crontab -l
systemctl list-timers
</pre>

== Casi d'uso pratici ==
* controlli periodici su siti, servizi o endpoint
* generazione e pubblicazione di contenuti
* raccolta inventario hardware o software
* aggiornamento di pagine wiki o sistemi documentali
* export dati da API e report automatici

== Sistemi automatici ==
* [[Apache_Airflow]]

== Buone pratiche ==
* separare credenziali, codice e log
* usare file `.env` o meccanismi equivalenti per configurazione e segreti
* tenere traccia di input, output e stato del job
* preferire automazioni idempotenti, o comunque sicure da rilanciare
* aggiungere sempre una verifica finale del risultato

== Riferimenti collegati ==
* [[CheckScript]]
* [[Parallelizzazione comandi]]
* [[Sviluppo]]
* [[Codex per struttura wiki e pubblicazione articoli]]

== Nota finale ==
L'automazione utile non e quella piu complessa, ma quella che riduce lavoro ripetitivo, mantiene il controllo umano e lascia un risultato verificabile.

Tips Automation/Apache Airflow

2026-03-16T09:57:35Z

Admin: Creata guida installazione e configurazione Apache Airflow

__NOTOC__
= Apache Airflow =

Guida pratica per installare e configurare Apache Airflow in ambiente Linux, con esempio rapido su Debian/Ubuntu orientato a uso operativo.

== Prerequisiti ==
* host Linux aggiornato
* Python 3.10+ consigliato
* accesso shell con permessi sudo
* database SQLite (test) o PostgreSQL (produzione)

== Installazione base (standalone, test/lab) ==
<pre>
sudo apt update
sudo apt install -y python3 python3-venv python3-pip

mkdir -p ~/airflow-home
cd ~/airflow-home
python3 -m venv .venv
source .venv/bin/activate

export AIRFLOW_HOME=~/airflow
pip install --upgrade pip setuptools wheel
pip install "apache-airflow==2.10.5" --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.10.5/constraints-3.10.txt"

airflow standalone
</pre>

Dopo il primo avvio, apri la UI su porta 8080 e salva le credenziali mostrate in output.

== Configurazione essenziale ==
=== Variabili ambiente ===
<pre>
export AIRFLOW_HOME=~/airflow
export AIRFLOW__CORE__LOAD_EXAMPLES=False
export AIRFLOW__WEBSERVER__EXPOSE_CONFIG=False
</pre>

=== Percorso DAG ===
Per default i DAG vivono in:
<pre>
$AIRFLOW_HOME/dags
</pre>

=== Esempio DAG minimo ===
Crea file `$AIRFLOW_HOME/dags/hello_airflow.py`:
<pre>
from datetime import datetime
from airflow import DAG
from airflow.operators.bash import BashOperator

with DAG(
dag_id="hello_airflow",
start_date=datetime(2025, 1, 1),
schedule="0 * * * *",
catchup=False,
tags=["tips", "automation"],
):
hello = BashOperator(
task_id="hello",
bash_command="echo 'Airflow operativo su GazziNet'"
)
</pre>

== Avvio come servizio (systemd, esempio) ==
Per ambienti persistenti conviene separare scheduler e webserver.

=== airflow-webserver.service ===
<pre>
[Unit]
Description=Airflow Webserver
After=network.target

[Service]
User=airflow
Group=airflow
Environment="AIRFLOW_HOME=/opt/airflow"
ExecStart=/opt/airflow/.venv/bin/airflow webserver
Restart=always

[Install]
WantedBy=multi-user.target
</pre>

=== airflow-scheduler.service ===
<pre>
[Unit]
Description=Airflow Scheduler
After=network.target

[Service]
User=airflow
Group=airflow
Environment="AIRFLOW_HOME=/opt/airflow"
ExecStart=/opt/airflow/.venv/bin/airflow scheduler
Restart=always

[Install]
WantedBy=multi-user.target
</pre>

== Sicurezza minima consigliata ==
* non esporre Airflow direttamente su internet senza reverse proxy
* usare HTTPS e autenticazione forte
* separare credenziali in variabili/profili dedicati
* limitare permessi utente di servizio

== Troubleshooting rapido ==
* DAG non visibile: controlla path, permessi e parsing nel log scheduler
* task in errore: verifica connessioni, variabili, timeout e retry
* webserver lento: valuta executor e risorse host

== Riferimenti ==
* [https://airflow.apache.org/docs/ Apache Airflow Documentation]
* [[Tips Automation]]

Pagina principale

2026-03-15T17:13:57Z

Admin:

__NOTOC__
<div class="gazzi-wiki-home">
<div class="gazzi-wiki-hero">
<h2>GazziNet Wiki</h2>
<p>Base tecnica interna con appunti operativi, procedure e raccolte tematiche.</p>
</div>

<div class="gazzi-wiki-grid">
<div class="gazzi-wiki-card">
<h3>Sistemi</h3>
<ul>
<li>[[Tips Linux]]</li>
<li>[[Tips Windows]]</li>
<li>[[Tips Database]]</li>
<li>[[Tips Application Server]]</li>
<li>[[Tips Virtualizzatori]]</li>
<li>[[Tips Automation]]</li>
<li>[[Tips Varie]]</li>
</ul>
</div>

<div class="gazzi-wiki-card">
<h3>Rete e sicurezza</h3>
<ul>
<li>[[Sicurezza & Forense]]</li>
<li>[[Operatore]]</li>
</ul>
</div>

<div class="gazzi-wiki-card">
<h3>Dev e piattaforme</h3>
<ul>
<li>[[Container|Container]]</li>
<li>[[Sviluppo]]</li>
<li>[[OBS]]</li>
<li>[[HW]]</li>
<li>[[Codex per struttura wiki e pubblicazione articoli]]</li>
</ul>
</div>

<div class="gazzi-wiki-card">
<h3>Supporto</h3>
<ul>
<li>[[Corso]]</li>
</ul>
</div>
</div>
</div>

Tips Automation

2026-03-15T17:11:54Z

Admin: Create automation tips page

__NOTOC__
= Tips Automation =

Breve raccolta di riferimenti operativi su automazione, scripting e workflow ripetibili usati nel contesto GazziNet.

== Obiettivi tipici ==
* ridurre task manuali ripetitivi
* standardizzare controlli e verifiche
* velocizzare raccolta dati, report e aggiornamenti
* diminuire errori operativi su procedure frequenti

== Approcci comuni ==

=== Shell e script rapidi ===
Adatti a task semplici, verifiche host, raccolta log, sincronizzazioni e controlli periodici.

<pre>
bash script.sh
crontab -e
journalctl -u nome-servizio
</pre>

=== Python ===
Utile quando serve lavorare con API, parsing strutturato, generazione di contenuti, file JSON, flussi condizionali o automazioni piu ricche.

<pre>
python3 script.py
python3 -m venv .venv
pip install -r requirements.txt
</pre>

=== Automazione schedulata ===
Per job periodici usare `cron`, systemd timer o servizi dedicati, evitando task manuali ricorrenti.

<pre>
crontab -l
systemctl list-timers
</pre>

== Casi d'uso pratici ==
* controlli periodici su siti, servizi o endpoint
* generazione e pubblicazione di contenuti
* raccolta inventario hardware o software
* aggiornamento di pagine wiki o sistemi documentali
* export dati da API e report automatici

== Buone pratiche ==
* separare credenziali, codice e log
* usare file `.env` o meccanismi equivalenti per configurazione e segreti
* tenere traccia di input, output e stato del job
* preferire automazioni idempotenti, o comunque sicure da rilanciare
* aggiungere sempre una verifica finale del risultato

== Riferimenti collegati ==
* [[CheckScript]]
* [[Parallelizzazione comandi]]
* [[Sviluppo]]
* [[Codex per struttura wiki e pubblicazione articoli]]

== Nota finale ==
L'automazione utile non e quella piu complessa, ma quella che riduce lavoro ripetitivo, mantiene il controllo umano e lascia un risultato verificabile.

Tips Linux

2026-03-15T17:09:49Z

Admin: Add Linux distributions comparison link under package references

Differenze tra le principali distribuzioni Linux

2026-03-15T17:08:39Z

Admin: Create page comparing major Linux distributions, enterprise and open

__NOTOC__
= Differenze tra le principali distribuzioni Linux =

Questa pagina riassume le differenze pratiche tra alcune delle distribuzioni Linux piu diffuse, distinguendo tra soluzioni enterprise a pagamento, rebuild compatibili e distribuzioni open orientate a desktop, sviluppo o laboratorio.

== Criterio principale di scelta ==
La scelta di una distribuzione non dovrebbe partire solo da preferenze personali, ma da questi fattori:

* supporto commerciale richiesto o meno
* stabilita del ciclo di vita
* compatibilita con software enterprise
* facilita di gestione operativa
* disponibilita di pacchetti recenti
* uso prevalente: server, desktop, sviluppo, laboratorio, container, sicurezza

== Distribuzioni enterprise a pagamento ==

=== Red Hat Enterprise Linux (RHEL) ===
Distribuzione enterprise di riferimento in molti contesti aziendali.

Punti forti:
* supporto commerciale diretto
* ciclo di vita molto lungo
* ampia compatibilita con software certificato
* documentazione e best practice mature

Quando ha senso:
* server critici
* ambienti con vendor che richiedono certificazione ufficiale
* contesti dove il supporto conta piu della flessibilita

=== SUSE Linux Enterprise Server (SLES) ===
Distribuzione enterprise molto usata in alcuni contesti infrastrutturali, SAP e ambienti tradizionali enterprise.

Punti forti:
* supporto commerciale
* buona integrazione in contesti enterprise consolidati
* forte presenza in alcuni scenari specifici come SAP

Quando ha senso:
* ambienti che gia usano SUSE
* contesti con requisiti vendor specifici

== Distribuzioni enterprise open o compatibili ==

=== Rocky Linux ===
Rebuild compatibile con RHEL, molto usata come alternativa open in ambito server.

Punti forti:
* approccio molto vicino a RHEL
* ottima scelta per chi vuole compatibilita enterprise senza costo licenza
* buona prevedibilita operativa

Quando ha senso:
* server interni
* ambienti di laboratorio vicini a RHEL
* sistemi dove servono stabilita e compatibilita, ma non supporto commerciale diretto

=== AlmaLinux ===
Alternativa compatibile con RHEL, orientata a scenari server e hosting.

Punti forti:
* simile a Rocky Linux per obiettivi e posizionamento
* buona adozione in ambienti hosting e infrastrutturali

Quando ha senso:
* casi simili a Rocky Linux
* ambienti dove si vuole restare nel mondo enterprise-compatible open

=== Oracle Linux ===
Distribuzione compatibile con RHEL, con valore aggiunto soprattutto in ecosistemi Oracle.

Punti forti:
* compatibilita elevata con mondo RHEL
* buona scelta in infrastrutture Oracle-centriche
* presenza del kernel UEK per alcuni scenari specifici

Quando ha senso:
* ambienti con database o middleware Oracle
* contesti gia allineati all'ecosistema Oracle

== Distribuzioni open general purpose ==

=== Debian ===
Distribuzione storica molto apprezzata per stabilita, pulizia e approccio conservativo.

Punti forti:
* molto stabile
* ottima base per server e servizi
* grande disponibilita di pacchetti
* forte ecosistema comunitario

Limiti:
* pacchetti spesso meno recenti rispetto a distribuzioni piu veloci

Quando ha senso:
* server affidabili
* infrastrutture semplici e pulite
* ambienti dove la prevedibilita conta piu della novita

=== Ubuntu ===
Distribuzione molto diffusa sia su desktop sia su server, con ampia documentazione e supporto comunitario.

Punti forti:
* enorme disponibilita di guide e pacchetti
* buona esperienza desktop
* molto usata in cloud, sviluppo e container
* versioni LTS comode per ambienti produttivi

Limiti:
* alcune scelte Canonical non piacciono a tutti in ambito tecnico

Quando ha senso:
* desktop tecnici
* server general purpose
* sviluppo, cloud e laboratorio

=== Fedora ===
Distribuzione moderna, molto aggiornata, usata spesso come piattaforma workstation tecnica o laboratorio.

Punti forti:
* pacchetti recenti
* buon supporto a tecnologie moderne
* ottima per sviluppo, desktop tecnico e sperimentazione controllata

Limiti:
* ciclo piu rapido e meno conservativo di Debian o RHEL-like

Quando ha senso:
* workstation
* sviluppo
* desktop Linux moderno
* test di stack recenti

=== openSUSE ===
Distribuzione open con due anime principali: Leap piu stabile e Tumbleweed rolling.

Punti forti:
* buona flessibilita
* strumenti di gestione storicamente apprezzati
* Tumbleweed molto interessante per chi vuole software recente

Quando ha senso:
* utenti che apprezzano ecosistema SUSE
* desktop o laboratorio con esigenze specifiche

== Distribuzioni specialistiche ==

=== Kali Linux ===
Distribuzione orientata a security testing e laboratorio offensivo/difensivo.

Punti forti:
* ampia dotazione di tool security
* utile per test, studio e laboratorio

Quando NON usarla come default:
* server generici
* workstation normali da produzione

=== Arch Linux ===
Distribuzione rolling, molto flessibile e controllabile, ma piu esigente lato gestione.

Punti forti:
* massima flessibilita
* software molto recente
* ottima per chi vuole controllo pieno del sistema

Limiti:
* meno adatta a chi cerca stabilita prevedibile e gestione standardizzata

== Differenza pratica tra pagamento e open ==
La differenza vera non e solo nel software, ma in cio che accompagna il sistema:

* contratti di supporto
* certificazioni vendor
* SLA
* canali ufficiali per patch, audit e supporto
* responsabilita formale del fornitore

In molti casi una distribuzione open compatibile puo andare benissimo tecnicamente. Una distribuzione a pagamento ha senso quando il contesto richiede supporto ufficiale, compliance, certificazioni o interlocutore commerciale.

== Scelte consigliate per scenario ==
* '''Server enterprise con software certificato''': RHEL o SLES
* '''Server interni stabili senza costo licenza''': Rocky Linux o AlmaLinux
* '''Ambienti Oracle-centrici''': Oracle Linux
* '''Server puliti e affidabili general purpose''': Debian
* '''Cloud, laboratorio, sviluppo e desktop tecnico''': Ubuntu o Fedora
* '''Security lab''': Kali Linux
* '''Utenti avanzati che vogliono massimo controllo''': Arch Linux

== Nota finale ==
Non esiste una distribuzione migliore in assoluto. Esiste quella piu adatta al carico, al team, al ciclo di vita atteso e al livello di supporto richiesto.

MediaWiki:Common.js

2026-03-14T11:32:35Z

Admin: Add Gazzi.net link next to wiki home link

MediaWiki:Common.js

2026-03-14T11:28:56Z

Admin: Add global wiki home link at end of every page

Codex per struttura wiki e pubblicazione articoli

2026-03-14T11:26:00Z

Admin: Add section about Codex, ChatGPT and local AI integration

__NOTOC__
= Codex per struttura wiki e pubblicazione articoli =

Questa pagina documenta in modo pratico come il sistema Codex e stato usato per riorganizzare il wiki GazziNet e per supportare la generazione e pubblicazione di articoli sul sito WordPress.

== Contesto d'uso ==
Il sistema e stato usato come agente operativo, non come semplice generatore di testo. Nel lavoro svolto ha avuto tre ruoli principali:

* riorganizzazione del wiki MediaWiki
* supporto alla produzione di articoli tecnici e news sul sito
* automazione di task ripetitivi su tema, struttura, contenuti e pubblicazione

== Come e stato usato sul wiki ==
Sul wiki l'uso principale e stato editoriale e strutturale. In pratica il flusso e stato questo:

# lettura delle pagine esistenti
# verifica del contenuto attuale e del markup reale servito dal sito
# riorganizzazione in sezioni piu leggibili
# normalizzazione di titoli, indici e pagine "Tips"
# correzione di nomi errati, redirect e link interni
# aggiornamento del CSS globale MediaWiki quando necessario per allineare il layout al sito principale

Esempi pratici di attivita fatte:
* pulizia e reimpaginazione della home del wiki
* revisione di pagine come ''Tips Linux'', ''Tips Windows'', ''Tips Database'', ''Tips Application Server'', ''Tips Virtualizzatori''
* correzione della pagina ''Conteiner'' in ''Container'' con redirect esplicito
* miglioramento della documentazione hardware della workstation locale
* ripristino dei controlli di editing quando erano stati nascosti dal CSS

== Come e stato usato per gli articoli ==
Sul sito WordPress Codex e stato usato per:

* generare articoli tecnici in stile coerente con la sezione ''GenDaIa''
* migliorare titoli, excerpt e struttura SEO dei post esistenti
* pubblicare nuovi articoli con categoria corretta
* uniformare template, tipografia e layout tra home, hub e singoli articoli

Il sistema e stato usato sia in modalita manuale che in modalita assistita. In pratica:
* su richiesta venivano creati nuovi articoli
* i testi venivano adattati al taglio tecnico o divulgativo richiesto
* i contenuti venivano poi pubblicati o corretti direttamente via WordPress

== Flusso operativo tipico ==
Un flusso tipico di lavoro con Codex, in questo contesto, e stato:

# richiesta dell'obiettivo
# analisi del contesto reale del sito o del wiki
# lettura dei file o del markup pubblico
# proposta implicita della modifica tramite esecuzione operativa
# verifica del risultato sul frontend o tramite API
# eventuale rifinitura successiva

Questo approccio e stato utile soprattutto quando il problema non era solo nel contenuto, ma nella combinazione di:
* struttura pagina
* stile
* template
* automazione
* pubblicazione

== Integrazione tra Codex, ChatGPT e IA locale ==
Nel lavoro pratico questi tre livelli possono convivere, ma non hanno lo stesso ruolo.

=== Codex ===
Codex viene usato come agente operativo: legge il contesto, controlla file, verifica pagine, modifica contenuti, esegue comandi e aggiorna strutture reali del sito o del wiki.

=== ChatGPT ===
ChatGPT e utile soprattutto come interfaccia conversazionale generale: brainstorming, chiarimenti, riscrittura, sintesi, definizione dell'obiettivo o raffinamento di una richiesta prima dell'esecuzione operativa.

=== IA locale ===
Una IA locale, per esempio tramite Ollama, e utile quando si vuole:
* generare contenuti senza dipendere da un servizio esterno
* fare test rapidi su prompt, classificazione o riscrittura
* mantenere alcuni flussi in ambiente locale
* ridurre costi ricorrenti per task ripetitivi o batch

=== Integrazione pratica ===
Nel contesto GazziNet l'integrazione puo essere vista cosi:
* ChatGPT o interfaccia simile per definire l'obiettivo o iterare sulla richiesta
* Codex per eseguire il lavoro concreto su file, WordPress, MediaWiki e struttura del sistema
* IA locale per automazioni editoriali, generazione assistita o test di pipeline locali

=== Esempio concreto ===
Un flusso concreto puo essere:
# scegliere un tema o una richiesta editoriale
# usare un modello locale per produrre una prima bozza
# usare Codex per controllare struttura, compatibilita, pubblicazione e verifica finale
# usare ChatGPT per rifinire tono, taglio o spiegazione quando serve un passaggio piu discorsivo

=== Vantaggio dell'approccio ibrido ===
L'aspetto interessante non e scegliere un solo sistema, ma usare ogni componente per il compito giusto:
* conversazione e ideazione
* esecuzione tecnica
* generazione locale o automatizzata

== Vantaggi pratici osservati ==
* riduzione del lavoro manuale ripetitivo
* maggiore uniformita tra pagine e sezioni diverse
* velocita nel passare da richiesta a modifica reale
* facilita nel documentare sistemi, procedure e note operative
* supporto concreto alla produzione di articoli e alla manutenzione del sito

== Limiti da tenere presenti ==
* i contenuti generati vanno sempre riletti se riguardano temi sensibili o decisioni operative
* la qualita finale dipende molto dalla precisione delle richieste iniziali
* per automazioni editoriali o pubblicazione automatica servono comunque controlli su credenziali, permessi e qualita del testo
* per temi tecnici complessi resta importante la validazione umana

== Uso sul sito GazziNet ==
Nel contesto GazziNet il sistema e stato quindi usato come supporto tecnico-editoriale per:
* rifare la struttura del wiki
* migliorare la coerenza tra le pagine
* pubblicare articoli tecnici sul sito
* preparare automazioni per la generazione di news e articoli
* documentare il sistema locale, i componenti hardware e le piattaforme usate

== Nota finale ==
Il valore pratico del sistema non sta nel "scrivere da solo", ma nel combinare analisi del contesto, modifica concreta, verifica e documentazione in un unico flusso di lavoro.