Categoría: Linux

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!