Directadmin utiliza el sistema de quotas del sistema operativo para calcular el espacio que está siendo utilizado por cada usuario. A veces, por diversas circunstancias, puede ser que necesitemos recalcular estos datos. Particularmente, en estos días tuvimos un problema con el acceso a un dispositivo que generó problemas en la ejecución del comando repquota y cuando solucioné el problema, tuve que recalcular la quota de todos los usuarios del sistema. Me pareció que sería útil explicar cómo hacerlo, porque si bien es algo que está explicado en la Knowledge Base de Directadmin, allí está en inglés.

Para que el sistema recalcule las quotas, es decir, analice todo el filesystem verificando el uso del disco y cree, confirme o repare los archivos de quotas, necesitamos correr el comando quotacheck. Para ello necesitamos deshabilitar las quotas, chequear y volver a habilitarlas.

# /sbin/quotaoff -a
# /sbin/quotacheck -avugm
# /sbin/quotaon -a

Esto tomará algunos minutos (particularmente el proceso quotacheck). Luego de lo cual podemos esperar que Directadmin corra el tally y recalcule los valores para cada usuario, o podemos indicarle explícitamente que lo haga en este momento. Para ello debemos agregar la tarea del tally a la cola:

# echo "action=tally&value=all" >> /usr/local/directadmin/data/task.queue

El tally se ejecutará cuando corra el proceso dataskq de Directadmin (que se ejecuta cada minuto). Podemos ver los logs de este proceso en /var/log/directadmin/system.log.

Pero si somos demasiado impacientes o queremos ver información de debug, podemos correr explícitamente el dataskq.

# /usr/local/directadmin/dataskq d10

Listo. Una vez que Directadmin re-procese todos los usuarios, los datos de consumo de disco de cada uno se habrá sincronizado con la información actual del sistema.

En esta pequeña guía veremos cómo actualizar muy sencillamente el software de nuestro servidor Directadmin usando Custombuild. Ya en otro artículo habíamos visto lo sencillo que era instalar software con Custombuild. En esta oportunidad, veremos que es igual de sencillo utilizarlo para mantener nuestro software actualizado.

Lo primero que debemos hacer es un update para descargar las nuevas versiones de las aplicaciones:

# cd /usr/local/directadmin/custombuild
# ./build update

Ahora que tenemos actualizado el propio custombuild, verificadas las versiones locales del software y descargadas las actualizaciones, podemos ver qué podemos actualizar.

# ./build versions

Esto nos va a mostrar por cada uno de los programas y librerías que maneja Custombuild, qué versión tenemos instalada y si hay una nueva para instalar. En base a esta lista, lo que podemos hacer es instalar la actualización para un programa/librería en particular, o actualizar todo.

Por ejemplo, si queremos actualizar solamente Apache, usaremos:

# ./build httpd

En cambio, si queremos actualizar todo, ejecutaremos:

# ./build update_versions

El Cron

Custombuild permite instalar un cronjob para manejar las actualizaciones. Tiene dos funcionalidades: avisarnos por mail cuando hay actualizaciones y actualizar automáticamente el software. Esto se configura en el archivo options.conf de Custombuild.

#Cron settings
cron=yes
email=nuestroemail@dominio.com
notifications=yes
updates=no

La variable “cron” habilita/deshabilita el cronjob. Si lo queremos instalar tiene que estar en “yes”. La variable “email” es la dirección donde recibiremos las notificaciones. Luego “notifications” habilita/deshabilita las notificaciones por email y “updates” habilita/deshabilita la actualización automática.

Personalmente, recomiendo no activar las actualizaciones automáticas, pues puede generar problemas inesperados en momentos en que no podemos resolverlos. Es preferible hacerlas manualmente cuando lo consideremos adecuado. Por otro lado, el cron se ocupa de actualizar automáticamente las aplicaciones web (los webmails), lo cual no suele traer problemas.

Para instalar el cron debemos configurar las opciones mencionadas en el options.conf (indicando cron=yes) y luego ejecutar:

# ./build cron

Este post viene un poco postergado. Hace algún tiempo que empecé con un pequeño proyecto y tenía pensado escribir una entrada en el blog para presentarlo, pero por distintos compromisos no he podido hacerlo hasta ahora, así que aquí va.

Para los que no lo sepan, Directadmin tiene una API para realizar distintas operaciones en el panel de control desde otra aplicación. La API no es más que una serie de URLs que reciben información por HTTP POST, ejecutan una acción y devuelven un resultado. De esa forma se pude acceder a muchas de las operaciones que uno realiza manualmente a través del panel (salvo algunas que parecen no estar muy bien implementadas/probadas).

En el foro de Directadmin existe una clase hecha en PHP a la que se le da bastante crédito, que lo que hace es abrir un socket y enviar requests HTTP a un servidor Directadmin y devolver la respuesta. Personalmente me parece que la clase es bastante mala y pobre, por las siguientes razones:

• Está pensada para PHP 4.
• No utiliza cURL, con lo cual hay demasiado código para hacer tareas que ya están implementadas en otras librerías.
• Tiene un manejo de errores muy pobre
• No es una implementación de la API de Directadmin (no implementa comandos específicos), sino que, como su nombre lo indica, se limita a crear un socket a un puerto HTTP y enviar requests (nuevamente… cURL).
• El código no sigue ningún estándar de formato y “mejores prácticas”.

A pesar de todos estos problemas, tampoco me parecía un aporte muy interesante reescribir esa clase utilizando cURL. Además no tenía ganas de programar en PHP. Por lo tanto, lo que hice fue crear una implementación de la API en Python. Es decir, una librería que se ocupe de conectarse a un servidor Directadmin, enviar comandos, procesar sus respuestas y ofrecer una interfaz de programación cómoda para el desarrollador. De paso, el proyecto me sirvió para aprender un poco más de Python que es un lenguaje que me gusta mucho.

El resultado fue este proyecto que alojé en Google Code: http://code.google.com/p/python-directadmin/

El código es bastante sencillo (e incluso un poco tosco). Si ven el código del módulo directadmin, van a ver que hay una serie de clases. La más importante es la clase Api, que implementa los distintos métodos de la API de Directadmin (salvo algunos que no implementé aún). Esa clase hace uso de ApiConnector que es una clase muy sencilla que resume en unas pocas líneas lo que hacía la clase de PHP, utilizando urllib2. Luego hay un par de clases más para representar los tipos de usuarios, que no revisten mayor interés.

Posibles implementaciones

Cuando publiqué mi contribución en el foro de Directadmin obtuve una respuesta bastante poco amistosa de un usuario que no le veía utilidad a mi aporte. Más allá de esa persona, que afirma no conocer a nadie que programe en Python (sin comentarios…), yo creo que hay al menos tres vías de implementación de esta librería:

• La más básica: crear scripts de consola para automatizar tareas (ver ejemplos más adelante).
• Desarrollo web: así como el principal objetivo de la clase en PHP era que las empresas de hosting pudieran integrar sus sitios institucionales con el panel de control, esta implementación en Python permite el mismo tipo de integración para sitios desarrollados en Python (por ejemplo usando frameworks como Django, web2py, TurboGears, Pylons, etc.).
• Aplicaciones de escritorio: no hay ni punto de comparación entre el soporte que ofrece Python para aplicaciones de escritorio con el que ofrece PHP. Hoy por hoy, un porcentaje muy alto de las aplicaciones de escritorio para Linux se escriben en Python y librerías como PyQt permiten hacer software desktop para Linux, Windows y Mac. Una aplicación de escritorio para monitorear y administrar múltiples servidores Directadmin se podría hacer sencillamente utilizando esta librería.

Ejemplos

Utilizar la API es bastante sencillo. En la página del proyecto podrán ver algunos ejemplos básicos como éste, para listar todos los usuarios del panel.

Además en el paquete incluí un archivo de ejemplo que se llama suspension.py. Este script utiliza la API para suspender/desuspender usuarios desde la consola. Se utiliza de la siguiente forma:

./suspension.py suspend

Tiene algunas otras opciones para especifiar host, puerto, usuario y password para conectarse Directadmin. Para ver las opciones disponibles pueden poner:

./suspension.py --help

Pendientes

Aún quedan varias cosas pendientes por hacer. Hay algunos métodos que no he implementado aún. Hay otros que los he probado y no funcionan, pero porque obtengo errores de parte de Directadmin y todavía nadie me ha sabido contestar por qué. También me gustaría crear un script de instalación con setuptools, pero todavía debo interiorizarme un poco más en el tema. Por último, me gustaría también hacer una implementación de más alto nivel, pues ahora la clase Api es una especie de bolsa de funciones que no me convence del todo.

Links

• Página del proyecto
• Descargar python-directadmin

ConfigServer Security & Firewall

En esta sencilla guía vamos a ver cómo instalar ConfigServer Security & Firewall (CSF), un paquete de aplicaciones para Linux que incluye in firewall ampliamente configurable y herramientas para análisis de logs y detección de intrusiones. Además se integra como plugin a Directadmin, y chequea distintos items de la configuración del servidor para darnos ideas sobre cuestiones a mejorar.

La instalación es muy sencilla.

cd /usr/src
wget http://www.configserver.com/free/csf.tgz
tar -xzf csf.tgz
cd csf
sh install.sh

Cuando lo probé yo me dio un error indicando que necesitaba el módulo LWP de Perl, el cual instalé con CPAN.

cpan -i LWP

Por último, es importante correr las pruebas que vienen incluidas para ver si tenemos todos los módulos de iptables necesarios. Aquí lo importante es que no dé FATAL ERRORS.

perl /etc/csf/csftest.pl

Eso es todo. Ahora ingresamos como admin a Directadmin, y en la sección de plugins encontraremos a ConfigServer. Allí podemos cambiar la configuración del firewall. Una vez terminado de configurar, cuando estamos seguros que todo funciona, debemos deshabilitar el testing mode. Este último lo que hace es limpiar el iptables regularmente, por si nos equivocamos, para no quedarnos sin acceder al servidor. También desde aquí podemos pedirle a ConfigServer que ejecute sus pruebas para ver la seguridad del servidor, y nos indique qué puntos nos quedan asegurar.

Las extensiones de FrontPage son básicamente una serie de scripts que corren del lado del servidor y que, como su nombre lo indica, extienden la funcionalidad del FrontPage. A pesar de ser un producto de Microsoft, es compatible con Apache.

El tema es que, al menos en Directadmin, solamente es compatible con Apache 1.3. Según entiendo, las extensiones en sí se pueden instalar con Apache 2.x, pero el Directadmin solamente las soporta cuando se usa la versión 1.3.

Ahora bien, esta instalación no vamos a poder realizarla con Custombuild, sino que tenemos que recurrir al más antiguo CustomApache. Entonces los pasos serían los siguientes:

Descargar e instalar CustomApache:

cd /usr/local/directadmin
mkdir customapache
cd customapache
wget http://files.directadmin.com/services/customapache/build
chmod 755 build
./build update

Lo más sencillo ahora sería ejecutar build all, que va a instalar el Apache y las extensiones:

./build all

Si por alguna razón no se quiere compilar e instalar todo, se puede compilar Apache con:

./build apache_mod_ssl

Y luego habría que instalar las extensiones:

./build mod_frontpage

Por último, y esto es muy importante, hace falta habilitar las extensiones para que Directadmin muestre el correspondiente menú. Para ello es necesario editar el archivo /usr/local/directadmin/conf/directadmin.conf y poner el parámetro frontpage_on en 1.

frontpage_on=1

Luego se reinicia el servicio del Directadmin y listo:

service directadmin restart

Directadmin Control Panel

¿Por qué usar custombuild?

Básicamente porque es la forma de instalar los distintos servicios de manera que el Directadmin pueda gestionarlos. Esto incluye, fundamentalmente, el hecho de generar archivos de configuración iniciales y ubicarlos en las localizaciones adecuadas, para que el panel pueda administrar virtual hosts de Apache, cuentas de email, etc. Además custombuild permite mantener una configuración estándar en distintos servidores que usen Directadmin, lo cual simplifica el trabajo al momento de acceder a un nuevo equipo y tener que hacer alguna tarea de diagnóstico, upgrade o instalación. Por último, el script simplifica muchísimo el trabajo para el sysadmin, porque si bien no es un sistema completo de manejo de paquetes (como podría ser apt-get en Debian, los ports de FreeBSD, o el odioso yum de Red Hat/CentOS), sí resuelve algunas dependencias, encargandose de descargar y compilar las distintas librerías que va a requerir la aplicación para poder ser instalada.

¿Qué permite instalar/actualizar Custombuild?

• Apache 1.3, 2.0 or 2.2
• AWstats
• Autoconf
• Automake
• cURL
• Dovecot
• Archivos de configuración de Exim
• FreeType
• GD
• libiconv
• libjpeg
• libpng
• libmcrypt
• libmhash
• mod_perl
• MySQL
• PHP (con o sin suPHP) 4, 5 or 6
• ProFTPD
• Webalizer
• Zend Optimizer
• Zlib

Y aplicaciones web como:

• Atmail Open webmail
• Roundcube webmail
• Squirrelmail webmail
• phpMyAdmin
• UebiMiau webmail

¿Cómo instalar Custombuild?

cd /usr/local/directadmin
wget http://files.directadmin.com/services/custombuild/1.1/custombuild.tar.gz
tar xvzf custombuild.tar.gz
cd custombuild
./build

options.conf

El Custombuild funciona con un archivo de configuración llamado options.conf. Este archivo define algunos parámetros básicos para el funcionamiento del script, indicando qué versiones se va a instalar de cada programa, etc.

Después de editar el archivo options.conf, siempre es necesario correr el siguiente comando para actualizar las dependencias.

./build update_data

Por otro lado, la primera vez que se utiliza Custombuild es conveniente correr el siguiente comando, que descargará e instalará TODO con las opciones por default.

./build all d

¿Qué es cada opción del options.conf?

PHP:

• default_php – Esta opción se utiliza cuando hay dos versiones de PHP en el sistema (4, 5, ó 6), para definir cual es la default. Por defecto este valor es igual a la última versión de PHP.
• phpX_cli – instalar/actualizar PHP como CLI (opción default) al hacer “./build php” or”./build all”. Valores posibles yes/no (default: yes).
• phpX_cgi – instalar/actualizar PHP como CGI (opción default) al hacer “./build php” or”./build all”. Valores posibles yes/no (default: no).
• php_ini - actualizar el archivo de configuración de PHP al hacer “./build php-ini” o “./build all”. Valores posibles: yes/no (default: no).
• php_ini_type - Esta opción define el tipo de php.ini a utilizar al momento de ejecutar “./build php-ini”. Valores posibles: dist/recommended (default: recommended).
• zend - Instalar/actualizar Zend Optimizer al usar “./build zend” o “./build all”. Valores posibles: yes/no (default: no).

MySQL:

• mysql - Versión de MySQL. Valores posibles: 4.1, 5.0, 5.1 (default: 5.0).
• mysql_inst – instalar/actualizar MySQL al utilizar “./build mysql” or “./build all”. Valores posibles: yes/no (default: no).
• mysql_backup - hacer backup de MySQL cada vez que se actualiza MySQL. Valores posibles: yes/no (default: yes).

Apache:

• apache_ver - Versión de Apache. Valores posibles: 1.3, 2.0, 2.2 (default: 2.2).

Aplicaciones web:

• phpmyadmin – instalar/actualizar phpMyAdmin al hacer “./build phpmyadmin” o “./build all”. Valores posibles: yes/no (default: yes).
• atmail – instalar/actualizar Atmail Open webmail al hacer “./build atmail” o “./build all”. Valores posibles: yes/no (default: no).
• squirrelmail - instalar/actualizar SquirrelMail webmail al hacer “./build squirrelmail” o “./build all”. Valores posibles: yes/no (default: yes).
• roundcube – instalar/actualizar RoundCube webmail al hacer “./build roundcube” o “./build all”. Valores posibles: yes/no (default: yes).
• uebimiau - instalar/actualizar UebiMiau webmail al hacer “./build uebimiau” o “./build all”. Valores posibles: yes/no (default: no).

Mail:

• exim – instalar/actualizar Exim al hacer “./build exim” o “./build all”. Valores posibles: yes/no (default: no).
• mail-header-patch – usar el patch del header de la función mail() de PHP al instalar/actualizar Valores posibles: yes/no (default: yes).
• dovecot - instalar/actualizar Dovecot al hacer “./build dovecot” o “./build all”. Valores posibles: yes/no (default: yes).
• eximconf – actualizar el archivo de configuración de exim (/etc/exim.conf) al hacer “./build exim_conf” o “./build all”. Valores posibles: yes/no (default: no).

Jailed shell:

• jail - instalar/actualizar programas de jailed shell al hacer “./build apache”, “./build all_jail”. Valores posibles: yes/no (default: no).

FTP:

• proftpd - instalar/actualizar ProFTPD al hacer “./build proftpd” o “./build all”. Valores posibles: yes/no (default: yes).

Estadísticas:

• awstats - instalar/actualizar AWstats al hacer “./build awstats” o “./build all”. Valores posibles: yes/no (default: no).
• webalizer - instalar/actualizar webalizer al hacer “./build webalizer” o “./build all”. Valores posibles: yes/no (default: yes).

Crontab:

• cron - habilitar crontad para Custombuild, al usar “./build cron” para configurarlo. Valores posibles: yes/no (default: no).
• email - definir notificaciones por email. Valores posibles: cualquier dirección de email (default: email@domain.com).
• notifications - habilitar notificaciones por email para actualizaciones. Valores posibles: yes/no (default: yes).
• updates – actualizar software/applicaciones automáticamente cuando hay actualizaciones disponibles. Valores posibles: yes/no (default: no).

CustomBuild:

• custombuild - version del script CustomBuild que se quiere utilizar. Valores posibles: 1.1/1.2 (default: la versión instalada).
• autover – descargar versions.txt cada vez que se ejecuta el comando “./build”.  Valores posibles: yes/no (default: no).
• bold - habilitar/deshabilitar texto en negrita. Valores posibles: yes/no (default: yes).
• clean – ejecutar “./build clean” cada vez. Valores posibles: yes/no (default: yes).
• cleanapache – excluir al apache del “./build clean”. Valores posibles: yes/no (default: no).
• clean_old_webapps - ejecutar “./build clean_old_webapps” cada vez. Valores posibles: yes/no (default: no).
• fileserver – definir el servidor desde el cual descargar los archivos. “1″ significa files.directadmin.com y “2″ significa files4.directadmin.com server (Europa). Valores posibles: 1/2 (default: 1).

¿Cómo ejecutar Custombuild?

Para instalar todo:

./build all

Otras opciones:

./build apache
./build autoconf
./build automake
./build curl
./build cron
./build dovecot
./build exim_conf
./build freetype
./build iconv
./build icu
./build libjpeg
./build libpng
./build libtool
./build libxml2
./build libxslt
./build mcrypt
./build mhash
./build mod_perl
./build mysql
./build pcre
./build php
./build proftpd
./build rewrite_confs
./build update_versions
./build used_configs
./build versions
./build webalizer
./build zend
./build zlib

Aplicaciones:

./build phpmyadmin
./build atmail
./build roundcube
./build squirrelmail
./build uebimiau

Jailed shell:

./build all_jail
./build coreutils
./build shell
./build smtp_mail
./jail/jail_user.sh user

Borrar información vieja:

./build clean

Obtener la última versión del script y de la información:

./build update
./build update_script

Obtener la información para el script actual:

./build update_data

Funciones recomendadas sólo para usuarios experimentados:

./build php4-cli
./build php5-cli
./build php4-cgi
./build php5-cgi
./build todovecot

Se puede pasar un segundo argumento a los comandos:

./build <option> d : ejecutar la acción default
./build <option> y : responder "yes" a todas las preguntas
./build <option> n : responder "no" a todas las preguntas

Fuente: Directadmin Custombuild FAQ.

Traducción propia.