Archivos de Categoría: Linux

Site-to-Site con Vyatta y OpenVPN en Debian.

Hoy toca uno de Networking, como el titulo lo dice, esto no es solo de Virtualización!

Si como yo tienes varias localidades (nah!! Son varios servidores Dedicados con VMs las cuales uso para pruebas) y las quieres administrar directamente como si estuvieran conectadas en una red corporativa y sin problemas de port-forwarding, aquí tengo “una solución” para eso.

Desde hace un tiempo no uso pfSense, por qué?  No me gusta OpenBGPd. Es algo lento en pfSense, esa es mi impresión. Además de eso, no creo que soportara una tabla full de BGP, en Vyatta actualmente en mi lugar de trabajo la tenemos en 2 servidores con Vyatta desde nuestro proveedor CLARO.

Bueno, lo de BGP será para otro post, ahora mismo para conectar nuestra localidad remota necesitaremos de un router que soporte OpenVPN en ambos lados, en mi casa tengo Vyatta y en el punto remoto un servidor Debian con OpenVPN instalado desde los paquetes. Necesitaremos los siguientes datos:

Red para el túnel: 10.45.252.252/30

Red en mi casa: 172.22.35.0/26

Red en punto remoto: 172.22.114.0/26

IP WAN en Vyatta-HOME: Dinámico (Gracias al DSL de CLARO)

IP WAN en Debian con OpenVPN: 173.208.168.10

Solo nos falta generar un key con OpenVPN para usarlo en este túnel:

openvpn –genkey –secret static.key

Con estos datos ya podemos configurar…..

En Debian con OpenVPN:

mode p2p          # modo peer to peer

proto udp           # protocolo UDP

lport 1194          # puerto local

dev-type tun     # tipo de interface, TUN porque sera en modo routing.

dev tun-home  # nombre de la interface que se vera en ifconfig

tun-ipv6              # queremos IPv6, don’t we?

comp-lzo          # compression

cd /etc/openvpn         # directorio donde tendremos el key generado.

secret static.key        # el archive con el key

persist-key         # si paso algo con el tunel, mantener el key

persist-tun         # si pasa algo con el tunel, mantener la interface

status /var/log/home.openvpn.status.log # LOGs

log-append /var/log/home.openvpn.log   # mas LOGs

keepalive 20 120

verb 5            # Verbose!

ifconfig 10.45.252.253 10.45.252.254

 

Todo esto lo tendremos en /etc/openvpn en un archivo llamado home.conf, OpenVPN detecta todos los archivos con .conf al final y los ejecuta para crear la interface y todo lo necesario para establecer el túnel.

En el Vyatta:

Aquí es algo diferente ya que los desarrolladores de Vyatta adaptaron OpenVPN a su CLI, si ya ha usado Vyatta, saben lo bien elaborado que esta el CLI.

edit interface openvpn vtun1 #creamos la interface vtun1, no podemos usar nuestros propios nombres aqui.

set local-address 10.45.252.254                #Nuestro lado del tunel

set local-host 10.0.0.2   #IP en la WAN con el DSL de CLARO

set local-port 1194          #no es necesario

set mode site-to-site    #tipo de tunel

set openvpn-options “–com-lzo –persist-tun –tun-ipv6″          #ya que algunas opciones no estan soportadas, existe la opcion de openvpn-options donde podemos usar las que faltan.

set protocol udp              #protocolo a ser usado por el tunel

set remote-address 10.45.252.253          #lado remoto del tunel

set remote-host 173.208.168.10              #IP WAN del servidor con Debian, nuestro Vyatta siempre iniciara la conexion ya que tiene IP Dinamico.

set remote-port 1194    #puerto donde realizaremos la conexión

set shared-secret-key-file          #archivo con el mismo key que usamos en el servidor.

commit

save

nota: no podemos usar comentarios en Vyatta, todo después del # no puede ser introducido en el CLI.

Al momento de hacer commit en Vyatta la configuración se aplica y este iniciara la conexión al servidor con OpenVPN, ahora debemos iniciar el OpenVPN en el servidor con Debian:

/etc/init.d/openvpn start home.conf

Automáticamente nuestro túnel debe subir y podemos hacer ping desde nuestro Vyatta hacia Debian usando la red 10.45.252.252/30.

Desde Vyatta: ping 10.45.252.253

Ahora solo nos faltaría que nuestro Vyatta y Debian sepan que redes maneja cada cual, esto en Vyatta lo podemos hacer así:

set protocol static route 172.22.114.0/26 next-hop 10.45.252.253

En nuestro servidor con Debian:

ip route add 172.22.35.0/26 via 10.45.252.254 dev tun-home

Ya nuestros equipos en ambos lados deben tener conectividad uno al otro usando el túnel.

Moviendo Debian de un servidor físico a Maquina Virtual

Hace varios días que tengo un nuevo host de VMware con ESXi 4.1 (información para un post..) y he decidido mover la mayoría de los equipos que tengo físicos a maquinas virtuales como ya lo había tenido en el pasado.

Buscando información de como usar VMware converter para convertir un Debian físico a VM, la información es algo escasa y muchas veces hacen referencia a correr el software en el entorno grafico el cual no tengo instalado en mi Debian. Por suerte existe rsync.

Los pasos fueron sencillos, primero cree una VM con Debian como Guest OS, luego de realizar una instalación mínima, instalo rsync en ambos equipos y estamos casi listos.

apt-get install rsync

/etc/init.d/cron stop; /etc/init.d/mysql stop

 

Si se esta corriendo otros servicios es recommendable detenerlos. En el servidor físico hacemos lo siguiente:

cd /

rsync –exclude dev/ –exclude proc/ –exclude sys/ –exclude etc/fstab \

–exclude boot/ –exclude etc/mtab –exclude etc/lvm/ -Rav –delete -e “ssh -c arcfour ” \

./ root@maquina.virtual:/

 

Solo queda esperar que rsync termine, apagamos el servidor físico y reiniciamos la VM para terminar con nuestro sistema virtualizado!

Convirtiendo cualquier Linux en Debían, remotamente.

Hace varias semanas tengo disponible un equipo dedicado con muy buenas prestaciones el cual pretendía usar para virtualizar con VMware o como último recurso con XenServer, lamentablemente este equipo no tiene KVM y mucho menos forma de usar virtual media. Gracias a que el proveedor del dedicado tiene un modo “Recovery”, este funciona booteando el server via PXE con un LiveCD de Ubuntu, asi que con este modo podría intentar instalar ESXi.

Mi primer intento fue copiar el archivo imagendd al servidor para luego hacer un “dd if=imagedd of=/dev/sda” esto debería instalar ESXi, inmediatamente recordé que no tendría forma de introducir el password usando el DCUI asi que era una misión casi imposible. Luego pensé en instalar ESXi en un USB y bootear en un equipo con hardware similar al dedicado para asi crear una imagen desde ese USB ya con un password y las configuraciones que necesitaba. Al final me di cuenta que la controladora SATA no estaba en la HCL.

El segundo intento fue instalar XenServer en un equipo con procesador Opteron, el dedicado tiene un Opteron, lamentablemente otra vez el inconveniente al parecer era la controladora SATA, al parecer el Kernel en XenServer no tiene el modulo necesario para ver la controladora.

Ultimo intento fue Debianizar el servidor para instalar Proxmox. Esta ultima resulto y tengo el equipo funcional, no como deseaba pero por lo menos puedo virtualizar.

Si por alguna razón tienes un servidor remotamente inaccesible, y que no tenga Debian instalado y asi lo deseas, gracias a debootstrap esta tarea es más sencilla de lo que se pueda imaginar.

http://www.void.gr/kargig/blog/2009/04/02/howto-remotely-install-debian-over-gentoo-without-physical-access/

El “servidor”  en cuestión es un Fujitsu PRIMERGY MX130, lo bueno de este equipo es que es “green edition” y soporta hasta 16G de RAM. Lamentablemente al parecer para poder instalar ESX/ESXi en el, tendría que tener acceso a consola o por lo menos iKVM.

http://www.server4you.com/templates/images/downloads/ds-py-mx130s1_en.pdf

Apache reverse Proxy y el falso error en DNS.

He decidido usar Apache2 reverse proxy para publicar algunas VM que corren Apache Web Server sin tener que usar esos feos puertos ya que el 80 está en uso por mi Elastix box, todo bien, esto ya lo había hecho antes. Mi sorpresa fue que luego de instalar el modulo [ aptitude install libapache2-mod-proxy-html ] solo tenía que activarlo [a2enmod proxy & a2enmod proxy_html ] y dar inicio a la configuración de los sites que es una combinación de Virtual Name + Apache reverse proxy.

Sorpresa la mía cuando al intentar acceder a uno de los sites me aparece un error diciendo que el DNS fallo al resolver el nombre del host [Reason: DNS lookup failure for: 172.22.35.50mediawiki ]. Después de buscar en Google donde la mayoría de los casos hablaban de que agregarán el host del equipo detrás del proxy a /etc/hosts la solución al final era más fácil de lo que pensaba.

Uno de los Vritual Name que estaba configurando tiene un Proxy configurado de la siguiente manera:

ProxyRequests Off

<Proxy *>

Order deny,allow

Allow from all

</Proxy>

ProxyPass / http://172.22.35.19

ProxyPassReverse / http://172.22.35.19

</VirtualHost>

Este presentaba el error de DNS, a simple vista es difícil pensar que un simple “slash o barra” como quieran llamare, seria la solución a el problema.

ProxyRequests Off

<Proxy *>

Order deny,allow

Allow from all

</Proxy>

ProxyPass / http://172.22.35.19/

ProxyPassReverse / http://172.22.35.19/

</VirtualHost>

Esta configuración funciona de maravillas.

Gracias a este link, no perdí otros 30 minutos intentando encontrar el problema.

Running IPv6 “a la Debian”

En Debian Administration se ha publicado un buen artículo de cómo crear un tunnel IPv6 usando Debian como end-point.

He visto que están usando el nameserver de HE para hacer forwarding de resoluciones DNS y al parecer funciona bien, veré como lo hago ya que mi DNS local es Windows Server 2003, creo que tendré que actualizar a WS2008.

http://www.debian-administration.org/article/Running_IPv6_in_practice

Otra cosa, en un post anterior hable de cómo estaba usando Vyatta, pero tengo para informar que he cambiado a m0n0wall, en Vyatta estuve teniendo problemas cuando no había trafico IPv6 entre los clientes y el router perdía la conectividad totalmente. Esto con m0n0wall no ha vuelto a pasar y estoy bien usándolo como router….

Si tienes IPv6 podrás ver Debian Administrator que al parecer esta estrenando conexión por el nuevo protocolo de Internet.

No mas apt-proxy… apt-cacher es el elegido.

Que nombre para un post!… bueno la cosa es que me he cansado de intentar encontrar el por qué mi apt-proxy nunca termina de descargar los headers, algunas veces duraba hasta 1 hora para eso.
Había buscado el por qué del problema y solo me encuentro con mas personas con el mismo problema y otros recomendando apt-cacher así que lo he instalado y la diferencia es del cielo a la tierra.
En agenda para instalarlo en varios sitios más!!

Monitoreando Windows Server con la ayuda de un Syslog Server.

Si tienes una infraestructura algo grande, digamos más de 10 Servers. No me mal interpreten, 10 Servers no es tan grande, pero a la hora de mirar 10 Event Viewers es algo incomodo hacerlo server por server o simplemente abrir un MMC y agregar todos los Visores de Eventos.

Actualmente en la infraestructura que administro junto con 2 administradores de sistemas, en total seriamos 3 personas administrando un poco más de 40 server. Es una mezcla de Windows y Linux donde Windows gana en mayoría, el objetivo era monitorearlos todos desde una misma aplicación y para Linux estaba más que claro que usaríamos Syslog pero para Windows? ….

Para Windows también usamos Syslog!! Si, syslog to the rescue!, nos ahorramos unos pesitos implementando una solución gratuita y que simplemente descargamos del catalogo de appliances de VMware, les había comentado que estamos usando VMware ESXi para virtualizar varios servicios ¿?, pues si fue bastante fácil implementar este Syslog Server, no voy a profundizar en el proceso usado para el deployment de un appliance descargado desde el catalogo de VMware pero es muy sencillo.

El appliance en cuestión se puede descargar desde este enlace [http://www.vmware.com/appliances/directory/53592 ], pero la cosa no termina ahí, teniendo este syslog funcionando solo nos brindaba la captura de eventos desde los equipos con Debian que son 6 pero aun nos faltaba los eventos de los servidores en Windows y para esto usamos un pequeño servicio que descargamos desde Purdue University, [https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys/ ] ellos han creado un EventLog to Syslog que se encarga de recolectar los eventos desde el Event Viewer y enviarlos al syslog server.

Uniendo todo esto terminamos con un punto centralizado para revisar los eventos de todos los servidores y como no de los equipos Cisco también!

Drivers bnx2 en Lenny.

Si has instalado Lenny y creo que Etch (no recuerdo bien..) en un servidor Dell de la serie PowerEdge x9xx, ya sea 1955 o 2950 te darás cuenta que este no encuentra la tarjeta de red integrada de estos equipos.

La solución es bastante sencilla, solo sigues la instalación del sistema sin network card y luego descargas el .deb desde el sitio oficial [http://packages.debian.org/lenny/firmware-bnx2 ] lo copias a una USB , lo pasas al server y haces dpklg –i paquete.deb, reinicias y listo ya tienes eth0 ready para mandar paquetes. ;)

Debian Logo..

El logo de Debian con personas caminando dentro de el…  :P

Comparing them with cars?

Reading my Google Reader (like always in the morning..) i found on FreeBSD – the unknown giant blog a chart comparing Operating Systems with cars.

 

Linuxrd.org – Primera Comunidad Linux?

WTF!!…. no se como llegue a ese site, pero recuerdo haber leido el URL en algun sitio y escribí en mi FireFox [ http://linuxrd.org ] y en la barra de titulo veo algo muy chocante, 1ra comunidad linux dominicana…. WTF!! (otra vez..) al parecer el propietario de ese blog (por que no es un portal de comunidad) no usaba Linux los días de ExpoLinux y #linuxlatino en UnderNET.

Usando Zimbra.

Hace varias semanas que tengo una maquina con Debian Etch + Zimbra 6.0 RC1 que al principio era 5.0.18GA, la razon del post es hablar un poco sobre este Collaboration Suite que esta dando mucha batalla en el mundo del hosting de correo y por lo que se puede leer en los foros ya se han hecho implementaciones de hasta mas de 20mil cuentas hosteadas en Cluster de todo tipo.

Hablando de mi pequeña instalación que actualmente esta hosteando mails para el dominio arielantigua.com y el cual tratare de usar mas para todo lo relacionado a correo, es una pequeña workstation con apenas 640MB de RAM y un disco de 80GB. Al parecer cuando hablaban de los prerequisitos recomendados no bromeaban por que en esta maquina que actualmente uso com Zimbra Server tiene la siguiente caracteristicas:

ariel@dexter:~$ perl sys.pl
Hostname: dexter – OS: Linux 2.6.18-6-686/i686 – CPU: Intel(R) Pentium(R) 4 CPU 2.26GHz, 2258.466MHz – Processes: 117 – Uptime: 7 Days, 7 Hours, 33 Minutes – Load Average: 1.06 – Memory Usage: 513.86mb/644.99mb (79.67%) – Disk Usage: 10.49gb/73.94gb (14.19%) – Network Traffic (eth0): In/Out 551.7mb/315.8mb
ariel@dexter:~$

Y como se puede ver el Load Average esta en 1.06 en un server que solo es de uso personal, al parecer necesito un upgra y zimbra se lo merece por que es uno de los software mejores elaborados que he usado hasta el momento…

Lastima que para Debian solo ahi version 32bit……. pero ni modos nada es perfecto  ;)

Viva Zimbra !!!!!

Xen, Lenny 5.0.2 y Grub2…..

Después que el Dom0 que hostea el domU encargado de hostear este blog (ya esta devuelta en su hospedaje original…) fallara repentinamente y el proveedor del colo realizara la instalación de Debian Lenny AMD64, resulta que ahora Lenny viene con GRUB2 como bootloader por defecto y que tal si les digo que GRUB1 y GRUB2 no funcionan igual y esto me causo bastantes problemas a la hora de instalar Xen en Lenny.

Lo primero que hice fue instalar el paquete xen-linux-system-2.6.26.1-xen-amd64 que instala varios dependecias y el software principal xen-hypervisor-3.2-1-amd64. El problema se origina cuando se realiza el cambio en el GRUB que ya no es mas menu.lst, ahora se llama grub.cfg y es totalmente diferente a lo que habia visto anteriormente.

Después de que el paquete se instala y realiza los cambios en el GRUB me toca reiniciar para terminar con una máquina que no bootea y que manualmente hay que seleccionar el kernel que instala por defecto para poder usar la máquina pero sin Xen….. después de mucho googlear me encontré con que tendría que modificar el archivo grub.cfg aunque fuera en contra a la primera linea de este archivo que indica que no tenemos que modificarlo manualmente pero esta fue la única manera que la máquina subio con el kernel Xen.

Aquí esta la entrada en grub.cfg, la posteo aquí por que fue algo dificil encontrar que era lo que tenia que agregar…

menuentry “Debian GNU/Linux, linux 2.6.26-1-xen-amd64″ {
set root=(hd0,1)
search –fs-uuid –set b1feaf41-ad71-487e-8d1e-f0fa9d1c0b71
multiboot /boot/xen-3.2-1-amd64.gz dom0_mem=384M noreboot
module   /boot/vmlinuz-2.6.26-1-xen-amd64 root=UUID=b1feaf41-ad71-487e-8d1e-f0fa9d1c0b71 ro
module   /boot/initrd.img-2.6.26-1-xen-amd64
}

Ubuntu Server 9.10 y su Enterprise Cloud..

Como muchos sabran… ayer se libero la version 9.10 de Ubuntu en sus versiones Workstation y Server, el topic del post no es para anunciar ni mucho menos, es simplemente para anotar que al version Server de esta distribucion ahora viene con Eucalyptus (algo que desconocia hasta el dia de ayer) y ayuda con la integración de Amazon EC2.

Desde que lei ese Feature nuevo en Ubuntu me dieron ganas de descargarlo, ya saben esto del Cloud es algo que todos queremos probar. Pero mi sorpresa ha sido cuando encuentro un enlace con detalles de esta funcionalidad en Ubuntu Server y leo que el Hypervisor es KVM y no Xen… Sera por que me gusta Xen y nunca he usado KVM ? sera que es cierto que Xen esta perdiendo territorio? …

Creo que estare habilitando un equipo con los prerequsitos necesarios para instalar esta version de Ubuntu y probar su Cloud…..

Enalces:

http://www.ubuntu.com/products/whatisubuntu/serveredition/cloud

http://www.ubuntu.com/products/whatisubuntu/serveredition/cloud/UEC

http://doc.ubuntu.com/ubuntu/serverguide/C/eucalyptus.html

Page 1 of 3123