Uncategorized

Aggiornare il firmware di un HBA Emulex da riga di comando

Attenzione: chi eseguendo i comandi elencati qui di seguito provocasse danni seri alla propria infrastruttura non potrà in nessun modo rivalersi sull’autore.

Questa è la procedura per aggiornare il firmware di un HBA Emulex con HBAnyware.

Per listare soltanto le HBA locali
hbacmd listhbas local
Questo è il comando per upgradare il firmware (che andrà ripetuto per ciascuna HBA):
hbacmd Download filedelfirmware.all
Per verificare che l’aggiornamento sia andato a buon fine:
cd /sys/class/scsi_host/ && find . -name fwrev

Aggiornare un server Ubuntu LTS 10.04 dietro a un proxy

Quanto scritto di seguito vale, ovviamente, anche per le ultime release di Debian.

Appunto veloce veloce…

La soluzione più immediata è quella di scrivere questa riga nel nostro bel terminale
export http_proxy="http://nostro.proxy.it:3128" e lanciare il solito apt-get update && apt-get upgrade.
Bene sul momento, ma dovremo rifarlo tutte le volte (o valorizzare la variabile http_proxy per il nostro ambiente, cosa che forse non ci interessa fare). Se invece vogliamo aggiungere la configurazione del proxy per apt al nostro server Ubuntu (continuo a riferirmi alla versione server perché con l’ambiente grafico è tutto più semplice) è sufficiente creare il file proxy all’interno della cartella /etc/apt/apt.conf.d e scriverci dentro la riga seguente: Acquire::http::Proxy "http://nostro.proxy.it:3128";

Installazione automatica di Red Hat (ma anche CentOS o Fedora) con un file kickstart remoto

Kickstart è lo strumento che Red Hat (e tutte le sue derivate di conseguenza) utilizza per automatizzare completamente l’installazione di un nuovo sistema. Avete presente tutte quelle schermate che via via anaconda vi presenta, dove si scelgono (quasi) sempre le stesse opzioni? Bene, con kickstart potete evitarvene un bel po’, se non tutte.

Se avrò voglia e tempo, prima o poi vi parlerò più diffusamente di questo utilissimo strumento.

Qui mi interessa più che altro appuntarmi come lanciare un’installazione automatica da CD/DVD (ma da rete cambierebbe ben poco) usando file di kickstart, pronto e corretto, raggiungibile via rete (in questo caso su un server ftp, ma funzionerebbe lo stesso con nfs o http). Il comando da usare alla prima schermata dopo l’avvio da CD è:
boot: linux ks=ftp://serverftp.dominio.it/filekickstart.ksIn questo caso l’installer cercherà di configurare la rete via DHCP, se non riuscirà a farlo chiederà a voi i parametri. Troppa interattività. Molto meglio, se non si dispone di un server DHCP, passargli tutto quello che gli serve al rigo di prima scrivendo così:
boot: linux ks=ftp://serverftp.dominio.it/filekickstart.ks ksdevice=eth0 ip=0.0.0.3 netmask=255.255.255.0 gateway=0.0.0.1 dns=10.10.10.10A questo punto possiamo quasi dirci soddisfatti e andare a strafarci di caffeina. Tempo 4/5 minuti e il nostro server dovrebbe essere pronto.

La prima volta con Arch Linux

Curioso di provare una rolling distro mi sono scelto la più esotica: Arch Linux.

Nel video che segue, che non ha nessuna pretesa nemmeno di somigliare a un tutorial, potete vedere quello che succede una volta che si inserisce il cd (anche se in questo caso ho usato una immagine iso) dentro a un nuovo sistema (virtuale nella fattispecie).

Un po’ di impressioni a caldo, sparse ancorché disorganizzate:

  • L’installer testuale è deliziosamente pulito e molto ben organizzato. Non ci ho provato a fare cose complicate (partizionamenti strambi, ad es.) ma tutti i passi sono guidati in un modo chiaro ed efficace.
  • Se ho ben capito c’è un “unico” file di configurazione /etc/rc.conf del sistema operativo. Sicuramente ci saranno dei “contro” terribili, ma in questo momento riesco a vedere solo tanti e tanti “pro”.
  • Pacman, il gestore dei pacchetti che è una delle peculiarità della distro, sembra abbastanza amichevole. Ho provato a installare i classici Apache/MySql/Php e non è molto diverso dal farlo su un sistema Debian o Red Hat.
  • Ottimo il fatto che alla fine dell’installazione non ci siano stupidi ambienti grafici mangia-risorse. Vabbè su questo punto forse non tutti concorderanno. Pace.
  • Pochissimi anche i servizi attivati di default. Ed è cosa buona e giusta. Non ammetto obiezioni in questo caso.
  • Chiunque sia a proprio agio con la riga di comando partirà molto avvantaggiato.
  • La documentazione ufficiale mi sembra abbastanza curata.

In definitiva il progetto mi sembra davvero molto interessate. Mi piace moltissimo l’approccio minimalista: tutto sembra ridotto ai minimi termini, non ci sono decine di migliaia di pacchetti inutili, che vanno manutenuti anche se non si sa nemmeno di averli installati, ma solo l’essenziale.

Non so se diventerà la mia distro (potrebbe essere ottima per ottimizzare l’uso delle risorse in ambienti virtuali non troppo prestanti ad esempio), ma mi sembra che gli sviluppatori abbiano fatto davvero un ottimo lavoro.

Simulare l’installazione di un pacchetto rpm

Può essere utile (in alcuni casi molto utile) simulare l’installazione, o la disinstallazione, di un pacchetto senza realmente portare a termine nessuna delle due operazioni.

Il comando rpm ha un’ opzione dedicata –test che può essere usata come nei due esempi che seguono:

Nel caso ci interessi simulare l’installazione:

rpm -ivh nomepacchetto.rpm --test

Nel caso ci interessi simulare la disinstallazione:

rpm -e nomepacchetto.rpm --test