Tag: linux

  • Xubuntu/XFCE: come avviare una sessione in VNC

    Di recente ho dovuto avviare una sessione VNC su una macchina remota; la mia preferenza per un desktop environment “light” ma al tempo stesso completo è andata su XFCE (installato di default su Xubuntu).

    Per avviare una sessione VNC è necessario modificare il file posto nella vostra home, e più precisamente in ~/.vnc/xstartup. Il file deve essere strutturato come segue (nel mio caso ho dovuto inserire soltanto le ultime due righe):

    #!/bin/sh

    Uncomment the following two lines for normal desktop:

    #unset SESSION_MANAGER
    #exec /etc/X11/xinit/xinitrc
    [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
    [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
    xsetroot -solid grey
    vncconfig -iconic &
    x-terminal-emulator -geometry 80×24+10+10 -ls -title "$VNCDESKTOP Desktop" &
    x-window-manager &
    startxfce4 &
    exec /usr/bin/xfce4-session &

  • Installazione e configurazione di Logwatch su Ubuntu

    Nei server Linux che amministro ho recentemente installato un programma di monitoring dei logs: logwatch.
    Una questione importante ma abbastanza noiosa e per cui non si ha mai molto tempo è – appunto – quella dell’analisi dei log, una sorta di “diario” dell’attività svolta dal sistema.
    Spesso si ricerca nei logs solo quando insorge un problema: la proattività di logwatch, invece, ci permette di avere una sintesi di ciò che è successo e che merita la nostra attenzione direttamente via email.

    Assicuratevi di avere un MTA installato e configurato a dovere [consiglio: postfix o qmail].
    Una volta installato, logwatch invia una mail a root@localhost ogni giorno.
    Modifichiamo quindi l’indirizzo a cui root farà il forward di tutta la posta:

    % cat /etc/aliases
    postmaster: root
    root: michele@bologna.com

    Modifichiamo la schedulazione dell’esecuzione di logwatch da giornaliero a mensile [da cron.daily a cron.weekly]:

    mv /etc/cron.daily/*logwatch /etc/cron.weekly

    Ed infine specifichiamo a logwatch di analizzare i log relativi agli ultimi 7 giorni e il formato da usare (HTML):

    cp /usr/share/logwatch/default.conf /etc/logwatch/conf/logwatch.conf

    Nel file di conf cambiate:

    • Format = html
    • Range = between -7 days and -1 days

    Ecco l’esempio di una mail ricevuta da logwatch:

    logwatch1

    logwatch2

     

     

     

     

    Come potete vedere ci sono informazioni molto interessanti, come:
    * i pacchetti installati/aggiornati tramite dpkg
    * gli accessi tramite ssh
    * gli utilizzatori di sudo
    * lo spazio disco utilizzato
    e altre informazioni sicuramente utili sullo stato della macchina in questione.

    logwatch è entrato nella dotazione software standard che installo su tutte le macchine Linux che amministro.

  • sshuttle: creiamo una VPN (via transparent proxy) con SSH

    In passato vi ho spiegato come creare un tunnel SSH per poter “tunnelizzare” il traffico Internet usando da tramite un server che esponeva il demone sshd. La scomodità di questa soluzione risiede nell’ultimo passo: dobbiamo impostare un tunnel SOCKS per ogni programma di cui vogliamo tunnelizzare il traffico. Ok, questo può non essere una scomodità vera e propria, tuttavia: per esempio, vogliamo tunnelizzare solo il traffico del browser [pensiamo di trovarci in una rete pubblica], mentre il traffico SSH [già cifrato] non ha bisogno di essere tunnelizzato.

    Oggi facciamo un passo oltre: vogliamo sfruttare la connessione SSH che abbiamo per tunnelizzare  tutto il traffico attraverso SSH. Questo è equivalente a creare una VPN con il server remoto, ma l’unica differenza importante è che non si creano interfacce di rete aggiuntive!

    Di conseguenza, l’host locale (che chiamiamo client) instaurerà una connessione SSH verso il server che si assumerà la responsabilità di instaurare la connessione verso gli altri host e di fare da “passacarte” verso il client. La configurazione è molto utile nel caso in cui il client si trovi ad utilizzare una rete pubblica non sicura (pensiamo ad esempio a Starbucks) ma allo stesso tempo voglia che tutto il traffico sia cifrato per evitare problemi di sniffing.

    Il software che ci permette di costruire la VPN (vi ricordo che non è a tutti gli effetti una VPN, anche se ne si hanno tutti i benefici) è sshuttle, disponibile per Linux e OSX.

    Una volta installato solo sul client (lo trovate nei repo di Ubuntu e in homebrew), vi consiglio di configurarlo per fare il forward di tutto il traffico (comprese le richieste DNS) nel seguente modo:

    ./sshuttle --dns -vvr username@sshserver 0/0

    [Nota: 0/0 è uno shortcut per 0.0.0.0 – se volete modificarlo per fare selective routing verso il tunnel di una particolare subnet, sapete cosa dovete modificare ;)]

    Per i più curiosi, ecco una piccola spiegazione di cosa c’è under the hood di sshuttle.

  • Convertire una macchina fisica in una virtuale: VMware vCenter Converter

    Ho recentemente convertito due macchine fisiche Windows in macchine virtuali (per questioni di manutenibilità) con un tool gratuito messo a disposizione da VMware: VMware vCenter Converter.

    Una volta installato si occupa di fare un’immagine virtuale di tutto il contenuto dell’hard disk (comprese eventuali partizioni), creando una macchina virtuale (compatibile con VMware e con Oracle VirtualBox).

    Non ho ancora provato a virtualizzare una macchina Linux (mi sono affidato a clonezilla), ma VMware supporta anche la conversione di Linux da fisico a virtuale.

  • zsh: perché non utilizzo bash

    Su tutte le macchine Linux e OSX che amministro non uso come shell di default la bash; uso invece zsh, perché:

    • zsh si offre di completare anche le opzioni e i parametri dei programmi più usati;
    • zsh fa spelling correction dei comandi digitati, chiedendo interattivamente se volete correggere il comando;
    • zsh offre una customizzazione più spinta della bash (vedremo tra poco il mio prompt);
    • zsh condivide la history tra più sessioni attive contemporaneamente;
    • zsh è già installata, di default, su OSX (ed è nei repo di Ubuntu, percui basta un aptitude install zsh).

    Se questi vantaggi non dovrebbero bastare, ecco il mio prompt:

    Ho scritto un tema ad-hoc, che funziona grazie a oh-my-zsh (un framework di customizzazione per zsh, che consiglio vivamente!). Cos’ha di speciale il mio prompt rispetto ad una semplice bash?

    • Colorazione diversa del prompt se siamo root
    • Colorazione del prompt in base all’esito positivo o negativo dell’ultimo comando utilizzato
    • Visualizzazione dello stato del repo git della directory attuale: branch + status (modifiche unstaged?)

    Ho caricato su github i due temi che ho creato per oh-my-zsh: michelebologna.zsh-theme è quello mostrato in questi screenshot. Ovviamente, prima dovete installare oh-my-zsh. Feedback benvenuti!

  • Evitare riavvii e shutdown remoti su Ubuntu con molly-guard

    Non mi è mai capitato ma potrebbe essere molto utile ai sysadmin più distratti: molly-guard è un pacchetto presente su Ubuntu/Debian che vi permette di evitare un riavvio/shutdown di una macchina remota a cui siete collegati tramite ssh.

    Se, per esempio, tentate di eseguire uno shutdown di una macchina remota a cui siete collegati tramite ssh, molly-guard vi chiede di scrivere per intero l’hostname della macchina che volete riavviare/spegnere.

    Il pacchetto è incluso nei repository ed è molto semplice da installare (basta un apt-get) ed è davvero molto utile: ho provveduto ad installarlo su tutte le macchine che gestisco.

    Per i più curiosi, il nome molly-guard deriva da una “divertente” vicenda.

  • RescueTime: il modo migliore per visualizzare dove “spendiamo” il nostro tempo

    RescueTime: il modo migliore per visualizzare dove “spendiamo” il nostro tempo

    Ricordarsi dove si “spende” la maggior parte del proprio tempo al computer è un’attività davvero difficile, soprattutto per chi con i computer ci lavora! Proprio per questo motivo ci viene in aiuto RescueTime: una volta installato vi verrà proposto di installare un programma che se ne starà in background e che monitorerà non invasivamente quello che fate al vostro computer, per produrre poi un report delle attività che svolgete al vostro computer, contabilizzando le ore che spendete in ogni applicazione; il tutto, automaticamente!

    Una volta installato, RescueTime vi fa alcune semplici domande per capire quali sono, a vostro giudizio, i programmi che ritenete più produttivi e quali, invece, perdite di tempo. Ogni volta che RescueTime vi invierà un report delle vostre attività, con dei semplici e chiari grafici come quello qui sopra, vi dirà se siete stati produttivi o meno proprio secondo le regole che voi stessi avete dichiarato.

    Come funziona? Dopo un po’ di investigazione, ho scoperto che RescueTime memorizza solamente il titolo dell’applicazione in foreground e per quanto tempo viene utilizzata (per il browser: anche il sito visitato). Questi sono i dati memorizzati da RescueTime, per cui, se siete preoccupati per la vostra privacy, potete decidere in autonomia se installare RescueTime.

    In generale trovo RescueTime davvero utile, proprio perché mi aiuta a capire dove spendo la maggior parte del mio tempo e, nel caso in cui le attività siano distrazioni, a potermi meglio regolare in futuro. Inoltre, funziona anche come un pratico “cronometro” per progetti: spesso mi aiuta a capire qual è l’elapsed vero di un progetto a cui sto lavorando.

    RescueTime è gratuito nella versione base per Windows, Linux e MacOSX ed offre anche una versione a pagamento che vi offre informazioni ancora più dettagliate e alcune funzionalità per restare nella “zone” bloccando le attività che vi distraggono.

  • proctools: (pgrep, pkill): gli strumenti per operare sui processi

    Quando ci si trova davanti ad un terminale e si deve operare sui processi, si filtra l’output di ps auxw con grep (ed eventualmente con kill). Ad esempio:

    michele@delta:~ % ps auxw | grep -i yes [ 6:20PM]
    michele 92888 8.7 0.0 2434788 372 s002 S+ 6:20PM 0:00.52 yes
    michele 92914 0.0 0.0 2425580 296 s005 R+ 6:20PM 0:00.00 grep -i yes

    In alcuni casi, l’operazione più comune che segue la grep è quella di kill:

    michele@delta:~ % kill -9 92888 [ 6:20PM]
    michele@delta:~ % ps auxw | grep -i yes [ 6:21PM]
    michele 92934 0.0 0.0 2425480 244 s005 R+ 6:22PM 0:00.00 grep -i yes

    Gli autuori di proctools hanno pensato bene di introdurre 3 utility che ci possono venire incontro per questi casi:

    • pgrep <pattern>: effettua una ricerca all’interno dei processi attivi, ritorna il PID dei processi che matchano il pattern specificato come argomento:

      michele@delta:~ % pgrep yes [ 6:28PM]
      93026
      93053

    • pkill <pattern>: è l’equivalente di kill (quindi bisogna specificare il tipo di signal da passare al processo) ma applicato ai processi: assicuratevi di specificare un pattern univoco, perché tutti i processi che matchano il pattern riceveranno il kill:

      michele@delta:~ % pkill -9 yes [ 6:28PM]

    proctools (il pacchetto che contiene i due comandi citati) è (solitamente) installato di default su Linux (se non è così, cercate proctools tra i pkg della vostra distro). Su MacOSX, invece, va installato (ma scriverò un post a riguardo).
    L’utilizzo che ve ne ho descritto è basic: per ulteriori informazioni, vi rimando alla manpage.

  • Ksplice: aggiornare il kernel di Ubuntu senza riavviare

    Segnalo che con Ksplice (ora Oracle) è possibile applicare gli aggiornamenti di sicurezza (in particolare quelli del kernel) senza dover riavviare. Un’opportunità davvero interessante per tutti i server che devono mantenere un certo uptime e che, di conseguenza, non possono essere riavviati facilmente. Il servizio è disponibile a pagamento per le versioni di Ubuntu server, mentre è gratuito per le versioni desktop. Ecco come installarlo:

    1. Richiedere una chiave di accesso che vi verrà recapitata via email
    2. Loggatevi come utente root, e create il file /etc/apt/sources.list.d/ksplice.list
    3. Incollate nel file le seguenti direttive che servono ad aggiungere le sorgenti dei pacchetti da installare:
      deb https://www.ksplice.com/apt oneiric ksplice 
      deb-src https://www.ksplice.com/apt oneiric ksplice
    4. Lanciate i seguenti comandi, che servono ad installare i pacchetti di Ksplice:
      apt-get install ca-certificates
      wget -N https://www.ksplice.com/apt/ksplice-archive.asc
      apt-key add ksplice-archive.asc
      apt-get update
      apt-get install uptrack
    5. Modificate il file /etc/uptrack/uptrack.conf impostando l’opzioneautoinstall al valore yes
    6. Lanciate il comando uptrack-upgrade -y

    Tutti gli updates di sicurezza  del kernel verranno quindi installati automaticamente, senza dover riavviare. Comodo, vero? Dal 2005 al 2008, Ksplice ha applicato con successo 64 patch senza dover riavviare.

    Per i più curiosi: come funziona Ksplice? Il segreto sta nel fatto che Ksplice aggiorna dinamicamente il kernel, direttamente in memoria, grazie ad un confronto sugli oggetti ELF allocati in memoria. Questo processo è di per sé rischioso e deve essere fatto con la massima attenzione: prima di fare un patch “a caldo” di un oggetto, viene freezata l’esecuzione del processo che accede a tale oggetto, sostituita la chiamata ai vecchi oggetti con la chiamata ai nuovi oggetti, e viene quindi ripresa l’esecuzione.

  • Ubuntu: l’aggiornamento a 11.04 corrompe grub. Ecco come risolvere

    Il 28/04, incuriosito dalla nuova release di Ubuntu (11.04) ho subito aggiornato dalla versione 10.10 usando la funzionalità di aggiornamento integrata nel sistema.

    Tuttavia, con mia grande sorpresa, l’aggiornamento corrompe la configurazione di grub, lasciando il sistema in uno stato inavviabile (in particolare, il sistema si arresta sulla schermata di grub prima del boot); e sembra che sia un problema generalizzato! Non tutto è perduto: il problema deriva da un’errata configurazione di grub prodotta dalla procedura di aggiornamento, ma possiamo recuperare il sistema senza dover reinstallare. Per risolvere il problema, procediamo nel seguente modo:

    • Prendete un CD di Ubuntu che abbia la stessa architettura del sistema da recuperare (i386 o amd64; se non sapete quale scegliere, usate i386);
    • Avviate il sistema da LiveCD e aprite un terminale
    • Trovate la partizione contenente la /boot del sistema da recuperare (aiutatevi con fdisk -l) e montatela (ad es. sudo mount /dev/sda1 /media/linux)
    • Montiamo le directory su cui dobbiamo operare:

      sudo mount -B /dev /media/linux/dev
      sudo mount -B /dev/pts /media/linux/dev/pts
      sudo mount -B /proc /media/linux/proc
      sudo mount -B /sys /media/linux/sys

    • E rilocalizziamo il sistema sul sistema target da recuperare: sudo chroot /media/linux
    • A questo punto ripariamo la configurazione di grub:

      grub-install /dev/sda
      update-grub

    • Smontate il filesystem e riavviate: il vostro sistema si avvierà con la versione di Ubuntu appena aggiornata!