Archivo para la categoría "*NIX"
Homebrew, gestión de paquetes en Mac OS X
Homebrew es un sistema de gestión de paquetes de software para Mac OS X como podría ser un apt en sistemas GNU/Linux pero sin distribución de paquetes precompilados.
Gestión de paquetes en Mac OS X
Apple propone el App Store como sistema para obtener software y mantenerlo actualizado. Evidentemente solo las aplicaciones publicadas en el Apple Store pueden ser mantenidas de esta manera. Y aún así la oferta es bastante limitada si nos fijamos en software Unix.
Otras opciones disponibles son MacPorts o Fink. Todos ellas tienen un planteamiento parecido y diferente al mismo tiempo. MacPorts y Fink plantean mantener todo el software a parte de la base de Mac OS X mientras que Homebrew prefiere utilizar al máximo la base propuesta por el sistema y construir únicamente lo que falte.
Este planteamiento tiene sus ventajas y sus inconvenientes:
- Al necesitar menos dependencias externas es más rápido.
- Al utilizar las dependencias del sistema las cosas se pueden romper cuando el sistema las actualice.
Por otro lado MacPorts y Fink, aunque más laboriosos tienen un entorno más controlado y por tanto más estable.
En resumen, depende de las necesidades de cada uno. En este artículo veremos el uso de habitual de Homebrew que probablemente sea el más ligero para empezar a probar.
Requisitos
Necesitamos el entorno de compilación de Mac OS X. Aunque algunas utilidades vienen ya instaladas de fábrica en el sistema, es recomendable (y en algunos casos indispensable) instalar Xcode. Lo podemos encontrar en el App Store.
Instalación de Homebrew
Desde la web oficial podemos acceder a la guía de instalación. En la práctica se reduce a ejecutar (a fecha de este artículo):
/usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"
La instalación se realiza en /usr/local por lo que o bien lo ejecutamos como administrador o bien nos damos de permisos para escribir en ese directorio.
Actualizar el listado de fórmulas
Homebrew utiliza el concepto de fórmula. Este concepto transmite la idea de cómo se obtiene un programa, es decir, sus dependencias y sus pasos de compilación.
El listado de fórmulas se mantiene en los repositorios de GitHub. Esto nos permite crear forks del proyecto, añadir nuestras fórmulas y demás. Veamos cómo se actualiza el listado:
$ brew update remote: Counting objects: 141, done. remote: Compressing objects: 100% (63/63), done. remote: Total 122 (delta 93), reused 88 (delta 59) Receiving objects: 100% (122/122), 13.71 KiB, done. Resolving deltas: 100% (93/93), completed with 18 local objects. From http://github.com/mxcl/homebrew f34cda7..09ad71b master -> origin/master Updated Homebrew from f34cda74 to 09ad71bd. [...]
Es la salida típica de git. A partir de ahí veremos un resumen de las nuevas fórmulas añadidas y de las actualizadas.
Buscar fórmulas
brew search PATRÓN
Mostrar información de una fórmula
Tenemos la opción clásica:
brew info FÓRMULA
y la curiosa opción de visitar la página del proyecto:
brew home FÓRMULA
Instalación de fórmulas
brew install FÓRMULA
Listar fórmulas antiguas
En el proceso de actualización del listado de fórmulas se detectarán nuevas versiones de fórmulas ya instaladas:
brew outdated
Actualización de paquetes
Tenemos dos opciones
brew upgrade
que actualiza todos las fórmulas con nuevas versiones o
brew upgrade FÓRMULA
que actualiza únicamente la fórmula especificada.
Eliminación de versiones antiguas
Una curiosidad de Homebrew es que no desinstala versiones anticuadas para ello usamos:
brew cleanup
Crear nuevas fórmulas
Es bastante sencillo crear una fórmula nueva. Aunque el Formula Cookbook es bastante claro, veremos brevemente los paso principales:
- brew create URL (con la URL de la descarga)
- Editar el fichero, creado automáticamente, en /usr/local/Library/Formula/FÓRMULA.rb
- Añadir las dependencias con depends_on.
- Añadir los comandos system necesarios para la compilación
- Probar la fórmula con brew install -vd FÓRMULA
Más información
NTP Sincronización de tiempos
Uno de los principios que debemos mantener en nuestros equipos es mantenerlos en hora. En algunos es un requisito, por ejemplo sistemas de autenticación dependientes del tiempo, y en otros para mantener la cordura, por ejemplo para realizar un seguimiento de logs en distintas máquinas.
La solución es el uso de NTP (Network Time Protocol) que nos permite sincronizar los relojes de nuestros equipos y mantenerlos en hora con el paso del tiempo. Vamos a ver las configuraciones típicas usando ntpdate y el demonio ntpd.
Pero antes un breve comentario sobre el stratum. El número del stratum nos indica el número de pasos a los que estamos de un reloj atómico (nivel 0). Los relojes atómicos son muy precisos (no como los relojes de cuarzo) pero también muy caros, por lo que es habitual que se utilicen relojes de GPS como origen.
Existen multitud de servidores públicos de NTP. Una iniciativa que mantiene un pool abierto y que además realiza balanceo es NTP pool project. Para este artículo utilizaremos de ejemplo 2.es.pool.ntp.org.
ntpdate, para equipos itinerantes
ntpdate está pensando para utilizarse una sola vez. Lo lanzamos, obtiene el tiempo del servidor remoto y sincroniza la hora local. Por ejemplo:
# ntpdate 2.es.pool.ntp.org 14 Sep 12:18:03 ntpdate[3359]: adjust time server 158.227.98.15 offset 0.000969 sec
El uso más habitual es para equipos portátiles u ordenadores que no tienen conexión permanente a Internet. Los equipos esperan a tener conexión y efectúan la sincronización.
Un error habitual es que el socket esté en uso, normalmente por el demonio ntpd, que exige cerrar primero ntpd y luego lanzar ntpdate:
# ntpdate 2.es.pool.ntp.org 14 Sep 12:21:57 ntpdate[3392]: the NTP socket is in use, exiting
La configuración de ntpdate como servicio es muy sencilla, podemos echar un vistazo en /etc/default/ntpdate (sistemas Debian).
Demonio ntpd, equipos con conexión permanente
Si el equipo está conectado la gran parte del tiempo lo recomendable es utilizar el demonio ntpd. Evidentemente se encargará de mantener el equipo sincronizado con el paso del tiempo.
Existe una diferencia importante entre ntpdate y ntpd. ntpd realiza un ajuste sutil sobre la velocidad del reloj para compensar la deriva natural del reloj (drift). Esto tiene una repercusión: el tiempo es continuo (obviemos cuestiones metafísicas 
).
Por ejemplo imaginemos que nuestro equipo está 5 minutos atrasado. ntpd intentará que el reloj “corra” hasta llegar a la sincronización sin saltarse ni un segundo (simplemente “cuenta los segundos más rápido”). ntpdate por otro lado al ver que la diferencia es mayor a medio segundo directamente “saltará” en el tiempo fijando la hora actual inmediatamente.
La práctica recomendada es arrancar el equipo con ntpdate y dejar que el demonio ntpd se haga cargo de mantener la hora.
La configuración es un poco más elaborada, ya que podemos configurarlo como servidor de NTP. El fichero de configuración /etc/ntp.conf está muy bien comentado y básicamente cambiando las directivas server por servidores locales (o del NTP pool project) sería suficiente.
Prestando servicio interno
Si queremos sincronizar varios equipos dentro de nuestra red haremos que un par de equipos se sincronicen con servidores externos y al mismo tiempo presten ese servicio a nivel local. De esta forma, incluso si se cae la conexión, todos los equipos estarán sincronizados contra la misma fuente de referencia. Además es más educado y consume menos recursos 
Para ello simplemente es necesario revisar las directivas restrict.
Broadcast
La última modalidad es la sincronización por broadcast. En esta configuración un servidor local de NTP emite de forma regular la hora actual, los equipos que escuchen actualizan la hora. Es una configuración muy típica para desplegar equipos con conexión a red como impresoras, cámaras y dispositivos similares.
Para configurar al servidor para que emita hay que hacer uso de la directiva broadcast.
Para hacer que un equipo escuche las emisiones la directiva es broadcastclient.
Más información
Servidor de proyectos con Subversion, Trac, Apache (y LDAP)
En esta entrada vamos a montar un servidor para la gestión de proyectos. Para ello utilizaremos un sistema de control de versiones (Subversion), un sistema de gestión de incidencias (Trac) y un sistema de autenticación compartido, para ello utilizaremos Apache y alguno de sus métodos de autenticación como por ejemplo LDAP (válido si es necesario utilizar las cuentas de un Directorio Activo).
Aunque existen soluciones más elaboradas y más integradas, como el software de SourceForge.net, este planteamiento permite montar un servidor a medida, pudiendo alterar cualquiera de sus elementos, y en mi opinión más sencillo de mantener.
Nos basaremos en una instalación mínima de Ubuntu Server 8.04 (por lo que no disponemos ni de Subversion 1.5 ni de Trac 0.11) con la idea de montar un servidor preparado para mantener varios proyectos.
Instalación y configuración de Subversion
Para empezar instalaremos subversion, también es recomendable subversion-tools por los scripts adicionales que incorpora, y preparamos un repositorio de prueba:
# apt-get install subversion subversion-tools # mkdir /srv/svn # svnadmin create /srv/svn/proyecto
Aprovechamos ahora para crear una estructura básica dentro del repositorio, esto nos servirá en las pruebas para ver si realmente podemos acceder al repositorio:
# svn co file:///srv/svn/proyecto
# svn mkdir proyecto/{branches,tags,trunk}
# svn ci -m 'Estructura Inicial' proyecto
Instalación y configuración de Trac
Instalaremos y configuraremos mínimamente un proyecto de Trac para el repositorio que acabamos de crear:
# apt-get install trac # mkdir /srv/trac # trac-admin /srv/trac/proyecto initenv (Opciones sugeridas) Path to repository [/path/to/repos]> /srv/svn/proyecto
Es el momento de comprobar que trac y su unión con el repositorio de subversion funcionan correctamente, para ello lanzaremos el servidor incluido en trac:
# tracd -p 80 /srv/trac/proyecto
Abriendo la URL http://localhost:80/ deberíamos ver disponible nuestro proyecto, “My Project“, y comprobamos que la función de “Browse Source” funciona correctamente.
Por el momento nada nuevo, paremos tracd y sigamos.
Instalación y configuración de Apache
Optamos por enganchar Trac con mod_python así que lo más sencillo es instalar el paquete de mod_python y que instale apache por sus dependencias:
# apt-get install libapache2-mod-python
Bien, ahora editamos la configuración para que Apache pase las peticiones que vayan a /trac a nuestro conjunto de proyectos en /srv/trac. Editando el fichero /etc/apache2/sites-available/default añadimos antes del cierre de </VirtualHost> lo siguiente:
<Location /trac> SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend PythonOption TracEnvParentDir /srv/trac PythonOption TracUriRoot /trac </Location>
Forzamos la recarga de la configuración de Apache:
# /etc/init.d/apache2 reload
Hacemos una prueba con el navegador en http://localhost/trac/ que debería mostrarnos un error por falta de permisos de escritura. Como vamos a dejar a Apache como gestor de los proyectos es necesario darle los permisos que necesita:
# chown -R www-data.www-data /srv/trac/proyecto
Con esto todo debería funcionar exactamente igual que con la prueba realizada con tracd. Vamos ahora a mostrar el repositorio desde Apache.
Subversion trabaja con Apache haciendo uso de WebDAV así que instalamos el módulo necesario:
# apt-get install libapache2-svn
Añadimos la configuración necesaria en el fichero /etc/apache2/mods-available/dav_svn.conf, podéis descomentar las opciones si os resulta más cómodo. En cualquier caso la configuración debe quedar de la siguiente manera:
<Location /svn> DAV svn SVNParentPath /srv/svn </Location>
De nuevo, forzamos la recarga de la configuración de Apache y comprobamos que http://localhost/svn/proyecto muestra el proyecto y que podemos navegar dentro de él. Si probáis http://localhost/svn/ os dará un error, ya que en este caso no existe un listado de proyectos disponibles como hacía Trac.
Igualmente que en Trac, si Apache es el gestor del repositorio es necesario que tenga permisos de escritura. En este caso vamos a ceder completamente el control a Apache:
# chown -R www-data.www-data /srv/svn/proyecto
Ahora mismo disponemos de un sistema completamente funcional en el que no se exige ningún tipo de autenticación. En el caso de Trac no se puede hacer login y en el caso de Subversion ni siquiera se pide. Si queréis verlo en podéis hacer la siguiente prueba:
# svn co http://localhost/svn/proyecto/trunk # touch trunk/README.txt # svn add trunk/README.txt # svn ci -m "Fichero leame" trunk
Si comprobamos el historial, svn log trunk/README.txt, podremos ver que no hay ningún usuario responsable del commit. En ningún momento se nos ha pedido identificarnos, ya que hay permisos de lectura y escritura para todo el mundo, así que podemos bajarnos el contenido del repositorio y los commit son anónimos.
Autenticando usuarios
Empecemos con lo más sencillo, usuarios válidos de un fichero htpasswd, podéis leer algo más en otro de mis artículos sobre ficheros .htpasswd.
# htpasswd -c /etc/apache2/users.conf chernando
Editamos Trac para soportar un login centralizado añadiendo un nuevo location a default:
<Location /trac/*/login> AuthType Basic AuthName "Trac Projects" AuthUserFile /etc/apache2/users.conf Require valid-user </Location>
Forzando la recarga de Apache ya disponemos de la función “login” en Trac. Para el repositorio vamos a dejar el acceso de lectura para todo el mundo y limitar el acceso de escritura a los usuarios registrados añadiendo a la configuración de WebDAV:
AuthType Basic AuthName "Subversion Repository" AuthUserFile /etc/apache2/users.conf <LimitExcept GET PROPFIND OPTIONS REPORT> Require valid-user </LimitExcept>
Una vez más recargando Apache ahora podemos bajar y actualizar un repositorio pero necesitaremos identificarnos para subir cambios al repositorio. Probad a añadir un nuevo fichero y comprobaréis que ahora se exige un usuario y password válidos.
Rizando el rizo, autenticando contra un LDAP
En el caso de disponer de un sistema de autenticación centralizada, por ejemplo LDAP o un Directorio Activo con el servicio LDAP activo, podemos delegar toda la carga de la gestión de usuarios dejando nuestro servidor de proyectos completamente “inhabitado”.
Para ello lo único que necesitamos es cambiar ambas configuraciones. En primer lugar habilitamos los módulos necesarios:
# a2enmod authnz_ldap (esto debería habilitar el módulo ldap por dependencias)
Y configuramos ambas secciones de autenticación. Primero eliminamos AuthUserFile que ya no es necesaria y después añadimos:
AuthBasicProvider "ldap" AuthLDAPURL "ldap://127.0.0.1/dc=chernando,dc=eu?uid?sub?(objectClass=inetOrgPerson)" authzldapauthoritative Off
Podéis ver más detalles en http://trac.edgewall.org/wiki/TracModPython.
Ampliaciones que pueden hacerse a partir de aquí
En esta entrada he intentado introducir el menor ruido posible, tanto en comandos como software a instalar, por lo que hay ciertas mejoras que se han quedado en el tintero. Por ejemplo:
- Configurar Apache para hacer uso de SSL, muy necesario ya que hasta el momento todas las negociaciones con Apache van en texto claro.
- Establecer limitaciones en el acceso de los repositorios (y en secciones de los mismos) haciendo uso de authz.
- Configurar un sistema de correo, que permita notificar todo tipo de eventos: nuevos tickets, cambios en el repositorio…
- Integrar Subversion con Trac, por ejemplo permitir que un commit cierre o añada información a un ticket de Trac.
- Utilizar la última versión de Subversion, 1.5, por su mejora en la gestión de merge de ramas.
- Utilizar la última versión de Trac, 0.11, por las mejoras en el interfaz y en la gestión del flujo de trabajo asociado a un ticket.
- Ampliar el sistema incluyendo otros servicios: listas de correo, servidor de integración continua…
OpenSSL vulnerable en Debian
Durante las últimas dos semanas se ha organizado un gran revuelo debido al descubrimiento de Luciano Bello: la generación de claves con openssl no ha sido realmente aleatoria. Para aquellos que no seáis aficionados a la criptografía podemos traducirlo como: “la hemos pifiado”.
El problema es “únicamente” de OpenSSL en Debian (y distribuciones derivadas)… es decir que programas como OpenSSH o OpenVPN o la generación de certificados desde finales del 2006 pueden estar afectados.
Está situación exige una actualización inmediata de todos los sistemas que puedan estar afectados, de hecho si habéis actualizado vuestras máquinas en la última semana habréis sufrido una regeneración forzosa de las claves de los servicios de SSH.
A fin de validar de las llaves se ha incluido una serie de paquetes de definiciones de llaves comprometidas: openssl-blacklist, openssh-blacklist y openvpn-blacklist. Estos paquetes incluyen una función de comprobación que deniega el acceso si se usan llaves comprometidas. Si últimamente el uso de ssh os ha pedido la clave manualmente es que vuestra llave está comprometida.
Para comprobar las llaves ssh de vuestro sistema podéis ejecutar como root: ssh-vulnkey -a
Tenéis más información en:
Jugando con DCOP, cambiando el fondo de pantalla
Si hacéis uso de la utilidad “Slide Show” de kdesktop para gestionar el fondo de pantalla puede que esta entrada os sea útil.
El problema radica es que una vez fijado el directorio del que elegir el fondo no se puede hacer un “pasa al siguiente”. O al menos yo no lo he encontrado
La posible solución era probar haciendo uso de DCOP y ha resultado tan sencillo… en fin, aquí tenéis el comando para forzar un avance dentro de la colección:
$ dcop kdesktop KBackgroundIface changeWallpaper
