Popular Tags:

Default VirtualHost en Apache

10 Julio 2014 at 8:48 by Adrián Pérez

Black Hole

A continuación, algunas notas sobre el comportamiento del primer VirtualHost definido en Apache.

En un entorno Apache con VirtualHosts, el primer VirtualHost es importante, pues será el VirtualHost por defecto. Ésto significa que será el VirtualHost con mayor prioridad, y por tanto atenderá a cualquier petición al server contra un dominio no especificado en ningún VirtualHost.

Usualmente tendremos definidos VirtualHost *:80 así como *:443. En este caso, tendremos un default para *:80 y un default para *:443. Si definieramos nuestros VirtualHost especificando IP:puerto, entonces tendríamos un default para cada IP:puerto definido.

El primer VirtualHost, no es más que el primer VirtualHost definido en el httpd.conf. Si usamos como es habitual un fichero de configuración por cada VirtualHost, dentro del directorio "conf.d" incluido por el httpd.conf, entonces el primer VirtualHost será el que primero aparezca, ordenado por nombre. Por esta razón se suele especificar el VirtualHost "default" en un archivo con nombre "_defaul.conf", para que se liste primero.

En la documentación oficial de Apache, además, comentan que este primer VirtualHost debería tener un ServerName y un DocumentRoot iguales a los definidos de forma global en el fichero de configuración global de Apache.

Fuentes:

http://httpd.apache.org/docs/2.2/vhosts/details.html

http://httpd.apache.org/docs/2.2/vhosts/name-based.html

Flickr! Foto por ( (( marS )) )

Comandos básicos de GIT

6 Junio 2014 at 12:44 by Adrián Pérez

git

Ésta seguramente acabará siendo una entrada que iré modificando una y otra vez, ya que lleva en borradores más de un año, y desde entonces, he entrado decenas de veces a editar y a ampliar el contenido.

En fin, git es un sistema de control de versiones open source y distribuido, que cambia el concepto de trabajo de los antiguos sistemas de control de versiones tipo "subversion". Git mantiene una copia completa de todo el repositorio, en cada uno de los ordenadores de trabajo, de tal manera que el programador siempre trabaja en local con su copia completa, lo cual le permite trabajar sin conexión o desde cualquier PC con acceso al repositorio de git (lo cual le permitiría clonar de nuevo el repositorio y continuar trabajando en local en el nuevo PC).

Si estás empezando con git, mírate bitbucket, que quizá te interese, y planteate usar algún cliente Git, como SourceTree. Si eres más de Linux y terminal, entonces quizá ésto te interese.

Git clone

Para copiar en local el repositorio entero de git, bastará con ejecutar git clone, seguido del fichero git con el repositorio a clonar. Por ejemplo:

[root@adripc]# git clone https://username@bitbucket.org/miproyecto/mirepo.git

El git clone, habitualmente, creará en el directorio local en el que estamos ubicados, un nuevo directorio que contendrá todo el árbol con el repositorio git. Hará un clonado en local, en toda regla. También podemos usar git clone para clonar nuestro repositorio local a un segundo repositorio local.

VLANs y múltiples alias de red en Red Hat 6

23 Abril 2014 at 12:36 by Adrián Pérez

networking vlanPara poder trabajar con VLANs tageadas en un servidor Red Hat Enterprise 6.0 con múltiples alias de red, tendremos que esforzarnos un poco. En mi caso, he partido de un servidor con una única tarjeta de red (eth0) configurada con 10 alias, todo IPs del mismo rango, del siguiente estilo:

eth0:0 192.168.1.2
eth0:1 192.168.1.3
...
eth0:10 192.168.1.12

Por supuesto, el servidor contaba con un default gateway configurado en cada uno de los alias:

GATEWAY=192.168.1.1

Con este servidor en producción, y con mucho sudor frío, he pasado a configurar el rango 10.0.0.2-10.0.0.25 en el servidor, con default gateway 10.0.0.1, todo perteneciente a la VLAN 30, y todo tageado, también usando la misma interfaz eth0, y lo más importante, manteniendo la configuración de red original (es decir, acabaremos teniendo el servidor configurado para trabajar con 2 rangos de IPs diferentes, uno de ellos perteneciente a la VLAN 30).

Por cierto, si estás pensando en seguir los pasos aquí descritos en un servidor en producción, te recomendaría testearlos primero en un entorno de test, y tener un plan B para recuperar la conectividad con el servidor en caso de cometer algún error.

Añadir un nuevo nodo a un Cluster Galera

11 Abril 2014 at 10:38 by Adrián Pérez

clusterEn este post veremos cómo añadir un nuevo nodo a un cluster MySQL en producción. Las pruebas se han hecho con este escenario:

Lo primero que haremos será situarnos sobre el que será el nuevo nodo y seguir los pasos descritos a continuación:

1. Si no lo tiene ya, deberemos instalar Percona-XtraDB Cluster, para posteriormente poder restaurar el backup. Recuerda:

Backups en un Cluster MySQL (PXC 5.6)

11 Abril 2014 at 10:00 by Adrián Pérez

datacenterDespués de montar un clúster PXC o Galera Cluster (versión 5.6 en servidores CentOS 6.5), igualmente querremos hacer backups de nuestros datos. Para ello, bastará con realizar un backup de uno de los nodos, puesto que todos los nodos contendrán exactamente la misma información. Aunque en realidad no es tan fácil...

Problemas con los backups en un cluster Galera

Hemos de tener en cuenta que los backups, en algún punto, realizarán un FLUSH TABLES WITH READ LOCK, que hará que ese nodo no permita escrituras y por tanto, no se podrán realizar escrituras en el cluster durante ese tiempo [Fuente 1 y Fuente 2]. La explicación es que una escritura al cluster devolverá ok cuando se haya replicado a todos los nodos del mismo. Por tanto, si un nodo no puede escribir, todo el cluster no podrá escribir.

A ésto hay que sumarle que por defecto un backup en PXC/Galera no guardará los "Global Transaction ID", necesarios para poder dar de alta nuevos nodos de forma rápida (ahorrándonos el SST inicial) a raíz de ese backup. [Fuente, transp. 44]

Fecha de creación de un fichero en Linux

27 Marzo 2014 at 10:58 by Adrián Pérez

timeHace un tiempo tuve la necesidad de ver la fecha de creación de un fichero en un servidor Linux. Conocía las fechas atime, ctime y mtime, pero no tenía muy claro cómo ver la fecha en la que el fichero se creó, puesto que por defecto, la salida del comando "ls -l" muestra la fecha de modificación del mismo.

Finamente he llegado a un blog donde explican perfectamente cómo sacar la crtime (o CReation Time). La idea es usar el comando "stat" con "debugfs". Para ello, primero tenemos que tomar como referencia la raíz del sistemas de ficheros que contiene el archivo a inspeccionar.

Instalar Percona XtraDB Cluster 5.6

24 Marzo 2014 at 12:23 by Adrián Pérez

percona

Hace un tiempo, escribí sobre cómo instalar Percona XtraDB Cluster 5.5, de cara a tener una solución tipo cluster para MySQL basada en Galera. Los últimos días, he estado testeando la nueva versión de Percona XtraDB Cluster 5.6, y me he encontrado con algunas diferencias respecto a la instalación/configuración de la versión 5.5.

Requisitos

Para empezar, de cara a instalar Percona XtraDB Cluster 5.6, es necesario contar con socat instalado en todos los nodos del cluster antes de empezar a instalar Percona. En mi caso, en un Centos 6.5, me ha dado problemas la instalación desde sources, y finalmente lo he instalado desde un repositorio externo.

[root@myServer1]# cd /etc/yum.repos.d
[root@myServer1]# wget --no-cache http://www.convirture.com/repos/definitions/rhel/6.x/convirt.repo

Fuente: http://www.convirture.com/wiki/index.php?title=C2_fedora_installation

Tras contar con socat, he podido instalar el cluster, igual que en la versión 5.5.

Actualizar automáticamente un servidor

12 Marzo 2014 at 12:09 by Adrián Pérez

updateÚltimamente he estado leyendo sobre cómo y cuando actualizar un servidor Linux (Fedora/CentOS/Red Hat en mi caso), de cara a aplicar los últimos parches de seguridad y mantener el sistema actualizado. Resulta que no soy el único que se pregunta sobre si hay algún tipo de guía, recomendaciones, o mejores prácticas para updatear sistemas.

Después de leer y leer, y ver las numerosas razones tanto a favor como en contra de los updates automáticos, la siguiente frase en la documentación oficial de Fedora resume cuándo habilitar las actualizaciones automáticas, por lo general:

"If the machine is a critical server, for which unplanned downtime of a service on the machine can not be tolerated, then you should not use automatic updates. Otherwise, you may choose to use them."

Es decir, por norma general sería una buena idea habilitar las actualizaciones automáticas en todo servidor que no sea crítico, siempre y cuando tengamos la posibilidad de deshacer los updates instalados, o revertir los cambios, en caso de error.

Gitolite: gestión de permisos en Git

26 Febrero 2014 at 17:48 by Adrián Pérez

gitEs muy posible que queramos tener un control de usuarios y permisos en nuestro repositorio git centralizado, si por ejemplo, tenemos a varios equipos de varios desarrolladores trabajando cada uno con un repositorio diferente. Afortunadamente, existen varias soluciones a este problema pero yo me he quedado con gitolite, por su facilidad de gestión y sus posibilidades.

NOTA: En este post se irá cambiando del servidor (miServer) a mi PC local (miPC). Se irá comentando a lo largo del post a qué entorno se hace referencia, pero si te pierdes, fíjate en el inicio de cada comando ejecutado (ej: [root@miServer ~] vs [adri@miPC])

Instalación

Añadimos el repositorio EPEL para nuestro servidor con el repositorio central, un CentOS 6:

[root@miServer ~]# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
[root@miServer ~]# rpm -Uvh epel-release-6-8.noarch.rpm

Instalamos git y a posteriori gitolite, que en mi caso, me ha instalado y/o actualizado bastantes paquetes, la mayoría relacionados con perl:

[root@miServer ~]# yum install git gitolite3.noarch

A continuación, crearemos un usuario de sistema, para gitolite, al que en el ejemplo hemos llamado "git", y que será el usuario de sistema con el que interactuarán los usuarios con el repo:

[root@miServer ~]# useradd --system --shell /bin/bash --home /home/git git

Maldet - Linux Malware Detect

26 Febrero 2014 at 16:34 by Adrián Pérez

virusMaldet (también conocido como LMD de las iniciales de Linux Malware Detect) es un detector de malware para entornos Linux compartidos, bajo licencia GNU GPLv2, que funciona desde el terminal.

Instalación

Podemos instalar Maldet de la siguiente manera:

1. Bajaremos el tarball de la página oficial:

[root@miServer tmp]# wget http://www.rfxn.com/downloads/maldetect-current.tar.gz

2. Descomprimiremos e instalaremos

[root@miServer tmp]# tar -zxcvf maldetect-current.tar.gz
[root@miServer tmp]# cd maldetect-1.4.2/
[root@miServer tmp]# ./install.sh

3. Ya estaremos listos para usar Maldet