mercoledì, maggio 08, 2013

genkey CentOS 6.4 (null) error

- post<li> - Permalink

genkey CentOS 6.4 (null) error
Generare certificati self-signed (auto-firmati) su CentOS è piuttosto semplice (NO - non sono uno di quelli che considera semplici 10 comandi openssl con 10 parametri ognuno tra file .key e .crt).

Il comando per generare il certificato per un dominio https è semplicemente 

>genkey nomedominio.it

che attraverso un Wizard con poche semplici domande genera tutti i comandi openssl necessari con i relativi parametri al posto giusto.

Peccato che con l'aggiornamento a CentOS 6.4 sia stato introdotto un bug piuttosto fastidioso che portava a errori simili a questo

Made a key
Opened tmprequest for writing
(null): bad certificate request
: error -8016
(null): Segmentation fault (core dumped)

dovuto alla disabilitazione proprio nella versione 6.4 dell'algoritmo MD5 tra quelli utilizzabili dalla libreria NSS.

La soluzione, una volta trovata (come sempre), è piuttosto semplice.

> export NSS_HASH_ALG_SUPPORT=+MD5
> genkey www.nomedominio.it -days 375

Intuitivo no? ;-)

Mai capitato? A me ultimamente, spesso, allora, l'ho appuntato qui.

Byez

 Vorrei essere amato dalle creature semplici e non discusso dai sapienti di letteratura. 

venerdì, febbraio 08, 2013

Crashing Linux CentOS VMWare

- post<li> - Permalink

Crashing Linux CentOS VMWare

Descrizione del problema

Crashing Linux CentOS VMWare
Tra le Virtual Machine che gestisco ce ne era una biricchina che andava in crash senza apparenti particolari motivi.

Dovendo riavviarla a mano ogni volta, in attesa di trovare una soluzione permanente ho aggiunto a /etc/sysctl.conf la riga
kernel.panic = 20
in modo che si riavviasse in automatico in caso di problemi.

Anche con questa NON soluzione però il downtime era alto. Questo significava che il crash non era secco e definitivo, ma il SO prima di cedere completamente, "languiva", soffriva, per diversi minuti.

Essendo una VM Linux CentOS che fa hosting per siti web dinamici, ho subito pensato che fosse un problema legato al consumo eccessivo di RAM da parte di mysqld o di httpd magari scatenato da qualche DOS.
Appurato dall'analisi dei log degli stessi che non si trattava di questo, ho provato ad aumentare la RAM a disposizione della VM.

Aumentare la RAM a disposizione della VM non ha risolto il problema!

Cosa fare?

Diagnosi

Per diagnosticare il problema, intuendo che fosse qualcosa relativo alla memoria ho aggiunto il seguente comando al "crontab -e"
0 * * * * /usr/bin/top -b -d 60 -n 60 > /tmp/top.$(date "+\%Y-\%m-\%d_\%H:\%M").log
che mi ha prodotto una serie di file (1 ogni ora) con il campionamento ogni minuto dello stato del sistema e di eventuali processi "simpatici".
Dall'analisi di questi file, negli orari in cui si sono verificati i problemi, mi sono saltati subito agli occhi i dati in neretto.
---------------------------------------------------------------------------
top - 13:17:37 up 22:47,  1 user,  load average: 35.22, 16.17, 6.38
Tasks: 134 total,  37 running,  97 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,100.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3107156k total,  2988996k used,   118160k free,      136k buffers
Swap:   524280k total,   524280k used,        0k free,     7288k cached
---------------------------------------------------------------------------
buco nei log
---------------------------------------------------------------------------
top - 14:33:14 up 1 day, 2 min,  1 user,  load average: 69.21, 67.62, 63.53
Tasks: 164 total,  69 running,  95 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,100.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3107156k total,  2988872k used,   118284k free,      108k buffers
Swap:   524280k total,   524280k used,        0k free,     6112k cached
---------------------------------------------------------------------------
riavvio
---------------------------------------------------------------------------
top - 15:05:13 up 1 day, 34 min,  1 user,  load average: 28.66, 63.10, 68.51
Tasks: 130 total,   1 running, 129 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.5%us, 94.9%sy,  0.2%ni,  3.8%id,  0.5%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3107156k total,  1148188k used,  1958968k free,    14880k buffers
Swap:   524280k total,   171828k used,   352452k free,   175056k cached
---------------------------------------------------------------------------
Si tratta del classico problema del Trashing! Bingo! Bisogna aumentare lo spazio di SWAP non la RAM disponibile!

Soluzione (Cura) - attenzione si sta operando su LVM - basta un attimo di distrazione per perdere tutti i dati!

  1. Aggiungere un disco alla Virtual Machine, io ne ho aggiunto uno da 2GB.
  2. Riavviare
  3. Leggere nel dmesg per riconoscere il disco. Es. nel mio caso
    SCSI device sda: 83886080 512-byte hdwr sectors (42950 MB)
    sda: Write Protect is off
    sda: Mode Sense: 61 00 00 00
    sda: cache data unavailable
    sda: assuming drive cache: write through
    SCSI device sda: 83886080 512-byte hdwr sectors (42950 MB)
    sda: Write Protect is off
    sda: Mode Sense: 61 00 00 00
    sda: cache data unavailable
    sda: assuming drive cache: write through
     sda: sda1 sda2
    sd 0:0:0:0: Attached scsi disk sda
      Vendor: VMware    Model: Virtual disk      Rev: 1.0
      Type:   Direct-Access                      ANSI SCSI revision: 02
     target0:0:1: Beginning Domain Validation
     target0:0:1: Domain Validation skipping write tests
     target0:0:1: Ending Domain Validation
     target0:0:1: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 127)
    SCSI device sdb: 4194304 512-byte hdwr sectors (2147 MB)
    sdb: Write Protect is off
    sdb: Mode Sense: 61 00 00 00
    sdb: cache data unavailable
    sdb: assuming drive cache: write through
    SCSI device sdb: 4194304 512-byte hdwr sectors (2147 MB)
    sdb: Write Protect is off
    sdb: Mode Sense: 61 00 00 00
    sdb: cache data unavailable
    sdb: assuming drive cache: write through
     sdb: unknown partition table
    sd 0:0:1:0: Attached scsi disk sdb
    
    
  4. Ora compare con
    > pvscan
      PV /dev/sda2   VG VolGroup00      lvm2 [39,88 GB / 0    free]
      PV /dev/sdb                       lvm2 [2,00 GB]
      Total: 2 [41,88 GB] / in use: 1 [39,88 GB] / in no VG: 1 [2,00 GB]
    
  5. Aggiungiamo il nuovo disco a VolgGroup00 con il comando
    #vgextend "VolGroup00" /dev/sdb
      Volume group "VolGroup00" successfully extended
    
  6. Ancora con
    >pvscan
      PV /dev/sda2   VG VolGroup00   lvm2 [39,88 GB / 0    free]
      PV /dev/sdb    VG VolGroup00   lvm2 [1,97 GB / 1,97 GB free]
      Total: 2 [41,84 GB] / in use: 2 [41,84 GB] / in no VG: 0 [0   ]
    
  7. Bene, ora abbiamo aggiunto il disco al VG (Volume Group), si possono seguire i passi indicati nell'articolo "17.2. Adding Swap Space" per aumentare lo spazio Swap. Quindi:
    # swapoff -v /dev/VolGroup00/LogVol01
    swapoff su /dev/VolGroup00/LogVol01
    
    #lvresize -l +100%FREE /dev/VolGroup00/LogVol01
      Extending logical volume LogVol01 to 2,47 GB
      Logical volume LogVol01 successfully resized
    
    # mkswap /dev/VolGroup00/LogVol01
    Impostazione spazio di swap versione 1, dimensione = 2650796 kB
    
    #swapon -v /dev/VolGroup00/LogVol01
    swapon su /dev/VolGroup00/LogVol01
    
  8. Ora si monitora ancora per un po' il log del "top" e se tutto è ok si rimuove la riga dal "crontab -e"
Questo è uno dei classici problemi abbastanza astrusi da diagnosticare, la cui "cura", per fortuna, risulta piuttosto semplice.

A voi è mai capitato?

Byez

Cuddy: Non nuocere è un punto fermo.
House: Si studia al secondo anno, vero? Ho avuto la mononucleosi quel quadrimestre.

martedì, ottobre 16, 2012

php_admin_value disable_functions = NON funziona

- post<li> - Permalink

phpinfo() disabled?
Cercando di mettere in sicurezza (non è mai troppa) i siti web in hosting sui miei server mi sono accorto di questa particolarità.

E' possibile  da file di configurazione di Apache andare a modificare i valori di PHP in modo da personalizzarli per ogni singolo VHost, il caso tipico è per esempio

#Securing
php_admin_flag allow_url_fopen Off
php_admin_value open_basedir "/var/www/webs/webXXX.com:/tmp" 


Allo stesso modo volevo, come riportato in più di un how-to disabilitare una serie di funzioni pericolose con il comando

php_admin_value disable_functions “show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open”

Peccato che non funzioni! Apache lo digerisce, phpinfo() te la mostra come valore locale diverso dal generale, ma ti mostra che tra le funzioni disabilitate c'è proprio se stessa (vedi immagine articolo)!

L'unico modo per disabilitare delle funzioni è a livello globale dentro al php.ini come confermato da una(!) riga dentro alla documentazione ufficiale:

"This directive must be set in php.ini For example, you cannot set this in httpd.conf."

Facile no?

Che altre sicurezze configurate sempre nei vostri server web?

Byez

Se l'America fosse stata scoperta tante volte quante l'ho scoperta io, nessuno si ricorderebbe di Cristoforo Colombo. 

martedì, settembre 18, 2012

Presentazione Abitat SIT 20/09/2012

- post<li> - Permalink

Normalmente non uso il blog per comunicazioni di servizio, ma a questo evento ci tengo particolarmente.

Per presentrare la nuova (grande) squadra che mi ha preso a bordo!

Se passate per un saluto (o anche un po' di più :-) fatemi sapere!

Byez

Ogni maledetta domenica si vince o si perde, resta da vedere se si vince o si perde da uomini.