dijous, 10 de març de 2016

Update BIOS on Lenovo X220

IMPORTANT: Ens assegurarem que el portàtil està conectat en tot moment a la corrent!!!.

Per a actualitzar la BIOS amb Lenovo necessitarem descarregar la iso de l'última versió que la trobarem ací.

A continuació ens descarreguem l'script geteltorito.pl del següent enllaç.

Una volta tenim ja totes les eines, convertim la iso descarregada en una imatge arrancable que anomenarem bios-update-x220.iso.
perl geteltorito.pl -o bios-update-x220.iso 8duj27us.iso 
Booting catalog starts at sector: 20 
Manufacturer of CD: NERO BURNING ROM
Image architecture: x86
Boot media type is: harddisk
El Torito image starts at sector 27 and has 63488 sector(s) of 512 Bytes

Image has been written to file "bios-update-x220.iso".
Una volta generada la imatge la copiem a un pendrive. En el nostre cas el pendriva ha sigut reconegut per el sistema com sdd.
dd if=bios-update-x220.iso of=/dev/sdd bs=512K
62+0 registros leídos
62+0 registros escritos
32505856 bytes (33 MB) copiados, 0,0655396 s, 496 MB/s
[root@localhost melkor]# sync
Reiniciem el portàtil. Presionem F12 per seleccionar l'arranc per USB. Després només hem de seguir les instruccions per pantalla.

Enllaços:

http://mattoncloud.org/2014/05/15/fedora-20-on-a-thinkpad-x1-carbon/
http://support.lenovo.com/gb/en/downloads/ds018807
https://workaround.org/article/updating-the-bios-on-lenovo-laptops-from-linux-using-a-usb-flash-stick/

dimecres, 9 de març de 2016

MySQL Slave out of sync: first log file name in binary log index file missing

Disposem de dues màquines amb MySQL configurades a una xarxa local, una està configurada com a master i l'altra com a slave. El slave presenta el següent problema:
MariaDB [(none)]> show slave status \G;
...
Last_IO_Error: Got fatal error 1236 from master when reading data 
               from binary log: 'Could not find first log file name 
               in binary log index file'
...
Si revisem la configuració del slave veurem que necessita el mysql-bin.000009 que deuria estar enmagatzemat en el master.
MariaDB [(none)]> show slave status \G;
...
Relay_Master_Log_File: mysql-bin.000009
...
Però en els binary logs enmagatzemats del master aquest fitxer no existeix.
ls /var/log/mysql
error.log error.log.2.gz   mysql-bin.000014  mysql-bin.index
error.log.1.gz mysql-bin.000013  mysql-bin.000015
Açò es deu que en el fitxer de configuració /etc/mysql/my.cnf hi ha configurada la següent entrada:
expire_logs_days        = 10
Açò provoca que si la màquina ha estat parada durant un temps, els binary logs s'han purgat i ara el slave no pot sincronitzar-se amb tota la informació del master.També es pot donar el cas que algú haja realitzat un purgat de binary logs accidentals en el master. L'única manera de recuperar tota la info del slave és: sincronitzar-lo des d'un altre slave o utilitzant un backup del master.

En en el nostre cas recuperarem la sincronització master-slave utilitzant un backup del master. El procediment es el següent (aquestes comandes s'han executat al master):
MariaDB [(none)]> reset master;
Query OK, 0 rows affected (0.38 sec)
MariaDB [(none)]> flush tables with read lock;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      312 |              | mysql            |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
Una volta hem reinicialitzat el binary logs del master realitzem un backup de la base de dades.
mysqldump -uroot -p --all-databases > restore_slave_failure.sql
Desbloquegem les taules,
MariaDB [(none)]> unlock tables;
Transferim el backup a la màquina slave.
scp restore_slave_failure.sql user@192.168.122.3:~/
user@192.168.122.3's password: 
A partir d'ací executem les comandes en el slave. El primer que farem serà restaurar el backup.
mysql -uroot -p < restore_slave_failure.sql 
Enter password: 
Parem el slave.
MariaDB [(none)]> stop slave;
Query OK, 0 rows affected (0.09 sec)
Reinicialitzem tots els valors del slave.
MariaDB [(none)]> reset slave;
Query OK, 0 rows affected (0.01 sec)
Configurem el slave per a que apunte a la posció actual del master.
MariaDB [(none)]> CHANGE MASTER TO 
                  MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=312;
Arranquem el slave de nou.
MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.09 sec)
Si comprobem l'estat del slave estarà ja funcionant de nou.
MariaDB [(none)]> show slave status\G;
...
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
...

Enllaços:

https://www.percona.com/blog/2014/10/08/mysql-replication-got-fatal-error-1236-causes-and-cures/
http://stackoverflow.com/questions/2366018/how-to-re-sync-the-mysql-db-if-master-and-slave-have-different-database-incase-o

dimarts, 1 de març de 2016

Two problems easily solved with lsof

Introducció:

Uns dels problemes per als que lsof es pot utilitzar es per a recuperar arxius oberts que accidentalment hem esborrat o per alliberar espai que s'està consumint per un fitxer que ja no existeix.

En aquest article explicarem ambdós casos.

Recuperació d'un fitxer:

Per a realitzar l'exemple, esborrarem un fitxer, en aquest cas /var/log/messages que està obert per el daemon rsyslog. Totes les comandes s'han executat com a usuari root.
cd /var/log/messages
rm messages 
rm: ¿borrar el fichero regular «messages»? (s/n) s
Si executem lsof i busquem els fitxers esborrats:
sudo /usr/sbin/lsof | grep deleted
Com podem veure hi ha diversos fitxers que estan oberts per processos i han estat esborrats del sistema.

Un fitxer en linux es un punter a un inode que conte la informació del fitxer (permisos, propietari i el punt del disc on esta enmagatzemada la informació). Quan esborrem el fitxer, esborrem el enllaç però no s'allibera l'inode fins que el procés que el té obert finalitza.
lsof |  grep deleted
firewalld  585         root    8u      REG        \
              253,1      4096   25240301 /tmp/ffipPHxxr (deleted)
gmain      585  979    root    8u      REG        \
              253,1      4096   25240301 /tmp/ffipPHxxr (deleted)
rsyslogd   588         root    3w      REG        \
              253,1    437311   17399895 /var/log/messages (deleted)
in:imjour  588  596    root    3w      REG        \
              253,1    437311   17399895 /var/log/messages (deleted)
rs:main    588  597    root    3w      REG        \
              253,1    437311   17399895 /var/log/messages (deleted)
tuned     1289         root    6u      REG        \
              253,1      4096   25240312 /tmp/ffikk0wCm (deleted)
gmain     1289 1447    root    6u      REG        \
              253,1      4096   25240312 /tmp/ffikk0wCm (deleted)
tuned     1289 1451    root    6u      REG        \
              253,1      4096   25240312 /tmp/ffikk0wCm (deleted)
tuned     1289 1452    root    6u      REG        \
              253,1      4096   25240312 /tmp/ffikk0wCm (deleted)
tuned     1289 1457    root    6u      REG        \
              253,1      4096   25240312 /tmp/ffikk0wCm (deleted)
La informació important ací son la 2a i la 4a columna. La segona columna identifica el PID del procés que el té obert i la 4a el descriptor de fitxer associat.

Si realitzem un ls del directori PID en el sistem /proc juntament amb el descriptor de fitxer veurem que està associat al fitxer.
ls  -la /proc/588/fd/3 
l-wx------. 1 root root 64 feb 26 11:41 \
            /proc/588/fd/3 -> /var/log/messages (deleted)
Només hem de copiar-lo per a recuperar el fitxer.
cp /proc/588/fd/3 /var/log/messages.removed
I ací el tenim de nou amb tot el seu contingut.
ls -la | grep messages
-rw-------.  1 root root 439012 feb 26 12:11 messages.removed

Alliberament d'espai:

El següent problema que sol·lucionarem es manifesta quan un fitxer que ha sigut esborrat pero el seu espai no s'allibera perquè el procés que te el descriptor obert no l'alliberà i per tant el fitxer segueix ocupant espai en disc.

Primer generarem les condicions de la proba. Començarem fent creixer un fitxer amb 1Gb o 2Gb de dades. Tornarem a crear el fitxer que hem esborrat al principi del article pero amb 1Gb de dades.
dd if=/dev/zero of=/var/log/messages bs=1024 count=1048576
Si comprobem l'espai utilitzat veurem que tenim ocupat un 40% d'espai a /.
df -h
S.ficheros              Tamaño Usados  Disp Uso% Montado en
/dev/mapper/centos-root   7,6G   3,1G  4,6G  40% /
devtmpfs                  487M      0  487M   0% /dev
tmpfs                     497M      0  497M   0% /dev/shm
tmpfs                     497M   6,7M  490M   2% /run
tmpfs                     497M      0  497M   0% /sys/fs/cgroup
/dev/vda1                 497M   148M  350M  30% /boot
tmpfs                     100M      0  100M   0% /run/user/0
tmpfs                     100M      0  100M   0% /run/user/1000
Com podem veure el fitxer messages ara ocupa 1Gb més o menys.
ls -lah |  grep messages
-rw-r--r--.  1 root root 1,1G feb 26 12:25 messages
Esborrem el fitxer per fer el test i si revisem lsof veiem que apareix el fitxer com a deleted.
rm messages
rm: ¿borrar el fichero regular «messages»? (s/n) s
lsof |  grep messages
rsyslogd  2706         root    4w      REG     \
              253,1 1073743866   16919887 /var/log/messages (deleted)
in:imjour 2706 2708    root    4w      REG     \
              253,1 1073743866   16919887 /var/log/messages (deleted)
rs:main   2706 2709    root    4w      REG     \
              253,1 1073743866   16919887 /var/log/messages (deleted)
Si revisem l'espai ocupat de nou veuerem que continua ocupant espai.
df -h
S.ficheros              Tamaño Usados  Disp Uso% Montado en
/dev/mapper/centos-root   7,6G   3,1G  4,6G  40% /
devtmpfs                  487M      0  487M   0% /dev
tmpfs                     497M      0  497M   0% /dev/shm
tmpfs                     497M   6,7M  490M   2% /run
tmpfs                     497M      0  497M   0% /sys/fs/cgroup
/dev/vda1                 497M   148M  350M  30% /boot
tmpfs                     100M      0  100M   0% /run/user/0
tmpfs                     100M      0  100M   0% /run/user/1000
Tenint en compte el PID del procés 2706 i el descriptor 4, accedim a ells via /proc.
cd /proc/2706/fd
ll | grep deleted
l-wx------. 1 root root 64 feb 26 12:25 4 -> /var/log/messages (deleted)
Si executem la següent comanda sobre el descriptor, l'espai s'alliberarà, d'aquesta manera no serà necessari reiniciar/matar el procés al que el descriptor de fitxer esta associat.
echo ''>4
Si comprovem l'espai utilitzat veurem que ara s'ha alliberat.
df -h
S.ficheros              Tamaño Usados  Disp Uso% Montado en
/dev/mapper/centos-root   7,6G   1,1G  6,6G  14% /
devtmpfs                  487M      0  487M   0% /dev
tmpfs                     497M      0  497M   0% /dev/shm
tmpfs                     497M   6,7M  490M   2% /run
tmpfs                     497M      0  497M   0% /sys/fs/cgroup
/dev/vda1                 497M   148M  350M  30% /boot
tmpfs                     100M      0  100M   0% /run/user/0
tmpfs                     100M      0  100M   0% /run/user/1000

Enllaços:

http://www.adamcrume.com/blog/archive/2011/06/30/viewing-deleted-but-open-files-on-linux
http://www.serverwatch.com/tutorials/article.php/3822816/Recovering-Deleted-Files-With-lsof.htm
http://neilr-linux.co.uk/?p=140