En búsqueda de un panel de control para el servidor de un cliente, que fuera centrado en el alojamiento web encontramos el bluequartz. Un panel de control muy fácil de usar, pero de momento no muy fácil de instalar.
El panel de control del que hablaremos está basado en el código del Cobalt Raq550, que fue la última versión que sacó Sun, antes de decidir que era un mercado de muy baja demanda y dejar a un lado el soporte de los servidores de alojamiento cobalt.
Se compraron y vendieron decenas de miles de servidores cobalt para realizar alojamiento, tan buen mercado que Sun decide comprarlo, pero inmediatamente después que lo compra, comienzan a quitarle el apoyo, no se veían actualizaciones tan constantes como antes, es más ya sobre el año 2002-2003 deciden descontinuar toda la línea.
El panel de control de cobalt es muy simple, no tiene soporte para resellers. Pero es muy fácil de entender y manejar tanto para el administrador del sistema como para los usuarios de éste.
En un artículo anterior explicamos cómo instalar bluequartz para centos 3, pero puede que hayan personas o empresas que mantengan sus viejos cobalt raq4 ó raq3 con varios sitios que quieran migrar.
El mover manualmente los sitios es un proceso bien complicado sobre todo si no se tienen las claves de los usuarios. Sin embargo existe una utilería para raq4 (cuando hable de raq4 puede asumirse que raq3 también funcionará) llamada CMU que permite hacer un vaciado de los sitios web de un servidor y que además permite tomar de ese dump (vaciado) e importar los sitios hacia un nuevo servidor.
El proceso será bien simple:
1- Instalaremos cmu en el servidor viejo
2- Instalaremos cmy en el servidor BQ
3- Exportaremos los sitios via cmu en el servidor viejo
4- Transferiremos los sitios exportados (tar.gz) hacia el BQ
5- Importaremos los sitios (tar.gz) en el servidor nuevo.
Instalando cmu tools en el viejo RaQ4
Es muy fácil, en este sitio se pueden encontrar las versiones de cmu tools para diferentes tipos de RaQ:
Escoger de este sitio la versión más adecuada para su RaQ e instalarlo usando el panel de control del cobalt que tenga. No debe presentar mayor inconveniente la instalación.
Instalando CMU tools en el BQ
Este paso yo lo he hecho para centos 3. Normalmente el paquete que vemos aquí funciona muy bien:
http://www.nuonce.net/bq/BQ-5102R-CMU-2.53.pkg
Aunque una vez usé esta versión pero está un poco vieja:
http://www.pacificdreams.net/cms/index.php?option=com_content&task=view&id=20&Itemid=40
Aunque hay personas que reportan que las cmu tools del raq550 del sitio de cobalt(ftp://ftp-eng.cobalt.com/pub/users/jeffb/cmu/beta/) igual funcionarán en el bluequartz.
CMU son herramientas hechas en perl y cualquier instalador para raq550 o para Bluequartz (independientemente de la versión del SO) debe funcionar bien.
Exportando los sitios de nuestro viejo cobalt:
Listo, una vez instaladas estas herramientas en ambos servers (el viejo raq y el BQ) podemos exportar muy fácilmente los sitios que tenemos en nuestro cobalt (el servidor viejo, el que queremos eliminar) usando:
cmuExport -d /home/export -n “www.sitio1.com,www.sitio2.com,www.sitio3.com,www.sitioN.com”
La -d indica el directorio donde se guardarán los archivos exportados (en este caso lo definí en /home/export)
El switch -n nos permite especificar una lista de sitios a migrar. Entiendo que si no se pone -n “...” se exportarán TODOS los sitios web que hay en el servidor. Pero yo personalmente prefiero ir poco a poco, comenzando digamos por los que empienzan con a*, b* y así poquito a poco para saber qué sitio se ha migrado y qué sitio no se ha migrado. Se pueden especificar con el switch -n varios sitios, no creo que haya límite impuesto, yo normalmente voy de 5 a 10 sitios por vez).
El proceso de exportar demora un rato, en dependencia del tamaño de los sitios que se estén exportando y de la velocidad del procesador de nuestro viejo cobalt raq4, o raq3 o raq550.
Una vez acabe de exportar nos dirá que todo está listo y veremos una serie de archivos en el directorio que hayamos escogido (en mi caso /home/export) y debemos pasar todos estos archivos (via ftp es una sugerencia) al nuevo servidor con bluequartz.
Sugiero que en el BQ, se pongan estos archivos en el mismo directorio que usamos en el cobalt. Es decir, en el bluequartz creen un directorio llamado /home/export y pasen por ftp todos los archivos que tenemos en /home/export del cobalt.
Importando los sitios hacia nuestro bluequartz
Listo, ya tenemos los archivos que exportamos en nuestro cobalt. Los hemos pasado por ftp hacia un directorio, en nuestro caso los hemos puesto en nuestro BQ en el directorio /home/export
El proceso de importación es casi idéntico, sólo que tenemos que especificarle la dirección IP bajo la cual importaremos los sitios. Se usa la utilería cmuImport:
cmuImport -d /home/export -i 192.168.1.1 -n "www.sitio1.com,www.sitio2.com,www.sitio3.com,www.sitioN.com”
Facilito, si se fijan sólo cambia cmuExport del ejemplo anterior por cmuImport y además el switch -i que indica la IP de nuestro servidor bajo la que importaremos los sitios.
Esto de poner la IP es vital, sino se nos pueden dar bonitas sorpresas, por ejemplo a veces pone la IP del servidor cobalt viejo en nuestra máquina y no podemos acceder desde una máquina a la otra pues el BQ piensa que es la misma (tiene las dos IP).
El proceso de importación demorará un poco pues tiene que recargar todos los usuarios y demás, y nos irá explicando si algo falla. Si algo fallare habrá que solucionarlo en el cobalt (a veces suceden cosas raras con las cuotas de algunos usuarios) y volver a exportar ese sitio e importarlo para el BQ. Es muy raro, pero puede ocurrir que una cuota esté pasada o algo así.
Conclusiones
El proceso de migración es muy simple como se puede apreciar, en nuestro BQ terminarán los sitios con sus usuarios creados perfectamente, posteriormente a realizarse la migración sugerimos:
1. Se cambien los DNS de una vez para que las personas comiecen a usar el BQ en vez del viejo cobalt
2. Una vez el dns esté cambiado y los usuarios estén trabajando con el BQ, proceder a borrar el sitio o los sitios ya migrados en el cobalt viejo.
Un detalle a tener en cuenta, si en el viejo cobalt teníamos sitios que usaban mysql, hay que hacer la migración de la BD mysql manualmente, es decir usando el comando mysqldump y creando el usuario y la clave en el BQ. Esto es ya que el cobalt no tenía nativamente incluido el mysql y por lo tanto las utilerías para exportar/importar los sitios en cobalt no incluyen la migración de mysql.
Nosotros también ofrecemos servicio de migración de sitios desde cobalt hacia BQ, no dude en contactarnos en caso de requerir de nuestros servicios profesionales y experiencia en este campo.
¿Cómo hacer backups en BlueQuartz?
Bien, una de las cuestiones fundamentales a la hora de tener este servicio es: cómo hacer backups automáticos en nuestro servidor bluequartz.
Para eso usaremos el paquete CMU que instalamos en nuestro BQ (la descripción de la instalación puede ser obtenida aquí)
El paquete cmu tiene una utilería llamada cmuExport que permite que sean exportados uno o varios sitios en nuestro servidor. Por exportar quiero decir que toma toda la información, usuarios, contraseñas, correos guardados, sitio web, y los comprime en unos paquetes del tipo tar.gz.
Ahora, existe una utilería hecha para cobalt raq3, raq4 y raq550 que permitía tomar TODOS los sitios web de nuestro servidor y exportarlos hacia un directorio determinado y/o hacia otro servidor. Se llama raqbackup.sh y lo mejor de todo es que nos permite también trabajar con el bluequartz nuestro!
El realizar la instalación es bien sencilla, entrar al sitio de ellos:
A la final nos mostrará en un cuadrito (en el paso 6) con los comandos que debemos copiar y pegar así mismito! En nuestro servidor. Estas 6 o 7 líneas lo que harán será crear el script en nuestro servidor, basado en los datos que les acabamos de dar.
Normalmente el script se llama raqbackup.sh y está en /etc/cron.daily, ahi lo pueden editar si desean.
Una vez hayamos pegado todos los comandos en nuestro servidor y que se haya creado /etc/cron.daily/raqbackup.sh podemos probarlo ejecutar:
/etc/cron.daily/raqbackup.sh screen
Esto nos hará un respaldo pero sacará los resultados por pantalla (para eso el screen) si algo falla tenemos que revisar qué puede ser.
A mi me falló solo una cosa, y es que el script de raqbackup.sh (editarlo) cuando llamaba al cliente ftp (ftp -i -n) le ponía un switch adicional: -p, este switch ya no existe para el cliente ftp de centos, y por lo tanto fallaba, así que eliminé -p de esa linea y todo funciona bien.
Migrando los DNS de un RaQ4 hacia BlueQuartz
En un artículo anterior explicamos cómo migrar los sitios de un cobalt raq550 o raq4 hacia un servidor CentOS3 con BlueQuartz.
Como bien comentamos allá, esta migración es solamente para los sitios y no incluye la migración de los DNS en caso de estar alojados en el servidor cobalt.
el proceso de migración es bien simple, sencillamente en el raq4 (solo lo he hecho para el raq4 y entiendo funciona solo para el raq4) procedemos a buscar dentro de /var/named o en /etc/named un archivo llamado: records y pasarlo por ftp hacia el BQ.
Ya podemos salir el viejo cobalt raq4 y entrar al BQ.
Una vez en el BQ bajemos la siguiente utilería:
cambiemos los permisos:
chmod +x dnsImport
y ejecutémosla:
./dnsImport records
Es decir, la ejecutamos y le indicamos que use el archivo records (tengamos ambos archivos dnsImport y records en el mismo directorio).
El sistema se ocupará solito de crear todas y cada uno de los records y zonas de DNS en nuestro BlueQuartz, basándose en el archivo records.
Al terminar, podemos cambiar en el registrar de nuestro dominio, la IP del DNS, en vez de la IP del viejo RaQ4 ponemos la IP del nuevo BQ y todo debe funcionar de una.
Migré en cuestión de minutos los dns de más de 100 dominios de un raq4 hacia nuestro BQ sin mayor inconveniente.
Cualquier duda o pregunta no duden en contactarnos, también podemos ayudarles en la migración completa de los DNS.
Hoy, cuando intenté usar cmuExport en mi servidor para realizar los respaldos semanales de mi bluequartz, me encontré conque éste, que hasta la semana pasada funcionaba, de repente había dejado de trabajar.
Ahora por ejemplo si yo intentaba el comando:
cmuExport -d /home/raqbackup/data
me respondía inmediatamente con un error:
Cannot export on a
Y ahí se quedaba... no puede exportar a...? A dónde? Vamos, a mi servidor!!!! Exporta!! pero nada, el comando tozudamente se negaba a exportar.
Así que lo abrí (vi /usr/sbin/cmuExport) y busqué eso de “Cannot export on a”, y encontré que este error sale cuando se chequea la versión de cobalt/bluequartz basado en una función llamada getBuild,
Edité el archivo /usr/cmu/perl/Global.pm donde está la función getBuild y encontré que es bien simple, la función getBuild tiene una lista de posibles versiones de cobalt listadas, y son estas:
Esta lista, la compara contra la versión de nuestro cobalt que está listada en /etc/build
Los contenidos actuales de mi /etc/build son estos:
cat /etc/build
build 20050703 for a 5101R in en_US
En efecto, 5101R no aparece listado entre las posibles versiones de cobalt de mi función getBuild, así que lo agregué a mi lista en /usr/cmu/perl/Global.pm, ahora queda así:
# RaQ Builds
"2700R", "RaQ1",
"2799R", "RaQ2",
"2800R", "RaQ2",
"3000R", "RaQ3",
"3001R", "RaQ4",
"3100R", "RaQ4",
"3500R", "RaQXTR",
"3599R", "RaQXTR",
"4100R", "RaQ550",
"5101R", "RaQ550"
después del primero RaQ550 puse una coma y agregué debajo una línea poniendo mi versión. Y listo, ahora me trabaja el cmuExport.
Esto lo dejo como constancia porque me parece que sucederá de nuevo si la gente que realiza el bq sigue cambiando /etc/build, yo les sugerí que no lo hagan para que no se rompan las aplicaciones que trabajan basadas en la info de /etc/build, pero no sé si colaboren en este caso. Por mi parte será simple siempre ir cambiando Global.pm
En búsqueda de un panel de control para el servidor de un cliente, que fuera centrado en el alojamiento web encontramos el bluequartz. Un panel de control muy fácil de usar, pero de momento no muy fácil de instalar.
El panel de control del que hablaremos en este pequeño howto, está basado en el código del Cobalt Raq550, que fue la última versión que sacó Sun, antes de decidir que era un mercado de muy baja demanda y dejar a un lado el soporte de los servidores de alojamiento cobalt.
Cobalt en su tiempo fue un suceso, pues era un appliance que venía con panel de control incluído. Este panel no venía con restricciones, es decir, al usuario comprar el appliance, no habían restricciones en cantidad de usuarios ni tráfico ni demás.
Se compraron y vendieron decenas de miles de servidores cobalt para realizar alojamiento, tan buen mercado que Sun decide comprarlo, pero inmediatamente después que lo compra, comienzan a quitarle el apoyo, no se veían actualizaciones tan constantes como antes, es más ya sobre el año 2002-2003 deciden descontinuar toda la línea.
El panel de control de cobalt es muy simple, no tiene soporte para resellers. Pero es muy fácil de entender y manejar tanto para el administrador del sistema como para los usuarios de éste.
Acciones del administrador:
Los sitios web, pueden ser limitados en su cantidad de usuarios, espacio en disco total, si usa o no php, frontpage, perl, ssi. Un sitio web puede tener varios administradores y al menos se le debe definir uno para que pueda realizar las labores de administración y manejo de usuarios.
Acciones del administrador del sitio:
El usuario administrador del sitio puede a su vez crear nuevos usuarios, administradores o no, puede subir el sitio web vía ftp. Al hablar de definir usuarios queremos decir que puede crearlos, eliminarlos o suspenderlos, cambiarles las claves o la cuota de espacio en disco, activarles el pop3 y demás características propias de un usuario.
Acciones del usuario normal:
El usuario normal puede leer su correo, tener su propio sitio web bajo su nombre de usuario y puede cambiar sus datos como nombre y clave. Básicamente estos usuarios son las cuentas de correo que se crean bajo el dominio en cuestión. Los usuarios administradores aparte de tener las posibilidades anter mencionadas, también son usuarios normales a los efectos de que pueden recibir correos y demás características.
Definiendo la distribución de linux a usar:
Una de las cuestiones más importantes a la hora de instalar un panel de control es definir la distribución linux a usar. Bluequartz permite básicamente tres distribuciones sistemas operativos al momento, el uno es fedora 1, el otro es CentOS-3 y CentOS-4
Los programadores que están laborando en esta bonita tarea, usaron al inicio el RedHat 9, pero poco tiempo después de estar trabajando en esto se toparon con la sorpresa de que redhat dejaba de soportar versiones que no fueran Enterprise Linux y se dedicaban de a lleno a su versión de Redhat Enterprise Linux. RedHat sugirió como variante al fedora, pero aclararon que iba a ser muy experimental y su ciclo de vida bien corto.
Muchos que seguían la línea de redhat 9 decidieron entonces irse con el proyecto fedora el cual carece de actualizaciones durante largos periodos de tiempo. Por ejemplo el fedora 1 salió a fines del 2003 y para fines del 2004 ya había dejado de ser soportado lo que obligaba a las personas a cambiarse a versiones más modernas.
Las empresas de hosting no pueden costear los gastos de cambiarse a versiones más modernas constantemente, por lo que el fedora no es una opción para alguien que requiere un servidor actualizado y funcionando durante años.
CentOS sin embargo es una opción basada en redhat enterprise linux, conocido como clon de redhat que tiene al menos actualizaciones hasta el año 2008 a 2010. La idea es que primero se pondrá viejo el hardware que no el software incluido en él.
Al momento de escribir este artículo centos-3.6 es una versión basada en RHEL 3 que lleva ya algunos años en el mercado, estable y funcionando sin mayores problemas, por lo que esta es la versión que usaremos para instalar nuestro bluequartz.
Debemos aclarar que también hemos probado la instalación en CentOS 4 e igual funciona muy bien.
De usted desearlo, le podemos enviar los cds de CentOS 3 o CentOS 4, por favor contáctenos para ponernos de acuerdo con el envío.
Instalando la distribución (CentOS 3):
Proceder a instalarla normalmente, de ser posible sin el ambiente gráfico, normalmente un servidor requiere todos los recursos para trabajar y no hace falta tener el ambiente gráfico que además consume espacio en disco.
Crear al menos una partición /home independiente que ocupe el mayor espacio posible.
Crear también /usr, /var y de ser posible /boot. /var y /usr con unos 3 gigas cada una. /boot con 100 megas. Recuerden, para /home todo el espacio posible y en partición propia (independiente de /).
Bajando el bluequartz:
En este sitio obtener la última versión:
ftp://bluequartz.org/pub/BlueQuartz/5100R/CentOS3/tgz/
En este momento es la:
BlueQuartz-5100R-CentOS3-2005070301.tar.gz
Una vez bajada, abramos el paquete:
tar -zxvf BlueQ*.tar.gz
veremos que nos crea un directorio que comienza con BlueQuartz entremos y ejecutemos el instalador desde la consola local:
./install.sh
El instalador comenzará chequeando qué paquetes hay instalados. Si requiere de algún paquete que no está instalado, lo indicará.
Por favor, también instalar el perl-DB_File:
yum -y install perl-DB_File
Al acabar de instalar, proceder a verificar que pueden entrar:
http://localhost/login
Debe poder entrar con usuario: admin y clave: admin (por supuesto al entrar cambien la clave)
Problemas
Nosotros no pudimos entrar con admin / admin nos decía que your login session has expired. Además, no podíamos entrar como root y nuestra clave, como que el sistema se alocó.
Después de muchas pruebas hallamos una solución y tenemos una teoría sobre lo que sucedió:
No creamos la partición /home (por eso insisto anteriormente en crearla aparte), por lo tanto las cuotas no se crearon dentro de /home y falló toda la parte de cuotas, cuando se quiso agregar el usuario admin en la base de datos del bluequartz, este falló y por eso no podíamos entrar.
Nuestra sugerencia a todo el que tenga este problema es que reinstale todo desde cero y cree /home correctamente. Nosotros la solución que hallamos fue editar:
vi /usr/sausalito/handlers/base/disk/modquota.pl
Buscar una linea que dice:
my $ok = Disk::setquota($cce, $obj, $oid);
Comentarla (agregándole # al inicio) y debajo de la línea ya comentada poner my $ok = 1; quedaría así:
#my $ok = Disk::setquota($cce, $obj, $oid);
my $ok = 1;
De esta forma al chequearse las cuotas el sistema saldrá inmediatmaente con un ok y no fallará.
Una vez hecho esto, ejecutar el script de creación del administrador:
/usr/sausalito/constructor/base/user/50_addAdmin.pl
Los que instalaron los paquetes de cuota y crearon la partición /home, posiblemente no tengan problemas como yo presenté.
Los que apliquen este cambio, por favor una vez puedan entrar (intenten de nuevo ir a http://localhost/login y entrar con admin / admin y ya podrán) por favor inmediatamente crear una partición /home y quitar este cambio que hicimos de saltarnos la verificación de quotas pues es sólo para arreglar lo del admin.
Lo más sugerible es que hagan la instalación como les indicamos antes, es decir creando /home, para esto, vuelvan a comenzar instalando el centos y creando ahora sí una partición /home lo suficientemente grande como para que permita varios sitios web (muchos gigas).
Al momento tenemos este servidor con centos3 y bluequartz instalado con más de 130 sitios web ejecutándose sin problemas mayores durante ya varios meses.