raid, come ti accelero

segnamoci queste poche informazioni per svegliare il resync del raid, soprattutto quando i dischi sono grossi e i tempi sono stretti:

# sysctl dev.raid.speed_limit_min
# sysctl dev.raid.speed_limit_max

le informazioni ottenute sono la quantita’ minima di kylobyte da sincronizzare e il corrispondente limite massimo.
di norma i valori sono 1000 e 200000. Questi valori sono poi gestiti dal kernel in base ai suoi normali livelli di attivita’ e del flusso di informazioni da’ e verso il disco. Tradotto: se la macchina non sta facendo nulla, allora si puo’ aumentare la velocita’ di sincronizzazione, altrimenti la si tiene bassa.

il valore che piu’ ci puo’ aiutare e’:

# sysctl -w dev.raid.speed_limit_min=50000

ovvero spostare da 1MB a 50MB il limite basso di sincronizzazione. La macchina si siedera’ un pochino, ma il tempo di resync scendera.

ovviamente non solo questi sono i valori necessari per migliorare i tempi; aggiungiamo lo stato di caching del disco (hdparm -W1 /dev/sdX: per aumentarlo) e il readahead dello stesso (blockdev –setra 65535 /dev/sdbX) ….

rifer:

http://www.cyberciti.biz/tips/linux-raid-increase-resync-rebuild-speed.html

Post collegati:

Pubblicato in disk, linux, service | Contrassegnato , , , , | Lascia un commento

speed postfix relay

il numero massimo di di connessioni parallele:
default_destination_concurrency_limit = 30
smtp_destination_concurrency_limit = 30

numero massimo di destinatari per la consegna di messaggi
default_destination_recipient_limit = 50
smtp_destination_recipient_limit = 50

tempo minimo inserito per ogni consegna  verso la stessa destinazione
default_destination_rate_delay = 0s

default_process_limit=100
smtp_mx_session_limit=20

tempo minimo e massimo per i successivi tentativi di spedione di un messaggio deferito
maximal_backoff_time = 1000s
minimal_backoff_time = 200s

limite massimo di connessioni contemporanee da parte di un client.
smtpd_client_connection_count_limit = 100 (default postfix 0)

in un caso sono stato costretto a commentare questa voce, in quanto un'applicazione usata da un cliente non aveva un meccanismo di limitazione delle performance trovandosi poi in errore durante la fase di invio.

tempo di ritardo inserito dopo un errore da parte di client
smtpd_error_sleep_time = 1s

smtpd_soft_error_limit = 10
smtpd_hard_error_limit = 20

numero di connessioni consentite per unita' di tempo da parte di un client. Anche questo e' stato ripassato a 0. Riguarda sempre le connessioni in entrata e siccome riguarda un mio server privato, non problemi di sovraccarico.
smtpd_client_connection_rate_limit = 20

qmgr_message_active_limit = 40000
qmgr_message_recipient_limit = 40000
queue_run_delay = 300s

ps. questo post, sara' destinatato a parecchie revisioni. Questi valori sono sempre in corso di modifica per vedere di migliorare / peggiorare la situazione. Quindi, mi raccomando, prendeteli con la massima attenzione.

Post collegati:

Pubblicato in linux, mail, mail filtering, Uncategorized | Contrassegnato , , , , | Lascia un commento

lvm e raid: caso pratico.

LVM, oltre a tante features interessanti, offre anche un meccanismo di raid 1 piuttosto efficace.
Come tutti i raid, uno dei dischi puo’ rompersi o comunque andare in errore. E’ questo il caso odierno:

caso reale, il disco guasto e’ sdb, macchina inchiodata.

vediamo come abbiamo risolto e come il santo pinguino ci e’ venuto incontro:

1: riavvio macchina, modalita’ amministrativa.
2: identifichiamo il disco con i log e i vari messaggi. nel nostro caso : sdb. Visto che l’assegnazione dei device e’ ormai cosa curiosa, provvediamo a segnarci anche il numero di serie e il modello attraverso hdparm -i /dev/sdb
3: cerchiamo ora di capire come viene utilizzato sdb1. In primo luogo vgscan -vvv; nell’ultima parte e’ presente un elenco che indica quali dischi e quali volumi logici sono associati.

      Adding data:0 as an user of data_mlog

Read data metadata (334) from /dev/sde1 at 238592 size 4788
Freeing VG data at 0x1ffc070.
/dev/sdc1 0:      0 238466: multimedia(0:0)
/dev/sde1 0:      0 476932: freebsd(0:0)
/dev/sdd1 0:      0   5960: system_mimage_1(0:0)
/dev/sdd1 1:   5960 470018: data_mimage_1(0:0)
/dev/sdd1 2: 475978    953: NULL(0:0)
/dev/sda2 0:      0   5960: system_mimage_0(0:0)
/dev/sda2 1:   5960    929: swap(0:0)
/dev/sda2 2:   6889 470018: data_mimage_0(0:0)
/dev/sda2 3: 476907     19: swap(929:0)
/dev/sdb1 0:      0      1: system_mlog(0:0)
/dev/sdb1 1:      1      1: data_mlog(0:0)
/dev/sdb1 2:      2 476929: NULL(0:0)

Bene. Non avendo altro disco libero da agganciare al volo, ho deciso di rimuovere il raid ovviamente in modo dinamico, ovvero direttamente in corsa:

lvmconvert -m 0 /dev/data/system
lvmcomvert -m 0 /dev/data/data

il comando rimuove la seconda partizione, ovvero quella che occupa sdb.
liberata la partizione, provvediamo togliere i riferimenti lvm dal disco, rimuovendo prima il disco dal gruppo lvm:

vgreduce /dev/data /dev/sdb1

e successivamente, rimuoviamo il volume fisico lvm dalla periferica:

pvremove /dev/sdb1

STOP. La prima fase e’ completa.

Ora down della macchina (qualche volta sono cosi’ sadico che queste cose le faccio senza neanche spegnere il pc – potere del pinguino), sostituzione del disco e riavviamo.

il procedimento inverso e’ piuttosto semplice:

creazione della partizione: fdisk, parted, quello che volete. Ricordarsi di marcare la partizione come volume lvm (per fdisk: tipo 8e)
creazione del volume fisico: pvcreate /dev/sdb1
aggiunta del volume fisico al gruppo lvm: vgextend /dev/data /dev/sdb1
creazione del raid:
lvmconvert -m 1 /dev/data/system
lvmconvert -m 1 /dev/data/data

queste ultime due righe sono piuttosto lunghe nell’esecuzione.
tenetevi una console tranquilla in un angoletto in modo che possano finire in pace.

ricordiamoci anche di reinstallare grub con il classico grub-install /dev/sdb

Post collegati:

  • Nessun post correlato
Pubblicato in Uncategorized | Lascia un commento

upgrade da squeeze a wheezy

 

I cambi di release sono sempre un dramma. Parecchie cose potrebbero andare storte, altrettante potrebbero andare peggio. Poi ci sono schemi di configurazioni che cambiamo, comandi non piu’ utilizzabili e tanta altra roba che non finisce piu’.

Oggi ho iniziato ad aggiornare un server di posta squeeze a wheezy e sono saltati fuori un po’ di casini, vediamo di che si tratta:

Mysql: si passa a mysql5.5. In linea di massima, l’upgrade e’ abbastanza indolore, tranne che se nel file my.cfg abbiamo i seguenti comandi:

master-host             = xxx.xxx.xxx.xxx
master-connect-retry    = 60
master-password         = MaStEr-PaSsWoRd
master-user             = MaStEr-UsEr

e’ meglio che li togliamo prima di fare l’aggiornamento, altrimenti diventeremo scemi dopo. Il demone non riparte manco a calci; ci viene richiesta una nuova password e poi appare un triste messaggio che non si riusce ad aggiornare tale password e il servizio resta fermo. Per capire di cosa si tratta, oltre a una ricerca in bugs.debian dove un utente e’ stato bacchettato per non aver letto la documentazione, lanciando a mano mysqld viene evidenziato il problema: il demone parte, mostra l’errore e si riferma. Questi comandi sono stati rimossi definitivamente e pertanto e’ meglio non metterli nella configurazione.

Postfix: postfix si aggiorna tranquillamente, pero’ al riavvio del servizio salteranno fuori una sfilza di warning riferiti a istruzioni presenti in main.conf non utilizzate. In questo caso, non c’e’ da allarmarsi piu’ di tanto. Tutta la baracca continua a funzionare. Per aggiungere carne al fuoco, mi sono preso la briga di commentare nel file main.cfg le righe incriminate:

#smtpd_relay_restrictions = permit_mynetworks,
# reject_unauth_destination,
# permit_sasl_authenticated,
# reject
virtual_maildir_limit_message = Sorry, the user's maildir has overdrawn his diskspace quota, please try again later.
virtual_mailbox_limit_message = Sorry, the user's maildir has overdrawn his diskspace quota, please try again later.
virtual_mailbox_limit_maps = proxy:mysql:$config_directory/local_mailbox_size.cf
virtual_maildir_limit_override = yes
virtual_mailbox_limit_override = yes
virtual_overquota_bounce = yes
virtual_maildir_limit_maps = proxy:mysql:$config_directory/local_mailbox_size.cf
virtual_create_maildirsize = yes
virtual_mailbox_extended = yes
virtual_maildir_extended = yes
autoresponder_destination_recipient_limit = 1

Dovecot: per chi utilizza come imap,pop,lda,sieve il server dovecot, c’e’ da tenere presente che tutta la configurazioni – ma proprio tutta, cambia di brutto. Tutto quello che inizialmente era contenuto in un singolo file o poco piu’ e’ stato pesantemente spezzettato in una caterva di file piu’ piccoli, ognuno specializzato in qualcuno degli aspetti del demone. Non e’ possibile nemmeno reciclare temporaneamente il vecchio file di configurazioni in quanto cambia pesantemente anche il meccanismo di configurazione. Il mio suggerimento e’ quello utilizzare uno schema di configurazione vergine e riportare i propri parametri riadattati. Ho provato a usare un file di configurazione vecchio stampo, ma ho notato troppe cose che non vanno.

amavis: secondo la procedura di upgrade il nuovo file di configurazione ha uno schema diverso rispetto al vecchio. Il vecchio viene rinominato in amavis.conf.disable che impedisce ad amavis di ripartire. ho prelevato questo file, l’ho rimesso al posto del nuovo togliendo la parolina disabled. il servizio e’ ripartito regolarmente. Piccola nota a margine: e’ possibile che vi arrivino notifiche circa’ la necessita’ di avviare lo script di manutenzione di amavis con utente amavis:

/etc/cron.daily/amavisd-new:
Please run this cronjob as user amavis
run-parts: /etc/cron.daily/amavisd-new exited with return code 1

No problems. Il nuovo amavis inserisce uno script in  /etc/cron.daily. Questo scritp e’ identico a quello in cron.d. ho tolto il primo e lasciato quello vecchio dove e’ indicato chiaramente quale utente deve essere usato quando lanciato.

Apache2: il vecchio file di configurazione fa riferimento al suo interno a httpd.conf. Questo file non e’ piu’ presente nella nuova installazione quindi e’ necessario verificare il proprio apache2.conf e togliere i riferimenti a questo file.

Attenzione pure, durante la fase di aggiornamento nel selezionare – quando viene richiesto – il mantenimento dei vostri file di configurazione. Se avete gia’ la certezza che la cosa non vi riguarda, potete anche dire di sostituire i vecchi con quelli forniti con il nuovo pacchetto, ma tranne pochi casi, immagino che tutti voi abbiate personalizzato i vari files, quindi e’ il caso di mantenerli affiancandoli a quelli che finiscono con dpkg-inst, ovvero quelli nuovi.

rotatelog: ha subito piccole modifiche, tra cui un

< invoke-rc.d rsyslog reload > /dev/null

>l invoke-rc.d rsyslog rotate > /dev/null

il problema si verifica quando, durante la notte avviene il ciclo sui log. L’applicazione va in crash.

Ultimi dettagli: posso immaginare, che tanti, siate soliti riutilizzare i vecchi file di configurazione anche con le nuove installazioni. Faccio anche io cosi’, ma prima di chiudere il posto, suggerirei di confrontare il proprio file con il nuovo file installato da apt e chiamato “nome vecchio file.conf”.dpkg-dist. Spesso le cose saranno le stesse, quindi potete cancellare il nuovo file e via, ma qualche volta, il nuovo file introduce opzioni nuove non presenti nel vecchio che potrebbero tornare comode. In questo caso, mi metto di santa pazienza e migro le vecchie configurazioni nel nuovo file che vado a sostituire al vecchio.

Altra cosa utile: nella condizione standard di debian, durante un upgrade, vengono spenti dei demoni interessati alla manovra e riavviati quando la configurazione e’ terminata. Se ci sono parecchi pacchetti da aggiornare e’ papabile che il demone venga fermato e riavviato dopo diverso tempo che potrebbe diventare troppo lungo. In questo caso ci viene in aiuto un semplice file:

policy-rc.d posizionato in /usr/sbin, con i flag di esecuzioni attivi, con il seguente contenuto:

#!/bin/bash
exit 101

la presenza di questo file impedisce il riavvio dei demoni. Ovviamente la cosa piu’ rivelarsi rischiosa con servizi delicati in quando – se faccio l’esempio di mysql – il servizio viene completamente rimosso per poi essere reinstallato quindi non garantisco che il non spegnerlo non provochi problemi indiretti causa la mancanza di pezzi precedentemente rimossi. Nel mio caso e’, p.esempio, tornata utile nell’aggiornare un host xen e evitare di trovarmi con tutte le macchine virtuali stoppate in attesa di completare l’aggiornamento. Ovvio che la situazione e’ temporanea, in quanto i nuovi aggiornamenti potrebbero essere vitali. E’ suggeribile, una volta finito l’aggiornamento, riavviare manualmente i servizi e verificare che tutto sia a posto.

Post collegati:

Pubblicato in Debian, http, linux, mail, operating system, sharing, sql | Contrassegnato , , , , , , , , , | Lascia un commento

Freebsd: come upgradare da i386 a amd64

questo link: https://wiki.freebsd.org/amd64/i386Migration e’ un ottimo punto di partenza per procedere all’upgrade di una macchina freebsd i386 a amd64 bit.
Non e’ stata scritta per la versione 10 di Freebsd, ma funziona benissimo.
di Fondo, installa una versione temporanea del sistema sfruttando l’area di swap. Successivamente procede all’upgrade vero e proprio.

allego la versione attuale in formato pdf, sia mai che il sito ufficiale smettese di esistere: amd64_i386Migration – FreeBSD Wiki

Post collegati:

Pubblicato in bsd, operating system | Contrassegnato , , , | Lascia un commento

lvm: gli appunti

lvm fa’ tanto, lvm e’ complesso, lvm ha un mare di comandi: questo e’ certo.

intanto come ottenre qualche info:

lvs -o +devices

lvs -o +devices,seg_pe_ranges

visualizza l’elenco dei volumi logici e affianco su quali dischi i volumi vanno a posizionarsi. Nota: nell’elenco che viene visualizzato puo’ darsi che non sia segnalato qualche volume fisico: no problems, potrebbe essere semplicemente il caso che quel volume e’ vuoto e pertanto non ci sia nulla da visualizzare. Potete verificare la correttezza della cosa con pvs. mettendo l’opzione deq_pe_ranges, abbiamo modo di sapere anche quanto esattamente e’ stato allocato.

pvs (ma anche pvscan)

visualizza informazioni circa i volumi fisici. lanciato cosi’, visualizza lo stato di occupazione dei volumi.

pvmove: consente di spostare l’insieme dei volumi logici presenti su un disco fisico su un altro disco. e’ un’operazione lenta e bisogna attendere. Il vantaggio e’ che si puo’ continuare a lavorare anche se leggeremente piu’ lenti.

Da ricordarsi, ogni volta che si gioca con i volumi fisici, di fare un update-grub e verificare la corretta configurazione di grub stesso. Altrimenti, al prossimo boot non si parte. Se appare un errore del tipo che non viene trovato un volume fisico PVX, significa che /boot/grub/device.map non e’ corretto. Stesso discorso se viene visualizzato un errore relativo proprio a device.map mentre viene effettuato un update-grub. Soluzione spiccia: rimuovere device.map e di nuovo update-grub. Se invece il danno e’ stato fatto e siamo gia’ incasinati al riavvio, basta risolvere avviando velocemente con un cd di emergenza e fare le stesse cose.

link:

http://www.datadisk.co.uk/html_docs/redhat/rh_lvm.htm

 

 

Post collegati:

  • Nessun post correlato
Pubblicato in disk, lvm | Lascia un commento

Raid e gpt e grub: tripletta infernale.

Mi son trovato a dover risolvere un piccolo problema di incompatibilita’ tra partizioni tradizionali, partizioni gpt, raid e lvm.

Il server in questione e’ nato inizialmente con due dischi in raid software suddivisi in una piccola partizione di boot e il restante con volume lvm.

La partizione iniziale dei due dischi e’ stata fatta nella classica via MBR.

Durante la sostituzione di un disco guasto, il nuovo disco e’ stato erroneamente partizionamento con GPT.

Apperentemente tutto ha continuato a funzionare correttamente. Riavvi del sistema senza problemi, ripristino del raid ok, installazione grub ok.

Il problema serio e’ saltato fuori quando si e’ presentata la necessita’ di sostituire il disco ancora partizionato BSD. La macchina non ne voleva sapere di fare il boot dal disco GPT.

Un po’ di analisi ed e’ venuto fuori che indipendentemente dalla presenza o meno di errori, grub si installava correttamente ma ignorava – senza segnalarlo che il disco GPT non andava bene in quanto e’ ormai noto che senza una partizioncina dedicata, il fetente non si installa su questo dipo di disco (tenete presente anche la presenza del RAID).

Ravanando in giro ho trovato il tool gdisk che consente di convertire allegramente una partizione GPT in MBR e viceversa senza danni e piagnistei. Il tool e’ semplicissimo da installare e da usare.

Per inciso, opzione “r” per i backup e i cambiamenti e “g” per passare da un tipo all’altro.

Il resto dei comandi ve li lascio a Voi. Ovviamente, per precauzioni fatevi prima un backup delle vostre partizioni, che la cacchiata e’ sempre dietro l’angolo. gdisk consente anche di fare salvataggi e ripristini, quindi la cosa e’ oltremodo facilitata’. Occhio pure che i comandi vengono eseguiti immediatamente, quindi una volta premuto il tasto di un’eventuale conversione, l’operazione viene immeditamente fatta sul disco.

Una volta fatto il cambiamento da GPT a MBR, e’ importante anche reinstallare grub in modo che il bimbo acquisisca i cambiamenti fatti.

Nel caso qualcosa vada storto – nei miei esperimenti, la macchina virtuale non e’ partita un paio di volte – le operazioni relative a grub-install, gdisk e soci le ho fatte avviando da cd.

 

Post collegati:

Pubblicato in boot, Debian, disk, linux, lvm, raid, tools | Contrassegnato , , , , , | Lascia un commento

osx impostazioni di rete manuali

ok… radunando i vari comandi che di tanto in tanto tornano comodi:

settaggio schede di rete da console:

networksetup -setmanual “service” “ip” “mask” “gw”

networksetup -setdnsservers “service” “dns1” “dns2”

per “service” si intende l’interfaccia su cui si deve lavorare. Per visualizzare le interfacce:

networksetup -listallnetworkservices

per il resto…. san google

Post collegati:

  • Nessun post correlato
Pubblicato in Uncategorized | Lascia un commento

E il doppio arduino…

Stavolta ho deciso di provare come viaggiano due arduino tra di loro.

Nella documentazione di base scopro che gli arduino supportano la comunicazione i2c. Tale protocollo fatto solo di 3 fili (dati, clock e gnd), consente di avere a disposizione un bus su cui collegare piu’ apparecchiature in grado di comunicare tra loro in modo semplice e diretto.

La libreria che consente questa meraviglia si chiama Wire.

Il sistema e’ abbastanza semplice:

Chi deve trasmettere, inizializza la libreria (Wire.begin()), apre il canale di comunicazione indicando il destinatario (Wire.beginTrasmission(x)), invia quello che deve inviare (Wire.write(xx)), e chiude il canale (Wire.endTransmission()).

Il modulo che riceve, e’ leggermente piu’ complesso: inizializza il canale indicando pero’ l’id di riconoscimento (Wire.begin(x)).

La parte interessante, e’ la gestione degli eventi: la libreria Wire include la giusta funzione proprio per permettere di associare un evento nel momento in cui i dati sono disponibili: Wire.onReceive(evento).

la funzione indicata in onReceive: evento(int qualchecosa), deve in primo luogo verificare se ci sono i dati sul canale: while(Wire.available() >0).
se ci sono dati disponibili, si possono prelevare con Wire.read().

In questa fase non ci sono da aprire canali. La funzione si attiva nel momento giusto.

Morale: in questo modo e’ possibile pilotare piu’ di un arduino affinche’ possano svolgere al meglio specifiche’ funzionalita’: p.es.: il primo arduino effettua i rilevamente di alcuni sensori. Il secondo si occupa magari di svolgere attivita’ su led e rele’. Alla fine, un Raspberry o qualche altra cosa, potrebbe ricevere i dati dei sensori, elaborarli e trasmetterli al secondo arduino che provvedera’ ad attivare determinati compiti. Nel mio test, ho collegato un led e un buzzer, attivandoli e disattivandoli in base ai valori 0 e 1 inviati dal primo arduino.

alcuni riferimenti:

la funzionalita’ che ho usato e’ meglio descritta qui:
http://arduino.cc/en/Tutorial/MasterWriter e
http://arduino.cc/en/Reference/Wire.

una nota, nel primo link, alla riga dove viene indicato il while: while(1<Wire.available()) credo che l’uno debba essere uno zero. A me funziona solo con zero. decidete voi.

Post collegati:

  • Nessun post correlato
Pubblicato in arduino | Lascia un commento

Arduino 2: il led che cambia…

Iniziamo a entrare nel merito, anche se siamo ancora lontani da qualcosa di utile.

Ho collegato un led e la sua resistenza (220 ohm) tra le uscite 3 (pwm) e la terra.

Da quanto ho capito le uscite PWM (ovvero quelle identificate come “~”) possono assumere una serie di valori variabili che vanno da 0 a 255.

Ho scritto poche righe di codice che definiscono quanto segue:

#define LEDV 3
int value = 1;
int livello = 0;

void setup()
{
pinMode(LEDV,OUTPUT);
}

void loop()
{
if (livello < 10) { value = 1; }
if (livello > 200) { value = -1; }
livello += value;
analogWrite(LEDV,livello);
delay(15);
}

in pratica:

ho definito quale porta usare: #DEFINE ….
ho definito due interi: value (che puo’ assumere due valori: +1 e -1),
ho indicato come la porta deve agire: nel mio caso deve inviare una tensione in uscita (che poi tensione non e’ in quanto la tecnica e’ quella switching).

livello, che contiene il valore da scrivere sulla porta PWM.
il codice e’ semplice:
la voce ‘livello’ aumenta o diminuisce in base a ‘value’ e successivamente viene inviato alla porta con la funzione analogWrite.
Ho aggiunto un piccolo delay affinche’ l’oscillazione del valore del led non sia troppo veloce.

aho! Il codice fara’ pure schifo, ma funziona.

Post collegati:

  • Nessun post correlato
Pubblicato in arduino | Contrassegnato , , | Commenti disabilitati su Arduino 2: il led che cambia…