Come installare Node.js e NPM su CentOS 8 Linux

Perché evitare il pacchetto generico di CentOS 8

Su CentOS 8 la scelta più pulita non è installare il primo nodejs disponibile nei repository base e sperare che basti. In ambito server conta avere una versione coerente, aggiornabile e allineata al ciclo di manutenzione dell’applicazione. Il punto non è solo ottenere il comando node e il package manager npm, ma farlo con un percorso che resti gestibile nel tempo, senza incastrarsi in dipendenze vecchie o moduli mancanti.

Su questa distribuzione il metodo più prevedibile è usare il repository ufficiale di NodeSource oppure, se serve una versione molto specifica, un gestore di versioni come nvm per l’utente applicativo. Per un server condiviso o una macchina di produzione, però, il repository di sistema resta in genere più semplice da governare: meno variabili, meno sorprese nei path, aggiornamenti più lineari.

Verifica preliminare del sistema

Prima di toccare i pacchetti, conviene capire con cosa stai lavorando. CentOS 8 è ormai un ambiente delicato dal punto di vista del lifecycle: in molte installazioni il problema non è Node.js, ma il fatto che il sistema sia già fuori dal flusso standard di aggiornamento. Questo non blocca l’installazione, ma impone un controllo in più sulla fonte dei pacchetti e sulla policy di aggiornamento.

Controlla la release e lo stato dei repository attivi:

cat /etc/centos-release
dnf repolist
uname -r

Se dnf repolist mostra repository disabilitati o non raggiungibili, sistemali prima: senza una base sana, l’installazione di Node.js finisce spesso per bloccarsi su dipendenze secondarie o metadata scaduti.

Installazione consigliata con repository ufficiale

Per la maggior parte dei casi conviene usare il repository ufficiale di NodeSource. Il vantaggio pratico è che puoi installare una release corrente di Node.js senza dover compilare nulla e senza dipendere dalla versione spesso conservativa presente nei repo base di CentOS 8.

1. Aggiorna l’indice pacchetti e i tool minimi di supporto:

sudo dnf -y update
sudo dnf -y install curl ca-certificates

2. Aggiungi il repository NodeSource. Scegli una major supportata dalla tua applicazione. Per un impianto nuovo, una LTS è quasi sempre la scelta più sensata.

curl -fsSL https://rpm.nodesource.com/setup_20.x | sudo bash -

Questo script configura il repository RPM corretto. Se il download fallisce, non andare avanti a installare pacchetti a mano: prima verifica con curl -I https://rpm.nodesource.com se hai connettività, DNS e TLS funzionanti.

3. Installa Node.js, che include anche npm nella maggior parte dei casi:

sudo dnf -y install nodejs

4. Verifica le versioni installate:

node -v
npm -v

Un output coerente ti dice che il binario è nel path giusto e che il pacchetto ha portato con sé anche il gestore pacchetti JavaScript. Se npm non risulta disponibile, controlla quale pacchetto è stato installato con rpm -qa | grep -E '^nodejs|^npm' e verifica se stai usando una versione minima o un repo incompleto.

Quando serve una versione precisa di Node.js

In alcuni ambienti il problema non è installare Node.js, ma installare quella versione. Capita con framework che richiedono una major specifica, moduli nativi compilati per ABI precise o pipeline CI che devono replicare la produzione. In quel caso non improvvisare con pacchetti casuali: o usi il repository corretto per la major richiesta, oppure isoli la versione con uno strumento dedicato.

Se vuoi restare sul livello sistema, puoi cambiare la stringa nello script NodeSource. Per esempio, per una major diversa:

curl -fsSL https://rpm.nodesource.com/setup_18.x | sudo bash -
sudo dnf -y install nodejs

La regola operativa è semplice: la versione deve essere una decisione architetturale, non un dettaglio lasciato al caso. Se l’app è in produzione, documenta il motivo della major scelta e il piano di aggiornamento, altrimenti tra sei mesi ti ritrovi con una dipendenza bloccante e nessuno che ricorda perché sia stata installata proprio quella release.

Installazione tramite nvm per ambienti di sviluppo o utenti dedicati

Se non stai preparando un servizio di sistema ma una postazione di sviluppo o un account applicativo dedicato, nvm è spesso la soluzione più flessibile. Installa più versioni in parallelo, non sporca i pacchetti di sistema e consente switch rapidi tra release diverse. Il rovescio della medaglia è che dipende dalla shell dell’utente e non è la prima scelta per un servizio systemd che deve partire in modo deterministico.

1. Installa i prerequisiti:

sudo dnf -y install curl git

2. Scarica e installa nvm per l’utente corrente:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash

3. Ricarica la shell o apri una nuova sessione, poi verifica che il comando sia disponibile:

command -v nvm

4. Installa la versione desiderata e impostala come predefinita:

nvm install --lts
nvm alias default lts/*
node -v
npm -v

Con nvm il vantaggio operativo è evidente: puoi testare una nuova major senza toccare il runtime di produzione. Il limite è altrettanto chiaro: se il servizio viene eseguito da un utente di sistema o da systemd, devi curare bene il caricamento dell’ambiente, altrimenti il binario non viene trovato o viene usata una versione diversa da quella attesa.

Controlli dopo l’installazione

Installare il pacchetto non basta. Serve confermare che il binario giusto sia nel path giusto, che i permessi siano coerenti e che il package manager funzioni davvero. In ambienti server gli errori “silenziosi” sono i peggiori: tutto sembra a posto finché un deploy o una build non si rompe per una dipendenza mancante.

Esegui questi controlli minimi:

which node
which npm
node -p "process.version"
npm config get prefix

Se which node restituisce un percorso diverso da quello atteso, stai probabilmente mischiando installazioni di sistema e installazioni utente. In quel caso evita di “correggere” a colpi di ln -s: meglio capire quale runtime deve essere quello ufficiale della macchina e ripulire il resto con criterio.

Un test più concreto è creare una directory temporanea e inizializzare un progetto minimo:

mkdir -p /tmp/node-check
cd /tmp/node-check
npm init -y
node -e "console.log('node ok')"

Se npm init -y fallisce, il problema non è l’installazione di Node in sé ma il contesto del filesystem, i permessi o una configurazione corrotta sotto ~/.npmrc o /etc/npmrc.

Permessi, utenti dedicati e best practice operative

Su un server non conviene eseguire applicazioni Node come root. Il runtime non ha bisogno di privilegi elevati per funzionare, e tenere separato l’utente applicativo riduce il danno potenziale di un exploit o di un modulo malevolo. La pratica corretta è creare un utente dedicato, assegnargli la directory dell’app e limitare l’accesso solo a ciò che serve.

Un esempio minimale:

sudo useradd --system --create-home --shell /sbin/nologin nodeapp
sudo mkdir -p /srv/nodeapp
sudo chown -R nodeapp:nodeapp /srv/nodeapp

Se l’applicazione usa porte basse o risorse privilegiate, non concedere privilegi globali al runtime. Meglio usare un reverse proxy su 80/443 e lasciare l’app su una porta alta, ad esempio 3000 o 8080. Così separi i compiti: Node gestisce l’applicazione, Nginx o Apache gestiscono l’esposizione pubblica.

Per i moduli globali, evita installazioni sparse con sudo npm install -g senza controllo. Se servono strumenti globali, documenta il motivo e verifica dove finisce il prefisso con npm config get prefix. In molti casi è preferibile usare dipendenze locali nel progetto e invocare gli eseguibili tramite npx o script di package.json.

Aggiornamento e manutenzione

Node.js non si installa una volta sola e si dimentica. Come qualunque runtime esposto a dipendenze moderne, richiede un ciclo di aggiornamento ragionato. Il punto non è inseguire l’ultima major, ma mantenere una versione supportata, testata con l’applicazione e coerente con il resto dello stack.

Se hai usato NodeSource, l’aggiornamento segue il normale flusso del sistema:

sudo dnf -y update nodejs

Dopo ogni update importante, rilancia i controlli minimi:

node -v
npm -v
npm --version

Se l’app ha dipendenze native, aggiungi anche un test di build o un avvio di prova. È il momento in cui emergono gli attriti reali: moduli compilati contro una vecchia ABI, toolchain mancanti, oppure script che assumono una versione di Node differente da quella appena installata.

Errore tipici e lettura rapida dei sintomi

Quando l’installazione non va come previsto, i sintomi sono quasi sempre ripetitivi. Se node non viene trovato, il problema è nel path o nell’installazione incompleta. Se npm manca ma node c’è, hai probabilmente un pacchetto parziale o una distribuzione non coerente. Se il download dello script NodeSource fallisce, il problema è quasi sempre a monte: DNS, proxy, TLS, oppure repository non raggiungibile.

Per distinguere rapidamente le cause, questi comandi sono più utili di molte ipotesi astratte:

curl -I https://rpm.nodesource.com
rpm -q nodejs
dnf info nodejs
journalctl -xe | tail -n 50

Se stai dietro a proxy aziendali o firewall restrittivi, il repository può risultare tecnicamente corretto ma non raggiungibile. In quel caso il problema non è Node.js: è la connettività in uscita o la policy di sicurezza che blocca il fetch dei pacchetti. La soluzione va chiusa a livello rete, non con workaround locali che sopravvivono solo fino al prossimo refresh del sistema.

Scelta pratica tra repository e nvm

La regola di base è semplice. Se stai preparando un server applicativo, una VM condivisa o un host gestito da procedure standard, usa il repository ufficiale e tieni Node.js come pacchetto di sistema. Se invece stai lavorando su sviluppo, test o su un utente dedicato che deve cambiare versione spesso, nvm dà più libertà con meno attriti.

Il vero errore operativo è mescolare i due approcci senza criterio. Installare una versione via RPM e un’altra via nvm nello stesso contesto porta quasi sempre a confusione: script che puntano al binario sbagliato, build che usano una versione e servizi che ne usano un’altra. Se vuoi evitare questo scenario, scegli un solo metodo per ciascun ambiente e documentalo nel runbook.

In sintesi: su CentOS 8 Node.js e NPM si installano in modo pulito, ma il valore sta nella disciplina con cui scegli il metodo, verifichi il risultato e mantieni aggiornato il runtime. Il comando giusto è utile; il processo giusto evita incidenti dopo tre mesi.