dilluns, 11 de novembre de 2013

MySQL connections mass killing

Si ens veiem amb la necessitat de matar connexions de MySQL masivament, el següent tutorial ens pot resultat d'utilitat. La següent taula conté la informació que obtenim quan realitzem un show processlist;
SELECT * from information_schema.processlist;
626 rows in set (0.00 sec)
La taula conte els següents atributs:
mysql> describe information_schema.processlist;
+---------+-------------+------+-----+---------+-------+
| Field   | Type        | Null | Key | Default | Extra |
+---------+-------------+------+-----+---------+-------+
| ID      | bigint(4)   | NO   |     | 0       |       |
| USER    | varchar(16) | NO   |     |         |       |
| HOST    | varchar(64) | NO   |     |         |       |
| DB      | varchar(64) | YES  |     | NULL    |       |
| COMMAND | varchar(16) | NO   |     |         |       |
| TIME    | int(7)      | NO   |     | 0       |       |
| STATE   | varchar(64) | YES  |     | NULL    |       |
| INFO    | longtext    | YES  |     | NULL    |       |
+---------+-------------+------+-----+---------+-------+
8 rows in set (0.02 sec)
Per tant, si en algun moment tenim moltes connexions en el show processlist i necessitem matar-les podem utlitzar aquesta taula per generar la llista de connexions a matar.
SELECT CONCAT('KILL ',id, ';') from information_schema.processlist \
where user='someone' into outfile 'mass_kill.out';
Si mirem el contingut del fitxer mass_kill.out trobarem alguna cosa semblant a:
+-------------------------+
| CONCAT('KILL ',id, ';') |
+-------------------------+
| KILL 2039971;           | | KILL 2039970;           | | KILL 2039968;           | | KILL 2039967;           | | KILL 2039966;           | | KILL 2039960;           | | KILL 2039959;           | | KILL 2039958;           | | KILL 2039955;           | | KILL 2039954;           | | KILL 2039953;           | | KILL 2039951;           | | KILL 2039950;           | | KILL 2039949;           | | KILL 2039948;           | | KILL 2039947;           | ...

Per a carregar-nos les connexions només hem d'executar la següent comanda:
mysql> source /tmp/mass_kill.out
Si necessitem guardar les comandes utlitzades així com canviar el pager per defecte la següent comanda ens pot resultar útil.
mysql> \P cat | tee /home/user/mysql_output.txt | less -n -i -S
PAGER set to 'cat | tee /home/user/mysql_output.txt | less -n -i -S'
mysql> SELECT * from information_schema.processlist;

ENLLAÇOS:


http://www.dbasquare.com/2012/05/15/why-do-threads-sometimes-stay-in-killed-state-in-mysql/
http://www.percona.com/doc/percona-toolkit/2.1/pt-kill.html
http://www.mysqlperformanceblog.com/2009/05/21/mass-killing-of-mysql-connections/

dijous, 10 d’octubre de 2013

MySQL User Creation/Deletion

La gestió d'usuaris en MySQL la realitzem utilitzant les comandes GRANT i DROP.

Creació d'usuaris

Per a la creació d'usuaris utilitzarem la comanda grant. En la següent pàgina trobarem els permisos que poden ser associats.
mysql>use mysql
mysql> \P less
Podem concedir tots els privilegis a un usuari.
mysql>GRANT ALL PRIVILEGES ON *.* To 'someone'@'%' \
      IDENTIFIED BY 'StrongPass';
També podem concedir permisos especifics a un usuari, en aquest li donem permisos per a realitzar selects, mostrar els procesos i obtenir informacio de la replicació master/slave.
mysql>GRANT SELECT,PROCESS,REPLICATION CLIENT ON *.* To \
      'someone'@'%' IDENTIFIED BY 'StrongPass';
Una volta concedits els permisos comprobem que siguen correctes:
mysql-nl> select * from user\G;
                  User: someone
              Password: *E1gfddfstrwttrtw4352tdftg5456rgetterter
           Select_priv: Y
           Insert_priv: N
           Update_priv: N
           Delete_priv: N
           Create_priv: N
             Drop_priv: N
           Reload_priv: N
         Shutdown_priv: N
          Process_priv: Y
             File_priv: N
            Grant_priv: N
       References_priv: N
            Index_priv: N
            Alter_priv: N
          Show_db_priv: N
            Super_priv: N
 Create_tmp_table_priv: N
      Lock_tables_priv: N
          Execute_priv: N
       Repl_slave_priv: N
      Repl_client_priv: Y
      Create_view_priv: N
        Show_view_priv: N
   Create_routine_priv: N
    Alter_routine_priv: N
      Create_user_priv: N
            Event_priv: N
          Trigger_priv: N
Create_tablespace_priv: N
              ssl_type:
            ssl_cipher:
           x509_issuer:
          x509_subject:
         max_questions: 0
           max_updates: 0
       max_connections: 0
  max_user_connections: 0
                plugin:
 authentication_string: NULL

Borrat d'usuaris

Per a borrar un usuari utilitzarem la comanda drop. Despres comprobem que efectivament l'usuari ha sigut eliminat de la taula mysql.
mysql>use mysql
mysql>drop user 'someone';
mysql> \P less
PAGER set to 'less'
mysql-nl> select * from user\G;

divendres, 27 de setembre de 2013

ACLs in Linux

Linux com a sistema compatible amb POSIX permet diferents esquemes per a gestionar la politica accesos als fitxers del disc. Generalment s'utlitza el sistema de permisos d'accés però també es poden utilitzar ACL. En aquest tutorial aprendrem a utilitzar les ACLs (Access Control Lists).

Comprobar que les ACLs estan activat:

Per a poder utilitzar aquestes comandes necessitem que en el fitxer /etc/fstab estiga configurada l'opció acl. Ho comprovem visualitzant el contingut del fitxer.
#
# /etc/fstab
/dev/mapper/sysvg-root  /               ext4    defaults        1 1
/dev/sda1               /boot           ext4    defaults        1 2
/dev/mapper/sysvg-data  /data           ext4    defaults        1 2
/dev/mapper/sysvg-usr   /usr            ext4    defaults        1 2
/dev/mapper/sysvg-var   /var            ext4    defaults        1 2
/dev/mapper/sysvg-swap  swap            swap    defaults        0 0
tmpfs                   /dev/shm        tmpfs   defaults        0 0
devpts                  /dev/pts        devpts  gid=5,mode=620  0 0
sysfs                   /sys            sysfs   defaults        0 0
proc                    /proc           proc    defaults        0 0
O executant la comanda mount:
[root@home log]# mount
/dev/mapper/sysvg-root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext4 (rw)
/dev/mapper/sysvg-data on /data type ext4 (rw)
/dev/mapper/sysvg-usr on /usr type ext4 (rw)
/dev/mapper/sysvg-var on /var type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
Tot i que la opció acl no està especificament declarada pot estar habilitada per defecte per a estar 100% segurs podem utilitzar la següent comanda
[root@home log]# tune2fs -l /dev/mapper/sysvg-var | grep acl
Default mount options:    user_xattr acl
Per tant es podem utilitzar les comandes getfacl i setfacl sobre les particions que presenten aquest atribut al executar la comanda anterior.

Utilització d'ACL:

Per a gestionar les ACLs (Access Control Lists) disposen de dues comandes:
  • setfacl - Set file access control list.
  • getfacl - Get file access control list.
Un fitxer al que mai li hem aplicat un acl, si executem la comanda getfacl sobre ell, presenta el següent aspecte:
[root@home log]# getfacl maillog
# file: maillog
# owner: root
# group: root
user::rw-
group::---
other::---
Amb l'utilitat setfacl podem concedir access a un usuari sobre un fixer especific. Per concedir accés de lectura només al usuari user1 al fixer /var/log/maillog executariem la següent comanda:
[root@home log]# setfacl -m u:user1:r  /var/log/maillog
Com es pot veure ara apareix un signe + si realitzem un ls que indica que s'ha afegit nous atributs al fitxer.
[root@home log]# ls -la /var/log/maillog
-rw-r-----+ 1 root root  3665 Sep  6 04:30 /var/log/maillog
Si tornem a executar la comanda getfacl per visualitzar de nou els atributs veurem que s'ha afegir l'usuari user1.
[root@home log]# getfacl /var/log/maillog
getfacl: Removing leading '/' from absolute path names
# file: var/log/maillog
# owner: root
# group: root
user::rw-
user:user1:r--
group::---
mask::r--
other::---

Rotació de logs amb ACL:

Per a evitar que quan es produeixca la rotació de logs es canvien els permisos del log haurem de modificar la configuració del log en questió. En el nostre cas el log es /etc/logrotate.d/maillog. La configuració quedaria com segueix:
 
/var/log/maillog
{
    sharedscripts
    copytruncate
    compress
    postrotate
        /usr/bin/setfacl -m u:user1:r  /var/log/maillog*
    endscript
}
Una volta configurat forcem la rotació per a assegurar-nos que funciona.
 logrotate -f maillog

Enllaços:

http://www.ghacks.net/2010/01/28/further-control-of-linux-files-with-acl/ http://serverfault.com/questions/258827/what-is-the-most-secure-way-to-allow-a-user-read-access-to-a-log-file http://bencane.com/2012/05/27/acl-using-access-control-lists-on-linux/

dimarts, 10 de setembre de 2013

SSH a box using ILO


Si perdem la connectivitat a un servidor amb una tarjeta ILO (HP) o Drac (Dell) configurada podem ser capaços de conectar-nos per SSH.

Aquest es el procediment per a un servidor HP que utilitza ILO. El servidor disposa d'una subxarxa de gestio per a ILO i una subxarxa per al trafic que genera ILO. Açò dependrà de com estiga configurat el servidor o datacenter en qüestió.

Si ens connectem a la ilo de "management", en el nostre cas 1.2.3.4 per SSH amb les credencials d'access previament configurades a la tarjeta ILO aconseguirem access al subsistema ILO. Una volta allí, si teclegem la comanda vsp podrem conectar-nos per SSH al sistema operatiu de la màquina.

La següent eixida de consola mostra tot el procés:
 
login as: root
root@1.2.3.4's password:
User:root logged-in to testmachine-ilo.(192.168.1.1)
iLO 3 Advanced 1.26 at  Aug 26 2011
Server Name: my-hpserver
Server Power: On

</>hpiLO->


</>hpiLO-> vsp

Virtual Serial Port Active: COM2

Starting virtual serial port.
Press 'ESC (' to return to the CLI Session.


Red Hat Enterprise Linux Server release 5.8 (Tikanga)
Kernel 2.6.18-308.8.2.el5 on an x86_64

my-hpserver login:

ENLLAÇOS:

http://stivesso.blogspot.co.uk/2012/02/hp-ilolinux-output-to-vsp-for-linux.html
http://newton.ph.unito.it/~berzano/w/doku.php?id=blog:ilo_vsp_linux
http://h10025.www1.hp.com/ewfrf/wc/document?cc=us&lc=en&dlc=en&tmp_geoLoc=true&docname=c03595461
http://blog.chrysocome.net/2013/05/proliant-virtual-serial-port.html

dimarts, 16 de juliol de 2013

Finding the largest files in Linux

Trobar fitxers grans en linux


Per a trobar els fitxers o directoris mes grans d'un sistema linux son molt útils les següents comandes:
find . -type d -print0 | xargs -0 du -s | sort -nr | head \
     -20 | cut -f2 | xargs -I{} du -sh {}
find . -type f -print0 | xargs -0 du -s | sort -nr | head \
     -20 | cut -f2 | xargs -I{} du -sh {}
Existeixen dues tecniques per tractar els espais en els noms dels fitxers. Utilitzant find -print 0 | xargs -0 que utilitzen delimitadors null en lloc de espais. La segona xargs -I{} utilitza new lines en lloc de espais per a marcar el final dels diferents elements.

Si el mètode anterior tarda molt, podem utilitzar el següent mètode més ràpid però menys precís.
du --max-depth=4 -x | sort -nr | head -n 20

Altres mètodes mes imperfectes:


La comanda du permet obtenir una estimació del espai que els fitxers mes pesats d'un directori, però no es recursiva.
du -sm * |sort -nr | head -10 
du -a /var | sort -nr | head -n 10
Aquesta comanda presenta el problema amb els fitxer majors de 999 Mb que no els ordena be.
for i in G M K; do du -ah  2>/dev/null | grep [0-9]$i | sort -nr -k 1; \
    done | head -n 10
La comanda find serveix per a buscar qualsevol fitxer, a més per a cada fitxer trobat permet executar una comanda sobre ell. El següent exemple busca per tot el sistema de fitxers, fitxers amb mes de 20Mb, executa un ls per cada fitxer i despres formateja l'eixida amb les columnes correctes.
find / -type f  -size +20M -exec ls -lh {} \; 2>/dev/null |awk  \
    '{print $NF ": " $5}' | sort -nrk 2,2
Aquesta comanda recorre tot el sistema de fitxers:
du -sk $(find . -type d) | sort -n -k 1
find . -type d -exec du -sk {} \; |  sort -n -k 1
A la fi les comandes mes eficients per a realitzar aquesta tasca son les 2 primeres que hem presentat.

Opcions de les comandes:


Les opcions utils de la comanda du son les següents:
   -h -> Human readable.
   -s -> Resum. Agrupa per directoris.
   -m -> Block size 1M
   -a -> Informació detallada de tots els fitxers, no sols directoris.
   -x -> Només un sistema de fitxers, evita directoris en altres 
         sistemes de fitxers.
La comanda sort serveix per ordenar qualsevol eixida de text.
   -n ordenacio númerica.
   -r ordenacio inversa
   -k per a marcar columnes amb les que ordenar
La comanda find es poden buscar fitxer majors o menors que un determnat valor utilitzant el següent flag:
   +size major que
   -size menor que

Enllaços:


http://superuser.com/questions/9847/linux-utility-for-finding-the-largest-files-directories
http://www.cyberciti.biz/faq/find-large-files-linux/
http://www.cyberciti.biz/faq/how-do-i-find-the-largest-filesdirectories-on-a-linuxunixbsd-filesystem/
http://linuxlookup.com/howto/find_all_large_files_linux_system

divendres, 28 de juny de 2013

Getting performance over InnoDB

Hardware:


Per fer funcionar optimament una Base de Dades MySQL amb InnoDB, hem de parar especial atenció a: CPU, memòria i disc.

De aquesta 3 elements la CPU es l'element menys important ja que no serà el nostre bottleneck. Ha de ser de 64 bits per a poder utilitzar mes RAM.

La memoria te més importancia, necessitarem almenys tanta memoria com la nostra base de dades. Quan mes dades puguem tindre en memoria menys accesos a disc necessitarem i per tant millorarà molt el rendiment de la base de dades.

El disc és l'element més important. Serà el bottleneck de la base de dades per tant necessitem discos el mes rapids possible i configurats amb Raid 10. El controlador RAID hauria de tenir Write-Back catxe.

En el cas de que la màquina s'utilitze per configurar un slave, com la replicació es realitza amb un unic thread, llavors s'haurà de planificar la màquina amb un disc més rapid i una cpu mes rapida. En aquest tipus de configuració aquestes característiques importen més.

Sistemes de Fitxers:


Utilitzar sistemes de fitxers com ext4 o xfs en lloc de ext3 millorarà el rendiment general del sistema. També es útil utilitzar LVM. Facilita els backups.

Innodb tunning:


Aquestos son els elements a configurar quan volem obtenir mes rendiment d'una base de dades innodb.
  • Innodb_buffer_pool
  • Innodb_log_file_size
  • Innodb_log_buffer_size
  • Innodb_flush_log_at_trx_commit
  • Innodb_thread_concurrency 
  • Innodb_flush_method
  • Innodb_file_per_table

Innodb_buffer_pool:

Quan mes gran siga aquest valor més actuara la base de dades com una base de dades in-memory i mes rendiment tindra ja que minimitzarà els accessos a disc que son molt costosos.

Si la base de dades es xicoteta un valor acceptable es un 10% de la mida de la base de dades. Si la base de dades es gran llavors reservarem un 10% menys de la seua mida. El valor que reservem en la practica sempre serà mes gran. La base de dades sempre reserva memoria per a estructures auxiliars

Normalment reservant 256 MB de RAM per al sistema sera suficient en la majoria de maquines. En maquines amb mes recursos un 5% de la RAM la deixarem per al sistema. Tot aço depén del nombre de conexions i altres procesos que corren en el sistema.

Si no estem massa segurs un valor entre el 70% i el 80% de la memoria RAM es un valor per començar si la base de dades es suficientment gran.

Innodb_log_file_size:

Aquest parametre s'utilitza per a definir la mida dels logs de MySQL ib_logfile0 i ib_logfile1.
Aquestos logs son circulares i els utilitza MySQL per a minimitzar els accessos a disc i per a recuperar dades. Un valor de 64M sol ser suficient per a la majoria de necessitats.

mysql> \P grep 'Log sequence number'
PAGER set to 'grep 'Log sequence number''
mysql> SHOW ENGINE INNODB STATUS\G SELECT SLEEP(60); SHOW ENGINE INNODB \
    STATUS\G;
Log sequence number 14994414540947
1 row in set (0.00 sec)

1 row in set (59.99 sec)

Log sequence number 14994416309995
1 row in set (0.00 sec)

ERROR:
No query specified

mysql> \P
Default pager wasn't set, using stdout.

mysql> select ROUND((14994416309995 - 14994414540947) / 1024 / 1024) AS MB;
+------+
| MB   |
+------+
|    2 |
+------+
1 row in set (0.00 sec)

Per tant si en 1 minut es generen 2 MB en 60 minuts tindrem 120MB, dividit entre 2 fitxers, 60Mb cada fitxer.

En les versions de MySQL posteriors a 5.1 podem realitzar el càlcul de la següent manera.

mysql> SELECT @a1 := variable_value AS a1
    -> FROM information_schema.global_status
    -> WHERE variable_name = 'innodb_os_log_written'
    -> UNION ALL
    -> SELECT Sleep(60)
    -> UNION ALL
    -> SELECT @a2 := variable_value AS a2
    -> FROM information_schema.global_status
    -> WHERE variable_name = 'innodb_os_log_written';
+---------------+
| a1            |
+---------------+
| 1611291073024 |
| 0             |
| 1611295460864 |
+---------------+
3 rows in set (1 min 0.00 sec)

mysql> SELECT ROUND((@a2-@a1) * 60 / 1024 / 1024 /  @@innodb_log_files_in_group) as MB;
+------+
| MB   |
+------+
|  126 |
+------+
1 row in set (0.00 sec)
Innodb_log_buffer_size:

Aquest parametre s'utilitza per definir la mida del buffer que InnoDB utilitza per a escriure els logs al disk. Si aumentem aquest valor estem permeten que les grans transaccions puguen correr sense xafar disc escriure a disc fins que arribe una transacció de commit. Normalment 4MB son suficient si no tenim un gran volum de BLOBS.

Aquesta comanda mostra el valor del log:

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_log_buffer_size';
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| innodb_log_buffer_size | 33554432 |
+------------------------+----------+
1 row in set (0.00 sec)
Si el següent valor es zero o proper a zero el parametre esta ben configurat, si aquest valor es alt i va creixent necessitarem incrementar el valor del buffer. 

 mysql> SHOW GLOBAL STATUS LIKE 'innodb_log_waits';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Innodb_log_waits | 0     |
+------------------+-------+
1 row in set (0.00 sec)

Innodb_flush_log_at_trx_commit:

 El valor per defecte es 1. Aquest valor es l'únic que garanteix que les transaccions respecten ACID.
Qualsevol valor diferent d'1 millorarà el rendiment però pots perdre fins a 1 segon de transaccions.

  • Valor 1: Respected ACID.
  • Valor 0: Millor rendiment, podem borrar fins a 1 segon de transaccions si mysql es cau.
  • Valor 2: Millor rendiment, en aquest cas nomes una perdua de corrent o un error en el sistema operatiu pot causar aquesta perdua de transaccions d'1 segon.
Alguns sistemes operatius i discs durs enganyen a l'hora de realitzar les operacions de FLUSH. Per tant la durabilitat de les transaccions no està garantida, ni amb 1 com a opció. Es convenient utilitzar catxés d'escritura a disc amb bateria. Açò aporta seguretat i velocitat a les transaccions.


mysql> show variables like '%innodb_flush_log_at_trx%'\G;
*************************** 1. row ***************************
Variable_name: innodb_flush_log_at_trx_commit
        Value: 1
1 row in set (0.00 sec)

mysql> set global innodb_flush_log_at_trx_commit=0;
Es pot agilitzar la velocitat a la que sincronitza un slave utilitzant aquest valor, però en el cas que es produeixca un error no podrem confiar en l'esclau i l'haurem de resincronitzar o comprobar d'alguna manera que les dues bases de dades son identiques.

Innodb_thread_concurrency:

Si tenim 1-2 CPU i una versió de MySQL posterior a 5.0.19, el millor es que configurem el valor a 0. Açò significa que el nombre de threads es il·limitat. Per a altres configuracions podem utilitzar aquesta formula 2*(NumCPUs+NumDisks), de forma que tinguem 2 threads per disc i per cpu.
Algunes voltes aquests valors no seran optims per tant millor sempre fer profiling per a veure quin impacte te en el rendiment qualscvol canvi en la configuració.


Innodb_flush_method:

Es  recomanable utilitzar O_Direct, així les transaccions es fan directament entre el MySQL i la controladora de disc sense passar per la catxe del Sistema Operatiu. Es important disposar un disc amb catxé d'escritura a disc amb bateria.

Cambiar el innodb_flush_method no es pot realitzar amb la base de dades funcionant, requereix reiniciar la màquina.

Innodb_file_per_table:

Si no tenim massa tables es recomanable configurar Innodb per a que cree un fitxer per taula. Així podem gestionar millor el tablespace.

Enllaços:


http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/
http://www.dbasquare.com/2012/04/10/what-is-the-proper-size-of-innodb-logs/
http://useranswer.com/answer/how-to-know-the-current-log-sequence-number-in-5-0-x/
http://www.mysqlab.net/knowledge/kb/detail/topic/innodb/id/6553
http://www.mysqlperformanceblog.com/2006/06/05/innodb-thread-concurrency/
http://www.dbasquare.com/kb/direct-io-in-innodb-o_direct/

dijous, 9 de maig de 2013

Resolving a DRBD Split-Brain

Per resoldre un Split-Brain en una base de dades amb Heartbeat + DRBD seguirem els següents passos.

Indentificar el problema:


Quan ocorrre un Split-Brain el sistema demana la intervenció humana per resoldre el problema. Apareix la següent entrada en el /var/log/messages i es marca l'estat de DRBD com a desconegut. La següent linea mostra l'entrada del log de sistema /var/log/messages.
Split-Brain detected, dropping connection!
Hi ha dos formes de consultar l'estat de DRBD. Una forma es utilitzant drbd-overview i l'altra es realitzar un cat del fitxer /proc/drbd.

El següent exemple mostra l'eixida d'aquestes dues comandes en la màquina que no ha detectat el split-brain.
root@home-1#drbd-overview
Mostra el següent:
  0:mysql  WFConnection Primary/Unknown UpToDate/DUnknown C r----- \ 
         /var/lib/mysql ext4 19G 2.5G 16G 14%
Si executem
root@home-1#cat /proc/drbd
Trobem el següent:
version: 8.3.11 (api:88/proto:86-96)
GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@home-1, \
    2013-05-09 12:33:07
 0: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r-----
    ns:0 nr:0 dw:113524 dr:3276073 al:33 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 \
    wo:b oos:352532

El estat de la primera màquina home-1 esta enumerat dalt. La segona màquina home-2 que ha identificat l'Split-Brain, quedaria com segueix:
root@home-2#cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
GIT-hash: 9ba8b93e24d842f0dd3fb1f9b90e8348ddb95829 build by root@home-2, \
    2013-05-09 10:09:38
 0: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/DUnknown   r---
    ns:0 nr:5405948 dw:150302972 dr:976818256 al:137 bm:751 lo:0 pe:0 \ 
    ua:0 ap:0 ep:1 wo:b oos:0
Si revisem ambdós maquines trobarem una màquina que apareix amb estat WFConnection i l'altra apareix amb l'estat StandAlone.

Resoldre el problema:


Per corregir el problema procedirem com següeix: Ens hem d'assegurar que el dimoni del heartbeat estiga parat en ambdós hosts. Després utilitzarem les següents comandes en la màquina amb estat StandAlone, en el nostre cas home-2:
root@home-2#drbdadm disconnect <resource>
root@home-2#debdadm secondary <resource>
root@home-2#drbdadm -- --discard-my-data connect <resource>
A l'altra màquina home-1 executarem:
root@home-1#drbdadm connect <resource>
Al fixer de configuració drbd.conf o dins del directory drbd.d trobarem el nom del <resource>,aquest s'especifica en el fitxer de configuració.

Amb aquestes comandes es sol·luciona el problema. Si realitzem ara un comprobació veurem que ja torna a funcionar:
root@home-1#cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@home-1, \
    2013-05-09 12:33:07
 0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
    ns:135180 nr:0 dw:3791924 dr:282584 al:8 bm:41 lo:0 pe:0 ua:0 ap:0 \
    ep:1 wo:b oos:0
 root@home-1#drbd-overview
  0: mysql  Connected Primary/Secondary UpToDate/UpToDate C r----- \ 
     /var/lib/mysql ext4 19G 2.5G 16G 14%
Una volta la base de dades estiga en l'estat correcte arranquem de nou  el heartbeat als 2 servidores.

Enllaços:


http://www.drbd.org/users-guide/s-resolve-split-brain.html
http://www.drbd.org/users-guide/ch-admin.html

dimarts, 7 de maig de 2013

Rooting Samsung Galaxy S2.

El primer que hem de determinar es quina versió de SO operatiu tenim i el model de HW del S2. A Europa normalment la versio mes corrent es la Internacional. En el meu cas era ICS 4.0.6. Per a les versions de ICS aquest fitxer fa el rooting: Root_SuperSU.0.96.Only-signed.zip.

Per seguretat realitzem el següent proces amb un 80% de bateria.
  • Instal·lem una tarjeta SD externa. 
  • Descarreguem aquest fitxer
  • Arranquem el telefon en Recovery Mode (volume up+home+power). 
  • Seleccionem "apply update from external storage".
  • Seleccionem "Root_SuperSU.0.96.Only-signed.zip" i ja tenim el telefon rootejat quan finalitza el procés.
Una volta arranquem el telefon de nou podem actualitzar SuperSu al android market i una volta instalada cliquem en la opció Reinstall en la pestanya de setttings de SuperSu i seguim les instruccions.

En cas que el SO siga Jelly Bean necessitarem la versió 0.98 de SuperSu.

Do it at your own risk. No hem faig responsable dels xafa papers que l'utilització d'aquest tutorial puga crear!

ENLLAÇOS:
http://someandroidinfo.blogspot.ca/search/label/Root
http://lifehacker.com/5886878/how-to-root-the-samsung-galaxy-s-ii
http://forum.xda-developers.com/showthread.php?p=28181736
http://forum.xda-developers.com/showthread.php?t=1826497
http://lkubuntu.wordpress.com/2012/10/26/how-to-root-an-android-device-under-ubuntu/

dimecres, 17 d’abril de 2013

Binary logs purge

Els binary logs contenen tota la informació referent a modificacions de la base de dades (Sentencies INSERT, UPDATE, DELETE). També s'utilitzen per a fer recuperar la base de dades en un punt concret  en el temps. Si disposem de un backup i els binary logs corresponents som capaços de recuperar la base de dades a un punt en concret.

Els binary logs van creixent en el temps, per tant es important tenir una politica de retenció de binary logs per a que no s'acumulen i acaben per esgotar l'espai del disc.

Per a eliminar tots els binary logs mes antics dels ultims 7 dies podem utilitzar una de les dues següents sentencies. Si volem utilitzar bash podem fer el següent:
echo "PURGE BINARY LOGS \ 
BEFORE '`date --date='7 days ago' +'%F %T'`';" | mysql
Si volem utilitzar la sentencia propia de MySQL, millor realitzar el següent:
mysql -uroot -e "PURGE BINARY LOGS \
BEFORE DATE_SUB( NOW( ), INTERVAL 7 DAY);"
També es possible eliminar tots els binary logs anteriors a una data concreta:
mysql PURGE MASTER LOGS BEFORE '2013-01-01 00:00:00';
A l'hora de definir una politica de retenció podem utilitzar el cron, pero no es la opció mes elegant ni correcta. La opció mes correcta i més neta passa per editar la configuració de mysql my.cnf i configurar el periode de retenció.
...
expire_logs_days = 7
...

ENLLAÇOS:
http://systems.takizo.com/2009/08/23/how-to-remove-mysql-binary-log/
http://dev.mysql.com/doc/refman/5.0/en/purge-binary-logs.html

divendres, 29 de març de 2013

Balancing a RHEL HA Cluster

L'objectiu d'aquesta entrada es donar les eines necessaries per a podre realitzar un balanceig d'un node a un altre en una arquitectura RHEL HA cluster. Per a poder assolir aquesta tasca, el primer que necessitarem serà poder obtenir informació detallada de l'estat del cluster.

Mostrar Informacio del Cluster:

Per revisar el status del cluster pots utilitzar:

# clustat
Cluster Status for TEST @ Thu Mar 28 09:21:04 2013
Member Status: Quorate

 Member Name                             ID   Status
 ------ ----                             ---- ------
 test1-cluster                               1 Online, Local, rgmanager
 test2-cluster                               2 Online, rgmanager

 Service Name                   Owner (Last)                   State
 ------- ----                   ----- ------                   -----
 service:Apache                 test1-cluster                 started

El Status que mostra la comanda correspon al següent:
  • Online: El node esta operatiu i el servei cman(cluster) esta funcionant i es accecible.
  • Local: Mostra el host, a dins del qual hem llançat la comanda clustat. Si llances la comanda des de l'altra màquina aquesta etiqueta apareixera en l'altre membre.
  • rgmanager: Mostra si el servei Resource Group Manager (rgmanager) esta funcionant en el node. Si aquesta etiqueta no es mostra en l'estat d'un node llavors aquest node no podra recibir un failover. 

La linia Member Status: Quorate ens mostra que el quorum ha estat assolit. Un cluster de dos nodes només necessita un sol node per a estar en el estat de Quorum.

També podem utilitzar la opció -l ens mostra l'ID del membre des del que l'estem
executant.
# clustat -l
Cluster Status for TEST @ Thu Mar 28 15:33:23 2013
Member Status: Quorate

 Member Name                               ID   Status
 ------ ----                               ---- ------
 test1-cluster                                 1 Online, Local, rgmanager
 test2-cluster                                 2 Online, rgmanager
 

Service Information
------- -----------

Service Name      : service:Apache
  Current State   : started (112)
  Flags           : none (0)
  Owner           : test1-cluster
  Last Owner      : test2-cluster
  Last Transition : Thu Mar 28 14:51:39 2013

La opcio -i actualitza la informació de la comanda cada X segons. La següent comanda realitzaria un refresc cada 10 segons.
# clustat -i 10 

Amb cman_tool status mostrem la percepcio local de l'estat del cluster.
# cman_tool  status
Version: 6.2.0
Config Version: 37
Cluster Name: Apache

Cluster Id: 50665
Cluster Member: Yes
Cluster Generation: 1196
Membership state: Cluster-Member
Nodes: 2
Expected votes: 3
Total votes: 3
Node votes: 1
Quorum: 2
Active subsystems: 10
Flags:
Ports Bound: 0 177 178
Node name: test1-cluster

Node ID: 1
Node addresses: 1.2.3.4

Balancejar el Cluster

Per a balancejar el cluster disposem de la comanda clusvadm
  • -d : Deshabilita un servei
  • -e : Habilita un servei
  • -r : Fa un failover del servei, balanceja el node.
Aquestes opcions s'utilitzarien de la següent forma:

#clusvadm -d Apache
#clusvadm -e Apache
#clusvadm -r Apache

cman_tool es un programa que gestiona el cluster management subsystem CMAN. cman_tool s'utilitza per a afegir/expulsar nodes del cluster per a matar un node o canviar el valor dels expected votes de un cluster.

Troubleshooting

Per a realitzar troubleshooting es interesant utilitzar el log /var/log/messages

Mar 28 14:38:42 test2-cluster rgmanager[2930]: Member 1 shutting down
Mar 28 14:39:04 test2-cluster qdiskd[2110]: Node 1 shutdown
Mar 28 14:39:04 test2-cluster corosync[2026]:   [QUORUM] 
    Members[1]: 2
Mar 28 14:39:04 test2-cluster corosync[2026]:   [TOTEM ] 
    A processor joined or left the membership and a new membership was 
    formed.
Mar 28 14:39:04 test2-cluster kernel: dlm: closing connection to node 1
Mar 28 14:39:04 test2-cluster corosync[2026]:   [CPG   ] 
    chosen downlist: sender r(0) ip(1.2.3.4) ; members(old:2 left:1)
Mar 28 14:39:04 test2-cluster corosync[2026]:   [MAIN  ] 
    Completed service synchronization, ready to provide service.
Mar 28 14:40:40 test2-cluster rgmanager[2930]: #43: Service 
    service:Apache has failed; can not start.
Mar 28 14:40:41 test2-cluster rgmanager[2930]: #13: Service 
    service:Apache failed to stop cleanly
Mar 28 14:42:13 test2-cluster corosync[2026]:   [TOTEM ] A 
    processor joined or left the membership and a new membership was 
    formed.
Mar 28 14:42:13 test2-cluster corosync[2026]:   [QUORUM]
    Members[2]: 1 2
Mar 28 14:42:13 test2-cluster corosync[2026]:   [QUORUM] 
    Members[2]: 1 2
Mar 28 14:42:13 test2-cluster corosync[2026]:   [CPG   ] 
    chosen downlist: sender r(0) ip(1.2.3.4) ; members(old:1 left:0)
Mar 28 14:42:13 test2-cluster corosync[2026]:   [MAIN  ]
    Completed service synchronization, ready to provide service.
Mar 28 14:42:29 test2-cluster kernel: dlm: got connection from 1
Mar 28 14:42:34 test2-cluster rgmanager[2930]: State change: 
    test1-cluster UP
Mar 28 14:46:34 test2-cluster rgmanager[2930]: Member 1 shutting down
Mar 28 14:46:55 test2-cluster qdiskd[2110]: Node 1 shutdown
Mar 28 14:46:56 test2-cluster corosync[2026]:   [QUORUM]
    Members[1]: 2
Mar 28 14:46:56 test2-cluster corosync[2026]:   [TOTEM ] 
    A processor joined or left the membership and a new membership 
    was formed.
Mar 28 14:46:56 test2-cluster kernel: dlm: closing connection to node 1
Mar 28 14:46:56 test2-cluster corosync[2026]:   [CPG   ] 
    chosen downlist: sender r(0) ip(1.2.3.4) ; members(old:2 left:1)
Mar 28 14:46:56 test2-cluster corosync[2026]:   [MAIN  ] 
    Completed service synchronization, ready to provide service.
Mar 28 14:50:08 test2-cluster corosync[2026]:   [TOTEM ] 
    A processor joined or left the membership and a new membership 
    was formed.
Mar 28 14:50:08 test2-cluster corosync[2026]:   [QUORUM] 
    Members[2]: 1 2 
Mar 28 14:50:08 test2-cluster corosync[2026]:   [QUORUM] 
    Members[2]: 1 2
Mar 28 14:50:08 test2-cluster corosync[2026]:   [CPG   ] 
    chosen downlist: sender r(0) ip(1.2.3.4) ; members(old:1 left:0)
Mar 28 14:50:08 test2-cluster corosync[2026]:   [MAIN  ]
    Completed service synchronization, ready to provide service.
Mar 28 14:50:26 test2-cluster kernel: dlm: got connection from 1
Mar 28 14:50:31 test2-cluster rgmanager[2930]: State change: 
    test1-cluster UP
Mar 28 15:13:51 test2-cluster ntpd[2544]: synchronized to 1.4.4.5, 
    stratum 4

Per a veure si la configuració del cluster (fitxer XML) es vàlida podem utilitzar la següent comanda.

# ccs_config_validate /etc/cluster/cluster.conf
Configuration validates

El fitxer de configuració principal d'un cluster es un fixer XML localitzat en /etc/cluster/cluster.conf. El servei esta definit entre els següents tags.

<rm>
    <service autostart="1" domain="" exclusive="0" name="" recovery="restart">
...
    </service>
</rm>

La configuració entre aquestes linies ajuda a  entendre com esta configurat el cluster.


Enllaços:

Cluster Suite Overview [PDF]
Adventures with two node RHEL HA Cluster
Cluster Administration

dimarts, 12 de febrer de 2013

Should I reboot after patching?

Quan planifiquem la actualització d'un sistema sempre tenim el dubte de si es estrictament necessari realitzar un reboot.

La resposta serà diferent depent dels paquets instal·lats. En alguns casos serà necessari reiniciar els servicis de la màquina i en altres casos serà necessari realitzar un reboot.

Com a primera aproximació podem utilitzar la utilitat lsoft. Amb aquesta comanda podem veure quines llibreries necessiten ser recarregades. Al final el resultat de la comanda ha de ser la cadena buïda. En cas contrari o el servei o la maquina ha de ser reiniciat.
lsof | grep deleted

En distribucions Debian o derivats, disposem de l'utilitat checkrestart, present a les debian-goodies Podem utilitzar el programa de la següent manera.
checkrestart -v
Per a distribucions Redhat i derivats disposem d'un plugin the yum, yum-plugin-ps:

Aquesta comanda llista tots els processos així com les actualitzacions associades.
yum ps all
Llista processos i mostra si tenen actualizacions els paquets.
yum ps updates
Llista els processos que han de ser reiniciats
yum ps restart


Links interessants al respecte:

http://it.toolbox.com/blogs/locutus/why-linux-can-be-updated-without-rebooting-12826
http://www.linuxplanet.com/tutorials/whats-so-great-about-debian-goodies.html
http://serverfault.com/questions/108446/equivalent-of-opensuse-zypper-ps-on-other-distros
http://gomix.fedora-ve.org/projects/fedobetatest/wiki/Yum-plugin-ps
http://kajuhome.com/yum_ps.shtml http://blog.pastoutafait.org/billets/Am%C3%A9liorer-la-s%C3%A9curit%C3%A9-avec-CheckRestart-sous-Debian-Ubuntu

dijous, 7 de febrer de 2013

VirtualBox on CLI

Virtualbox disposa d'una linia de comandes que permet la creació d'una màquina virtual directament per consola. Per a crear una màquina seguirem els següents passos.
Creem el directori on es guardaran tots els fitxer de la VM.

mkdir /home/user/VirtualBox\ VMs/VboxCLI

CREATE DISK
===========
Per a la creació d'un disc de 10Gb utilitzarem la següent ordre:

vboxmanage createhd --size 10000 --format vdi --filename /home/user/VirtualBox\ VMs/VboxCLI/VboxCLI-disk1.vdi
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Disk image created. UUID: b421697b-5f5d-4056-98c9-0cd0219b013a


SHOW OS TYPES
==============
Per a mostrar els tipus de sistemes operatius que tenim disponibles utilitzarem la següent ordre:

vboxmanage list ostypes

CREATE VM
==========
Per a la creacio d'una VM utilitzarem la següent ordre:

vboxmanage createvm --name VboxCLI --register --ostype Ubuntu_64
Virtual machine 'VboxCLI' is created and registered.
UUID: 5a89bddc-d7b0-4e08-b6cb-8e49dd7b2206
Settings file: '/home/user/VirtualBox VMs/VboxCLI/VboxCLI.vbox'


ATTACH SATA CONTROLLER
=======================
IMPORTANT!: Si volem instal·lar WindowsXP o alguna versió antiga de Linux que no tinga els drivers SATA millor instal·lar un controlador IDE a la màquina o no serem capaços d'arrancar la màquina amb aquesta configuració.
Una volta creada la màquina afegim un adaptar SATA.

vboxmanage storagectl VboxCLI --name "Sata Controller" --add sata --controller "IntelAHCI"

ATTACH HD
==========
Una volta tenim afegit el controlador SATA afegim un disc dur Sata al controlador

vboxmanage storageattach VboxCLI --storagectl "Sata Controller" --port 0 --device 0 --type hdd --medium VboxCLI-disk1.vdi

ADD MEMORY
===========
Definim la memòria que necessitem.

vboxmanage modifyvm VboxCLI --memory 1024

ADD NETWORK
============
Afegim un adaptador de xarxa i el configurem com a bridged, per a que la VM estiga en la mateixa xarxa que el host.

vboxmanage modifyvm VboxCLI --nic1 bridged --bridgeadapter1 eth0

ADD DVD AND LOAD AN ISO
========================
Afegim un dvd i una iso per poder iniciar la instal·lació.

vboxmanage storageattach VboxCLI --storagectl "Sata Controller" --port 1 --device 0 --type dvddrive --medium /home/user/Descargas/ubuntu-12.04.1-server-amd64.iso

VIEW SETTINGS
==============
Per a mostrar la configuració de la màquina que estem configurant podem utilitzar la següent comanda:

vboxmanage showvminfo VboxCLI
Name:            VboxCLI
Guest OS:        Ubuntu (64 bit)
UUID:            d37c6445-de02-4793-a9f4-06148103918f
Config file:     /home/user/VirtualBox VMs/VboxCLI/VboxCLI.vbox
Snapshot folder: /home/user/VirtualBox VMs/VboxCLI/Snapshots
Log folder:      /home/user/VirtualBox VMs/VboxCLI/Logs
Hardware UUID:   d37c6445-de02-4793-a9f4-06148103918f
Memory size:     1024MB
Page Fusion:     off
VRAM size:       8MB
CPU exec cap:    100%
HPET:            off
Chipset:         piix3
Firmware:        BIOS
Number of CPUs:  1
Synthetic Cpu:   off
CPUID overrides: None
Boot menu mode:  message and menu
Boot Device (1): Floppy
Boot Device (2): DVD
Boot Device (3): HardDisk
Boot Device (4): Not Assigned
ACPI:            on
IOAPIC:          on
PAE:             on
Time offset:     0 ms
RTC:             local time
Hardw. virt.ext: on
Hardw. virt.ext exclusive: on
Nested Paging:   on
Large Pages:     off
VT-x VPID:       on
State:           powered off (since 2013-02-05T13:21:05.000000000)
Monitor count:   1
3D Acceleration: off
2D Video Acceleration: off
Teleporter Enabled: off
Teleporter Port: 0
Teleporter Address:
Teleporter Password:
Storage Controller Name (0):            Sata Controller
Storage Controller Type (0):            IntelAhci
Storage Controller Instance Number (0): 0
Storage Controller Max Port Count (0):  30
Storage Controller Port Count (0):      30
Storage Controller Bootable (0):        on
Sata Controller (0, 0): /home/user/VirtualBox VMs/VboxCLI/VboxCLI-disk1.vdi (UUID: b421697b-5f5d-4056-98c9-0cd0219b013a)
Sata Controller (1, 0): /home/user/Descargas/ubuntu-12.04.1-server-amd64.iso (UUID: 36ff046c-69a8-4352-b604-356f177af2ab)
NIC 1:           MAC: 080027FD9D5A, Attachment: Bridged Interface 'eth0', Cable connected: on, Trace: off (file: none), Type: 82540EM, Reported speed: 0 Mbps, Boot priority: 0, Promisc Policy: deny
NIC 2:           disabled
NIC 3:           disabled
NIC 4:           disabled
NIC 5:           disabled
NIC 6:           disabled
NIC 7:           disabled
NIC 8:           disabled
Pointing Device: PS/2 Mouse
Keyboard Device: PS/2 Keyboard
UART 1:          disabled
UART 2:          disabled
Audio:           disabled
Clipboard Mode:  Bidirectional
VRDE:            disabled
USB:             disabled

USB Device Filters:

<none>

Available remote USB devices:

<none>

Currently Attached USB Devices:

<none>

Shared folders:  <none>

VRDE Connection:    not active
Clients so far:     0

Guest:

Configured memory balloon size:      0 MB
OS type:                             Ubuntu_64
Additions run level:                 0

Guest Facilities:

No active facilities.


CHANGE MEMORY SIZE
===================
Per a redimensionar la memòria RAM de la VM podem utilitzar:

vboxmanage modifyvm VboxCLI --memory 512

SETUP VRDE
===========
VRDE, permet connectar-nos a les VMs utilitzant el Remote Desktop de Virtualbox. L'última ordre habilita multiples connexions. Per a habilitar vrde realitzarem la següent configuració:

vboxmanage modifyvm VboxCLI --vrde on vboxmanage modifyvm VboxCLI --vrdeaddress localhost vboxmanage modifyvm VboxCLI --vrdeport 3001 vboxmanage modifyvm VboxCLI --vrdemulticon on

INSTALL EXT-PACK
================
La instal·lació del "extension pack" permet disposar de USB 2.0, Virtualbox RDP and PXE per a tarjetes Intel.

vboxmanage -v
4.1.18_Ubuntur78361

wget -c http://download.virtualbox.org/virtualbox/4.1.18/Oracle_VM_VirtualBox_Extension_Pack-4.1.18-78361.vbox-extpack

vboxmanage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.1.18-78361.vbox-extpack 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% Successfully installed "Oracle VM VirtualBox Extension Pack".


START VM HEADLESS
==================
Per a iniciar una màquina en background sense cap element visible en el foreground.

vboxmanage startvm VboxCLI --type headless
Waiting for VM "VboxCLI" to power on...
VM "VboxCLI" has been successfully started.


START VM HEADLESS (TROUBLESHOUTING)
===================================
El mateix que abans pero no et retorna el prompt. Útil per a troubleshouting.

VBoxHeadless -s VboxCLI -v on
Oracle VM VirtualBox Headless Interface 4.1.18_Ubuntu
(C) 2008-2012 Oracle Corporation
All rights reserved.

VRDE server is listening on port 3001.


CONNECT BY RDESKTOP TO THE MACHINE
===================================
Per a connectar a una màquina headless ens assegurem que estiga escoltant en el port i utilitzem rdesktop.

netstat -tanep
...
tcp 0 0 127.0.0.1:3001 0.0.0.0:* ESCUCHAR 1000 17286 -
...

rdesktop 127.0.0.1:3001


LIST VMs
=========
Mostrar les màquines que hi ha registrades.

vboxmanage list vms
"AddDiskWithoutReboot-LVM" {d7b517cd-4136-40d2-a94b-a81f08657b87}
"VboxCLI" {d37c6445-de02-4793-a9f4-06148103918f}


STOP VM
========


vboxmanage controlvm VboxCLI poweroff
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
LIST RUNNING VMs
=================
Mostrar les màquines estan en estat "Running".

vboxmanage list runningvms
"VboxCLI" {d37c6445-de02-4793-a9f4-06148103918f}


TAKE SNAPSHOT
==============
Per a la creació d'un snapshot utiltzarem:

vboxmanage snapshot VboxCLI take VboxCLI-snap01
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%


RESTORE SNAPSHOT
=================
Per a restaurar un snapshot utilitzarem:

vboxmanage snapshot VboxCLI restore VboxCLI-snap01
Restoring snapshot f5c0273d-ce47-426e-b4bd-f1f5c1c84d2c
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%


BIBLIOGRAPHY
=============
http://www.perkin.org.uk/posts/create-virtualbox-vm-from-the-command-line.html

http://itsecworks.wordpress.com/2012/04/24/virtualbox-the-tool-i-use-for-virtualization-of-course-with-cli/

divendres, 1 de febrer de 2013

Add a key for a Debian/Ubuntu repository

 Per a realitzar la instalació de un repositori nou i la seua clau en ubuntu/debian afegim les fonts en el sources.list i després hem d'afegir la clau.

 La clau es pot obtenir amb la següent comanda:

gpg --keyserver [name of keyserver] --recv-keys [keyhash] 
 
Una volta descarregada la clau la exportem i la afegim.
gpg --export --armor CE49EC21 | sudo apt-key add - 

Per exemple per a afegir la clau del repositori  seria:

gpg --keyserver subkeys.pgp.net --recv-keys 8842CE5E 


Aquesta es la eixida del programa.

gpg: /root/.gnupg: directorio creado
gpg: creado un nuevo archivo de configuración `/root/.gnupg/gpg.conf'
gpg: AVISO: las opciones en `/root/.gnupg/gpg.conf' no están aún \
 activas en esta ejecución
gpg: anillo «/root/.gnupg/secring.gpg» creado
gpg: anillo «/root/.gnupg/pubring.gpg» creado
gpg: solicitando clave 8842CE5E de hkp servidor subkeys.pgp.net
gpg: /root/.gnupg/trustdb.gpg: se ha creado base de datos de confianza
gpg: clave 8842CE5E: clave pública "Launchpad PPA for Bitcoin" importada
gpg: Cantidad total procesada: 1
gpg:               importadas: 1  (RSA: 1)

Despres afegirem la clau amb:

gpg --export --armor  8842CE5E | sudo apt-key add - 


Si tot funciona correctament rebrem un OK per part del programa.

dijous, 10 de gener de 2013

Apache reboots on Redhat and Debian

Cada volta que canviem la configuració d'Apache, hi ha que assegurar-se que la sintaxi del fitxer de configuració del servidor web és la correcta. Aquest es el pas previ a qualsevol altre.

En Redhat utilitzariem la següent comanda per comprobar la sintaxi:

/etc/init.d/httpd configtest

I en Debian:

apache2ctl configtest

Si tot funciona correctament recibirem el següent missatge:

Syntax OK

Una volta ens hem assegurat que la sintaxi del fitxer de configuració es correcta podem procedir a realitzar el reinici del proces. Existeixen dos formes de reiniciar el servei: restart i graceful.

Restart:

Si utilitzem la opció restart, s'envia una senyal SIGHUP a tots els processos d'Apache. Açò es tradueix en:
  • Sol·licitar la finalització dels procesos fill amb una senyal TERM, i la posterior finalització del process pare.
  • Es tornen llegir el fitxers de configuracio. 
  • S'obren els fitxer dels logs.
  • Es crea un nou process pare i els fills que depenen d'ell.
El servei queda interrumpit durant un xicotet espai de temps.

Per a realitzar aquest tipus de reinici utilitzarem la següent comanda en Redhat:

/etc/init.d/httpd restart

Amb Debian la comanda serà una d'aquestes dos:
/etc/init.d/apache2 restart
apachectl -k restart

Graceful:

Si utilitzem la opció graceful, s'envia una senyal SIGUSR1, d'aquesta manera el proces pare d'Apache permet que els fills acaben de servir la petició que estan processant i que finalitzen una volta estiga servida.
  • S'envia una senyal SIGUSR1
  • El proces pare indica als processos fills que finalitzen quan acaben de servir la petició en curs.
  • El proces pare torna a llegir els fitxers de configuracio i a obrir els logs.
  • El fills que finalitzen de servir les peticions es van substituint per nous fills creats per el pare.
El servei no s'interrumpeix
Per a realitzar aquest tipus de reinici utilitzarem la següent comanda en Redhat:

/etc/init.d/httpd restart

Amb Debian la comanda serà una d'aquestes dos:

/etc/init.d/apache2 reload  
apachectl -k graceful