Assegnare un IP statico in Ubuntu 20.04


Impostare un IP statico, ossia un indirizzo IP che non cambia, in Ubuntu 20.04 non è molto difficile. La modifica può essere fatta via interfaccia grafica nella versione desktop, mentre nella versione server di Ubuntu 20.04 è necessario usare la riga di comando.

Per prima cosa occorre individuare il nome dell’interfaccia di rete alla quale sarà assegnato l’indirizzo IP statico. Per scoprirlo basta usare il comando:

ip a

Nell’output generato dal comando si può vedere che la scheda di rete che ha l’IP 192.168.217.9 (assegnato tramite DHCP ossia dinamicamente) si chiama ens192.

Ora possiamo creare un file di configurazione della scheda di rete.

sudo vi /etc/netplan/50-my-init.yaml

In questo file incolliamo questo testo, opportunamente modificato con i nostri parametri.

network:
    ethernets:
        ens192:
            dhcp4: false
            addresses: [192.168.217.32/24]
            gateway4: 192.168.217.1
            nameservers:
              addresses: [192.168.217.1,8.8.8.8]
    version: 2

ens160 corrisponde al nome dell’interfaccia di rete recuperato col comando ip a. 192.168.217.32 è l’IP statico che abbiamo scelto per la nostra rete, mentre /24 corrisponde alla netmask. Il gateway della rete è specificato dalla voce gateway4.

Si possono aggiungere anche diversi indirizzi IP dei DNS, questi vanno separati con una virgola; per esempio nel caso sopra gli indirizzi dei server DNS sono 192.168.217.1 e 8.8.8.8.

La vecchia configurazione della scheda di rete era in DHCP, quindi spostiamo il vecchio file in modo che esso possa essere recuperato ma non sia attivo:

sudo mv /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml_old

A questo punto è possibile applicare la nuova configurazione usando il comando:

sudo netplan apply

Ora eseguendo il comando ip a potremmo scoprire come la scheda di rete ha un indirizzo IP statico.

Rinnovare un certificato TLS in Tomcat

La procedura per rinnovare il certificato SSL/TLS nel keystore di Tomcat dipende tipicamente dal tipo di certificato o meglio dall’ente certificatore.

Nelle ultime versioni di Tomcat l’uso del keystore, come abbiamo visto negli articoli precedenti, non è più necessario rendendo il rinnovo del certificato più semplice in quanto basta sostituire i file della chiave, della full-chain e riavviare Tomcat.

Tuttavia l’uso del keystore è ancora molto popolare quindi se vi ritrovate a dover rinnovare il certificato è probabile che dobbiate usare il keystore e lo strumento per la gestione: il keytool.

Nel caso di Letsencrypt i passaggi sono piuttosto semplici e automatizzabili: consistono nella cancellazione del certificato dal keystore e dall’importazione del nuovo, più riavvio di Tomcat.

Se invece il vostro certificato viene rilasciato da un rivenditore di certificati, la procedura solitamente prevede:

  • la creazione di un CSR (Certificate Signing Request) a partire dal certificato+chiave memorizzato nel keystore,
  • l’invio del CSR al rivenditore,
  • la verifica dell’identità del richiedente tramite DNS, mail o inserimento di una pagina web ad hoc,
  • la ricezione del certificato,
  • il caricamento del certificato nonchè del certificato root CA e dell’intermedio nel keystore
  • il riavvio di Tomcat.

Per verificare quali certificati sono presenti nel proprio keystore si può usare il comando (dove miokeystore.jks è il nome del proprio keystore):

keytool -list -keystore miokeystore.jks

Nella schermata precedente, ci sono 3 certificati: intermediate e root sono quelli della CA, mentre mydomain è il nostro certificato con chiave (PrivateKeyEntry) di Tomcat.

Facciamo una copia di backup del keystore

cp miokeystore.jks miokeystore.jks_backup

Per procedere alla generazione del CSR abbiamo bisogno della password del keystore e di sapere quale è l’alias che Tomcat usa per il certificato. Nel nostro caso è mydomain, quindi possiamo lanciare questo comando:

keytool -certreq -alias mydomain -file tomcat.csr -keystore miokeystore.jks

Verrà generato un file chiamato tomcat.csr partendo dal certificato con chiave contenuto nel keystore miokeystore.jks; il file tomcat.csr (non contiene la chiave) va passato al rivenditore di certificati.

A questo punto il rivenditore permette di scegliere un metodo di identificazione e autenticazione del proprietario del dominio. Scelto il metodo e verificato il proprietario, allora ci viene fornito il certificato del dominio in formato testuale.

Questo certificato spesso non è sufficiente da solo ma è necessario aggiungere nel keystore tutta la catena dei certificati, iniziando con il certificato della root CA, poi quello intermedio e poi il certificato del dominio.

Supponendo di dover sostituire il root CA e l’intermedio già presente nel keystore, bisogna eliminarli entrambi (solo se non ci sono altri certificati nel keystore che li usando, ovviamente).

I vecchi certificati intermediate e root possono essere eliminati:

keytool -delete -alias intermediate -keystore miokeystore.jks
keytool -delete -alias root -keystore miokeystore.jks

Non va cancellato il certificato con chiave mydomain.

I nuovi certificato root e intermediate che sono stati scaricati dal sito del rivenditore o della certification authority possono essere importati così:

keytool -import -trustcacerts -alias root -file DigiCert_Global_G2.pem -keystore miokeystore.jks

Dove DigiCert_Global_G2.pem è il certificato della Root CA.

keytool -import -trustcacerts -alias intermediate -file DigiCertGlobalCAG2.pem -keystore miokeystore.jks

Dove DigiCertGlobalCAG2.pem è il certificato della Intermediate CA.

Importiamo ora il certificato ricevuto dal rivenditore, supponiamo che il certificato sia contenuto nel file mydomain.txt

keytool -import -alias mydomain -file mydomain.txt -keystore miokeystore.jks

Così facendo il nuovo certificato verrà unito alla chiave già presente nel keystore.

Per far ripartire Tomcat su Debian o CentOS

systemctl restart tomcat9

Se l’importazione è stata effettuata in maniera corretta, il riavvio di Tomcat sarà completato con successo, altrimenti è possible che Tomcat non riesca a ripartire.

In tal caso, è possibile ripristinare il keystore originale (antecedente alle modifiche) e analizzare cosa è andato storto.

Una delle verifiche da fare è la corretta importazione del certificato con chiave. Infatti il certificato senza chiave non permette la partenza di Tomcat. Per verificare se c’è il certificato con chiave, basta cercare nell’output della lista se c’è PrivateKeyEntry.

keytool -list -keystore miokeystore.jks

NXNSAttack: Scoperta nuova vulnerabilità che sfrutta il meccanismo di delega DNS

La falla consente a un utente malintenzionato di forzare qualsiasi DNS resolver ricorsivo a inviare un numero elevato di query (Distributed denial-of-service) al server DNS autorevole della vittima.

L’aspetto che viene sfruttato è la delega glueless, dove un glue record corrisponde agli indirizzi IP di un name server (ossia un DNS server).
Petr Špa?ek scrive ul blog di CZ.NIC che
“Questa è la cosiddetta delega glueless, ovvero una delega che contiene solo nomi di server DNS autorevoli (a.iana-servers.net. oppure b.iana-servers.net.), ma non contiene i loro indirizzi IP.
Ovviamente DNS risolutore non può inviare una query a “nome”, quindi il risolutore deve prima ottenere l’indirizzo IPv4 o IPv6 del server autorevole “a.iana-servers.net”. o “b.iana-servers.net.” e solo allora può continuare a risolvere la query originale “esempio.com. A”. Questa delega glueless è il principio base di NXNSAttack: il server compromesso semplicemente restituisce la delega con nomi di server falsi (casuali) che puntano al dominio DNS della vittima, costringendo così il risolutore per generare query verso i server DNS delle vittime (in un inutile tentativo di risolvere falsi nomi di server autorevoli).
Molteplici i server DNS affetti da questo problema tra cui Bind, PowerDNS, i DNS di Cloudflare, Google, Amazon, Microsoft.

Si consiglia di aggiornare al più presto i propri pacchetti sulle varie distribuzioni Linux. Rimanente in attesa per quelle che non è ancora disponibile l’aggiornamento.

Dettagli nel documento: http://www.nxnsattack.com/dns-ns-paper.pdf

Ridurre la dimensione dei file di log di Journal

Systemd, il gestore di tutto in Linux, è uno dei servizi fondamentali dei sistemi operativi del piguino usciti negli ultimi 6-7 anni.
Ha gradualmente soppiantato SysVinit, il tradizionale gestore di avvio/spegnimento dei deamon, e ha anche preso posto di altri tool integrandosi nel sistema in maniera alquanto invasiva.

Journal è un componente di systemd che si occupa principalmente del logging raccogliendo messaggi dal kernel, boot, syslog e altri servizi. Il deamon che governa journal è systemd-journald, il quale raccoglie i messaggi e li memorizza nei suoi “registri” (/run/log/journal, non persistente al riavvio) e in alcuni file di log.

Questi ultimi file di log si trovano nella cartella journal della classica /var/log. La cosa particolare è che questi file di log non dovrebbero essere riciclati dal classico logrotate ma dovrebbero essere mantenuti dal deamon systemd-journald che si dovrebbe occupare della cancellazione dei dati più vecchi.

La mancanza della cartella /var/log/journal implica che non vengono manutenuti file di log persistenti, a meno che nel file di configurazione venga indicato un percorso alternativo.

Il file di configurazione principale è /etc/systemd/journald.conf ed eventuali altri in /etc/systemd/journald.conf.d/, in questi file si possono modificare alcuni parametri tra cui compressione e tempo di conservazione.

La mancanza del file di configurazione implica l’uso delle opzioni di default, tra cui l’attivazione della compressione, un file per utente, l’occupazione del massimo del 10% dello spazio disponibile nel filesystem dove i dati sono mantenuti persistenti e il 15% dello spazio del filesystem dove i dati non persistenti.

Quest’ultimo aspetto è interessante, in quanto se abbiamo una partizione /var/log molto piccola es. 5 GB, journal manterrà al massimo 500MB. Tuttavia se sia /run sia /var/log sono sullo stesso filesystem è possibile che l’uso del disco da parte di journal arrivi a raggiungere il 25% (10% + 15%), prima di essere recuperato.

Per vedere quanto spazio su disco occupa il file di log si può usare il comando:

journalctl --disk-usage

Per ridurre rapidamente le dimensioni su disco ci sono due vie la prima quella di decidere di mantenere soltanto un dato numero di file di journal, per cui verranno cancellati i file più vecchi ad eccezione dei tot più recenti.
Lanciando per esempio il comando:

journalctl --vacuum-files=4

Conserveremo esclusivamente gli ultimi 4 file.

Se il comando sopra non fosse disponibile, per ridurre le dimensioni del file di log si può usare anche il comando:

journalctl --vacuum-size=100M

dove 100M sono le dimensioni in cui il file di log deve stare ossia verranno scartiti tutti i log più vecchi finchè non si raggiunge uno spazio di disco usato da Jorunal di 100M (o meno).

Come attivare HTTPS su Tomcat

In questa guida vediamo come configurare il supporto HTTPS, tramite Transport Layer Security (TLS), su Tomcat.
Tomcat sfrutta le tecnologie Java sottostanti per fornire il supporto alle connessioni sicure e per questo motivo la configurazione di TLS su Tomcat non è così immediata come per il classico Apache HTTPD.

Questo articolo fa riferimento alla versione Tomcat 9, per dettagli sulla configurazione potete leggere questi due articoli: Installare Tomcat su Ubuntu 20.04 Focal Fossa e installare Tomcat su CentOS 8.

Nel resto dell’articolo supporremo che il nostro server Tomcat abbia come dominio tomcat.example.com, per cui nei successivi comandi dovrete sostituire tomcat.example.com con il nome del vostro dominio.

Abbiamo usato Letsencrypt per generare un certificato TLS gratuito da usare per il nostro Tomcat.
Per installare Letsencrypt su Ubuntu usare il comando:

sudo apt install letsencrypt

Per generare il certificato, dopo aver installato Letsencrypt:

certbot certonly --standalone -d tomcat.example.com

Attendiamo la fine del comando precedente e convertiamo il certificato e la chiave in un formato p12 utilizzabile per il java keytool. Il tipo di file p12 con certificato full chain e chiave, ci consente di fare un singolo inserimento del keystore. L’alternativa è quella di aggregare chiave e certificato del dominio in un file da aggiungere al keystore. Poi sia il certificato intermedio sia quello root vanno anche essi importati in 2 passaggi nel keystore; invece con il file p12, l’importazione è una sola.

Detto questo, aggreghiamo i vari componenti per creare un file p12:

openssl pkcs12 -export -out /tmp/tomcat.example.com_fullchain_and_key.p12 \
-in /etc/letsencrypt/live/tomcat.example.com/fullchain.pem \
-inkey /etc/letsencrypt/live/tomcat.example.com/privkey.pem \
-name tomcat

A questo punto ci viene chiesta una password, scegliamo per esempio 58dssqPo2Muw
La password ci servirà successivamente.
Ora lanciamo il seguente comando, avendo cura di sostituire 58dssqPo2Muw con la password da voi scelta e tomcat.example.com con il vostro dominio.

keytool -importkeystore \
-deststorepass 58dssqPo2Muw -destkeypass 58dssqPo2Muw \
-destkeystore /tmp/tomcat.example.com.jks \
-srckeystore /tmp/tomcat.example.com_fullchain_and_key.p12 \
-srcstoretype PKCS12 -srcstorepass 58dssqPo2Muw \
-alias tomcat

Copiamo il file /tmp/tomcat.example.com.jks in una nuova cartella chiamata tls che si troverà in /usr/local/tomcat9/

mkdir /usr/local/tomcat9/tls/
cp /tmp/tomcat.example.com.jks /usr/local/tomcat9/tls/

Aprite il file di configurazione di Tomcat che si chiama server.xml e si trova nella cartella conf dell’installazione di Tomcat. Se avete seguito i tutorial precedenti si dovrebbe trovare in /usr/local/tomcat9/conf/server.xml

nano /usr/local/tomcat9/conf/server.xml

Inserite il seguente testo avendo cura di sostituire la password e il dominio.

<Connector
           protocol="org.apache.coyote.http11.Http11NioProtocol"
           port="8443" maxThreads="200"
           scheme="https" secure="true" SSLEnabled="true"
           keystoreFile="tls/tomcat.example.com.jks"
           keystorePass="58dssqPo2Muw"
           clientAuth="false" sslProtocol="TLS"/>

Ora riavviate Tomcat con il comando

systemctl restart tomcat9

Ora se andrete sull’indirizzo
https://tomcat.example.com:8443 dovrà compare la solita pagina di inizio di Tomcat.

Se avete problemi vi consiglio di consultare il file /usr/local/tomcat9/logs/catalina.out per capire quale è l’errore che ha impedito l’attivazione corretta di https su Tomcat.

Per maggiori dettagli, la guida di configurazione è indicata: http://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html

Installare Tomcat su Ubuntu 20.04 Focal Fossa

In un precendente tutorial abbiamo visto come installare Tomcat su CentOS 8, ora vediamo come installare il popolare application server su Ubuntu 20.04 Focal Fossa.

Dopo aver installato Ubuntu 20.04, versione server, è sufficiente installare il Java JDK versione 8 sul server.

sudo apt install openjdk-8-jdk

Create un utente chiamato tomcat9 e create una cartella per ospitare i file di Tomcat.

sudo useradd -r tomcat9
mkdir /usr/local/tomcat9

Poi scaricate da Internet l’ultima versione di Tomcat 9 per sistemi GNU/Linux, usando questo comando:

wget http://mirror.nohup.it/apache/tomcat/tomcat-9/v9.0.34/bin/apache-tomcat-9.0.34.tar.gz -O apache-tomcat-9.0.34.tar.gz

Qualora il comando vi restituisca un errore, recatevi alla pagina http://mirror.nohup.it/apache/tomcat/tomcat-9/v9.0.34/bin/ e selezionate una versione più recente es. nel caso di una futura 9.0.35 l’url può essere trasformato così: wget http://mirror.nohup.it/apache/tomcat/tomcat-9/v9.0.35/bin/apache-tomcat-9.0.35.tar.gz -O apache-tomcat-9.0.35.tar.gz

Scompattiamo l’archivio di Tomcat nella cartella predisposta prima.

tar zxvf apache-tomcat-9.0.*.tar.gz --strip-component=1 -C /usr/local/tomcat9

Facciamo sì che tutti i file di Tomcat nella cartella /usr/local/tomcat9 siano di proprietà dell’utente tomcat9

sudo chown -R tomcat9:tomcat9 /usr/local/tomcat9

Per poter avviare Tomcat in maniera automatica è opportuno creare uno script per systemd. Creiamo quindi un file di tipo service:

nano /etc/systemd/system/tomcat9.service

In questo file incolliamo il seguente testo:

[Unit]
 Description=Apache Tomcat Server
 After=syslog.target network.target

 [Service]
 Type=forking
 User=tomcat9
 Group=tomcat9

 Environment=CATALINA_PID=/usr/local/tomcat9/temp/tomcat.pid
 Environment=CATALINA_HOME=/usr/local/tomcat9
 Environment=CATALINA_BASE=/usr/local/tomcat9

 ExecStart=/usr/local/tomcat9/bin/catalina.sh start
 ExecStop=/usr/local/tomcat9/bin/catalina.sh stop

 RestartSec=10
 Restart=always

 [Install]
 WantedBy=multi-user.target

Salvato il file è necessario ricaricare la lista dei servizi gestiti da systemd, lo si può fare col comando:

sudo systemctl daemon-reload

Per abilitare l’avvio automatico di Tomcat alla partenza del sistema operativo lanciare questo comando:

sudo systemctl enable tomcat9.service

Per lanciare Tomcat usare invece quest’altro comando:

sudo systemctl start tomcat9.service

A questo punto è possibile collegarsi a Tomcat usando l’indirizzo http://localhost:8080 dal server locale.

Abilitare l’accesso a Tomcat dall’esterno

Di default, Tomcat non consente l’accesso da IP esterni al server di installazione. Questo per motivi di sicurezza.

Per consentire l’accesso dall’esterno, bisogna modificare il file /usr/local/tomcat9/conf/server.xml aggiungendo nella sezione Connector port=”8080″, la coppia opzione-valore address=”0.0.0.0″

A questo punto occorre ricaricare (o riavviare) Tomcat.

sudo systemctl reload tomcat9.service

Ora ci si può collegare dall’esterno, nell’esempio l’IP del server Ubuntu con Tomcat 9 è 192.168.217.7:

Mini-guida alle share NFS

Per condividere una cartella con un altro sistema Linux si può usare il protocollo NFS (versione 4 o 3). Sul server dove la cartella viene condivisa va installato e attivato il servizio nfs-server.

Nel file di configurazione della cartella condivisa che è /etc/exports va inserita una riga così:

/export 192.168.1.14(rw,sync,no_subtree_check,fsid=3587)

dove /export è la cartella da condividere e 192.168.1.14 è l’ip del sistema client, rw significa in modalità read&write, fsid è un numero casuale indicativamente sul migliaio, mai uguale per altre voci nel file exports.

La cartella /export deve esistere. I permessi di questa cartella sono uno degli aspetti da considerare perchè la possono rendere inaccedibile dal client: se gli UID e GID dell’utente, di un eventuale processo che scrive dentro file, che ci accedono da remoto concidono con quelli del proprietario della cartella, non è necessario cambiarli altrimenti sì.
Nell’ultimo caso un banale chmod 777 /export potrebbe essere sufficiente.

Per esportare (ossia esporre) la share sul server nfs bisogna usare il comando:

exportfs -ra

Sul sistema client va montato su una cartella usando queste opzioni nel file /etc/fstab

192.168.1.12:/export /mnt/export nfs nfsvers=4,rw 0 0

dove 192.168.1.12 è l’IP server server NFS, nfsvers=4 è la versione di nfs, in questo caso v4. Può essere cambiata con nfsvers=3 per usare NFSv3. /mnt/export è la cartella dove sarà montata la share (deve esistere).

Per verificare la visibilità della share sul client:

showmount -e 192.168.1.12

Per verificare la corretta esportazione della share sul server nfs:

showmount -e localhost

Red Hat / CentOS 7 con GUI minima

Vi sarà capitato di dover installare un sistema operativo CentOS, oppure Red Hat o Oracle Linux, con numero minimo di pacchetti per evitare di installare programmi e funzionalità inutili.
A volte invece capita che vi chiedano di installare la GUI e la GUI, di suo, comporta l’installazione di centinaia di pacchetti che mai userete.
Eccovi un metodo per installare Red Hat o CentOS (anche Oracle Linux e cloni) con la GUI minimale.
La prima cosa è quella di installare il sistema operativo scegliendo il profilo Minimal.
Al termine dell’installazione collegarsi e installare i seguenti pacchetti:

yum groupinstall "X Window System" "Fonts"
yum install gnome-classic-session gnome-terminal nautilus-open-terminal control-center liberation-mono-fonts

Poi per impostare l’avvio della GUI all’avvio del sistema:

sysconfig set-default graphical.target

Il gruppo di pacchetti che sarà installato con “X Window System” comprende l’insieme ridotto per far funzionare il server X, mentre il gruppo “Fonts” benchè non strettamente necessario permette di non avere problemi di visualizzazione delle finestre e di vari programmi installati perchè installa uno svariato numero di caratteri.
Infine con il comando install di gnome-classic-session gnome-terminal nautilus-open-terminal control-center liberation-mono-fonts permette di installare Gnome in maniera semplice ed essenziale.

Installare NextCloud e abilitare la videoconferenza open source

NextCloud mette a disposizione una piattaforma per la videoconferenza, chiamata NextCloud Talk, molto utile in questi giorni. Dunque vediamo come installare NextCloud su un virtual private server e come configurare NextCloud Talk.

Il nostro VPS ha un disco di 10 GB e come sistema operativo Debian 10 Buster.

La prima cosa da fare è installare un ambiente LAMP (Linux, Apache, MySQL e PHP). Partiamo con MySQL.

Scarichiamo il pacchetto ufficiale che contiene i repository community di MySQL.

wget https://dev.mysql.com/get/mysql-apt-config_0.8.15-1_all.deb

Installiamo il pacchetto

dpkg -i mysql-apt-config_0.8.15-1_all.deb

Durante la configurazione viene chiesto di scegliere quale versione di MySQL usare, scegliamo la 5.7 (non la 8)

Aggiorniamo la cache dei pacchetti e poi il server e client MySQL.

apt update
apt install mysql-server mysql-client

Durante l’installazione viene chiesto di inserire una password quella che sarà assegnata all’utente root. Inseriamone una e annotiamocela.

Lanciamo poi la riga di comando di gestione di mysql, inserendo poi la password di root

mysql -u root -p

Digitiamo questo codice, avendo cura di scegliere una password difficile da indovinare al posto di tNl2wcZRgcl, infatti questa è la password dell’utente usernextcloud che viene usato da nextcloud per collegarsi al database dbnextcloud.

CREATE DATABASE dbnextcloud;
GRANT ALL PRIVILEGES ON dbnextcloud.* TO 'usernextcloud'@'localhost' IDENTIFIED BY 'tNl2wcZRgcl';
flush privileges;
exit;

Ora possiamo installare i componenti di PHP.

apt install php-cli php-fpm php-json php-pdo php-mysql php-zip php-gd php-mbstring php-curl php-xml php-pear php-bcmath

Dopo aver installato i componenti di PHP, si possono installare quelli di Apache.

apt install libapache2-mod-php apache2 apache2-utils

Bene. Possiamo scaricare l’archivio nextcloud-18.0.3.tar.bz2 dal sito di nextcloud contenente l’ultima versione, poi scompattare l’archivio e assegnare i permessi sui file.

cd /var/www/html
wget https://download.nextcloud.com/server/releases/nextcloud-18.0.3.tar.bz2
tar xjvf nextcloud-18.0.3.tar.bz2 --strip-component=1
rm -f nextcloud-18.0.3.tar.bz2
chown -R www-data:www-data /var/www/html

Per garantire una maggior sicurezza, è bene abilitare il protocollo HTTPS per l’accesso e l’uso di nextcloud. Per fare questo useremo i certificati generati gratuitamente da Letsencrypt. Per usare Letsencrypt è necessario che il nome del vostro dominio nextcloud punti all’indirizzo IP del vostro VPS.

Per esempio il nostro dominio è nextcloud.pyroplastic.stream il record A corrispondente è uguale all’IP del nostro VPS.

Dobbiamo abilitare il supporto HTTPS per Apache, perchè di default non lo è.

a2enmod ssl

Installiamo Letsencrypt.

apt install letsencrypt

Apriamo il file /etc/apache2/sites-available/default-ssl.conf e commentiamo (ossia anteponiamo un cancelletto) le righe con SSLCertificateFile e SSLCertificateKeyFile, sostituendole con quelle qui sotto.

SSLCertificateFile /etc/ssl/certs/tls.cert
SSLCertificateKeyFile /etc/ssl/private/tls.key
SSLCACertificateFile /etc/ssl/certs/tls-ca-bundle.crt

Ora generiamo il certificato con il tool letsencrypt dove nextcloud.pyroplastic.stream è il nome del vostro dominio.

letsencrypt certonly --webroot -w /var/www/html -d nextcloud.pyroplastic.stream

A questo punto sono stati generati dei file con chiave, certificato e chain. Creiamo dei link simbolici, avendo cura di sostituire nei seguenti comandi nextcloud.pyroplastic.stream con il vostro dominio.

ln -s /etc/letsencrypt/live/nextcloud.pyroplastic.stream/cert.pem /etc/ssl/certs/tls.cert
ln -s /etc/letsencrypt/live/nextcloud.pyroplastic.stream/privkey.pem /etc/ssl/private/tls.key
ln -s /etc/letsencrypt/live/nextcloud.pyroplastic.stream/chain.pem /etc/ssl/certs/tls-ca-bundle.crt

Abilitiamo la configurazione HTTPS appena modificata lanciando questo comando e riavviamo apache.

a2ensite default-ssl.conf
systemctl restart apache2

Siamo arrivati alla fine della configurazione via riga di comando. Ora puntando all’url https://nextcloud.pyroplastic.stream e configurare nextcloud.

Nella parte sotto della pagina, bisogna inserire i valori relativi al database MySQL che abbiamo configurato all’inizio.

Terminata la configurazione, parte lo scaricamento di alcune funzionalità. Talk è già installato ma non è attivo di default per cui è necessario abilitarlo. Per fare ciò andiamo nella sezione dell’aggiunta delle applicazioni e fra quelle sociali cerchiamo Talk.

Clicchiamo su abilita.

Dopo pochi secondi nel menù in alto a sinistra appare Parla. Cliccandoci su, e poi cliccando su un contatto es. Rosa, si aprirà la chat.

Per fare una call, è sufficiente premere sul pulsante Inizia Chiamata, verrà chiesto di poter accedere al microfono e alla webcam.

Sul sito di nextcloud è possibile scaricare il client Windows, Linux e Android per poter usare NextCloud (e anche Talk): https://nextcloud.com/install/

E’ possibile acquistare una VPS a 11,80 euro l’anno con 1536 MB di RAM e 10 GB di disco su AlexHost.com, scegliendo il piano PROMO KVM VDS 0.99/mo con pagamento annuale.

Clear Linux

Quanti di voi avevano mai sentito parlare di Clear Linux prima di qualche giorno fa?
Immagino pochi, ebbene Clear Linux o meglio Clear Linux * OS è una distribuzione GNU/Linux prodotta da Intel (il colosso delle CPU) che dà il suo meglio su CPU AMD. Grazie all’ottima gestione delle risorse è emerso che Clear Linux è in grado di offrire performance di calcolo migliori su sistemi AMD con molti core rispetto a quanto faccia Windows 10.

Dunque mi è venuta la curiosità di provare questa distribuzione, installandola anche su un virtual machine.

Desktop di ClearLinux, installabile come bundle ulteriore

Installazione di Clear Linux

Clear Linux richiede EFI, non funziona con il tradizionale BIOS, per cui è necessario possedere un PC con supporto ai 64 bit, EFI (UEFI) abilitato e almeno 2 GB di RAM. Probabilmente ogni PC o portatile prodotto negli ultimi 8 anni dovrebbe essere in grado di disporre tranquillamente di tali risorse.

Dopo aver scaricato la ISO e avviato la virtual machine è facile procedere all’installazione del sistema usando il comando clr-installer, così parte un installer alquanto spartano che ricorda molto i sistemi operativi della fine degli anni ’90, primi anni del nostro secolo 🙂

Muovendosi con le frecce o il tasto tab è possibile configurare la lingua, il layout della tastiera.

Le unice lingue disponibili sono l’inglese (statunitense), lo spagnolo (messicano) e il cinese mandarino; poca scelta.

Per fortuna è possibile scegliere almeno il layout della tastiera (it).

L’altra cosa importante è la selezione del disco dove installare il sistema operativo. Nel menù principale scegliere la voce “Configure installation media” e poi, se non ci sono esigenze particolari, direi di impostare “Safe installation”, ottimo compromesso per una virtual machine di prova.

Per poter installare il sistema bisogna aggiungere un utente (di tipo admin) e configurare anche la telemetria.

Nel menù con le impostazioni avanzate è possibile configurare una scheda di rete, utile per comunicare col modo esterno. Essa viene in automatico impostata in modo da accettare un indirizzo IP dinamico (tramite server DHCP), si può ovviamente dare un IP statico.

Scendendo in basso nel menù Avanzato, si può dare un hostname alla VM.

Poi è possibile installare già del software aggiuntivo, entrando nel menu “Select Additional Bundles”

Clear Linux per default imposta l’aggiornamento automatico del sistema. La cosa può essere cambiata in caso di necessità.

Ora procediamo con l’installazione vera e propria.

Terminata l’installazione e dopo il riavvio del sistema, Clear Linux parte con la sua interfaccia testuale.

Guida all’uso di Clear Linux

Abbiamo riscontrato la presenza di un kernel molto aggiornato, oggi è il 15 febbraio.

Questo perchè il sistema operativo Clear Linux è una distribuzione a rilascio continuo (rolling), ciò rende estremamente interessante la sua installazione su hardware molto recente. In fase di installazione era possibile scegliere anche un kernel più vecchio ma è preferibile affidarsi all’ultimo.

Il software per la gestione dell’avvio dei deamon (servizi) è systemd.

A livello di partizionamento, se si sceglie quello automatico predefinito, ci si troverà con un layout formato da 3 partizioni: una boot EFI (da 142 MB), swap (da 244 MB) e la partizione / con il restante spazio.

Per installare del software si può usare il comando swupd (abbreviazione di software update). A differenza di altre distribuzioni, Clear Linux non permette di installare in maniera semplice singoli pacchetti ma lo si può fare tramite flatpak es. per installare il gioco 0AD.

flatpak install flathub com.play0ad.zeroad 

Di suo, Clear Linux invece offre i cosiddetti bundle ossia un insieme di programmi e configurazioni per rendere un dato software o servizio funzionante.

Nel caso volessimo installare il web server Apache ci sono sufficienti 3 comandi:

sudo swupd bundle-add httpd
sudo systemctl enable httpd.service
sudo systemctl start httpd.service

Dove la prima riga permette di scaricare e configurare tutto il necessario per usare Apache. Le altre 2 servono per attivare il servizio.

Per poi, se si vuole, aggiunger anche PHP con un semplice:

sudo swupd bundle-add php-basic

Invece se si desidera installare un ambiente desktop (Gnome) si può installare il bundle desktop-autostart.

sudo swupd bundle-add desktop-autostart

Così, sarà installato Gnome e una serie di programmi tra cui Firefox, Gimp.

Conclusioni

Quest’articolo non vuole essere una guida a Clear Linux ma già con questi pochi elementi si evince come Clear Linux sia una distribuzione ideata per girare come piccolo sistema per virtual machine oppure come container nel quale installare software da combinare con altre tecnologie per scalare velocemente. Il fatto che sia molto aggiornata, consente di sfruttare i vantaggi delle nuove feature introdotte nel kernel e nei nuovi pacchetti.