LUKS – Encriptando discos duros en Linux

LUKS es un estándar para el encriptado de discos en Linux. A diferencia de otras soluciones, LUKS almacena la configuración necesaria en las cabecera de las particiones, lo que nos permite llevarnos los discos a otro sistema facilmente.
Voy a detallar brevemente como preparar un disco encriptado con LUKS, utilizando Debian 6.

1) Instalar cryptsetup-luks

# apt-get install cryptsetup

Comprobar que nuestro kernel tiene cargado el módulo dm-crypt:

# lsmod | grep dm_cry

Si no es así lo tendremos que cargar con modprobe.

2) Preparar disco
En mi caso voy a utilizar un disco duro externo (sde), podemos ver que actualmente tiene una única partición:

# fdisk -l /dev/sde
Disco /dev/sde: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cilindros of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000abcce

Disposit. Inicio Comienzo Fin Bloques Id Sistema
/dev/sde1 1 182401 1465136001 83 Linux

Una buena práctica antes de encriptar un disco, sobre todo si este no es nuevo, es comprobar que funciona perfectamente y no tiene bloques erroneos. Para ello podemos usar la utilidad badblocks:

# badblocks -s -w /dev/sde1 -b 4096

Tener en cuenta que esta operación tarda varias horas.

3) Encriptar el filesystem

# cryptsetup luksFormat /dev/sde1

Podemos comprobar la cabecera luck con:

# cryptsetup -v luksDump /dev/sde1
LUKS header information for /dev/sde1
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 2056
MK bits: 256

4) Formatear partición

# mkfs.ext3 /dev/mapper/cryptvol01
# tune2fs -i 0 -c 0 /dev/mapper/cryptvol01

5) Montar/desmontar volumen
Para montar el volumen a mano:

# mkdir /mnt/cryptvol01
# cryptsetup luksOpen /dev/sde1 cryptvol01
# mount /dev/mapper/cryptvol01 /mnt/cryptvol01

Y para desmontarlo:

# umount /mnt/cryptvol01
# cryptsetup luksClose /dev/mapper/cryptvol01

Documentación:
http://code.google.com/p/cryptsetup/
http://rm-rf.es/encriptar-un-filesystem-con-luks-y-cryptsetup/
http://wasesores.com/cifrar-discos-o-particiones-en-linux-ubuntu/
http://chernando.eu/seguridad/cifrando-una-particion-con-cryptsetup/

Advertisements

Clusters de Alta Disponibilidad (HA)

Para conseguir redundancia y protección contra fallos de un sistema, la primera de las medidas que se suelen tomar es replicar sus componentes hardware más críticos. Por ejemplo en el caso de un servidor se emplean configuraciones de discos en RAID, fuentes de alimentación redundantes, varias interfaces de red en bonding, etc. Y el mismo concepto de redundancia se aplica también para el resto de componentes como la electrónica de red o el sistema eléctrico.

Estas medidas indudablemente aumentan el nivel de disponibilidad de un sistema, pero para conseguir un nivel aun mas alto, se suelen utilizar configuraciones avanzadas de hardware y software como son los clusters de Alta Disponibilidad.

Un Cluster de Alta Disponibilidad es un conjunto de dos o mas servidores, que se caracteriza por compartir el sistema de almacenamiento, y por que están constantemente monitorizándose entre sí. Si se produce un fallo del hardware o de los servicios de alguno de las maquinas que forman el cluster, el software de alta disponibilidad es capaz de rearrancar automáticamente los servicios que han fallado en cualquiera de los otros equipos del cluster. Y cuando el servidor que ha fallado se recupera, los servicios se migran de nuevo a la máquina original.

Esta capacidad de los clusters de restablecer en pocos segundos un servicio, manteniendo la integridad de los datos, permite que en muchos casos los usuarios no tengan por que notar que se ha producido un problema. Cuando una avería de este tipo, en un sistema sin cluster, podría dejarles sin servicio durante horas.

La utilización de clusters no solo es beneficiosa para caídas de servicio no programadas, si no que también es útil en paradas de sistema programadas como puede ser un mantenimiento hardware o una actualización software.

En general las razones para implementar un cluster de alta disponibilidad son:

* Aumentar la disponibilidad
* Mejorar el rendimiento
* Escalabilidad
* Tolerancia a fallos
* Recuperación ante fallos en tiempo aceptable
* Reducir costes
* Consolidar servidores
* Consolidar el almacenamiento

1. Configuraciones de Alta Disponibilidad
Las configuraciones mas comunes en entornos de clusters de alta disponibilidad son la configuración activo/activo y la configuración activo/pasivo.

– Configuración Activo/Activo
En una configuración activo/activo, todos los servidores del cluster pueden ejecutar los mismos recursos simultáneamente. Es decir, los servidores poseen los mismos recursos y pueden acceder a estos independientemente de los otros servidores del cluster. Si un nodo del sistema falla y deja de estar disponible, sus recursos siguen estando accesibles a través de los otros servidores del cluster.

La ventaja principal de esta configuración es que los servidores en el cluster son mas eficientes ya que pueden trabajar todos a la vez. Sin embargo, cuando uno de los servidores deja de estar accesible, su carga de trabajo pasa a los nodos restantes, lo que produce una degradación del nivel global de servicio ofrecido a los usuarios.
En la siguiente figura se muestra como ambos servidores están activos, proporcionando un mismo servicio a los diferentes usuarios. Los clientes acceden al servicio o recursos deforma transparente y no tienen conocimiento de la existencia de varios servidores formando un cluster.

– Configuración Activo/Pasivo
Un cluster de alta disponibilidad, en una configuración activo/pasivo, consiste en un servidor que posee los recursos del cluster y otros servidores que son capaces de acceder a esos recursos, pero no los activan hasta que el el propietario de los recursos ya no este disponible.

Las ventajas de la configuración activo/pasivo son que no hay degradación de servicio y que los servicios solo se reinician cuando el servidor activo deja de responder. Sin embargo, una desventaja de esta configuración es que los servidores pasivos no proporcionan ningún tipo de recurso mientras están en espera, haciendo que la solución sea menos eficiente que el cluster de tipo activo/activo. Otra desventaja es que los sistemas tardan un tiempo en migrar los recursos (failover) al nodo en espera.

2. Funcionamiento de un cluster de alta disponibilidad
En un cluster de alta disponibilidad, el software de cluster realiza dos funciones fundamentales. Por un lado intercomunica entre sí todos los nodos, monitorizando continuamente su estado y detectando fallos. Y por otro lado administra los servicios ofrecidos por el cluster, teniendo la capacidad de migrar dichos servicios entre diferentes servidores físicos como respuesta a un fallo.

A continuación se describen los elementos y conceptos básicos en el funcionamiento del cluster.

– Recurso y Grupos de Recursos
Tradicionalmente se entiende como servicio a un conjunto de procesos que se ejecutan en un momento dado sobre un servidor y sistema operativo. Este último provee a los procesos de los recursos necesarios para realizar su tarea: sistema de ficheros, interfaces de red, tiempo de cpu, memoria, etc.
En un cluster de alta disponibilidad, el software de cluster, abstrae e independiza a los servicios de un host concreto. Posibilitando que estos se desplacen entre diferentes servidores de forma trasparente para la aplicación o los usuarios.
El software de cluster permite definir grupos de recursos, que son todos aquellos recursos necesarios por el servicio. Estos recursos serán los scripts de arranque del servicio, un sistema de ficheros, una dirección IP, etc.

– Intercomunicación
El software de cluster gestiona servicios y recursos en los nodos. Pero además, tiene que mantener continuamente entre estos una visión global de la configuración y estado del cluster. De esta forma, ante el fallo de un nodo, el resto conoce que servicios se deben restablecer.
Ya que la comunicación entre los nodos del cluster es crucial para el funcionamiento de este, es habitual utilizar un canal especifico como una red IP independiente o una conexión serie, que no se pueda ver afectada por problemas de seguridad o rendimiento.

– Heartbeat
El software de cluster conoce en todo momento la disponibilidad de los equipos físicos, gracias a la técnica de heartbeat. El funcionamiento es sencillo, cada nodo informa periódicamente de su existencia enviando al resto una “señal de vida”.

– Escenario Split-Brain
En un escenario split-brain, mas de un servidor o aplicación pertenecientes a un mismo cluster intentan acceder a los mismos recursos, lo que puede causar daños a dichos recursos. Este escenario ocurre cuando cada servidor en el cluster cree que los otros servidores han fallado e intenta activar y utilizar dichos recursos.

– Monitorización de Recursos (Resource Monitoring)
Ciertas soluciones de clustering HA permiten no solo monitorizar si un host físico esta disponible, también pueden realizar seguimientos a nivel de recursos o servicios y detectar el fallo de estos.
El administrador puede configurar la periodicidad de estos monitores así como las acciones a llevar a cabo en caso de fallo.

– Reiniciar Recursos
Cuando un recurso falla, la primera medida que toman las soluciones de cluster es intentar reiniciar dicho recurso en el mismo nodo. Lo que supone detener una aplicación o liberar un recurso y posteriormente volverlo a activar.
Algunas implementaciones no permiten reiniciar un único recurso, y lo que realizan es un reinicio completo de todo un grupo de recursos (servicio). Esto puede llegar a demorar bastante para servicios como las bases de datos.

– Migración de Recursos (Failover)
Cuando un nodo ya no esta disponible, o cuando un recurso fallido no se puede reiniciar satisfactoriamente en un nodo, el software de cluster reacciona migrando el recurso o grupo de recursos a otro nodo disponible en el cluster.
De este modo el tiempo de inactividad por el posible fallo es mínimo, y el cluster seguirá proporcionando el correspondiente servicio.

– Dependencia entre recursos
Habitualmente para que el cluster proporcione un servicio, son necesarios no solo un recurso si no varios (ip virtual, sistema de ficheros, proceso), lo que se conoce como grupo de recursos. Cuando se arranca o detiene un servicio, sus recursos tienen que activarse en el orden apropiado ya que unos dependen de otros. El software de cluster tiene que permitir definir estas dependencias entre recursos así como entre grupos.

– Preferencia de Nodos (Resource Stickiness)
En configuraciones de cluster con múltiples nodos, es común distribuir los servicios a proporcionar entre los diferentes servidores. Además puede que los servidores tengan características hardware diferentes (cpu, memoria ram) y nos interese que, para un estado ideal del cluster, determinados servicios se ejecuten siempre en un determinado servidor.
Este comportamiento se define mediante la preferencia de nodo en la definición de cada recurso.

– Comunicación con otros sistemas
El cluster tiene que monitorizar no solo que un servidor y sus servicios están activos, también debe de comprobar que, de cara a los usuarios, dicho servidor no queda desconectado de la red por el fallo de un latiguillo, switch, etc.
Por lo tanto el software de cluster debe comprobar que los nodos son alcanzables. Un método simple para conseguirlo, es verificar que cada nodo tiene accesible el router o puerta de enlace de la red de usuarios.

– Fencing
En los clusters HA existe una situación donde un nodo deja de funcionar correctamente pero todavía sigue levantado, accediendo a ciertos recursos y respondiendo peticiones. Para evitar que el nodo corrompa recursos o responda con peticiones, los clusters lo solucionan utilizando una técnica llamada Fencing.
La función principal del Fencing es hacerle saber a dicho nodo que esta funcionando en mal estado, retirarle sus recursos asignados para que los atiendan otros nodos, y dejarlo en un estado inactivo.

– Quorum
Para evitar que se produzca un escenario de Split-Brain, algunas implementaciones de cluster HA introducen un canal de comunicación adicional que se emplea para determinar exactamente que nodos están disponibles en el cluster y cuales no. Tradicionalmente se implementa utilizando los llamados quorum devices, que habitualmente son un volumen de almacenamiento compartido exclusivo (disk heart beating). También existen implementaciones que utilizan una conexiones de red adicional o una conexión serie. Esta última tiene limitaciones de distancia y actualmente ha quedado en desuso.

Documentación:
* Blueprints for High Availability – Evan Marcus, Hal Stern – Wiley 2003
* Clusters for High Availability – Peter S. Weygant – Prentice Hall 2001
* Red Hat Cluster Suite Overview – Red Hat Inc. 2008
* The SUSE Linux Enterprise Server Heartbeat Guide – Novell 2008
* Linux-HA Project Documentation – www.linux-ha.org

Artículos Anteriores:
Introducción a los Clusters
Introducción a la Alta Disponibilidad

Paulo Clavijo – lintips.com – 2010

lBookV3 – Ereader de papel electrónico

Desde hace unas semanas tengo un lBookV3 (HalinV3). Este aparatillo es genial para los aficionados a la lectura y viene perfecto también para llevar cientos de libros técnicos en el tamaño de una caja de dvds.

Y como no podía ser menos, corre bajo Linux, en concreto un kernel 2.6.11.17. con la última versión del firmware.

otas de la versión, con el firmware actualizado

Para descargar las últimas versiones del firmware visitar:
http://lbook.com.ua/ru/download/lBook%20V3
http://www.jinke.com.cn/Compagesql/English/service/update.asp

Imagenes para la pantalla de inicio y apagado:
http://www.the-ebook.org/forum/viewtopic.php?t=7020

Comunidades de usuarios de e-readers:
http://www.mobileread.com/
http://www.lectoreselectronicos.com

Libros para descargar en español:
http://www.grammata.es/obras
http://fegoal.blogspot.com/search/label/fb2

Cambiando a Drupal

Bueno, después de la larga espera, he pasado este blog de wordpress a drupal.

En concreto he utilizado Drupal 5.1
http://ftp.osuosl.org/pub/drupal/files/projects/drupal-5.1.tar.gz

con el tema:
http://ftp.osuosl.org/pub/drupal/files/projects/barron-5.x-1.3.tar.gz

Ademas utilizo los siguientes modulos adicionales:

El modulo de filtro me queda con el siguiente orden:
0 URL filter
1 HTML filter
2 Code filter
3 Line break converter

Aparte de instalar Drupal y los modulos indicados he instalado la librería de gráficos de php4:

# apt-get install php4-gd

El único problema que me ha surgido con la instalación de drupal ha sido el siguiente error:
Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes), con el tamaño de memoria asignado por defecto a php.

La solución al problema se comenta en http://drupal.org/node/76156 y consisten en configurar el parametro memory_limit en los siguientes ficheros de configuración.

/etc/php/apache2/php.ini

memory_limit = 12M to your php.ini file

sites/default/settings.php

ini_set('memory_limit', '12M');

.htaccess

php_value memory_limit 12M

HowTo GRUB bootdisk

La idea es crear un disquete de arranque de nuestro Linux. Que nos servirá de respaldo, por si nos cargamos el mbr o la configuración de nuestro grub en disco duro.

Para crear un disquete de arranque GRUB, seguimos los siguientes pasos:

# apt-get install dosfstools
# fdformat /dev/fd0 mkfs -t msdos /dev/fd0
# mount /dev/fd0 /mnt/floppy
# mkdir -p /mnt/floppy/boot/grub
# cp /boot/grub/stage* /mnt/floppy/boot/grub
# umount /dev/fd0
# grub
# grub> root (fd0)
# grub> setup (fd0)
# grub> quit

Con esto ya tendríamos un disco de arranque con grub. Reiniciando el sistema veremos como se carga GRUB desde el disquete. Eso si, sin menú alguno, solo la entrada de comandos de grub. Por lo que tenemos que indicar a mano que queremos arrancar. Por ejemplo, para un sistema Debian con un solo disco y dos particiones la / (sda1) y la swap:

# grub> root (hd0,0)
# grub> kernel /boot/vmlinuz-2.6.8-3-686 root=/dev/sda1 ro
# grub> initrd /boot/initrd.img-2.6.8-2-686
# grub> boot

Esto último no me es demasiado útil, ya que supone conocer la imagen del kernel a arrancar así como discos y particiones. Si queremos tener un menú con los diferentes arranques, lo que necesitamos es crear o copiar en el disquete un menu.lst valido. Por ejemplo copiamos el actual menu.lst al bootdisk.

# mount /dev/fd0 /mnt/floppy
# cp /boot/grub/menu.lst /mnt/floppy/boot/grub/menu.lst
# umount /dev/fd0

Apuntes instalación “Servidor con Debian Sarge”

He instalado Debian en una Sun Ultra10 con arquitectura Sparc. Mi idea es utilizar esta maquina como router+firewall.

Realizo la instalación de Debian 3.1r5 Sarge, únicamente instalo el sistema base. Mas tarde ya ire instalando los servicios que me hacen falta.

0) Configuro las interfaces de red en /etc/network/interfaces

# The loopback network interface
auto lo
iface lo inet loopback
# Interfaz LAN (sun happy meal)
auto eth1
iface eth1 inet static
 address 192.168.0.1
 netmask 255.255.255.0
 network 192.168.0.0
 broadcast 192.168.0.255
 # dns-* options are implemented by the resolvconf package, if installed
 dns-nameservers 193.152.63.197
 dns-search net-wolf.esp
 # Se definen las rutas estaticas a otras intranets
 up "/sbin/route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.2 metric 1"
 down "/sbin/route del -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.2 metric 1"
# Interfaz WAN (3com, conectada al cable-modem)
auto eth0
iface eth0 inet dhcp

Activo ipforwarding entre interfaces en /etc/network/options

ip_forward=yes

Y aplico reglas iptables necesarias para hacer NAT y cerrar puertos:

# Hacemos enmascaramiento de la red local
/sbin/iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE
# Se permite el acceso Web desde el exterior, el resto se cierra
/sbin/iptables -A INPUT -p tcp -i eth0 -m state --state NEW,ESTABLISHED,RELATED --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -p all -i eth0 -m state --state NEW,INVALID -j DROP

1) Instalo OpenSSH para poder administrar la maquina remotamente

# apt-get install ssh

Por seguridad desactivo el acceso por ssh para root en /etc/ssh/sshd_config
PermitRootLogin no

Desde la red local me gusta acceder a los servidores, sin tener que utilizar contraseñas. Así que voy a generar la llave publica de mi equipo y la registro en el servidor (la maquina que estoy instalando).

# ssh-keygen -t dsa
# scp id_dsa.pub ipservidor:/home/usuario/.ssh/authorized_keys

2) Configuro APT, el fichero sources /etc/apt/sources.list me queda con estas fuentes:

# vi /etc/apt/sources.list
~ deb <a href="http://security.debian.org/">http://security.debian.org/</a> stable/updates main contrib
~ deb <a href="http://ftp.es.debian.org/debian/">http://ftp.es.debian.org/debian/</a> stable main contrib

y actualizo

# apt-get update 
# apt-get upgrade

3) Actualizo el nucleo de Linux de la version 2.4.27-3-sparc64 a 2.6.8-3-sparc64

# apt-get install kernel-image-2.6.8-3-sparc64

tras reiniciar y comprobar que el nuevo kernel 2.6 funciona bien, desinstalo la imagen del 2.4

# apt-get remove kernel-image-2.4.27-3-sparc64

4) Instalando LAMP

# apt-get install apache2 apache2-doc lynx
# apt-get install mysql-server
# apt-get install php4 libapache2-mod-php4
# apt-get install php4-mysql

– Configuro apache /etc/apache2/apache2.conf, para que utilize ISO-8859-1 como juego de caracteres por defecto.

AddDefaultCharset ISO-8859-1

– Se configura apache para activar el uso de php. En /etc/apache2/apache2.conf se añade la siguiente linea:

AddType application/x-httpd-php .php

– se puede modificar el fichero /etc/apache2/sites-enabled/000-default
para desactivar la redireccion a /apache2-default/

– Se configura php para que utilize mysql, con la siguiente linea en /etc/php/apache2/php.ini:

extension=mysql.so

– establezco password para localhost de mysql

# mysqladmin -u root password 'newpassword'

5) Instalo servidor ftp vsftpd

# apt-get install vsftpd

Se configura en /etc/vsftpd.conf. Desactivo el acceso para el usuario anonimo y activo la jaula para usuarios locales:

ftpd_banner=Bienvenido al Servidor FTP
anonymous_enable=NO
local_enable=YES
chroot_local_user=YES

Si tenemos usuarios que solo utilizan el ftp, los configuramos en /etc/passwd con el shell /bin/false. Y añadimos este a la lista de shells del sistema

# echo "/bin/false" >> /etc/shells

ya que si no hacemos esto último, vsftd no permitira al acceso a dichos usuarios.

Si usamos usuario anonimo, el directorio por defecto es /home/ftp
6) Instalar dhcpd

# apt-get install dhcp

Y realizo la configuración para mi subred en /etc/dhcpd.conf. Sin olvidar definir en /etc/default/dhcp las interfaz por las que se serviran peticiones.

7) Instalar webmin y algunos de sus modulos adicionales

# apt-get install webmin webmin-core logcheck
# apt-get install webmin-mysql webmin-dhcpd

8) Instalo el cliente no-ip. Para que actualize automáticamente, mi nombre de dominio, cuando mi ip publica cambie (con ono suele ser a las 2 semanas).

# apt-get no-ip

y configuro con mi cuenta en no-ip con el siguiente comando

# no-ip -C

9) Instalar las X.
Voy a realizar una instalación de las X mínima, ya que la máquina va a hacer de servidor y solo las voy a utilizar en casos muy puntuales.
– Instalar el servidor de las XFree86 (por defecto en sarge)

# apt-get install x-window-system-core

– Lo siguiente sería instalar el display manager (tenemos varias opciones xdm, gdm, kdm). Aunque en mi caso no instalo ninguno ya que arranco a mano.
– Instalar un windows manager (fluxbox, icewm, …) o un entorno de escritorio (gnome, kde, …), yo elijo fluxbox.

# apt-get install fluxbox

10) Instalar VNC

# apt-get install vncserver

y para configurarlo se modifica /etc/vnc.conf, para ajustar por ejemplo la resolució con la opción $geometry=”800×600″;

Uso:
vncserver //inicia vnc
vncserver -kill :1 //para vnc

Documentación:
http://www.debian-administration.org/articles/135

Apendice I) Exportar e Importar BDD en Mysql
Exportarmos la base de datos indicada a un archivo comprimido con:

# mysqldump --quick nombre_bdd | gzip > nombre_bdd.gz

Si se va a importar a un servidor donde la BDD no existia previamente hacemos:

# mysqladmin -u root -p create nombre_bdd
# gunzip < nombre_bdd.gz | mysql -u root -p nombre_bdd
# mysql -u root -p
mysql> show databases ;
mysql> grant all on nombre_bdd.* to <a href="mailto:usuario_bdd@localhost">usuario_bdd@localhost</a> identified by 'password' ;

Apendice II) Acceso a MySQL desde otras IP
Si para una bd mysql queremos permitir el acceso desde otra ip que no sea localhost, simplemente deberemos conceder permisos a un usuario tanto para localhost como para la ip del cliente.

mysql> grant all on nombre_bdd.* to <a href="mailto:usuario_bdd@localhost">usuario_bdd@localhost</a> identified by 'password' ;
mysql> grant all on nombre_bdd.* to <a href="mailto:usuario_bdd@ipcliente">usuario_bdd@ipcliente</a> identified by 'password' ;

Y editar /etc/mysql/my.cnf , poniendo la ip del servidor en la red.

#bind-address           = 127.0.0.1
bind-address            = 192.168.1.1

si queremos que escuche en mas de una IP, nos tocara poner 0.0.0.0, ya que mysql no permite poner mas de una bind-address.

Apendice III) Reconfigurar locales

#dpkg-reconfigure locales
Generating locales (this might take a while)...
  es_ES.UTF-8... done
  en_GB.ISO-8859-1... done
  en_GB.ISO-8859-15... done
  en_GB.UTF-8... done
  en_US.ISO-8859-1... done
  en_US.ISO-8859-15... done
  en_US.UTF-8... done
  es_ES.ISO-8859-1... done
  <a href="mailto:es_ES.ISO-8859-15@euro">es_ES.ISO-8859-15@euro</a>... done
Generation complete.

con el anterior comando podemos seleccionar las locales que queremos generar y seleccionar cual se utilizará por defecto. Es muy importante configurar bién las locales, por ejemplo para aplicaciones web en php, si no se tiene las locales españolas no mostraran las fechas en español, etc.

Apendice IV) Permitir que el servidor envie correos a cuentas de Internet.
Necexitamos tener instalado exim4 y mailx, la instalación por defecto de debian ya lo instala. Si no fuese el caso:

# apt-get install exim4 mailx

Lo importante es que, por defecto, exim4 esta configurado para la entrega solo en local. Si queremos enviar correos al exterior debemos configurarlo. Para ello lo mas sencillo es mediante:

# dpkg-reconfigure exim4-config

donde cambiaremos la entrega solo en local, por envio al exterior directo mediante SMTP (internet site; mail is sent and received directly using SMTP).

Podemos probar si funciona mediante:

/usr/bin/mail -s "CORREO PRUEBA" "<a href="mailto:nombreusuario@correo.com">nombreusuario@correo.com</a>" < mensaje.txt -v

Recetas para un Servidor Casero

Algunas notas y recetillas sobre la configuración de mi servidor casero (router, firewall, proxy-cache, server dhcp, dns)

Hardware: (Compaq 2000)

  • Intel Pentium 200MHz
  • RAM 96 MB
  • 2x NIC Intel 10/100 Mbits
  • CF 1GB y adaptador para CF a IDE (utilizo la tarjeta flash como disco duro)

El adaptador me ha costado 5 € con portes y la CF 10 €. Todo lo demas era hardware para tirar, que no me ha costado nada. Así que en total me he gastado 15€, en la “maquina” :-).

Documentación:
Compartir la conexión y algo más con GNU/Linux (CRySoL)