Il mio router principale OpenWrt gestisce 3 reti separate, ognuna con i propri punti di accesso Wi-Fi, IP e regole firewall:
La rete "STANDARD", su 192.168.1.x, che permette completo accesso sia alla LAN interna che alla WAN esterna (internet)
La rete "THINGS", su 192.168.2.x, che viene usato da tutti i dispositivi IOT e similari, che può accedere solo alla rete stessa, e al router e a un server interno per la gestione domotica, ma a parte queste "eccezioni" non può accedere al resto della rete interne ne alla rete WAN esterna.
La rete "GUEST", un accesso Wi-Fi per gli ospiti che può accedere alla rete esterna "WAN", ma a niente della rete interna.
Fin qui tutto bene: non è compito di questo articolo spiegare come si ottiene la configurazione sopra (che è comunque una configurazione delle reti Wi-Fi piuttosto standard, con propri DHCP e configurazioni specifiche sul firewall).
Il problema è estendere queste 3 reti sugli access point sparsi per casa/giardino in modo da mantenere inalterate tutte le regole. Se un dispositivo IOT che si trova in giardino si connette alla sua Wi-Fi della rete "THINGS" deve mantenere le sue limitazioni sopra, anche se si sta connettendo a un access point (a sua volta connesso via LAN al router principale).
Giusto 2 parole per mia futura memoria. In un nuovo laptop che ho acquistato (con scheda grafica integrata intel) mi sono finalmente deciso a usare wayland.
Ed è andato tutto molto più liscio di quanto mi aspettassi. Ha funzionato tutto al volo, tutto molto fluido e veloce, e uso di RAM molto contenuto (anche se non ho fatto test particolarmente stressanti).
Ci sono solo 2 aspetti che alla fine mi hanno fatto tornare a X11, ma per entrambi credo sia solo questione di tempo:
Avendo la necessità di eseguire PHP via command line (per poter eseguire degli script php) su una macchina batocera, ci si accorge che il problema è più complesso del previsto: batocera nel suo repository di pacchetti non ha la possibilità di installare PHP, e anche facendo delle ricerche non ho trovato nulla a riguardo.
Dopo qualche prova sono riuscito tramite flatpak (supportato nativamente da batocera) e l'ambiente org.freedesktop.Sdk.
Proseguo con gli articoli "fuori norma" (dopo quello su cappotto e pompa di calore) per questo blog, e pubblico i risultati dei primi mesi di fotovoltaico.
Ho montato un impianto a terra da 5,76kWp (16 pannelli da 360W), con orientamento di 40° Sud-Ovest e inclinazione di 25°[Nota1], inverter Solaredge SE5000H, batteria LG Chem RESU10H da 9.3kWh utilizzabili (9.8kWh nominali)
L'impianto è stato montato a metà dicembre 2021, quindi di fatto lo analizzo da Gennaio 2022.
Se durante la procedura di shutdown uno dei job si blocca con la dicitura "A stop job is running..." di solito rimane bloccato per 1 minuto e mezzo! Se capita significa che qualcuno dei task di chiusura ha dei problemi, e quindi la soluzione corretta sarebbe indagare sullo specifico servizio systemd, guardare i log, capire e risolvere il problema. Intanto però abbassare quel minuto e mezzo aiuta!
Basta modificare la voce "DefaultTimeoutStopSec" all'interno del file "/etc/systemd/system.conf", impostandola ad esempio a "10s". Oppure, per evitare di modificare un file di sistema, aggiungere un file "/etc/systemd/user.conf.d/99-stop-fast.conf":
[Manager]
DefaultTimeoutStopSec=5s
In modo analogo, se il problema è durante il boot iniziale, possiamo modificare la voce "DefaultTimeoutStartSec".
Può capitare di voler installare un pacchetto sul proprio sistema non aggiornato da tempo e questo non è possibile perchè ormai il pacchetto stesso o le sue dipendenze, nelle versioni volute dal sistema attualmente installato, non si trovano più nei mirror. La soluzione corretta sarebbe fare un aggiornamento di tutto il sistema, ma questo a volte può far perdere molto più tempo del voluto.
Si può risolvere la cosa velocemente aggiungendo tra i mirror di pacman il repository con l'archivio COMPLETO dei pacchetti di arch linux.
Editiamo il file "/etc/pacman.d/mirrorlist" e aggiungiamo la riga:
Server = https://archive.archlinux.org/packages/.all
Questo funziona se stiamo attenti a non aggiornare mai l'elenco pacchetti. In alternativa, per essere sicuri di evitare problemi anche in questo caso, si può inserire come url un puntatore ai pacchetti alla data specifica di aggiornamento del nostro sistema (possiamo rilevarla guardando il log di pacman).
Server = https://archive.archlinux.org/repos/2023/02/07/$repo/os/$arch
