Configurar replicacion de archivos en RHEL/CentOS/SL 6/7 con lsyncd y csync2

csync2

Configurar replicacion de archivos en RHEL/CentOS/SL 6/7 con lsyncd y csync2

Introduccion

En caso de que necesitemos sincronizar en tiempo cercano al real directorios entre 2 o mas servidores podemos utilizar las herramientas lsync y csync2
csync2 es el encargado de la sincronizacion o copia como tal
lsync se encarga de detectar cualquier cambio en los directorios y de notificar a csync2 para que este los sincronice
En este documento veremos como instalar y configurar estas 2 herramientas para sincronizar entre 3 nodos el directorio /home y /web

Instalacion de los paquetes necesarios

RHEL/CentOS/SL 6

Para instalar lsyncd y csync2 en CentOS/RHEL 6 solo es necesario el repositorio EPEL y se instala directo vía yum como se detalla abajo.
Configurar el repositorio EPEL

rpm -Uhv https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm

Instalar los paquetes necesarios

yum install csync2 lsyncd xinetd

RHEL/CentOS/SL 7

Para versiones de RHEL 7 es necesario descargar la versión de csync2 que es para Fedora22, la misma se puede descargar desde la siguiente URL http://rpm.pbone.net/index.php3/stat/3/limit/1/srodzaj/1/dl/40/search/csync2/field%5B%5D/1/field%5B%5D/2
Una vez que descargamos instalamos con el comando:

yum install ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/releases/22/Everything/x86_64/os/Packages/c/csync2-1.34-15.fc22.x86_64.rpm

Configurar el repositorio EPEL

rpm -Uhv https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

Instalar los paquetes necesarios

yum install csync2 lsyncd xinetd

Los pasos anteriores son los únicos que difieren en cuanto a la versión 7 de la versión 6, una vez instalado los pasos son los mismos en ambas versiones

Configurar csync2

Habilitar el servicio csync2 bajo xinetd:

Para habilitar el servicio csync2 a traves de xinetd

sed -i.bak 's#yes#no#g' /etc/xinetd.d/csync2

Luego levantamos el servicio xinetd

service xinetd start

Generar los .key para la autenticacion entre los servidores

Para la autenticacion entre los servidores es necesario crear un archivo .key, el mismo lo podemos crear con el comando csync2 y la opcion -k:

csync2 -k /etc/csync2/csync2.key

Configurar alias y directorios

Podemos crear varias configuraciones de csync2 que se encarguen de sincronizar 1 o mas directorios, en el siguiente ejemplo crearemos un alias home que se encarga de sincronizar el /home y otro que sincronizara el /web de nombre web
Para configurar csync2 debemos crear el archivo /etc/csync2/csync2_<alias>.cfg, cargando lo siguiente:

vim /etc/csync2/csync2_home.cfg

nossl * *;
group web
{
        host node1;
        host node2;
        host node3;
        key /etc/csync2/csync2.key;
        include /home/;
        exclude *.log;
        auto younger;
}

vim /etc/csync2/csync2_web.cfg

nossl * *;
group web
{
        host node1;
        host node2;
        host node3;
        key /etc/csync2/csync2.key;
        include /web/;
        auto younger;
}

Se debe tener en cuenta que el nombre de host (en este caso node1) debe ser el hostname o fqdn de cada servidor

Copiar los archivos del csync a los otros nodos:

Copiamos a los demas nodos:

scp /etc/csync2/* node2:/etc/csync2

scp /etc/csync2/* node3:/etc/csync3

Iniciar la replicacion de csync2

Para la sincronizacion inicial es necesario correr el siguiente comando por cada alias

csyncs2 -xXrvB -C <alias>

Ej:

csyncs2 -xXrvB -C home

Configurar lsyncd

Crear archivos de configuracion

Se deben agregar las siguientes lineas al archivo /etc/lsyncd.conf

vim /etc/lsyncd.conf

settings {
        logident        = "lsyncd",
        logfacility     = "user",
        logfile         = "/var/log/lsyncd.log",
        statusFile      = "/var/log/lsyncd_status.log",
        statusInterval  = 1
}

initSync = {
        delay = 1,
        maxProcesses = 1,
        action = function(inlet)
                local config = inlet.getConfig()
                local elist = inlet.getEvents(function(event)
                        return event.etype ~= "Init"
                end)
                local directory = string.sub(config.source, 1, -2)
                local paths = elist.getPaths(function(etype, path)
                        return "\t" .. config.syncid .. ":" .. directory .. path
                end)
                log("Normal", "Processing syncing list:\n", table.concat(paths, "\n"))
                spawn(elist, "/usr/sbin/csync2.sh", "-C", config.syncid, "-x")
        end,
        collect = function(agent, exitcode)
                local config = agent.config
                if not agent.isList and agent.etype == "Init" then
                        if exitcode == 0 then
                                log("Normal", "Startup of '", config.syncid, "' instance finished.")
                        elseif config.exitcodes and config.exitcodes[exitcode] == "again" then
                                log("Normal", "Retrying startup of '", config.syncid, "' instance.")
                                return "again"
                        else
                                log("Error", "Failure on startup of '", config.syncid, "' instance.")
                                terminate(-1)
                        end
                        return
                end

                local rc = config.exitcodes and config.exitcodes[exitcode]
                if rc == "die" then
                        return rc
                end
                if agent.isList then
                        if rc == "again" then
                                log("Normal", "Retrying events list on exitcode = ", exitcode)
                        else
                                log("Normal", "Finished events list = ", exitcode)
                        end
                else
                        if rc == "again" then
                                log("Normal", "Retrying ", agent.etype, " on ", agent.sourcePath, " = ", exitcode)
                        else
                                log("Normal", "Finished ", agent.etype, " on ", agent.sourcePath, " = ", exitcode)
                        end
                end
                return rc
        end,

        init = function(event)
                local inlet = event.inlet;
                local config = inlet.getConfig();
                log("Normal", "Recursive startup sync: ", config.syncid, ":", config.source)
                spawn(event, "/usr/sbin/csync2.sh", "-C", config.syncid, "-xXrvvB")
        end,

        prepare = function(config)
                if not config.syncid then
                        error("Missing 'syncid' parameter.", 4)
                end
                local c = "csync2_" .. config.syncid .. ".cfg"
                local f, err = io.open("/etc/csync2/" .. c, "r")
                if not f then
                        error("Invalid 'syncid' parameter: " .. err, 4)
                end
                f:close()
        end
}

local sources = {
        ["/home"] = "home",
        ["/web"] = "web"
}

for key, value in pairs(sources) do
        sync {initSync, source=key, syncid=value}
end

No olvidar cambiar el “home” por el alias que le asignara a cada directorio, este alias debe tener su configuracion correspondiente en la siguiente ruta:

/etc/csync2/csync2_<alias>.cfg

Ej:

/etc/csync2/csync2_home.cfg

Agregar la ruta del archivo de configuracion de lsync

Debemos agregar la ruta del archivo creado en el paso previo en el archivo /etc/sysconfig/lsyncd, eso lo podemos hacer con el comando sed:

sed -i.bak 's#^LSYNCD_OPTIONS=.*#LSYNCD_OPTIONS=" /etc/lsyncd.conf"#g' /etc/sysconfig/lsyncd

Crear el Script que ejecutara el lsync

Para sincronizar las carpetas el lsync intentara ejecutar el script /usr/sbin/csync2.sh, el cual debemos crear:

cat <<EOF > /usr/sbin/csync2.sh
#!/bin/bash

/usr/sbin/csync2 $@

exit 0

## Se agrega el exit 0 para que no se detenga el lsyncd al dar un error
EOF

Dar permisos de ejecución al Script

chmod 755 /usr/sbin/csync2.sh

Habilitar e Iniciar el servicio lsyncd:

Habilitamos el servicio para que incie junto con el Sistema Operativo

chkconfig lsyncd on
chkconfig xinetd on

Luego levantamos el servicio

service lsyncd start

Instalacion y configuracion de Puppet 3.6 en modo MASTER/AGENT RHEL/CentOS/SL 5/6/7

Instalacion y configuracion de Puppet en modo MASTER/AGENT RHEL/CentOS/SL 5/6/7

En caso de necesitar usar Puppet en modo MASTER/AGENT es necesario tener un servidor dedicado para la tarea de "Puppet Master", basicamente es el encargado de publicar y asignar los modulos puppet para cada equipo que los solicite.

La arquitectura del modo MASTER/AGENT o MASTE/SLAVE de puppet es la siguente:

Cada equipo se conecta al Puppet MASTER a traves de un agente llamado "puppet-agent". Dicha conexion se realiza sobre HTTPS a traves del puerto 8140/tcp.

Instalacion del Puppet MASTER

Para proceder con la instalacion y configuracion del puppet master es necesario configurar los repositorios oficiales de puppetlabs.

La configuracion del repositorio varia segun la version del S.O.

  • Para RHEL/CentOS/SL 5.x
    sudo rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-5.noarch.rpm
  • Para RHEL/CentOS/SL 6.x
    sudo rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-6.noarch.rpm     ##> En caso de ser RHEL 6
  • Para RHEL/CentOS/SL 7.x
    sudo rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm     ##> En caso de ser RHEL 7

Instalacion de paquetes

Una vez configurado el repositorio procedemos a instalar los paquetes necesarios con el comando yum

yum install -y puppet-server

Creacion de certificado para el Master

Para crear el certificado es necesario especificar todos los nombres DNS a los que debe responder el mismo, en la mayoria de los casos dicho nombre es el FQDN de nuestro Master

Para dicha configuracion es necesario editar el archivo /etc/puppet/puppet.conf en la seccion [ main ] se debe de agregar los nombres DNS para los cuales respondera el certificado

[main]
dns_alt_names = puppet,puppet.example.com,puppetmaster01

Configuracion del servicio puppetmaster

Una vez instalados los paquetes necesarios se debe editar el archivo /etc/sysconfig/puppet

vim /etc/sysconfig/puppet

Dicho archivo debe quedar de la siguiente manera

# The puppetmaster server
#PUPPET_SERVER=puppet
 
# If you wish to specify the port to connect to do so here
PUPPET_PORT=8140
 
# Where to log to. Specify syslog to send log messages to the system log.
PUPPET_LOG=/var/log/puppet/puppet.log
 
# You may specify other parameters to the puppet client here
PUPPET_EXTRA_OPTS=--waitforcert=500

Iniciar y habilitar el servicio Puppet Master

Una vez configurado nuestro puppet master procedemos a iniciar el servicio y luego habilitar el mismo

Iniciar el servicio

service puppetmaster start

Habilitar el inicio automatico del servicio

chkconfig puppetmaster on

Creacion de modulos

Para crear los modulos es necesaria la siguiente estructura de directorio, cambiando el "modulo" por el nombre que tendra el modulo a crear

mkdir -p /etc/puppet/modules/"modulo"
 
mkdir -p /etc/puppet/modules/"modulo"/files
 
mkdir -p /etc/puppet/modules/"modulo"/manifests

Asignar modulos a clientes

Para asignar los modulos a los clientes es necesario modificar el archivo /etc/puppet/manifests/site.pp:

vim /etc/puppet/manifests/site.pp

Agregando los siguiente por cada cliente

hostnamedelcliente{
  include nombredelmodulo1
  include nombredelmodulo2
}

Instalacion y configuracion del puppet-agent en los equipos Clientes/Slave/Agentes

Una vez que se configuro el master se pasa a configurar los clientes donde correra el puppet-agent

Instalacion del puppet-agent

Para instalar el puppet-agent tambien es necesario configurar los repositorios oficiales de puppetlabs. Se puede realizar dicha tarea siguiendo los pasos descriptos para la instalacion del puppet-master

Luego se procede a instalar el paquete con el comando yum

yum install -y puppet

Configuracion del agente

Una vez que se instalo el paquete se debe modificar el archivo /etc/puppet/puppet.conf en la seccion [ agent ] agregar lo siguiente:

vim /etc/puppet/puppet.conf

server = puppet.example.com   ## (Esto se debe cambiar por el nombre DNS del servidor puppetmaster)
report = true
pluginsync = true

Iniciar y habilitar el servicio puppet-agent

Se debe tener cuenta que el cliente debe poder llegar al Master al puerto 8140/tcp

Inicio del puppet-agent

service puppet start

Habilitamos el servicio para que se levante cada vez que el equipo inicia

chkconfig puppet on

Firmar los certificados del cliente para que pueda establecer conexion con el Master

Una vez que se inicio el servicio en el cliente deberia de haber creado un certificado el mismo es enviado al puppet master, para que el cliente pueda consultar al Master es necesario firmar dicho certificado.

Dento del puppet-master ejecutamos podemos consultar la lista de certificados pendientes de firma

puppet cert list

Los certificados tienen como nombre el FQDN del cliente.
Finalmente se procede a firmar el certificado del cliente

puppet cert sign nombredelcertificado

Solucionar error Probably resource factory threw an exception.: () oVirt/RHEV vdsm

Solucionar error Probably resource factory threw an exception.: () oVirt/RHEV vdsm

Si al tratar de realizar alguna tarea sobre nuestros discos virtuales, es decir:

  • snapshots
  • clonaciones
  • exportaciones
  • importaciones
  • storage live migration

En la lista de eventos del oVirt GUI se presenta el siguiente error:

Probably resource factory threw an exception.: ()

Y en los logs del vdsm /var/log/vdsm/vdsm.log del host que es SPM encontramos el siguiente mensaje:

OSError: [Errno 17] File exists: '/rhev/data-center/00000002-0002-0002-0002-00000000008b/e1f1947b-b04a-4a50-a22d-f65110516143/images/58693eb1-d498-480e-95e7-524e0a682410'
67acab09-4bfb-4f05-a4f6-a36b31e01743::WARNING::2016-04-03 14:16:45,951::resourceManager::594::Storage.ResourceManager::(registerResource) Resource factory failed to create resource 'e1f1947b-b04a-4a50-a22d-f65110516143_imageNS.58693eb1-d498-480e-95e7-524e0a682410'. Canceling request.
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/resourceManager.py", line 590, in registerResource
    obj = namespaceObj.factory.createResource(name, lockType)
  File "/usr/share/vdsm/storage/resourceFactories.py", line 193, in createResource
    lockType)
  File "/usr/share/vdsm/storage/resourceFactories.py", line 122, in __getResourceCandidatesList
    imgUUID=resourceName)
  File "/usr/share/vdsm/storage/image.py", line 189, in getChain
    srcVol = volclass(self.repoPath, sdUUID, imgUUID, uuidlist[0])
  File "/usr/share/vdsm/storage/blockVolume.py", line 80, in __init__
    volume.Volume.__init__(self, repoPath, sdUUID, imgUUID, volUUID)
  File "/usr/share/vdsm/storage/volume.py", line 181, in __init__
    self.validate()
  File "/usr/share/vdsm/storage/blockVolume.py", line 89, in validate
    volume.Volume.validate(self)
  File "/usr/share/vdsm/storage/volume.py", line 193, in validate
    self.validateImagePath()
  File "/usr/share/vdsm/storage/blockVolume.py", line 460, in validateImagePath
    raise se.ImagePathError(imageDir)
ImagePathError: Image path does not exist or cannot be accessed/created: (u'/rhev/data-center/00000002-0002-0002-0002-00000000008b/e1f1947b-b04a-4a50-a22d-f65110516143/images/58693eb1-d498-480e-95e7-524e0a682410',)

Posiblemente se deba a quedaron links simbolicos rotos en el directorio que apunta a los volumenes presentados al cluster /rhev/data-center/

La solucion para dicho problema es eliminar todos los link simbolicos que se encuentran "rotos", es decir que apuntar a una ruta inexistente, para hacer eso podemos usar el siguiente comando:

[root@virt3 ~]# for file in $(find /rhev/data-center/ -type l); do [ -h "$file" -a ! -e "$file" ] && rm -fvr "$file"; done;

Dicho comando debe ejecutarse en el host que esta como SPM, aunque es recomendable ejecutarlo en todos los hosts de manera a que cuando alguno asuma como SPM no se vuelva a presentar el problema.

Una vez que hecho esto podemos reitentar la tarea que habia fallado.

Migrar S.O. RHEL/CentOS/SL 7 que bootea por SAN

Migrar S.O. RHEL/CentOS/SL 7 que bootea por SAN a otra LUN

Entorno

Sistema Operativo: CentOS 7.1
Lun Actual: /dev/mapper/emc_so
Lun Nueva: /dev/mapper/vsp_so
Particiones:

/boot -> /dev/mapper/emc_so1
LVM -> /dev/mapper/emc_so2

  • Volume Group -> rootvg
    • / -> rootlv
    • /tmp -> tmplv
    • /home -> homelv
    • /var -> varlv

Para lograr que la migracion se culmine de manera correcta se deben seguir los siguientes pasos:

1: Se debe presentar la lun nueva al equipo, y lograr que el equipo la reconozca:

Para que el S.O. reconozca la nueva LUN posiblemente sea necesario re-escanear o reiniciar las HBAs para eso podemos usar los siguientes comandos:

Escanear HBA: echo - - - > /sys/class/scsi_host/host#/scan

Reiniciar HBA: echo 1 > /sys/class/fc_host/host#/issue_lip

Donde # se debe reemplazar por el numero de HBA.

Se recomienda realizar un escaneo de todas las HBAs, en caso de que aun no se reconozco la lun se puede proceder a reiniciar las HBAs y luego volver a escanear las mismas.

En esta estapa se recomienda configurar el "nombre amigable" de la nueva lun, para esto debemos identificar el wwid de la lun nueva, el wwid es el valor que se muestra entre parentesis al ejecutar multipath -ll.

Por Ejemplo, si queremos identificar el wwid de una LUN presentada desde un Storage Hitachi:

[root@c7ke ~]# multipath -ll | grep HITACHI

mpathf (360060e80129f9b0050409f9b000002a1) dm-15 HITACHI ,OPEN-V

Una vez que tenemos el wwid de la lun nueva podemos asignarle un nombre amigable agregando la siguiente entrada en el archivo /etc/multipath.conf:

multipaths {
    multipath {
        wwid    360060e80129f9b0050409f9b000002a1
        alias   vsp_so
    }
}

Reemplanzando el wwid por el de la LUN nueva y el alias porque el nombre que elijamos.

Luego se debe "recargar" el servicio multipath para que tome los cambios:

service multipathd reload

2: Una vez que el equipo reconozca la Lun nueva es necesario particionar la misma.

Para clonar la tabla de particiones de la lun actual a la lun nueva podemos utilizar el comando sfdisk:

sfdisk -d /dev/mapper/emc_so | sfdisk /dev/mapper/vsp_so

Luego es necesario que el equipo reconozca las particiones creadas con el comando anterior:

partprobe /dev/mapper/vsp_so

3: Clonamos el /boot.

Como el /boot solo es accedido al momento del booteo del sistema lo podemos desmontar y clonar sin afectar el funcionamiento del S.O.

Para la clonacion de dicho FS podemos usar el comando dd:

umount /boot

dd if=/dev/mapper/emc_so1 of=/dev/mapper/vsp_so1 bs=5M

4: Movemos los volumenes LVM.

Si tenemos implementado LVM la migracion se simplifica bastante ya que con el comando pvmove se pueden mover datos en caliente.

Primero debemos crear los "Physical volumens"

pvcreate /dev/mapper/vsp_so2

Luego debemos extender nuestro "volume group" de manera a que la particion de la lun nueva sea parte del mismo.

vgextend rootvg /dev/mapper/vsp_so2

Procedemos a migrar los volumenes

pvmove /dev/mapper/emc_so2 /dev/mapper/vsp_so2

Una vez que termine la migracion de los volumenes podemos quitar del "volume group" la lun vieja.

vgreduce rootvg /dev/mapper/emc_so2

Finalmente debemos eliminar los PVs en la lun vieja para que al retirar no se presenten errores

5: Retirar la lun vieja.

Al culminar el paso 4 todo el Sistema Operativo esta sobre la Lun nueva, por lo tanto podemos despresentar la lun vieja de manera segura.

6: Montar el /boot

Una vez que retiramos la lun vieja podemos volver a montar el /boot. Para evitar errores al montar ese necesario hacer una recarga de los servicios manejados por el systemd, esto debido a que existe un unit-file que se encarga del /boot.

systemctl daemon-reload

En caso de que en el archivo /etc/fstab tengamos el /boot configurado a traves de UID, podemos montar el /boot con el siguiente comando:

mount /boot

En caso contrario debemos corregir el path en el fstab, cambiando /dev/mapper/emc_so1 por /dev/mapper/vsp_so1, luego ejecutamos:

mount /boot

7: Verificar configuracion del MultiPath:

Para que la migracion culmine de manera exitosa es muy importante tener bien configurado el multipath.

Una vez identificado el wwid de la lun nueva es sumamente importante verificar que la misma se encuentra dentro de 2 archivos:

/etc/multipath/wwids

Dentro del /etc/multipath/wwids deberiamos encontrar una linea parecida a la siguiente:
/360060e80129f9b0050409f9b000002a1/

[root@c7ke ~]# cat /etc/multipath/wwids | grep 360060e80129f9b0050409f9b000002a1
/360060e80129f9b0050409f9b000002a1/

Donde el valor dentro de las barras (/) debe se el wwid de la lun nueva

/etc/multipath/bindigs

Dentro del /etc/multipath/bindings deberiamos encontrar una linea parecida a la siguiente:
mpathf 360060e80129f9b0050409f9b000002a1

Ej:
Donde mpathf puede ser mpath[a-z] y el segundo valor debe ser el wwid de la lun nueva

[root@c7ke ~]# cat /etc/multipath/bindings | grep 360060e80129f9b0050409f9b000002a1
mpathf 360060e80129f9b0050409f9b000002a1

8: Eliminar cache de LVM

Para evitar problemas con el proximo inicio se recomienda eliminar la cache LVM:

rm /etc/lvm/cache/.cache

9: Configurar el grub2 con la lun nueva

Para dicha tarea es necesario editar el archivo /boot/grub2/device.map. El mismo debe contener lo siguiente:

(hd0) < ruta_de_la_lun_nueva >

Por ejemplo en nuestro caso nuestra lun tiene como nombre vsp_so. Por lo tanto el archivo debe contener lo siguiente:

(hd0) /dev/mapper/vsp_so

10: Instalar el grub2 en la nueva lun

Se debe instalar el grub2 directamente sobre la LUN

[root@c7ke ~]# grub2-install /dev/mapper/vsp_so

11: Volver a crear el Initial Ram Disk (initrd)

Luego de realizar y verificar todos los pasos anterios debemos volver a crear el initrd:

[root@c7ke ~]# cd /boot/
[root@c7ke boot]# dracut -f -v -a multipath

Reiniciar el Servidor

Finalmente podemos reiniciar el servidor, al reiniciar debemos cambiar la politica de booteo del mismo para apuntar a la nueva LUN

Solucionar error ERROR 1047 (08S01): WSREP has not yet prepared node for application use

Solucionar error 1047 en MariaDB

Este error se genera normalmente en las siguientes situaciones:

  • Cuando tenemos un cluster MariaDB con 2 nodos y uno de los nodos es apagado de manera brusca
  • Se pierde la conexion entre los nodos del cluster

El error que se genera es el siguiente:

error ERROR 1047 (08S01): WSREP has not yet prepared node for application use

Para solucionar dicho error tenemos 2 opciones:

  • Detener el servicio de mysql en el nodo que quedo solo y luego realizar el "bootstrap" del cluster, en CentOS/RHEL 6 se utilizarian los siguientes comandos:
    service mysql stop
    service mysql bootstrap
  • La otra forma de solucionar es ingresando a la consola mysql del nodo que quedo activo y establecer el valor "pc.bootstrap=yes" a la variables wsrep_provider_options
MariaDB> SET GLOBAL wsrep_provider_options="pc.bootstrap=yes";
Query OK, 0 rows affected (0.00 sec)

Con esto podremos volver a utilizar nuestras bases de datos de manera normal.

Instalación y configuración de Keepalived para usarlo con HAProxy


KeepAlived

KeepAlived es el encargado de levantar las direcciones IPs flotantes, el mismo se encarga de verificar si el servicio HaProxy se esta ejecutando en los nodos de manera a hacer failover automatico en caso de que caiga el servicio HaProxy

Instalacion de KeepAlived

El servicio keepalived es parte del paque "keepalived" que podemos instalar via yum

yum install -y keepalived

El archivo de configuracion principal del servicio es el /etc/keepalived/keepalived.conf *en dicho archivo se establecen tanto las direcciones IP que manejara el servicio ademas de los metodos para definir en que nodo debe estar preferentemente la IP.

###Abajo un ejemplo de configuracion basico del servicio keepalived con 2 direcciones IP flotantes.

vrrp_script chk_haproxy {          # Script de verificacion 
  script "killall -0 haproxy"      # verifica si existe un pid de haproxy
  interval 2                       # dicha verificacion lo hace cada 2 segundos
  weight 2                         # agrega 2 puntos al nodo que tenga un pid de haproxy
}
 
 
vrrp_instance VI_1 {               # Nombre de la instancia
    state MASTER                   # El rol que cumple dicho nodo en cuanto a la instancia, puede ser MASTER o BACKUP
    interface eth0                 # Interfaz de red en la cual se levantara la IP
    virtual_router_id 1            # ID del Virtual Router   
    priority 101                   # Prioridad o puntaje del nodo, 100 para el BACKUP y 101 para el MASTER
    advert_int 1                   # Intervalo en segundo de verificacion entre nodos
    vrrp_unicast_bind 10.150.48.73  # IP interna del nodo
    vrrp_unicast_peer 10.150.48.74  # IP del segundo nodo
    virtual_ipaddress {            # Se establecen las direcciones IP a levantar, pueden ser varias 
        10.150.48.75
        10.150.48.77
    }
    authentication {               # Se establece el metodo de autenticacion entre nodos
        auth_type PASS
        auth_pass 1111
   }
 
   track_script {                  # Se configura el chequeo del proceso haproxy configurado previamente
        chk_haproxy
   }
}
 
vrrp_instance VI_2 {               # Nombre de la instancia
    state BACKUP                   # El rol que cumple dicho nodo en cuanto a la instancia, puede ser MASTER o BACKUP
    interface eth0                 # Interfaz de red en la cual se levantara la IP
    virtual_router_id 2            # ID del Virtual Router   
    priority 100                   # Prioridad o puntaje del nodo, 100 para el BACKUP y 101 para el MASTER
    advert_int 1                   # Intervalo en segundo de verificacion entre nodos
    vrrp_unicast_bind 10.150.48.73  # IP interna del nodo
    vrrp_unicast_peer 10.150.48.74  # IP del segundo nodo
    virtual_ipaddress {            # Se establecen las direcciones IP a levantar, pueden ser varias 
        10.150.48.76
        10.150.48.78
    }
    authentication {               # Se establece el metodo de autenticacion entre nodos
        auth_type PASS
        auth_pass 1111
   }
 
   track_script {                  # Se configura el chequeo del proceso haproxy configurado previamente
        chk_haproxy
   }
}

Se debe tener en cuenta que dicho archivo debe ser editado conforme al rol y a la IP de cada nodo.

Una vez creado el archivo de configuracion debemos habilitar e iniciar el servicio

service keepalived start
chkconfig keepalived on

Que son las cookies?

Cookies

Que son las Cookies

Una cookie es una pequeña información enviada por un sitio web y almacenada en el navegador del usuario, de manera que el sitio web puede consultar la actividad previa del usuario.

Sus principales funciones son:

  • Llevar el control de usuarios: cuando un usuario introduce su nombre de usuario y contraseña, se almacena una cookie para que no tenga que estar introduciéndolas para cada página del servidor. Sin embargo, una cookie no identifica a una persona, sino a una combinación de computador-navegador-usuario.
  • Conseguir información sobre los hábitos de navegación del usuario, e intentos de spyware (programas espía), por parte de agencias de publicidad y otros. Esto puede causar problemas de privacidad y es una de las razones por la que las cookies tienen sus detractores.

Que es HTTP y HTTPS?


HTTP

HiperText Transfer Protocol (en español, protocolo de transferencia de hipertexto).

Es un protocolo de red (un protocolo se puede definir como un conjunto de reglas a seguir) para publicar páginas de web o HTML. HTTP es la base sobre la cual está fundamentado Internet, o la WWW.

Cómo funciona el protocolo HTTP?

El protocolo HTTP funciona a través de solicitudes y respuestas entre un cliente (por ejemplo un navegador de Internet) y un servidor (por ejemplo la computadora donde residen páginas web).
Una peticion HTTP tiene el siguiente formato:

Una respuesta HTTP tiene el siguiente formato:

HTTPS

HiperText Transfer Protocol Secure (en español, protocolo seguro de transferencia de hipertexto)

Está obviamente basado en el antes mencionado HTTP pero con la particularidad de utilizar un cifrado basado en la Secure Socket Layers mas conocidas como SSL y así crear un canal de transferencia cifrado con el que obviamente aumenta la seguridad en el tráfico de información en comparación al protocolo HTTP común.

Volver atras archivo modificado por Puppet con Puppet Filebucket

En caso de haber cometido un error en algún template o archivo modificado por puppet es posible volver atrás gracias a que por defecto puppet hace un backup de los archivos antes de modificarlos, para restaurar un backup la sintaxis del comando a ejecutar en el equipo cliente es la siguiente:

puppet filebucket restore -b /directoriobucket /ruta/archivo MD5arestaurar

Por defecto en entornos RHEL/CentOS el directorio es /var/lib/puppet/clientbucket/

Ej:

En la maquina cliente:

puppet filebucket restore -b /var/lib/puppet/clientbucket/ /etc/passwd 379aa0669894ff4150ec2dad28622216

Un Ejemplo practico:

Tenemos un archivo de texto llamado archivo-test

[root@nodo ~]# cat /root/archivo-test.txt
Esto es una prueba de rollback

Luego al ejecutar el agente puppet, el mismo modifica dicho archivo

[root@nodo ~]# puppet agent -t
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for nodo.infratic.com
Info: Applying configuration version ‘1416421872’
Notice: /Stage[main]/Basico/File[/root/archivo-test.txt]/content:
— /root/archivo-test.txt 2014-11-19 15:40:49.248857861 -0300
+++ /tmp/puppet-file20141119-7388-tkwcex-0 2014-11-19 15:41:04.858857840 -0300
@@ -1 +1 @@
-Esto es una prueba de rollback
+Esto es una prueba de rollback “Esto no deberia estar despues”
 
Info: Computing checksum on file /root/archivo-test.txt
Info: FileBucket got a duplicate file {md5}379aa0669894ff4150ec2dad28622216
Info: /Stage[main]/Basico/File[/root/archivo-test.txt]: Filebucketed /root/archivo-test.txt to puppet with sum 379aa0669894ff4150ec2dad28622216
Notice: /Stage[main]/Basico/File[/root/archivo-test.txt]/content: content changed ‘{md5}379aa0669894ff4150ec2dad28622216’ to ‘{md5}3de659e5dc355b14ec5cd0606b2baef8’
Notice: Finished catalog run in 0.79 seconds

Al finalizar la ejecucion el agente nos notifica que modifico el contenido de nuestro archivo y nos muesta el MD5sum de la version anterior y de la version actual del archivo, es el MD5sum de la version anterior (lo que esta en negritas)el que debemos guardar.

Notice:/Stage[main]/Basico/File[/root/archivo-test.txt]/content: content changed ‘{md5}379aa0669894ff4150ec2dad28622216’ to ‘{md5}3de659e5dc355b14ec5cd0606b2baef8’

Verificamos de que realmente se modifico nuestro archivo

[root@nodo ~]# cat /root/archivo-test.txt
Esto es una prueba de rollback “Esto no deberia estar despues”

Procedemos a volver a la version anterior.

[root@nodo ~]# puppet filebucket restore -b /var/lib/puppet/clientbucket/ /root/archivo-test.txt 379aa0669894ff4150ec2dad28622216

Finalmente verificamos que volvimos atras los cambios hechos por Puppet

[root@nodo ~]# cat /root/archivo-test.txt
Esto es una prueba de rollback

Dicho MD5sum de la versiones anteriores de nuestros archivos modificados los podemos sacar de los logs del agente puppet en las maquinas clientes o en caso de tener herramientas como Foreman simplemente verificamos los reportes de la maquina cliente