29 dic

¿Cómo compilar Squid con SSL?

Como bien sabemos Squid con ssl no viene por defecto, para activar esta opción debemos compilar el paquete Squid con la opción –enable-ssl, entonces ¿cómo compilar squid con ssl?

En mi caso me hizo falta para arm, pero el procedimiento es igual para arquitecturas x86

Paquetes necesarios

[codeBusc]
sudo apt-get install devscripts build-essential fakeroot libssl-dev
[/code]

Código fuente de Squid3

apt-get source squid3
apt-get build-dep squid3

Dependencias

dpkg-source -x squid3_3.4.8-6+deb8u1.dsc
Preparación del paquete

Añadimos las opciones de compilación en el fichero rules


vim squid3-3.4.8/debian/rules

DEB_CONFIGURE_EXTRA_FLAGS := --datadir=/usr/share/squid3 \
                --sysconfdir=/etc/squid3 \
                --mandir=/usr/share/man \
                --enable-inline \
                --disable-arch-native \
                --enable-async-io=8 \
                --enable-storeio="ufs,aufs,diskd,rock" \
                --enable-removal-policies="lru,heap" \
                --enable-delay-pools \
                --enable-ssl \
                --enable-ssl-crtd \
Compilación de Squid con SSL

Y por último a compilar y a esperar, en mi caso fueron varias horas, pobre Raspberry

 dpkg-buildpackage -rfakeroot -b 

Una vez finalizado dispondremos de diferentes paquetes, los dos que nos hacen falta son

squid3_3.4.8-6+deb8u1_armhf.deb
squid3-common_3.4.8-6+deb8u1_all.deb

Una vez instalados podremos comprobar que mirando la versión de squid tendremos activada la opcion –enable-ssl 

[email protected]:~# squid3 -v | grep ssl
configure options:  '--build=arm-linux-gnueabihf' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=${prefix}/lib/squid3' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--datadir=/usr/share/squid3' '--sysconfdir=/etc/squid3' '--mandir=/usr/share/man' '--enable-inline' '--disable-arch-native' '--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-ssl' '--enable-ssl-crtd' '--enable-cache-digests' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth-basic=DB,fake,getpwnam,LDAP,MSNT,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' '--enable-auth-digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper' '--enable-auth-ntlm=fake,smb_lm' '--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group' '--enable-url-rewrite-helpers=fake' '--enable-eui' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--disable-translation' '--with-swapdir=/var/spool/squid3' '--with-logdir=/var/log/squid3' '--with-pidfile=/var/run/squid3.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--enable-build-info=Raspbian linux' '--enable-linux-netfilter' 'build_alias=arm-linux-gnueabihf' 'CFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security'

Con esto ya disponemos de Squid con SSL, ahora podemos añadir certificados para la creación del una conexión segura cliente servidor.

 

 

17 ago

Añadir nodo a un cluster Voldemort

Después de explicar ¿qué es voldemort? y ¿cómo instalarlo? nos quedamos con un cluster de dos nodos, en este post explicaré como añadir en nuevo nodo a un cluster Voldemort.

cluster voldemort

Como impresiones generales diré, que no es sencillo, no es intuitivo y no es rápido, pero que hacer, se puede hacer.

Me pareció algo así

Tarea

Primero de todo nos ponemos en situación, en el ultimo post, teníamos un cluster de dos nodos, con 5 particiones.


<cluster>
 <name>Test</name>
 <server>
 <id>0</id>
 <host>node1</host>
 <http-port>8081</http-port>
 <socket-port>6666</socket-port>
 <partitions>0, 2, 4</partitions>
 </server>
 <server>
 <id>1</id>
 <host>node2</host>
 <http-port>8081</http-port>
 <socket-port>6666</socket-port>
 <partitions>1, 3, 5</partitions>
 </server>
</cluster>

Como sabemos al ser la particiones estáticas deberemos utilizar las 6 que disponemos, el sistema de voldemort trae herramientas que nos dan una idea de cómo debería quedar el cluster.

Los pasos son

  1. Reparticionar
  2. Rebalancear
  3. Lanzar la tarea
  4. Limpiar datos huérfanos

Paso 1 .- Repartition.

Para una expansion del cluster deberemos crear un fichero cluster xml provisional  “interim”, en el que añadiremos los nuevos nodos , pero con la parte de particiones vacía.


<cluster>
<name>qacluster</name>
<server>
<id>0</id>
<host>nodo1</host>
<http-port>8081</http-port>
<socket-port>6666</socket-port>
<partitions>0, 2, 4</partitions>
</server>
<server>
<id>1</id>
<host>nodo2</host>
<http-port>8081</http-port>
<socket-port>6666</socket-port>
<partitions>1, 3, 5</partitions>
</server>
<server>
<id>2</id>
<host>nodo3</host>
<http-port>8081</http-port>
<socket-port>6666</socket-port>
<partitions></partitions>
</server>
</cluster>

Como podemos ver añadimos el nodo 3 en un fichero cluster-interim, pero con las particiones vacías.

Lanzamos la herramienta de RepartitionerCLI, la encontramos dentro de la carpeta bin.

bin/run.class.sh voldemort.tools.RepartitionerCLI --current-cluster <current-cluster> --current-stores <current_stores> --interim-cluster <interim-cluster> --output-dir <output_dir>

Os recomiendo que os creáis unas carpetas para tener cada fichero ordenado, deberemos añadir todos los stores en un solo fichero, el ejemplo de la llamada sería.

bin/run-class.sh voldemort.tools.RepartitionerCLI --current-cluster repo_stores/cluster.xml --current-stores repo_stores/prueba.xml --interim-cluster repo_stores/interim/cluster.xml --output-dir repo_stores/plan/

Dentro de la carpeta repo_stores/plan tendremos

current-cluster.xml.analysis
final-cluster.xml
final-cluster.xml0
final-cluster.xml0.analysis
final-cluster.xml.analysis

En los ficheros de analysis tendremos los pasos que realizar para llegar a la estructura final del cluster, que es el fichero final-cluster.xml

Paso 2 .- Rebalancing 

Deberemos crear el plan para hacer el rebalancing, usaremos el fichero final-cluster.xml que obtuvimos del paso anterior.

bin/run-class.sh voldemort.tools.RebalancePlanCLI --current-cluster repo_stores/cluster.xml --current-stores repo_stores/prueba.xml --final-cluster repo_stores/planRepartitioner/final-cluster.xml --output-dir repo_stores/planRebalance/

En la carpeta planRebalance deberemos tener el fichero final-cluster.xml, recordemos que tenemos 2 nodos que estan trabajando, pero un tercero que no esta dentro del cluster ni tienes las stores, asi que debemos añadirlo y  crear las stores en el tercer nodo antes de continuar.

Debemos utilziar el fichero de cluster-interim del paso 1, para actualizarlo en todos los servidores, de esta manera el nodo 3 no tendrá particiones y será, la tarea de rebalancing del paso siguiente la que lo actualice las particiones.

bin/vadmin.sh meta set cluster.xml=repo_stores/interim/cluster.xml --node 0 --url tcp://127.0.0.1:6666
bin/vadmin.sh store add --file repo_stores/prueba.xml --node 2 --url tcp://127.0.0.1:6666

Utilizamos la herramienta vadmin.sh con la opcion –node 2, para añadir las stores únicamente en el servidor 3

 Paso 3 .- Lanzar el rebalancing 

Utilizaremos la siguiente herramienta.

bin/run-class.sh voldemort.tools.RebalanceControllerCLI --url $URL --final-cluster final-cluster.xml --parallelism 8 --proxy-pause 900
  • $URL: Será la direccion de uno de los nodos del cluster
  • Final-cluster :  EL fichero final-cluster que obtuvimos en el último paso, que es la situación final que estará el cluster cuando termine la tarea.
  • Parallelism: Numero de tareas de rebalancing que se pueden lanzar en el mismo momento.
  • Proxy-pause : El tiempo que esperará entre la actualizacion de la metadata y el inicio del rebalancing,

Nota: Antes de lanzarlo si paramos en medio del proceso, el sistema queda inestable asi que utilicemos algun screen o tmux o algo asi …

bin/run-class.sh voldemort.tools.RebalanceControllerCLI --url tcp://127.0.0.1:6666 --final-cluster repo_stores/planRepartitioner/final-cluster.xml --parallelism 8 --proxy-pause 900

Nos dará información sobre lo que va ha hacer y comenzara el proceso, ¿cómo podemos ver el estado?

bin/vadmin.sh async-job list --url tcp://127.0.0.1:6666

 

Aquí podemos ver que esta haciendo, como dato informativo en mi caso para 20Gb de información tardo 4 horas, o sea rápido rápido no es

Y por último.

 Paso 4 .- Limpieza de los datos huérfanos.

Este proceso solo mueve datos, con lo que una vez terminado habrá nodos que tendrán datos de particiones que ya no le pertenecen.

bin/vadmin.sh cleanup orphaned-data --all-nodes --url tcp://127.0.0.1:6666

Finalizado, cluster ampliado, en el siguiente post explicaré el concepto de zonas y como aprovecharlas para realizar replicaciones.

 

 Referencias: 

http://www.project-voldemort.com/voldemort/rebalance.html

https://github.com/voldemort/voldemort/wiki/Voldemort-Admin-to

 

 

 

 

 

 

 

 

16 mar

Marathon framework para Apache-Mesos

Después de explicar qué es Apache-Mesos y cómo se instala llega el momento de poner a funcionar el sistema, para ello lo que vamos a instalar es Marathon y lo utilizaremos para correr aplicaciones en los slaves de Apache-Mesos.

Pues vamos al lio

¿Qué es Marathon?

Marathon es un framework que corre junto a Mesos y que nos permite lanzar a través de él aplicaciones de larga duración, o sea que vayan a estar tiempo dando servicio, por ejemplo un Apache, servicios Python …, viene siendo un init para el cluster de Mesos, a más a más dispone de una API que hace la gestión realmente sencilla.

¿Cómo se instala Marathon?

Siguiendo con la arquitectura de los post anteriores, tenemos en nuestras maquinas Centos añadidos los repositorios de Mesosphere, asi pues que la instalacion es tan sencilla como lanzar en todos los masters del cluster de Mesos el siguiente comando

yum install marathon

Al utilizar el paquete que nos da Mesosphere la configuración es automática, por defecto nos utilizara el mismo ZooKeeper que tenemos configurado para Mesos.

Únicamente me encontré con un problema a la hora de configurarlo y fue que me hacia falta cambiar el puerto por el cual estaba escuchando ya que se solapaba con otros servicios, esto se hace de una forma muy fácil.

Las opciones que nos encontramos en http://mesosphere.github.io/marathon/docs/command-line-flags.html se activan creando un fichero de configuración de la siguiente manera, por ejemplo para modificar el puerto por el cual escucha

cat /etc/marathon/conf/http_port
7070

¿Cómo se trabaja con Marathon?

Una vez instalado comprobamos que el servicio esta corriendo.

marathon.service - Marathon
Loaded: loaded (/usr/lib/systemd/system/marathon.service; enabled)
Active: active (running) since Sun 2015-03-15 09:14:58 UTC; 7min ago
Main PID: 1352 (java)
CGroup: /system.slice/marathon.service
├─1352 java -Djava.library.path=/usr/local/lib -Djava.util.logging.SimpleFormatter.format=%2$s%5$s%6$s%n -Xmx512m -cp /usr/local/bin/marathon mesosphere.marathon.Main --http_port 7070 --zk zk://172.3...
├─1368 logger -p user.info -t marathon[1352]
└─1369 logger -p user.notice -t marathon[1352]

Tenemos dos formas de trabajar, a través de una web o por command line.

Interfaz web

Para conectarnos a Marathon iremos a la ip de nuestro master y el puerto por defecto 8080.

Veremos algo tal que así, en mi caso ya dispongo de algunas tareas corriendo.

marathon

Por la interfaz web podemos hacer cosas muy sencillas, por ejemplo si le damos a New App nos permitirá lanzar una aplicación con algunos parámetros base.

marathon2

Por ejemplo podemos hacer una tarea que lace un echo y se espere 5 segundos, como hemos dicho, Marathon se asegurara que esa tarea siempre este corriendo en el cluster de Mesos, a más a más como explicamos en los post anteriores nos asegurará que tendremos los recursos que nos hacen falta, en este caso un 10% de la cpu disponible 16MB de Ram y sin disco necesario.

marathon task

Como hemos dicho sin nos fijamos en el gif, esta tarea tiene un final, pero el cluster se encargara de que siempre este funcionando, cuando se detecte que la tarea se finalizo se volverá a lanzar.

runAPP.gif

Si le damos encima de la aplicación podemos ver datos muy interesantes como por ejemplo, cuando se lanzo, en que nodo del cluster se encuentra o que versión esta desplegada. Cada cambio que apliquemos en las condiciones que queremos que corra nuestra aplicación (por ejemplo aumentarle la RAM) será una nueva versión, de tal manera que podremos volver atrás en las configuraciones.

Información de la tarea

infotaskConfiguración

configure

 

Hasta aquí la parte sencilla, ahora vamos al command line y vamos a explicar como se mueven las aplicaciones por el cluster.

Marathon como no podría ser de otra manera tiene una API para gestionar las tareas, las peticiones sobre las tareas nuevas o ya existentes se realizan envío de ficheros json, tenemos diferentes opciones todas están descritas aquí.

Vamos a poner ejemplo de las más comunes.

Creación y modificación de aplicaciones a través de la REST API.

Lo primero es generar un json con las opciones que queramos, en la doc oficial podemos ver que pueden tener un montón de opciones diferentes. https://mesosphere.github.io/marathon/docs/rest-api.html#post-/v2/apps

Aquí voy a poner unos cuantos ejemplos y explicaré las opciones que me resultaron mas útiles.

Ports

{
"cmd": "echo `hostname` test.txt ; /usr/bin/python -m SimpleHTTPServer $PORT0",
"id": "/python",
"instances": 3,
"mem": 0.001,
"cpus": 0.001,
"disk": 0,
"ports": [
80
]
}

Este es muy sencillo, pero es interesante ver como podemos pasar un puerto a la lina de ejecución, en este caso nos interesa que nuestro servidor HTTP siempre se ejecute en el puerto 80, esta característica será imperativo para que la aplicación pueda correr en un slave, o sea que dicho slave tenga el puerto 80 libre. Con esto nos permite poder correr diferentes servidores web en el cluster. La variable $PORT0 será un puerto aleatorio que asignara mesos, cuando explique la alta disponibilidad de Marathon veremos como podemos saber ese puerto en todo momento.

HealthChecks

"healthChecks":[
{
"protocol":"TCP",
"gracePeriodSeconds":3,
"intervalSeconds":5,
"portIndex":1,
"timeoutSeconds":5,
"maxConsecutiveFailures":3
}

Podemos asignar HeathCheck a la tarea, por defecto cuando el pid de la tarea desaparece se da por finalizada y se vuelve a lanzar, pero como sabemos esto no siempre es significativo, podemos entonces verificar el funcionamiento de nuestra aplicación a través de un check TCP o una respuesta HTTP

upgradeStrategy

"upgradeStrategy": {
"minimumHealthCapacity": 1
},

Esta opción es muy interesante, con ella le diremos el número mínimo de instancias que debe haber en el caso que realicemos un cambio de configuración, cuando se realiza dicho cambio las tareas se vuelven a lanzar, imaginemos que tenemos 100 apaches, y queremos aumentarle la memoria, en el caso que no hubiéramos puesto esta opción nos encontraríamos que el cluster apagaría todas las instancias para volver a lanzarlas con la nueva configuración.

uris y env

{
"cmd": "env ; /tmp/env ; gzip -d server.gz ; bash server $PORT0",
"cpus": 0.2,
"id": "artifact",
"instances": 1,
"mem": 1,
"disk": 15000,
"backoffSeconds": 1,
"upgradeStrategy": {
"minimumHealthCapacity": 1
},
"tasksRunning": 3,
"tasksStaged": 0,
"ports": [
0
],
"uris": [
"http://172.30.0.145/server.gz"
],
"env": {
"TEST": "ENVIO DE VARIABLE"
}

Como explicamos en los post anteriores cuando lanzamos una tarea Mesos crea un nuevo container, este nuevo espacio aislado tiene sus propias variables de entorno, estas variables se las podemos pasar como vemos en el ejemplo, la  variable TEST.

A más a más dentro del proceso de desligue de la aplicación le podemos decir que se descarga algo de una web, por ejemplo el código de la aplicación. ;)

Constraints

{
"id": "kafka",
"cmd": "/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/server.properties",
"mem": 12,
"cpus": 0.001,
"instances": 1,
"constraints": [
["hostname", "UNIQUE"]
]
}

Nos puede interesar tener diferentes servicios en diferentes nodos del cluster, por ejemplo si tenemos un mysql corriendo no nos interesara que los slaves y el master puedan estar en la misma máquina, UNIQUE es nuestro amigo.

Vamos a ver como lanzamos una tarea.

Crearemos una sencilla, un servidor python que correrá en cualquier puerto, la linea de hostname no es necesaria, pero es útil para cuando expliquemos el HA de marathon, le decimos que nos arranque 3 instancias.

{
"cmd": "echo `hostname` ; test.txt ; /usr/bin/python -m SimpleHTTPServer $PORT0",
"id": "/zpython",
"instances": 3,
"mem": 0.001,
"cpus": 0.001,
"disk": 0,
"ports": [
80
]
}
curl -H "Content-Type: application/json" -d @python.json http://localhost:7070/v2/apps

Como podemos ver en el gif la tarea se crea y se despliegan 3 instancias

deployAPP.gifSi nos vamos a la web del cluster de Mesos vermeos las tareas corriendo.

runtask

 

Escalada de aplicaciones 

Imaginemos que ahora en vez de 3 necesitariamos 100, pues la cosa seria tan sencilla como modificar la opcion instance y volver a lanzar el curl.

{
"cmd": "echo `hostname`; test.txt ; /usr/bin/python -m SimpleHTTPServer $PORT0",
"id": "/zpython",
"instances": 50,
"mem": 0.001,
"cpus": 0.001,
"disk": 0,
"ports": [
80
]
}
curl -H "Content-Type: application/json" -d @python.json http://localhost:7070/v2/apps

Como podéis ver los valores de mem y cpu no tienen sentido, pero los puse asi para que podamos crear aplicaciones sin control.

scalationAPP.gif

Esto es una maravilla a mi parecer.

50

Una vez creadas las 50 tareas, si nos conectamos a un slave como se reparten con un simple ps

[[email protected] centos]# ps aux | grep python
root 471 0.0 0.5 549976 18140 ? Ssl 08:59 0:00 /usr/bin/python -Es /usr/sbin/tuned -l -P
root 24059 0.0 0.0 115216 1472 ? Ss 10:33 0:00 sh -c echo `hostname` &gt;&gt; test.txt ; /usr/bin/python -m SimpleHTTPServer $PORT0
root 24062 0.0 0.2 201072 9676 ? S 10:33 0:00 /usr/bin/python -m SimpleHTTPServer 31631
root 24283 0.0 0.0 115216 1472 ? Ss 10:41 0:00 sh -c echo `hostname` &gt;&gt; test.txt ; /usr/bin/python -m SimpleHTTPServer $PORT0
root 24286 0.0 0.2 201072 9676 ? S 10:41 0:00 /usr/bin/python -m SimpleHTTPServer 31394
root 24301 0.0 0.0 115216 1468 ? Ss 10:41 0:00 sh -c echo `hostname` &gt;&gt; test.txt ; /usr/bin/python -m SimpleHTTPServer $PORT0
root 24304 0.0 0.2 201072 9680 ? S 10:41 0:00 /usr/bin/python -m SimpleHTTPServer 31905

Podemos ver como se han ido asignando puertos “aleatorios” en los servicios, si hacemos una petición a ese puerto buscando el fichero test.txt nos deberá dar el hostname de la maquina donde esta corriendo.

[[email protected] centos]# curl localhost:31842/test.txt
ip-172-30-0-116.us-west-2.compute.internal

Si queremos volver a dejar todo como estaba el procedimiento es el mismo, cambiamos el 50 por 3 y listos.

decrecerAPP
Vamos a ver que pasaría en el caso que uno de nuestros servicios python dejará de funcionar repentinamente, ya que dijimos que siempre deberíamos tener 50 corriendo.

killAPP

Como podemos ver es muy rapida.

Por último vamos a ver donde podemos encontrar nuestras aplicaciones dentro de los slaves, si no le hemos dicho lo contrario todos los contenedores son creados en /tmp.

Si nos vamos a ese nivel y hacemos un find del fichero txt podremos ver lo siguiente.

[[email protected] mesos]# find . -name test.txt
./slaves/20150315-085909-1862278828-5050-809-S1/frameworks/20150109-162856-2449481388-5050-10637-0000/executors/python.504a72d9-caf2-11e4-82c6-0233785b9264/runs/72d62e43-101c-4e20-89b6-f0b93b1baa94/test.txt
./slaves/20150315-085909-1862278828-5050-809-S1/frameworks/20150109-162856-2449481388-5050-10637-0000/executors/python.53d3e7ba-caf2-11e4-82c6-0233785b9264/runs/3798405d-b0d4-40ed-9939-7b29eb40c68b/test.txt
./slaves/20150315-085909-1862278828-5050-809-S1/frameworks/20150109-162856-2449481388-5050-10637-0000/executors/python.c2094b5c-caf3-11e4-8d09-02f82bce2403/runs/6c67ef7b-1bac-44cf-850e-209b99517c08/test.txt
...
[[email protected] mesos]# pwd
/tmp/mesos

La ruta que vemos es el mismo identificador que vemos en la pagina de Mesos Cluster
taskid

 

En el siguiente post explicaremos como montar HA para las aplicaciones de Marathon.

23 nov

Instalación de Graphite en HA

Graphite en HA

Instalar Graphite para HA

Vamos a explicar como montar un sistema de Graphite en HA , en esta entrada explicaba como hacer la instalación inicial de graphite , así que partimos de un escenario donde ya tenemos un Graphite instalado y lo que queremos es asegurarnos que en el caso que caiga no nos quedemos sin sistema de métricas.

Por último antes de empezar, el sistema de alta disponibilidad que vamos a montar es tipo mirror.

Pues vamos al lío…

Partes de Graphite

Graphite se compone de una serie de demonios que trabajan al unisono para poder generar las graphicas, vamos a explicar que papel tiene cada uno de ellos, ya que será interesante para entender como montar el sistema de alta disponibilidad.

Carbon-Relay: Es el encargado de tratar la métrica que recibimos en primera instancia, decidira a que carbon-cache enviara la metrica segun el tipo de balanceo que le hayamos dicho (consistent-hashing o relays-rules)

  • Consistent-hashing : Este método se utiliza cuando las métricas siempre irán a los mismos carbón-caches y tenemos más de uno, básicamente lo que hacemos en un balanceo tipo Round-Robin
  • Relays-rules: Dependiendo del patron de la metrica el relay enviará el dato a un o otro carbon-cache(o a otro relay).

/opt/graphite/conf/carbon.conf

# Use relay-rules.conf to route metrics to destinations based on pattern rules
#RELAY_METHOD = rules
#
# Use consistent-hashing for even distribution of metrics between destinations
#RELAY_METHOD = consistent-hashing

Carbon Cache : Este demonio tiene dos funciones, por un lado es el encargado de escribir la métrica en disco y por otro lado es el encargado de recibir las peticiones de la webapp.

Whisper: Es el sistema de escritura que se utiliza por defecto, las métricas se grabaran en fichero wsp (whisper) de forma secuencial.

Webapp : Esta es la parte con la que veremos las metricas, es un django servido por un apache.

Arquitectura deseada.

Donde queremos llegar.

Graphite HA structure

Vamos a explicar el flujo de datos que tendremos y después explicaremos como se configura esta arquitectura.

  1. Los servidores 1 y 2 serán iguales y los servidores 3-4 también.
  2. La estructura se compone de 4 servidores, los 4 tendrán configurado Graphite con la instalación normal (así resulta mas fácil)
  3. Tendremos un balanceador para que nos enviara las peticiones en round robin a los primeros Carbon-relays (Servidor 1 y 2)

Flujo de envío de datos.

  1. Enviaremos las métrias al balanceador
  2. El balanceador en RoundRobin enviara cada métrica a un Carbon-relays de los servidores 1 y 2
  3. Los servidores 1 y 2 enviaran la métrica recibida a los Carbon-relays de los servidores 3-4 a través, NO es roundrobin, tendremos factor de replicación 2 con dos servidores, así que la métrica se enviara dos veces.
  4. Los Carbon-relays de los sservidores 3 y 4 recibirán la métrica, estos se encargaran de enviarlos a los Carbon-cache, tendremos 2 por máquina (un Carbon-cache una Cpu), en este caso con factor de replicación 1, una métrica para cada Carbon-cache (RoundRobin).
  5. Carbon-Cache recibirá la métrica y la grabará en whisper.

 Flujo de consulta de datos

  1. La peticiones las enviaremos a los servidores 3-4.
  2. La peticion llegará al balancedador, este por RoundRobin enviara a uno de los dos sevidores (3-4)
  3. La Webapp recibirá la petición, primero de todo irá al Memcache de los servidores 1-2 para comprobar que no tenga el dato. (Memcache no es necesario, pero aligera la carga)
  4. Si el dato no se encuentra lanzará la petición a los Carbon-cache del mismo servidor por los puertos 7102 y 7002.
  5. Carbon-cache ira a disco  buscar el dato y lo entregará a la webapp

 

Como podemos ver lo que estamos haciendo es simplemente repartir el dato que recibimos entre dos sistemas, de esta manera tendremos un espejo de la arquitectura de Graphite, los servidor 1-3 y los servidores 2-4, pudiendo romper cualquier elemento sin perder servicio.

 

Configuración de la alta disponibilidad

Como hemos visto la arquitectura es simétrica, así pues la configuración de los servidores 1-3 será la misma que la de los servidor 2-4.

Configuración de carbon-relay (Servidores 1-2)

Estos servidores los configuraremos exclusivamente en la sección relay del fichero de configuración de carbon.conf

Le diremos configuraremos el puerto normal y el puerto donde enviaremos las métricas Pickle, (altamente recomendado enviar todo lo que podamos por Pickle)

/opt/graphite/conf/carbon.conf

LINE_RECEIVER_INTERFACE = 0.0.0.0
LINE_RECEIVER_PORT = 2003
PICKLE_RECEIVER_INTERFACE = 0.0.0.0
PICKLE_RECEIVER_PORT = 2014

Seleccionaremos el método de balanceo que queramos, en nuestro caso como queremos un espejo tendremos que activar consistent-hashing

RELAY_METHOD = consistent-hashing

Ahora el factor de replicación, en estos Carbon-relays deberá ser 2, ya que queremos que cada métrica se envíe a ambos grupos de servidores (2-4)


REPLICATION_FACTOR = 2

Como es lógico le tendremos que decir donde están esos servidores, los puertos que ponemos serán los puertos Pickle, ya que todas las comunicaciones que se muevan en el sistema deberían ser Pickle

DESTINATIONS = Servidor3:2014, Servidor4:2014

Esta configuración sera igual en los servidores 1 y 3

Configuración de carbon-relay (Servidores 3-4)

La métrica que se envía desde los servidores 1-2 deberá ser recibida por los Carbon-relay de los servidores 3-4, en este caso ponemos un Carbon-relay por delante ya que vamos a tener mas de un Carbon-cache y nos interesa que podamos balancear entre ellos.

En el fichero carbon.conf de los servidores 3-4 en la seccion [relay], deberemos poner lo siguiente:

/opt/graphite/conf/carbon.conf
PICKLE_RECEIVER_INTERFACE = 0.0.0.0
PICKLE_RECEIVER_PORT = 2014

Donde el PICKLE_RECEIVER_PORT deberá ser el mismo que hemos puesto en los destinos de los primeros Carbon-relay,

&lt;/pre&gt;
RELAY_METHOD = consistent-hashing

Ahora el factor de replicación, en estos Carbon-relays deberá ser 1, ya que queremos que cada métrica se envíe a solo un Carbon-cache de los que tenemos en la misma máquina, o sea que consiguiremos un RoundRobin.

 

REPLICATION_FACTOR = 1

Como es lógico le tendremos que decir donde están esos servidores, los puertos que ponemos serán los puertos Pickle, ya que todas las comunicaciones que se muevan en el sistema deberían ser Pickle

DESTINATIONS = 127.0.0.1:2004, 127.0.0.1:2014

Configuración de carbon-cache (Servidores 3-4)

Como vemos en el esquema por cada servidor tendremos dos Carbon-cache, deberemos estar atentos a este punto ya que cambia un poco la configuración estándar.
Deberemos localizar dentro de la sección [cache] en el fichero carbon.conf de los servidores 3 y 4 los siguientes valores.

[cache]
PICKLE_RECEIVER_PORT = 2004
CACHE_QUERY_PORT = 7002

Podremos para el primer Carbon-cache los puertos donde podremos enviar las métricas PICKLE_RECEIVER_PORT, que deberá ser el mismo que hemos configurado en los Carbons-relay de los servidores 3-4.
Y el CACHE_QUERY_PORT que será el puerto por el que la Webapp enviará las consultas.

Con esto tendremos la configuración del primer Carbon-cache de un servidor, ahora deberemos configurar el segundo, tal que así.

[cache:b]
PICKLE_RECEIVER_PORT = 2104
CACHE_QUERY_PORT = 7102

Con esto creamos un nuevo carbón cache b siguiendo la misma lógica que con el primero

Por ultimo deberemos decirle al sistema que levante los dos Carbon-cache.

Podemos tener un init.d tal que así

#!/bin/sh
# !!! generated by puppet !!!

### BEGIN INIT INFO
# chkconfig: 2345 99 80
# Provides: carbon-cache
# Required-Start: $remote_fs $network $time
# Required-Stop: $remote_fs $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start/Stop carbon-cache
# Description: Enables Graphites carbon-cache data collecting engine
### END INIT INFO

case &quot;$1&quot; in
start)
python /opt/graphite/bin/carbon-cache.py --instance=a start
python /opt/graphite/bin/carbon-cache.py --instance=b start
;;
stop)
python /opt/graphite/bin/carbon-cache.py --instance=a stop
python /opt/graphite/bin/carbon-cache.py --instance=b stop
;;
status)
python /opt/graphite/bin/carbon-cache.py --instance=a status
python /opt/graphite/bin/carbon-cache.py --instance=b status
;;
restart)
$0 stop ; sleep 3 ; $0 start
RC=$?
exit $RC
;;
*)
echo &quot;Usage: $0 {start|stop|restart|status}&quot;
exit 1
;;
esac

exit

Esta configuración será la misma para el servidor 4

Configuración de la Webapp

Ya solo nos queda la Webapp esta se configura en un fichero diferente

Deberemos tocar las siguientes opciones:

vim  /opt/graphite/webapp/graphite/local_settings.py
MEMCACHE_HOSTS = ['Servidor1:11211','Servidor2:11211',]
CARBONLINK_HOSTS = [&quot;127.0.0.1:7002:a&quot;, &quot;127.0.0.1:7102:b&quot;]

En el caso que utilicemos Memcache deberemos decirle donde esta y donde encontrara los carbon-query para hacer peticiones de datos, en nuestro esquema se encuentran en la misma máquina.

Esta configuración es la misma para servidor 4

Y con eso ya tendremos el sistema montado, si todo salio bien, en el momento que le enviemos un métrica al Carbon-relay servidor 1 o 2 esta se repartirá entre los servidores 3 y 4

03 ago

LXC integrado con ZFS

Sin títuloNunca trabajé muy seriamente con lxc hasta ahora, total que estuve mirando para aprender sobre el tema y resulta que sacaron lxc 1.0.3, con un monton de cosas muy molonas, entre ellas la posibilidad de que se integre con sistemas de ficheros, desconozco si las versiones anteriores ya podían hacer, yo parto de la 1.0.3 y todo lo anterior esta obsoleto :).

Total que esta integración la tiene con bastantes sistemas, pero me pareció muy interesante dos de ellos btrfs (que también empece a trabajar con el y me parece muy interesante) y por supuesto zfs. Así que no hay mejor forma de entender que leer y después probar.

 

Este post me centrare en hacer trabajar lxc con zfs de forma celestial .

Pues venga al lío que se nos va el Domingo.

Instalación de LXC y ZFS

Primero de todo instalaremos lxc y zfs, la parte de zfs la podéis encontrar explicada en en Instalar OpenZFS en LINUX


[email protected]:~# apt-get install ubuntu-zfs lxc

En mi caso la máquina tiene un disco principal de 8GB y vamos añadir dos más de 10GB cada uno, para poder hacer raidz-1 con zfs, y allí es donde montaremos nuestros lxc,  lo haremos en dos partes, primero zfs.

Los discos que tenemos son los siguientes.

ZFS


Disk /dev/sdb: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdb doesn't contain a valid partition table

Disk /dev/sdc: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Haremos el pool con los dos de 10GB, sdb y sdc


[email protected]:~# zpool create -f containers raidz /dev/sdb /dev/sdc


[email protected]:~# df -h

containers      9.8G     0  9.8G   0% /containers

Pues ya tenemos el sitio donde meter los containers, ahora a por lxc

LXC

Primero de todo tenemos que decirle a lxc que coloque los containers en el pool de zfs, lo haremos con dos directivas en el fichero

vim /etc/lxc/lxc.conf

lxc.lxcpath = /containers/lxc
lxc.bdev.zfs.root = /containers/lxc

lxc.lxcpath -> Path donde estarán todos los container

lxc.bdev.zfs.root -> Nombre por defecto del zfs root

Deberemos crear el directorio lxc dentro del pool containers,  sino mal asunto.


[email protected]:~# zfs create containers/lxc

[email protected]:~# df -h

containers             9.8G 128K 9.8G  1%     /containers
containers/lxc    9.8G 128K 9.8G  1%    /containers/lxc

Y con esto ya tenemos el entorno montado, ahora es el momento de probar!

LXC más ZFS

Vamos a crear un container de forma normal, pero le daremos la opción -B zfs, es el valor predeterminado del directorio, pero si asignamos zfs o btrfs o lvm, lo que nos debería hacer es que el sistema de ficheros sea zfs y nos generara un nuevo volumen por contenedor y –zfsroot donde le diremos donde esta el container.


[email protected]:~# lxc-create -t ubuntu -n test -B zfs --zfsroot containers/lxc

Como es el primer container, esta descargando la imagen y eso lleva un ratillo… una vez termine nos dice este mensaje que es muy interesante y útil.


##
# The default user is 'ubuntu' with password 'ubuntu'!
# Use the 'sudo' command to run tasks as root in the container.
##

Pues vamos a ver como quedo la situación


[email protected]:~# zfs list
NAME                 USED AVAIL REFER MOUNTPOINT
containers           318M 9.47G 31K /containers
containers/lxc       318M  9.47G 34K /containers/lxc
containers/lxc/test  318M 9.47G 318M /containers/lxc/test/rootfs

Ahí lo tenemos test esta listo para arrancar, no la hagamos esperar mas.


lxc-start --name test

Y ya tenemos el tema andando, ahora por último lo que vamos hacer es sacarle un poco de jugo al zfs, que para eso lo hemos montado, vamos a jugar con la compresión, deduplicacion y snapshots.

Tenemos más detalle de los mismos en post anteriores, así que aquí vamos a ir al lío directamente.

Deduplicacion y compresion

Snapshots

Compresion, deduplicacion y snapshots


zfs set dedup=on containers

zfs set compression=lz4 containers

zpool set listsnapshots=on containers

La compresión en lz4 que es lo que se lleva ahora ;).

Comprobamos que este todo activado.


[email protected]:~# zfs get compression
NAME                PROPERTY    VALUE SOURCE
containers          compression lz4   local
containers/lxc      compression lz4   inherited from containers
containers/lxc/test compression lz4   inherited from containers
[email protected]:~# zfs get dedup
NAME                 PROPERTY VALUE SOURCE
containers           dedup on local
containers/lxc       dedup on inherited from containers
containers/lxc/test  dedup on inherited from containers

Pues venga a jugar!!!

Vamos a crear otro container a ver como se comporta la deduplicacion y la compresion.


lxc-create -t ubuntu -n test2 -B zfs --zfsroot containers/lxc

Una vez creado si comprobamos nos llevaremos una sorpresa


[email protected]:~# zfs get compressratio

containers/lxc/test compressratio 1.00x -
containers/lxc/test2 compressratio 2.10x -


[email protected]:~# zpool list

containers 19.9G 947M 19.0G 4% 1.01x ONLINE -

Uno de los containers esta comprimido pero el otro no, y aún por encima no aplico nada de deduplicacion :(, esto es sencillamente porque hemos aplicado esas características después de crear “test”, así que hay que tenerlo en cuenta.

Vamos hacer un snapshot y crear un nuevo container, ahí si que veremos que la deduplicacion surge efecto.

Creamos el snapshot.


[email protected]:~# zfs snapshot [email protected]
[email protected]:~# zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
[email protected] 0 - 31K -

Creamos test3


lxc-create -t ubuntu -n test3 -B zfs --zfsroot containers/lxc

Y comprobamos


[email protected]:~# zpool list
containers 19.9G 962M 18.9G 4% 2.02x ONLINE -

Ahora si, tenemos test2 y test3 ocupando como si solo fuera 1 a más a más como están comprimidos el tamaño es inferior respecto test1


containers/lxc/test  319M  4% /containers/lxc/test/rootfs
containers/lxc/test2 153M  2% /containers/lxc/test2/rootfs

Por ultimo los snapshots, como habeis visto hemos realizado un snapshot con zfs, pues otra de las cosas molonas que trae esta version de lxc es que puede controlar los snapshots de zfs, btrfs, lo podemos comprobar haciendo.

[email protected]:~# lxc-snapshot -n test3 -L
snap0 (/containers/lxcsnaps/test3) 2014:08:02 04:53:18
snap1 (/containers/lxcsnaps/test3) 2014:08:02 04:53:33

Ahí los tenemos :)

Podemos crear snapshot de zfs directamente de lxc en un container especifico.


[email protected]:~# lxc-snapshot -n test2
could not find any snapshots to destroy; check snapshot names.

[email protected]:~# zfs list -t snapshot -o name,creation
NAME CREATION
[email protected] Sat Aug 2 4:58 2014

Lo lanzamos con lxc y lo comprobamos con zfs, al revés que en el caso anterior, parece que si que se entienden(que era el objetivo del post :) )

Pues ya tenemos el sistema montado…

Ale a desfrutarlo!

08 ene

Gestión de Snapshots con OpenZFS

Dentro de la sorpresa y la emoción de OpenZFS, voy a explicar cómo funcionan los snapshots y los clones de ZFS, es un post continuación del Instalar OpenZFS en Linux, y complemento de los anteriores:

  1. Comandos zpool
  2. Optimización de ZFS
  3. Tipos de caches en ZFS

Situación

  • Un pool con dos discos, en nuestro caso en RAID 0 a lo loco.
[email protected]:~# df -h
other                          9,8G      0  9,8G   0% /other
[email protected]:~# zpool iostat -v 2
other        748K  9,94G      0      0      0      0
sdf1       448K  4,97G      0      0      0      0
sde1       301K  4,97G      0      0      0      0

Actualmente en ese recurso no tenemos nada, así que vamos a hacer diferentes snapshots para ver claramente el concepto.

Creación de snapshots

Vamos a crear un snapshot con el nombre snap1, del pool other, pensar que donde ponemos poner snap1 puede ser el día de la semana o el mes o algo más descriptivo

[email protected]:/storage# zfs snapshot [email protected]

Ahora podemos verlo listando, para ver todos los que tenemos en cualquier pool, haremos

zfs list -t snapshot

Para ver únicamente los de nuestro pool, haremos

[email protected]:/storage# zfs list -r -t snapshot -o name,creation other
NAME         CREATION
[email protected] lun dic  9 15:56 2013

Ya tenemos un snapshot, lo que nos puedo interesar hacer es ver que diferencias tenemos entre el snapshot y la situación actual.

[email protected]:/storage# zfs diff -FHt [email protected]
[email protected]:/storage#

Como es lógico no nos sale nada, pues vamos a cambiar cosas para que esto se nos mueva un poco.

Vamos a hacer, por ejemplo, la creación de ficheros, en ese pool

while (true); do; /other/file.$RANDOM; sleep 1; done

Lo dejamos un rato y volvemos mirar las diferencias, donde ahora si que veremos cosas.

[email protected]:/other# zfs diff -FHt [email protected]
1386601533.500608604    M       /       /other/
1386601529.484608700    +       F       /other/file.18132
1386601530.488608676    +       F       /other/file.15910
1386601531.488608652    +       F       /other/file.18620
1386601532.492608628    +       F       /other/file.14556
1386601533.500608604    +       F       /other/file.799

Donde podemos ver como nos dice que todos esos “file” están en el disco “+” y no en el snapshot.

Ahora vamos a hacer otro snapshot y después eliminaremos uno de los ficheros y veremos lo que nos dice.

[email protected]:/storage# zfs snapshot [email protected]
[email protected]:rm -rf /other/file.14556

 

[email protected]:/other# zfs diff -FHt [email protected]
1386601765.588603052    M       /       /other/
1386601532.492608628    -       F       /other/file.14556

Y como es lógico (menos mal) nos enseña el fichero que hemos borrado, y nos dice que ese fichero no existe en el snap2.

Comprobamos que supone hacer un snapshot cuando el sistema tiene bastante carga, y lo hacemos con un dd y ¡un gif súper chulo!
snap
El snapshot tarda un poco más, pero no se corta el dd ni baja significativamente el rendimiento.

Pues ahora que tenemos 3-4 snapshot vamos a jugar como ellos.

Rolling back

Aquí tenemos que tener claro que por ejemplo en nuestro caso tenemos 4 snapshots, su volvemos por ejemplo al 2, no podemos volver ni al 3 ni al 4 y estos los perderemos, pongamosnos en la situación que queremos recuperar el fichero file.14556, que borramos unos pasos más atrás.

[email protected]:/other# zfs diff -FHt [email protected]
1386602119.328594591    M       /       /other/
1386601532.492608628    -       F       /other/file.14556
1386602227.756591997    +       F       /other/prueba3.dd
[email protected]:/other# zfs diff -FHt [email protected]
1386602227.756591997    M       F       /other/prueba3.dd
[email protected]:/other# zfs diff -FHt [email protected]
1386602119.328594591    M       /       /other/
1386601532.492608628    -       F       /other/file.14556
1386602227.756591997    +       F       /other/prueba3.dd
[email protected]:/other# ll /other/file.14556
ls: no se puede acceder a /other/file.14556: No existe el archivo o el directorio
[email protected]:/other#

ROLLBACK!!!

[email protected]:/other# zfs rollback -r [email protected]
[email protected]:/other# ll /other/file.14556
-rw-r--r-- 1 root root 0 dic  9 16:05 /other/file.14556
[email protected]:/other#

Pues ahí lo tenemos, ¿Cuál es el problema? Pues muy claro que hemos perdido también todos los cambios que hemos hecho desde el snap2 hacia adelante, e incluso nuestro querido prueba3.dd, entonces lo que esta claro es que tenemos que tener alguna forma de recuperar ese fichero sin perder el resto… pues lo explico más abajo, no nos desviemos!

Vamos a eliminar el snap1 que no nos sirve para nada

Eliminación de Snapshots

[email protected]:/other# zfs list -r -t snapshot -o name,creation other
NAME         CREATION
[email protected] lun dic  9 15:56 2013
[email protected] lun dic  9 16:07 2013
[email protected]:/other# zfs destroy [email protected]
[email protected]:/other# zfs list -r -t snapshot -o name,creation other
NAME         CREATION
[email protected] lun dic  9 16:07 2013

Y ya esta solo queda 1…

Ahora pongamosnos en la situación que tenemos un snapshot del sábado que no queremos borrar bajo ningún concepto, pues lo que podremos hacer es bloquear el snapshot, de la siguiente forma!

[email protected]:/other# zfs snapshot [email protected]
[email protected]:/other# zfs hold noborrar [email protected]
[email protected]:/other# zfs destroy [email protected]
cannot destroy snapshots in [email protected]: dataset is busy
[email protected]:/other# zfs release noborrar [email protected]
[email protected]:/other# zfs destroy [email protected]
[email protected]:/other#

Con la opción hold ponemos un tag (noborrar) en el snapshot, de esta manera evitamos que pueda ser borrado, si nos fijamos cuando intentamos lanzar el destroy nos da un error “cannot destroy snapshots in [email protected]: dataset is busy”, para liberarlo deberemos lanzar el comando release y después el destroy.

También podemos ver la lista de tags con el comando zfs holds

[email protected]:/other# zfs holds [email protected]
NAME         TAG       TIMESTAMP
[email protected] noborrar  lun dic  9 17:48 2013

Clones

Bueno volvemos al caso anterior donde hemos hecho la restauración de un snapshot y por consiguiente hemos perdió los cambias desde el snapshot hasta el momento actual, ¿Cómo evitaremos esto? pues con los clones!!

Vamos a ver un ejemplo:

Tenemos el recurso other, el cual vamos a crear ficheros y haremos un snapshot, después creamos más ficheros e intentamos recuperar el primer snapshot sin perder los datos hasta el momento actual.

Utilizamos el mismo while que hemos utilizado antes.

  while (true); do   ; /other/file.$RANDOM   ; sleep 1; done  

Vamos a listar los ficheros que no tenemos snapshot clone1, respecto a la base, para así saber que es lo que vamos a recuperar.

Imaginemos que queremos recuperar el fichero file.3984, que no esta en la lista, bueno pues vamos a “montar” el clone en una directorio, para poder acceder a los ficheros.

zfs clone [email protected] [email protected]:/other/clone1#
ls -la /other/clone1/file.3984
-rw-r--r-- 1 root root 0 dic 17 10:41 /other/clone1/file.3984

Y ahí lo tenemos, en un directorio a parte, podemos ver que tenemos un nuevo recurso montado con la carpeta clone1.

[email protected]:/other/clone1# df -h | grep clone1
other/clone1                   9,8G      0  9,8G   0% /other/clone1

Una vez terminado de recuperar los datos pues eliminamos el clone…

zfs destroy other/clone1

Vamos a poner otro ejemplo, pensemos que hemos estado trabajando con el clone1 y ahora se convirtió en importante y queremos empezar a utilizarlo como sustitución del recurso actual, o sea, queremos promocionarlo.

Promocionar clone

Vamos a cambiar el escenario, vamos hacerlo con números para que se entienda bien, o sea, “uno” sera el recurso de producción, “dos” el clone restaurado y “tres” el rename de “uno”

Creamos un nuevo recurso

[email protected]:~# zfs create other/uno

Realizamos el snapshot con el que trabajaremos y lo promocionaremos

[email protected]:~# zfs snapshot [email protected][email protected][email protected][email protected]                         

Ahora lo montamos en un directorio llamado dos

[email protected]:~# zfs clone [email protected] other/dos

Y lo promocionamos.

[email protected]:~# zfs promote other/dos

De la forma más lógica cambiamos el nombre recurso uno a tres, para poder liberar el nombre de uno y ponérselo al dos, que actualmente es nuestra copia.

[email protected]:~# zfs rename other/uno other/tres

Y con esto ya tenemos restaurado la versión del recurso que nos interesaba

[email protected]:~# zfs rename other/dos other/uno

Pues con esto ya podemos empezar a jugar con los snapshot de openZFS

23 dic

Resizing an Online Multipath Device

Vamos a ampliar una disco conectado por FC a una cabina, de tal manera que deberemos rehacer la particion o disco del servidor para disfrutar del nuevo tamaño, lo haremos sin reiniciar el servidor.

Situación inicial

Lun presentada desde una cabina NetAPP por FC.

Montada en un RedHat con multipath, 4 paths

MySQL_Slave1 (360a980006470484f576f737278463034)
dm-0 NETAPP,LUN [size=120G][features=1 queue_if_no_path][hwhandler=0][rw]
_ round-robin 0 [prio=50][active] _ 5:0:1:0 sdc 8:32  [active][ready]
_ round-robin 0 [prio=50][enabled] _ 6:0:1:0 sde 8:64  [active][ready]
_ round-robin 0 [prio=10][enabled] _ 5:0:0:0 sdb 8:16  [active][ready]
_ round-robin 0 [prio=10][enabled] _ 6:0:0:0 sdd 8:48  [active][ready]

Tamaño inicial

/dev/mapper/MySQL_Slave1 119G   92G   21G  82% /mnt/mysql55-slave1

Resizing an Online Multipath Device without partition

Una vez que hemos aumentado la LUN desde el servidor

Vamos a comprobar que el servidor detecta el nuevo tamaño, para ello hacemos un rescan de los discos.

echo '- - -' &gt; /sys/class/scsi_host/host5/rescan
multipathd -ll  MySQL_Slave1 (360a980006470484f576f737278463034)
dm-0 NETAPP,LUN [size=201G][features=1 queue_if_no_path][hwhandler=0][rw] _ round-robin 0 [prio=50][active]
_ 5:0:1:0 sdc 8:32  [active][ready] _ round-robin 0 [prio=50][enabled] _ 6:0:1:0 sde 8:64  [active][ready]
_ round-robin 0 [prio=10][enabled] _ 5:0:0:0 sdb 8:16  [active][ready] _ round-robin 0 [prio=10][enabled]
_ 6:0:0:0 sdd 8:48  [active][ready]

Desmontamos la unidad en el caso que la tengamos montada, en el caso de que no este montada o sea desmontada ya no hace falta que la desmontemos :)

Haremos el primer resize a través del multipath tal que así:

multipathd -k'resize map MySQL_Slave1' ok

Y ahora rápidamente un resize molón del disco, como esta lun no tiene particiones lo haremos directamente, contando que si es ext2 o ext3 utilizaremos resize2fs y si es ext4 como en nuestro caso, utilizaremos resize4fs

e4fsck /dev/mapper/MySQL_Slave1 resize4fs /dev/mapper/MySQL_Slave1

Comprobamos

/dev/mapper/MySQL_Slave1  198G 92G 96G 49% /mnt/mysql55-slave1

Resizing an Online Multipath Device with partition

La situación ahora es que tenemos un disco conectado a una cabina por FC, pero esta vez el disco que ve el sistema tiene un partición, en este caso el método es un poco distinto.

La primera parte igual, ampliamos la LUN en la cabina y hacemos el rescan en el sistema.

echo '- - -' &gt; /sys/class/scsi_host/host5/rescan
multipath -ll MySQL_Master (360a980006470484f576f74346e446e56)&amp;amp;lt;strong&amp;amp;gt; dm-0
NETAPP,LUN [size=200G][features=1 queue_if_no_path][hwhandler=0][rw]
_ round-robin 0 [prio=50][active]  _ 5:0:1:0 sde 8:64  [active][ready]
_ round-robin 0 [prio=50][enabled]  _ 6:0:1:0 sdk 8:160 [active][ready]
_ round-robin 0 [prio=10][enabled]  _ 5:0:0:0 sdb 8:16  [active][ready]
_ round-robin 0 [prio=10][enabled]  _ 6:0:0:0 sdh 8:112 [active][ready]

El disco que vemos es el dm-0, vemos con un fdisk -l que tiene una partición que es la que queremos ampliar.

Disk /dev/dm-0: 200 GB,
214749413376 bytes 255 heads, 63 sectors/track, 26108 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot      Start         End      Blocks   Id
System /dev/dm-0p1               1       xxxxx   xxxxxx+

Pues ahora que lo tenemos todo localizado vamos a ampliar la partición, desmontamos primero. y lo que haremos es eliminar la partición actual y volverla a crear, pero esta vez veremos que el end de la partición es superior, ya que el tamaño es superior, la practica es tal que así.

umount /dev/dm-0p1
fdisk -u /dev/sdc &amp;amp;lt; d [Enter] n [Enter] p [Enter] 1 [Enter] w [Enter]
d = delete
n = new
p = primary
1 = la primera
fsck -f /dev/dm-0p1
resize2fs /dev/dm-0p1

Cuando termine ya tendremos la nueva partición con el tamaño deseado, por ultimo le diremos al sistema que vuelva a escanear la tabla de particiones.

partprobe -s /dev/dm-0

Y con esto ya tenemos el disco ampliado sin necesidad de reiniciar.

Fuentes

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/DM_Multipath/MPIO_admin-troubleshoot.html

http://www.redhat.com/advice/tips/rhce/partprobe.html

09 dic

Instalar OpenZFS en LINUX

20131209-084324.jpgParece ser que tenemos una versión estable de openZFS, así que como es un tema que me gusta bastante, pues os voy a explicar como instalarlo en Linux y comprobar su funcionamiento, si queréis saber cosas mas a fondo de ZFS, pues pasaros por los artículos anteriores:

  1. Tipos de caches en ZFS
  2. Comandos zpool
  3. Optimización de ZFS

Situación

  1. Esta disponible para los kernels Linux 2.6.26 – 3.11.
  2. No se recomienda instalarlo en sistemas de 32bits
  3. Mínimo 2GB de RAM, si queréis utilizar deduplicacion o compresión, bueno entonces pensar en poner una cuanta más.. os podéis hacer a la idea en los post que comento mas arriba.

Por qué sale OpenZFS?

  1. Oracle registró el nombre ZFS como marca comercial complicando su uso (MAL)
  2. Sale OpenZFS como proyecto “protesta” open source del proyecto ZFS de SUN, por los problemas con Oracle. (BIEN)
  3. Uno de los lideres es Matt Ahrens, co-fundador del proyecto ZFS (BIEN)
  4. La idea es unificar el desarrollo en FreeBSD, Linux, Mac OS X, and illumos (BIEN)
  5. 3 BIEN – 1 MAL así que vamos a explicarlo.

Nosotros lo vamos a montar en un Ubuntu server 13.10.

Creación

Primero de todo añadiremos los el ppa para bajarnos los paquetes:

sudo add-apt-repository ppa:zfs-native/stable

Deberemos instalar lo siguiente

apt-get install zfs-dkms parted mountall spl-dkms spl ubuntu-zfs zfsutils

Una vez finalice hacemos un reboot y listos ya tenemos zfs en linux (sin fuse)

Ahora que lo tenemos vamos a probar algunas de las cosas que dicen que hace…. :)

Creación de RAID Z

Añadir un par de discos y montamos, por ejemplo un Raid Z mirror


Disco /dev/sdb: 8589 MB, 8589934592 bytes
Disco /dev/sdc: 8589 MB, 8589934592 bytes

 

[email protected]:~# zpool create -f storage raidz /dev/sdb /dev/sdc
[email protected]:~# df -h

S.ficheros Tamaño Usados Disp Uso% Montado en
storage 7,9G 0 7,9G 0% /storage

Como bien sabemos así  de sencillo se crea un RAID, si queréis algo mas complejo, pues lo dicho a los post anteriores.

Forzar un error de disco

Ahora lo que vamos a probar es quitar un disco mientras escribimos en el otro…  hice un gif para que se vea que no se pierde escritura.
En el gif podéis ver 4 pantallas que os explico en la siguiente imagen.

teste mirror 1
Y en el gif, el casque

mirror1_fail

En el recuadro de abajo a la izquierda vemos como se esta lanzando un dd, vemos la tasa de escritura en el de la derecha, y arriba como quitamos el disco del pool lo añadimos y empezamos a ver como se resincroniza, para cubrirnos un poco ante un fallo de disco, podemos añadir otro en spare

Añadir disco en SPARE

zpool add -f storage spare /dev/sdd

diskspare

Fallo de disco, con un disco spare

Por defecto, el spare entra en funcionamiento automáticamente en el caso que tener un fallo de uno de los dos del mirror, pero como no puedo quitar el disco a lo burro, pues vamos hacer la emulación, a más que así también aprendemos como se hace manualmente, que ha veces lo automático deja de ser lo.

  • Ponemos uno de los discos del mirror en offline.
zpool offline storage sdc

fail online disk

Ahora de forma manual le vamos a decir que remplace el disco “roto” por el spare.

  • Remplazo del disco por el spare.
 zpool replace storage sdc sd

Y veremos
remplazo

Si nos fijamos en el disco sdd a pasado a estar dentro del pool y estado ONLINE, esto que quiere decir, pues que aun que tengamos el sdc OFFLINE, el sdd ya esta recibiendo peticiones y forma parte del RAID

Aquí se ve claramente

spareonlineEn este punto tenemos dos caminos o volvemos a poner el disco sdc ONLINE o lo eliminamos, de tal manera que el sdd pasara a formar parte de el pool en la misma situación que el sdc cuando funcionaba, pues probamos los dos casos!

  • Ponemos el sdc en ONLINE
zpool online storage sdc

Ahora lo que pasará es que tendremos el sdc y el sdd como discos spare asociados a ese pool, pero estando los 3 activos, si nos fijamos hemos pasado de tener un disco spare disponible a activo, cuando este esta activo queda asociado al pool en el cual empezó a trabajar, cuando nosotros hicimos el replace lo asociamos al pool de storage, entonces cuando ponemos el sdc ONLINE, lo que tendremos es lo siguiente.

todoonlineFijaros como el sdc paso a estar en uso, en la imagen anterior cuando lo añadimos estaba en disponible.

todoonline

Ahora hacemos escrituras veremos como los 3 están escribiendo.

todosescribiendoPERO! Cuantos utilizaremos si leemos?

Pues dos, los dos que están activos realmente, para atender a todas las peticiones.
lectura

  • Dejar todo como estaba

Vale, bueno ahora lo que nos interesa es volver a dejar un disco en spare, disponible para todos los pools que tengamos, el sdd como nuevo disco dentro del raidz, o sea todo tal y como estaba, la verdad es que no se si es la mejor forma, pero no encontré otra mejor… tendremos que  ponerlo offline y hacer el detach

zpool offline storage sdc
zpool detach storage sdc

Y todo volverá a la normalidad, pero teniendo el RAID montado con el sdb y el sdd en vez de con el sdb y el sdc, que este ahora será spare disponible para todos los pools

normalidad

Si llegados a este punto estamos convencidos de que vamos a utilziar zfs, pues lo que nos gustará hacer es que cuando arranque nos monte el pool. para eso deberemos hacer dos cosas:

Editar

vim /etc/default/zfs

ZFS_MOUNT='yes'

ZFS_UNMOUNT='yes'

Y os preguntareis que linea hay que meter en el fstab?, pues ninguna ya que el demonio zfs se encarga de montar el pool que tenemos configurado al arrancar, esto lo hace partiendo de la información del fichero zpool.cache (fichero importante) y se crea cuando creamos el pool o podemos recrearlo con el siguiente comando.

zpool set cachefile=/etc/zfs/zpool cache pool

Si en algún momento queremos montar o desmontar el pool nosotros mismos, es tan sencillo como hacer

zfs mount pool
zfs umont pool
14 nov

IPtables bloqueos de ataques

Esta vez vamos hacer un post tirando más a bloc de notas (el segundo después del de los certificados, igual ya es la edad), ya que si hemos trabajado con iptables, las reglas que vamos a comentar están al orden del día.

Las explicaciones están basadas en una debian, la idea principal es añadir algunas reglas por defecto que nos permitan proteger nuestro sistemas ante algunos tipos de ataques, por ejemplo DDOS o Pings de la muerte!, no son la panacea, pero algo hacen.

Lo primero que voy hacer es intentar protegerme, para que en el caso que se nos vaya la mano (algo que suele pasar) con alguna regla, pues no nos quedemos sin acceso a la máquina, así en mi caso como estoy conectado por ssh,  lo que voy hacer es controlar que mi usuario este conectado y en el caso que se desconecte, pues borramos todas las reglas y santas pascuas. Seria algo tan sencillo como

#!/bin/bash
USUARIO=Nombre
who | grep ${USUARIO}

if [ $? -ne 0 ]; then
  echo &quot;Stopping firewall and allowing everyone...&quot;
  iptables -F
  iptables -X
  iptables -t nat -F
  iptables -t nat -X
  iptables -t mangle -F
  iptables -t mangle -X
  iptables -P INPUT ACCEPT
  iptables -P FORWARD ACCEPT
  iptables -P OUTPUT ACCEPT
exit 1
fi

Y lo podemos ejecutar cuando empecemos, por ejemplo con un while, tal que así.


while true ;do /bin/bash script.sh &amp;&amp; sleep 10; done

Bueno pues ahora vamos a mirar las reglas que podemos ir poniendo y las vamos a ir explicando, así si se entiende pues cada cual puede utilizarlas como mejor le vaya.

Vamos a utilizar muy mucho -m recent, básicamente los que nos permite hacer es crear un fichero temporal donde vamos almacenar las ips que cumplan los patrones del ataque, de esta manera podremos comprobar el numero de veces que una ip esta intentando acceder a nuestro sistema. También vamos hacer uso del -N, pongamos, por ejemplo que queremos logar (que va a ser el caso) aquellas peticiones que cumplan nuestras reglas, en este caso tendremos que realizar dos reglas, la primera para logar y la segunda para hacer el DROP. Por ejemplo,

iptables -A INPUT -s 10.0.0.0/8 -j LOG --log-level 4 -log-prefix 'SourceDrop '
iptables -A INPUT -s 10.0.0.0/8 -j DROP

Esto si tenemos unas cuantas reglas en un rollo bastante grande, así que para mejorar lo que haremos es utilizar chains, como funcionan? pues muy fácil, creamos un chail tal que así

iptables -N LOGandDROP

Con la opcion -A lo que vamos hacer es añadir las reglas que queremos que tenga el chail.

iptables -A LOGandDROP -j LOG --log-level 6 --log-prefix 'IPDROP '
iptables -A LOGandDROP -j DROP

Y ahora si queremos volver a crear la regla de antes lo que haremos es

iptables -A INPUT -s 10.0.0.0/8 -j LOGandDROP

Nos ahorramos como el 50% de las reglas…. en este caso. Vamos al lío.

Control de los accesos al puerto 22, uno de los puertos que solemos tener abiertos es el 22 así que vamos a montar unas reglas para que en el caso que detectemos muchos accesos en un periodo de tiempo, pues los bloqueemos, esta va a ser bien bien la base de la mayoría de reglas. Vamos hacer un chain que se llame SSH, para ser originales

iptables -N SSH
iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j SSH
iptables -A SSH -m recent --set --name SSH --rsource
iptables -A SSH -m recent --update --seconds 30 --hitcount 5 --name SSH --rsource -j LOG --log-prefix &quot;Firewall SSH-Bruteforce: &quot; --log-level 6
iptables -A SSH -m recent --update --seconds 30 --hitcount 5 --name SSH --rsource -j DROP

Donde

–name es el nombre de la “clase” que defines ,

–rsource que se mantenga en la lista utilizando la ip remota

–rcheck mirar si la ip esta en la lista

update si esta en la lista hace una actualización del timestamp

–seconds numero de segundos para rastrear la dirección

hitcount numero de peticiones que aceptamos en el numero de segundo que definimos.

En este ejemplo que tenemos? muy fácil tenemos primero la regla de INPUT donde le decimos que si se cumple lo que tiene que haces es ir al chai SSH, o sea que si la petición vienen al 22 aplicara las reglas de chai SSH, y que hacen estas reglas? Pues si la ip que hace la petición al puerto 22 no hizo mas de 5 hits en el tiempo en segundo que hemos dicho hará el accept, en caso contrario pues DROP que te crió!.

Esto lo podemos hacer para todos los puertos que nos interese o para rangos, grupos etc Ahora vamos a mirar de protegernos del scanner de puertos.

Aplicaremos las siguientes reglas y las explicamos.

Paquetes mal formados o vacíos

En la primera lo que estamos haciendo es decirle que todas las peticiones entrantes sin –tcp-flags(SYN, ACK, FIN, RST, URG, PSH) que haga más de 3 por minuto y con un pico máximo de 5 se envíen al log


iptables -A INPUT -p tcp --tcp-flags ALL NONE -m limit --limit 3/m --limit-burst 5 -j LOG --log-prefix &quot;Firewall Scan Ports &quot;

En la siguiente lo que hacemos es decirle que aquellas ip que estén en la blacklist que se bloqueen durante 60 segundos.


iptables -A INPUT -p tcp --tcp-flags ALL NONE -m recent --name blacklist_60 --set -m comment --comment &quot;Drop/Blacklist ip Scan Ports&quot; -j DROP

Mas cosas.

TCP-reset

Lo que sale en el gif que me encontré que lo explica muy bien. http://i29.tinypic.com/103ybo8.jpg


iptables -N tcp-reset
iptables -A tcp-reset -m limit --limit 3/second --limit-burst 8 -j LOG --log-prefix &quot;Firewall tcp-reset &quot; --log-level 6
iptables -A tcp-reset -p tcp -j REJECT --reject-with tcp-reset
iptables -A tcp-reset -j REJECT

ICMP- control

iptables -N ICMP
iptables -A ICMP -p icmp -m limit --limit 1/s --limit-burst 2 -j LOG --log-prefix &quot;Firewall PING-DROP&quot; --log-level 6
iptables -A ICMP -p icmp -m limit --limit 1/s --limit-burst 2 -j DROP

syn-flood –> Denial-of -service

iptables -N syn-flood
iptables -A syn-flood -m limit --limit 50/second --limit-burst 100 -j LOG --log-prefix &quot;Firewall syn-flood &quot;
iptables -A syn-flood -j DROP

Paquetes mal formados.


iptables -N PKT_FAKE
iptables -A PKT_FAKE -m state --state INVALID -j DROP
iptables -A PKT_FAKE -p tcp --dport 80 --tcp-flags ALL ACK,RST,SYN,FIN -j LOG --log-prefix &quot;Firewall PKT_FAKE &quot;
iptables -A PKT_FAKE -p tcp --dport 80 --tcp-flags SYN,FIN SYN,FIN -j LOG --log-prefix &quot;Firewall PKT_FAKE &quot;
iptables -A PKT_FAKE -p tcp --dport 80 --tcp-flags SYN,RST SYN,RST -j LOG --log-prefix &quot;Firewall PKT_FAKE &quot;
iptables -A PKT_FAKE -p tcp --dport 80 ! --syn -m state --state NEW -j LOG --log-prefix &quot;Firewall PKT_FAKE &quot;
iptables -A PKT_FAKE -f -j LOG --log-prefix &quot;Firewall PKT_FAKE &quot;
iptables -A PKT_FAKE -j RETURN

Drop lista de ips IANA


iptables -A INPUT -s 0.0.0.0/7 -j DROP
iptables -A INPUT -s 2.0.0.0/8 -j DROP
iptables -A INPUT -s 5.0.0.0/8 -j DROP
iptables -A INPUT -s 7.0.0.0/8 -j DROP
iptables -A INPUT -s 10.0.0.0/8 -j DROP
iptables -A INPUT -s 23.0.0.0/8 -j DROP
iptables -A INPUT -s 27.0.0.0/8 -j DROP
iptables -A INPUT -s 31.0.0.0/8 -j DROP
iptables -A INPUT -s 36.0.0.0/7 -j DROP
iptables -A INPUT -s 39.0.0.0/8 -j DROP
iptables -A INPUT -s 42.0.0.0/8 -j DROP
iptables -A INPUT -s 49.0.0.0/8 -j DROP
iptables -A INPUT -s 50.0.0.0/8 -j DROP
iptables -A INPUT -s 77.0.0.0/8 -j DROP
iptables -A INPUT -s 78.0.0.0/7 -j DROP
iptables -A INPUT -s 92.0.0.0/6 -j DROP
iptables -A INPUT -s 96.0.0.0/4 -j DROP
iptables -A INPUT -s 112.0.0.0/5 -j DROP
iptables -A INPUT -s 120.0.0.0/8 -j DROP
iptables -A INPUT -s 169.254.0.0/16 -j DROP
iptables -A INPUT -s 172.16.0.0/12 -j DROP
iptables -A INPUT -s 173.0.0.0/8 -j DROP
iptables -A INPUT -s 174.0.0.0/7 -j DROP
iptables -A INPUT -s 176.0.0.0/5 -j DROP
iptables -A INPUT -s 184.0.0.0/6 -j DROP
iptables -A INPUT -s 192.0.2.0/24 -j DROP
iptables -A INPUT -s 197.0.0.0/8 -j DROP
iptables -A INPUT -s 198.18.0.0/15 -j DROP
iptables -A INPUT -s 223.0.0.0/8 -j DROP
iptables -A INPUT -s 224.0.0.0/3 -j DROP

Como le hemos dicho que nos envie los problemas al log lo que deberemos hacer es montar que iptables envie el log a un fichero, como? pues por el rsyslog, asi que vamos al lio.

Vamos a crear las carpetas donde vamos a dejar los logs, en mi caso los tengo en mnt así que haremos


mkdir -p /mnt/log/firewall
touch /mnt/log/firewall/iptables.log
chmod 600 /mnt/log/firewall/iptables.log
chown root:adm //mnt/log/firewall/iptables.log

Lo normal es que se envien los logs a rsyslog y sea este el que debamos configurar para que escriba en el log, la configuracion del rsyslog la coge por defecto del directorio /etc/rsyslog.d/, ahí debermeos crear el fichero de configuracion para el firewall, tal que asi.


vi /etc/rsyslog.d/firewall.conf

 


:msg, startswith, &quot;Firewall &quot; -/mnt/usb/firewall/iptables.log
&amp; ~

Vale ahora vamos a configurar el logrotate, para que vaya limpiando el log y no se nos haga infumable. creamos el fichero de configuracion en


vim /etc/logrotate.d/iptables.log

 


/mnt/usb/firewall/iptables.log
 {
 rotate 5
 daily
 size 10M
 dateext
 missingok
 create 600 root adm
 notifempty
 compress
 delaycompress
 postrotate
 invoke-rc.d rsyslog reload &gt; /dev/null
 endscript
 }

Reinicimos el servicio


/etc/init.d/rsyslog restart

Ahora podemos comprobar que funciona, haciendo una peticion nc al puerto 22. Y parasa esto.

while true; do nc -vz -w3 IP 22 &amp;&amp; sleep 2 ; done
Connection to ---------- 22 port [tcp/ssh] succeeded!
Connection to ---------- 22 port [tcp/ssh] succeeded!
Connection to ---------- 22 port [tcp/ssh] succeeded!
Connection to ---------- 22 port [tcp/ssh] succeeded!
nc: connect to ---------- port 22 (tcp) timed out: Operation now in progress
nc: connect to ---------- port 22 (tcp) timed out: Operation now in progress
nc: connect to ---------- port 22 (tcp) timed out: Operation now in progress
nc: connect to ---------- port 22 (tcp) timed out: Operation now in progress

Al cabo de 30 segundos sin recivir peticiones liberaremos la ip.

Resumen lista de reglas

iptables -N LOGandDROP
iptables -A LOGandDROP -j LOG --log-level 6 --log-prefix 'IPDROP '
iptables -A LOGandDROP -j DROP
iptables -N SSH
iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j SSH
iptables -A SSH -m recent --set --name SSH --rsource
iptables -A SSH -m recent --update --seconds 30 --hitcount 5 --name SSH --rsource -j LOG --log-prefix &quot;Firewall SSH-Bruteforce: &quot; --log-level 6
iptables -A SSH -m recent --update --seconds 30 --hitcount 5 --name SSH --rsource -j DROP
iptables -N HTTP
iptables -A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j HTTP
iptables -A HTTP -m recent --set --name HTTP --rsource
iptables -A HTTP -m recent --update --seconds 30 --hitcount 30 --name HTTP --rsource -j LOG --log-prefix &quot;Firewall HTTP-Bruteforce: &quot; --log-level 6
iptables -A HTTP -m recent --update --seconds 30 --hitcount 30 --name HTTP --rsource -j DROP
iptables -N HTTPS
iptables -A INPUT -p tcp -m tcp --dport 443 -m state --state NEW -j HTTPS
iptables -A HTTPS -m recent --set --name HTTPS --rsource
iptables -A HTTPS -m recent --update --seconds 30 --hitcount 30 --name HTTPS --rsource -j LOG --log-prefix &quot;Firewall HTTPS-Bruteforce: &quot; --log-level 6
iptables -A HTTPS -m recent --update --seconds 30 --hitcount 30 --name HTTPS --rsource -j DROP
iptables -N ICMP
iptables -A ICMP -p icmp -m limit --limit 1/s --limit-burst 2 -j LOG --log-prefix &quot;Firewall PING-DROP&quot; --log-level 6
iptables -A ICMP -p icmp -m limit --limit 1/s --limit-burst 2 -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -m limit --limit 3/m --limit-burst 5 -j LOG --log-prefix &quot;Firewall Scan Ports &quot;
iptables -A INPUT -p tcp --tcp-flags ALL NONE -m recent --name blacklist_60 --set -m comment --comment &quot;Drop/Blacklist ip Scan Ports&quot; -j DROP
iptables -N syn-flood
iptables -A syn-flood -m limit --limit 50/second --limit-burst 100 -j LOG--log-prefix &quot;Firewall syn-flood &quot;
iptables -A syn-flood -j DROP
iptables -N PKT_FAKE
iptables -A PKT_FAKE -m state --state INVALID -j DROP
iptables -A PKT_FAKE -p tcp --dport 80 --tcp-flags ALL ACK,RST,SYN,FIN -j LOG --log-prefix &quot;Firewall PKT_FAKE_80 &quot;
iptables -A PKT_FAKE -p tcp --dport 80 --tcp-flags SYN,FIN SYN,FIN -j LOG --log-prefix &quot;Firewall PKT_FAKE_80 &quot;
iptables -A PKT_FAKE -p tcp --dport 80 --tcp-flags SYN,RST SYN,RST -j LOG --log-prefix &quot;Firewall PKT_FAKE_80 &quot;
iptables -A PKT_FAKE -p tcp --dport 80 ! --syn -m state --state NEW -j LOG --log-prefix &quot;Firewall PKT_FAKE_80 &quot;
iptables -A PKT_FAKE -p tcp --dport 443 --tcp-flags ALL ACK,RST,SYN,FIN -j LOG --log-prefix &quot;Firewall PKT_FAKE_443 &quot;
iptables -A PKT_FAKE -p tcp --dport 443 --tcp-flags SYN,FIN SYN,FIN -j LOG --log-prefix &quot;Firewall PKT_FAKE_443 &quot;
iptables -A PKT_FAKE -p tcp --dport 443 --tcp-flags SYN,RST SYN,RST -j LOG --log-prefix &quot;Firewall PKT_FAKE_443 &quot;
iptables -A PKT_FAKE -p tcp --dport 443 ! --syn -m state --state NEW -j LOG --log-prefix &quot;Firewall PKT_FAKE_443 &quot;
iptables -A PKT_FAKE -f -j LOG --log-prefix &quot;Firewall PKT_FAKE &quot;
iptables -A PKT_FAKE -j RETURN
iptables -N tcp-reset
iptables -A tcp-reset -m limit --limit 3/second --limit-burst 8 -j LOG --log-prefix &quot;Firewall tcp-reset &quot; --log-level 6
iptables -A tcp-reset -p tcp -j REJECT --reject-with tcp-reset
iptables -A tcp-reset -j REJECT
iptables -A INPUT -s 0.0.0.0/7 -j DROP
iptables -A INPUT -s 2.0.0.0/8 -j DROP
iptables -A INPUT -s 5.0.0.0/8 -j DROP
iptables -A INPUT -s 7.0.0.0/8 -j DROP
iptables -A INPUT -s 10.0.0.0/8 -j DROP
iptables -A INPUT -s 23.0.0.0/8 -j DROP
iptables -A INPUT -s 27.0.0.0/8 -j DROP
iptables -A INPUT -s 31.0.0.0/8 -j DROP
iptables -A INPUT -s 36.0.0.0/7 -j DROP
iptables -A INPUT -s 39.0.0.0/8 -j DROP
iptables -A INPUT -s 42.0.0.0/8 -j DROP
iptables -A INPUT -s 49.0.0.0/8 -j DROP
iptables -A INPUT -s 50.0.0.0/8 -j DROP
iptables -A INPUT -s 77.0.0.0/8 -j DROP
iptables -A INPUT -s 78.0.0.0/7 -j DROP
iptables -A INPUT -s 92.0.0.0/6 -j DROP
iptables -A INPUT -s 96.0.0.0/4 -j DROP
iptables -A INPUT -s 112.0.0.0/5 -j DROP
iptables -A INPUT -s 120.0.0.0/8 -j DROP
iptables -A INPUT -s 169.254.0.0/16 -j DROP
iptables -A INPUT -s 172.16.0.0/12 -j DROP
iptables -A INPUT -s 173.0.0.0/8 -j DROP
iptables -A INPUT -s 174.0.0.0/7 -j DROP
iptables -A INPUT -s 176.0.0.0/5 -j DROP
iptables -A INPUT -s 184.0.0.0/6 -j DROP
iptables -A INPUT -s 192.0.2.0/24 -j DROP
iptables -A INPUT -s 197.0.0.0/8 -j DROP
iptables -A INPUT -s 198.18.0.0/15 -j DROP
iptables -A INPUT -s 223.0.0.0/8 -j DROP
iptables -A INPUT -s 224.0.0.0/3 -j DROP

Ahora para que siempre este disponible al reiniciar la maquina haremos.


#!/bin/bash
iptables-save &gt; /etc/firewall.conf
echo &quot;#!/bin/sh&quot; &gt; /etc/network/if-up.d/iptables
echo &quot;iptables-restore &lt; /etc/firewall.conf&quot; &gt;&gt; /etc/network/if-up.d/iptables
chmod +x /etc/network/if-up.d/iptables

Ale a difrturalo!

04 nov

Renovar certificado SSL con entidad certificadora

Este es claramente un post de recuerdo, una nota de algo que tarde o temprano nos toca hacer a todos y por norma general  cada vez que me toca siempre me paso un buen rato recordando como se hacia, hasta que monto la linea bendita para generar el CSR nuevo.

Así, que me la apunto aquí y así podéis disfrutarla vosotros también.

Vamos a generar la key y el CSR, siendo este ultimo el que tenemos que enviar a la entidad certificadora para que nos genere el nuevo certificado, que sera el que pondremos en apache, nginx o donde buenamente queramos.


openssl req -new -newkey rsa:2048 -nodes -out nombre.csr -keyout nombre.key -subj &quot;/C=ES/ST=Ciudad/L=Localidad/O=Organizacion/CN=urldelcertificado&quot;

Por ejemplo para un certificado tipo *.dominio.com


openssl req -new -newkey rsa:2048 -nodes -out nombre.csr -keyout nombre.key -subj &quot;/C=ES/ST=Barcelona/L=Barcelona/O=Umbrella Corporation SL/CN=*.umbrellacorporation.com&quot;

Esto nos genera un CSR y un key, como comento el CSR se lo enviamos a la entidad certificadora para que nos envíen el certificado.

Por último podemos comprobar que el csr se genero correctamente, con el siguiente comando.

openssl req -in nombre.csr -noout -text

Y veremos los datos del csr que hemos generado.

Algo tal que así:


Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=ES, ST=Barcelona, L=Barcelona, O=Umbrella Corporation SL, CN=*.umbrellacorportation.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
etc... etc