Publicado el

Medidas de seguridad en WordPress

seguridadWordPress va genial, pero todo sea dicho, también puede ser un coladero si no se ponen medidas para hacerlo seguro. A continuación listo algunas de las medidas que se podrían aplicar para empezar a hacer de nuestro site, un sitio más seguro.

1. Eliminar el usuario «Admin»

Si vas a instalar un WordPress de cero, no uses «admin» como nombre de usuario. Tampoco «root» ni «administrador» ni cosas así. Si en su momento instalaste WordPress con el usuario «admin», lo mejor es que crees un nuevo usuario con permisos de Administrador (ésto puedes hacerlo fácilmente desde el panel de control de WordPress) y una vez creado, te loguees con tu nuevo usuario y elimines el usuario «admin». Tranquilo, al borrar el usuario te pedirá si quieres conservar los posts escritos por «admin» y a qué otro usuario atribuírselos. Sólo con ésto te evitarás más de un dolor de cabeza.

Ah, también ayuda usar un password complejo, a ser posible una combinación de mayúsculas, minúsculas, números y carácteres alfanuméricos.

Continuar leyendo «Medidas de seguridad en WordPress»

Publicado el

Resumen de Scrum desde las trincheras

scrumEste es mi resumen de la parte de Scrum (sin incluir XP) del libro «Scrum y XP desde las trincheras» de Henrik Kniberg. No es la biblia ni debe ser una referencia, pero sí que puede ayudar a refrescar algún concepto o a empezar con Scrum.

Scrum = marco de trabajo

1- Pilas de producto

Lista priorizada de requisitos/historias en jerga del cliente.

  • Id
  • Nombre: de 2 a 10 palabras
  • Importancia: más alto = más importante. La importancia la da el product owner.
  • Estimación inicial: la unidad son puntos de historia [PH en adelante] (días/persona ideales). Ojo, no es un contrato ni un compromiso. Las estimaciones absolutas no son importantes, lo son las relativas. P.ej. Una historia con 2 PH debería durar la mitad que una con 4 PH.
  • Cómo probarlo: descripción a alto nivel de cómo testearlo (descripciones simples).
  • Notas: otra info breve.

El product owner se encarga de los objetivos del negocio y no interviene en decisiones técnicas.

Debe existir la pila de producto, con las importancias, antes de empezar el sprint.

Continuar leyendo «Resumen de Scrum desde las trincheras»

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