Estendere un disco LVM con un disco aggiuntivo

Se si volesse aumentare un volume lvm inserendo un nuovo disco o come nel nostro caso creando un nuovo disco virtuale nella virtual machine

NB. tutti i comandi che dovremmo dare devono essere eseguiti come amministratore e quindi dovremmo anteporre sudo ai comandi o eseguirli da root.

 per prima cosa dobbiamo vedere come è stato montato il nostro disco dando il comando :

fdisk -l

Se il disco non è stato ancora formattato o partizionato fdisk restituirà in uscita un messaggio come il seguente, questo è normale perchè stiamo andando a creare le partizioni necessarie per le fasi successive.

questo significa che il nostro disco è montato su /dev/sdb ci servirà per lanciare fdisk.

(ci sono software che eseguno le seguenti procedure con una interfaccia grafica ad esempio Gparted noi eseguendo la procedura su di un server via ssh utilizzeremo il terminale)
dal terminale lanciare il comando

fdisk /dev/sdb

si aprirà un prompt di fdisk

  inserire i comandi nell'ordine indicato per creare una nuova partizione primaria che utilizzi completamente il disco e renda pronto per LVM.Per creare partizioni multiple di dimensioni diverse consiglio di utilizzare gparted o la guida di fdisk.

NB.le seguenti istruzioni formattano il disco quindi verificare in precedenza che il disco non contenga dati e che sia quello che vogliamo utilizzare.

• n = creare nuova partizione
• p = creare una partizione primaria
• 1 = rendere la partizione la prima sul disco
• enter = selezioniamo il primo cilindro
• enter = selezioniamo l'ultimo cilindro

per preparare il disco all'utilizzo di LVM inserire i seguenti 2 comandi

• t = cambia tipo di partizione
• 8e = cambia il tipo in LVM
 

prima di scrivere le partizioni sul disco controllare che le informazioni saino giuste

• p = visualizza configurazioni delle partizioni da controllare prima di scriverle sul disco
• w = scrivi i cambiamenti su disco (non reversibile!!)

 dopo l'ultimo comando si esce da fdisk e si torna al prompt dei comandi

Ci sono tre  strumenti di base che ci permettono di ridimensionare volumi fisici,gruppi di volumi e volumi logici.(ciascuno di questi comandi deve essere preceduto da pv (volume fisico), vg (gruppi di volumi) o lv (volumi logici)in base a cosa si vuole modificare)

• resize - può ridurre o espandere i volumi fisici e volumi logici ma non gruppi di volumi
• extend - può ingrandire gruppi di volumi e volumi logici ma non può ridurli
• reduce - può ridurre gruppi di volumi e volumi logici ma non puòingrandirli

adesso vediamo come aggiungere un uovo disco rigido al volume logico "lvstuff" creato in precedenza .

aggiungiamo il nuovo disco al gruppo di volumi con il comando

vgextend vgpool /dev/sdc1

 per ridimensionare il volume logico dobbiamo dire a LVM di quando vogliamo estendere o la dimensione a cui vogliamo portarlo.
per estendere il disco ad una dimensione di 8GB eseguire il comando

lvextend -L8G /dev/vgpool/lvstuff

 se volessi invece aggiungere 3GB al disco appena creato dovrei usare il comando

lvextend -L+3G /dev/vgpool/lvstuff

adesso come possiamo vedere dal messaggio che viene restituito il disco è da 11GB

se provassimo a dare il comando df -h vedremmo che lo spazio libero è identico a prima questo è dovuto al fatto che il volume logico è di 11GB ma il filesystem su questo volume è ancora della dimensione precedente. Per far utilizzare al filesystem tutto lo spazio che è stato predisposto basta far puntare il comando resize2fs al volume logico e il gioco è fatto.

resize2fs /dev/vgpool/lvstuff

NB. questo comando si riferisce a ext3/4 per filesystem differenti vedere il comando di resize addatto.

Creare .deb da un .tar.gz con checkinstall

Checkinstall è una utilità molto utile per creare pacchetti .deb per Debian o Ubuntu da file .tar.gz (o .tgz) di sorgenti dopo averli compilati nella tua distribuzione.
Praticamente si prepara il pacchetto per un successivo utilizzo senza il bisogno di compilare il tutto sulla tua macchina linux.
Un'altra applicazione di checkinstall è la disinstallazione del pacchetto dopo averlo installato dai sorgenti.
Come avrete notato non tutti i programmi aggiungono la regola "uninstall" al Makefile e quindi il comando "make uninstall" non andrebbe a buon fine.
La soluzione migliore è utilizzare checkinstall pre preparare i pacchetti dai sorgenti e installarli e disinstallarli con dpkg.
Questa procedura spiga come preparare il .deb di clamav dai sorgenti

1. installare checkinstall
sudo aptitude -y install checkinstall (Ubuntu, Debian e derivate)
2. Reperire i sorgenti da installare
   wget http://mesh.dl.sourceforge.net/sourceforge/clamav/clamav-0.81.tar.gz (per esempio)
3. Installare le dipendenze e le librerie che servono per il funzionamento del pacchetto
   sudo aptitude install libgmp3 libgmp3-dev
4. Compilare i sorgenti
   tar xvfz clamav-0.81.tar.gz
cd clamav-0.81/
./configure --sysconfdir=/etc
make
5. Esegui checkinstall e segui le istruzioni (descrizione pacchetto ecc..):
   sudo checkinstall -D make install
6. Quando sarà finito avremo clamav-0.81_0.81-1_i386.deb e si potrà installarlo con sudo dpkg -i clamav-0.81_0.81-1_i386.deb oppure copiarlo su un'altro computer per un'altra installazione.

Come autenticarsi in Linux senza password con le chiavi SSH

SSH è un fantastico strumento per gli amministratori di sistema. Consente di eseguire comandi da remoto, copiare file in rete, creare dei tunnel e tutto sfruttando i più robusti algoritmi di cifratura. Inoltre consente di stabilire delle rigide politiche riguardo l'autenticazione, come gli host o i PC da autenticare, utenti, ecc.
Quello di cui vi vorremmo parlare oggi è la possibilità di OpenSSH di autenticare un utente in base a uno scambio di chiavi, senza che venga richiesta la password e senza che questo possa rendere meno sicuro il nostro sistema. Di solito infatti siamo abituati a inserire una password per accedere a un sistema. Il concetto è quello di inserire una chiave pubblica (possedendo solo noi la corrispondente chiave privata) all'interno della configurazione di SSH sull'host remoto sul quale vorremmo autenticarci. In questo modo al tentativo di connessione SSH controllerà se la nostra chiave privata e la chiave pubblica lì presente fanno parte della stessa coppia e, in caso positivo, ci darà accesso al sistema.
Trovare una chiave privata a partire da una pubblica è infatti praticamente impossibile, e certamente più difficile di trovare una password. Se la mancanza di richiesta di password vi sconvolge pensate che comunque per assegnarla al server sarà necessario il login: non è quindi un'operazione che possono svolgere tutti, ma solo coloro che hanno già le giuste credenziali di accesso.
In pratica genereremo una coppia di chiavi, una pubblica e una privata. Quella pubblica verrà copiata sul server. Quando il server ci chiederà chi siamo, il nostro client genererà una firma a partire dalla nostra chiave pubblica. Il server, in possesso della chiave pubblica, può controllare se quella firma è stata generata da una chiave privata corrispondente alla chiave pubblica in suo possesso. In caso positivo verrà dato accesso al sistema.
Generiamo quindi la coppia di chiavi con il comando ssh-keygen, ci verrà chiesto di inserire un percorso (va bene anche quello proposto di default) e una passphrase (che sarà bene inserire e non usare una vuota a me no che non si voglia utilizzare degli automatismi in tale caso è opportuna lasciarla vuota) per la generazione delle chiavi:

[utente@linuxbox1 ~]$ ssh-keygen -b 2048 -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/home/utente/.ssh/id_rsa):
Created directory '/home/utente/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/utente/.ssh/id_rsa.
Your public key has been saved in /home/utente/.ssh/id_rsa.pub.
The key fingerprint is:
90:98:4f:f5:69:39:57:5d:46:83:a4:a2:d6:63:3c:25 utente@linuxbox1

A questo punto dovremmo copiare la chiave pubblica sul server SSH. Questa essendo pubblica può essere letta da chiunque, senza problemi di sicurezza. Per copiarla possiamo usare anche scp, programma per la copia di SSH. Ipotizzando che il server si chiami linuxbox2 e che l'utente si chiami utente2, il comando sarà:

[utente@linuxbox1 ~]$ scp /home/utente/.ssh/id_rsa.pub utente2@linuxbox2:.

Ci verrà chiesta la password di utente2 e il file id_rsa.pub, contenente la chiave pubblica, verrà copiata nella home di utente2 su linuxbox2. A questo punto facciamo il login su linuxbox2 (ovviamente come utente2), e copiamo il contenuto del file appena copiato nel file /home/utente2/.ssh/authorized_keys:

cat /home/utente2/id_rsa.pub >> /home/utente2/.ssh/authorized_keys

altro sistema per copiare la mia chiave pubblica su un server remoto (al quale ho un accesso):

ssh-copy-id -i ~/.ssh/id_rsa.pub username@macchina.remota

oppure utilizzando il protocollo ssh
creare una directory ~/.ssh come utente2 su Linuxbox2. (La directory potrebbe gia' esistere, il che va bene...):

utente@linuxbox1:~> ssh utente2@linuxbox2 mkdir -p .ssh
utente2@linuxbox2's password:

Ora appendi la nuova chive pubblica di utente su utente2@linuxbox2:.ssh/authorized_keys ed inserisci la password di utente2 per l'ultima volta:

utente@linuxbox1:~> cat .ssh/id_rsa.pub | ssh utente2@linuxbox2 'cat >> .ssh/authorized_keys'
utente2@linuxbox2's password:

A questo punto basterà provare a collegarsi dall'host linuxbox1 su linuxbox2 per connettersi a patto di inserire la passphrase scelta :

ssh utente2@linuxbox2

Backup incrementale con tar

Una funzionalità di tar non molto usata è quella degli archivi incrementali. E’ invece una funzionalità che può risultare molto utile in alcune strategie di backup, quando, ad esempio, si esegue un ciclo di backup su base settimanale ma non si vuole o non si può fare un backup completo ogni giorno.

Supponiamo ad esempio di voler fare il backup della directory /home/documenti salvando l’archivio in /var/backup. Il comando da dare è:

tar zcvf /var/backup/documenti-`date +%s`.tgz --listed-incremental=/var/log/documenti.tarlog /home/documenti

Viene cioè creato un’archivio dal nome documenti-.tgz (per esempio: documenti-1180427502.tgz), che contiene tutto quello che c’è in /home/documenti. La scelta di aggiungere la data in formato unix è totalmente arbitraria e serve solo come promemoria. Può essere usata al suo posto la data in formato normale usando +%F al posto di +%s.

Viene inoltre creato un file di log (/var/log/documenti.tarlog) che servirà a tar nei successivi backup per capire cosa è cambiato in /home/documenti e cosa va quindi inserito nei successivi backup.

Nei successivi archivi creati con lo stesso comando verranno inseriti solo i file nuovi o modificati e verrà aggiornato il file di log.

Cancellando il file di log e rilanciando il comando viene ricreato un archivio completo. Tutti gli archivi creati, quelli completi e quelli incrementali, hanno il grosso vantaggio di poter essere trattati individualmente, cioè non c’è bisogno della presenza del file di log per poter estrarre i files e le directory in essi contenuti.

Nella pratica se la directory /var/backup viene salvata ogni notte dei giorni lavorativi su supporto esterno (tape, cd/dvd, nas etc.) un semplicissimo script /usr/local/bin/backup_documenti.sh che utilizzi la funzionalità incrementale di tar potrebbe essere scritto in questo modo:

#!/bin/sh
# Cancella i vecchi archivi presenti
rm /var/backup/documenti-*.tgz
# prepara il nuovo archivio, completo se il file di log
#non esiste, altrimenti incrementale
tar zcvf /var/backup/documenti-`date +%s`.tgz --listed-incremental=/var/log/documenti.tarlog /home/documenti

Ovviamente se serve avere il file completo e gli incrementali la cancellazione degli archivi la facciamo nello script che parte il lunedì.

Lo scipt va lanciato tramite cron ogni giorno prima che il sistema di backup archivi la directory sul supporto esterno. Il primo giorno della settimana, prima che venga archiviata la directory dei documenti, sempre tramite cron, viene cancellato il file di log, in modo che il primo backup della settimana sia sempre completo.

Le righe da inserire in un crontab possono essere simili a queste:

#lunedì sera alle 21 cancello il file di log prima
#che cominci l'archiviazione
0 21 * * 1 rm -f /var/log/documenti.tarlog
# dal lunedì al venerdì alle 22 viene preparato
#il file archivio
0 22 * * 1-5 /usr/local/bin/backup_documenti.sh

Eseguire automaticamente script all'avvio di Ubuntu

Per poter creare uno script che venga automaticamente lanciato ad ogni avvio di Ubuntu, dobbiamo creare un file .sh nella cartella /etc/init.d/ che però deve avere come intestazione un blocco di sintassi rigida compreso tra

### BEGIN INIT INFO

### END INIT INFO

questo è il blocco di codice che deve essere inserito

### BEGIN INIT INFO
# Provides: scriptname
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start daemon at boot time
# Description: Enable service provided by daemon.
### END INIT INFO

Quindi:

sudo nano /etc/init.d/nomescript.sh

Scriviamo all’interno del file lo scirpt che vogliamo sia lanciato, diamo i permessi di esecuzione:

sudo chmod a+x /etc/init.d/nomescript.sh

ed infine lo lanciamo:

sudo update-rc.d -f nomescript.sh defaults

Ora lo script verrà eseguito ad ogni avvio della macchina e fermato al suo spegnimento

se noi volessimo invece che lo script venga solo avviato all'avvio (99 è il numero di priorità più alto il numero più tardi viene eseguito)

sudo update-rc.d -f myscript.sh start 99 2 3 4 5.

se volessimo che sia avviato al riavvio e allo spegnimento

sudo update-rc.d -f myscript.sh start 90 0 6.

oppure che venga fermato al riavvio e allo spegnimento

sudo update-rc.d -f myscript.sh stop 90 0 6.

altra possibilità è inserire lo script direttamente in /etc/rcN.d ovvero in rc2.d rc3.d ... rc5.d per avviarlo alla partenza e in rc0.d rc1.d rc6.d per il reboot e shutdown chiamando il file con S per start k per stop seguito dalla priorità.

In genere su Linux sono utilizzati i seguenti livelli:

Runlevel 0 : /etc/rc.d/rc0.d Questo runlevel avvia la sequenza di arresto del sistema (shutdown)
Runlevel 1: /etc/rc.d/rc1.d Questo runlevel rappresenta la modalità singolo utente, nessun altro utente può collegarsi, il servizio di rete è disabilitato.
Runlevel 2: /etc/rc.d/rc2.d Rappresenta lo stato multiutente, il servizio rete è attivo ma è disabilitato il file sharing.
Runlevel 3: /etc/rc.d/rc3.d In genere è quello predefinito quando si opera in modalità testuale, tutti i servizi sono attivi.
Runlevel 4: /etc/rc.d/rc4.d Inutilizzato. Può essere dedicato ad usi personali
Runlevel 5: /etc/rc.d/rc5.d E' il runlevel predefinito quando si vuole avviare Linux in modalità grafica
Runlevel 6: /etc/rc.d/rc6.d Il runlevel 6 è quello di reboot.  

Lo script /etc/rc.d/rc gestisce quali processi far partire a seconda del runlevel, andando ad analizzare le singole directory /etc/rc.d/rc#.d. In queste directory esistono una serie di symlink con nomi del tipo S12syslog o K65identd che puntano a degli script con nomi tipo /etc/rc.d/init.d/syslog o /etc/rc.d/init.d/identd.
/etc/rc.d/rc a seconda della directory corrispondente al runlevel da caricare fa partire tutti gli script che iniziano con S e fa chiudere tutti quelli che iniziano con K, eseguendoli nell'ordine indicato dal numero presente nei nomi dei file.
Gli script che di fatto permettono di gestire l'avvio o lo stop di un servizio sono quindi nella directory /etc/rc.d/init.d/ e possono essere utilizzati direttamente dall'utente per gestire i singoli processi.

es: S99nomescript.sh o K99nomescript.sh

altra possibilità di avviare uno script al completo riavvio del pc e inserire il nome dello script in /etc/init.d/rc.local che viene avviato dopo il completo avvio del pc ma comunque prima del login.

un esempio di script con funzioni avanzate si trova nel file /etc/init.d/skeleton che può servire come base di partenza per script d'avvio anche complessi

per ulteriori informazioni si veda il comando man update-rc.d

nfs su ubuntu

Introduzione

NFS sta per Network File System e indica un filesystem distribuito, ovvero condiviso fra un certo numero di nodi di una rete.

Alla base di questa tecnica c'è la necessità di accedere e lavorare sulle proprie risorse anche se non si è davanti al proprio computer.

La delocalizzazione delle informazioni porta tuttavia con sè tutta una serie di problematiche, prima delle quali vi è la coerenza dello stato delle informazioni ed il controllo della sincronizzazione delle modifiche effettuate (poichè UNIX è un sistema operativo multiutente ad un dato istante di tempo N utenti possono tentare di accedere in scrittura ad uno stesso file).

Installazione

Per installare il supporto per nfs lato kernel digitare:

sudo apt-get install nfs-kernel-server

Configurazione di NFS lato server

Il pacchetto necessario per il setup del servizio NFS di filesystem distribuito su Linux è nfs-kernel-server che viene gestito con i comandi da shell

/etc/init.d/nfs-kernel-server start|stop|restart|status

I servizi correlati con nfs sono :

/sbin/portmap: gestibile con il comando

/etc/init.d/portmap start | stop | restart

/etc/init.d/nfs-common

/etc/init.d/nfs-kernel-server

Il file di configurazione lato server è /etc/exports la cui sintassi è della seguente forma:

[directory da esportare] [host a cui esportarla] ([permessi])

Un esempio è il seguente :

/home/administrator *.pascal.org(ro) sola lettura sostituire ro con rw per lettura scrittura

Questo dice al server NFS di permettere a tutti i client del dominio pascal.org di accedere al filesystem in /home/administrator in modalità di sola lettura.

Il comando da usare per esaminare i fs montati è :

showmount

Per aumentare la sicurezza e la protezione del vostro server NFS dovrete definire la protezione servizi RPC lato server. Il file da editare è /etc/hosts.allow. Il formato di questo file è il seguente:

Programma:hosts:permissions

Ad esempio:

portmap:ALL EXCEPT .org:DENY

Nega a tutti gli hosts tranne quelli del dominio org l'accesso via RPC al file system distribuito NFS.

Configurazione dei clients

Il client che voglia accedere ad una risorsa NFS deve soltanto decidere come montare tale risorsa , se manualmente tramite il comando mount oppure automaticamente ad ogni avvio inserendo mount point e host nel file /etc/fstab.

Personalmente non consiglio quest'ultima soluzione poichè anche cercando di ottimizzare si va incontro a notevoli problemi di stabilità e sicurezza dei propri sistemi.

Come montare le risorse esportate:

Esempio: host B vuole temporaneamente montare la directory /home/administrator condivisa da host A sul suo fs locale /media/exported.

Il Comando su host B :

mount -t nfs hostA:/home/administrator /media/exported

La cartella /media/exported deve essere già creata e disponibile, come questa lo deve essere qualsiasi altra cartella che si desideri utilizzare.

Come fare se host B vuole montare sempre al boot la directory remota condivisa da host A?

Modificare il file /etc/fstab su hostB aggiungendo la seguente riga:

hostA:/home/administrator /media/exported nfs ro 0 0

disinstallare grub2 e installare grub ubuntu 9.04

Prima di tutto scaricate una distribuzione live tipo Ubuntu 9.04 o succcessive (obbligatorio in caso di filesystem ext4) dopo aver verificato la presenza del collegamento internet eseguire quanto segue Code: sudo fdisk -l Dispositivo Boot Start End Blocks Id System /dev/sda1 * 1 2496 20049088+ 83 Linux /dev/sda2 2497 2610 915705 5 Esteso /dev/sda5 2497 2610 915673+ 82 Linux swap / Solaris con questo comando si riesce a vedere su quale disco viene eseguito il boot nel nostro caso su sda1 dopo aver verificato questo eseguire i seguenti comandi: Code: sudo mount /dev/sda1 /mnt sudo mount --bind /dev /mnt/dev sudo mount --bind /proc /mnt/proc sudo chroot /mnt apt-get purge grub2 apt-get install grub Se i comandi in precedenza non creano errori si continua così: Code: mv /boot/grub/menu.lst /boot rm -fr /boot/grub grub-install /dev/sda update-grub cat /boot/grub/menu.lst exit Dopo aver lanciato update-grub alla richiesta premere "S" o "y" per creare un nuovo menu.lst, se anche questo termina correttamente si può riavviare ed il gioco è fatto.