? #howto – Impostare gli header di sicurezza su Apache2 e Nginx

Possedete uno o più siti web, avete intero accesso al server e volete potenziare la loro sicurezza? Potete farlo con gli header di sicurezza.

Cosa sono gli header di sicurezza?

Gli header di sicurezza sono degli header HTTP ricevuti in risposta dal browser utilizzati per migliorare la protezione di un’applicazione web. Una volta impostati, questi header limitano i browser moderni dal cadere facilmente in alcune vulnerabilità conosciute e prevenibili.

È facile impostare gli header di sicurezza?

Assolutamente sì. Infatti, è solamente necessario possedere l’accesso alle configurazioni di Apache2 o Nginx dei propri siti web, e dopo aver inserito delle piccole, ma utili stringhe di testo, il gioco sarà fatto.

Principali header di sicurezza

Vediamo assieme una lista dei principali header di sicurezza, altamente consigliati da impostare:

  • HTTP Strict Transport Security (HSTS)
  • X-Frame-Options
  • X-XSS-Protection
  • X-Content-Type-Options
  • Content-Security-Policy
  • Referrer-Policy

HTTP Strict Transport Security (HSTS)

L’HTTP Strict Transport Security, abbreviato in HSTS, è un meccanismo della policy della sicurezza web che aiuta a proteggere i siti web contro gli attacchi downgrade e l’hijacking dei cookie. L’HSTS indica ai web server che le connessioni con i browser (o user agent) devono essere effettuate solamente in HTTPS, e mai attraverso l’insicuro protocollo HTTP. La policy può essere impostata inserendo nella propria configurazione l’header Strict-Transport-Security, e deve essere utilizzato solo se desiderate che le connessioni al vostro sito web arrivino esclusivamente in HTTPS.

Un esempio di configurazione di questo header è il seguente:

Strict-Transport-Security: max-age=31536000 ; includeSubDomains

Il parametro max-age serve per indicare il tempo in cui il browser si deve ricordare che l’accesso al sito internet deve essere effettuato solo via HTTPS. includeSubDomains, invece, è un parametro opzionale, e può essere inserito per indicare che l’HSTS deve essere applicato anche ai sottodomini, nel caso ne aveste qualcuno.

X-Frame-Options

L’header di risposta X-Frame-Options serve a proteggere le applicazioni web dal fenomeno chiamato Clickjacking. Esso indica al browser che non deve in alcun modo mostrare i contenuti trasmessi in frame di altre pagine web.

Un esempio di configurazione di X-Frame-Options è il seguente:

X-Frame-Options: deny

Il valore deny vieta in tutti i modi che un frame mostri i contenuti di altre pagine web. A questo header possono essere impostati più valori:

  • deny
  • sameOrigin
  • allow-from: Dominio

Il primo. deny, è già stato spiegato. Impostando, invece, sameOrigin, si obbliga il browser a bloccare quanto impostato in un frame solamente se l’origine dei contenuti non è la stessa del sito web che si sta visitando. allow-from: Dominio permette che il frame mostri dei contenuti solamente se provenienti da un dominio specificato.

X-XSS-Protection

L’header X-XSS-Protection imposta delle regole per il filtro che protegge il browser dal Cross-Site Scripting, noto appunto come XSS.

Vediamo un esempio di impostazione dell’X-XSS-Protection:

X-XSS-Protection: 1; mode=block

Ecco tutti i valori impostabili all’header:

  • 0, disabilita il filtro
  • 1, abilita il filtro, e quando si rileva un attacco XSS la pagina viene pulita
  • 1; mode=block, abilita il filtro, e in caso di attacco XSS la pagina non viene pulita, bensì il suo caricamento è proprio bloccato
  • 1; report=http://[tuodominio]/URI_tua_segnalazione, abilita il filtro, ed in caso di attacco XSS la pagina viene pulita e la violazione viene registrata su una pagina a tua scelta. Si tratta di una funzione di Chromium

X-Content-Type-Options

Quando l’header X-Content-Type-Options viene impostato, si previene che il browser interpreti un file in modo diverso rispetto a quanto indicato dagli header HTTP con i tipi MIME.

Esempio di impostazione dell’X-Content-Type-Options:

X-Content-Type-Options: nosniff

Solamente il valore nosniff è utilizzabile, siccome non ne esistono altri. Il suo scopo è quello di evitare che il browser legga una risposta di un tipo MIME diverso rispetto a quanto indicato.

Content-Security-Policy

L’header Content-Security-Policy, o CSP, è uno dei più difficili da impostare, e richiede un’approfondita conoscenza di quello che è presente nelle pagine web dei propri siti. Se abilitato, il CSP ha un impatto significativo sul come il browser carica una pagina: con questo header infatti possono essere scelti gli script JavaScript da non caricare, così come per i file di stile. Proprio per questo motivo il CSP aiuta a prevenire vari tipi di attacchi, tra cui il Cross-site scripting ed altre injection cross-site.

Un esempio di impostazione del CSP è il seguente:

Content-Security-Policy: script-src 'self'

Così impostato, il server indica al browser che solamente gli script JavaScript provenienti dallo stesso dominio possono essere eseguiti, mentre gli altri devono essere bloccati.

Ecco tutti i parametri impostabili nella CSP:

  • base-uri
  • default-src
  • script-src
  • object-src
  • style-src
  • img-src
  • media-src
  • frame-src
  • child-src
  • frame-ancestors
  • font-src
  • connect-src
  • manifest-src
  • form-action
  • sandbox
  • script-nonce
  • plugin-types
  • reflected-xss
  • block-all-mixed-content
  • upgrade-insecure-requests
  • referrer
  • report-uri
  • report-to

Se vengono impostati più valori, ricordatevi di separarli con un punto e virgola come nell’esempio qui sotto:

Content-Security-Policy: script-src https://linuxhub.it/script.js https://google.it/scriptest123.js; style-src 'self'

Esatto, si possono anche impostare dei link o file multipli.

Referrer Policy

L’header Referrer Policy definisce quante informazioni riguardanti il server o l’applicazione web devono essere mandati in risposta al browser.

Un esempio di impostazione della Referrer Policy:

Referrer-Policy: no-referrer-when-downgrade

Ecco tutti i parametri impostabili per questo header di sicurezza:

  • no-referrer, l’header Referrer viene completamente omesso
  • no-referrer-when-downgrade, l’header Referrer viene mostrato se una risorsa viene caricata sullo stesso protocollo (in questo caso HTTPS), e si omette se si passa da quest’ultimo all’HTTP.
  • origin, indica solamente l’origine del documento
  • origin-when-cross-domain, manda un intero URL quando viene effettuata una richiesta su uno stesso dominio, mentre fa sapere esclusivamente l’origine del documento in altri casi
  • same-origin, un Referrer viene inviato solo se i documenti provengono dallo stesso sito, mentre le richieste cross-origin non mostreranno nessun’informazione
  • strict-origin, simile al secondo parametro, indica l’origine del documento invece dell’header
  • strict-origin-when-cross-origin, invia l’origine del documento tramite un URL intero solo se la richiesta viene effettuata da HTTPS a HTTPS
  • unsafe-url, fornisce un intero URL quando si effettua una richiesta dalla stessa o più origini

Come inserire gli header di sicurezza in Apache2

Per prima cosa, apriamo il nostro file apache2.conf su Debian e derivate, o httpd.conf su CentOS e RHEL-based (la locazione della configurazione potrebbe variare, e qui sotto ho inserito le directory principali, pertanto dovete solo capire dove si trova):

sudo nano /etc/apache2/apache2.conf
sudo nano /etc/apache2/httpd.conf
sudo nano /etc/httpd/httpd.conf
sudo nano /etc/httpd/conf/httpd.conf

e accertiamoci che la seguente riga non sia commentata:

LoadModule headers_module modules/mod_headers.so

Se non è abilitato, controlliamo che questo modulo sia caricato (non eseguito) da Apache con il seguente comando:

apache2ctl -M

Nel caso non fosse presente nella lista, abilitatelo con questo comando:

a2enmod headers

e riavviamo Apache:

sudo apache2ctl restart

Se il modulo è installato, alla fine del file potete inserire gli header di sicurezza che desiderate. Ecco un esempio basato sulla mia esperienza e preferenza:

Header set X-XSS-Protection "1; mode=block"
Header always append X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options nosniff
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set Referrer-Policy "no-referrer-when-downgrade"

Se volete aggiungere un header che io non utilizzo e/o non è presente tra i consigliati, ricordatevi sempre di aggiungere davanti ad esso Header set o Header always set in base alle situazioni.

Controlliamo se è tutto impostato correttamente:

sudo apache2ctl -t

Ora possiamo riavviare Apache con:

sudo apache2ctl restart

Come inserire gli header di sicurezza su Nginx

Per poter inserire gli header di sicurezza su Nginx, il procedimento è quasi simile. Apriamo il nostro file di configurazione del web server:

sudo nano /etc/nginx/nginx.conf

E inseriamo i nostri header preferiti:

add_header X-XSS-Protection "1; mode=block";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Referrer-Policy no-referrer-when-downgrade;

Controlliamo di non aver effettuato errori nel file di configurazione:

sudo nginx -t

Se è tutto a posto, riavviamo Nginx:

sudo service nginx restart

Conclusione

Dopo aver inserito i nostri header di sicurezza, per verificare se un sito web è protetto possiamo visitare securityheaders.com che ci dà una piccola panoramica di quello che viene rilevato.

Panoramica degli header di sicurezza presenti su linuxhub.it

Per dubbi e chiarimenti, fate accesso al nostro gruppo Telegram.

? #howto – Installazione e configurazione di Microsoft SQL Server su Centos 7

Dalla release del 2017, Microsoft SQL Server è disponibile per sistemi Linux in modo nativo.

In questa guida vediamo come installare l’SQL Server di Microsoft su Centos 7, tramite la repository ufficiale.

Configurazione repository

Per prima cosa dobbiamo scegliere la repository di nostro interesse, al momento Microsoft ne offre di 3 tipologie:

  • CU (Cumulative Updates)
  • DGR (General Distribution Release)
  • Preview (l’anteprima per la versione 2019 nel momento in cui scrivo l’articolo)

Eseguiamo quindi il relativo comando per la versione scelta della repository.

Cumulative Updates

sudo curl -o /etc/yum.repos.d/mssql-server.repo https://packages.microsoft.com/config/rhel/7/mssql-server-2017.repo

General Distribution Release

sudo curl -o /etc/yum.repos.d/mssql-server.repo https://packages.microsoft.com/config/rhel/7/mssql-server-2017-gdr.repo

Preview

sudo curl -o /etc/yum.repos.d/mssql-server.repo https://packages.microsoft.com/config/rhel/7/mssql-server-preview.repo

Installazione

Una volta configurata la repository possiamo procedere con l’installazione vera e propria, procediamo quindi tramite yum:

sudo yum install -y mssql-server

installiamo inoltre gli strumenti per la riga di comando:

sudo curl -o /etc/yum.repos.d/msprod.repo https://packages.microsoft.com/config/rhel/7/prod.repo
sudo yum -y install mssql-tools unixODBC-devel

una volta ultimato, il server è pronto per la prima inizializzazione.

Configurazione

Procediamo con la prima esecuzione del server, avviamo il setup guidato tramite:

sudo /opt/mssql/bin/mssql-conf setup

Nel primo step ci viene chiesto di selezionare la tipologia di licenza, per scopi personali o istruzione, selezionate uno fra:

  • Evaluation (free, no production use rights, 180-day limit)
  • Developer (free, no production use rights)
  • Express (free)

La licenza di tipo Express va bene nella maggior parte dei casi, fate riferimento al sito ufficiale.

procediamo col secondo step in cui accettiamo la licenza del prodotto, infine ci verrà chiesta una password per l’utente admin, ricordiamo di salvarla.

Configurazione variabile PATH

Per poter utilizzare il server e la riga di comando, dobbiamo aggiungere i binari alla variabile $PATH, in questo modo:

echo 'export PATH=$PATH:/opt/mssql/bin:/opt/mssql-tools/bin' | sudo tee /etc/profile.d/mssql.sh

Gli strumenti saranno disponibili una volta riavviata la sessione.

Infine abilitiamo il servizio con systemctl:

sudo systemctl enable mssql-server

ed avviamolo:

sudo systemctl start mssql-server

Configurazione Firewall

Nel caso fosse abilitato firewalld come Firewall di sistema, dobbiamo aggiungere qualche regola per renderlo disponibile all’esterno:

sudo  firewall-cmd --add-port=1433/tcp --permanent
sudo  firewall-cmd --reload

Ora tutto è pronto per l’utilizzo.

 

Per dubbi e chiarimenti, fate accesso al nostro gruppo Telegram.

Good *nix _Mirko

 

? #howto – Utilizzo del comando ‘curl’

Il comando curl è un potente strumento per il download di risorse web e non solo, si può infatti utilizzare anche in altri contesti, come ad esempio interpellare delle API e inviare e/o ricevere header.

Sintassi

La sintassi del comando è la seguente:

curl [opzioni] [url]

Utilizzo del comando

Come comando è facilmente comprensibile, supporta diverse opzioni e si può utilizzare in più contesti.

Nel caso in cui vogliamo ricevere il contenuto di una risorsa (ad esempio questa guida):

curl https://linuxhub.it/article/howto-utilizzo-del-comando-curl

riceveremo un output col contenuto della pagina web, in formato HTML.

Download di file

Possiamo scaricare un file, ad esempio un archivio .zip, specificandone l’output mediante flag -o:

curl https://url/archivio.zip -o archivio.zip

in alternativa possiamo sfruttare l’operatore > nel comando curl in questo modo:

curl https://url/archivio.zip > archivio.zip

altrimenti sfruttando il nome stesso della risorsa tramite flag -O:

curl -O https://url/archivio.zip

in tutti i casi, il file verrà scaricato sotto nome archivio.zip.

Download di file multipli

Come visto precedentemente per la flag -O, possiamo utilizzare lo stesso concetto per scaricare più file semplicemente scrivendo in sequenza:

curl -O https://url/archivio_1.zip -O https://url/archivio_2.zip

per scaricare quindi i file archivio_1.zip e archivio_2.zip.

Riprende un download interrotto

Nel caso in cui un download viene interrotto per x motivi, possiamo recuperarlo portandoci nella locazione dove è presente il frammento del precedente download e sfruttare la flag -C per continuarne il download:

curl -C - -O https://link/archivio.zip

Reindirizzamenti

Può capitare di inciampare in un messaggio che specifica lo spostamento in nuova locazione della risorsa, possiamo istruire curl a seguire questo/i reindirizzamenti tramite flag -L:

curl -OL https://url_vecchio/archivio.zip

il che farà riferimento al link nuovo nel caso di reindirizzamento.

Ricevere gli header

Possiamo utilizzare la flag -I per ricevere gli header di una chiamata, ad esempio per visualizzare quelli di questo sito web:

curl -X HEAD -i https://linuxhub.it

in questo caso l’output sarà simile al seguente:

curl -I https://linuxhub.it
HTTP/2 200 
date: Mon, 16 Sep 2019 08:52:35 GMT
content-type: text/html; charset=UTF-8
x-drupal-dynamic-cache: MISS
link: <https://linuxhub.it/>; rel="shortlink", <https://linuxhub.it/>; rel="canonical"
x-ua-compatible: IE=edge
content-language: it
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN

Inviare header

Nel caso in cui vogliamo interagire con la risorsa inviando un header, ad esempio uno di autenticazione (Authorization), possiamo utilizzare la flag –header (o -I) in questo modo:

curl --header "Authorization: AUTH_TOKEN" https:/link_risorsa

il quale restituirà un output a seconda della programmazione della risorsa.

 

Per dubbi e chiarimenti, fate accesso al nostro gruppo Telegram.

Good *nix _Mirko

? #howto – Installazione di Ghost CMS su Debian/Ubuntu e derivate

Ghost è una piattaforma di blogging gratis e open source, creato per semplificare il processo di pubblicazione online per blogger e testate.

In questo articolo vediamo come installarlo e configurarlo.

Requisito fondamentale è NodeJS, che deve essere presente sulla nostra macchina a questo proposito vi rimando alla nostra guida su come installare NodeJS su Debian 9.

Requisiti

In questa installazione andremo ad usare Nginx come Web Server e MariaDB come Database Server, ricapitolando quindi:

  • NodeJS
  • NGINX
  • MariaDB (leggi la sezione qui)
  • CERTBOT(facoltativo)

Preparazione del database

Procediamo per prima cosa, con la creazione del nostro database e nome utente da dedicare poi all’installazione del CMS, da console mysql quindi, accessibile mediante:

sudo mysql -u root -p

creiamo un nuovo database:

CREATE DATABASE ilmiodb;

 dove ilmiodb è il nome del nuovo database. Creiamo poi il nostro nuovo utente:

CREATE USER il_mio_user@localhost IDENTIFIED BY 'la_mia_password';

dove:

  • il_mio_user – è il nome utente con cui faremo accesso al database
  • la_mia_password – è la password del nostro utente

ed impostiamo i permessi per l’accesso al database:

GRANT ALL PRIVILEGES ON ilmiodb.* TO il_mio_user@localhost;
FLUSH PRIVILEGES;

infine chiudiamo la console:

exit

Installazione

L’installazione si suddivide in due step:

  • Installazione della cli
  • Installazione del cms

Installazione della cli

Per prima cosa, supponendo di aver installato NodeJS e quindi npm (node package manager) nel nostro sistema, andiamo ad installare ghost-cli, lo strumento completo offerto dagli sviluppatori, per facilitarne l’installazione:

sudo npm install -g ghost-cli@latest

Una volta completata l’installazione del software, andiamo a creare la locazione dove posizioneremo successivamente il CMS, ad esempio in /var/www:

sudo mkdir /var/www/ghost

ed impostiamo i permessi corretti:

sudo chown -R $USER:$USER /var/www/ghost
sudo chmod -R 775 /var/www/ghost

dove $USER corrisponde ad un utente esistente nel sistema, nel nostro esempio hersel:hersel.

Installazione del CMS

Andiamo ora finalmente ad installare il CMS, portiamoci quindi nella locazione precedentemente creata:

cd /var/www/ghost/

ed avviamo l’installazione guidata tramite comando ghost:

ghost install

il che dovrebbe restituire un output simile al seguente:

hersel@debianhersy:/var/www/ghost$ ghost install
✔ Checking system Node.js version
✔ Checking logged in user
✔ Checking current folder permissions
System checks failed with message: 'Linux version is not Ubuntu 16 or 18'
Some features of Ghost-CLI may not work without additional configuration.
For local installs we recommend using `ghost install local` instead.
? Continue anyway? (y/N)

Nel caso in cui lo script rilevi un sistema differente da Ubuntu, procedete con Yes al prossimo step.

entro qualche minuto ci verrà chiesto di inserire l’indirizzo del nostro blog:

? Enter your blog URL: (http://localhost:2368)

a questa domanda possiamo rispondere in due modi:

  • nel caso in cui vogliamo installare ed eseguire in locale il nostro blog, lasciamo il campo vuoto e procediamo con invio
  • se vogliamo invece rendere reperibile il nostro blog in rete, ci basterà inserire l’indirizzo del nostro dominio, il quale dovrà puntare al server (leggi come qui). Quindi, nell’esempio di questo blog, il dominio è linuxhub.it, andiamo quindi ad inserire https://linuxhub.it

Importante tenere in considerazione che, per quanto riguarda le installazioni con dominio, dobbiamo rispondere Yes alle seguenti domande quando ci verranno poste:

? Do you wish to set up Nginx? yes
? Do you wish to set up SSL? yes

Successivamente ci verrà chiesto di inserire i dati del nostro database (precedentemente creato) da dedicare all’installazione:

? Enter your MySQL hostname: localhost
? Enter your MySQL username: hersel
? Enter your MySQL password: [hidden]
? Enter your Ghost database name: ghost

Seguiranno poi altri step a cui rispondere Yes o No, normalmente procedo con risposta positiva a tutti gli step. Una volta terminata l’installazione, dovremmo ricevere un output simile al seguente:

Ghost is already running! For more information, run:

    ghost ls

digitiamo quindi:

ghost ls

per ricevere un output di questo tipo:

hersel@debianhersy:/var/www/ghost$ ghost ls
+ sudo systemctl is-active ghost_151-**-188-***
┌────────────────┬────────────────┬─────────┬──────────────────────┬────────────────────────┬──────┬─────────────────┐
│ Name           │ Location       │ Version │ Status               │ URL                    │ Port │ Process Manager │
├────────────────┼────────────────┼─────────┼──────────────────────┼────────────────────────┼──────┼─────────────────┤
│ 151-**-188-*** │ /var/www/ghost │ 2.31.0  │ running (production) │ http://localhost:2369/ │ 2369 │ systemd         │
└────────────────┴────────────────┴─────────┴──────────────────────┴────────────────────────┴──────┴─────────────────┘

Nel mio caso l’installazione è locale, il risultato sarà diverso nel caso abbiate scelto l’installazione pubblica tramite Nginx e SSL.

Ci basterà ora visitare l’indirizzo per proseguire con la procedura di configurazione guidata direttamente dal nostro browser.

? #howto – Creare uno script di post installazione con UPI (Universal Post Install)

Uno script di post installazione può semplificare il lavoro in molti casi, come per un rollout, la configurazione di un ambiente di sviluppo o il semplice cambio di distribuzione.

UPI (Universal Post Install) è uno strumento sviluppato da linux/hub che permette di creare semplici script di post installazione in pochi minuti.

Introduzione

Ogni script viene identificato da una distribuzione e dalla sua versione. Nell’esempio in cui dobbiamo predisporre una postazione con Centos 7, lo script sarà identificato dalla distribuzione centos in versione 7.

Funzionamento

Il funzionamento di UPi è semplice e logico. In primis identifica la distribuzione in cui viene eseguito, successivamente controlla se è presente uno script compatibile e lo carica.

Una volta caricato lo script viene visualizzato a schermo un menu di installazione da cui è possibile selezionare le voci di interesse (come nell’esempio qui sotto):

UPI (cli)

Esiste inoltre una versione GTK (sperimentale) del menu, accessibile passando la flag -gtk all’avvio del programma:

UPI (gtk)

Nonostante non siano ancora stati riscontrati bug, questa versione è ancora in fase di sviluppo e pertanto sconsigliata in un ambiente di produzione.

Creare uno script

Siccome UPI lavora in locale, possiamo creare script per ogni esigenza, indifferentemente dal fatto che sia definito per Ubuntu o Fedora in modo generico. Basterà infatti inserire lo script nella cartella script, ed eseguire poi il programma sulla postazione di nostro interesse.

Nell’esempio seguente andiamo a creare uno script di post installazione per elementaryOS 5.0 juno. Per prima cosa scarichiamo una copia di UPI:

wget https://github.com/mirkobrombin/Universal-Post-Install/archive/master.zip

e scompattiamo l’archivio:

unzip master.zip

andiamo nella directory scripts e creiamo il nostro script (in questo caso è già presente e possiamo procedere con la sua modifica). Il file si deve chiamare come la distribuzione interessata e terminare con l’estensione .py. Il nome corretto della distribuzione è reperibile digitando:

lsb_release -i 2> /dev/null | sed 's/:\t/:/' | cut -d ':' -f 2-

Il contenuto dello script sarà il seguente:

import helper
import sys
import os

g = False

for px in sys.argv:
    if px == '-gtk':
        g = True

# Define the package manager
E = "apt"

helper.title("ElementaryOS")
helper.author("Mario Rossi")
helper.website("https://linuxhub.it")

supported_versions = [
    "0.4.1", 
    "5.0"
]

# Check for release
distro = helper.get_distro()
if distro.release in ["0.4.1", "5.0"]:
    class PostInstall:
        global E
        # Define menu voices
        voices_en_US = [
            ("Install updates ", "install_updates"), 
        ]
        voices_it_IT = [
            ("Installa aggiornamenti", "install_updates"), 
        ]
        
        # Define functions for each menu voice
        def install_updates(self, g=False):
            helper.pkg_update(E)
            helper.pkg_sys_upgrade(E)
    
    helper.not_compatible()

# Load script
pi = PostInstall()
try:
    voices = eval('pi.voices_' + distro.lang)
except AttributeError:
    voices = pi.voices_en_US
helper.steps(voices, pi, g)

dove andiamo a compilare:

  • helper.title col nome personalizzato del nostro script, in questo caso ElementaryOS
  • helper.author col nostro nome e cognome
  • helper.website con un sito web di referenza
  • supported_versions con una lista di versioni con cui il nostro script è compatibile
  • E che definisce il package manager di sistema, in questo caso apt

Possiamo reperire la versione della distribuzione digitando:

lsb_release -r 2> /dev/null | sed 's/:\t/:/' | cut -d ':' -f 2-

in questo caso restituirà 5.0.

Ogni script è compatibile in più lingue: basterà inserire la sigla di interesse. In questo caso utilizzeremo sia l’inglese (en_US) che l’italiano (it_IT) e sarà quindi necessario compilarli entrambi. Portiamoci quindi alla voce PostInstall:

class PostInstall:
        global E
        # Define menu voices
        voices_en_US = [
            ("Install updates ", "install_updates"), 
        ]
        voices_it_IT = [
            ("Installa aggiornamenti", "install_updates"), 
        ]
        
        # Define functions for each menu voice
        def install_updates(self, g=False):
            helper.pkg_update(E)
            helper.pkg_sys_upgrade(E)
    
    helper.not_compatible()

precisamente alle voci:

  • voices_en_US per la lingua inglese
  • voices_it_IT per la lingua italiana

Ogni voce è composta da titolo e nome funzione:

("Install updates ", "install_updates"), 

dove:

  • Install updates è il titolo
  • install_updates la funzione

aggiungiamo una nuova voce, ad esempio:

("Install Blender ", "install_blender"), 

e la relativa traduzione italiana:

("Installa Blender ", "install_blender"), 

notare che la funzione non viene mai tradotta.

Portiamoci alla voce:

# Define functions for each menu voice

e creiamo una nuova funzione chiamata install_blender:

def install_blender(self, g=False):
    helper.pkg_install("blender", E)

ogni funzione può sfruttare i metodi pkg messi a disposizione dall’helper:

pkg_install per installare un pacchetto

helper.pkg_install("blender", E)

pkg_add_repo per aggiungere una repository

helper.pkg_add_repo("ppa:philip.scott/elementary-tweaks", E)
helper.pkg_update(E)

pkg_update per aggiornare la lista dei pacchetti

pkg_remove per rimuovere un pacchetto

helper.pkg_remove("blender", E)

pkg_sys_upgrade per effettuare un aggiornamento di sistema

helper.pkg_sys_upgrade(E)

Una volta creata la nostra prima funzione, salviamo ed eseguiamo lo script sulla postazione interessata con:

python main.py

per visualizzarne il risultato.

Funzioni avanzate

Ci sono alcuni metodi messi a disposizione da helper, con la quale possiamo effettuare operazioni avanzate nel nostro script.

Possiamo utilizzare helper.do per eseguire comandi nella shell:

helper.do("touch $HOME/hello.world", False)

o via sudo cambiando l’ultimo parametro in True.

Sfruttiamo invece la funzione helper.perm per cambiare i permessi di una directory:

helper.perm("/directory", "755", False)

anche qui cambiando in True per utilizzare sudo.

Personalizzazione

Possiamo sfruttare alcune funzioni per mostrare informazioni personalizzate nello script. Ogni funzione richiede un unico parametro, ossia il testo da mostrare:

  • helper.title(“Hello World!”)
  • helper.text(“Testo normale”)
  • helper.info(“Testo informativo”)
  • helper.bold(“Testo in grassetto”)
  • helper.success(“Testo di successo”)
  • helper.error(“Testo errore”)
  • helper.warning(“Testo avviso”)

col seguente risultato:

UPI (custom)

È possibile proporre script “ufficiali” e generici nel progetto GitHub: https://github.com/mirkobrombin/Universal-Post-Install

 

Per dubbi e chiarimenti, utilizzate il nostro gruppo Telegram.

Good *nix _Mirko

? #howto – Installare VMware Player su Fedora 30

Il player di VMware permette la creazione, gestione ed esecuzione di macchine virtuali. Il pacchetto offerto dall’azienda è vasto ed offre più strumenti, fra cui l’insieme Workstation/Professional.

In questa guida vediamo come installare il player su Fedora 30, la quale richiede alcuni accorgimenti come la compilazione dei moduli, al momento non supportati nella versione 5 del kernel Linux.

Compilazione moduli

Per prima cosa scarichiamo ed installiamo via dnf, gli strumenti necessari alla compilazione del moduli:

sudo dnf install git make gcc gcc-c++ kernel-devel kernel-headers

portiamoci in una locazione su cui lavorare, ad esempio nella cartella Download (Scaricati su sistemi in Italiano) del nostro utente:

cd ~/Scaricati

ed otteniamo/scompattiamo la versione più recente della patch (la 15.1.0 nel momento in cui scrivo):

wget https://github.com/mkubecek/vmware-host-modules/archive/player-15.1.0.zip
unzip player-15.1.0.zip

successivamente procediamo con la compilazione via make:

make
sudo make install

Installazione di VMware Player

Otteniamo una copia gratuita del player dal portale ufficiale (la 15.1.0 nel momento in cui scrivo), portiamoci alla sua locazione da terminale e rendiamo il file eseguibile:

chmod +x VMware-Player-*.bundle

ed avviamo l’installazione:

sudo ./VMware-Player-*.bundle

Infine una volta terminata l’installazione (per non riavviare la macchina), carichiamo manualmente il modulo vmmon:

sudo modprobe vmmon

Possiamo ora avviare l’interfaccia del player dal menu applicazioni di sistema o semplicemente digitando vmplayer.

 

Per dubbi e chiarimenti, utilizzate il nostro gruppo Telegram.

Good *nix _Mirko

? #howto – Come fare un dual boot su Arch Linux

Arch Linux è una distribuzione molto amata dalla comunità, per via di una community attiva e una wiki completa, ma non per questo è esente da problemi di sorta o complicazioni nell’uso.

Una nelle spine nel fianco di Arch Linux è l’installazione, a non tutti gli utenti può piacere, ma la maggior parte si ritroverà compatta su una cosa: “Ma quanto è problematico fare un buon Dual Boot con Arch Linux!”.

Dato che l’installazione di Arch viene fatta da terminale, i tools per il partizionamento del disco sono molto più complessi da usare per un utente normale e bisogna fare attenzione a non fare passaggi sbagliati(cosa non scontata), ma soprattutto non c’è nessun riferimento su quale siano le partizioni da formattare e quali siano quelle del sistema da mantenere per il Dual Boot.

Io per il partizionamento procedo in un altro modo rispetto al partizionamento da terminale.

Configurazione delle partizioni

Se siamo su Windows, prima cosa procurarsi una live di GParted, così da avere uno strumento grafico per vedere e gestire le partizioni su linux, se invece siete su una distribuzione linux potete usare lo strumento di partizionamento che più vi aggrada. Dopo aver preparato la chiavetta riavviare il PC e entrare nella live.

Ora partizioniamo il disco con la GUI di GParted, così da fare il tutto in modo più semplice che con il terminale e così da non rischiare di eliminare partizioni sbagliate, a questo punto prendiamo lo strumento per le note che più ci aggrada e ci appuntiamo quali sono esattamente le partizioni dove vogliamo installare il nostro Arch(Es. /dev/sdx1 /, /dev/sdx2 /home). Ora riavviamo con una USB con Arch e procediamo a formattare le partizioni giuste e ovviamente, a montarle.

Alla fine dovremmo avere una struttura del tipo:

Disco ->
|-Partizione del secondo OS
|-ESP del secondo OS
|-Partizioni di Arch
|-ESP di Arch

Creazione del Dual Boot

A questo punto durante l’installazione quando installiamo grub installiamo anche os-prober e, finita l’installazione ed entrati in Arch Linux, entrando in un terminale possiamo creare il nuovo file config di grub:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/intel-ucode.img /boot/initramfs-linux.img
Found fallback initrd image(s) in /boot: initramfs-linux-fallback.img
Found Windows Boot Manager on /dev/sda3@/efi/Microsoft/Boot/bootmgfw.efi
done

Così grub avrà aggiunto anche il secondo OS tra le boot entry e potremo usare il nostro Dual Boot con Arch.

 

Per dubbi e chiarimenti, utilizzate il nostro gruppo Telegram.

? #howto Installazione e configurazione di MongoDB su Debian

MongoDB è un database non relazionale, basato su documenti. La sua struttura lo colloca nella classifica dei database NoSQL.

In questa guida vediamo come installarlo su Debian .

Installazione

Per prima cosa dobbiamo installare il pacchetto mongodb dal gestore pacchetti:

sudo apt install -y mongodb

questo è in realtà un metapackage che andrà ad installare un totale di 5 pacchetti:

  • mongodb-org-server
  • mongodb-org-mongos
  • mongodb-org-shell
  • mongodb-org-tools

procediamo infine con l’abilitazione e l’avvio del servizio via systemctl:

sudo systemctl enable mongodb
sudo systemctl start mongodb

richiedendone quindi lo stato:

sudo systemctl status mongodb

dovremmo ricevere un output simile al seguente:

mongodb.service - An object/document-oriented database
   Loaded: loaded (/lib/systemd/system/mongodb.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-08-07 17:55:43 BST; 38min ago
     Docs: man:mongod(1)
 Main PID: 17360 (mongod)
    Tasks: 16 (limit: 4915)
   CGroup: /system.slice/mongodb.service
           └─17360 /usr/bin/mongod --unixSocketPrefix=/run/mongodb --config /etc/mongodb.conf

Aug 07 17:55:43 hersy systemd[1]: Started An object/document-oriented database.

Possiamo procedere nel seguente modo per ottenere una seconda verifica del suo funzionamento:

mongo --eval 'db.runCommand({ connectionStatus: 1 })'

ottenendo quindi un esito simile al seguente:

MongoDB shell version: 3.2.11
connecting to: test
{
        "authInfo" : {
                "authenticatedUsers" : [ ],
                "authenticatedUserRoles" : [ ]
        },
        "ok" : 1
}

dove ok: 1 è la conferma che il server funziona correttamente.

Configurazione

Per impostazione base MongoDB è configurato per funzionare nella maggior parte delle casistiche, unico accorgimento è quello di modificare l’indirizzo IP a cui è consentita la connessione. Infatti di default resta in ascolto sull’indirizzo locale 127.0.0.1 per consetire a MongoDB di funzionare con un IP pubblico ci basta modificare le impostazioni con il seguente comando:

sudo nano /etc/mongodb.conf

andiamo quindi a modificare come segue:

bind_ip = 127.0.0.1, NOSTRO_IP
#port = 27017

dove NOSTRO_IP è ovviamente il nostro indirizzo IP a cui vogliamo abilitare l’accesso.

Ultimate le modifiche riavviamo il servizio via systemctl:

sudo systemctl restart mongodb

 

Per dubbi e chiarimenti, utilizzate il nostro gruppo Telegram.

? #howto – Collegare e sincronizzare Nextcloud su desktop Linux

Abbiamo già pubblicato nella Raccolta su Nextcloud come installare questa piattaforma su varie distribuzioni server.

Il termine Linux nel titolo di questo articolo fa riferimento in realtà a tutto l’insieme di distribuzioni compatibili (Fedora, Ubuntu, Debian, ..).

Ciò che andiamo a vedere oggi è come collegare e sincronizzare Nextcloud nella nostra distribuzione desktop di tutti i giorni. I pregi di mantenere la sincronia fra desktop e server sono diversi, in primis l’immediata disponibilità dei file, il loro aggiornamento ed il poterli utilizzare quando non è presente una connessione per poi salvare le modifiche quando torniamo online.

Installazione

Il mio metodo preferito per sincronizzare i file è tramite il client ufficiale, si può poi optare per altre soluzioni come ad esempio la configurazione del percorso DAV ma non è questa la guida.

Per prima cosa scarichiamo il client ufficiale (qui) che su Linux viene fornito sotto forma di AppImage pronta all’uso:

Download Nextcloud Linux AppImage

Successivamente portiamoci nella directory dove è stato scarico il file e spostiamolo nella locazione /opt di sistema:

sudo mv Nextcloud*.AppImage /opt

ed impostiamo i permessi per l’esecuzione del file:

sudo chmod +x /opt/Nextcloud*.AppImage

in questo modo lo possiamo eseguire come una normale applicazione.

Registrazione nel sistema

Portarsi sempre alla directory /opt o ricorrere al terminale per avviare l’applicazione, non è di certo la miglior scelta in un contesto produttivo. In questa parte di guida vediamo come registrare l’applicazione con appimaged in modo da inserire la nostra AppImage nella directory di sistema e facendola così rilevare ed inserire nei menu delle applicazioni.

Per prima cosa scarichiamo appimaged:

wget "https://github.com/AppImage/appimaged/releases/download/continuous/appimaged-x86_64.AppImage"

impostiamo i permessi:

chmod +x appimaged-x86_64.AppImage

ed installiamo

./appimaged-x86_64.AppImage --install

rieffettuiamo il login col nostro account per renderlo funzionante. Infine eseguiamo:

appimaged

 per rilevare le nostre AppImage, ora NextCloud compare nel nostro menu applicazioni.

Avvio col sistema

Per facilitarne il funzionamento, può tornare utile eseguirlo col sistema in modo da avviarlo ad ogni accensione.

Ci sono diversi metodi per fare ciò, quello che consiglio io è sfruttare le impostazioni fornite col Desktop Environment in uso.

KDE

Nel caso di KDE possiamo procedere dal gestore Impostazioni, cerchiamo Avvio e spegnimento, una volta entrati nella sezione clicchiamo su Aggiungi programma e selezioniamo la nostra AppImage in /opt, infine salviamo le modifiche.

GNOME

Creiamo uno script sh per l’esecuzione della nostra AppImage in ~/.config/autostart:

nano ~/.config/autostart/nextcloud.sh

col seguente contenuto:

#!/bin/bash
cd /opt
./Nextcloud.AppImage

infine salviamo.

XFCE/Mate

Dal menu delle Impostazioni, portiamoci su Avvio applicazioni, nella finestra che si apre clicchiamo su Aggiungi e selezioniamo il percorso della nostra AppImage in /opt.

 

Per dubbi e chiarimenti, utilizzate il nostro gruppo Telegram.

Good *nix _Mirko

? #howto – Guida all’uso di Visual Studio Code

Chi abitualmente chiacchiera con noi sul gruppo Telegram di gentedilinux sa già che il mio editor di codice preferito è Visual Studio Code.

Sono tentato di chiamarlo “Ambiente di Sviluppo” (o IDE) poichè nonostante sia pubblicizzato come editor di codice estendibile, è in realtà talmente supportato dalla community da essere uno degli strumenti di programmazione più avanzati e completi che io conosca.

Visual studio code gode di un ottima documentazione fornita ufficialmente, di una ottima community e di supporto su tutti i sistemi operativi. Per questo motivo oggi ho deciso di elencarvi quali sono le motivazioni e gli strumenti che potete configurare sul vostro pc per avere un ambiente che si avvicina molto ad un ambiente di sviluppo integrato. Eviterò cose ovvie come le estensioni, per il quale il software ha già una serie di meccanismi che ne semplificano la scoperta e la l’installazione.

Tutti gli esempi li farò usando java come linguaggio d’esempio.

Workspace setting

Il primo passo è sicuramente quello di impostare quelle che sono le impostazioni comuni per il vostro workspace. Apriamo quindi la cartella dove siamo intenzionati a inserire i file del nostro progetto e tramite menu bar selezioniamo File->Save Workspace As->... e diamo un nome al nostro file.

Ci si aprirà quindi un editor sul file creato, ci troviamo davanti un file json, non troppo difficile tranquilli, anche perchè è già parzialmente compilato. Inseriamo nella voce path, nelle virgolette che seguono i due punti, il percorso completo della cartella dei nostri sorgenti.

L’ambiente ora ci mostrerà nell’explorer solo quei file!

Code Snippet

Anche chiamati code template da altri IDE, sono quegli strumenti che tramite un abbreviazione a scelta inseriscono dei blocchi di codice.

Per farvi un esempio provate a strivere sysout o syserr e premere ctrl-spazio. vi si aprirà un layout che vi proporrà di sostituire quell’abbreviazione con System.out.println(); o System.err.println();

Comodo vero?
Vediamo come impostare i nostri snippet!

Dalla menu bar accediamo a File->preferences->user snippet, qui possiamo decidere se creare delle abbreviazioni globali o solo per la cartella src. Io sceglierei quelle globali.
Ci troviamo anche qui un file json, se odiavate questa tipologia di file beh mi spiace.

Dovrete scrivere gli snippet tra parentesi graffe e separate ognuno da virgola, tutto racchiuso tra le due parentesi graffe già presenti nel file.

Studiamo la struttura di un singolo snippet:

"NOME SNIPPET":{
    "prefix": "abbreviazione",
    "body":[
        "linea di codice",
        "altra linea di codice",
        "va beh avete capito..."
    ],
    "description": "descrizione se volete"
}

Dunque non mi soffermerò su cose ovvie come descrizione e nome dello snippet, vediamo gli altri due campi invece.

Il “prefix” è semplicemente quella frase che attiverà lo snippet, nel caso in esempio scrivendo abbreviazione e premendo ctrl-spazio, o premendo prima la combinazione per poi cercare la parola chiave in seguito, potrete assistere alla sostituzione del blocco di codice.

Inserendo nel blocco ‘body’ le variabili $1,$2…etc avrete dei tab-blocking, cioè segnaposti che vi permetteranno di compilare dei campi in successione premendo tab per spostarvi da uno all’altro. Ancora potete usare alcune variabili particolari per creare combinazioni veramente potenti, come ottenere all’interno del blocco il numero di riga, la data, il nome del file o del testo precedentemente selezionato. Altri dettagli nella documentazione [https://code.visualstudio.com/docs/editor/userdefinedsnippets#_variables]

Ecco un esempio di snippet:

"System exit":{
        "prefix": "sysex",
        "body":[
            "System.out.println(\"${1:messaggio_uscita}\");",
            "System.exit(${TM_CURRENT_WORD:codice_uscita});"
        ],
        "description": "Exit method"
    }

Questo snippet consente di sostituire all’abbreviazione sysexit la stampa di un messaggio e l’uscita di un programma java. Se prima di scriverlo viene selezionato un numero questo si sostituisce come codice di uscita all’interno del metodo che l’attua.

Compilazione

L’autocompilazione del codice su un IDE è una delle cose sicuramente più importanti che ci sia per evitare inutili perdite di tempo a chi sviluppa.

Su visual studio code si possono impostare i così detti “task”, cioè l’auto esecuzione di alcuni comandi tramite un semplice click.
Per creare un task andiamo su terminal->run task ci chiederà se vogliamo creare un nuovo task e che tipo di task, selezioniamo quindi “other”. Si aprirà un editor con un file json che rappresenterà il nostro task, inizialmente il template riporterà un task bash semplice, un echo.

{
"version": "2.0.0",
    "tasks": [
        {
            "label": "echo",
            "type": "shell",
            "command": "echo Helloworld"
        }
    ]
}

Non è difficile capire che questo task semplicemente esegue una stampa in bash della stringa hello world ma analizziamolo meglio:

  • label: indica il nome del task
  • type: attraverso questo parametro diremo a vscode che il comando eseguito è un comando da avviare con l’interprete dei comandi predefinito
  • command: potete inserire qua qualunque comando vogliate interpretabile tramite shell, oppure il percorso di uno script

Ora capirete da qua che questo approccio ha già infiniti risvolti, perchè già definendo uno script in particolare con i comandi che ci servono per compilare il nostro progetto abbiamo già tutte le possibilità che cerchiamo.

Possiamo concatenare più task aggiungendo una virgola dopo la parentesi graffa che segue command nell’esempio… così:

{
"version": "2.0.0",
    "tasks": [
        {
            "label": "echo",
            "type": "shell",
            "command": "echo Helloworld"
        },
        {
            "label": "cat",
            "type": "shell",
            "command": "cat Helloworld"
        }
    ]
}

Questo ci fa capire che il blocco del task vero e proprio è quello più interno.

Ma noi siamo persone brutte, e vogliamo fare di più… esistono delle variabili particolari nei task che possono essere utilizzati per richiamare particolari testi. ad esempio la cartella di lavoro o il percorso del file, quindi troviamo la varibile che più ci aggrada in questa pagina [https://code.visualstudio.com/docs/editor/variables-reference] e scriviamo i nostri task complessi, ecco a voi quello che uso io per compilare in java:

{
    "label": "compila ",
    "type": "shell",
    "command": "javac ${file} ${workspaceFolder}/../bin"
}

Si può fare molto di più con i task di VSCode, come le attività di compilazione continua, oppure i build task. Ma lascio queste scoperte a voi ricordandovi la documentazione.

La stesura completa di tutte le possibilità che si hanno con questo software è ancora lunga, ci sono altre potenzialità come il debug. Però vista la corposità dell’articolo lasciamo queste scoperte ad un possibile futuro approfondimento.

div>