Vai al contenuto

Tag: Debian

Pubblicato Lascia un commento per Verificare lo stato di un disco che sembra non supportare S.M.A.R.T.

Il sistema di monitoraggio dischi S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) si applica sia ai vecchi dischi a piatti rotanti che hai nuovi dischi allo stato solido e serve per avere una serie di informazioni sullo stato di salute dei dischi utili a prevederne futuri guasti.

Non si tratta di un sistema recente quindi ci si aspetta che funzioni anche su dischi datati quindi quando mi sono trovato un messaggio che dice che il mio vecchio ASUS Eee PC 900 ha i dischi (SSD tra l'altro) che non supportano SMART sono rimasto perplesso e, difatti, non è vero. Lo supportano.

Per monitorare i parametri SMART si usa smartmontools

apt install smartmontools

Se, come è capitato a me, il tool dice che SMART non è supportato

# smartctl -a /dev/sda1

Device Model: ASUS-PHISON OB SSD
Serial Number: xxxxxxxxxxxxxxx
Firmware Version: TST2.04P
User Capacity: 4,034,838,528 bytes [4.03 GB]
Sector Size: 512 bytes logical/physical
Device is: Not in smartctl database 7.3/5319
ATA Version is: ATA/ATAPI-5 (minor revision not indicated)
SMART support is: Unavailable - device lacks SMART capability.

Bisogna abilitarlo forzandolo

# smartctl -T permissive -s on /dev/sdb1

Il tool smartmontools installa anche un servizio: smartmontools.service che ha bisogno di un piccolo settaggio altrimenti di suo non riesce a capire che in realtà SMART è abilitato e fallisce. Bisogna editare il file di configurazione /etc/smartd.conf e commentare la riga del DEVICESCAN per impedire che cerchi autonomamente i dischi e bisogna aggiungere in coda i device che si vogliono monitorare aggiungendoci la direttiva permissive

/dev/sdb -T permissive
/dev/sda -T permissive

Nel mio caso sono i due sopra. A questo punto basta riavviare il servizio

systemctl restart smartmontools.service

ed è fatta. Ora, per esempio, il file /var/lib/smartmontools/smartd.ASUS_PHISON_SSD-SOQ1482230.ata.state contiene tutte le info SMART. Se le volete in forma più leggibile da un umano potete usare questo comando

smartctl -T permissive -a /dev/sdb1

Pubblicato Lascia un commento per Downgrade forzato di OpenSSL con PHP nuovo

Generalmente quando si aggiorna una Linux ci si aspetta un upgrade e non un downgrade come mi è capitato su delle Debian Buster 10.9 (ma discorso analogo anche su delle Ubuntu LTS).

La causa è di una versione di PHP più aggiornata di quella standard della distribuzione che richiede un downgrade di alcuni pacchetti: niente di grave. Lasciategli fare il downgrade e, al amassimo, controllate che fili tutto liscio.

Se invece non avete installato un PHP più aggiornato allora non vi capiterà di vedervi apparire un downgrade.

Pubblicato Lascia un commento per Cinque gradi in meno di temperatura passando da Debian Stretch a Buster

Quello che vedete sopra è il grafico del monitoraggio della temperatura della scheda madre di un pc portatile (adibito a "server" casalingo) prima, durante e dopo l'upgrade dalla versione Stretch di Debian alla versione Buster.

Si tratta di circa 5 gradi in meno e, per un vecchio portatile (che era rimasto spento alcuni anni), avere una motherboard più fresca è un ottimo sistema per farlo durare ancora alcuni anni.

Ricordatevi di tenere aggiornate le vostre macchine GNU/Linux based: tra i vari vantaggi potreste anche aggiungere, come è capitato a me, una migliorata efficienza energetica.

Pubblicato Lascia un commento per Esporre in maniera sicura un servizio web di casa propria

Se avete l'esigenza di esporre un servizio web di casa vostra e volete farlo in maniera sicura gestendo voi direttamente il tutto per avere il massimo controllo una soluzione è il reverse proxy con autenticazione.

Per fare un esempio potreste voler pubblicare in internet una ip cam di sorveglianza che guarda l'esterno di casa. Il modo più facile è di impostare una regola sul vostro router per aprire la porta della videocamera ma questo presenta almeno un paio di problematiche che portano a sconsigliarlo. La più ovvia è che la videocamera potrebbe non avere l'impostazione per proteggerla con password e non è bello che chiunque possa guardare fuori da casa vostra. Una seconda considerazione è sul grado di sicurezza della vostra ip cam: potrebbe avere dei bug che permettono ad un malintenzionato di prenderne il controllo o, anche se non ne avesse, in futuro potrebbero saltarne fuori e il produttore quasi certamente non pubblicherà un aggiornamento per tappare la falla.

La soluzione reverse proxy con autenticazione è indubbiamente più complessa ma permette di avere il pieno controllo della parte che si pubblica in internet e di poter quindi tenere aggiornati tutti i componenti alle ultime versioni: un sistema correttamente configurato e mantenuto aggiornato è una buona garanzia di sicurezza.

Cosa serve per realizzarlo? Prima indico un breve elenco di oggetti che servono e poi qualche dettaglio sulle configurazioni.

Elenco:

  • Un ip pubblico (niente NAT/Carrier Grade NAT altrimenti non siete raggiungibili dall'esterno)
  • Un router che possa tenere aggiornato un dns dinamico con il vostro ip (o un ip pubblico statico)
  • Un server sempre acceso da adibire a reverse proxy

Per accedere in maniera sicura bisogna esporre il servizio in HTTPS quindi usiamo Let's Encrypt per avere un certificato gratuito per il dns che abbiamo impostato nel nostro router.

Se utilizzare una Debian con Apache come web server allora dovete abilitare i vari moduli proxy e un idea di settaggi del reverse proxy potrebbe essere:

<VirtualHost *:443>
          SSLEngine on
          SSLCertificateFile /etc/letsencrypt/live/tuo.dominio.it/fullchain.pem
          SSLCertificateKeyFile /etc/letsencrypt/live/tuo.dominio.it/privkey.pem
          ServerAdmin tuaemail@example.it
          ServerName tuo.dominio.it
          ProxyPass / http://192.168.1.100/
          ProxyPassReverse / http://192.168.1.100/
          <Proxy *>
                    AuthType Basic
                    AuthName "Restricted Access"
                    AuthUserFile "/cartella/dove/metti/il/file/passwordapache"
                    Require user nomeutente
          </Proxy>
          </VirtualHost>
<VirtualHost *:80>
          ServerName tuo.dominio.it
          Redirect permanent / https://tuo.dominio.it/
</VirtualHost>

Come vedete ho messo un rediret permenent per HTTP (porta 80) in modo che se anche cerchi di accedere senza l'HTTPS vieni rediretto sul sito sicuro. Nella sezione sopra, quella HTTPS (porta 443), ho indicato le posizioni dei certificati, l'ip interno del web server da esporre (da notare che può essere anche solo HTTP ma verso l'esterno viene fatto transitare HTTPS), come AuthName non mettete nulla di personale perché è visibile a chiunque prima dell'autenticazione e poi c'è il file dove salverete utente e password.

Fatto in questo modo potete accedere da internet al vostro servizio web semplicemente con https://tuo.dominio.it/ vi apparirà la richiesta di nome utente e password e tutto quanto transiterà in maniera cifrata.

Pubblicato Lascia un commento per La scheda di rete che cambia nome dopo un upgrade a Debian 9

Durante un upgrade da Debian 8 a Debian 9 potrebbe capitarvi che il server non torni raggiungibile.

Se avete un accesso diretto (tastiera e monitor oppure una console di un server virtuale) usatelo e verificate che sia tutto a posto lato network.

Con un networkctl ottenete la lista delle interfacce di rete e poi verificate che nel file /etc/network/interfaces il nome sia lo stesso: se non lo fosse allora sistematelo e riavviate il network con un systemctl restart networking.service.

Già che ci siete verificate anche che il servizio di rete sia abilitato allo startup controllando cosa dice un systemctl status networking.service perché potrebbe essere disabled.