En este ejemplo tenemos un equipo de una red remota (remoto_lan) que tiene un servicio escuchando en el puerto 88 sólo para la red interna. En esta misma red tenemos un equipo al cual sí que podemos acceder externamente a través de ssh (sshd_remoto).

El proceso sería sencillo (en el equipo de trabajo y siempre como root):

ssh -4 -L localhost:8888:remoto_lan:88 root@sshd_remoto

Explicando la línea anterior:

• -4 => Esto obliga a que use IPv4.
• -L => hace la redirección
  • El primer parámetro es la ip de escucha (en este ejemplo localhost que es nuestra máquina desde donde estamos conectando).
  • El segundo es el puerto de la ip de escucha (el puerto que vamos a utilizar en nuestra máquina).
  • El tercero la IP de la máquina remoto_lan a la que va a reenviar las conexiones el servidor ssh.
  • El cuarto el puerto de la máquina remoto_lan a la que reenviar las conexiones (puerto 88 en este ejemplo).

Osease y resumiendo, cuando te conectas a localhost:8888, el equipo hace una redirección de toda la información a sshd_remoto que a su vez reenvía dicha información a remoto_lan al puerto 88.

Si le pasamos el parámetro -v (que diga todo lo que hace), después de pedir la contraseña debe decir:

debug1: Local connections to localhost:8888 forwarded to remote address 172.26.0.112:88
debug1: Local forwarding listening on 127.0.0.1 port 8888.

Ya sólo habría que apuntar la aplicación que queramos a localhost:8888 para acceder a remoto_lan:88

Pongamos esta vez un ejemplo más tangible y con ips:

Imaginemos esta configuración de red (una red muy normal en ámbitios domésticos o empresas pequeñas).

En nuestra red interna, tendríamos un equipo (ip 192.168.1.123) el cual es accesible desde internet al servicio ssh en el puerto 222 (hemos configurado una redirección NAT en el router para permitir y reenviar el puerto externo 222 al puerto interno 22 de la ip 192.168.1.123). He puesto otro puerto para hacer más completo el ejemplo pero no hay ningún problema por usar el puerto por defecto de ssh (TCP 22). Indiscutiblemente lo que si es necesario es que podamos acceder a la máquina interna desde internet!

Ahora se nos presenta el caso de que tenemos que modificar cierta configuración en nuestro router desde donde estamos (fuera de nuestra red interna) pero nuestro router no nos permite acceder desde fuera. Pues bien, podemos hacer esto:

ssh -4 -L localhost:8888:192.168.1.1:80 -p222 root@80.70.60.50

Con esto estamos creando una redirección desde nuestro puerto 8888 local al puerto 80 del router (ip interna 192.168.1.1) a través del equipo ssh (192.168.1.123)

Ya sólo nos quedaría abrir un navegador y acceder a: http://localhost:8888

ls -lh /dev/dvb/adapter0/
crw-rw----+ 1 root video 212, 0 dic 13 17:00 demux0
crw-rw----+ 1 root video 212, 1 dic 13 17:00 dvr0
crw-rw----+ 1 root video 212, 3 dic 13 17:00 frontend0
crw-rw----+ 1 root video 212, 2 dic 13 17:00 net0

Ya tenemos identificador necesario para dicho dispositivo (212 en este caso).

Ahora, con la máquina contenedor en marcha, vamos a indicar desde el host principal que comparta dichos nodos con el contenedor:

lxc-device -n nombre_contenedor add /dev/dvb/adapter0/

Por cada línea debería remitirnos:

Added '/dev/dvb/adapter0/demux0' to 'nombre_contenedor' as '/dev/dvb/adapter0/demux0'.
Added '/dev/dvb/adapter0/demux0' to 'nombre_contenedor' as '/dev/dvb/adapter0/dvr0'.
Added '/dev/dvb/adapter0/demux0' to 'nombre_contenedor' as '/dev/dvb/adapter0/frontend0'.
Added '/dev/dvb/adapter0/demux0' to 'nombre_contenedor' as '/dev/dvb/adapter0/net0'.

Esto nos ha permitido tanto ceder los recursos del dispositivo (temporalmente) como crear los nodos necesarios en el contenedor. Y digo temporalmente porque cuando reiniciemos el contenedor, perderemos dicha gestión.

Para que sea permanente y ya que con el paso anterior creamos los nodos para su montaje automático, debemos añadir al archivo de configuración del contenedor lo siguiente:

(Normalmente el archivo se encuentra en /var/lib/lxc/nombre_contenedor/config)

lxc.cgroup.devices.allow = c 212:* rwm

Recuerda que 212 es en nuestro caso de ejemplo; deberás especificar el tuyo en cuestión.

Con esto ya quedaría todo funcionando en posteriores reinicios.

El caso es que podemos mandar la señal detener ( -19 ) a un determinado proceso para posteriormente poder iniciarlo de nuevo ( -18 ). Esta señal se puede mandar con el comando kill y el id de proceso o con el comando killall y el nombre de proceso. Como no me gusta dar tantas vueltas, me centraré en killall:

• Pausar proceso: killall -19 <nombre-proceso>
• Reanudar proceso pausado: killall -18 <nombre-proceso>
• Matar proceso: killall -9 <nombre-proceso>

De forma que si queremos pausar por ejemplo firefox, bastaría con un killall -19 firefox y un killall -18 firefox para reanudad este proceso. Hay que tener en cuenta que a partir de la versión 10 (creo recordar) de firefox los plugins (como flash) se ejecutan en un proceso diferente (plugin-container normalmente) de forma que aunque pausemos a firefox, no pausaremos el proceso flash lanzado por el mismo (tendríamos que lanzar  killall -19 plugin-container).

Es muy curioso lo bien que trabaja este sistema con los navegadores al igual que con flash por ejemplo. Se me ha dado más de un caso donde encontraba información realmente buena en una página llena de molestos banners flash lo cual hacía que el hecho de bajar la página se convirtiese en un grandioso reto. Bastaba con pausar dicho proceso (plugin-container), revisar el texto y una vez cerramos la pestaña, reanudarlo de nuevo. De hecho funciona bastante bien con grooveshark o con youtube de forma que puedes pausar flash y al reanudarlo, reanuda perfectamente la reproducción por donde lo teníamos.

Ni que decir queda que para aquellos que no sepan el nombre de proceso, bastaría con el comando ps y grep de forma que para firefox bastaría con:

ps -A | grep fire

donde con ps -A decimos que muestre todos los procesos y con grep fire filtramos en la lista de todos los procesos aquellos que contengan fire.

Los usuarios de KDE tenemos nuestra aplicación de Actividad del sistema desde donde podemos mandar varios tipos de señales a un proceso. Para inicial la aplicación de Actividad del sistema bastaría con pulsar las teclas Crtl + esc

Como vemos en esta aplicación tenemos más que de sobra para manejar dichos procesos. En la parte superior tenemos un campo para filtrar procesos. En este caso filtro por fire (lo cual me saca todo lo coincidente al igual que grep). Vemos que hay 2 procesos, dicho firefox y el proceso para lanzar plugins del mismo.

Al pulsar con botón derecho vemos que podemos mandar entre otras señales:

• Suspender (STOP) => pausar el proceso como hacíamos con killall -19 <nombre-proceso>
• Continuar (CONT) => reanudad el proceso como hacíamos con killall -18 <nombre-proceso>
• Matar (KILL) => matar el proceso como hacíamos con killall -9 <nombre-proceso>

Esta entrada viene inspirada por esta otra http://fedoreando.com/2012/06/09/usando-linux-like-a-boss-pausar-aplicaciones en la cual se explica el mismo proceso pero con el comando kill en vez de con killall. Viendo dicha entrada me vino a la mente que aunque es algo que use habitualmente desde hace algún tiempo, es muy probable que no se conozca en la mayoría de los casos por lo que al ver que era un tanto compleja para el público mayor, decidí exponerla de forma más sencilla.

Hay varias maneras de instalar un equipo por red:

• Iniciar con el disco de instalación y escoger la opción de instalación por red.
• Instalar remótamente mediante vnc o ssh (muy útil para servidores dedicados externos).
• Iniciar por red el disco de instalación

Seguramente se me habrá pasado alguna. En esta guía nos vamos a centrar en “Iniciar por red el disco de instalación”.

¿Qué ventajas nos reporta?

• No necesitamos ningún dispositivo extra (usb, dvd, cdrom…). Lógicamente
• Una vez configurado, instalamos muy fácilmente los clientes.
• Podemos tener todas las versiones/distribuciones que deseemos/configuremos para dicha instalación.

Lógicamente tiene contras, como el proceso de elaboración del sistema, o la necesidad de otro equipo funcionando para entregar “arranques” por red.

La parte de servidor de esta guía la basaré sobre openSuse 11.1 (en 32 bits), pero es válida desde la versión 10.1 hasta la fecha del artículo (también para 64 bit). Ya que no es un servicio que vaya a estar demandado a diario, por facilidad en migraciones y comodidad, lo he implantado sobre una máquina virtual (que es lo que os recomiendo).

Para los clientes, sólo es requerido que puedan iniciar desde red.

Para empezar, lógicamente necesitamos ya el equipo servidor instalado (cualquier tipo de instalación). Una vez cumplido este requisito, nos ponemos manos a la obra:

Lo primero será instalar un servidor DHCP. Si ya tenemos un servidor funcionando en algún equipo de la red y podemos cambiar su configuración, recomiendo hagáis las modificaciones sobre el mismo.

La mayoría de servidores DHCP incluidos en los routers que nos entregan las compañías ISP no nos permite especificar un archivo para el inicio por red, por lo que no son válidos pero podemos establecer una configuración para que funcione con los mismos.

En todos los casos excepto en el que podemos actualizar la configuración del servidor DHCP y este nos permite establecer el archivo de inicio, deberemos:

Instalar el servidor DHCP:

zypper install dhcp-server

El archivo de configuración es /etc/dhcpd.conf. Viene bien comentado cada apartado, pero como es bastante lioso ir explicando que modificar y que nó, recomiendo cambiarle el nombre y establecer uno nuevo con lo básico especificado en cada escenario.

mv /etc/dhcpd.conf /etc/dhcpd.conf.original

Así pues, separamos este apartado en 2 opciones:

Si no tenemos ningún servidor DHCP funcionando en la red (o no podemos modificar sus parámetros):

El contenido que deberemos insertar en el archivo /etc/dhcpd.conf es:

authoritative;
ddns-update-style none;
allow booting;
subnet 192.168.1.0 netmask 255.255.255.0
{
        option subnet-mask 255.255.255.0;
        option routers 192.168.1.1;
        option domain-name-servers 80.58.61.250, 8.8.8.8;
        range dynamic-bootp 192.168.1.100 192.168.1.199;
        default-lease-time 3600;
        max-lease-time 7200;
        filename "pxelinux.0";
        next-server 192.168.1.8;
}

Explicandolo un poco:

• subnet => Indicamos nuestra red para la configuración. Deberemos establecer la ip de nuestra red (el último número debe ser un 0 “cero” en la mayoría de los casos -depende de la máscara de red-)
• netmask => Indicamos nuestra máscara de red.
• option subnet-mask => Nuestra máscara de red (la misma que antes).
• option routers => La ip de nuestra puerta de enlace (suele ser la ip del router).
• option domain-name-servers => Las ip de los servidores DNS separadas por comas.
• range => Rango de ips para cuando se soliciten. Osease, cuando un cliente se conecte y solicite una ip, se la concederá dentro de ese rango.
• default-lease-time => Tiempo (en segundos) por defecto que durará la asignación de ip al cliente. Llegados a este tiempo, el cliente deberá renovar dicha dirección.
• mas-lease-time => Tiempo (en segundos) máximo que durará la asignación de ip al cliente. Llegados a este tiempo, si el cliente no renueva, se libera dicha ip para asignarla de nuevo.
• filename => Indica a los clientes el nombre del archivo a obtener si inician mediante red.
• next-server => Indica la dirección del servidor tftp para iniciar el “arranque” por red. En este caso, pondremos la dirección del equipo que estamos configurando

Si tenemos otro servidor DHCP funcionando en la red el cual no podemos modificar:

El contenido que deberemos insertar en el archivo /etc/dhcpd.conf es:

authoritative;
allow booting;
ddns-update-style none;
subnet 192.168.1.0 netmask 255.255.255.0
{
        option routers 192.168.1.1;
        option domain-name-servers 80.58.61.250, 8.8.8.8;
        broadcast-address 192.168.1.255;
        pool {
              default-lease-time 180;
              max-lease-time 360;
              next-server 192.168.1.8;
              filename "pxelinux.0";
              allow members of "pxe";
              allow members of "etherboot";
              filename "pxelinux.0";
              range 192.168.1.100 192.168.1.199;
     }
 
}
 
class "pxe" {
    match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
}
class "etherboot" {
    match if substring (option vendor-class-identifier, 0, 9) = "Etherboot";
}

En el apartado anterior se explica cada sección, por lo que no lo repetiremos. Es importante actualizar los datos de ip a los vuestros.

En openSuse, también deberemos editar el archivo /etc/sysconfig/dhcpd y establecer en DHCPD_INTERFACE la interface de red conectada normalmente eth0). Podemos comprobrarla con un simple ifconfig.

Reciniciamos el demonio dhcpd con:

rcdhcpd restart

Con esto ya tenemos el servidor dhcp funcionando. Este demonio simplemente lo que hace es asignar una ip a una determinada máquina para evitar el tener que configurarla manualmente.

El siguiente paso será instalar y configurar el servidor tftp. Recomiendo utilizar atftp por ser libre y estar en los repositorios:

zypper install atftp

Editamso /etc/sysconfig/atftpd y establecemos la ruta que vamos a utilizar de forma que quede así:

ATFTPD_OPTIONS="--daemon --user tftp -v"
ATFTPD_USE_INETD="no"
ATFTPD_DIRECTORY="/srv/tftp/tftpboot"

Comprobamos si existe el usuario tftp

cat /etc/passwd | grep tftp

Si no existe, lo creamos

useradd -d /srv/tftp/ tftp

Reiniciamos el servicio:

rcatftpd restart

Si deseamos que inicie automáticamente, haremos:

chkconfig tftp on

Ya por último, nos queda crear el entorno de inicio PXE.

Creamos la estructura en el sistema de ficheros:

mkdir -p /srv/tftp/tftpboot/pxelinux.cfg

Necesitamos el archivo pxelinux.0 el cual se encuentra en el paquete syslinux:

zypper install syslinux
cp /usr/share/syslinux/pxelinux.0 /srv/tftp/tftpboot

Creamos el archivo de configuración de PXE en /srv/tftp/tftpboot/pxelinux.cfg/default con el contenido:

DISPLAY f1.txt
F1 f1.txt
 
default OS11.2
prompt   1
timeout  30
 
# openSuse 11.2 32bits
label OS11.2
  kernel openSuse_11.2_32
  append initrd=initrd_openSuse_11.2_32 splash=silent vga=0x314 showopts install=http://download.opensuse.org/distribution/11.2/repo/oss/
 
# openSuse 11.2 32bits
label OS11.264
  kernel openSuse_11.2_64
  append initrd=initrd_openSuse_11.2_64 splash=silent vga=0x314 showopts install=http://download.opensuse.org/distribution/11.2/repo/oss/

Descargamos los archivos kernel e initrd para openSuse 11.2:

cd /srv/tftp/tftpboot
wget -O openSuse_11.2_32 http://download.opensuse.org/distribution/11.2/repo/oss/boot/i386/loader/linux
wget -O initrd_openSuse_11.2_32 http://download.opensuse.org/distribution/11.2/repo/oss/boot/i386/loader/initrd
wget -O openSuse_11.2_64 http://download.opensuse.org/distribution/11.2/repo/oss/boot/x86_64/loader/linux
wget -O initrd_openSuse_11.2_64 http://download.opensuse.org/distribution/11.2/repo/oss/boot/x86_64/loader/initrd

Creamos el archivo de configuración para mostrar en el inicio a los clientes. Este archivo será /srv/tftp/tftpboot/f1.txt y contendrá:

boot options:
  OS11.2      - Instalación en 32 bit para openSuse 11.2
  OS11.264   - Instalación en 64 bit para openSuse 11.2

Y esto es todo. En verdad, aunque sea largo el artículo, el proceso es bastante rápido.

Si tenemos descargado el dvd o alguna copia del repositorio en nuestra red, podemos cambiar las rutas del archivo /srv/tftp/tftpboot/pxelinux.cfg/default

usbip es un proyecto bastante interesante. Nos permite compartir cualquier dispositivo usb conectado en un equipo para que lo pueda gestionar otro. Puede ser bastante útil para compartir cierto hardware con máquinas virtuales.

Su instalación y configuración en openSuse viene a ser bastante sencilla:

El servidor

Instalación:

zypper install usbip

El software usbip lee la lista de dispositivos conocidos en la ruta /usr/share/hwdata pero en realidad está /usr/share/usbip/ así que con hacer un enlace a dicho archivo bastaría

mkdir /usr/share/hwdata
ln -sf /usr/share/usbip/usb.ids /usr/share/hwdata/

Cargamos los módulos necesarios en el kernel:

modprobe usbip
modprobe usbip_common_mod

Podemos verificar si todo está correcto:

lsmod | grep usbip

Nos saldría algo como:

server:~ # lsmod | grep usbip
usbip                  21540  0
usbip_common_mod       25232  1 usbip
server:~ #

Para hacer automática la carga del módulo al iniciar el sistema podemos añadirlo a la línea MODULES_LOADED_ON_BOOT=”usbip usbip_common_mod” del archivo /etc/sysconfig/kernel

Si hemos añadido la “auto-carga” de dicho módulo, es recomendable ejecutar un:

SuSEconfig

Para iniciar el demonio de usbip, ejecutaremos:

usbipd -D

Nos reportará algo así:

Bind usbip.ko to a usb device to be exportable!

A partir de este momento, ya tenemos el demonio funcionando para compartir el dispositivo.
Sólo nos queda indicarle el dispositivo que deseamos compartir. Para saber el dispositivo a compartir, podemos usar lsusb:

server:~ # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 05ac:9130 Apple, Inc.
Bus 001 Device 004: ID 058f:6362 Alcor Micro Corp. Hi-Speed 21-in-1 Flash Card Reader/Writer (Internal/External)
Bus 001 Device 005: ID 05e3:0718 Genesys Logic, Inc.
Bus 001 Device 006: ID 05ac:9222 Apple, Inc.
Bus 001 Device 007: ID 04d9:0499 Holtek Semiconductor, Inc.
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 046d:08f0 Logitech, Inc. QuickCam Messenger
server:~ #

En principio, compartiré un disco duro usb (05e3:0718 Genesys Logic, Inc.) y la webcam logitech (046d:08f0 Logitech, Inc. QuickCam Messenger).
Con el comando bind_driver –list, listaremos los dispositivos que se permiten compartir:

server:~ # bind_driver --list
List USB devices
 - busid 1-2 (05ac:9130)
         1-2:1.0 -> hub                                                                                                                                                                                              
 
 - busid 1-3 (058f:6362)
         1-3:1.0 -> usb-storage                                                                                                                                                                                      
 
 - busid 1-5 (05e3:0718)
         1-5:1.0 -> usb-storage                                                                                                                                                                                      
 
 - busid 2-1 (046d:08f0)
         2-1:1.0 -> STV06xx
         2-1:1.1 -> snd-usb-audio
         2-1:1.2 -> snd-usb-audio                                                                                                                                                                                    
 
 - busid 1-2.2 (05ac:9222)
         1-2.2:1.0 -> usbhid
 
 - busid 1-2.3 (04d9:0499)
         1-2.3:1.0 -> usbhid
 
server:~ #

Para enlazar dichos dispositivos:

bind_driver --usbip 1-5
bind_driver --usbip 2-1

De momento, si tenemos el cortafuegos funcionando, recomiendo detenerlo para comprobar su funcionamiento y después configurarlo para permitir acceso al puerto 3240 en TCP:

netstat -putan | grep usbipd

El cliente

Instalación:

zypper install usbip

Volvemos a enlazar bien el archivo usb.ids en la ruta correcta:

mkdir /usr/share/hwdata
ln -sf /usr/share/usbip/usb.ids /usr/share/hwdata/

Cargamos los módulos necesarios:

modprobe vhci-hcd

Comprobando…

lsmod | grep vhci_hcd

client:~ # lsmod | grep vhci_hcd
vhci_hcd               26576  0
usbip_common_mod       25232  1 vhci_hcd
client:~ #

Para establecerlo como auto-inicio editaremos el archivo /etc/sysconfig/kernel y actualizar MODULES_LOADED_ON_BOOT=”vhci-hcd”

Si hemos establecido el auto-inicio

SuSEconfig

Ahora listamos los dispositivos compartidos del equipo servidor:

client:~ #usbip -l 192.168.10.5
- 192.168.10.5
     1-5: Genesys Logic, Inc. : unknown product (05e3:0718)
        : /sys/devices/pci0000:00/0000:00:02.1/usb1/1-5
        : (Defined at Interface level) (00/00/00)
        :  0 - Mass Storage / SCSI / Bulk (Zip) (08/06/50)
 
     2-1: Logitech, Inc. : QuickCam Messenger (046d:08f0)
        : /sys/devices/pci0000:00/0000:00:02.0/usb2/2-1
        : Vendor Specific Class / Vendor Specific Subclass / Vendor Specific Protocol (ff/ff/ff)
        :  0 - Vendor Specific Class / Vendor Specific Subclass / Vendor Specific Protocol (ff/ff/ff)
        :  1 - Audio / Control Device / unknown protocol (01/01/00)
        :  2 - Audio / Streaming / unknown protocol (01/02/00)
 
client:~ #

Lógicamente, sustituiremos con la ip del equipo servidor.

Para conectar los dispositivos:

client:~ #usbip -a 192.168.10.5 1-5
8 ports available
 
port 0 attached
client:~ # usbip -a 192.168.10.5 2-1
8 ports available
 
port 1 attached
linux-gqss:~ #

Comprobamos…

linux-gqss:~ # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 004: ID 05e3:0718 Genesys Logic, Inc.
Bus 005 Device 005: ID 046d:08f0 Logitech, Inc. QuickCam Messenger
linux-gqss:~ #

Pruebas y conclusiones

Las pruebas, sinceramente, son bastante escasas. Tras intentar varias veces la configuración de la webcam, no pude hacerla funcionar correctamente. Sólo se mostraba una imagen verde (aunque puede ser debido a los problemas que tengo en el equipo cliente con el driver nvidia).

Sobre el disco duro usb, en una hora aproximada de pruebas, funcionó perfectamente.
Calculé la transferencia media y resultó en 7.143 Mb/s. No es mala transferencia para unas tarjetas de red a 100 Mbits, pero he de decir que las pruebas de transferencia por nfs superan el rendimiento (alrededor de 9.5 Mb/s de media).

El proyecto usbip, ha liberado una etapa bastante temprana del cliente para windows, por lo levanté una máquina virtual y me puse a “trastear”. A pesar de listar los dispositivos, reiteró varios errores al hacer la conexión.

Fuentes:
http://www.howtoforge.com/how-to-set-up-a-usb-over-ip-server-and-client-with-opensuse-11.2

ClearOS es una distribución GNU/Linux derivada de ClarkConnect (la cual deriva de Red Hat) que a diferencia de esta, presume de ser “más libre” y poseer algunas características no disponibles en la versión libre de ClarkConnect. En cierto modo, ClearOS parte de ClarkConnect pero en vez de mantener el hilo principal derivado de Red Hat, lo hace de CentOS.

ClearOS está muy enfocada en su utilización como router gateway (puerta de enlace), servidor proxy, dns, firewall… muy al estilo de ipcop o cualquiera de las distribuciones que repasamos en el artículo Router, firewall, proxy… bajo una máquina potente o poco potente.

Pero al igual que eBox Plataform, está mucho más orientada a ofrecer muchos más servicios muy adecuados para PYMES (pequeñas y medianas empresas).

Entre los servicios más destacados de ClearOS (aparte de los ya nombrados) encontramos:

• Escaneo de virus y spam a través de la pasarela de paso para tráfico http así como imap, pop y smtp (parecido al plugin copfilter de ipcop).
• Filtrado de contenidos/protocolos a través de proxy de una manera realmente fácil y rápida.
• Firewall sencillo con detección de intrusiones.
• Servidor LDAP con autenficación de SAMBA como PDT (muy fácilmente configurable).
• Sistema de impresión (CUPS) y recursos compartidos (sistema de ficheros e impresoras) a través de SAMBA.
• Servidor FTP (ProFTPD), WEB (apache 2 con módulo de php) y MySQL con administración a través del proyecto phpMyAdmin.
• Servidor de correo electrónico (postfix) con soporte de captura de correo de otras cuentas (maildrop), SMTP, POP y WebMail.
• Sistema de backup de configuración del servidor (tanto local como remotamente en el servidor del proyecto).
• Informes de logs sobre cada uno de los servicios.

Para activar ciertos servicios, necesitamos crear una cuenta en www.clearcenter.com. Si optamos por crear una cuenta con suscripción, tendremos algunas características más (como la vpn con ip dinámica o un espacio de almacenamiento para backups).

El sistema se nota bastante robusto aunque algo pesado. Las traducciones a español son incompletas y aunque presume de ser estable, he encontrado algunos errores en la interface.

¿Críticas e impresiones? Allá vamos:

Integrar de una forma bastante notable y consistente todas las autentificaciones de servicios bajo LDAP es algo bastante cómodo y con cierta fiabilidad y escalabilidad.

El sistema de correo parece que funciona correctamente, pero creo que deberían haber hecho más incapié en integrar un groupware. Es una verdadera lástima que no venga integrado de serie ya que es la mejor manera de centralizar notas, contactos, calendarios…

A pesar de ser una distribución orientada totalmente a servidor, no he encontrado ninguna versión de 64 bits, algo que la verdad no comprendo.

Se hecha en falta algunas características bastante buenas para el servidor proxy (squid) como un cacheador para las actualizaciones de los sistemas operativos (como el módulo Update Accelerator para IpCop).

Un sistema de centralización de backups para los equipos de la red de forma que se instale un ligero demonio o servicio en cada equipo y el servidor sea el encargado de realizar dichos backups.

Básicamente, son los detalles que he echado en falta para implantar una “solución completa” para PYMES.

Por cierto, respecto a la instalación, un asistente con pocos y sencillos pasos. Nada donde perderse la verdad. Para acceder a la administración, https en el puerto 81.

nMap es una muy buena herramienta para escaneo de recursos en la red. Entre muchas utilidades para auditorias incluye un par de características muy interesantes; la posibilidad de escanear equipos en un rango de red y escanar los puertos de dichos equipos (o uno sólo).

Su instalación en openSuse viene a ser bien sencilla:

zypper install nmap

A pesar de ser una herramienta de consola, bastaría con hacerse una “chuletilla” con los parámetros más habituales:

• -sS =>Básicamente, un escaneo de puertos TCP.
• -sU => Escaneo de puertos UDP.
• -sP => Comprobación de ping a los hosts (opción por defecto).
• -p [1-65535] => rango de puertos a escanear.
• -A => Detección del software utilizado en el puerto de escucha (opción por defecto).
• -F => Escaneo rápido.
• -NP => Omite la comprobación de ping.

Hay bastantes más parámetros y opciones pero para una comprobación rápida son más que suficientes.

El formato de uso es:

nmap [parámetros] ip_del_host => para un sólo host.

nmap [parámetros] rango_ip/máscara_octal => para un rango de ip.

Si no se especifica un rango de puertos, se utilizan los “más típicos” (denominados ‘well know’).

Los estados de puerto que notifica:

• open => El puerto es accesible y hay un servicio escuchando tras el.
• closed => El puerto es accesible pero no hay un servicio escuchando tras el.
• filtered => El puerto no es accesible normalmente debido a que un cortafuegos lo está filtrando.

Bueno, pasemos a los ejemplos:

• Escanear los puertos “típicos” rápidamente de un host (192.168.1.10):

nmap -F 192.168.1.10

• Escanear el rango de red 192.168.1.x para los puertos TCP  del 2000 al 3000:

nmap -sS -p 2000-3000 192.168.1.0/24

Creo que con estos dos ejemplos queda más que demostrada la facilidad de uso de la herramienta, pero no todos nos sentimos igual de bien frente a la consola. No hay problema si es el caso ya que también posee algunas interfaces gráficas. En concreto, destaco NmapSI4.

Esta interface gráfica nos facilita en la medida de lo posible la mayoría de opciones típicas de uso. Su instalación en openSuse viene de parte del repositorio packman y dado que es un repositorio bastante común, sólo nos quedaría realizar un:

su -c zypper install nmapsi4

En caso de no tener añadido dicho repositorio, lo encontrarán en la opción de repositorios de la comunidad al añadir uno mediante el gran YaST.

Recomiendo que lancemos la GUI como root ( kdesu nmapsi4  por ejemplo). La inteface es bien sencilla y creo que no necesita mucha más explicación.

Para sistemas Windows existen aplicaciones todo en uno que te instalan apache, mysql y php de una forma muy fácil y sencilla; para GNU/Linux y mac, tambien existen dichos paquetes, pero para el caso de GNU/Linux, es más sencillo, práctico y útil instalar dichos servicios desde los repositorios de nuestra distribución. En esta ocasión, me centraré en openSuse.

Bueno, pasemos manos a la obra:

Nos pasamos a administrador:

su

Instalamos los paquetes:

zypper refresh
zypper install mysql mysql-client apache2 apache2-mod_fcgid php5-bcmath php5-bz2 php5-calendar php5-ctype php5-curl php5-dom php5-ftp php5-gd php5-gettext php5-gmp php5-iconv php5-imap php5-ldap php5-mbstring php5-mcrypt php5-mysql php5-odbc php5-openssl php5-pcntl php5-pgsql php5-posix php5-shmop php5-snmp php5-soap php5-sockets php5-sqlite php5-sysvsem php5-tokenizer php5-wddx php5-xmlrpc php5-xsl php5-zlib php5-exif php5-fastcgi php5-pear php5-sysvmsg php5-sysvshm ImageMagick curl apache2-mod_php5

Activamos los módulos de apache que hemos instalado (por defecto se suelen activar, pero así nos aseguramos):

a2enmod suexec
a2enmod rewrite
a2enmod ssl
a2enmod actions
a2enmod fcgid

Iniciamos y activamos los servicios para que inicien automáticamente al inicio:

chkconfig --add apache2
chkconfig --add mysql
/etc/init.d/apache2 start
/etc/init.d/mysql start

Elevamos la seguridad de mysql realizando un sismple asistente

mysql_secure_installation

Con esto y en principio, ya tenemos el servidor funcionando. Realmente fácil y sencillo.

Para afinar un poco más, haremos unas ligeras modificaciones a la configuración de php. Dicha configuración se refleja en el archivo /etc/php5/apache2/php.ini :

Para habilitar el etiquetado corto de la programación de php, lo haremos en la variable:

short_open_tag = on

Los parámetros de memoria límite para cada script así como el tiempo máximo de ejecución se configuran con las variables:

max_execution_time = 60     ; Maximum execution time of each script, in seconds
memory_limit = 64M      ; Maximum amount of memory a script may consume (128MB)

Para los reportes de error en aplicaciones php, podemos definir que se debe mostrar en pantalla. En un servidor en producción, se deberá configurar para que no se muestren, pero en un servidor de desarrollo, es muy útil que muestre absolutamente todos los errores/advertencias para correjirlos:

error_reporting = E_ALL
display_errors = On
log_errors = On

Es muy importante que aunque estemos en un servidor en producción, ‘logueemos’ los errores para poder revisarlos.

Estos son los principales cambios que se suelen configurar. De todas formas, siéntase libre de revisar todo el archivo (tan bien documentado). Sería una buena idea que hiciese una copia del mismo por lo que pueda pasar.

Si necesitamos “hosts virtuales”, añadir un nuevo “sitio virtual” a nuestro Apache es algo realmente sencillo. Para cada sitio, deberemos tener un archivo en /etc/apache2/vhosts.d; Dentro de dicha ruta tenemos un archivo de ejemplo (vhost.template) el cual nos puede guiar. Por ejemplo, voy a definir un “sitio virtual” con dominio midominio.com:

cp /etc/apache2/vhosts.d/vhost.template /etc/apache2/vhosts.d/midominio.com.conf
vim /etc/apache2/vhosts.d/midominio.com.conf

Es imprescindible que el nombre del archivo que definamos termine en .conf
Deberemos hacer los cambios que necesitemos. En mi caso, he dejado el archivo así:

    ServerAdmin mimail@mail.com
    ServerName midominio.com
 
    DocumentRoot /srv/www/midominio.com/web
 
        Options Indexes FollowSymLinks
        AllowOverride All
        Order allow,deny
        Allow from all
 
    ErrorLog /srv/www/midominio.com/logs/error_log
    CustomLog /srv/www/midominio.com/logs/access_log combined
 
    HostnameLookups Off
    UseCanonicalName Off
    ServerSignature On
 
    ScriptAlias /cgi-bin/ "/srv/www/midominio.com/cgi-bin/"
 
        AllowOverride None
        Options +ExecCGI -Includes
        Order allow,deny
        Allow from all

Una vez terminado, y ya que he definido una estructura personalizada, deberemos crear las rutas especificadas:

mkdir /srv/www/midominio.com/web
mkdir /srv/www/midominio.com/logs
mkdir /srv/www/midominio.com/cgi-bin

En la subcarpeta web, guardaremos toda la aplicación. En logs, se guardarán los registros de acceso y errores de este “sitio virtual”. Por último los scripts cgi ya no se suelen utilizar, por lo que podríamos omitir el crear esta carpeta siempre y cuando no la definamos en el archivo de configuración anterior.

Así, cada vez que necesitemos un sitio virtual nuevo en nuestro servidor, bastaría con sacar una copia de este archivo y cambiar los datos que necesitemos.

Por supuesto, cada vez que cambiemos alguna configuración de apache, hay que recargarlo para que la adopte. Como no es un sitio en producción, recomiendo reiniciarlo con (como root):

/etc/init.d/apache2 restart

Para terminar, “la guinda” que nos queda es phpMyAdmin. Me decanto por esta aplicación ya que es la más extendida en los servicios de hosting y una gran aplicación.

Para instalarla, lo podemos hacer fácilmente mediante:

Una vez instalado, podemos acceder mediante http://localhost/phpMyAdmin (o la ip/nombre del equipo donde lo hemos instalado).

Es probable que nos reporte: El archivo de configuración ahora necesita salvoconducto (una frase secreta) (blowfish_secret).

Para este caso, deberemos editar el archivo de configuración /srv/www/htdocs/phpMyAdmin/config.inc.php y actualizar:

$cfg['blowfish_secret'] = ''; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */

Debemos especificar alguna “frase aleatoria” para la encriptación. Estaría bien que contuviese letras, números y todo tipo de caracteres (a excepción de las comillas simples). Esto no es ningún tipo de contraseña y no necesitaremos recordarlo, así que siéntase libre de “chaporrotear las teclas”.

Si este archivo no existe, deberemos copiar el archivo de ejemplo y hacer las modificaciones pertinentes:

cp /srv/www/htdocs/phpMyAdmin/config.sample.inc.php /srv/www/htdocs/phpMyAdmin/config.inc.php

Con estos pasos, ya tenemos funcionando un servidor perfecto para pre-producción. Ahora sólo nos quedaría combinarlo con alguna solución para compartir el sistema de ficheros mediante NFS o Samba y un servidor DNS local y fácil de administrar.

Por cierto, la ruta por defecto es /srv/www/htdocs/. Es lógico que vuestro usuario no tenga permisos en esa carpeta, así que para establecerlos, ejecutaremos (como root):

chown - R tu_nombre_de_usuario /srv

Con esto, hemos establecido todos los permisos de la carpeta www (servidor web) y ftp (servidor ftp) a nuestro usuario.

De bien es sabido que el rey dns en GNU/Linux es BIND. Pero también existen grandes alternativas como MyDNS.

MyDNS es un servidor dns bastante ligero que nos permite almacenar sus datos de registros dentro de una base de datos en MySQL. Esto tiene como ventaja el poder integrarse fácilmente en proyectos que lo requieran.

Otra principal ventaja es que podemos replicar esos datos en distintos servidores y así tenerlos completamente sincronizados prescindiendo de las jerarquías de las réplicas en DNS.

Y creo que la mayor ventaja es que cada vez que realicemos un cambio, no hay que recargar el demonio (como ocurre en BIND).

Su instalación en openSuse sería tan sencillo como hacer click en:

Una vez instalado, tenemos 2 opciones. La primera sería instalar un administrador gráfico para el servidor dns; la segunda sería configurar el servicio manualmente y administrarlo haciendo consultas a mysql directamente. Por comodidad, yo me decanté por un administrador gráfico, por lo que usé MyDNSConfig.

Ya que MyDNSConfig es un gestor escrito en php y que se administra vía web, deberemos tener un servidor web (apache normalmente) con php instalado. No voy a entrar en detalles de cómo instalar Apache y php así como mysql ya que hay muchísima información (y bastante buena) al respecto. De todas formas, tengo un artículo básico sobre esta cuestión (http://miguelcarmona.com/blog/lamp-en-opensuse)

Para realizar la instalación y configuración con mydns, sólo bastará con descargarlo y ejecutar la instalación:

su
cd /tmp
wget http://downloads.sourceforge.net/mydnsconfig/MyDNSConfig-3.0.1.tar.gz?use_mirror=
tar xvfz MyDNSConfig-3.0.1.tar.gz
cd mydnsconfig/install/
php -q install.php

Seguimos el asistente de instalación, y una vez terminado, accederemos a la administración desde http://localhost:8080 (cambiar localhost por la ip del equipo si estamos en otro).

Lógicamente, deberemos tener tanto apache como mysql y mydns ejecutándose:

su
/etc/init.d/apache2 restart
/etc/init.d/mysql restart
/etc/init.d/mydns restart

MyDNSConfig es parte del proyecto ISPConfig (panel de gestión para servidores web y de correo). Es bastante fácil, sencillo e intuitivo como para tener que extender este artículo con una explicación.

Si queremos que el servidor dns y mysql inicien por defecto, haremos:

su
chkconfig --add mysql
chkconfig --add mydns

Así mismo, si queremos que apache también inicie automáticamente (para administrar MyDNS con MyDNSConfig), haremos:

su
chkconfig --add apache2

Para que nuestros equipos resuelvan correctamente con este servidor DNS, deberemos indicarle que el primer servidor DNS a utilizar es la ip del servidor donde lo hemos instalado (por ejemplo, 192.168.10.80). De forma que editaríamos el archivo /etc/resolvers.conf y añadiríamos al principio la línea:

nameserver 192.168.10.80

MyDNS no es capaz de resolver nombres de dominio que no administra, así que para obtenerlos se apoya en un servidor DNS externo (podemos usar el de nuestro ISP por ejemplo). Para especificarle dicho servidor externo, deberemos editar el archivo /etc/mydns.conf y especificárselo:

su
vim /etc/mydns.conf

Buscamos la línea:

recursive =                     # Location of recursive resolver

Y especificamos el servidor DNS

recursive =  80.58.61.250                   # Location of recursive resolver

Reiniciamos el servidor:

/etc/init.d/mydns restart

Y ya tenemos un servidor dns completamente funcional.

PHP quick profiler

PHP quick profiler es una librería para php5 que nos permite tener una consola extra donde poder revisar la ejecución de nuestra aplicación.

Es una gran librería que nos revela información variada como datos recibidos, clases iniciadas, el lugar donde las mismas se inician, número de consultas a la sql, consultas a la sql, tiempo de carga, memoria consumida por la aplicación, archivos incluidos y un largo etcétera.

Podéis hecharle un vistazo en http://particletree.com/examples/pqp/ aunque os dejo algunas capturas de sus distintos paneles:

La instalación y funcionamiento de dicha librería para una aplicación en php5 está muy explicada en la página del autor, por lo que no entraré en detalles

Hay un proyecto que consiste en integrar esta librería dentro del framework codeIgniter (PHP quick profiler for codeigniter).

Para descargar dicha librería, por comodidad, haremos uso de git. Para aquellos que no lo tengan instalado en openSuse, bastará con hacer un:

su -c 'zypper install git'

Procedemos a extraer una copia del código del repositorio git:

git clone git://github.com/danmorin/php-quick-profiler-for-codeigniter.git

Si accedemos a la carpeta descargada (php-quick-profiler-for-codeigniter), veremos 3 carpetas y un archivo readme. Para instalar la librería en codeIgniter deberemos copiar:

• Contenido de la carpeta app_config a application/config/ (si no utilizas los hooks de codeIgniter, sobre escribe el archivo sin pensarlo).
• Contenido de la carpeta app_libraries a application/libraries/
• Contenido de la carpeta app_plugins a application/plugins/ (si no dispone de esta carpeta, créela).

Sólo nos queda habilitar los hooks en el archivo application/config/config.php:

$config['enable_hooks'] = TRUE;

y especificar la línea:

$this->output->enable_profiler(TRUE);

en la función/es que deseemos para lanzar dicha consola.

Por comodidad, lo podemos incluir en el constructor de una clase y así se lanzará para todas sus funciones. Pero, ¿y si lo tengo en el constructor de varias clases y quiero que no se lance? En mi caso, he definido la variable $config[‘php-quick-profiler’] en application/config/config.php y en los constructores:

if( $this->config->item('php-quick-profiler') )
$this->output->enable_profiler(TRUE);

De esta forma, sólo bastaría con cambiar esta variable dentro del config para que se muestre la consola en aquellas clases que la especificamos.

Realmente es muy práctico para depurar una aplicación ya que localizamos rápidamente dónde se encuentra el problema.