Archivi tag: yum

yum-cron: verificare automaticamente la disponibilità degli aggiornamenti su CentOS 6

SO: Linux, , , , , ,

In questo post ho reso disponibile uno scrip bash (scritto di mio pugno) in grado di verificare (tramite yum) la disponibilità di security fix, bug fix e CVE.

Adesso vedremo come estendere tale funzionalità a qualsiasi tipo di update, usufruendo di un pacchetto software creato appositamente per CentOS 6, ovvero yum-cron.

yum

Per prima cosa installiamo il suddetto applicativo:

[root@linuxbox ~]# yum install yum-cron

Ad installazione completa modifichiamo il file di configurazione /etc/sysconfig/yum-cron secondo le nostre esigenze. In particolare, vogliamo fare in modo che ci venga notificata tramite email la disponibilità di eventuali update, senza installare nulla automaticamente:

# Don't install, just check (valid: yes|no)
CHECK_ONLY=yes

# Check to see if you can reach the repos before updating (valid: yes|no)
CHECK_FIRST=yes

MAILTO=vostro.indirizzo@email.it

A questo punto non ci rimane che avviare il servizio yum-cron:

[root@linuxbox ~]# service yum-cron start

e fare in modo che venga eseguito in automatico dopo ogni reboot della nostra macchina:

[root@linuxbox ~]# chkconfig yum-cron on

E’ tutto. Alla prossima.

checksecurity.sh: script bash per monitorare gli aggiornamenti critici su CentOS 6

Sicurezza, SO: Linux, , , , , , , ,

Poichè devo gestire un elevato numero di VM *nix, mi è indispensabile riuscire ad automatizzare quanti più task possibili, tenendo sempre a mente tale regola:

                                                                        a good sysadmin is a lazy one

Uno di questi task riguarda le notifiche per gli aggiornamenti critici di sistema, soprattutto per ciò che concerne l’aspetto della cyber security.

A tal proposito, ho realizzato uno scrip bash in grado di verificare la presenza di eventuali aggiornamenti e di inviarmi successiva notifica via email.  Starà a me, in un secondo momento, decidere quando e se installare gli aggiornamenti proposti.

I tool necessari al suo funzionamento sono 2, ovvero yum-security e mutt. Procediamo dunque con la loro installazione mediante yum:

[root@linuxbox ~]# yum install yum-plugin-security mutt -y

bashEd ecco lo scrip:

#!/bin/bash

logfile=/var/log/checksecurity.log

data=`date +%d-%m-%Y`

destinatario=vostro.indirizzo@email.it

echo "$data: Checking for security updates..." >> $logfile

yum clean all

yum list-security >> /root/checksec/tmp

security=`cat /root/chcksec/tmp | grep security | grep -v Loaded`

bugfix=`cat /root/checksec/tmp | grep bugfix`

cve=`cat /root/checksec/tmp | grep cve`

if [ -n "$security" ];then
echo "$data: security updates available" > /root/checksec/out
fi

if [ -n "$bugfix" ];then
echo "$data: bugfix updates available" >> /root/checksec/out
fi

if [ -n "$cve" ];then
echo "$data: cve updates available" >> /root/checksec/out
fi

if [ -s /root/checksec/out ];then

cat /root/checksec/tmp >> /root/checksec/out

cat /root/checksec/out >> $logfile

cat /root/checksec/out | mutt -s "GESTORE01: security, bugfix and cve system report" $destinatario

rm /root/checksec/out

else

echo "$data: Nothing to do, exiting..." | tee -a $logfile

fi

rm /root/checksec/tmp

exit 0;

Ci rimane solo rendere lo scrip eseguibile (chmod +x /root/checksec/checksecurity.sh) ed aggiungerlo a crontab.

Alla prossima.

Web server benchmarking

SO: Linux, , , , , , , , , , ,

Solitamente, prima di mettere in produzione una Web application, si rende necessario testarla in modo approfondito su di un ambiente apposito, in modo da ridurre al minimo eventuali problemi/disservizi riscontrati dagli utenti che intendono utilizzarla.

Tralasciando i veri test che puntano esclusivamente sull’usabilità e sul corretto funzionamento della Web application in quanto tale (oltre, ovviamente, agli aspetti legati alla sicurezza), è indispensabile effettuare delle prove di carico sul server Web che la ospita (o, in alternativa, sull’application server).

In questo post vi mostrerò come effettuare dei test di carico mediante due tool nati per questo scopo, ovvero httperf ed ab (aka Apache Benchmark).

Installiamo dunque gli applicativi menzionati in precedenza. Il primo potete scaricarlo da qui (CentOS x86_64), mentre il secondo si trova all’interno del package httpd, installabile mediante un semplice packet manager (ad esempio yum):

[root@client ~]# yum install httpd

Per installare httperf (dopo averlo scaricato), potete lanciare il comando:

[root@client ~]# rpm -ivh httperf-0.9.0-1.el6.rf.x86_64.rpm

A questo punto possiamo dare inizio ai nostri test. Per prima cosa faremo delle prove sul server lato utente anonimo, ovvero simuleremo il traffico generato da tutti gli utenti che non hanno ancora effettuato il login (sempre che la nostra Web application lo preveda).

[root@client ~]# httperf --server=ipserverweb --uri=/ --num-conn 12000 --num-call 50 --rate 300 --timeout 5

In questo modo stiamo simulando un numero massimo di 12000 connessioni, ciascuna delle quali effettua 50 chiamate HTTP, ogni sencondo vengono effettuate 300 nuove connessioni (fino al tetto massimo di 12000) ed il timeout di ciascuna connessione è pari a 5 secondi.

Secondo questa logica, possono essere effettuati test di carico ancora più consistenti, ad esempio:

[root@client ~]# httperf --server=ipserverweb --uri=/ --num-conn 50000 --num-call 500 --rate 300 --timeout 30

o ancora:

[root@client ~]# httperf --server=ipserverweb --uri=/ --num-conn 100000 --num-call 1000 --rate 500 --timeout 60

I risultati dei suddetti test ci appariranno in un formato simile al seguente:

Total: connections 4996 requests 249800 replies 249800 test-duration
44.835 s

Connection rate: 111.4 conn/s (9.0 ms/conn, <=1022 concurrent connections)
Connection time [ms]: min 65.0 avg 8439.3 max 12570.1 median 8742.5
stddev 1720.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 50.000

Request rate: 5571.6 req/s (0.2 ms/req)
Request size [B]: 59.0

Reply rate [replies/s]: min 5557.4 avg 5571.4 max 5585.2 stddev 10.5 (8
samples)
Reply time [ms]: response 168.7 transfer 0.1
Reply size [B]: header 229.0 content 5043.0 footer 0.0 (total 5272.0)
Reply status: 1xx=0 2xx=0 3xx=0 4xx=249800 5xx=0

CPU time [s]: user 0.87 system 43.96 (user 1.9% system 98.0% total 100.0%)
Net I/O: 29005.9 KB/s (237.6*10^6 bps)

Errors: total 7004 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 7004 addrunavail 0 ftab-full 0 other 0

Le informazioni presenti nel suddetto report sono lapalissiane e possono tornarci di grande aiuto per ciò che concerne il traffico che il nostro server Web è in grado di reggere.

Nel frattempo, durante i suddetti test, è importante tenere sotto controllo due fattori:

1) l’effettiva raggiungibilità del sito (facendo delle prove di connessione mediante un semplice browser);

2) l’utilizzo delle risorse locali (RAM e CPU). A tal proposito vi consiglio di utilizzare uno strumento abbastanza semplice e più evoluto rispetto al comando top, ovvero htop:

[root@client ~]# yum install htop

La schermata che vi apparirà sarà simile alla seguente:

 

htop.png

Terminati i test lato utente anonimo, iniziamo con quelli lato utente loggato (che sicuramente stresseranno maggiormente la nostra macchina). Infatti, durante questi test verranno processate le chiamate server side (PHP, Jsp, ASP, C# et similia, a seconda della tecnologia utilizzata per implementare la Web application), allocando grosse quantità di RAM (e parte della swap) e facendo lavorare intensamente la (oppure le) CPU.

Come già accennato in precedenza, è possibile effettuare dei test lato utente loggato utilizzando un tool messo a disposizione dell’Apache Software Foundation, ovvero Apache Benchmark (ab). Nella fattispecie, la flag da utilizzare è -C ed usa come argomento il contenuto dell’authentication cookie rilasciato dalla nostra applicazione Web (potete utilizzare questo add-on di Mozilla Firefox in grado di leggere il contenuto del cookie in questione).

Ecco un esempio:

[root@client ~]# ab -n 2 -C "contenuto dell'authentication cookie" http://sitodatestare/

Con la flag -n sto indicando il numero di connessioni che devono essere simulate. Inoltre, i vari campi che compongono l’auth cookie devono essere intervallati da un ; mentre il valore di ciascun campo deve essere preceduto da un =. Ad esempio:

[root@client ~]# ab -n 2 -C "has_js=1; pri_num=3" http://sitodatestare/

Come avrete facilmente intuito, nell’esempio viene effettuato un test molto blando. Passiamo adesso ad alcune prove più impegnative (in termini di carico), utilizzando la flag -c che ha il compito di simulare le connessioni contemporanee:

[root@client ~]# ab -n 20 -c 10 -C "contenuto dell'authentication cookie" http://sitodatestare/

e ancora:

[root@client ~]# ab -n 210 -c 200 -C "contenuto dell'authentication cookie" http://sitodatestare/

e così via.

Il report generato avrà il seguente formato:

Benchmarking *.*.com (be patient)
Completed 100 requests
Completed 200 requests
Finished 210 requests

Server Software:        Apache/2.2.3
Server Hostname:        *.*.com
Server Port:            80

Document Path:          /
Document Length:        36020 bytes

Concurrency Level:      210
Time taken for tests:   89.815037 seconds
Complete requests:      210
Failed requests:        15
   (Connect: 0, Length: 15, Exceptions: 0)
Write errors:           0
Non-2xx responses:      15
Total transferred:      7129290 bytes
HTML transferred:       7030005 bytes
Requests per second:    2.34 [#/sec] (mean)
Time per request:       89815.039 [ms] (mean)
Time per request:       427.691 [ms] (mean, across all concurrent requests)
Transfer rate:          77.51 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   1.3      1       2
Processing:  1748 54696 18359.3  58915   89812
Waiting:     1747 54695 18359.3  58914   89811
Total:       1748 54697 18359.2  58916   89814

Percentage of the requests served within a certain time (ms)
  50%  58916
  66%  64830
  75%  69917
  80%  71274
  90%  76405
  95%  77879
  98%  79840
  99%  80893
 100%  89814 (longest request)

Questo è quanto, buon benchmarking.

Linux: packaging tool e proxy HTTP

Pillole, , , , ,

Usate un packaging tool (aptitude, emerge, yum et similia) per scaricare ed installare i pacchetti sulla vostra macchina Linux? Non avete accesso diretto al Web e quindi necessitate di interfacciarvi con un proxy HTTP? Niente paura, basta seguire questi semplici passi.

variabili di ambiente, aptitude, yum, emerge, export, http proxy

Per prima cosa occorre definire la variabile di ambiente http_proxy, il cui valore dovrà essere simile al seguente:

nightfly@nightbox:~$ export http_proxy=http://192.168.1.1:3128/

dove 192.168.1.1 è l’indirizzo IP del proxy e 3128 la porta su cui è in ascolto.

Se il proxy richiede autentica, è necessario definire la variabile precedentemente citata usando la seguente sintassi:

nightfly@nightbox:~$ export http_proxy=http://username:password@192.168.1.1:3128/

Attenzione però, le variabili di ambiente valgono esclusivamente per l’utente che le definisce. Per fare in modo che una variabile d’ambiente possa essere utilizzata da tutti gli utenti del sistema, è necessario operare sul file /etc/profile:

nightfly@nightbox:~$ sudo nano /etc/profile

ed aggiungere la direttiva:

export http_proxy=http://192.168.1.1:3128/

oppure:

export http_proxy=http://username:password@192.168.1.1:3128/

in caso di autentica.

Infine, per listare le variabili di ambiente basta lanciare il comando:

nightfly@nightbox:~$ export -p

Done.