Uno dei tratti più caratteristici e distintivi di una distribuzione rispetto ad un’altra è sempre stata la configurazione del sistema, e in particolare delle interfacce di rete.
Tradizionalmente Red Hat (e figlie) ha sempre fatto affidamento sul comando ifcfg e i relativi file di configurazione /etc/sysconfig/network-scripts/ifcfg-, uno per ogni scheda di rete. A questi, che si occupano di IP e DNS, si affiancano le rotte in /etc/sysconfig/network-scripts/route-.
Debian (e derivate) ha sempre preferito ifconfig, con le configurazioni in /etc/network/interfaces – o sperati in file singoli /etc/network/interfaces.d.
Anche fra distribuzioni sentite vicine ci possono essere differenze. Per esempio, Arch è spesso stata definita la versione compilata di Gentoo, ma la prima usa l’utility netctl e la seconda netifrc. Mentre systemd propone la sua networkd – che almeno avrebbe il vantaggio di non essere legato ad una distro specifica.
Ci fermiamo qui ma avete capito che si potrebbe andare avanti a lungo.
Confusi? Beh, è normale: la frammentazione è evidentemente altissima, francamente eccessiva.
Già qualcosa come 3 anni fa auspicavamo un metodo standard, che ancora non c’è, ma forse ci stiamo muovendo nella direzione giusta.
Da qualche anno il comando ritenuto standard per la configurazione delle interfacce è ip, e praticamente tutte le distribuzioni hanno adeguato i propri tool per poterlo usare, installandolo anche di default.
Semmai, talvolta, è stata creata un’utility alternativa, come NetPlan, di Ubuntu. In realtà questo strumento vuol essere generico, popolando a sua volta i file usati da altri tool, come systemd-networkd, ma nella pratica è il punto in cui intervenire.
Red Hat ha scelto da tempo NetworkManager, che ormai è lo standard per qualsiasi desktop. Ma per non rompere la compatibilità con i vecchi metodi, NetworkManager, oltre ai suoi keyfile, può usare anche i file ifcfg.
Fedora ha una proposta è semplice: rimuovere il supporto per i vetusti file ifcfg, e affidarsi alla sola configurazione di NetworkManager.
La scelta non si basa solo su “nuovo è meglio“, ma ha risvolti importanti sulla qualità del software e il suo mantenimento. Una frase salta all’occhio nel dettaglio della proposta:
Given the complexities stemming from historical legacy of ifcfg files not being designed (or documented) in a particularly forward-looking way, this has been a huge and complex effort with all the downsides: The ifcfg support code is huge (130K lines, not counting the enormous test suite) and has constantly been a source of bugs.
Date le complessità derivanti dall’eredità storica dei file ifcfg di non essere stati progetta (o documentati) in modo particolarmente lungimirante, questo è stato un impegno complesso ed enorme, con tutti i lati negativi: il codice per il supporto di ifcgf è gigantesco (130K linee, senza contare l’enorme suite per i test) ed è stato costantemente una fonte di bug.Quindi non solo la rimozione del supporto a qualcosa che non ha più senso di esistere sarà indolore, ma porterà a vantaggi di stabilità (meno bug) e qualità (meno lavoro disperso), oltre a maggior sicurezza (meno linee di codice vuol dire meno meccanismi potenzialmente sfruttabili).
Il supporto finora presente non sarà semplicemente buttato via. Sarà disponibile in pacchetto aggiuntivo a parte, sebbene non installato di default. In questa maniera, chi ancora fa affidamento sui file ifcfg, potrà continuare ad usarli. Ma la strada ormai è tracciata – e meno male!
Ho coltivato la mia passione per l'informatica fin da bambino, coi primi programmi BASIC. In età adulta mi sono avvicinato a Linux ed alla programmazione C, per poi interessarmi di reti. Infine, il mio hobby è diventato anche il mio lavoro.
Per me il modo migliore di imparare è fare, e per questo devo utilizzare le tecnologie che ritengo interessanti; a questo scopo, il mondo opensource offre gli strumenti perfetti.
English (US)