1 06/11/2026 10 min

Installare Microsoft SQL Server 2022 Preview su Ubuntu 20.04

Qui il punto non è solo “far partire il pacchetto”, ma evitare di ritrovarsi con un’istanza che si installa e poi non si avvia per colpa di dipendenze mancanti, spazio disco insufficiente o repository configurati male. Su Ubuntu 20.04 la strada più pulita è usare i pacchetti ufficiali Microsoft, verificare prima l’ambiente e poi procedere con un’installazione minimale, reversibile e controllata.

La dicitura Preview conta: non stiamo parlando di una release stabile “da produzione senza riserve”, ma di una build pensata per test e validazione. Quindi il primo filtro è sempre lo stesso: capire se il nodo è un host di laboratorio, una VM di staging o una macchina già in uso. Se il contesto è produzione, serve almeno una finestra di manutenzione e un rollback chiaro.

Prerequisiti da verificare prima di toccare i pacchetti

Prima di installare, conviene controllare tre cose: versione del sistema, spazio disponibile e compatibilità dell’architettura. SQL Server su Linux è sensibile ai prerequisiti base; saltarli significa perdere tempo su errori banali che si potevano intercettare in due minuti.

Verifica la release di Ubuntu e l’architettura:

lsb_release -a
uname -m

Atteso: Ubuntu 20.04.x e architettura x86_64. Se compare un’architettura diversa, fermati: il pacchetto non è il target giusto. Se la release non è 20.04, non dare per scontata la compatibilità dei repository e verifica la documentazione ufficiale della build che vuoi usare.

Controlla anche spazio e memoria, perché l’installazione base può sembrare leggera ma l’istanza cresce in fretta appena aggiungi database, log e backup locali:

df -h /
free -h

Come regola pratica, evita di partire con meno di qualche gigabyte libero sul filesystem che ospiterà i dati e i log. Non è un numero magico: dipende dal carico, dal numero di database e dalla retention dei log, ma se lo spazio è già tirato, l’errore non arriva durante il setup; arriva dopo, quando è più scomodo da gestire.

Aggiungere il repository Microsoft e importare la chiave

Per installare SQL Server 2022 Preview su Ubuntu 20.04, la via corretta è aggiungere il repository Microsoft dedicato alla distribuzione e alla versione del pacchetto. Questo evita di inseguire file .deb trovati in giro e ti permette di aggiornare il software in modo coerente con gli altri pacchetti del sistema.

Prima aggiorna l’indice dei pacchetti e installa gli strumenti necessari per la gestione del repository:

sudo apt update
sudo apt install -y curl gnupg apt-transport-https

Ora importa la chiave del repository Microsoft e registra la sorgente pacchetti. In questa fase è utile essere precisi con la distribuzione, perché un errore qui si traduce in un repository non valido o in pacchetti non trovati.

curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | sudo gpg --dearmor -o /usr/share/keyrings/microsoft.gpg
curl -fsSL https://packages.microsoft.com/config/ubuntu/20.04/mssql-server-preview.list | sed 's#deb \[#deb [signed-by=/usr/share/keyrings/microsoft.gpg] #' | sudo tee /etc/apt/sources.list.d/mssql-server-preview.list

Se il file /etc/apt/sources.list.d/mssql-server-preview.list viene creato correttamente, hai già una verifica concreta: il repository è stato scritto sul sistema. Se il comando fallisce, controlla subito connettività, DNS e l’eventuale blocco del proxy aziendale, perché il problema potrebbe non essere SQL Server ma la rete in uscita.

A questo punto aggiorna la cache di APT e verifica che il pacchetto sia visibile:

sudo apt update
apt-cache policy mssql-server

Nel risultato di apt-cache policy dovresti vedere una candidate version proveniente dal repository Microsoft. Se non compare, il repository non è stato agganciato correttamente oppure la chiave non è stata applicata come previsto.

Installare il pacchetto mssql-server

Con il repository a posto, l’installazione vera e propria è lineare. Qui la scelta giusta è restare essenziali: installa il motore, non aggiungere componenti extra se non servono davvero.

sudo apt install -y mssql-server

Durante l’installazione possono comparire messaggi relativi al contratto di licenza e alla configurazione iniziale. Se stai operando in sessione interattiva, completa i passaggi richiesti. Se il pacchetto si ferma su errori di dipendenze, non forzare: leggi l’output completo e verifica prima il sistema, soprattutto se il nodo ha repository terzi misti o aggiornamenti parziali.

Una volta terminato il setup, il servizio viene gestito da systemd. Il controllo base è questo:

systemctl status mssql-server --no-pager

Atteso: stato active (running). Se lo stato è failed, la prima cosa da leggere non è il web, ma il journal del servizio:

journalctl -u mssql-server -n 100 --no-pager

In caso di errore, i motivi più comuni sono memoria insufficiente, configurazione incompleta o problemi sul filesystem dati. Il journal ti dice dove guardare; senza quel log, si va a tentativi.

Eseguire la configurazione iniziale con mssql-conf

Dopo l’installazione, SQL Server richiede la configurazione della password dell’account sa e di alcuni parametri fondamentali. Il tool di riferimento è mssql-conf, che ti evita di modificare a mano file interni non necessari per la fase iniziale.

Avvia la configurazione interattiva:

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

Durante il setup ti verrà chiesta una password robusta per sa. Qui non c’è margine per improvvisare: usa una password lunga, non riutilizzata e conservata in un password manager. Se stai preparando un ambiente di test condiviso, il minimo sindacale è che la credenziale non finisca mai in chat o in file di note non protetti.

La configurazione scrive in genere sotto /var/opt/mssql/, con il file di stato e i parametri del motore. Se vuoi verificare che la configurazione sia stata applicata, puoi controllare che il servizio sia ancora in esecuzione e che il processo risponda localmente sulla porta standard:

ss -ltnp | grep 1433

Se la porta non è in ascolto, il problema è quasi sempre a valle della configurazione iniziale o del servizio che non è ripartito correttamente. In quel caso torna al journal e leggi gli ultimi eventi.

Aprire il firewall solo se serve davvero

Su un host locale o in una rete già segmentata, non è detto che la porta 1433 debba essere esposta liberamente. Se il server deve accettare connessioni remote, allora va autorizzato in modo esplicito e limitato agli indirizzi necessari.

Con UFW, un’apertura minima può essere questa:

sudo ufw allow from 10.0.0.0/24 to any port 1433 proto tcp
sudo ufw status numbered

Atteso: regola presente e limitata alla subnet autorizzata. Se apri la porta a tutto il mondo senza una ragione precisa, stai aumentando inutilmente la superficie d’attacco. In ambienti esposti, meglio ancora mettere davanti un controllo di rete o un reverse tunnel amministrato, invece di lasciare la porta pubblica senza filtro.

Se il firewall non è UFW ma un security group cloud o un appliance di rete, il principio non cambia: autorizza solo il traffico necessario e verifica il path completo, non solo il firewall locale.

Verificare il login locale e la connessione remota

Prima di dare per scontato che l’istanza sia pronta, fai una prova locale. Il client sqlcmd è utile per chiudere il cerchio: se il motore risponde localmente, il problema eventuale non è il servizio ma la rete o l’autenticazione remota.

Se non hai ancora il client, puoi installarlo aggiungendo il relativo pacchetto Microsoft. In molti casi conviene farlo subito, così hai uno strumento di test coerente con il server appena installato:

sudo apt install -y mssql-tools unixodbc-dev

In base alla shell che usi, potrebbe essere utile aggiungere il percorso dei binari al PATH. Per una sessione corrente:

export PATH="$PATH:/opt/mssql-tools/bin"

Test locale con autenticazione SQL:

sqlcmd -S localhost -U sa -P 'LaTuaPasswordForte' -Q 'SELECT @@VERSION'

Atteso: output con la versione del motore SQL Server e nessun errore di login. Se la query fallisce con errore di autenticazione, la password o il setup iniziale non sono stati applicati come pensi. Se fallisce con errore di connessione, torna a porta, servizio e binding locale.

Per una prova remota, sostituisci localhost con l’IP o il nome host del server. Se la connessione fallisce da remoto ma funziona in locale, il problema è quasi sempre uno di questi tre: firewall, routing o ascolto sulla rete sbagliata. La verifica più semplice resta sempre la stessa: controllare la porta 1433 e il path di rete tra client e server.

Backup, dati e percorso di rollback

Anche se si tratta di una Preview, è bene impostare fin da subito un minimo di disciplina operativa. Se l’istanza serve solo per test, documenta dove stanno i database, dove finiscono i log e qual è il metodo per rimuovere il pacchetto senza lasciare residui confusi.

Prima di qualunque modifica futura, una copia dei file di configurazione utili è una scelta sensata. I punti chiave sono in genere sotto /var/opt/mssql/; non spostare o editare a caso, ma conserva uno snapshot o un backup del contenuto rilevante prima di cambiare parametri di istanza.

Se devi fare rollback dell’installazione in un ambiente di test, il percorso standard è fermare il servizio e rimuovere il pacchetto. Questo è un’operazione potenzialmente distruttiva per i dati dell’istanza se non hai salvato prima il necessario, quindi va fatta solo con un prerequisito chiaro: dati non ancora in uso o già copiati altrove.

sudo systemctl stop mssql-server
sudo apt remove -y mssql-server

Se il rollback deve essere più pulito, valuta anche la rimozione dei file residui sotto /var/opt/mssql/, ma solo dopo aver verificato che non contengano dati da preservare. In un ambiente condiviso, la differenza tra “disinstallare” e “cancellare tutto” è sostanziale: la seconda opzione ha impatto diretto sui database locali e non va eseguita senza consapevolezza.

Errori tipici e come leggerli in fretta

Ci sono alcuni pattern che tornano spesso. Se il pacchetto non si trova, il problema è quasi sempre il repository o la cache APT. Se il servizio non parte, il journal di systemd è la fonte primaria. Se la connessione remota fallisce, il nodo successivo non è il database ma la rete.

Un errore di login su sqlcmd non significa automaticamente che SQL Server sia rotto. Spesso indica una password sbagliata, un setup non completato o un client che sta puntando all’istanza sbagliata. Anche qui vale la stessa logica: verifica prima il fatto osservabile, poi la causa.

Se invece il servizio consuma troppa memoria o va in pressione sotto carico, non forzare subito parametri avanzati. Prima misura: RAM disponibile, carico reale e log di sistema. Solo dopo ha senso ragionare su tuning, limiti e collocazione del database su storage più adatto.

Quando ha senso usare questa preview

La Preview ha senso quando devi validare compatibilità applicative, driver, query, procedure di deploy o integrazioni con strumenti esterni. Non è il posto giusto per trattare con leggerezza affidabilità, supporto o hardening definitivo. Per questi aspetti serve una release stabile e una procedura di migrazione ben pianificata.

Se l’obiettivo è solo imparare il flusso di installazione, la procedura sopra è sufficiente: repository corretto, pacchetto installato, servizio attivo, configurazione iniziale completata, test con sqlcmd e verifica della porta. Se invece stai preparando un ambiente più serio, aggiungi subito monitoraggio, policy di backup e un controllo preciso sugli accessi di rete.

Assunzioni: Ubuntu 20.04 LTS x86_64, installazione su host dedicato o VM, accesso amministrativo via sudo, ambiente di test o staging, nessuna personalizzazione preesistente di SQL Server.