Here documents (<<), Here strings (<<<) y el comando "read"

22 Diciembre 2016 at 13:16 by Adrián Pérez

bash

< < (Here documents)

Un here document es un tipo de redirección que le dice al shell que vaya leyendo el input que se le está pasando hasta encontrar una determinada palabra clave ('TAG' en el ejemplo).

cat >> file << 'TAG'
primera línea
segunda línea
última línea
TAG

Consiste, pues, en un bloque de código cuyas líneas se pasan una a una a un comando o programa interactivo (como ftp o cat). Podemos usar cualquier TAG para indicar el final del bloque que compone el here document, pese a que se suele usar "EOF", pero podríamos usar cualquier cosa, mientras estemos seguros de que será una cadena de carácteres que no se usará dentro del bloque que queremos procesar.

Un posible uso es el de añadir un bloque de líneas a un fichero. Cabe decir que el here document incluirá los espacios/tabs de inicio de cada línea. Si no es lo que quieres, puedes eliminar los tabs de inicio de línea al procesar el here document añadiéndo un "-" justo tras la redirección y antes del tag (quedaría "< <-"). Aquí un ejemplo manteniendo tabs y usando variables dentro del bloque:

NOMBRE="$1"
cat >> file << EOF
Hola $NOMBRE
este es mi bloque de líneas
que guardaré en file
        esta línea tiene un tab 
  y esta dos espacios
EOF

Bash bang commands y más

15 Septiembre 2016 at 11:26 by Adrián Pérez

bash
A continuación una serie de comandos útiles en bash, que (por lo menos a mí) me viene bien tener a mano, razón por la cual seguramente este post se actualice varias veces a medida que vaya añadiéndo comandos útiles a mi día a día.

"$?": Exit code

"$?" Muestra el exit code del comando que se acaba de ejecutar.

[adri@localhost tmp]$ cat test 
#!/bin/bash
exit 0
[adri@localhost tmp]$ ./test 
[adri@localhost tmp]$ echo $?
0
[adri@localhost tmp]$ cat test 
#!/bin/bash
exit 1
[adri@localhost tmp]$ ./test 
[adri@localhost tmp]$ echo $?
1

Ésto se puede usar dentro de scripts en bash, para saber cómo ha acabado la línea anterior del script, lo cual puede resultar muy muy útil.

Docker: Gestión y Administración

11 Septiembre 2016 at 16:12 by Adrián Pérez

docker

Tenía pendiente ver el tercer vídeo de self-training que tiene Docker en su web. Como soy mucho de hacer resúmenes de aquello que me parece interesante (para interiorizar y poder volver a consultarlo más adelante), y ya que hice lo propio con la entrada "Introducción a Docker", con este tercer vídeo no podía hacer menos.

Container troubleshooting

Podemos ver la salida del proceso con PID 1 (correspondiente al "comando" pasado en el "docker run") con "docker logs".

docker logs [-f] <container_name>
</container_name>

Otra opción, es directamente mapear un directorio del host al directorio de logs de la aplicación que se corre en el container:

docker run -d -P -v /nginxlogs:/var/log/nginx nginx

Con "docker inspect" devolveremos todos los detalles del contendor en un json.

docker inspect <container_name>
</container_name>

En /etc/default/docker se define la variable DOCKER_OPTS, la cual controla las opciones de arranque cuando iniciamos docker como servicio. Por ejemplo, podremos cambiar el nivel de log por defecto especificándolo en DOCKER_OPTS mediante la opción "--log-level", la cual dejará los logs en /var/log/upstart/docker.log. Esta variable nos dará mucha flexibilidad.

Instalar JBoss AS7 en entornos Red Hat

24 Febrero 2015 at 19:54 by Adrián Pérez

JBoss_logoJBoss es un Servidor de Aplicaciones Java completo, de código abierto, desarrollado por Red Hat. Y sí, yo también pienso en Apache Tomcat en estos momentos, pero hay diferencias entre ellos explicadas por ejemplo aquí o aquí. Voy a copiar literalmente una respuesta de StackOverflow que explica la diferencia entre un Servlet Container como Tomcat y un Application Server como JBoss:

"A servlet-container supports only the servlet API (including JSP, JSTL).

An application server supports the whole JavaEE - EJB, JMS, CDI, JTA, the servlet API (including JSP, JSTL), etc.

It is possible to run most of the JavaEE technologies on a servlet-container, but you have to install a standalone implementation of the particular technology." por Bozho

Ahora que quizá tenemos algo más claro qué es JBoss y por qué este post no habla sobre Tomcat, faltará ver qué diferencias hay entre la versión de la comunidad y la enterprise (más info aquí). Como es de esperar, la versión de la comunidad siempre irá por delante respecto a la empresarial en cuanto a novedades y funcionalidades, con lo cual no estará tan testeada ni será tan estable como debería ser la versión empresarial, más pensada para alojar aplicaciones críticas.

En esta entrada se instalará y pondrá en marcha la versión de la comunidad.

Migrar de Apache/PHP a Nginx/PHP en CentOS

24 Febrero 2015 at 12:49 by Adrián Pérez

nginx2Si contamos con un servidor Apache, quizá nos interese pasarlo a nginx con el menor downtime posible. Yo he hecho alguna prueba partiendo del siguiente entorno:

  • CentOS release 6.6
  • Apache/2.2.15 sin módulos adicionales
  • VirtualHosts para un proyecto PHP 5.3.3

Lo que haremos con nginx es instalarlo y configurarlo de forma muy básica en un puerto diferente y posteriormente una vez esté todo bien, cambiar puertos de escucha.

ATENCIÓN: Si estás pensando en migrar de Apache a Nginx, en producción, ten en cuenta que dependiendo de tu entorno, deberás hacerlo de una u otra manera. No es lo mismo migrar un proyecto python que sirve Apache via mod_wsgi, que un proyecto PHP que ni si quiera usa mod_rewrite (como en este ejemplo). Este post, por tanto, te puede servir de punto de partida, pero no es la "guía definitiva".

Instalación de nginx

En primer lugar, deberemos crear el fichero para acceder al repositorio de nginx, pues éste no viene en los repositorios de CentOS.

[root@lab01 ~]# vi /etc/yum.repos.d/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

Tras configurar el repo, ya podremos instalar nginx via yum:

[root@lab01 ~]# yum install nginx

Algunos apuntes sobre Bash

12 Febrero 2015 at 16:41 by Adrián Pérez

bashHe querido recoger algunas notas de Bash scripting para no tener que correr a Google (o a cualquier página de StackExchange) cada vez que las dudas me asalten.

/usr/bin/env bash vs /usr/bin/bash

Leí en la siguiente página sobre las "mejores prácticas en Bash" acerca del uso de "#!/usr/bin/env bash" en lugar del habitual "#!/usr/bin/bash" o "#!/bin/bash". La idea es usar"#!/usr/bin/env bash" pues de esta manera lo que hacemos es buscar en el PATH dónde está bash, el cual es probable se encuentre en ubicaciones distintas en servidores diferentes. Ésto evitará problemas portando scripts a otros entornos. [Más info] [2]

#!/usr/bin/env bash

Corchete simple vs Doble corchete

Básicamente, ambos sirven para evaluar expresiones. "[" es un alias para el comando "test" y tanto uno como el otro están disponibles en el estándar POSIX. "[[" sin embargo es una keyword, no un programa, y se trata una versión mejorada para evaluar expresiones, únicamente disponible en Bash, KornShell y Zsh. Si no estás preocupado por la portabilidad de tus scripts con sistemas donde no cuentes con Bash, es mejor usar siempre el doble corchete, por la funcionalidad extra que aporta (posibilidad de usar && y ||, expresiones regulares, pattern matching, etc.). [Más info] [2]

La siguiente evaluación será "true" pues b és mayor que a, 8 mayor que 4, y abcd entra dentro del patrón "a*":

if [[ b > a && 8 -gt 4 && abcd = a* ]]; then ...

PD: Dejo un enlace a la wikipedia donde se especifican los nombres en inglés de éstos símbolos, según la zona.

Configuración inicial de un servidor CentOS

5 Febrero 2015 at 13:07 by Adrián Pérez

centosHace ya unos años, y sin ningún software de administración tipo Puppet/Chef/Ansible, creamos un documento para que todos los técnicos pudieran decir la suya respecto a los pasos a dar tras instalar un sistema operativo Linux (CentOS en nuestro caso), con tal de no olvidarnos ninguno e ir mejorando entre todos este proceso de configuración inicial de un servidor. Eso significa que si tú, amado lector, tienes cualquier sugerencia de mejora, no dudes en dejarla en los comentarios.

Hoy en día, ese documento, muy pensado para instalaciones CentOS 6, tanto en entornos Cloud Computing como para en máquinas propias, es algo parecido a lo que listo a continuació.

NOTA: No te tomes todos los puntos al pie de la letra, seguramente querrás valorar si lo que propongo a continuación tiene sentido en tu entorno antes de aplicarlo, y seguro que más de un punto es mejorable.

1. Actualización del SO

Tras la instalación, es una buena idea forzar un update para estar a la última de los paquetes de nuestro SO.

yum update

2. Deshabilitar selinux

Selinux es una herramienta útil, pero que no compensa, y proporciona más dolores de cabeza de los que pretende solucionar. Es por eso que proveedores como RackSpace o Hetzner proveen sistemas con Selinux deshabilitado de fábrica. Si aún así quieres trabajar con Selinux, seguramente este sea el momento de configurarlo adecuadamente. En caso contrario, símplemente deshabilitalo tal y como sigue:

vi /etc/selinux/config
SELINUX=disabled

Tras deshabilitarlo, será necesario reinciar el sistema para activar los cambio. Así pues, reinicia para evitar tener problemas con los próximos pasos.

¿Cuantas CPUs tiene mi servidor Linux? ¿Y RAM?

30 Octubre 2014 at 13:12 by Adrián Pérez

cpuOtro post que tenía en borradores y que he decidido rescatar. Esta vez sobre hardware, con comandos tan básicos como útiles.

¿Cuantas CPUs tiene mi servidor?

En la mayoría de distribuciones Linux, pero concretamente en CentOS, podemos saber cuantas CPUs tiene el servidor, consultando /proc.

[root@myserver]# cat /proc/cpuinfo

El comando anterior nos mostrará la información referente a nuestras CPUs, pero "a simple vista" no sabemos si lo que nos está enseñando es el número de CPUs físicas, el número de nucleos, todo mezclado, etc. Para ello, hemos de prestar atención especialmente a los siguientes campos:

  • "Pyhisical id": id de CPU física. Nos servirá para saber el número de CPUs físicas del servidor. En el ejemplo, vemos 4 CPUs pero en realidad un único "physical id", lo cual nos indicará que tenemos una única CPU física con 4 núcleos:
[root@myserver]# grep "physical id" /proc/cpuinfo        
physical id     : 0
physical id     : 0
physical id     : 0
physical id     : 0

Administrar un LSI MegaRAID con MegaCLI

19 Septiembre 2014 at 12:01 by Adrián Pérez

LSI MegaRAIDYa vimos cómo gestionar un RAID en servidores HP con hpacucli (y también aquí). Si tienes un server Supermicro, esta herramienta no te servirá. Para gestionar un LSI MegaRAID de un server Supermicro, desde un CentOS, podemos usar "MegaCli".

Desde la página de LSI podremos buscar por nuestro modelo concreto de controladora RAID para bajarnos la versión de MegaCli apropiada, aunque cada versión abarca múltiples controladoras diferentes.

Una vez descargado el programa, podremos instalarlo, en CentOS 6 símplemente ejecutando:

[root@myServer]# unzip 8.07.14_MegaCLI.zip
[root@myServer]# rpm -i Linux/MegaCli-8.07.14-1.noarch.rpm

Como con cualquier otro paquete rpm, podremos ver el contenido del mismo con:

[root@myServer]# rpm -qpl Linux/MegaCli-8.07.14-1.noarch.rpm
/opt/MegaRAID/MegaCli/MegaCli
/opt/MegaRAID/MegaCli/MegaCli64
/opt/MegaRAID/MegaCli/libstorelibir-2.so.14.07-0

Si nos es más cómodo, podemos crear un enlace simbólico para tener el programa en el PATH y poderlo llamar sin tener que introducir su ruta completa.

[root@myServer]# ln -s /opt/MegaRAID/MegaCli/MegaCli64 /usr/local/sbin/MegaCli

Ahora ya podremos escribir "MegaCli" para usar el programa. El programa tiene muchos parámetros, algunos de los cuales están muy bien explicados en este post, y otros están resumidos en este otro post. A continuación, destacaré los que a mí particularmente me han sido más útiles.

Cómo configurar un registro SPF

10 Septiembre 2014 at 16:45 by Adrián Pérez

emailSPF, o Sender Policy Framework, es un estándar usado para verificar que los correos electrónicos enviados desde un determinado dominio, proceden de servidores de correo autorizados para dicho dominio.

Es decir, con telnet (u otros métodos), podríamos enviar un mail usando cualquier dirección de correo electrónico como origen. Así por ejemplo, yo podría enviar un mail haciéndome pasar por obama@whitehouse.com, o dios@elcielo.net. Aquí (y en muchos otros sitios) explican cómo.

El registro SPF, pues, sirve para ayudar a determinar a un servidor de correo, si el mail que acaba de recibir ha de descartarse o entregarse en el inbox.