Haciendo visibles en la red máquinas con VirtualBox en Fedora 11

Josemaría | 10 de junio de 2009 | 5 comentarios

herramientas Configurar las máquinas virtuales de VirtualBox en modo bridge para que sean accesibles cómodamente entre si o con las máquinas “reales” de nuestra red local es ahora un poco más fácil (desde la versión 2.2.2) de lo que contábamos aquí puesto que ahora aparece un casillero específico para esta opción en la configuración de red de la máquina virtual:

Virtualbox bridge en Fedora 11

Pero, ya puestos vamos a darle un repaso y así vemos como se hace en Fedora 11.

Antes de nada debemos de instalar el paquete bridge-utils (yum install bridge-utils).

Luego editamos el fichero de configuración del interfaz de red de la máquina anfitriona (en mi caso /etc/sysconfig/network-scripts/ifcfg-eth0) y añadimos, al final, la siguiente línea:

BRIDGE=br0

A continuación creamos un nuevo fichero de configuración (/etc/sysconfig/network-scripts/ifcfg-br0) para el bridge:

DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0
STP=off

Por último reiniciamos los servicios de red (service network restart) y ya sólo nos queda configurar la red de la máquina virtual como se muestra en la imagen de aquí arriba. Con esto la máquina virtual tomará una dirección de forma dinámica del servidor DHCP disponible en la red de la máquina anfitriona y será perfectamente visible tanto por cualquier otra máquina conectada a dicha red como por otras máquinas virtuales configuradas de igual forma en el mismo anfitrión.

Virtualbox bridge en Fedora 11

ACTUALIZACIÓN: Si has llegado aquí a través de Google, olvídate de ello. Virtualbox tiene ya un modo bridge de forma automática con sólo escoger la opción adecuada en la configuración de red. Lo hemos contando aquí.
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Configuración de red en Fedora 11

Josemaría | 18 de marzo de 2009 | 3 comentarios

Fedora Una de las cosa más frustrantes a la hora de cambiar de distribución de Linux es que, de pronto, hay algunas cosas que ya no están donde esperas encontrarlas. ¿Dónde diablos se ha metido ahora mi fichero /etc/network/interfaces? Normalmente los cambios son mínimos, pero los hay y no hay más remedio que saber cuales son. Para configurar manualmente la red en una máquina con Fedora, los ficheros que hay que tocar estan en la tabla siguiente. Pongo a su lado los equivalentes en una Debian/Ubuntu para que le resulte más intuitivo a quienes, como yo, venimos de largos años con estas distribuciones:

Debian/UbuntuFedora
Dirección IP y máscara de red/etc/network/interfaces/etc/sysconfig/network-scripts/ifcfg-ethx
Router por defecto/etc/network/interfaces/etc/sysconfig/network
Servidores DNS/etc/resolv.conf/etc/resolv.conf
Nombre del host/etc/hostname/etc/sysconfig/network
Daemon del servicio de red/etc/init.d/networking/etc/init.d/network

La configuración básica está, como veis, en un fichero denominado ifcfg-ethx (donde ethx es el interfaz de red por ejemplo eth0, eth1, etc.). La configuración por defecto de Fedora configura el interfaz de red con una dirección obtenida de forma dinámica por DHCP. Para configurar una IP fija el contenido debería de ser parecido a este:

# Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller
DEVICE=eth0
HWADDR=00:16:e6:50:45:e2
BOOTPROTO=static
IPADDR=192.168.1.5
NETMASK=255.255.255.0
ONBOOT=yes

En el archivo /etc/sysconfig/network configuramos el nombre del host y el router por defecto. Más o menos así:

NETWORKING=yes
GATEWAY=192.168.1.1
HOSTNAME=valeria.isf-apd.org

Por último, el fichero /etc/resolv.conf:

nameserver 87.216.1.65
nameserver 87.216.1.66
nameserver 62.14.2.1
search isf-apd.org

He leído, pero ho he llegado a probarlo, que tanto los servidores DNS y el dominio de búsqueda por defecto como el router predeterminado, pueden asociarce a la interfaz de red en el fichero ifcfg-ethx correspondiente mediante la siguiente sintaxis:

GATEWAY=192.168.1.1
DNS1=87.216.1.65
DNS2=87.216.1.66
DNS3=62.14.2.1
DOMAIN=isf-apd.org

Y, para esos a los que esto de la línea de comandos no les convence, existe también un asistente gráfico para todo ello: system-config-network.

system-config-network en Fedora 11

ACTUALIZACIÓN: Ya he probado la configuración de servidores DNS y router por defecto en el fichero ifcfg-ethx y funciona perfectamente.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes
Categorías: distribuciones, networking
Etiquetas: ,

Instalar y Configurar hmailServer

Josemaría | 27 de febrero de 2009 | 14 comentarios

correo hmailServer es un servidor de correo gratuito para windows. Hasta su versión 4 era, además, un proyecto de software libre. La versión 5 es de código propietario aunque sigue siendo gratuita. Nosotros veremos aquí el procedimiento e instalación de la versión 4.4.3 Build 285, la última estable y que mantenía aún la licencia GPL, pero puede aplicarse perfectamente para la instalación de la versión 5.

Como paso previo a la instalación, no debemos de olvidar que para que un servidor de correo funcione necesitamos un dominio. En nuestro ejemplo será moratalaz.es. En segundo lugar necesitamos que el servidor DNS desde el que se vaya a gestionar dicho dominio tenga un registro MX que apunte al servidor que gestionará nuestro correo. Si también estamos obligados a usar un servidor windows para esta función debería de quedar algo así:

Registro MX en el DNS de windows

Bien. Una vez hecho esto descargamos el ejecutable de la versión 4.4.3 y la instalamos con todas las opciones por defecto. En un momento del proceso se nos pedirá una contraseña que usaremos posteriormente para entrar en el panel de administración del servidor. Al concluir, tendremos un servicio llamado hmailserver (configurado para arrancar automáticamente al iniciar el sistema) y un nuevo grupo de programas en el menú de Inicio de nuestro windows con el mismo nombre. Si entramos ahora en el hmailserver Administrator (para ello se nos pedirá la contraseña que hemos introducido durante la instalación) nos podemos ir haciendo una idea de la multitud de opciones que tenemos disponibles en este servicio:

Menú principal del Administrador de hmailserver

Luego debemos de añadir el dominio cuyo correo queremos gestionar desde este programa y que, como vemos en el pantallazo anterior, es lo primero que se nos solicita. Pulsamos el botón y lo introducimos en la ficha que se nos abre:

Añadiendo un dominio a hmailserver

El siguiente paso no es imprescindible para que nuestro servidor funcione, pero si muy recomendable para no tener problemas. En el apartado de protocolos y dentro de la ficha destinada a SMTP deberíamos de especificar el nombre público con el que nuestro servidor se verá en Internet y que, en una instalación sencilla como la que estamos haciendo, posiblemente será el mismo que hemos puesto en el registro MX de nuestro DNS:

Especificando el nombre público de nuestro servidor

Pues ya hemos acabado. Si configuramos ahora nuestro primer buzón de correo y un cliente para que lo use podremos comprobar que funciona correctamente.

Nuestro primer buzón en hmailserver

Esto en cuanto a la configuración inicial que es hasta donde vamos a llegar aquí. Para explotar el resto de posibilidades que nos ofrece el programa (integración con antivirus, antispam, backups, límites, etc.) podeis echarle un vistazo a la excelente documentación disponible en el propio sitio web del producto.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Instalando un servidor con NFS

Josemaría | 19 de diciembre de 2008 | Comentar

servicios en red ¿Cuánto tiempo hace que no te tropiezas con un servidor con NFS? Si se tratase de un animal seguro que casi podríamos decir que está en peligro de extinción. El caso es que, en ambientes mixtos Windows/*nix con un Directorio Activo (que es el entorno más habitual al que nos enfrentamos) es mucho más práctico y menos problemático montar un servidor con Samba. Pero si en nuestro entorno no existen máquinas con windows o estas son minoritarias, aún podemos montar nuestros servidores de archivos con NFS y usar Windows Services for Unix para dar soporte a este protocolo desde las máquinas con windows (aquí tenéis un tutorial de instalación en castellano).

Para preparar la máquina que ofrecerá los servicios de NFS (y partiendo, como siempre, de una Debian o derivada), sólo tenemos que instalar el paquete nfs-kernel-server (sudo apt-get install nfs-kernel-server) y sus dependencias. Una vez hecho esto podemos ver en el archivo /proc/filesystems que nuestro sistema ya debería de soportar nfs.

Los directorios que queremos compartir se configuran de forma sencilla en el fichero /etc/exports. Allí, y en función de nuestras necesidades, podríamos tener algo como esto:

/mnt/Sistemas 192.168.1.0/25(rw,sync,subtree_check)
/mnt/Desarrollo 192.168.1.0/25(rw,sync,subtree_check)
/mnt/Gestión 192.168.1.0/25(rw,sync,subtree_check)
/mnt/Público (rw,sync,subtree_check)

La sintaxis es bien sencilla. En cada línea pondremos en primer lugar el recurso compartido, en segundo la dirección o direcciones de las máquinas que tendrán acceso a él y, por último y entre paréntesis y sin ningún espacio de separación, los atributos que aplicaremos al recurso compartido.

La forma de expresar las máquinas que tienen acceso al recurso es bien versatil. Podemos poner una única dirección IP (192.168.1.5), una subred completa (192.168.1.0/25 ó 192.168.1.0/255.255.255.128), un nombre de máquina (estacion1.midominio.net), o usar comodines * y ? (estacion*). Si no ponemos nada quiere decir que no habrá restricciones en cuanto al origen de la conexión (como en el caso del recurso /mnt/Público del ejemplo anterior). Si quisiéramos aplicar opciones diferentes según el origen de la conexión lo hacemos de forma consecutiva en la misma línea del fichero exports. De esta forma:

/mnt/Gestión 192.168.1.10(rw) 192.168.1.11(rw) 192.168.1.0/25(ro)

Las diferentes opciones de montaje pueden consultarse con man exports. Algunas de las más comunes son ro (sólo lectura), rw (lectura y escritura), async o sync (según si queremos que replique las modificaciones antes de hacer un commit de estas o no), etc. Despues de cada cambio en el fichero de unidades compartidas debemos de ejecutar la orden exportfs -a para que estos tengan efecto. Ah, y no olvidemos que los permisos aplicados sobre ficheros y directorios de las unidades compartidas ha de ser coherente con los que apliquemos al publicar las mismas.

Y ahora nos vamos con los clientes. En ellos lo único que tenemos que instalar es el paquete nfs-common y sus dependencias. Y listo. Ahora podemos montar las unidades de nuestro servidor remoto de forma manual o, si queremos hacerlo de forma permanente, añadiendo una línea en nuestro fichero fstab. La forma manual sería algo así:

mount -t nfs servidornfs:/mnt/datos /home/josemaria/datos

Si queremos hacerlo desde el fichero fstab, la línea a añadir para el mismo ejemplo anterior sería esta:

servidordns:/mnt/datos /home/josemaria/datos nfs auto,user,noexec,rw

Un par de notas finales. NFS siempre ha recibido muchas críticas por su seguridad hasta la versión 3. La versión 4, que es la que implementan ya los kernels modernos de Debian y sus derivados (Ubuntu, etc.), puede usar Kerberos para proporcionar seguridad en los accesos si así lo requerimos. Por último, aquí tenéis una buena comparativa que señala las debilidades y fortalezas de los sistemas de compartición de archivos más comunes (CIFS es la versión de SMB implementada por los sistemas de Microsoft).

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Hacer visible en nuestra red una máquina virtual con VirtualBox (o comunicar entre si dos de estas)

Josemaría | 22 de noviembre de 2008 | 32 comentarios

herramientas Cuando creas una máquina virtual con VirtualBox, con las opciones de red por defecto, esta cuenta con conexión a cualquier recurso en la red al que tenga acceso la máquina anfitriona (conexión a Internet incluida) y puede compartir archivos con ella si configuramos la opción de “Directorios Compartidos”, pero entre máquina anfitriona y máquina virtual no existe ninguna otra posible conexión. La máquina virtual tampoco es accesible de ninguna forma desde otra máquina de nuestra red local y si abrimos dos máquinas virtuales en la misma máquina anfitriona tampoco pueden verse entre si. Esto puede cambiarse fácilmente para que cualquier máquina virtual que creemos sea totalmente visible, tanto por la máquina anfitriona, como por cualquier otra máquina física (o virtual, en esta u otra máquina anfitriona configurada por este mismo método) como si se tratase verdaderamente de una máquina real conectada de forma independiente a nuestra red. Nos ponemos a ello.

Partimos de una máquina anfitriona con Debian o una distribución derivada (Ubuntu, Kubuntu, etc.), que ya tiene Virtualbox instalado y cuenta con una única interfaz de red (eth0). Lo primero que tenemos que hacer es instalar el paquete bridge-utils.

josemaria@valeria:~$ sudo apt-get install bridge-utils

Luego editamos la configuración de nuestro interface ethernet (/etc/network/interfaces) y lo dejamos de esta forma:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto br0
iface br0 inet dhcp
bridge_ports eth0 vbox0 vbox1

Las líneas en negritas son las que hemos añadido. En ellas estamos definiendo dos interfaces virtuales (vbox0 y vbox1) que están ligados a nuestro interfaz físico real (eth0) y que tomaran una IP de forma dinámica a través de un servicio DHCP que debemos de tener disponible en nuestra red. Esto no quiere decir que no podamos ponerles direcciones fijas a nuestras máquinas virtuales: Estas tendrán disponible este servicio, si existe, desde su arranque pero luego nosotros podremos configurarlas perfectamente mediante IP’s estáticas sin ningún problema, ya dentro del sistema operativo que hayamos elegido para ellas. Por cierto: hemos creado dos interfaces por que es lo que necesitamos (yo, en concreto, quiero hacer prácticas para los chicos con un windows 2003 server y un windows xp que deben de verse para que el segundo se conecte al dominio definido por el primero) pero, lógicamente, podríamos definir una sóla. O diez :-) .

Ahora editamos el archivo de configuración de interfaces de virtualbox (/etc/vbox/interfaces) y añadimos las siguientes líneas:

vbox0 josemaria br0
vbox1 josemaria br0

En ellas redefinimos los dos nuevos interfaces virtuales que hemos creado (vbox0 y vbox1) y declaramos el usuario de la máquina anfitriona que tiene permiso para usarlos.

Ya casi estamos. Ahora reiniciamos, por este orden, la interfaz de red física de nuesta máquina anfitriona y luego virtualbox:

josemaria@valeria:~$ sudo /etc/init.d/networking restart
* Reconfiguring network interfaces...
(...)
bound to 192.168.1.10 -- renewal in 39314 seconds.
[ OK ]
josemaria@valeria:~$ sudo /etc/init.d/virtualbox-ose restart
* Shutting down VirtualBox host networking
* done.
* Starting VirtualBox host networking
* done.

Luego iniciamos Virtualbox y configuramos la red de las máquinas que queremos hacer accesibles de esta forma:

Configurando VirtualBox con bridge-utils

Y con esto ya si que hemos acabado. En el siguiente pantallazo (ampliable si hacéis click en él) podéis ver como mis dos máquinas virtuales se ven perfectamente (la XP tomando su IP mediante DHCP, el 2003 server con IP estática configurada manualmente), la autenticación de dominio entre ellos se ha hecho perfectamente y ambas son visibles también desde la máquina anfitriona.

Configurando VirtualBox con bridge-utils

ACTUALIZACIÓN: Si has llegado aquí a través de Google, olvídate de ello. Virtualbox tiene ya un modo bridge de forma automática con sólo escoger la opción adecuada en la configuración de red. Lo hemos contando aquí.
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Instalando OpenWrt en la Fonera (y II)

Josemaría | 14 de julio de 2008 | 10 comentarios

fonBueno. Vamos a terminar con esto que dejamos a medias hace un par de días que no me gusta dejar las cosas incompletas. Haciendo un breve repaso de la situación, si lo que quieres es una fonera pero más controladita no sigas leyendo y quédate donde lo dejamos en el anterior texto. Si prefieres jugar con un router inalámbrico más serio acompáñame en los siguientes párrafos.

Empezamos por los preliminares. Vamos a necesitar un servidor tftp, una especie de FTP sencillote que suele usarse como sistema de actualización en dispositivos con pocos recursos como este. En Linux puedes usar fácilmente el tftpd y en Debian o distribuciones derivadas (Ubuntu, Kubuntu, etc.) es tan fácil como instalar los paquetes apropiados (sudo apt-get install tftp tftpd xinetd) y crear un fichero de configuración llamado tftp dentro del directorio /etc/xinet.d con el siguiente contenido:

service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = /tftpboot
disable = no
}

Ahora debemos de crear el directorio que hemos indicado como raíz de nuestro servidor tftp (sudo mkdir /tftpboot), y cambiar sus permisos y propietario (sudo chmod -R 777 /tftpboot; sudo chown -R nobody /tftpboot). Dentro de ese directorio dejaremos los dos ficheros que nos harán falta para sustituir el firmware de la fonera que son openwrt-atheros-2.6-vmlinux.lzma y openwrt-atheros-2.6-root.squashfs. Muy importante: hay que dejarlos “a pelo” en el mismo directorio ya que el tftp no reconocerá ninguna estructura jerárquica. Por último en cuanto a este paso, reiniciamos el servicio xinetd que es el que da soporte a nuestro tftp (sudo /etc/init.d/xinetd restart) y volvemos con la fonera.

Lo primero que necesitamos es instalar Redboot. El procedimiento a seguir, en dos pasos y con un reinicio de por medio, puede verse en los dos siguientes pantallazos de mi terminal:

instalando redboot en la fonera
instalando redboot en la fonera

Para facilitar los “corta y pega” los comandos son estos:

cd /tmp
wget http://fonera.info/camicia/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
mtd -e vmlinux.bin.l7 write openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma vmlinux.bin.l7
reboot

Después del reinicio nos conectamos de nuevo y ejecutamos la segunda parte:

cd /tmp
wget http://fonera.info/camicia/out.hex
mtd -e “RedBoot config” write out.hex “RedBoot config”
reboot

Después de esto nuestra fonera arrancará con Redboot y con la dirección IP 192.168.1.254. El acceso a Redboot solamente puede hacerse durante los primeros segundos una vez que el sistema arranque con lo cual es importante que estemos atentos (aunque, si nos despistamos, no pasa nada: apagamos la fonera y volvemos a intentarlo). El acceso a Redboot ha de hacerse por telnet y a través del puerto 9000.

El proceso completo, desde la conexión a Redboot hasta el reset final puede verse en el siguiente pantallazo:

instalando openwrt en la fonera

Igualmente, los comandos y unas aclaraciones a los mismos:

ip_address -l 192.168.1.254 -h 192.168.1.5
load -r -b %{FREEMEMLO} openwrt-atheros-2.6-vmlinux.lzma
fis init
fis create -e 0×80041000 -r 0×80041000 vmlinux.bin.l7
fis free
load -r -b %{FREEMEMLO} openwrt-atheros-2.6-root.squashfs
fis create -l 0x6f0000 rootfs
reset

En la primera línea es en la que definimos la conexión con el servidor tftp. La primera IP que aparece es la de nuestra fonera y la segunda la de la máquina que aloja al servidor. El otro comando al que hay que prestar atención es el que aparece en la línea 7. Es el momento en que decimos la dirección de memoria donde debe de ubicar la raíz del sistema de ficheros. La dirección hexadecimal que ahí aparece no es arbitraria: es el resultado de restar las dos direcciones que nos devuelve como resultado el comando de la línea 5 (fis free). En mi caso y (en casi todos los ejemplos que he visto en Internet) estos valores son 0xA80F0000 y 0xA87E0000 y por tanto el resultado es el 0x6f0000 que aparece en el comando de la línea 7. Poned atención por si acaso y, si lo necesitáis, ajustad el cálculo vosotros mismos.

Una última advertencia: algunos de los comandos anteriores se demoran bastante (más de 15 minutos en algunos casos). No os impacientéis y no rompáis el proceso ni apaguéis la alimentación de la fonera en el transcurso de estas esperas.

El primer arranque de OpenWrt se hace con el wifi deshabilitado y asignando la dirección 192.168.1.1 a la ethernet de la fonera. Esto posiblemente entrará en conflicto con nuestro router si tenemos una instalación corriente, así que este primer arranque conviene hacerlo con la fonera conectada directamente por cable con nuestro ordenador el cual habremos configurado manualmente con una IP adecuada. La primera conexión deberemos de hacerla por telnet y una vez que asignemos una contraseña al usuario root (con el comando passwd) el acceso por telnet se deshabilitará y las conexiones subsiguientes podremos hacerlas ya por ssh como está mandado:

nuestro primer acceso a openwrt en la fonera

Y listo. Nuestro nuevo router ya está disponible. Ahora toca configurarlo y para eso hay muy buenos recursos en la red. Yo sólo os voy a ayudar a dar los primeros pasos para que los menos habituados a estas lides no se frustren nada más empezar ¿de acuerdo?

Lo primero que necesitamos es reconfigurar el interface ethernet. Para ello editamos con vi el fichero /etc/config/network y allí modificamos la opción correspondiente a la dirección IP y completamos la configuración al menos indicando el router y el dns que queremos que use. El resultado final de este fichero debe de quedar más o menos así:

# Copyright (C) 2006 OpenWrt.org

config interface loopback
option ifname lo
option proto static
option ipaddr 127.0.0.1
option netmask 255.0.0.0

config interface lan
option ifname eth0
option type bridge
option proto static
option ipaddr 192.168.1.4
option netmask 255.255.255.0
option gateway 192.168.1.1
option dns 192.168.1.1

Salvamos los cambios y reiniciamos la red (/etc/init.d/network restart). Después de esto perderemos la conexión de la sesión de ssh (le hemos cambiado la dirección IP al dispositivo, recordad) pero ya podremos integrarlo directamente a nuestra red y en la próxima conexión que hagamos tendrá acceso a Internet, lo cual nos resulta imprescindible para el siguiente paso: instalarle una interfaz web para su gestión.

OpenWrt usa un sistema de gestión de paquetes denominado ipkg que en líneas generales resulta muy similar a nuestro familiar apt-get pero que es mucho más ligero y, por tanto muy adecuado para este tipo de dispositivos. Para actualizar los paquetes del sistema, por ejemplo, ejecutamos ipkg update y a continuación ipkg upgrade. Os suena mucho ¿verdad?

root@OpenWrt:~# ipkg update
Downloading http://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
Updated list of available packages in /usr/lib/ipkg/lists/release
Downloading http://downloads.openwrt.org/kamikaze/packages/mips/Packages
Updated list of available packages in /usr/lib/ipkg/lists/packages
Done.
root@OpenWrt:~# ipkg upgrade
Nothing to be done
Done.
root@OpenWrt:~#

Para instalar X-Wrt, que es la interfaz web de gestión que usa OpenWrt, necesitamos editar el archivo /etc/ipkg.conf y añadirle la siguiente línea:

src X-Wrt http://downloads.x-wrt.org/xwrt/kamikaze/7.09/atheros-2.6/packages

A continuación volvemos a actualizar la base de datos de paquetes (ipkg update) e instalamos el paquete webif (ipkg install webif):

instalando x-wrt en la fonera

Ahora, si ya estamos un poco aburridos de la línea de comandos, podemos continuar a través de esta interfaz web escribiendo en nuestro navegador la dirección que le hemos asignado al dispositivo y usando como usuario de acceso root y la contraseña que le hayamos puesto al mismo. Echadle un vistazo y ya veréis que diferencia en cuanto a posibilidades con respecto a lo que teníamos originalmente…

acceso a la fonera con x-wrt

Sólo os acompaño en una cosa más y ya os dejo solos. Hasta ahora tenemos un router wifi… pero sin wifi ya que este sigue desactivado. Para arreglar esto entramos en Network, seleccionamos Wireless, marcamos la opción de Radio en ON, modificamos, si así lo queremos, el ESSID que trae por defecto, salvamos los cambios y, que no se nos olvide, los aplicamos hasta que la opción de “review changes” esté vacía (esto puede precisar más de una aplicación de cambios). En unos segundos nuestros dispositivos wifi detectarán la nueva señal que, por el momento, está totalmente abierta y sin cifrado alguno.

acceso wifi a openwrt

Para activar el cifrado, en la misma página donde estamos hay un selector marcado como Encription Type que tiene seleccionada la opción de Disabled. Elegimos, por ejemplo, WPA2 (PSK), cumplimentamos la clave que usará el cifrado en el casillero WPA PSK que nos aparece tras haber hecho la elección y se nos solicita que elijamos entre dos paquetes diferentes para su instalación: uno que sólo sirve para PSK y PSK2 llamado HostAPD-Mini y otro que incluye también la opción de autenticación mediante un servidor RADIUS (HostAPD). Elegimos el que creamos conveniente (yo he escogido el segundo porque la autenticación mediante RADIUS es una de las cosas con las que me apetece jugar) pulsando sobre el botón adecuado y listo.

cifrando el acceso wifi en openwrt

No os asustéis por el final del proceso que concluye mostrando en el navegador el fichero .sh que ha ejecutado en el dispositivo. Pulsar la flecha atrás de vuestro navegador y volveréis a la página de configuración de la interfaz inalámbrica del OpenWrt. Si ahora pulsamos F5 veremos que tenemos cambios por revisar. Los aplicamos y con esto nuestra conexión inalámbrica ya estará lista para ser usada de forma segura.

Y ahora ya si que os dejo que sigáis jugando solos ;-)

Toda la documentación que he utilizado y algunos extras adicionales están en el tag fonera de mi del.icio.us. Hay cosas realmente interesantes. Echadles un vistazo si queréis aprender un poquito más o explorar otras posibilidades.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Instalando OpenWrt en la Fonera (y I)

Josemaría | 12 de julio de 2008 | 4 comentarios

fon Tenía pendiente “flashear” un par de foneras para liberarlas y cargarles OpenWRT desde hace casi seis meses pero hasta ayer no encontré tiempo para hacerlo. Lo bueno es que al final la cosa salió bien. Lo malo que tardé más de la cuenta pero estaba tan enfrascado en ello que, cuando me quise dar cuenta, era la 1.30 de la madrugada, así que me quede sin ir al cine a ver la última que le gustó a Tormento (son tan escasas sus críticas positivas que no hay más remedio que atenderlas) que era lo que en realidad tenía pensado para ayer tarde… Os dejo aquí la chuleta para que a vosotros no os pase lo mismo que a mí y podáis disfrutar de una vida social un poco más sana que la mía. Como esto ha salido bastante largo lo voy a cortar en dos pedazos, pero no preocuparos que os voy a cobrar lo mismo ;-)

Lo primero que hay que hacer para meterle mano a una fonera, y eso ya lo sabemos todos, es habilitar el acceso a la misma por ssh. Ya conté por aquí hace más de un año como hacerlo por hardware a través del puerto serie interno. Ahora se trataba de hacerlo por software por aquello de experimentar, ya sabéis. El método más usual de hacerlo consiste en “engañar” a la fonera con un DNS trucado de forma que al reiniciarla, momento en el que se trata de conectar con FON buscando actualizaciones de software, en realidad lo que se descarga es un parche que nos permite acceder temporalmente a ella por ssh a través del puerto wifi. Desgraciadamente parece que este hack sólo funciona con la versión 0.7.1.r2 o inferiores y mis foneras venían ya con la versión 0.7.2.r2 (¡y se actualizaron a la 0.7.2.r3 la primera vez que las dejé que llamaran a casa solitas!), así que parecía claro que lo primero que había que hacer es instalarles una versión de firmware inferior. Vamos a ello.

conectando a la fonera con knetworkmanager Sin conectar la fonera a Internet (para que no actualice su firmware) la encendemos y esperamos a que inicialice. Cuando lo haga podremos conectarnos a ella a través de la señal privada que difunde (MyPlace) usando como clave WPA su número de serie. La fonera arranca con la dirección IP 192.168.10.1 asignada a su interfaz inalámbrica, así que una vez autenticados a través del wifi escribimos esta IP en la barra de direcciones de nuestro navegador y accedemos a la pequeña web de administración del dispositivo con el usuario root y la contraseña admin.

Ahora nos vamos a la sección advanced del menú lateral y reconfiguramos el interface de red (Internet Connection) proporcionándole una IP estática dentro del rango de nuestra red y, muy importante, la IP 88.198.165.155 como servidor DNS. Una vez hecho esto pulsamos el botón de submit, apagamos la fonera, le conectamos el cable de ethernet y la volvemos a encender.

modificando la configuración de red

Una vez que ha rearrancado y que volvemos a tener acceso web a ella, la reseteamos pulsando el botón que tiene en su parte inferior durante al menos 30 segundos para forzar una actualización automática del firmware. El arranque tardará esta vez bastante más tiempo pero cuando este finalice tendremos ya instalada la versión 0.7.1.r2. Pero, cuidado, la configuración de conexión a Internet también se ha reiniciado y vuelve a apuntar al servidor de DNS de FON con lo cual hay que permanecer atentos y en el mismo momento en que tengamos acceso a ella (señal de que ha rearrancado correctamente) hay que desconectarle el cable de red para abortar cualquier nuevo intento de actualización por parte de FON. Ahora volvemos a modificar la conexión de red (la misma que antes), pulsamos submit, apagamos la fonera, le volvemos a conectar el cable de red y la encendemos otra vez. Después de que vuelva a encender (tardará de nuevo un poco más de lo normal aunque no tanto como en la anterior ocasión) dejamos transcurrir unos minutos (tened paciencia: está aplicando los cambios y se trata de un dispositivo lentito) y ya tendremos acceso a ella a través de ssh y del interfaz inalámbrico. Usuario y contraseña siguen siendo root y admin, respectivamente:

entrando por ssh a la fonera

Los siguientes pasos ya se han comentado en muchas ocasiones: hay que habilitar el ssh de forma permanente y deshabilitar las actualizaciones automáticas por parte de FON. Para lo primero tenemos que editar el fichero /etc/firewall.user y descomentar las líneas 22 y 23 dejándolas así:

### Open port to WAN
## — This allows port 22 to be answered by (dropbear on) the router
iptables -t nat -A prerouting_rule -i $WAN -p tcp –dport 22 -j ACCEPT
iptables -A input_rule -i $WAN -p tcp –dport 22 -j ACCEPT

Luego creamos un enlace para que el demonio de Dropbear (el pequeño servidor ssh que usa la fonera) arranque de foma automática en el inicio del dispositivo:

ln -s /etc/init.d/dropbear /etc/init.d/S50dropbear

Para lo segundo basta con editar el fichero /bin/thinclient y comentar la última línea (la 56) que es donde se ejecutan las actualizaciones. La línea debe de quedar así:

# . /tmp/.thinclient.sh

Reiniciamos (reboot) y tras el rearranque ya podremos acceder a ella también a través del interface ethernet y no tendremos que preocuparnos de que una actualización de software no deseada nos vuelva a dejar sin el control de nuestro aparatito.

Hasta aquí, y si modificamos de nuevo los datos de la conexión a Internet volviendo a decirle que use el servidor DNS de FON (213.134.45.129) seguimos teniendo una fonera plenamente operativa y funcional con la salvedad de que ahora el control de lo que se instala en la misma es sólo nuestro y que podemos acceder a ella a través de ssh. En la segunda parte contaré como, a partir de aquí, instalar el firmware de OpenWrt.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Anda, anímate a usar Cacti

Josemaría | 21 de febrero de 2008 | 16 comentarios

herramientasDebe de haber pocos programas tan fáciles de instalar y configurar y tan útiles para un administrador de sistemas como Cacti Yo no la conocía hasta que mi amigo Jose me la recomendó aquí mismo hace ahora justamente dos años y desde entonces es un “primer pick” obligado en cualquier sistema que me encomiendan.

Algunas gráficas de Cacti

La instalación en una debian o derivada es lo de siempre: apt-get install cacti y ya. Para la configuración basta con saber algo de SNMP y como configurar o habilitar este protocolo en los dispositivos que queramos monitorizar. ¿No te animas a probarlo?

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Calendario de conferencias sobre Asterisk en el SIMO

Josemaría | 16 de octubre de 2007 | 4 comentarios

icono de asterisk Este año y en el SIMO hay cita obligada en el stand de Digium dónde se selebrará una atractiva serie de charlas acerca de Asterisk, una de las soluciones de software libre más interesante del panorama actual. El programa completo de las charlas está disponible aquí y a mi me parece particularmente interesante la jornada del viernes día 9 de noviembre, así que si no hay ningún problema estaré por allí.

Visto en Barrapunto.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes
Categorías: eventos, VoIP
Etiquetas: , , ,

Trixbox

Josemaría | 4 de septiembre de 2007 | 13 comentarios

icono de trixbox Donde dije digo, digo Diego. La instalación de Asterisk que tenía pendiente ya está lista y operativa pero al final no he usado ni Asterisk Now ni una instalación manual sobre Debian como tenía pensado. Asterisk Now me resultó aún bastante verde y con muy poca documentación de soporte detrás suya como para apoyarte en el momento en que necesitas hacer algo fuera de las opciones más corrientes. Además el sistema de gestión de paquetes (rpath + conary) me resultaba bastante ajeno y, sinceramente, me daba pereza pelearme con él.

Pero cuando ya estaba a punto de pasar a la opción dos leí que existe otra distribución específica para montar una centralita con Asterisk basada en CentOS y que incorpora freePBX: Trixbox. Mano de santo, oigan.

El equipo que he montado usa una tarjeta Digium wildcard TDM400P con una línea analógica y una Junghanns quadBRI con dos RDSI (cinco canales en total) y da servicio por el momento a algo más de 20 extensiones sitas en la misma oficina dónde está el servidor aunque nuestra idea en breve es extender el soporte a otras oficinas en España. América y Africa de forma que realmente podamos sacarle partido a todos los beneficios de la VoIP (los usuarios en África, por ejemplo, podrían llamar y ser llamados a y desde teléfonos de nuestro país con tarifas locales). Los teléfonos que usamos son aparatos Thomsom ST2030, adaptadores Sipura para teléfonos analógicos convencionales y diversos SoftPhones.

La instalación ha sido engorrosa, no quiero engañar a nadie. En primer lugar debía de montarla sobre una máquina con una versión precaria de Asterisk montada sobre un Ubuntu Desktop y que estaba dando servicio así que me ha tocado hacerlo a ratos entre las 7.00 y las 9.00 de la mañana y sobre un segundo disco duro. En segundo lugar se trata de algo que tenía muy olvidado y hay conceptos de este tipo de instalaciones que es preciso tener muy claros, así que me ha tocado releer mucho sobre el tema. Por el momento no me siento con ganas de escribir un “paso a paso” como otras veces, así que no lo haré a menos que vea mucho interés en los comentarios. Lo que si me gustaría dejaros son algunas referencias para que, si tenéis interés, os sirvan para empezar:

Y, para terminar y darle un poco de color al post, un par de pantallazos de la interfaz web del sistema final:

Panel principal de Trixbox
Panel de centralita de Trixbox

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes
Categorías: distribuciones, VoIP