dimarts, 20 de setembre de 2016

Backup data on Android Phone

Per a realitzar un backup de tota la informació del mòbil podem utilitzar diferents aplicacions. El primer pas es utilizar el conte de google per fer un backup de:
  • Contactes
  • Calendari
  • Dades Aplicació
  • Wifi Passwords
  • Configuració del telèfon
Per configurar la sincronització de totes aquestes dades anirem a Settings -> Accounts --> Google -> account@gmail.com -> Sync Now També hem de configurar Settings -> Accounts -> Backup and reset i marcar les opcions Backup my data i Automatic Restore.

Per a tenir un backup de les fotos utilitzarem l'aplicació Photobucket. Utilitzarem les opcions "Autobackup" i "Wifi Only" en la configuració de l'App.

Per fer un backup dels SMS i els registres de les cridades, utilitzarem SMS Backup +. Seleccionarem la opció "Auto backup" també.

Enllaços:

http://www.ubergizmo.com/how-to/backup-android-phone-for-free/
http://www.wikihow.com/Sync-Google-Contacts-With-Android

dilluns, 19 de setembre de 2016

How to first configure AWS CLI

Introducció:

L'objectiu d'aquesta entrada es ensenyar a configurar AWS CLI.

Configuració:

Per a instal·lar AWS el primer es realitzar python 2.7, açò ho conseguirem en Ubuntu com segueix:
 
sudo apt-get install python2.7
Després ens descarreguem el següent script. Aquest script descarrega l'última versió de pip i altres dependencies com setuptools.
curl -O https://bootstrap.pypa.io/get-pip.py
Executem com a root el script que hem descarregat.
sudo python27 get-pip.py
Instal·lem el client de aws amb pip.
 sudo pip install awscli
Configurem el client amb l'usuari amb el que l'utilitzarem. No s'ha d'utilitzar l'usuari root.
aws configure
Es poden recollir totes les dades clicant sobre l'usuari, despres a "Security Credentials" i després a "Access Keys" en la web d'AWS. Configurem aquestes claus i marquem la regió que volem en el nostre cas es eu-west-1 (Irlanda). Hem de configurar també el tipus d'output.
aws  ec2 describe-instances --output table  --region eu-west-1
I ja tenim funcionant l'AWS cli.

Enllaços:

http://docs.aws.amazon.com/cli/latest/userguide/installing.html
http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html

divendres, 2 de setembre de 2016

Configure htpasswd on nginx

Introducció:

L'objectiu d'aquest tutorial es mostrar com s'instal·la un password en una pàgina web servida per nginx.

Configuració:

En primer lloc instal·lem les utilitats d'Apache2. La següent comanda mostra com fer-ho en sistemes debian o derivats.
 sudo apt-get install apache2-utils
Seguidament configurem un password per a un usuari.
htpasswd -c /etc/nginx/.htpasswd user
A continuació configurem els paràmetres auth_basic i auth_basic_user en el fitxer /etc/nginx/sites-available/your-site
 server {
  listen       portnumber;
  server_name  ip_address;
  location / {
      root   /var/www/mywebsite.com;
      index  index.html index.htm;
      auth_basic "Restricted";                    #For Basic Auth
      auth_basic_user_file /etc/nginx/.htpasswd;  #For Basic Auth
  }
}

Per últim reiniciem el servei.
/etc/init.d/nginx restart

Enllaços:

https://www.digitalocean.com/community/tutorials/how-to-set-up-http-authentication-with-nginx-on-ubuntu-12-10

divendres, 5 d’agost de 2016

Working with Git Locally

Introducció:

L'objectiu d'aquest tutorial és definir les bases per a l'ús local del sistema de control de versions Git. Els sistemes de control de versions són una eïna fonamental per a tenir control i traçavilitat sobre els canvis.

Jugant amb Git:

Durant aquesta secció anirem probant diferents comandes sobre un repositori Git per entendre les diferents funcionalitats útils quan treballem sobre un repositori local. Per començar a utilitzar Git el primer que haurem de configurar són dos paràmetres bàsics per poder realitzar i traçar els diferents canvis. Aquestos seràn el nom, l'email i l'editor.
git config --global user.name "Roberto Nebot" 
git config --global user.email "rnegoz [ad] mymail.com"
git config --global core.editor "vim" 
Per comprobar que hem configurat correctament el nom, l'email i l'editor de text utilitzàrem la següent comanda:
git config --list
user.name=Roberto Nebot
user.email=rnegoz (ad) mymail.com
core.editor=vim
Una volta configurada la informació de l'usuari generarem el nostre primer respositori i començarem a treballar amb ell
git init test
La primera tasca que realitzàrem serà generar un fitxer README i escriure el nostre primer commit afegint aquest fitxer al registre de canvis.
cd test
touch README
git add README 
git commit -m "Added an empty README file"
[master (root-commit) 6c9545e] Added an empty README file
 1 file changed, 1 insertion(+)
 create mode 100644 README
Existeix la possibilitat també d'utilitzar un repositori extern d'Internet, ja siga perquè volem contribuïr al projecte o treballar fer proves en local, etc. Per clonar un repositori remot utilitzarem la següent comanda:
git clone https://github.com/major/securekickstarts
Una volta tinguem un repositori creat o clonat des d'una font remota ja podem començar a treballar. El primer que provarem serà veure l'estat dels fitxers del projecte myfirstproject que hem creat abans. Per veure l'estat dels fitxers teclejarem:
git status
En la rama master
nothing to commit, working directory clean
Si editem el fitxer README i li afegim algunes dades quan tornem a realitzar un status, ens indica que el fitxer ha sigut modificat:
vi README
git status
En la rama master
Cambios no preparados para el commit:
  (use «git add ...» para actualizar lo que se confirmará)
  (use «git checkout -- ...» para descartar cambios en el directorio de 
   trabajo)

 modificado:    README

no hay cambios agregados al commit (use «git add» o «git commit -a»)

Com el fitxer ha sigut modificat i els canvis no han sigut inclosos, el marquem per a que s'afegisquen quan realitzem el següent commit:
git add README 
Si tornem a realitzar un status del directori de treball ens indica que el fitxer serà afegit en el proper commit.
git status
En la rama master
Cambios para hacer commit:
  (use «git reset HEAD ...» para sacar del stage)

 modificado:    README


Realitzem el commit.
git commit -m "This is my first change on README file."
[master e2985e1] This is my first change on this file.
 1 file changed, 1 insertion(+)


Ara crearem un fitxer .gitignore per a que Git ometa determinats fitxers del directori de treball. Podem utilitzar expresions regulars en la definició del fitxer.
vim .gitignore
cat .gitignore 
*.log
Es possible també obtenir una informació més resumida del estatus del fitxer amb la següent comanda, per obtenir-la afegim més dades al README:
vim README
git status -s
 M README
?? .gitignore
Seguidament utilitzarem la comanda diff per veure les diferències entre el fitxer del directori de treball i el que tenim guardat a l'últim commit.
diff --git a/README b/README
index 3d6526c..7d81acf 100644
--- a/README
+++ b/README
@@ -1 +1,2 @@
 This is my first change on this file.
+Some minor modifications on the file.
Si afegim el fitxer .gitignore a l'àrea de staging i realitzem el diff amb l'opció --staged veiem els canvis de staged respecte a l'últim commit.
git add .gitignore
git diff --staged
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..397b4a7
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+*.log
Per a esborrar un fitxer en Git hem de esborrar-lo de l'àrea d'staging per evitar que Git continue realitzant el control de versions. Això ho aconteseguim amb la següent comanda. Com es pot veure, com hi han canvis respecte a l'últim commit no ens deixa esborrar el fitxer a menys que específicament utilitzem l'opció -f.
git rm README 
error: the following file has local modifications:
    README
(use --cached to keep the file, or -f to force removal)
Realitzem el commit.
git add README 
git status
En la rama master
Cambios para hacer commit:
  (use «git reset HEAD ...» para sacar del stage)

 nuevo archivo: .gitignore
 modificado:    README


git commit -m "Adding .gitignore and some additions on README"
[master b2bdb6e] Adding .gitignore and some additions on README
 2 files changed, 2 insertions(+)
 create mode 100644 .gitignore
Si intentem esborrar el fitxer README ara ja ens deixarà.
git rm README 
rm 'README'
git status
En la rama master
Cambios para hacer commit:
  (use «git reset HEAD ...» para sacar del stage)

 borrado:       README


Un error amb el que ens podem trobar és la necessitat d'esborrar un fitxer afegit a staging per error, per exemple, un log que no hem afegit al .gitignore. Per esborrar elements de l'àrea d'staging utilitzàrem rm --cached. Al següent example ho podem veure:
touch file1
git add file1
git status
En la rama master
Cambios para hacer commit:
  (use «git reset HEAD ...» para sacar del stage)

 borrado:       README
 nuevo archivo: file1

git rm --cached file1
rm 'file1'

git status
En la rama master
Cambios para hacer commit:
  (use «git reset HEAD ...» para sacar del stage)

 borrado:       README

Archivos sin seguimiento:
  (use «git add ...» para incluir en lo que se ha de confirmar)

 file1

A més a més d'esborrar, ens pot aparèixer la necessitat de moure un fitxer o renombrar-lo. Git disposa de la comanda mv. En el següent exemple veurem el seu ús.
touch README
git add README 
git status
En la rama master
Cambios para hacer commit:
  (use «git reset HEAD ...» para sacar del stage)

 modificado:    README

Archivos sin seguimiento:
  (use «git add ...» para incluir en lo que se ha de confirmar)

 file1


git mv README README.md
git status
En la rama master
Cambios para hacer commit:
  (use «git reset HEAD ...» para sacar del stage)

 borrado:       README
 nuevo archivo: README.md

Archivos sin seguimiento:
  (use «git add ...» para incluir en lo que se ha de confirmar)

 file1

Arribats fins aquest punt, revisarem l'historial de commits del projecte. Per poder-ho fer hi ha que teclejar la següent comanda:
git log
commit b2bdb6e16581c5be9f66176145ba340f87eddfff
Author: Roberto Nebot 
Date:   Fri Aug 5 09:49:10 2016 +0200

    Adding .gitignore and some additions on README

commit 3e4b22e07cb6e5f1a4d01a9bccfcb09e251c74bf
Author: Roberto Nebot 
Date:   Thu Aug 4 18:28:41 2016 +0200

    This is my first change on README file.

commit 53d903731e17709feed4121b0c10215a4ff8da78
Author: Roberto Nebot 
Date:   Thu Aug 4 18:20:04 2016 +0200

    Added an empty README file

En aquest moment afegirem un commit amb els últims canvis. Introduïrem un error en un commit per a modificar-lo després. Per modificar un commit utilitzarem --amend. Aquesta comanda llançarà un editor de text amb l'editor definit a la variable core.editor de la configuració global de Git, per defecte es nano.
git commit -m "This commit will be amended"
[master b148abf] This commit will be amended
 2 files changed, 2 deletions(-)
 delete mode 100644 README
 create mode 100644 README.md
git commit --amend
git log
commit f21c572eef8c9164a280928f7f12fc91bccf19fd
Author: Roberto Nebot 
Date:   Fri Aug 5 10:17:46 2016 +0200

    An empty README.md file has been added

commit b2bdb6e16581c5be9f66176145ba340f87eddfff
Author: Roberto Nebot 
Date:   Fri Aug 5 09:49:10 2016 +0200

    Adding .gitignore and some additions on README

commit 3e4b22e07cb6e5f1a4d01a9bccfcb09e251c74bf
Author: Roberto Nebot 
Date:   Thu Aug 4 18:28:41 2016 +0200

    This is my first change on README file.

commit 53d903731e17709feed4121b0c10215a4ff8da78
Author: Roberto Nebot 
Date:   Thu Aug 4 18:20:04 2016 +0200

    Added an empty README file

Si necessitem de moure fitxer de l'àrea d'stagging a l'àrea de treball, per evitar incloure el fitxer al commit podem utilitzar la comanda git reset HEAD <file>.
git status
En la rama master
Archivos sin seguimiento:
  (use «git add ...» para incluir en lo que se ha de confirmar)

 file1

no se ha agregado nada al commit pero existen archivos sin seguimiento 
   (use «git add» para darle seguimiento)
git add file1 
git status
En la rama master
Cambios para hacer commit:
  (use «git reset HEAD ...» para sacar del stage)

 nuevo archivo: file1

git reset HEAD file1
git status
En la rama master
Archivos sin seguimiento:
  (use «git add ...» para incluir en lo que se ha de confirmar)

 file1

no se ha agregado nada al commit pero existen archivos sin seguimiento 
   (use «git add» para darle seguimiento)
A continuació, revertirem un fitxer que ha sigut modificat a l'estat del seu últim commit. El fitxer no ha d'estar en l'àrea d'staging, ha d'estar en el directori de treball.
git add file1
git commit -m "This is an empty file1"
[master 3158758] This is an empty file1
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file1
git status
En la rama master
nothing to commit, working directory clean
vi file1 
git status
En la rama master
Cambios no preparados para el commit:
  (use «git add ...» para actualizar lo que se confirmará)
  (use «git checkout -- ...» para descartar 
        cambios en el directorio de trabajo)

 modificado:    file1

no hay cambios agregados al commit (use «git add» o «git commit -a»)
cat file1 
This is my first line in this file.
git checkout -- file1
cat file1
Per últim la següent comanda mostra els fitxers que tenim a Git.
git ls-tree -r master 
100644 blob 397b4a7624e35fa60563a9c03b1213d93f7b6546 .gitignore
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 README.md
100644 blob ca944af541d42052824a268ed72e97e3b8537b3c file1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 file2

Enllaços:

http://wildlyinaccurate.com/a-hackers-guide-to-git
http://askubuntu.com/questions/206449/git-config-global-file-remove-settings
https://try.github.io/levels/1/challenges/1

dimarts, 26 de juliol de 2016

SSH Keep Alive

Últimament quan hem conecte a màquines AWS per SSH la terminal es queda bloquejada. Per sol·lucionar aquest problema configurem en /etc/ssh/ssh_config la següent directiva.
ServerAliveInterval 60

dimecres, 20 de juliol de 2016

Showing and Listing Databases and Tables in PostgresSQL

Introducció:

Aquest tutorial busca donar unes xicotetes nocions per començar a gestionar un postgres tenint uns coneixements molts bàsics sobre bases de dades.

Utilització bàsica de Postgres:

El primer que necessitarem serà accedir a la consola d'administració postgres. Per a accedir a la consola psql ens canviarem a usuari postgres i llançarem la comanda psql.
sudo su postgres
psql
could not change directory to "/root"
psql (9.1.22)
Type "help" for help.

Una volta executem la consola mostrarem les bases de dades que hi han configurades. La comanda \x serveix per canviar el pager per a que mostre les files de la bases de dades en vertical. El que ens resultarà útil depenent de la consola amb la que accedim.

Per mostrar les bases de dades utilitzarem la ordre \l.
postgres=# \x
postgres=# \l
List of databases
-[ RECORD 1 ]-----+----------------------
Name              | postgres
Owner             | postgres
Encoding          | UTF8
Collate           | en_US.UTF-8
Ctype             | en_US.UTF-8
Access privileges | 
-[ RECORD 2 ]-----+----------------------
Name              | template0
Owner             | postgres
Encoding          | UTF8
Collate           | en_US.UTF-8
Ctype             | en_US.UTF-8
Access privileges | =c/postgres
                  | postgres=CTc/postgres
-[ RECORD 3 ]-----+----------------------
Name              | template1
Owner             | postgres
Encoding          | UTF8
Collate           | en_US.UTF-8
Ctype             | en_US.UTF-8
Access privileges | =c/postgres
                  | postgres=CTc/postgres
El següent que farem serà crear una base de dades de proba anomenada test.
postgres=# create database test;
CREATE DATABASE
A continuació comprobarem que la base de dades s'ha creat correctament.
postgres=#  \l
List of databases
-[ RECORD 1 ]-----+----------------------
Name              | postgres
Owner             | postgres
Encoding          | UTF8
Collate           | en_US.UTF-8
Ctype             | en_US.UTF-8
Access privileges | 
-[ RECORD 2 ]-----+----------------------
Name              | template0
Owner             | postgres
Encoding          | UTF8
Collate           | en_US.UTF-8
Ctype             | en_US.UTF-8
Access privileges | =c/postgres
                  | postgres=CTc/postgres
-[ RECORD 3 ]-----+----------------------
Name              | template1
Owner             | postgres
Encoding          | UTF8
Collate           | en_US.UTF-8
Ctype             | en_US.UTF-8
Access privileges | =c/postgres
                  | postgres=CTc/postgres
-[ RECORD 4 ]-----+----------------------
Name              | test
Owner             | postgres
Encoding          | UTF8
Collate           | en_US.UTF-8
Ctype             | en_US.UTF-8
Access privileges | 
Com podem veure en el RECORD 4 s'ha creat correctament. Seguidament ens conectem a la base de dades amb \c.
postgres=# \c test;
You are now connected to database "test" as user "postgres".
Una volta accedim a la base de dades test, creem una taula t1 amb 2 camps, un identificador id i una cadena name.
CREATE TABLE t1 (id INTEGER PRIMARY KEY, name VARCHAR);
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "t1_pkey" \
         for table "t1"
CREATE TABLE
A continuació, mostrem les taules creades amb \dt. Veurem que s'ha creat correctament la taula.
test=# \dt
List of relations
-[ RECORD 1 ]----
Schema | public
Name   | t1
Type   | table
Owner  | postgres
Insertem dades a la taula t1 creada previament.
test=# insert into t1 (id, name) values (1, 'Cremem la nit!');
INSERT 0 1
Si realitzem una consulta veurem que les dades apareixen correctament.
test=# select * from t1;
-[ RECORD 1 ]------------------------------------
id          | 1
name        | Cremem la nit!
Una altra cosa que podem comprobar son els usuaris que hi han donats d'alta a postgres. Això ho comprobem amb la següent comanda:
test=# select * from pg_shadow;
-[ RECORD 1 ]------------------------------------
usename     | postgres
usesysid    | 10
usecreatedb | t
usesuper    | t
usecatupd   | t
userepl     | t
passwd      | 
valuntil    | 
useconfig   | 
Per últim modifiquem el pager al comportament normal.
postgres=#\x off
Aquesta comanda s'utilitza per eixir de la base de dades.
postgres=# \q

Enllaços:

https://chartio.com/resources/tutorials/how-to-list-databases-and-tables-in-postgresql-using-psql
http://www.davidpashley.com/articles/postgresql-user-administration/

divendres, 13 de maig de 2016

Installing TWRP into a Rooted Phone

Introducció:

Quan comprem un telèfon per a poder començar a tenir llibertat amb el seu ús el primer que hem de d'aconseguir es rootejar-lo. Una volta tenim el telèfon rootejat podrem modificar l'utilitat de recuperació instal·lada per defecte. Aquesta facilitarà instal·lar diferents ROMs així com reparar el software del telèfon en cas de problemes.

Existeixen diferents tipus d'utilitats de recuperació com TWRP i Clockworkmod. En el nostre cas ens centrarem amb TWRP.

Procés:

Per a poder seguir el procés que es descriu en aquest tutorial necessitem tenir permisos de root sobre el telefon. Per rootejar un telefon Samsung Galaxy S3 com el que s'ha utilitzat per a la realització d'aquest tutorial podeu seguir el següent enllaç.

La utilitat recuperació que utilitzarem s'anomena TWRP (Team Win Recovery Project). La forma més senzilla d'instalar-la es descarregar de Google Play l'aplicació Flashify.
  1. Cliquem la icona de Flashify
  2. Seleccionem Flash -> Recovery Image -> TWRP -> twrp-3.0.2-0-i9300.img
  3. Cliquem en la Image Descarrega
  4. Cliquem Yup!
  5. Reiniciem
Una volta instal·lat si presionem "Volume up + Home + Power button" al encendre el dispositu podrem accedir a TWRP.

Enllaços:

https://twrp.me/ http://www.techverse.net/how-to-install-clockworkmod-recovery-android-phone-tablet-easy-method/
https://wiki.cyanogenmod.org/w/All_About_Recovery_Images

dijous, 21 d’abril de 2016

Rooting Samsung Galaxy S3

Aquesta guia funciona per "rootejar" un Samsung Galaxy S3 GT-I9300 amb la versió d'Android Jelly Bean. El telèfon ha de ser lliure. Aquest tutorial s'ha realitzat utilitzant un sistema operatiu Windows 7 de 64 bits.

Per seguretat realitzem el següent proces amb un 80% de bateria.
  • Activem el debugging mode, Settings -> About Phone, en la secció Build Number, cliquem 7 voltes sobre "Build Number" i el sistema ens avisarà que ja som developers.
  • Fes un backup de la informació important del telèfon.
  • Assegurar-se que el dispositiu es el model Samsung Galaxy S3 GT-I9300, si no es possible que "briquegem" el telèfon.
  • Descarreguem el següent fitxer.
  • Descomprimim el fitxer.
  • Descarreguem l'última versió d'Odin.
  • Arranquem el Samsung Galaxy S3 en Download Mode amb "Volume down + home + Power".
  • Cliquem en AP en Odin i seleccionem el fitxer CF-Auto-Root-m0-m0xx-gti9300.tar.md5, ens assegurem que les opcions Auto-Reboot i F.Reset Time estan seleccionades. Fem clic en Start.
Si tot funciona correctament, quan el dispositiu s'acabe de reiniciar realitzarà diversos canvis i ens apareixerà l'aplicació SuperSU, que s'utilitza per elevar privilegis.

He intentat realitzar el mateix procés amb linux i l'última versió de Heimdall però, no ha sigut possible per que no reconeix el dispositiu.

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

Enllaços:

http://www.ibtimes.co.uk/galaxys3-i9300-root-android43-jellybean-update-howto-521949
https://download.chainfire.eu/229/CF-Root/CF-Auto-Root/CF-Auto-Root-m0-m0xx-gti9300.zip
http://www.ninjaromeo.com/enable-usb-debugging-developer-options-jelly-bean/
https://github.com/Benjamin-Dobell/Heimdall/issues/209

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

dijous, 25 de febrer de 2016

Telnet ESC character Macbook keyboard

Quan utilitzes una sessió telnet sempre existeix un caracter d'escapada. Aquest caracter és el que fa que aparega el prompt telnet>:
telnet 192.168.122.196 22
Trying 192.168.122.196...
Connected to 192.168.122.196.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.6.1
^]
telnet> quit
Connection closed.
En els PCs aconseguim açò amb Ctrl-+. Aquesta combinació no funciona amb els Mac, per a realitzar el mateix amb un Mac hem d'utlitzar Ctrl-5 que generarà el caracter ^].

DISCLAIMER!!: Aquesta prova s'ha realitzat amb un Macbook amb Linux, no amb el MacOS X, no se si en aquest cas funcionarà.

dilluns, 22 de febrer de 2016

Postfix Relay Domains

Per defecte postfix funciona com a relay per als dominis configurats a la directiva relay_domains al fitxer main.cf al directori /etc/postfix/.

La directiva relay_domains està buida (Postfix 3.0 o superior) o conté el valor de la variable $mydestination (Postfix anteriors a 3.0). Ací teniu un exemple:
...
relay_domains = $mydestination
...
mydestination = $myhostname, localhost.$mydomain, localhost
...
Si afegim dominis separats per comes a la variable relay_domains aquest host podrà utilitzar el servidor de correu com a relay. També es important la directiva smtpd_client_restrictions, aquesta directiva restringeix les conexions dels clients basant-se en el RCPT TO especificat per el client.

Quan afegim els dominis a la directiva relay_domains només reiniciant el daemon de postfix és suficient per reflexar els canvis de la configuració.
/etc/init.d/postfix reload
L'altra opció que tenim es utilitzar una base de dades per configurar els dominis amb relay autoritzat. Per a configurar aquesta opció haurem d'instal·lar la base de dades de Berkeley. Després configurarem els relay_domains amb un fitxer que definim així.
 
...
relay_domains = hash:/etc/postfix/relay_domains
...
El fitxer /etc/postfix/relay_domains contindra els dominis autoritzats a relay.
domain1 OK
domain2 OK
domain3 OK
Si volem afegir un nou domini haurem d'editar el fitxer i regenerar la base de dades amb:
postmap /etc/postfix/relay_domains
Una volta regenerada la base de dades, reiniciem el daemon per a que carregue la nova configuració.
/etc/init.d/postfix reload

Enllaços:

https://kiranjith.wordpress.com/2010/03/02/7-postfix-relay-domains/
http://www.postfix.org/postconf.5.html#relay_domains

dilluns, 11 de gener de 2016

Apache virtual host configuration on Centos 7.2

Introducció:

L'objectiu d'aquest article és configurar un Apache amb suport per a virtual hosts amb una distribució CentOS 7.2. Per a la realització d'aquesta tasca utilitzarem KVM com a hipervisor i una màquina virtual.

Configuració bàsica

Instal·lem una CentOS 7.2 i l'actualitzem. Una volta actualitzada la distribució procedim a configurar la xarxa amb una IP. En el nostre cas la IP assignada serà 192.168.122.4. Per configurar la xarxa editem el fitxer /etc/sysconfig/networking-scripts/ifcfg-eth0 amb la següent configuració:
HWADDR=52:54:00:44:9B:40
TYPE=Ethernet
BOOTPROTO=none
IPADDR=192.168.122.4
NETMASK=255.255.255.0
USERCTL=no
NAME=eth0
UUID=b166b9bb-a7a3-4d6e-8a76-0c9dfa2d9be7
ONBOOT=yes
Una volta assignada una IP a la xarxa, configurem també la porta d'enllaç per a que la màquina virtual tinga eixida a Internet. Editem el fitxer /etc/sysconfig/network com següeix:
# Created by anaconda
NETWORKING=yes
HOSTNAME="apache-c7"
GATEWAY=192.168.122.1
Afegim també un DNS per a que puga realitzar la resolució de noms a /etc/resolv.conf.
...
nameserver 192.168.122.1
Una volta tenim configurada la xarxa, el DNS bàsic i la màquina es capaç de fer ping a altres màquines dins la seua xarxa privada procedirem a la instal·lació i configuració del servidor web.

Configuració d'Apache:

El primer que farem serà instal·lar Apache. Per a instal·lar Apache a una distribució CentOS teclegem la següent comanda:
yum install httpd
Una volta tenim Apache instal·lat habilitem en el firewall el port 80 per a que el servidor puga rebre peticions.
firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --reload
Seguidament configurem el servidor per a que s'arranque automàticament al iniciar la màquina.
systemctl enable httpd
I arranquem el servidor.
systemctl start httpd
A partir d'ací utilitzarem una forma de configurar els virtual hosts un poc diferent a l'habitual. En primer lloc crearem l'estructura de directoris que utilitzarem per desplegar les pàgines web. Crearem un directori amb el nom del domini i despres crearem dos directoris www i log per enmagatzemar les pàgines i els logs respectivament.
sudo mkdir -p /var/www/proba.com/www
sudo mkdir -p /var/www/proba2.com/www

sudo mkdir -p /var/www/proba.com/log
sudo mkdir -p /var/www/proba2.com/log
Creem el següent fitxer a /var/www/proba.com/www/index.html amb el següent codi:
<html>
 <head>
    <title>Proba.com</title>
  </head>
  <body>
    <h1>Proba.com funciona!</h1>
  </body>
</html>
Repetim el proces per al segon host. Creem el següent fitxer a /var/www/proba2.com/www/index.html amb el següent codi:
<html>
 <head>
    <title>Proba2.com</title>
  </head>
  <body>
    <h1>Proba2.com funciona!</h1>
  </body>
</html>

Aquest fitxers els configurarem amb permisos 644. Crearem també dos directoris en el directori de configuració de l'Apache per gestionar més facilment el diferents virtual hosts que anirem configurant.
sudo mkdir -p /etc/httpd/sites-available
sudo mkdir -p /etc/httpd/sites-enabled
Afegim la següent linia al final del fitxer /etc/httpd/conf/httpd.conf per a afegir una nova ubicació per als fitxers del virtual host.
IncludeOptional sites-enabled/*.conf
Configurem el primer domini proba.com. Editarem el següent fitxer:
vi /etc/httpd/sites-available/proba.com.conf
Amb les següents opcions:

    ServerName www.proba.com
    ServerAlias proba.com
    DocumentRoot /var/www/proba.com/www
    ErrorLog /var/www/proba.com/log/error.log
    CustomLog /var/www/proba.com/log/requests.log combined

Repetim el procés per al segon domini:
vi /etc/httpd/sites-available/proba2.com.conf
Amb les següents opcions:

    ServerName www.proba2.com
    ServerAlias proba2.com
    DocumentRoot /var/www/proba2.com/www
    ErrorLog /var/www/proba2.com/log/error.log
    CustomLog /var/www/proba2.com/log/requests.log combined

Per activar els diferents virtual hosts crearem un soft link al directori que el fitxer de configuració utilitza.
sudo ln -s /etc/httpd/sites-available/proba.com.conf \ 
     /etc/httpd/sites-enabled/proba.com.conf
sudo ln -s /etc/httpd/sites-available/proba2.com.conf \ 
     /etc/httpd/sites-enabled/proba2.com.conf
I reiniciarem Apache per a que recarregue la configuració.
systemctl stop httpd
systemctl start httpd
Configurem la resolució de noms localment en la màquina desde la que realitzem la petició de la pàgina. Si la màquina que utilitzem per realitzar la petició es un linux, com es el nostre cas, afegirem al fitxer /etc/hosts les dues entrades referents a proba i proba2.
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.122.4   apache-c7
192.168.122.4   www.proba.com
192.168.122.4   www.proba2.com
Al realitzar la proba el servidor web donava un error de permisos en el fitxer /var/log/httpd/error_log, pero si comprovavem els permisos aquestos semblaven correctes. Comprovem que no siga un problema relacionat amb SElinux.
...
[Tue Dec 22 06:16:33.069393 2015] [mpm_prefork:notice] 
[pid 1142] AH00170: caught SIGWINCH, shutting down gracefully
(13)Permission denied: AH00091: httpd: could not open error log 
file /var/www/proba2.com/log/error.log.
AH00015: Unable to open logs
(13)Permission denied: AH00091: httpd: could not open error log 
file /var/www/proba2.com/log/error.log.
AH00015: Unable to open logs
(13)Permission denied: AH00091: httpd: could not open error log 
file /var/www/proba2.com/log/error.log.
AH00015: Unable to open logs
(13)Permission denied: AH00091: httpd: could not open error log 
file /var/www/proba2.com/log/error.log.
AH00015: Unable to open logs
...
Per facilitar-nos la tasca instal·lem el paquet setroubleshoot que ens ajuda a identificar els problemes relacionats amb SElinux.
yum install setroubleshoot
Executem la següent comanda sobre el log de SElinux per veure possibles problemes i ens mostra que efectivament SElinux esta bloquejant l'accés.
sealert -a /var/log/audit/audit.log 
La següent comanda sol·lucionarà el problema.
chcon -R -t httpd_sys_rw_content_t log/

Enllaços:

https://www.digitalocean.com/community/tutorials/how-to-set-up-apache-virtual-hosts-on-centos-7
https://wiki.centos.org/es/HowTos/SELinux