Publicado el

Administrar un LSI MegaRAID con MegaCLI

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.

Continuar leyendo «Administrar un LSI MegaRAID con MegaCLI»

Publicado el

Cómo configurar un registro SPF

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 [email protected], o [email protected]. 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.

Continuar leyendo «Cómo configurar un registro SPF»

Publicado el

Instalar yum en Red Hat 4

old manBueno, hoy me he encontrado con un (muy) antiguo server Red Hat 4 que no tenía yum instalado. Hace un tiempo ya me pasó algo parecido, así que he decidido crear un post para documentar cómo lo solucionamos.

Lo primero es verificar que no tenemos yum instalado. Para eso, como root, podemos ejecutar:

[root@myOldServer ~]# yum
bash: yum: command not found
[root@myOldServer ~]# whereis yum
yum:
[root@myOldServer ~]# rpm -q yum
package yum is not installed

Posteriormente, nos aseguramos de la versión y la arquitectura de nuestro servidor, para saber qué paquetes exactos necesitaremos:

[root@myOldServer ~]# uname -m 
x86_64
[root@myOldServer ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux ES release 4 (Nahant Update 6)

Continuar leyendo «Instalar yum en Red Hat 4»

Publicado el

Default VirtualHost en Apache

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 )) )

Publicado el

Comandos básicos de GIT

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://[email protected]/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.

Continuar leyendo «Comandos básicos de GIT»

Publicado el

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

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.

Continuar leyendo «VLANs y múltiples alias de red en Red Hat 6»

Publicado el

Añadir un nuevo nodo a un Cluster Galera

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:

Continuar leyendo «Añadir un nuevo nodo a un Cluster Galera»

Publicado el

Backups en un Cluster MySQL (PXC 5.6)

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]

Continuar leyendo «Backups en un Cluster MySQL (PXC 5.6)»

Publicado el

Fecha de creación de un fichero en Linux

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.

Continuar leyendo «Fecha de creación de un fichero en Linux»

Publicado el

Instalar Percona XtraDB Cluster 5.6

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.

Continuar leyendo «Instalar Percona XtraDB Cluster 5.6»