jueves, 4 de diciembre de 2014

Compilando la última versión del driver wanpipe en Elastix 2.5

Al seguir las instrucciones de la página oficial el siguiente error aparece:
Press [Enter] to continue...

Compiling WANPIPE LibSangoma API library ...Failed.

Press [Enter] to continue...

Compiling WANPIPE LibStelephony API library ...Failed.

El problema es que la instalación de las librerías LibSangoma API y LibStelephony API requieren del comando libtoolize que es proporcionado por el paquete libtool... O al menos eso se supone, la cuestión es que Elastix proporciona una versión más nueva de dicho paquete que no incluye ese comando

Luego, la solución consiste en instalar la versión proporcionada por CentOS. Después de instalar los paquetes para crear el entorno de desarrollo (Revise el procedimiento descrito en el link de arriba), ejecute lo siguiente:
yum remove libtool

yum install libtool.x86_64 --disablerepo=* --enablerepo='base'

Adicionalmente, cada vez que vaya a actualizar el sistema debe excluir dicho paquete del proceso con la opción -x:
yum update -x libtool

Por cierto, la gente de Elastix mantiene una campaña en indiegogo para financiar la Migración de Elastix 2.5 a CentOS 7. Supongo que las razones pueden no parecer del todo claras (De hecho, muchas cosas parecen no tener sentido en este proyecto). No obstante, no veo mala idea el colaborar.

martes, 25 de noviembre de 2014

Error con aptitude update

Ciertamente, el siguiente error es difícil de explicar.
W: Se produjo un fallo al descargar http://debian.salud.gob.sv/debian/dists/wheezy/contrib/source/Sources: 404  Not Found
W: Se produjo un fallo al descargar http://debian.salud.gob.sv/debian/dists/wheezy/non-free/source/Sources: 404  Not Found
W: Se produjo un fallo al descargar http://debian.salud.gob.sv/debian/dists/wheezy/contrib/binary-amd64/Packages: 404  Not Found
W: Se produjo un fallo al descargar http://debian.salud.gob.sv/debian/dists/wheezy/non-free/binary-amd64/Packages: 404  Not Found
E: Some index files failed to download. They have been ignored, or old ones used instead.
E: No se pudo reconstruir el almacén de paquetes

Resulta que los servidores del trabajo estaban respondían de esta forma a un aptitude update, aún cuando los equipos que uso para laboratorio usaban la misma configuración en el archivo sources.lst.

Supongo que debe existir una mejor solución: Sin embargo, lo que me funcionó fue eliminar del ficheros aquellos ramas que daban problemas. Más o menos de esta forma
#deb http://debian.salud.gob.sv/debian/ wheezy main contrib non-free
#deb http://debian.salud.gob.sv/debian/ wheezy main contrib non-free

deb-src http://debian.salud.gob.sv/debian/ wheezy main
deb-src http://debian.salud.gob.sv/debian/ wheezy main

deb http://debian.salud.gob.sv/debian/ wheezy-updates main contrib non-free
deb-src http://debian.salud.gob.sv/debian/ wheezy-updates main contrib non-free

deb http://debian.salud.gob.sv/debian-security/ wheezy/updates main contrib non-free
deb-src http://debian.salud.gob.sv/debian-security/ wheezy/updates main contrib non-free
Luego, actualizo la lista de paquetes sin problemas
aptitude update
Vuelvo a activar las ramas problemáticas

deb http://debian.salud.gob.sv/debian/ wheezy main contrib non-free
deb http://debian.salud.gob.sv/debian/ wheezy main contrib non-free

deb http://debian.salud.gob.sv/debian/ wheezy-updates main contrib non-free
deb-src http://debian.salud.gob.sv/debian/ wheezy-updates main contrib non-free

deb http://debian.salud.gob.sv/debian-security/ wheezy/updates main contrib non-free
deb-src http://debian.salud.gob.sv/debian-security/ wheezy/updates main contrib non-free
Y esta vez la actualización sucede sin problemas:
aptitude update

Un de las tantas cosas que evidencian el final feliz a este problema es que el comando avisa que hay nuevos paquetes disponibles. (El tanto el pensaba que ya no existían porque había creado su lista de paquetes disponibles sin las ramas problemáticas)
Estado actual: 50 actualizados [+13], 36480 nuevos [+35024].

domingo, 12 de octubre de 2014

'nomodeset' y gráficos Intel

Los dispositivos Intel son sin duda de los más soportados en Linux.
Hace años, comprar una motherboard Intel me cambio la vida en cuanto a la experiencia con gráficos.

Sin embargo un pequeño inconveniente aparece con las versiones más recientes del kernel linux: Tomo como referencia el 3.11-6 que trae OpenSuSE 13.1 y el que trae Fedora 20, 3.11.10.
En openSuse es posible que el vídeo no se muestre correctamente. Tal como si no se hubiera instalado el driver correctamente. En Fedora, es la resolución de pantalla que no se muestra correctamente, y no es posible cambiar entre todas las resoluciones que sabemos están soportadas. Estos problemas se deben a nomodeset
nomodeset
The newest kernels have moved the video mode setting into the kernel. So all the programming of the hardware specific clock rates and registers on the video card happen in the kernel rather than in the X driver when the X server starts.. This makes it possible to have high resolution nice looking splash (boot) screens and flicker free transitions from boot splash to login screen. Unfortunately, on some cards this doesnt work properly and you end up with a black screen. Adding the nomodeset parameter instructs the kernel to not load video drivers and use BIOS modes instead until X is loaded.
La solución no podría ser más sencilla: Removemos nomodeset. En el fichero /etc/default/grub buscamos en la línea GRUB_CMDLINE_LINUX la opción nomodeset y la borramos.

Ahora, actualizamos propiamente la configuracion del kernel con algo tan simple como ejecutar desde consola:
grub2-mkconfig

La ventaja de modificar indirectamente /boot/grub2/grub.cfg de esta forma es que la configuración no ha de perderse con actualizaciones del Kernel u otras modificaciones que hagamos.

Por otra parte, hay que tener en cuenta que este arreglo sólo funciona para los problemas descritos (Y quizá algunos más) pero exclusivamente para gráficos Intel.

Fuente

viernes, 21 de febrero de 2014

El eterno problema en samba: nofile = 1024

Al hacer una configuración de samba en Debian Wheezy (Y parece que en la mayoría de distribuciones linux), un mensaje de error aparece al configurar samba y comprobando el archivo de configuración con testparm:
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Este mensaje viene a decir que el número máximo de archivos que un usuario puede abrir esta configurado a 1024 en el sistema. Esta es parte de toda una serie de límites que se configuran en el sistema para evitar que un usuarios acapare todos los recursos del sistema.

La solución pareciera estar documentada en muchas partes, sin embargo a mi no me ha funcionado. Según la mayoría, basta con agregar lo siguiente en el archivo /etc/security/limits.conf, al menos antes de la última línea
(...Contenido suprimido...)
#@student        -       maxlogins       4
*                -       nofile          16384
# End of file
Pero mi Debian no responde a tal configuración. Y sin embargo lo hace cuando se configura al vuelo con ulimit -n 16384. Por tanto, supe que era posible.

Para que en realidad funcione, basta con especificar el usuario sobre el que se realiza este configuración en lugar del comodín * Así queda
(...Contenido suprimido...)
#@student        -       maxlogins       4
root             -       nofile          16384
# End of file

Tiene sentido al final de cuentas. Con el comodín, el límite máximo sería alcanzable para todo el que se loguea en el sistema (Sobre todo en mi caso que lo uso como PDC...). En este caso, sólo cambiamos el límite para root, que es quién maneja los procesos de Samba.

Actualización:
Por si las dudas (Se supone que hemos arreglado el problema, pero el mensaje de error continúa apareciendo cuando se ejecuta testparm desde una sesión root obtenida con su -), agregue en /etc/pam.d/sudo lo siguiente,
(...Contenido suprimido...)
session    required   pam_limits.so
Reinicie el sistema y todo estará bien.

jueves, 20 de febrero de 2014

DVD de CentOS como repositorio

Cuando se instala un cliente paravirtualizado en xen, su naturaleza impide usar algunos componentes de hardware, entre los que se incluyen las lectoras DVD. Lo usual es que se use una instalación en red para la mayoría de casos.

Para instalar CentOS, tenemos la opción usar un repositorio externo, lo que que no parece una opción saludable ni cuerda. Sin embargo, posible usar el DVD que de todos los días como repositorio local de un forma bastante simple.

Instalamos apache
zypper install -t pattern lamp_server
Permitimos el listado de ficheros para este directorio con la opción Indexes
vim /etc/apache2/default-server.conf
A modo de ejemplo, y con contenido recortado
DocumentRoot "/srv/www/htdocs"

#
# Configure the DocumentRoot
#
<Directory "/srv/www/htdocs">
        # Possible values for the Options directive are "None", "All",
        # or any combination of:
        #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
        #
        # Note that "MultiViews" must be named *explicitly* --- "Options All"
        # doesn't give it to you.
        #
        # The Options directive is both complicated and important.  Please see
        # http://httpd.apache.org/docs-2.2/mod/core.html#options
        # for more information.
Options Indexes
        # AllowOverride controls what directives may be placed in .htaccess files.
        # It can be "All", "None", or any combination of the keywords:
        #   Options FileInfo AuthConfig Limit
AllowOverride None
        # Controls who can get stuff from this server.
Order allow,deny
 Allow from all
</Directory>
Iniciamos el servicio
systemctl status apache2.service
Creamos un directorio dentro del cual crearemos el repositorio
mkdir /srv/www/htdocs/centos
Lo montamos
mount -o loop /home/usuario/CentOS-6.5-x86_64-bin-DVD1.iso /srv/www/htdocs/centos/
Y nada, que ya lo podemos especificar como --location dentro del comando virt-install. La URL queda http://<ip-servidor>/centos

DVD de CentOS como respositorio
Creo que en cuanto pueda, revisaré con cuales otras distribuciones es posible hacer esto.

martes, 18 de febrero de 2014

Acomodando virt-install para Debian sobre OpenSuSE

Siguiendo la línea de una anterior entrada, me pareció que todo iba bien hasta el momento en que tuve que virtualizar un sistema Debian.
Usando paravirtualización y escogiendo un servidor HTTP como fuente del árbol de instalación, mediante las herramientas virt-manager (Que se encuentra en los repositorios de Open SuSE y CentOS, por ejemplo ), el comando de instalacion

virt-install --prompt --network bridge=br0 --virt-type=xen --location http://ftp.egr.msu.edu/debian/dists/wheezy/main/installer-amd64/ -n enlace --description enlace -r 512 --vcpus=1 --disk path=/dev/system/gateway --os-type=linux --paravirt --arch x86_64 
me arrojaba el siguiente error:
ERROR    'NoneType' object has no attribute '__getitem__'
Después de revisar el log de virt-manager
tail -f  ~/.virtinst/virt-install.log
Llegué a la siguiente solución
Abrimos el fichero
vim /usr/lib/python2.7/site-packages/virtinst/OSDistro.py 
 
Aproximadamente en la línea 80 de dicho fichero, empieza una selección en la código de esta forma (La lista de hecho se extiende un poco màs)

 # FIXME: This 'distro ==' doesn't cut it. 'distro' is from our os
    # dictionary, so would look like 'fedora9' or 'rhel5', so this needs
    # to be a bit more intelligent
    if distro == "fedora" or distro is None:
        stores.append(FedoraDistro)
    if distro == "rhel" or distro is None:
        stores.append(RHELDistro)
    if distro == "centos" or distro is None:
        stores.append(CentOSDistro)
    if distro == "suse" or distro is None:
        stores.append(SuseDistro)
    if distro == "sl" or distro is None:
        stores.append(SLDistro)
    if distro == "debian" or distro is None:
        stores.append(DebianDistro) ... 

Básicamente, el cambio consiste en cambiar el orden de las opciones. Hasta ahora el error sólo aparece cuando el sistema es Debian, por lo tanto basta con anteponer este a SuSE Empresarial
if distro == "fedora" or distro is None:
        stores.append(FedoraDistro)
    if distro == "rhel" or distro is None:
        stores.append(RHELDistro)
    if distro == "centos" or distro is None:
        stores.append(CentOSDistro)
    if distro == "debian" or distro is None:
        stores.append(DebianDistro)
    if distro == "suse" or distro is None:
        stores.append(SuseDistro)
    if distro == "sl" or distro is None:
        stores.append(SLDistro)

Obviamente, si hoy problemas de ese tipo con otras distribuciones, entonces también puede cambiarse el orden con respecto a SLES. 
Y claro, el problema pasa por ser más complicado, pero esta solución chapucera realmente me funciona

lunes, 17 de febrero de 2014

Problemas con el cliente ownCloud en Open SuSE

Instalo la versión 1.5.1 del cliente de ownCloud para openSuSE 13.1 desde un One Click Install y tras configurarlo y descargar los archivos, me aparece el siguiente error:
No se puede iniciar un registro (journal) de sincronización
Imagen del error
 La solución es tan simple como instalar el plugin de sqlite para QT 4.
zypper info libqt4-sql-sqlite
No entiendo como es que esta dependencia no sea había resuelto. Quizá suponían que cualquier sistema tendría instalado ese paquete, pero en openSuSE 13.1 con XFCE parece que ningún otro programa lo necesita.

Por cierto, para darse cuenta del error, bastó con revisar el fichero .csync_journal.db, que se crea en cada directorio que se sincroniza, con el comando file, y ver que al empezar no lo reconocía sino como un archivo vacío, cuando en realidad su tipo debería ser SQLite 3.x database.

sábado, 15 de febrero de 2014

Afinando nuestro servidor Xen en Open SuSE

Virtualizar con Open SuSE podría parecer más fácil (que no sencillo) que en otras distros, por el hecho que casi todo es más fácil (que no sencillo) que hacer que en otras distros.

Sólo agrego una último detalle del que parece que nadie se había dado cuenta que faltaba:

Según las buenas prácticas de Xen, se aconseja especificar un máximo de memoria RAM a ser usado por Domain-0. Y no estaría mal el limitar el número de núcleos del procesador a ser usados por él. Que aparte de seguir con la costumbre de no dejar configuraciones por defecto, permite que se gane un poco en rendimiento.

No entiendo porque las herramientas gráficas de OpenSuSE no me funcionaron para ello. Me salté el problema agregando lo siguiente al archivo /etc/default/grub, de donde se leen las configuraciones para crear el archivo  /boot/grub2/grub.cfg
GRUB_CMDLINE_XEN="resume=/dev/system/swap dom0_mem=2048M,max:2048M dom0_max_vcpus=1 splash=silent quiet showopts" 
 Tal como la documentación de Xen lo dice, lo importante acá son las opciones dom0_mem=2048M,max:2048M dom0_max_vcpus=1 

Luego, se crea el archivo grub.cfg de acuerdo a nuestra nueva configuración
grub2-mkconfig -o /boot/grub2/grub.cfg
Después basta con reiniciar, y al volver podrá verse que Domain-0 se restringe al uso de los recursos del sistema tal como se ha especificado.
Algunas pruebas de como la configuración ha funcionado
Y si, posiblemente sea lo que se tenga que hacer en otras distribuciones con Grub2

Otros apuntes interesantes

Otros apuntes interesantes