Tutti gli articoli di Gianluca Nanoia

Ubuntu disponibile sul Windows Store

E’ proprio vero, come promesso da Microsoft qualche mese fa, la prima distribuzione Linux è a disposizione degli utenti Windows 10 direttamente sullo Store. Questo significa che chiunque abbia a disposizione una macchina con Windows 10 potrà scaricare ed installare il relativo pacchetto come accade per qualsiasi altra app, ed utilizzare (limitatamente alla riga di comando) un vero e proprio sistema operativo Linux.

Attualmente l’unica distribuzione disponibile è Ubuntu, ma molto presto sarà possibile installare Fedora e Suse. Essendo una novità assoluta, questa feature ha sicuramente bisogno di un periodo di test prima di diventare disponibile al grande pubblico, ed al momento l’installazione è limitata agli utenti del programma Windows Insider. L’iscrizione al programma è gratuita e semplicissima, e per effettuarla o semplicemente per avere qualche informazione è possibile visitare la pagina:

https://insider.windows.com/

Con tutta probabilità l’installazione delle distribuzioni Linux dello Store sarà disponibile per tutti dopo l’installazione del Fall Creators Update, l’aggiornamento della release di Windows che verrà distribuita a partire dal prossimo autunno.

Considerando quello che siamo in grado di fare con Windows Subsystem for Linux (https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm), ci chiediamo che differenza faccia utilizzare questo tipo di distribuzione rispetto a quella inclusa in Windows 10 a partire dall’Anniversary Update. Fondamentalmente non ci sono differenze, quello che cambia è la modalità di installazione, estremamente semplice, ed il fatto che la modalità di installazione che utilizzavamo fino ad ora sarà considerata “deprecata”, e probabilmente verrà dismessa. Dallo store, inoltre, sarà possibile scegliere la distribuzione da installare, operazione ad oggi possibile ma un po’ complessa.

L’app scaricata dallo store installa una distribuzione indipendente, che gira in una “sandbox” ed è quindi possibile installare più distribuzioni contemporaneamente per utilizzarle in maniera autonoma.

Se siete già in possesso di una macchina con Windows 10 Insider con una build maggiore o uguale a #16215, quindi, non vi resta che provarla; potete scaricare l’app Ubuntu direttamente da questo link:

https://www.microsoft.com/it-it/store/p/ubuntu/9nblggh4msv6

Noi non possiamo fare altro che seguire tutte le novità e le sorprese a cui Windows 10 ci sta abituando!

Configurazione di macchine Linux su Azure tramite DSC

In un articolo precedente (https://www.ictpower.it/guide/installare-e-configurare-powershell-desired-state-configuration-for-linux.htm) abbiamo visto come configurare un ambiente per il deploy automatico di packages tramite Desired State Configuration for Linux su client e server nella nostra rete locale.

Vediamo cosa succede nel caso in cui l’esigenza è quella di configurare delle macchine linux che si trovano invece sul cloud di Microsoft, da tutti conosciuto con il nome di Azure. Per questo esempio utilizzeremo una macchina Debian, creandola utilizzando uno dei template disponibili; per creare le risorse su Azure è necessario possedere una sottoscrizione attiva.

Iniziamo proprio creando le risorse necessarie su Azure, effettuiamo quindi il login su https://portal.azure.com e selezioniamo dal menu:

Nuovo -> Calcolo -> Ubuntu Server 16.04 LTS

Quindi facciamo click su Crea per avviare la configurazione di una macchina virtuale Ubuntu.

Un semplice wizard richiederà di compilare tutte le informazioni necessarie, quali tecnologia dei dischi da utilizzare, nome macchina, modalità di autenticazione e gruppo di risorse a cui associare la VM. Sceglieremo poi le risorse hardware, la configurazione della rete ed eventuali servizi aggiuntivi. In pochi minuti una notifica sulla pagina web del portale ci informerà del completamento dell’operazione, e la nostra macchina sarà raggiungibile tramite collegamento ssh direttamente sull’ip pubblico assegnato.

Il wizard chiede di assegnare un nome al gruppo di risorse che conterrà la macchina Ubuntu e tutti i servizi correlati (storage, rete, ecc…); questo nome verrà utilizzato in seguito per creare altre risorse. Per il mio esempio il nome del gruppo di risorse è LinuxDSC.

Allo stato attuale le versioni di OMIserver e dell’agent DSC non permettono il deploy corretto delle configurazioni nel caso queste prevedano l’installazione di pacchetti software. Essendo il nostro scopo proprio quello di installare dei servizi sulla macchina linux remota, è neccessario procedere all’aggiornamento dei due pacchetti. L’operazione è molto semplice e possiamo effettuarla direttamente connettendoci via SSH alla macchina remota. Io ho utilizzato Windows Bash, ma possiamo utilizzare putty o un qualsiasi altri client ssh.

Connettiamoci via SSH quindi all’IP pubblico che troviamo sul portale Azure, relativo alla nostra VM, ed eseguiamo sulla macchina linux i seguenti comandi per scaricare nella cartella /tmp le versioni (ad oggi) più recenti di OMI server e PowerShell DSC:

sudo wget https://github.com/Microsoft/omi/releases/download/v1.1.0-0/omi-1.1.0.ssl_100.x64.deb -P /tmp

sudo wget https://github.com/Microsoft/PowerShell-DSC-for-Linux/releases/download/v1.1.1-294/dsc-1.1.1-294.ssl_100.x64.deb -P /tmp

e li installiamo con:

sudo dpkg -i /tmp/omi-1.1.0.ssl_100.x64.deb /tmp/dsc-1.1.1-294.ssl_100.x64.deb

Possiamo verificare di avere le versioni corrette con i comandi:

sudo dpkg -l | grep dscsudo dpkg -l | grep omi

 

E’ possibile anche avviare una sessione SSH utilizzando PowerShell, ma è necessario installare un modulo aggiuntivo chiamato Posh-SSH, per aggiungere il supporto a questo protocollo. Il modulo è eventualmente disponibile sul sito PowerShell Gallery a questo indirizzo:

https://www.powershellgallery.com/packages/Posh-SSH/1.7.7

Per l’installazione, in ogni caso, è sufficiente aprire PowerShell come amministratore ed eseguire:

Install-Module -Name Posh-SSH

Volendo utilizzare i cmd-let di PowerShell per gestire la nostra sottoscrizione Azure abbiamo bisogno di installare anche i moduli Azure PowerShell, scaricando ed installando il pacchetto disponibile a questo link:

http://aka.ms/webpi-azps

A questo punto possiamo effettuare il login su Azure utilizzando ilcomando

Add-AzureRmAccount

Dopo aver inserito le credenziali, PowerShell ci risponde con i dettagli della sottoscrizione:

Nel caso esistano più sottoscrizioni con lo stesso account possiamo selezionare quella da utilizzare con i seguenti comandi:

#Connessione ad Azure

Add-AzureRmAccount

#Selezione subscription

$subscription (Get-AzureRmSubscription  Out-GridView -Title ‘Select an Azure Subscription …’  -PassThru)

Set-AzureRmContext -SubscriptionId $subscription.subscriptionId -TenantId $subscription.TenantID

E’ necessario quindi creare un ulteriore “Account di archiviazione” o “Storage Account” per ospitare le configurazioni DSC. Utilizziamo anche qui Azure PowerShell specificando il nome del nostro Resource Group, il nome del nuovo storageaccount da creare e la location. I valori disponibili per la variabile $Location ad oggi sono i seguenti: eastus, eastus2, eastus2stage, westus, westeurope, eastasia, southeastasia, japaneast, japanwest, northcentralus, southcentralus, centralus, northeurope, brazilsouth, australiaeast, australiasoutheast, southindia, centralindia, westindia, canadaeast, canadacentral, westus2, westcentralus, uksouth, ukwest, koreacentral, koreasouth

$ResourceGroupName “LinuxDSC”

$storageaccountName “dscdisk”

$Location “westeurope”

New-AzureRmStorageAccount -ResourceGroupName $ResourceGroupName -Name $storageaccountName -Type Standard_LRS -Location $Location

Al termine dell’elaborazione ci verrà restituito un messaggio di conferma

Possiamo verificare che il nuovo storage account è disponibile sul portale Azure:

Creiamo ora un container all’interno dello storage account; per non appesantire la guida creiamo il container con “Permission -Off” rendendo accessibile il container solo al proprietario. Essendo le variabili già definite eseguiamo:

Set-AzureRmCurrentStorageAccount -ResourceGroupName $ResourceGroupName -Name $storageaccountName

New-AzureStorageContainer -Name linuxdsc -Permission Off

Il container è subito disponibile, e ce lo conferma la risposta nella PowerShell

Ora prepariamo la nostra macchina per eseguire il push della configurazione, nel mio caso sto utilizzando una macchina con Windows 10 Pro. Abbiamo bisogno di installare il modulo DSC for Linux, quindi eseguiamo da una PowerShell con diritti amministrativi il comando:

Install-Module –name nx

In alternativa è possibile effettuare il download del pacchetto MSI da:

https://www.microsoft.com/en-us/download/details.aspx?id=46919

ed installarlo utilizzando le opzioni predefinite. L’installazione provvederà ad aggiungere il modulo nx, necessario per l’utilizzo di DSC for Linux nella cartella

%USERPROFILE%\Documents\WindowsPowerShell\Modules

Tutto è pronto per la preparazione di uno script di configurazione, che per l’occasione consisterà nell’installazione automatizzata del servizio httpd sulla nostra macchina Azure con sistema operativo Ubuntu. Lo script è molto semplice, e va eseguito direttamente da PowerShell. Consiste in una prima parte di dichiarazione della configurazione ed una seconda in cui viene eseguito il comando per generare il file .mof che DSC utilizzerà per eseguire il push sulla macchina remota.

Personalmente ho avuto un po’ di problemi nell’incollare lo script nella finestra PowerShell poiché venivano stranamente aggiunti caratteri in modo casuale corrompendo il testo incollato. Non sapendo se il problema dipende da qualcosa di particolare nella mia situazione, mostro comunque il workaround utilizzato.

Ho incollato lo script direttamente nell’ISE e salvato in formato .ps1, quindi ho richiamato l’esecuzione dello script direttamente da PowerShell. Per aprire l’ISE è sufficiente cercare PowerShell ISE nella barra della ricerca di Windows, o lanciare il comando ISE da PowerShell.

Lo script utilizzato è il seguente:

Configuration
ubuntuconf {


Import-DscResource -Module nx


Node “localhost” {

    nxPackage
Apache {

        PackageManager ‘Apt’

        Ensure ‘Present’

        Name ‘apache2’

    }

}

}

ubuntuconf -OutputPath: “C:\temp”

Salviamo lo script ad esempio con il nome conf.ps1 e lo eseguiamo da PowerShell:

.\conf.ps1

Verrà creato un file chiamato <nomehost>.mof nella directory indicata nello script; questo file è il modello che DSC confronterà con lo stato attuale della macchina da configurare, effettuando in maniera automatizzata le eventuali operazioni di adeguamento. Nel nostro caso, ad esempio, si assicurerà che il pacchetto apache2 sia installato.

Trasferiamo questo file all’interno del container che abbiamo creato su Azure con il comando PowerShell:

Set-AzureStorageBlobContent -Container linuxdsc -File C:\temp\localhost.mof

Anche in questo caso possiamo verificare dal portale Azure che il nostro contenitore include il file .mof che abbiamo appena inviato

Ora è necessario configurare i privilegi di accesso su questo file per fare in modo che la nostra macchina Ubuntu sia in grado di leggerlo. A costo di complicare un po’ la procedura evitiamo di ottenere un link pubblico impostando l’accesso con autenticazione tramite Shared Access Signatures (SAS), creando un opportuno token. Possiamo impostare un limite di tempo per la validità di questo token, e per questo esempio imposteremo 1 mese.

$templateuri New-AzureStorageBlobSASToken -Container linuxdsc -Blob ‘localhost.mof’ -Permission -ExpiryTime (Get-Date).AddMonths(1) -FullUri

Il comando

echo $templateuri

ci restituirà il valore da utilizzare nello script DSC descritto successivamente. Infine otteniamo l’elenco delle chiavi disponibili con il commando:

Invoke-AzureRmResourceAction -ResourceGroupName $ResourceGroupName -ResourceType Microsoft.Storage/storageAccounts -ResourceName $StorageAccountname -Action listKeys -ApiVersion 2015-05-01-preview -Force -OutVariable keys

Essendo sufficiente al nostro scopo la key1, per ottenere la chiave da utilizzare nel prossimo script possiamo eseguire eseguire da PowerShell:

$keys[0].key1

Siamo pronti quindi ad effettuare il deploy della nostra configurazione eseguendo uno script PowerShell DSC; per personalizzare lo script abbiamo bisogno di tenere presente le variabili relative allo storage account ed alle chiavi che permettono la lettura del file mof. Le variabili sono:

StorageAccountName (il nome dell’account archivio creato nel primo step), StorageAccountKey (La key1 restituita dal comando precedente), FileUri (Il valore restituito dopo l’upload del file mof), vmname (il nome della risorsa della macchina virtuale su Azure)

Eseguiamo il cmd-let per conoscere l’ultima versione di DSCforLinux disponibile

$extensionName ‘DSCForLinux’

$publisher ‘Microsoft.OSTCExtensions’

Get-AzureRmVMExtensionImage -PublisherName Microsoft.OSTCExtensions -Location $location -Type DSCForLinux

E settiamo la variabile version utilizzando questa versione

$version ‘2.2’

Poi settiamo le variabili relative all’autenticazione:

$privateConfig 

‘{

“StorageAccountName”: “linuxdsc”,

“StorageAccountKey”: “//storageaccountkey//”

}’

$publicConfig ‘{

“Mode”: “Push”,

“FileUri”: “//fileuri//”

}’

E finalmente lanciamo il deploy del modello che avevamo creato sulla vm Linux su Azure, avendo cura di settare la variabile $vmName indicando il nome della VM su Azure, nel mio caso:

$vmName=“LNXClient01”

Set-AzureRmVMExtension -ResourceGroupName $ResourceGroupName -VMName $vmName -Location $location -Name $extensionName -Publisher $publisher -ExtensionType $extensionName -TypeHandlerVersion $version -SettingString $publicConfig -ProtectedSettingString $privateConfig

Un messaggio di OK ci conferma l’avvenuto deploy della configurazione. In questo caso abbiamo installato il pacchetto apache2 (Webserver apache) sulla nostra macchina di test.

Nel caso si verificassero degli errori è possibile analizzare i log direttamente sulla macchina Linux; possiamo trovare informazioni dettagliate sulle operazioni relative a DSC nel file /var/log/azure/DSCForLinux/<versione>/extension.log

Per verificare il funzionamento del servizio creiamo dal portale Azure una regola di firewall all’interno delle risorse di tipo “Gruppo sicurezza di rete” per consentire le connessioni sulla porta 80 (servizio http), e proviamo ad aprire un browser navigando direttamente sull’ip pubblico della nostra macchina.

Il webserver è attivo e raggiungibile dall’esterno

Possiamo ora divertirci a provare infinite configurazioni, ricordando che DSC è in grado di effettuare tantissime operazioni sulla macchina client, fra le quali gestione di file e cartelle, installazione e rimozione di pacchetti, gestione gruppi e utenti ed esecuzione di script.

Personalmente credo che questa funzionalità abbia un potenziale davvero enorme, e sembra quasi incredibile come su una infrastruttura proprietaria Microsoft sia possibile utilizzare servizi di automazione completamente Open Source.

Switch delle shell Linux con Windows 10 WSL

Sono passati 9 mesi dal rilascio di Windows 10 Anniversary Update, l’aggiornamento del sistema operativo che ha introdotto la funzionalità Windows Subsystem for Linux (WSL), grazie alla quale è possibile eseguire su Windows i binari di tipo ELF64, compilati cioè per funzionare su un sistema operativo Linux.

All’interno della community ICTPower ci siamo spesso occupati di questa nuova funzionalità, poiché ribadisce con forza la volontà di Microsoft di avvicinare il mondo dell’Open Source, e costituisce quindi una delle novità più importanti della politica aziendale degli ultimi tempi.

Rimandiamo quindi agli articoli precedenti in cui abbiamo illustrato gli step per l’installazione di questa funzionalità:

https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm

e mostrato come sostituire l’immagine di Ubuntu di default con una contenente Suse:

https://www.ictpower.it/guide/opensuse-in-windows-subsystem-for-linux-in-windows-10.htm

In questo articolo, invece, presentiamo un progetto molto interessante che è possibile trovare su github, chiamato WSL Distribution Switcher. Come è possibile intuire dal nome si tratta di un tool in grado di tenere installate sul nostro client Windows 10 molteplici distribuzioni di Linux, ed impostare quella in uso con WSL con un semplice comando.

Finalmente, quindi, ognuno è libero di utilizzare la propria distribuzione preferita, e l’occasione è imperdibile per chi si sta avvicinando al mondo Linux per la prima volta per provare le differenze tra le varie distribuzioni senza creare un numero enorme di macchine virtuali, e scegliere quella più adatta alle proprie esigenze. L’occasione è imperdibile anche per me, poiché utilizzando in maniera molto più agevole CentOS rispetto alle altre, finalmente ho la possibilità di farlo anche con WSL.

Come premessa riporto la pagina del progetto è la seguente, in modo da poterla seguire per tutti gli aggiornamenti futuri:

https://github.com/RoliSoft/WSL-Distribution-Switcher

Il tool è costituito da una serie di immagini, una per ogni distribuzione di Linux, ed uno script per effettuare lo switch da una distribuzione all’altra. Lo script è scritto in Python, un linguaggio di programmazione molto semplice e dinamico, e quindi abbiamo bisogno di installare le relative librerie per utilizzarlo.

Scarichiamo l’ultima versione di Python3 dal sito python.org, ad oggi troviamo la versione 3.6.1 disponibile a questo link:

https://www.python.org/ftp/python/3.6.1/python-3.6.1-amd64.exe

ed installiamo il pacchetto lasciando le impostazioni di default:

Scarichiamo quindi il pacchetto contenente il tool dall’indirizzo:

https://github.com/RoliSoft/WSL-Distribution-Switcher/archive/master.zip

Ed estraiamo l’archivio, ad esempio nella cartella Download

Nel mio caso particolare tutti i file sono nella cartella:

C:\Users\ICTPower\Downloads\WSL-Distribution-Switcher-master

Apriamo una PowerShell e posizionamoci in questa cartella. Per eseguire semplicemente questa operazione è possibile scrivere “powershell” nella barra degli indirizzi della cartella stessa, ed avviamo il download della distribuzione desiderata utilizzando lo script get-source. Iniziamo, ad esempio, scaricando un’immagine di CentOS con il comando:

py.exe .\get-source.py centos

Allo stesso modo è possibile effettuare il download di debian, fedora, suse ed alpine; in futuro saranno sicuramente disponibili immagini di altre distribuzioni. Per eseguire lo step successivo è necessario che WSL sia installato ma non attivo, quindi non dovranno essere aperte istanze di Windows bash al momento dell’esecuzione del comando altrimenti lo script restituirà un errore.

Scaricata l’immagine la installiamo con:

py.exe .\install.py centos

Al termine delle operazioni l’immagine appena installata diventa quella di default all’apertura di Windows bash, verifichiamolo subito aprendo una shell eseguendo dal prompt dei comandi:

bash

e leggiamo il contenuto del file /etc/os-release, che nelle distribuzioni CentOS ci da un po’ di informazioni sulla versione in uso

cat /etc/os-release

Come possiamo vedere ci troviamo su una CentOS7, loggati nel sistema con l’utente creato in fase di installazione di WSL. Nel mio caso il nome dell’utente è gnanoia. Ho trovato un problema nell’eseguire il comando “su” e guadagnare i privilegi di root. Al momento della richiesta della password, infatti, questa non veniva riconosciuta. Non avendo modo di indagare se il problema fosse dovuto alla versione dell’immagine, alla mia build di Windows10 o ad altri fattori, ho trovato un rapido workaround settando l’utente root come predefinito all’apertura di Windows bash; in questo modo la shell viene avviata senza la richiesta di alcuna password ed è possibile eseguire il comando “passwd” per settarne una nuova. E’ poi possibile reimpostare l’utente non privilegiato come predefinito per tornare alla condizione iniziale.

E’ possibile modificare l’utente predefinito di WSL utilizzando il comando lxrun /setdefaultuser <user>, quindi nel nostro caso eseguiamo da un prompt di DOS:

lxrun /setdefaultuser root

quindi apriamo bash e modifichiamo la password con il comando

passwd

chiudiamo la shell di root con

exit

chiudimo la shell iniziale per tornare al DOS con

exit

e risettiamo l’utente iniziale come predefinito. Nel mio caso:

lxrun /setdefaultuser gnanoia

Tutta la sequenza è visibile nello screenshot seguente:

Proviamo ora ad avviare bash ed utilizzare su per utilizzare la shell con privilegi amministrativi:

Ora la nostra immagine Centos7 è completa e funzionante, e possiamo utilizzare il gestore dei pacchetti yum per installare i nostri software preferiti.

Da un’analisi più approfondita però sono emerse delle limitazioni dovute alla tenera età di WSL, per cui non risulta possibile installare alcuni pacchetti, probabilmente per la mancanza del supporto ad alcune syscall; non ci rimane che essere pazienti e sperare che questa funzionalità cresca il più velocemente possibile chissà che nella prossima build di Windows10 non sia già tutto perfettamente funzionante.

In particolare i test di installazione sono falliti per iptools ed httpd, nello screenshot seguente vediamo il dettaglio dell’errore:

yum install httpd

Alla fine dell’elaborazione del comando il risultato sarà quello mostrato in figura:

Senza allarmarci troppo, quindi, fiduciosi di una rapida risoluzione, non perdiamo troppo di vista lo scopo dell’articolo, e torniamo all’installazione di distribuzioni alternative di Linux per WSL, provando ad effettuare in maniera rapida lo switch da una all’altra.

Torniamo quindi sulla nostra PowerShell per scaricare ed installare un’immagine di debian.

Come per l’installazione precedente, lo script imposta l’ultima immagine installata come predefinita, quindi avviando Windows bash ci aspettiamo di trovare una shell Debian. Infatti…

Per switchare da una distribuzione all’altra non è ovviamente necessario reinstallarla, quindi volendo tornare ad utilizzare CentOS, od una qualsiasi altra distribuzione già installata possiamo ricorrere allo script per lo switch:

py.exe .\switch.py centos

Verifichiamo che l’operazione ha avuto successo riaprendo bash e leggendo il file /etc/os-release

Ringraziamo sentitamente gli autori dello script, e rimaniamo in attesa della disponibilità delle nostre immagini preferite; anche in questo caso non possiamo fare a meno di notare che l’avvicinamento di Microsoft al mondo dell’Open Source sta scatenando una miriade di contributi di chi, ognuno a modo proprio, cerca di favorire la completa integrazione dei sistemi.

X server e Desktop App con Windows Subsystem for Linux

Nel codice etico del bravo tecnico, ed ancor più in quello del consulente informatico, esiste la rigida regola di utilizzare e proporre sempre soluzioni supportate dai produttori. Perché tenere un’azienda ferma minuti, ore, o addirittura giorni perché i sistemi si bloccano, non rispondono quello che ci aspettiamo, e non poter chiedere aiuto a nessuno non è mai piacevole.

Ci sono delle situazioni, però, in cui utilizzare soluzioni non supportate è tollerato, se non addirittura una necessità. I motivi possono essere i più disparati: hardware o software oltre la data di “End of Support” a cui non esiste un’alternativa, budget limitato, incompatibilità con sistemi esistenti, e mille altre ragioni più o meno tecniche.

Immaginiamo ad esempio di dover dismettere un vecchissimo computer linux che ospita il gestionale di un commercialista. Il gestionale non viene più utilizzato, ma sarebbe comodo poterne utilizzare alcune funzionalità nel caso ce ne fosse bisogno. Il gestionale è scritto per funzionare su una macchina Linux con interfaccia grafica, ed il commercialista ci chiede se possiamo spostare questo software sul suo client Windows10 prima di dismettere il vecchio computer.

Poiché ormai avendo più volte letto l’articolo Windows Subsystem for Linux: finalmente in una release ufficiale sappiamo installare ed utilizzare Windows Subsystem for Linux (WSL), proviamo ad installare tutto il necessario per far girare dei software Linux che utilizzano una interfaccia grafica. Proviamo quindi a configurare un server X su Ubuntu, ed utilizzarlo per lanciare degli eseguibili.

Ci ritroviamo quindi nella condizione di dover utilizzare una funzionalità non supportata: WSL, infatti, è pensato per poter utilizzare degli eseguibili Linux in ambiente Windows 10 limitatamente alla riga di comando, e dobbiamo tenere presente alcune cose mentre cerchiamo di mettere a punto questa forzatura:

  • Il server X effettua delle chiamate al Kernel Linux, che nel nostro caso è un sistema formato da delle librerie per la traduzione delle chiamate di sistema ed un Kernel Windows. Il “sistema di traduzione” non è pensato per gestire delle Desktop App
  • L’ambiente che utilizziamo in WSL è in User Mode, quindi qualsiasi chiamata che richiede un livello di esecuzione più basso (Kernel mode) fallisce
  • La gestione dei Bus di Linux è completamente diversa da quella di Windows, quindi molte “istruzioni” potrebbero non funzionare correttamente

Considerando, però, che non abbiamo niente da perdere proviamo ad installare X server – il gestore grafico di Linux. X server (conosciuto anche semplicemente come X) è il servizio di base per l’utilizzo di qualsiasi interfaccia grafica; essendo Linux un sistema open, infatti, esistono molte interfacce grafiche diverse. Uno dei nostri problemi, quindi, sarà anche cercare l’interfaccia più adatta al nostro scopo. Io ho scelto Unity ed LXDE, laprima perché è prodotta da Canonical per Ubuntu, e per questo motivo mi aspetterei maggiore compatibilità, la seconda perché è molto leggera e mi piace graficamente.

Avvio delle applicazioni in finestra

Passiamo finalmente alla pratica, e grazie ad apt-get installiamo da root i pacchetti ubuntu-desktop e unity.

Per guadagnare i privilegi di root eseguiamo da utente

sudo bash

ed inseriamo la password scelta in fase di configurazione di WSL

Installiamo quindi i pacchetti con

apt-get install ubuntu-desktop unity


Il sistema propone un download di 569MB (potrebbe variare a seconda delle versioni), che diventeranno 2Gb di software. Confermiamo ed attendiamo speranzosi…

Al termine dell’installazione possiamo notare che ci sono degli errori relativi al dbus, il sottosistema di scambio messaggi tra applicazioni presente sul sistema operativo Linux, che utilizza funzioni non ancora implementate su WSL. In mancanza di questo, le funzionalità grafiche non saranno disponibili; vediamo quindi come modificare la configurazione del servizio in questione per renderlo utilizzabile.

Quello che andremo a fare è modificare il “mezzo” su cui viaggiano questi messaggi dai socket linux predefiniti (e non implementati), al prococollo TCP. E’ necessario quindi sostituire nel file

/etc/dbus-1/session.conf,

La riga

<listen>unix:tmpdir=/tmp</listen>

con

<listen>tcp:host=localhost,port=0</listen>

E’ possibile effettuare la sostituzione con un editor di testo oppure con il comando:

sudo sed -i 's$<listen>.*</listen>$<listen>tcp:host=localhost,port=0</listen>$' /etc/dbus-1/session.conf

Installiamo ora il tool per la configurazione dell’interfaccia grafica Unity, chiamato per brevità ccsm

apt-get install compizconfig-settings-manager

L’installazione di pochi mega termina senza problemi e siamo pronti per provare ad avviare il nostro server grafico.

Generalmente una macchina Linux ha la possibilità di “disegnare” le finestre attraverso i messaggi scambiati tra il server X e il sottosistema video. Il kernel Windows, però, – ricordiamo che l’unico kernel in uso è quello Windows, non essendo WSL una macchina virtuale- non è in grado di comprendere questi messaggi, ed abbiamo la necessità di installare un software per scambiare i messaggi con il server X di Linux.

In termini pratici per visualizzare l’ambiente desktop abbiamo bisogno di utilizzare un X server anche sulla macchina Windows, e siamo costretti a ricorrere a software di terze parti (ce ne sono molti open source); è proprio questo il motivo per cui questa soluzione non è attualmente supportata da Microsoft.

Per questo esempio utilizziamo vcXsrv (https://sourceforge.net/projects/vcxsrv/), ma nessuno ci vieta di provare CygWinX (http://x.cygwin.com/), Xming (https://sourceforge.net/projects/xming/) oppure mobaXterm (http://mobaxterm.mobatek.net/).

Quindi scarichiamo da https://sourceforge.net/projects/vcxsrv/files/latest/download ed installiamo banalmente l’applicazione vcXsrv (oggi alla versione 64.1) con le opzioni di default.

Lanciamo quindi vcXrsv dopo averlo cercato nelle app ed esportiamo la variabile display da Windows bash per presentare all’X server di Windows le finestre che andremo ad aprire. Eseguiamo quindi:

export DISPLAY=:0

Proviamo ad aprire qualche tool Linux con interfaccia grafica, iniziando con qualcosa di semplicissimo:

xcalc

Si, è vero, c’è Windows Calc che è molto più comodo, ma non dimentichiamo che stiamo facendo tutto questo per il nostro povero commercialista. Proviamo a spingerci un po’ oltre:

Da Windows bash proviamo a vedere cosa succede digitando:

firefox

Beh, abbiamo un bel po’ di warning che ci avvisano che non è possibile utilizzare il multithreading, ma abbiamo un browser attivo e funzionante.

Visualizzazione del Desktop Linux

Vediamo cosa succede se installiamo un server VNC su WSL e proviamo a connetterci con il proprio viewer; questa volta utilizzeremo LXDE, un altro ambiente Desktop Open Source per Linux. Installiamo LXDE e server vnc con un semplice

sudo apt-get install xorg lxde-core tightvncserver

avviamo per la prima volta il servizio vnc ed impostiamo una password

tightvncserver :1


Ora la configurazione è stata creata e possiamo stoppare vnc server:

tightvncserver -kill :1

e possiamo modificare il nostro file di configurazione per creare la sessione server utilizzando LXDE; è sufficiente aprire con un editor di testo il file xstartup

nano ~/.vnc/xstartup

La notazione ~ serve ad indicare la home dell’utente così come avviene nella PowerShell di Windows. Il file xstartup, infatti, si trova nella cartella .vnc (sotto Linux il punto iniziale indica una cartella nascosta), che a sua volta si trova all’interno del profilo utente corrente.

All’interno del file dobbiamo poi aggiungere queste righe posizionandole in fondo alla configurazione:

lxterminal &

/usr/bin/lxsession -s LXDE &

Il file diventerà così:

Salviamo con ctrl-x e yes e riavviamo il servizio tightvnc

tightvncserver :1

Passiamo poi al “client” Windows: scarichiamo VNC Viewer ed installiamolo. Possiamo scaricare il viewer da questa pagina: https://www.realvnc.com/download/viewer/

Eseguiamolo ed apriamo una connessione verso localhost:5901, la porta di default che identifica il display 1

Confermiamo che siamo coscienti di utilizzare una connessione non criptata ed immettiamo la password scelta in precedenza.

Et Voilà, il desktop della nostra macchina Linux, anzi della nostra macchina Windows su cui gira un desktop Linux J

Non ci rimane che provare a copiare il software del commercialista, e con un po’ di fortuna potremmo avergli risolto un bel problema! Ricordiamo che anche dal Desktop abbiamo accesso a tutto il filesystem Windows, trovando il contenuto del nostro volume C:\ all’interno del path Linux /mnt/

Utilizzo di un server X Windows

Un’altra possibilità, forse ancora più elegante, per utilizzare l’interfaccia grafica Linux è quella di esportare la variabile DISPLAY come abbiamo fatto in precedenza per xcalc e firefox, e lanciare non più una singola applicazione desktop, ma l’intera interfaccia grafica. Proviamo a vedere cosa succede lanciando l’interfaccia installata in precedenza: unity.

Lanciamo il server X di Windows con i settings avanzati aprendolo tramite l’uility XLaunch, richiamando la stessa dalle app di Windows; impostiamo quindi un’unica finestra ed il display numero 0 e lasciamo le restanti opzioni con i valori di default.

Ricordiamo da Windows bash di esportare il display se non è stato fatto con

export DISPLAY=:0

e lanciamo la configurazione dell’ambiente grafico Linux con

ccsm

Aggiungiamo le spunte per l’abilitazione delle funzionalità necessarie così come negli screenshot seguenti

Dopo aver cliccato su Close, saremo in grado di lanciare l’interfaccia grafica di unity digitando

compiz

direttamente dalla riga di comando di Windows bash. Io in questo caso non sono stato molto fortunato, e come segnalano molti possessori di schede video Nvidia, ho ottenuto un crash dell’applicazione nel momento in cui ha inizializzato le librerie OpenGL.

Al momento non sono riuscito a trovare un workaround valido, ma ho voluto segnalare comunque l’intera procedura perché, su diversi dispositivi questa va a buon fine.

Lo scopo di questo articolo è ovviamente andare un po’ più a fondo sulle potenzialità offerte da WSL, ritenendolo una funzionalità davvero particolare e interessante.

A questo punto posso svelarvi il segreto che ho tenuto nascosto per tutta la durata dell’articolo: non esiste nessun commercialista J

openSUSE in Windows Subsystem for Linux in Windows 10

Con il rilascio dell’Anniversary update è stata aggiunta a Windows 10 una funzionalità molto particolare, chiamata Windows Subsystem for Linux (WSL), che consente di eseguire dei binari di tipo ELF64 (eseguibili compilati in modalità nativa Linux), direttamente su Windows, senza l’ausilio di macchine virtuali o emulatori di terze parti.

In questo articolo (https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm) abbiamo visto come abilitare questa funzionalità, e come durante l’installazione il sistema scarichi dal Windows Store il pacchetto Ubuntu for Linux, distribuzione prodotta da Microsoft e Canonical appositamente per l’integrazione su Windows.

L’aggiunta di questa funzionalità, passata forse in sordina nei primi tempi, sta ora suscitando qualche gelosia da parte di chi produce distribuzioni Linux a livello commerciale, che vede la possibilità di far conoscere la propria distribuzione ad un pubblico più ampio, sfruttando la popolarità di Windows 10 a livello client. E’ il caso di Hannes Kühnemund, senior Product Manager di SUSE, che in una recente dichiarazione ha affermato che Microsoft per il suo WSL stesse utilizzando la distribuzione errata di Linux, sostenendo che SUSE esiste da molto più tempo rispetto ad Ubuntu, e per questo sicuramente avrebbe meritato maggiore attenzione.

La dichiarazione è stata opportunamente accompagnata dal rilascio, in versione non ufficiale, del pacchetto openSUSE Leap 24.2 integrabile in WSL. OpenSUSE Leap è la versione Open della distribuzione commerciale SUSE Enterprise, ed è quindi possibile scaricarla ed installarla liberamente su qualsiasi client Windows, a patto che sia stata precedentemente attivata la funzionalità WSL, e che durante il relativo wizard di installazione sia stato creato un utente con password.

Non ci rimane che mettere alla prova questa nuova distribuzione, iniziando in primis a capire se questo pacchetto rispetta le promesse circa la possibilità di utilizzarlo senza problemi con Windows 10. Ci aspettiamo, quindi, di poter avviare openSUSE bash, ed utilizzare il gestore dei pacchetti Zypper così come utilizziamo apt-get su Ubuntu.

Per comprendere tutti i passaggi dell’installazione è importante analizzare il filesystem di Windows, individuando la cartella in cui lavora WSL, ossia la cartella dove sono presenti tutti i file relativi al sottosistema linux. Il sistema è composto da due parti fondamentali: la prima comprende tutti i binari e i file di configurazione della distribuzione, la seconda comprende tutto il resto, tra cui ad esempio i dati utente o il path in cui sono montati i dischi Windows. Il tutto si trova nella cartella (nascosta) %localappdata%\lxss. Nel mio caso, ad esempio, il sottosistema Linux si trova nella cartella:

C:\Users\ICTPower\AppData\Local\lxss

Qui troviamo la cartella rootfs, all’interno della quale c’è il sistema operativo Linux vero e proprio insieme ad altre cartelle, tra cui quelle relative agli utenti (home) e quella in cui vengono montati i volumi di Windows (mnt). Notiamo la presenza del file bash.ico, che andremo a modificare in seguito. Lo screenshot seguente mostra come si presenta la cartella %localappdata%\lxss vista dal sistema operativo Windows.

Vediamo, inoltre, che all’interno della cartella rootfs è presente il sistema operativo base:

La cartella %localappdata%\lxss\rootfs\home è vuota, poiché il profilo dell’utente Linux, nel mio caso chiamato gnanoia, si trova nella cartella home al livello superiore, cioè %localappdata%\lxss\home

Ho preferito essere un po’ puntiglioso per questo semplice chiarimento perché è di fondamentale importanza per eseguire correttamente i passaggi seguenti dell’installazione.

L’idea è infatti quella di sostituire la cartella base del sistema operativo (la cartella rootfs con Ubuntu per intenderci), con la corrispondente openSUSE, presente nel pacchetto rilasciato pochi giorni fa.

Iniziamo quindi scaricando il pacchetto openSUSE-42.2.tar.xz, che è l’immagine di un “container” basato su openSUSE. Non approfondiremo in questa sede il concetto di container, rimandando i più curiosi al video presente su questa pagina (https://www.nicolaferrini.it/ita/blog/871-techeroes-come-funzionano-i-container-con-docker.html), ma teniamo solo presente che stiamo effettuando il download di una distribuzione Linux “pronta all’uso”, come se avessimo “catturato” l’immagine base di una macchina openSUSE già installata.

Per iniziare, quindi, apriamo Windows Bash (bash on Ubuntu on Windows) ed eseguiamo:

wget -O openSUSE-42.2.tar.xz https://github.com/openSUSE/docker-containers-build/blob/openSUSE-42.2/docker/openSUSE-42.2.tar.xz?raw=true

Notiamo che all’avvio di Windows bash la cartella di lavoro corrente corrisponde alla home dell’utente Linux, e quindi il download sarà eseguito nella cartella \home\<nomeutente>, e quindi il percorso completo del file scaricato nel mio caso sarà: \home\gnanoia\openSUSE-42.2.tar.xz

Ora creiamo con permessi di root (quindi utilizzando il comando sudo) una cartella chiamata rootfs all’interno della nostra home, estraiamo l’immagine scaricata all’interno di questa cartella, e chiudiamo la shell.

sudo mkdir rootfs

sudo tar -C rootfs -Jxf openSUSE-42.2.tar.xz

exit

A seconda della release di WSL in uso potrebbero essere visualizzati degli errori relativi alla syscall MKNOD, che potrebbe risultare non supportata. Possiamo tranquillamente ignorare gli errori poiché la nostra necessità è semplicemente quella di scompattare l’archivio.

A questo punto dobbiamo sostituire la cartella rootfs originale (quella con Ubuntu) con quella appena creata; poiché questa operazione viene eseguita su cartelle in uso da WSL è necessario stoppare il relativo servizio per proseguire. Eseguiamo quindi da un prompt di DOS con privilegi elevati:

net stop lxssmanager

Possiamo quindi rinominare la cartella %localappdata%\lxss\rootfs in %localappdata%\lxss\rootfs.ubuntu, e copiare al suo posto la cartella con il pacchetto openSUSE appena estratto (la troviamo su %localappdata%\lxss\home\rootfs).

Questa operazione può ovviamente essere eseguita con Windows Explorer o con i seguenti comandi da un prompt di DOS:

cd %localappdata%\lxss\

rename rootfs rootfs.ubuntu

move .\home\<nomeutente>\rootfs .\

Lo screenshot seguente mostra le operazioni eseguite per la sostituzione della cartella rootfs

Possiamo quindi avviare nuovamente il servizio lxssmanager:

net start lxssmanager

L’ultimo passo è quello di settare l’utente predefinito della nuova distribuzione. Non essendo presenti utenti oltre a root sull’immagine openSUSE possiamo eseguire da DOS:

lxrun /setdefaultuser root

Per finire il lavoro con eleganza possiamo sostituire l’icona %localappdata%\lxss\bash.ico (preferibilmente rinominandola ubuntu.ico) con quella di openSUSE scaricabile da:

http://www.iconarchive.com/download/i46667/saki/nuoveXT/Apps-suse.ico

e rinominare con “bash in openSUSE on Windows” il collegamento presente in

C:\Users\<nomeutente>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs

O crearne uno nuovo sul Desktop

Per lo screenshot finale accompagnato dagli applausi del pubblico scegliamo di eseguire il comando

cat /etc/os-release

che ci mostrerà distribuzione e release attualmente in uso

Come promesso vediamo come si comporta il manager di pacchetti, provando ad installare apache utilizzando zypper; se tutto è a posto dovrebbe bastare un semplice comando:

zypper in apache2

Creiamo ora un semplice file index:

echo "Hello World" > /srv/www/htdocs/index.html

Avviamo apache:

httpd

E navighiamo su http://127.0.0.1

Direi che è proprio quello che ci aspettavamo, solo ora mi sento di affermare che è possibile utilizzare anche un userspace openSUSE, e quindi SUSE Linux Enterprise Server su Windows Subsystem for Linux.

Preferire Ubuntu o SUSE a questo punto è una scelta puramente personale, se non fosse così d’altro canto non si chiamerebbero sistemi open 😀

Se invece siete arrivati fin qui per sapere cosa preferisco io… beh… sono in attesa del rilascio di CentOS 😀

Installare e configurare PowerShell Desired State Configuration for Linux

Panoramica

PowerShell Desired State Configuration, più semplicemente conosciuta come PowerShell DSC, è una piattaforma utilizzabile all’interno di Windows PowerShell, che permette di eseguire alcune operazioni di configurazione su delle macchine definite “Target”. I Target possono essere server singoli o gruppi di server, o anche semplici client. Tramite questa funzionalità è possibile esaminare la configurazione attuale di un sistema, confrontarla con un modello, ed eseguire in maniera automatica le operazioni per allineare il sistema a quel modello. PowerShell DSC è in grado di effettuare molte operazioni al fine di rendere la configurazione compatibile con il modello, tra cui:

  • Gestione di file e cartelle
  • Installazione e rimozione di ruoli e funzionalità
  • Gestione gruppi e utenti
  • Esecuzione di script PowerShell

E’ possibile utilizzare DSC per automatizzare la configurazione anche di ambienti complessi, per poterli facilmente replicare ad esempio in siti diversi; esistono, a tal proposito, repository come PowerShell Gallery (https://www.powershellgallery.com/) dove è possibile scaricare delle configurazioni già pronte, da applicare ad ambienti diversi.

La distribuzione delle configurazioni avviene tramite un server di pull, che oltre a comandare l’esecuzione dei vari script e dare il via al cambio di configurazione delle macchine, si occupa di generare dei report sullo stato delle macchine stesse, ed aiutare quindi l’amministratore a monitorare il sistema in tempo reale.

PowerShell DSC è stata introdotta con Windows 2012 R2 ma può essere utilizzata su sistemi precedenti implementando Windows Management Framework (WMF). In ogni caso è necessario disporre di PowerShell almeno versione 4.

Con l’introduzione di PowerShell for Linux, a partire da Maggio 2015, Desired State Configuration è disponibile anche su questo sistema operativo; è possibile quindi attraverso il server di pull gestire sia macchine Windows che macchine Linux. Proviamo ad installarlo e comprenderne un po’ le potenzialità.

Prerequisito fondamentale per l’utilizzo di PowerShell DSC su Linux è l’installazione di Open Management Infrastructure (OMI), un sistema di management per dispositivi di Networking, Server, Stampanti, ecc… che comunica con i protocolli CIM e WSMAN. Non entreremo troppo nel dettaglio del funzionamento di questi protocolli, ma diamo per assodato che si tratta di un sistema che si propone di diventare uno standard universale per il management di qualsiasi tipo di macchina, sia esso un computer, un server, un apparato di rete o una periferica.

Altri prerequisiti per il funzionamento di Linux DSC sono:

  • glibc almeno v2.4
  • python almeno v2.4
  • openssl OpenSSL v0.9.8 o v1.0
  • ctypes stessa versione di python
  • libcurl v7.15.1

La macchina Linux utilizzata per i test e gli screenshot relativi a questo articolo è una CentOS 7, quindi tutti i comandi e i percorsi utilizzati si riferiscono a questa distribuzione. In particolare la macchina utilizzata ha IP 192.168.12.10; ogni volta che sarà indicato questo indirizzo IP all’interno di una configurazione sappiamo quindi che ci stiamo riferendo alla nostra macchina Linux. Per distribuzioni diverse da CentOS sarà ovviamente necessario utilizzare i percorsi ed i package manager corrispondenti.

PowerShell DSC è supportato infatti anche su altre distribuzioni. La pagina di riferimento su GitHub ad oggi riporta che è possibile installare questa funzionalità su:

  • CentOS 5, 6, and 7 (x86/x64)
  • Debian GNU/Linux 6 and 7 (x86/x64)
  • Oracle Linux 5, 6 and 7 (x86/x64)
  • Red Hat Enterprise Linux Server 5, 6 and 7 (x86/x64)
  • SUSE Linux Enterprise Server 10, 11 and 12 (x86/x64)
  • Ubuntu Server 12.04 LTS and 14.04 LTS (x86/x64)

Partiamo quindi dall’installazione dei prerequisiti; un’unica istruzione yum installerà tutti i pacchetti eventualmente mancanti ed aggiornerà quelli obsoleti:

yum install glibc python openssl python-ctypes libcurl

Passiamo ora all’installazione di Open Management Infrastructure (OMI) versione 1.0.8.4 (l’ultima al momento della stesura dell’articolo)

In primo luogo verifichiamo quale versione di openssl è installata sul nostro sistema con

openssl version

e cerchiamo sulla pagina del progetto https://github.com/Microsoft/omi/releases il pacchetto relativo all’architettura e alla versione di openssl in uso

Nel nostro caso l’ultima versione è la 1.1.0, siamo su una macchina a 64bit con ssl 1.0

cd /usr/local/srl
wget https://github.com/Microsoft/omi/releases/download/v1.1.0-0/omi-1.1.0.ssl_100.x64.rpm

Installiamo il pacchetto
rpm -ivh omi-1.1.0.ssl_100.x64.rpm


Ora siamo pronti per installare DSC for Linux; iniziamo scaricando l’ultima versione disponibile da qui https://github.com/Microsoft/PowerShell-DSC-for-Linux/releases/latest

Avendo cura di scegliere anche qui la versione relativa all’architettura e alla versione di Openssl in uso

Al momento troviamo versione 1.1.1-294 e possiamo scaricarla ed installarla con:

wget https://github.com/Microsoft/PowerShell-DSC-for-Linux/releases/download/v1.1.1-294/dsc-1.1.1-294.ssl_100.x64.rpm
rpm -ivh dsc-1.1.1-294.ssl_100.x64.rpm


Installato tutto il necessario possiamo procedere alla configurazione dei servizi per iniziare ad utilizzare DSC for Linux. Per prima cosa è necessario lanciare omiserver come servizio, o come preferiscono chiamarlo i seguaci di Linux, come demone. Per fare ciò lanciamo l’eseguibile di omiserver con l’opzione –d

/opt/omi/bin/omiserver –d

Successivamente è fondamentale copiare i moduli di Linux DSC sul server Windows da cui poi effettueremo la connessione (e quindi il push della configurazione), o installare i moduli per il management delle macchine Linux direttamente da PowerShell.

Con Windows 10 Anniversary Update o Windows 2016 sarà sufficiente eseguire il comando

Install-Module nx, nxComputerManagement, nxNetworking

Su sistemi operativi precedenti, è possibile procedere alla copia manuale delle “risorse nx” presenti nella cartella “Modules”

Potete ovviamente utilizzare il metodo che preferite, io ho usato WINSCP scaricandolo da

https://winscp.net/download/WinSCP-5.9.2-Portable.zip

WinSCP è un client di trasferimento con protocollo SCP, è in grado quindi di trasferire file da e verso una macchina Linux da Windows sfruttando una connessione SSH. Nel nostro caso stabiliamo la connessione e copiamo la cartella nx come segue:

dalla macchina Linux dal percorso /opt/microsoft/dsc/modules/nx
nella macchina Windows nel percorso C:\Windows\System32\WindowsPowerShell\v1.0\Modules

Avviando PowerShell da Windows possiamo verificare che siano presenti i moduli per il management dei client linux eseguendo il cmd-let

Get-DSCResource nx*

Ora è davvero tutto pronto per provare a stabilire una connessione con la macchina linux, creare un file di configurazione, ed inviarlo al client per avviare il deploy automatico delle risorse.

Per effettuare il push della configurazione è necessario creare da Windows Powershell una connessione con la macchina Linux e per questo utilizzeremo una CIM Session. Questa operazione si esegue con poche righe direttamente da PowerShell; abbiate cura ovviamente di sostituire l’indirizzo IP con quello desiderato al momento di aprire la connessione tramite il comando New.CimSession.

$RootCredentials = Get-Credential -UserName:'root' -Message 'Root Credentials'

$CIMOptions = New-CimSessionOption -SkipCACheck -SkipCNCheck -UseSsl -SkipRevocationCheck

$CIMSession = New-CimSession -Credential $RootCredentials -ComputerName '192.168.12.10' -Port 5986 -Authentication Basic -SessionOption $CIMOptions

Una messagebox chiederà di immettere la password per connetterci alla macchina linux, dal momento che abbiamo indicato -Message ‘Root Credentials’ nel comando Get-Credentials. Avremmo potuto specificare la password direttamente nello script, ma sarebbe stata visibile in chiaro e questa soluzione non mi piace molto.

Inserita la password, se PowerShell non ritorna errori la connessione è andata a buon fine.

Rimbocchiamoci le maniche, quindi, e scriviamo il nostro primo file di configurazione per PowerShell DSC. In questo esempio proveremo ad eseguire il push di una configurazione che mi piace definire “semplice ma non troppo”; proveremo, infatti, a lanciare l’autoconfigurazione di LAMP sulla macchina linux. Il sistema effettuerà l’installazione in autonomia del servizio Apache con supporto PHP e del servizio MariaDB (MySQL), effettuando il download dei servizi e di eventuali prerequisiti utilizzando il gestore dei pacchetti yum; procederà poi all’avvio dei servizi e creerà un file php nella home directory di Apache.

Per creare il file di configurazione utilizziamo l’editor ise e salviamo il file in formato .ps1 in modo da poterlo eseguire direttamente da PowerShell. Incolliamo il seguente codice per testarne le funzionalità. Nel mio caso salvo il file in:

C:\DSCTest\LAMP-on-192-168-12-10.ps1

configuration LAMP

{

    Import-DSCResource -Module nx
Import-DSCResource -Module nxComputerManagement
Import-DSCResource -Module nxNetworking
node <192.168.12.10>

    {
nxPackage Apache
{

            PackageManager = 'Yum'
Ensure = 'Present'
Name = 'httpd'
}

        nxPackage MariaDB
{
PackageManager = 'Yum'
Ensure = 'Present'
Name = 'mariadb-server'
}

        nxPackage PHP
{
DependsOn = '[nxPackage]Apache'
PackageManager = 'Yum'
Ensure = 'Present'
Name = 'php php-mysql'
}

        nxService Apache
{
DependsOn = '[nxPackage]Apache'
Name = 'httpd'
Enabled = $true
Controller = 'systemd'
State = 'Running'
}

        nxService MariaDB
{
DependsOn = '[nxPackage]MariaDB'
Name = 'mariadb'
Enabled = $true
Controller = 'systemd'
State = 'Running'
}

        nxFile PHPTest
{
DependsOn = '[nxPackage]Apache'
Ensure = 'Present'
Type = 'File'
DestinationPath = '/var/www/html/index.php'
Contents = "<?php phpinfo(); ?>"
}
}
}

LAMP

$RootCredentials = Get-Credential -UserName:'root' -Message 'Root Credentials'

$CIMOptions = New-CimSessionOption -SkipCACheck -SkipCNCheck -UseSsl -SkipRevocationCheck

$CIMSession = New-CimSession -Credential $RootCredentials -ComputerName '192.168.12.10' -Port 5986 -Authentication Basic -SessionOption $CIMOptions

Start-DscConfiguration -CimSession $CIMSession -Wait -Verbose -Path c:\DSCTest\LAMP

Get-DscConfiguration -CimSession $CIMSession

Test-DscConfiguration -CimSession:$CIMSession

Durante l’esecuzione verrà generato un file .MOF in una sottocartella chiamata come il nome dichiarato all’interno del file di configurazione. Nel nostro caso, lanciando lo script PowerShell da c:\DSCTest, il file MOF verrà creato n c:\DSCTest\LAMP. E’ questo, quindi, il percorso da indicare nel parametro Path del comando Start-DscConfiguration nelle ultime righe dello script.

Proviamo quindi a posizionarci in c:\DSCTest, lanciare lo script ed osservare cosa succede.

Il Cmd-let Test-DscConfiguration come ultimo comando esegue un test della configurazione e restituisce il risultato. Nel nostro caso tutto è andato come sperato e non abbiamo errori.

Dato che DSC ci ha confermato di aver creato nella root directory del webserver un file chiamato index.php che esegue il comando phpinfo, proviamo a puntare un browser su http://192.168.12.10 e vediamo se l’installazione è andata davvero a buon fine.

Direi che non abbiamo molto altro da aggiungere, non ci rimane che provare ad affinare i nostri script per ottenere praticamente ogni tipo di configurazione possibile, e divertirci a creare intere farm gestendo tutti i servizi con semplici script.

Installare e configurare Microsoft SQL Server for Linux

Ormai non è più una novità, torniamo a parlare di Microsoft nel mondo Linux come se fosse una cosa “normale”; in questo articolo vediamo come è possibile installare SQL Server, si proprio lui, Microsoft SQL Server, su una macchina Linux, in maniera davvero semplice e veloce.

Non stiamo ovviamente parlando di Open Source, il servizio database viene fornito già compilato e pacchettizzato per le varie distribuzioni. Nella versione Linux, attualmente denominata SQL Server vNext CTP1 è basato sul nuovo motore SQL Server 2016, ed è scaricabile direttamente dal sito Microsoft al seguente link:

https://www.microsoft.com/en-us/sql-server/sql-server-vnext-including-Linux#resources

Senza dilungarci troppo su cos’è e come funziona SQL Server, passiamo all’installazione su una macchina di test; per questa occasione utilizziamo una macchina CentOS 7, quindi utilizzeremo yum come gestore di pacchetti. Navigando sul link indicato in precedenza sceglieremo quindi l’installazione dedicata all’ambiente Red Hat e ci ritroveremo davanti a questo rapidissimo step by step:

https://docs.microsoft.com/it-it/sql/linux/sql-server-linux-setup-red-hat

Ricordiamo che per avviare il servizio è necessario che la macchina abbia almeno 3,25 GB di RAM.

Il primo passo consiste nell’aggiungere ai repository in cui yum effettua le ricerche dei pacchetti, quello in cui è presente il servizio SQL Server per distribuzioni Red Hat, che corrisponde all’indirizzo https://packages.microsoft.com/config/rhel/7/mssql-server.repo

Scarichiamo quindi con curl il file testuale corrispondente all’URL appena indicato e lo salviamo tra i repository di yum.

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

Per questo esempio siamo loggati sulla macchina con un utente dedicato all’installazione e avvio del servizio SQL chiamato sqluser. Per eseguire comandi con privilegi amministrativi utilizziamo sudo.

Lanciamo quindi l’installazione con l’utente sqluser eseguendo

sudo yum install -y mssql-server

Il gestore di pacchetti yum scaricherà i files necessari (circa 140Mb) più eventuali prerequisiti ed installerà tutto il necessario. L’installazione sulla mia macchina di test è durata circa 5 secondi, circa lo stesso tempo che impiega a comparire lo splash screen dell’ìnstallazione quando avviata su Windows.

Come visibile anche dallo screenshot, al termine dell’installazione viene richiesto di lanciare uno script per lanciare la configurazione del servizio. Durante la configurazione verrà settata la password dell’utente SA e verrà chiesto se avviare il servizio SQL al termine dell’installazione. E’ possibile anche abilitare l’esecuzione del servizio automaticamente all’avvio. Anche questa configurazione viene completata in circa 10-15 secondi.

Per avviare lo script è necessario eseguire:

sudo /opt/mssql/bin/sqlservr-setup

Verifichiamo subito che il servizio è effettivamente up and running con il commando

service mssql-server status

Se sulla nostra distribuzione Red Hat (oppure CentOS) è attivo un firewall, possiamo configurarlo per accettare connessioni sql in ingresso con:

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

Se vogliamo utilizzare questa stessa macchina linux per effettuare il management del motore database dobbiamo installare i relativi tools. L’operazione è molto semplice e del tutto simile alla precedente. Sarà necessario aggiungere un nuovo repository ed avviare l’installazione dei tools con il comando yum.

sudo su -
curl https://packages.microsoft.com/config/rhel/7/prod.repo > /etc/yum.repos.d/msprod.repo
exit
sudo yum install mssql-tools

Tutto è pronto quindi per effettuare la connessione al database utilizzando i tools forniti da Linux. Il comando che utilizzeremo è sqlcmd e sintassi e modalità d’uso sono identiche alla versione per Windows.

Effettuiamo un primo test di connessione con:

sqlcmd -S <host> -U <utente> -P <Password>

Omettendo la password verrà richiesta dopo aver premuto invio. Quindi nel nostro caso:

sqlcmd -S localhost -U SA


A questo punto siamo pronti per interagire con il motore database utilizzando query Transact-SQL

Creiamo ad esempio un database di nome “ictpower”, all’interno di questo database creiamo una tabella chiamandola “anagrafica”.

CREATE DATABASE ictpower;
GO

CREATE TABLE anagrafica (id INT, nome NVARCHAR(50), cognome NVARCHAR(50));
GO


Inseriamo ora due record all’interno della tabella anagrafica:

INSERT INTO anagrafica VALUES (1, 'Gianluca', 'Nanoia');
INSERT INTO anagrafica VALUES (2, 'Nicola', 'Ferrini');
GO

Possiamo testare anche i comandi di selezione per effettuare delle query sulla tabella appena create:

Possiamo ovviamente connetterci al servizio database utilizzando il classico SQL Management Studio di Windows. E siccome sono sicuro che siete molto scettici, facciamo subito una prova per cancellare ogni dubbio.

Attualmente l’unica versione di SQL Server Management Studio che permette la connessione e a SQL Server vNext CTP 1 è la 17.0 RC1. E’ necessario scaricare il pacchetto relativo alla lingua del sistema operativo in uso. Nello specifico al seguente link è scaricabile SSMS 17 in inglese:

https://go.microsoft.com/fwlink/?LinkID=835608&clcid=0x409

Quello in italiano è disponibile invece al seguente indirizzo:

https://go.microsoft.com/fwlink/?LinkID=835608&clcid=0x410

Effettuiamo quindi il download e procediamo con l’installazione, che non richiede particolari attenzioni.

Avviamo subito il client e proviamo a connetterci al motore di database inserendo IP della macchina Linux, nome utente e password settata in precedenza

La connessione va a buon fine e proviamo subito a guardare le proprietà del server cliccando con il tasto destro sul nome (o l’IP) del server nell’object explorer e selezionando proprietà.

Beh, in effetti è un po’ strano da vedere ma è esattamente quello che ci aspettavamo: Microsoft SQL Server versione 14 su CentOS Linux.

Per testare le funzionalità di base verifichiamo innanzi tutto l’esistenza di database, tabelle e record creati in precedenza, e successivamente proviamo a creare un’altra tabella ed inserire qualche dato di esempio.

Tutto sembra perfetto, ed anche creazione tabella ed inserimento dati non comportano problemi

E’ possibile programmare anche delle stored procedures, quindi il motore di database è assolutamente utilizzabile per ambienti anche di una certa complessità.

Mi sento di dire che è sicuramente un ottimo inizio, anche se la versione di Microsoft SQL Server per Linux ha ancora molte limitazioni rispetto al SQL Server che siamo abituati ad utilizzare su Windows. Risparmio il mero copia-incolla dalla pagina ufficiale indicando il link alla relativa pagina di Microsoft, nella quale sono indicate in dettaglio tutte le differenze tra le due versioni.

https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-release-notes

Installare e configurare PowerShell for Linux

Ci stiamo quasi abituando ai rilasci sempre più rapidi di software e servizi che integrano il mondo Windows con quello Linux e le sfaccettature della nuova politica di Microsoft sono talmente tante che spesso capita di perderci qualcosa. A me per esempio era sfuggito questo simpatico video, nel quale viene ufficializzato dal team di sviluppo il rilascio della prima PowerShell Open Source nei repository GitHub.

https://www.youtube.com/watch?v=1uGyswOOPdA

E’ sicuramente un altro passo verso la strada della completa interazione tra Windows ed il mondo Open Source iniziata due anni fa e fortemente voluta dal CEO di Microsoft Satya Nadella. Tramite PowerShell Open Source, infatti, è possibile amministrare delle macchine Windows utilizzando Linux o MacOS, funzionalità impensabile fino a poco tempo fa.

Andiamo subito a vedere come possiamo installare e che cosa è possibile fare in dettaglio con questa Shell, utilizzando ad esempio un server Linux. In questo caso siamo su una macchina CentOS versione 7, ma la Shell è supportata anche su distribuzioni Ubuntu e MacOS; è disponibile inoltre anche in una immagine Docker. I binari per tutte le versioni sono disponibili su GitHub a questo link:

https://github.com/PowerShell/PowerShell/blob/master/README.md

Nel nostro caso, effettuiamo il download della versione per linux Centos con:

wget https://github.com/PowerShell/PowerShell/releases/download/v6.0.0-alpha.12/powershell-6.0.0_alpha.12-1.el7.centos.x86_64.rpm

ed installiamo il pacchetto utilizzando yum, che provvederà anche a scaricare ed installare eventuali prerequisiti

yum install ./powershell-6.0.0_alpha.12-1.el7.centos.x86_64.rpm

La nostra PowerShell è già pronta e possiamo già utilizzarla digitando il commando

powershell

Eseguiamo il comando

Get-Module -ListAvailable

per visualizzare i moduli PowerShell disponibili sulla macchina linux:

Probabilmente un sistemista Linux non utilizzerà mai PowerShell per amministrare la propria macchina, ma è altrettanto vero che un sistemista Windows può amministrare delle macchine Linux con i comandi che già conosce; non possiamo certo ignorare il fatto che la strada intrapresa è quella che consentirà di amministrare “everything from everywhere”.

Molto particolare è sicuramente la possibilità di accedere ad una sessione PowerShell su un Windows remoto tramite il cmd-let Enter-PSSession; per fare ciò abbiamo la necessità di costruire un canale di comunicazione tra la macchina linux che stiamo usando e la macchina Windows da amministrare. Ciò viene fatto tramite una connessione SSH e per consentire alle macchine di “parlarsi” abbiamo bisogno di configurare il servizio sulla macchina target.

Iniziamo con l’installazione della nuova PowerShell 6.0 scaricando il pacchetto in formato .msi da questa pagina:

https://github.com/PowerShell/PowerShell/releases

Al momento della stesura di questo articolo l’ultima versione è la 6.0.0.12-alfa scaricabile da questo link (per Windows Server 2016):

https://github.com/PowerShell/PowerShell/releases/download/v6.0.0-alpha.12/PowerShell_6.0.0.12-alpha.12-win10-x64.msi

Terminata l’installazione apriamo la PowerShell 6 dal nuovo link che troviamo nel menu start e prepariamo il sistema per accettare connessioni remote configurando il servizio WinRM (Windows Remote Management). Questo servizio è installato di default ed impostato per l’avvio automatico da Windows 2008 in poi, ma necessita di una rapidissima configurazione per accettare le connessioni remote. Per configurare il servizio con i parametri di default è sufficiente eseguire dal prompt dei comandi:

winrm quickconfig

e confermare le modifiche quando richiesto


Per ulteriori informazioni su WinRM si può fare riferimento all’articolo https://msdn.microsoft.com/en-us/library/aa384372(v=vs.85).aspx

Abbiamo poi bisogno di registrare la nuova Powershell su WinRM; questa operazione viene fatta lanciando uno script presente nella cartella di installazione della shell stessa, che di default risulta essere

C:\Program Files\PowerShell\6.0.0.12

Eseguiamo quindi lo script con:

cd "C:\Program Files\PowerShell\6.0.0.12"
.\Install-PowerShellRemoting.ps1

Prendiamo nota della cartella di installazione di PowerShell 6 perché ci sarà utile in seguito.

A questo punto torniamo alla costruzione del nostro “canale di comunicazione” tra Windows e Linux, che consiste nell’installazione sui due sistemi del servizio OpenSSH. Quasi tutte le distribuzioni Linux hanno questo servizio installato di default, passiamo quindi all’installazione lato Windows. Seguendo questa mini guida saranno necessari solo pochi minuti per raggiungere il nostro checkpoint:

1 – Scaricare l’ultima build di OpenSSH server da qui

https://github.com/PowerShell/Win32-OpenSSH/releases/latest/

2 – Estrarre il file scaricato nella directory c:\Program Files\OpenSSH

3 – Installare il servizio OpenSSH eseguendo da PowerShell i seguenti comandi:

cd "c:\Program Files\OpenSSH"
powershell -executionpolicy bypass -file install-sshd.ps1


4 – Generare le chiavi relative all’host per avviare il servizio OpenSSH eseguendo

.\ssh-keygen.exe -A


5 – Configurare Windows Firewall per consentire l’accesso sulla porta 22

New-NetFirewallRule -Protocol TCP -LocalPort 22 -Direction Inbound -Action Allow -DisplayName SSH

6 – Modificare il file sshd_config all’interno della cartella OpenSSH per consentire l’accesso tramite password e definire il sottosistema powershell. Le modifiche da effettuare sono:

Decommentare: PasswordAuthentication yes

Nella sezione Subsystem aggiungere le riga (utilizzando il percorso di powershell.exe annotato in precedenza):

Subsystem     powershell C:\Program Files\PowerShell\6.0.0.12\powershell.exe -sshs -NoLogo -NoProfile

7 – Avviare i servizi

Start-Service sshd
Start-Service ssh-agent

8 – Per impostare l’avvio automatico del servizio OpenSSH eseguire:

Set-Service ssh-agent -StartupType Automatic
Set-Service sshd -StartupType Automatic

NB – SUCCESSIVA DISINSTALLAZIONE

Se state eseguendo l’installazione solo per testare le funzionalità alla fine dei test sarà possibile disinstallare il servizio OpenSSH con i seguenti comandi (con PowerShell dalla cartella c:\program files\openssh):

Stop-Service sshd
powershell.exe -executionpolicy bypass -file uninstall-sshd.ps1

Sulla macchina linux invece sarà necessario solo effettuare un paio di modifiche al file /etc/ssh/sshd_config

A seconda delle distribuzioni il percorso del file sshd_config potrebbe cambiare. Per editare il file utilizziamo un qualsiasi editor di testo, ad esempio

nano /etc/ssh/sshd_config

decommentiamo: PasswordAuthentication yes

ed aggiungiamo nella sezione “# override default of no subsystems”

Subsystem powershell powershell -sshs -NoLogo -NoProfile

Salviamo le modifiche e riavviamo il servizio ssh con il comando (sulla distribuzione Centos)

service sshd restart

A questo punto siamo pronti per stabilire una connessione PowerShell dalla nostra Linux box al server Windows, utilizzando il cmd-let di PowerShell

Enter-PSSession

Apriamo quindi la PowerShell con il comando

powershell

ed avviamo una sessione remota tramite

Enter-PSSession -HostName [NomeHost] -UserName [NomeUtente]

La macchina target è ora pronta per ricevere i nostri comandi.

Eseguiamo anche qui il comando Get-Module -ListAvailable per vedere i moduli utilizzabili (questa volta da PowerShell 6 su Windows)

Il team di sviluppo ha in progetto l’implementazione di altri moduli in un futuro più o meno prossimo, sarà sicuramente interessante poter gestire ruoli e funzionalità oppure accedere al database Active Directory. Nel frattempo prendiamo confidenza con i comandi disponibili e non dimentichiamo di seguire tutti gli sviluppi direttamente sulla pagina del progetto:

https://github.com/powershell

Gestione dei servizi su Windows 10 Subsystem for Linux

Possiamo definire “servizio” un processo, o un insieme di processi, che può funzionare su un sistema indipendentemente dall’attività dell’utente. Su un qualsiasi client Windows, ad esempio, troviamo i servizi per gestire l’assegnazione automatica di un indizzo ip (dhcp client), per indicizzare i files in modo da facilitare le ricerche (Windows search), per proteggere le connessioni verso la nostra macchina (Firewall), analizzare file potenzialmente dannosi (Windows Defender), e così via…

Tutte queste funzionalità, ed ovviamente molte altre, sono presenti su una macchina anche se nessun utente la sta utilizzando, e costituiscono una componente molto importante nell’architettura di un sistema operativo poiché è proprio grazie ad esse che sarà possibile effettuare o meno delle attività sul sistema stesso.

E’ chiaramente possibile installare e rimuovere servizi per aumentare o diminuire le funzionalità attive sulla nostra macchina, e siamo sempre stati abituati a gestire il loro avvio su una macchina Windows utlilzzando il comando net dal prompt dei comandi DOS, aprendo la gestione dei servizi da Pannello di controllo o eseguendo services.msc dal menu avvio.

Utilizzando questa management console, ad esempio, è sufficiente visualizzare le proprietà di ogni servizio per avviarlo, fermarlo, oppure indicare se il servizio stesso dovrà partire automaticamente all’avvio del sistema, o dovrà essere avviato manualmente.

Con l’introduzione di Windows Subsystem for Linux (https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm) la situazione si complica un po’, perché tutti i servizi che sono presenti sul sottosistema Linux non sono gestibili attraverso questa console, ma si comportano proprio come farebbero su un sistema Linux nativo.

Per comprendere la gestione dei servizi in un sistema Linux è necessario introdurre il concetto di runlevel. Il runlevel indica lo stato in cui si trova il sistema operativo relativamente all’utilizzo o meno dei servizi, e viene indicato attraverso un numero intero. I runlevel principali sono rappresentati nell’elenco seguente:

0 – Rappresenta lo stato di totale inattività della macchina con nessun processo in esecuzione. Questo stato si verifica in un unico caso: la macchina è spenta

1 (Single user mode) – Utilizzato unicamente per fini diagnostici, è lo stato del sistema in cui è attiva una minima parte del sistema operativo, senza nessun servizio attivo; l’accesso è consentito solo all’amministratore.

2 – La macchina è in modalità multiutente con il networking abilitato ma senza servizi attivi

3 – La macchina è in modalità multiutente con il networking abilitato ed i servizi attivi ad esclusione del server grafico. Il sistema è utilizzabile unicamente da riga di comando

4 – Non utilizzato

5 – Corrisponde al level 3 con l’aggiunta del server grafico

6 – Rappresenta l’azione di chiusura dei servizi e riavvio della macchina

Le operazioni che il sistema effettua per ogni runlevel sono sempre modificabili, poiché per ogni servizio è possibile scegliere su quale runlevel deve essere attivo. Su una macchina linux è interessante notare che possiamo scegliere di avviare il sistema con runlevel 3 oppure 5 a seconda se vogliamo utilizzare la command line oppure il server grafico.

Su una macchina Linux della distribuzione Ubuntu, e quindi sul sottosistema Linux della nostra macchina Windows la gestione dei servizi è affidata a degli script. Nel momento in cui un servizio viene installato viene automaticamente generato uno script per l’avvio/arresto del servizio stesso e posizionato nella cartella /etc/init.d

In questa cartella, quindi, troveremo tutti gli script per la gestione dei servizi presenti sulla macchina, dove ogni script è un file di testo contenente i comandi necessari per avviare, fermare, o conoscere lo stato di un particolare servizio. Il nome del file è uguale al nome del servizio a cui si riferisce, e generalmente non ha estensione. Vediamo il contenuto della cartella /etc/init.d della mia macchina di esempio.

Come è possibile notare, troviamo gli script apache2 e mysql che servono a gestire il webserver ed il database server che abbiamo installato in precedenza (https://www.ictpower.it/guide/apache-php-e-mysql-su-windows-subsystem-for-linux-e-possibile.htm).

Per richiamare l’esecuzione dello script possiamo scegliere se lanciarlo direttamente (con l’opportuna azione) richiamandone il path completo in questo modo

/etc/init.d/nomescript azione

oppure utilizzare il comando service come scorciatoia. Il risultato finale sarà lo stesso:

service nomescript azione

per vedere le azioni disponibili lanciamo uno dei due senza alcuna azione, ad esempio

service nomescript

E’ chiaro che alcune azioni come ad esempio start e stop saranno valide per tutti gli script, altre (in questo caso ad esempio start-htcacheclean) saranno relative solo al servizio di riferimento. Per conoscere lo stato di un servizio utilizziamo il comando

service nomescript status

Vediamo qualche esempio di azioni lanciate sui nostri servizi apache2 e mysql:

Ribadiamo ancora una volta che stiamo lavorando su una funzionalità beta, ed anche in questo caso al momento dell’avvio dei servizi riceviamo dei warning o degli errori, che però abbiamo notato non comprometterne le funzionalità.

Nella cartella /etc esistono poi le sottocartelle che si occupano di gestire l’avvio dei servizi nei vari runlevel, ed esiste una cartella per ogni runlevel. All’interno di queste, posizionate in /etc/rcX.d doveX è il runlevel, troviamo i link agli script per far partire i servizi relativi a quel runlevel. Tralascerò il dettaglio sulla gestione di queste cartelle per il motivo che capirete tra pochissimo.

Su una distribuzione Ubuntu “reale” esiste un comando per la gestione dell’avvio dei servizi, ed è sufficiente eseguire con privilegi di amministratore (utente root):

update-rc.d nomeservizio enable

per abilitare il servizio all’avvio automatico, oppure

update-rc.d nomeservizio disable

per disabilitarlo.

Per Windows Subsystem for Linux, però, le cose non stanno proprio così; il sottosistema linux viene richiamato solo all’avvio del processo bash.exe, e fermato non appena l’esecuzione di bash termina. Gli script di avvio non vengono, quindi, processati all’avvio della macchina, e per l’avvio automatico dei servizi del sottosistema linux sarà necessario richiamarne l’esecuzione durante l’avvio di Windows.

Lanciando da un prompt di DOS il comando:

bash.exe –c "/etc/init.d/apache2 start"

siamo, ad esempio, in grado di avviare il webserver.

Per automatizzare il comando al logon dell’utente è necessario quindi creare un batch ed includerlo in esecuzione automatica, o al momento attendere speranzosi che in una prossima versione di WSL ci sia qualche interazione con i servizi di Windows.

Nel frattempo godiamoci il nostro ambiente-studio e continuiamo ad esplorarne tutte le possibiltà.

Installazione di WordPress su Windows Subsystem for Linux

Torniamo a parlare di Windows Subsystem for Linux, questa volta per una prova “pratica”. Proveremo infatti a configurare nell’ambiente creato in precedenza (https://www.ictpower.it/guide/apache-php-e-mysql-su-windows-subsystem-for-linux-e-possibile.htm) un sito basato sul famoso CMS WordPress.

L’ambiente citato è una architettura di tipo Linux, sul quale sono installati i servizi Apache (webserver) MySQL (database engine) e PHP (interprete di comandi), ottenuto però su una macchina Windows 10 su cui è attiva la funzionalità Windows Subsystem for Linux. Per l’installazione di questa funzionalità vi riporto al seguente articolo (https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm).

La scelta di WordPress per questo test non è casuale. Ho scelto un sistema relativamente complesso, a larga diffusione, che trovi dei vantaggi nell’utilizzo di una architettura basata su Linux. Il vantaggio fondamentale è quello di lavorare su una piattaforma software che è nata e sviluppata per linux e che quindi offre su questo sistema operativo maggiori performance e flessibilità. Non a caso la stragrande maggioranza dei provider che forniscono server pronti per ospitare siti WordPress mettono a disposizione per questo CMS delle macchine linux.

Premesso quindi che abbiamo un’architettura LAMP (Linux, Apache, MySQL, PHP) pronta, iniziamo con il download dell’ultima versione di WordPress disponibile direttamente dalla pagina http://it.wordpress.org, preferendo il formato .tar.gz. Questo formato è un archivio con algoritmo gunzip facilmente manipolabile da riga di comando tramite bash.

Terminato lo scaricamento del file nella cartella Dowload del nostro utente possiamo quindi avviare Windows bash ed eseguire il seguente comando per scompattare l’archivio:

tar xvfz <nomearchivio.tar.gz>

L’output ci farà vedere in tempo reale i nomi dei files mentre vengono scompattati e produrrà una cartella chiamata wordpress, che contiene tutto il necessario per dare il via all’installazione del nostro CMS.

Proponiamo uno screenshot con il quale cogliamo l’occasione di mostrare il comportamento di alcuni altri semplici comandi:

pwd – mostra il path corrente

cd <path> – cambia il path corrente con quello specificato

ls – visualizza i file nel path corrente (equivalente del DIR di DOS)

Al termine delle operazioni avremo la cartella wordpress decompressa all’interno della cartella Download, posizione originale del file .tar.gz.

A questo punto possiamo cambiare la configurazione del webserver per puntare direttamente alla cartella di WordPress, ma questa è un’operazione relativamente complessa. Proviamo ad ottenere lo stesso risultato con qualcosa di più semplice. Possiamo infatti spostare questa cartella all’interno del path che rappresenta la home predefinita del webserver stesso. La home predefinita di Apache su Ubuntu, e quindi su Windows Subsystem for Linux, è la seguente:

/var/www/html

Per spostare la cartella di WordPress utilizzeremo il comando mv (move), che ha la seguente sintassi:

mv <oggetto> <nuovopath>

nel nostro caso quindi possiamo eseguire:

mv wordpress /var/www/html/

e subito verificare che la cartella ora è effettivamente posizionata nel nuovo percorso eseguendo:

cd /var/www/html/

ls

così come mostrato nello screenshot seguente:

Ora non ci rimane che creare un database e possiamo farlo con poche righe di codice utilizzando il client per MySQL fornito da linux. Il comando per la connessione al database è:

mysql –p

alla richiesta di password risponderemo con la password scelta al momento dell’installazione del servizio database).

creiamo poi il database chiamandolo wordpress con il comando

create database wordpress;

usciamo dal client mysql con

exit

Il tutto è riportato nel seguente screenshot:


A questo punto possiamo dare il via all’installazione di WordPress puntando il browser della nostra macchina sull’indirizzo http://127.0.0.1/wordpress. Possiamo eseguire la stessa operazione da una macchina in LAN aprendo http://x.x.x.x/wordpress dove x.x.x.x è l’ip privato della nostra macchina Windows 10.

Facciamo click su Iniziamo ed inseriamo i parametri per la connessione, ricordando che abbiamo appena creato un database di nome wordpress.

Il Wizard ci informerà che è riuscito ad autogenerare il file di configurazione necessario all’utilizzo del database e può iniziare l’installazione

Completiamo i parametri a nostro piacimento e proseguiamo, cercando sempre di utilizzare password complesse per l’accesso

Al termine dell’installazione il nostro sito è pronto! Cliccando su login possiamo accedere al CMS ed iniziare a costruirlo come preferiamo!

Sarebbe d’obbligo testare l’utilizzo di svariati template e plugin, ma non posso mica fare tutto da solo! L’utilizzo di WordPress è molto intuitivo ed in poco tempo sarete in grado di costruire un sito web con infinite potenzialità.

Anche questa volta abbiamo utilizzato comandi Linux su una macchina Windows con estrema semplicità ed abbiamo verificato che questa funzionalità introdotta in Windows 10 riesce davvero ad offrire spunti molto interessanti.