Posts Tagged ‘Ubuntu’

Problemas con tex4ht en Ubuntu

Sunday, June 22nd, 2008

Al tratar de compilar un documento .tex con tex4ht me producía el siguiente error.


Transcript written on document.log.
----------------------------
tex4ht.c (2006-09-13-14:27 kpathsea)
tex4ht -f/document
  -i/usr/share/texmf/tex4ht/ht-fonts/
--- warning --- Can't find/open file `tex4ht.env | .tex4ht'
--- error --- Illegal storage address
----------------------------
t4ht.c (2006-09-13-14:28 kpathsea)
t4ht -f/howto-repositorios
--- warning --- Can't find/open file `tex4ht.env | .tex4ht'
--- warning --- Can't find/open file `document.lg'

Luego de buscar por un buen rato, llegué a una solución. Hay que ejecutar en línea de comando, como superusuario, lo siguiente.


# texhash
no
texhash: Updating /var/lib/texmf/ls-R-TEXMFMAIN...
texhash: Updating /var/lib/texmf/ls-R-TEXMFDIST-TETEX...
texhash: Updating /var/lib/texmf/ls-R...
texhash: Done.

Nota: Texthash lo que hace es actualizar un índice de paquetes Latex instalado, de esta manera el resto de las aplicaciones saben cuales paquetes están instalados.

Bibliografía


Debian Changelog tex4ht (20080228-1)[packages.debian.org]

Gem + Rails + Ruby + Debian. ¿Cómo solucionarlo?

Saturday, June 21st, 2008

Comencé a conocer un poco más sobre este mundo llamado Ruby y me he quedado
bastante sorprendido. Al parecer es un problema recurrente el tema de las gemas y ubuntu. Por lo tanto paso a explicar mi experiencia y cómo lo solucione. Se pueden encontrar muchas explicaciones por Internet,
pero ninguna simple y concisa.

Tengo en cuenta que tienen ya instalado Ruby. Sólo me enfocaré en las Rubygems. Para esto lo primero crear nuestro propio repositorio de gemas. Por ejemplo


$ mkdir -p /home/user/.rubygems/repos

Una vez creada la ubicación de nuestro repositorio bajaremos el código fuente de RubyGems y lo instalaremos en la ubicación creada anteriormente (/home/user/.rubygems). Podemos encontrar las distintas versiones de RubyGems en RubyForge. Utilizo la versión 1.0.1 para ejemplificar la instalación y posterior explicación. Es muy probable que cuando lea este post se encuentre una versión más reciente de RubyGems.


$ wget http://rubyforge.org/frs/download.php/29548/rubygems-1.0.1.tgz
$ tar xzvf rubygems-1.0.1.tgz
$ cd rubygems-1.0.1
$ ruby setup.rb all --prefix=/home/user/.rubygems

El comando anterior instalará RubyGems y creará dentro de .rubygems dos carpetas (bin y lib), la importante aquí es bin, que es donde se encuentra el ejecutable de RubyGem

Nota: la instalación la estamos realizando en /home/user/.rubygems y no en /home/user/.rubygems/repos. Porque sólo estamos instalando RubyGems y no los gems.

Si verifican dentro de la carpeta bin el ejecutable se llama gem1.8, para comodidad he decidido hacer un link simbólico llamado gem


$ ln -s ./gem1.8 ./gem

Felicitaciones tenemos instalado RubyGems, pero ahora falta definir para el resto de las aplicaciones dónde está RubyGems y dónde el repositorio. Se logra definiendo las siguientes variables de entorno GEM_HOME y PATH

GEM_HOME
Declaramos en dónde se encuentra nuestro repositorio de gemas
PATH
Declaramos en dónde se encuentra RubyGems

Nos valdremos del comando export para definirlas


$ export GEM_HOME=/home/user/.rubygems/repos
$ export PATH=$PATH:/home/user/.rubygems/bin
$ export PATH=$PATH:/home/user/.rubygems/repos/bin

Expliquemos un poco lo que hemos hecho para los más despistados. Aquí hemos definido en dónde esta el repositorio de gemas, por lo tanto, todo programa que utilice gemas sabrá en dónde se encuentran. El segundo export hemos exportado la ejecución del RubyGems (gem) desde cualquier lado. El último export permite ejecutar alguna gema en particular (e.g. rails).

Nota: Para que las nuevas variables sean leídas hay que utilizar el siguiente comando:


$ source ~/.bashrc

Veamos un ejemplo. Si no hubiese definido las variables anteriores y realizo lo siguiente:


$ cd /home/a/un/lugar/lejos
$ gem
El programa «gem» no está instalado actualmente.  Puedes instalarlo escribiendo:
sudo apt-get install rubygems
Compruebe que tiene el componente 'universe' activado
bash: gem: orden no encontrada

Aparece como si no estaría instalado; el sistema no sabe en dónde hemos instalado RubyGems (/home/user/.rubygems/bin). Por lo tanto, al “exportar” esta ubicación podemos ejecutar RubyGems desde cualquier lado, sin que sea necesario estar dentro de /home/user/.rubygems/bin

Y por último si no hubiésemos definido el GEM_HOME el sistema no sabría en dónde están las gemas. Entonces por ejemplo si ejecutásemos RubyGems para instalar una gema, éste no sabría en dónde
instalarlo. Y sucedería lo siguiente


$ gem install rails

Bulk updating Gem source index for: http://gems.rubyforge.org
ERROR:  While executing gem ... (Gem::FilePermissionError)
    You don't have write permissions into the /usr/bin directory.

Una vez definida nuestras variables de entorno podemos hacer lo siguiente


$ gem install rails
Bulk updating Gem source index for: http://gems.rubyforge.org
Successfully installed rake-0.8.1
Successfully installed activesupport-2.0.2
Successfully installed activerecord-2.0.2
Successfully installed actionpack-2.0.2
Successfully installed actionmailer-2.0.2
Successfully installed activeresource-2.0.2
Successfully installed rails-2.0.2
7 gems installed
Installing ri documentation for rake-0.8.1...
Installing ri documentation for activesupport-2.0.2...
Installing ri documentation for activerecord-2.0.2...
Installing ri documentation for actionpack-2.0.2...
Installing ri documentation for actionmailer-2.0.2...
Installing ri documentation for activeresource-2.0.2...
Installing RDoc documentation for rake-0.8.1...
Installing RDoc documentation for activesupport-2.0.2...
Installing RDoc documentation for activerecord-2.0.2...
Installing RDoc documentation for actionpack-2.0.2...
Installing RDoc documentation for actionmailer-2.0.2...
Installing RDoc documentation for activeresource-2.0.2...

Nos crearía dentro de /home/user/.rubygems/repos ($GEM_HOME) los directorios: cache, doc, gems, specifications. Dentro gems, estará la gema rails y sus dependencias.

Nota: Con la variable de entorno GEM_HOME, podemos definir más de un repositorio de gemas, en caso de que tengamos múltiples repositorios, tendríamos que hacer: export GEM_HOME=$GEM_HOME:/hacia/el/otro/repositorio

Las variables establecidas anteriormente no son persistentes, o sea, deberíamos definirlas cada vez que reiniciamos la computadora. Para persistirlas:


$ echo "export GEM_HOME=/home/user/.rubygems/repos" >> /home/user/.bashrc
$ echo "export PATH=$PATH:/home/user/.rubygems/bin" >> /home/user/.bashrc
$ echo "export PATH=$PATH:/home/user/.rubygems/repos/bin" >> /home/user/.bashrc

Otra comprobación de las variables es con el comando


$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.0.1 (1.0.1)
  - RUBY VERSION: 1.8.5 (2006-08-25) [i486-linux]
  - INSTALLATION DIRECTORY: /home/user/.rubygems
  - RUBY EXECUTABLE: /usr/bin/ruby1.8
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-linux
  - GEM PATHS:
     - /home/user/.rubygems
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://gems.rubyforge.org

Como nota el procedimiento anterior soluciona los siguientes problemas al ejecutar Netbeans 6 en Debian (o Ubuntu)

  1. Your Ruby installation does not appear to have Ruby Gems installed. Cannot find “gem” command either in the interpreter’s folder or on the
    system path
  2. The gem repository is not writable as this user. Either install your gems elsewhere by changing Gem Home in the Ruby Plataform Manager to an alternative (and writable) repository or run as root, or manually change the gem repository file permissions, or build your own Ruby installation with user permissions.

Bibliografía

Servidor proxy de archivos Debian, Approx

Thursday, January 24th, 2008

Tabla de contenidos

  1. Marco teórico
  2. Funcionamiento de Approx
  3. Instalación y parámetros de configuración de Approx
  4. Papel del sources.list
  5. Armado de las parejas nombre/valor
  6. Reescritura de solicitudes
  7. Problemas frecuentes
  8. Puesta en marcha
  9. Beneficios
  10. Desventajas
  11. Notas finales
  12. Bibliografía

Marco teórico

Si una red local está formada por varios equipos Debian (o fork), un servidor proxy que mantiene repositorios locales de archivos Debian mejoraría el tiempo de respuesta y el uso de ancho de banda.

De esta manera cada vez que un equipo Debian actualice o instale archivos Debian, primero se revisará en el repositorio local, si el archivo se encuentra en él se suministrá, sino se encuentra, se revisará en los repositorios remotos. Estos archivos se guardarán en el repositorio local para futuras solicitudes.

Los repositorios locales, la administración y su gestión es realizado por el servidor proxy. Esta funcionalidad la podemos encontrar con Approx.

Funcionamiento de Approx

Approx permanece escuchando solicitudes de archivos Debian en algún puerto determinado, los clientes piden los archivos a Approx y éste es quién se encarga de buscar localmente el archivo, sino se encuentra, reescribe la solicitud recibida para enviarla a un repositorio remoto y descargar los archivos solicitados, éstos son entregados al cliente y son almacenados en el repositorio local.

Instalación y parámetros de configuración de approx

Primero tenemos que elegir la máquina de nuestra red que será el servidor proxy, una vez definida instalamos en ella el servidor


# aptitude install approx

Cuenta con un único archivo de configuración localizado en /etc/approx y los repositorios locales serán creados en /var/cache/approx. El archivo de configuración es muy pequeño y podemos encontrar los siguientes parámetros

interfaces
Es la interface de red por la cual escucha approx. Por defecto está en any.
port
Es el puerto por el cual approx escucha las solicitudes HTTP de archivos debian. Por defecto es el puerto 9999.
interval
Especifica el tiempo (minutos) en los que approx considerará a un archivo cacheado demasiado viejo, con lo cual antes de entregarlo consultará con el repositorio remoto si es que existe una versión más reciente. Por defecto está en 720 (12 horas).
max_wait
Especifica el tiempo que esperará un proceso approx para bajar archivos concurrentemente, antes de intentar bajar el archivo. (no me queda claro bien este parámetro, acepto ayuda :-P). Por defecto es 10 (segundos).
max_rate
Especifica el máximo de ancho de banda que se utilizará para bajar archivos de repositorios remotos. Con lo cual podemos limitar el ancho de banda utilizado por approx. Por defecto unlimited. Los valores pueden ser indicados con K(KiloBYTE), M(MegaBYTE) y G(GigaBYTE).
debug
Activa un log ubicado en /var/log/debug. Por defecto false.

El resto del archivo de configuración define una tabla hash (clave/valor), los cuales mapean el repositorio local con el repositorio remoto.

Papel del sources.list

Ahora debemos entender (mínimamente) el papel que cumple el archivo sources.list. Cuando se ejecuta, por ejemplo aptitude install mysql-server-5.0, el comando verifica el archivo sources.list (localizado en /etc/apt/) para obtener la dirección del repositorio remoto de archivo, y bajar en este caso mysql-server-5.0.

La sintaxis de un sources.list luce así

deb | deb-src uri distribución [sección1] [sección2] [...]

El primer campo indica el tipo de repositorio, binario (deb) o fuente (deb-source), el segundo, URI es la ubicación del repositorio de dónde obtendrá los archivos (http, ftp, file, etc) y el resto de los campos definen la distribución y tipos de componentes (main, contrib, non-free).

Entonces para poder utilizar el proxy, debemos modificar el sources.list de las máquinas clientes, para que dejen de apuntar a un repositorio remoto y lo hagan a nuestro sevidor proxy. Y el archivo de configuración de approx (approx.conf), tendrá las direcciones de los repositorios remotos de los sources.list’s clientes.

Armado de las parejas nombre/valor

Vamos a definirlas tomando un ejemplo. Tenemos un cliente Debian etch en nuestra LAN con la dirección 192.168.1.5 y el servidor proxy en la dirección 192.168.1.1. Primero tenemos que tomar la dirección que aparece en el sources.list de la máquina Debian, mapearla en el servidor proxy y sustituirla por la dirección del servidor proxy. Por ejemplo, obtendremos las direcciones del sources.list en 192.168.1.1


deb http://sft.if.usp.br/debian/ stable main
deb-src http://sft.if.usp.br/debian/ stable main
deb http://security.debian.org/ stable/updates main

Ahora las mapearemos con el repositorio local, esto se hace en el archivo /etc/approx/approx.conf


debian          http://sft.if.usp.br/debian/
security        http://security.debian.org/

Hemos definido que los archivos de la dirección http://sft.if.usp.br/debian/ se cacheen en el repositorio local llamado debian y los de http://security.debian.org/ en el repositorio llamado security. Estos repositorios se encontrarán en /var/cache/approx.

Ahora sólo falta modificar el sources.list de la máquina 192.168.1.5 para que apunte al proxy


deb http://192.168.1.1:9999/debian stable main
deb-src http://192.168.1.1:9999/debian stable main
deb http://192.168.1.1:9999/security stable/updates main

Lo que hemos hecho fue modificar el servidor remoto por nuestro proxy y además especificamos el repositorio local, el cuál mapea al repositorio remoto.

Reescritura de solicitudes

Ahora veremos como Approx reescribe la solicitude de un cliente utilizando su tabla hash de clave/valor

Archivo sources.list de cliente


deb http://192.168.1.1:9999/clave-repositorio2/  feisty main restricted

Donde el cliente hará solicitudes de la forma

http://192.168.1.1:9999/clave-repositorio2/otra/URL

Archivo approx.conf del servidor (192.168.1.1)


clave-repositorio1     http://sevidor-remoto-a/path
clave-repositorio2     http://sevidor-remoto-b/path
clave-repositorio3     http://sevidor-remoto-c/path

Solicitud armada por el servidor proxy, en caso que la búsqueda falle en el cache local

http://servidor-remoto-b/path/otra/URL

Problemas frecuentes

Es importante aquí entender la idea de hash (clave/valor), las palabras con rectángulo de color verde es una clave que le indica a approx cual dirección remota consultará, la cual se encuentra cacheada en un directorio dentro /var/cache/approx con el mismo nombre. Sino indicamos la clave de mapeo en el sources.list, approx no cacheará correctamente los archivos y desde la máquina cliente nos saldrán errores cómo


Err http://192.168.1.1 stable/main Packages
  403 Forbidden
Err http://192.168.1.1 stable/main Sources
  403 Forbidden
Err http://192.168.1.1 stable/updates/main Packages
  403 Forbidden
Leyendo lista de paquetes... Hecho
W: No se puede leer la lista de paquetes fuente http://192.168.1.1 stable/main Packages (/var/lib/apt/lists/192.168.1.1:9999_dists_stable_main_binary-i386_Packages) - stat (2 No existe el fichero o el directorio)
W: No se puede leer la lista de paquetes fuente http://192.168.1.1 stable/updates/main Packages (/var/lib/apt/lists/192.168.1.1:9999_dists_stable_updates_main_binary-i386_Packages) - stat (2 No existe el fichero o el directorio)
W: No se puede leer la lista de paquetes fuente http://192.168.1.1 stable/main Packages (/var/lib/apt/lists/192.168.1.1:9999_dists_stable_main_binary-i386_Packages) - stat (2 No existe el fichero o el directorio)
W: No se puede leer la lista de paquetes fuente http://192.168.1.1 stable/updates/main Packages (/var/lib/apt/lists/192.168.1.1:9999_dists_stable_updates_main_binary-i386_Packages) - stat (2 No existe el fichero o el directorio)
W: Tal vez quiera ejecutar 'apt-get update' para corregir estos problemas

Puesta en marcha

Una vez instalado y configurado Approx y editado la tabla de mapeo, debemos reiniciar el servidor (/etc/init.d/approx restart). Si al reiniciar falla, a habido un error en la sintaxis tanto de los parámetros o de la tabla. Ahora podríamos hacer una prueba. Desde la máquina Debian, en este caso 192.168.1.5, crearemos el repositorio


root@192.168.1.5:/# aptitude update

Este comando actualizará la lista de archivos disponibles de los servidores fuentes indicados en el sources.list.Veamos la secuencia de llamadas para comprender todo esto

  1. Se verifica el sources.list y se obtiene la dirección hacia donde se hará la solicitud
  2. La solicitud de la lista es escuchada por nuestro servidor proxy
  3. El proxy verifica el repositorio local (/var/cache/approx), en este caso debian y segurity. En esta busqueda no encontrará nada
  4. El proxy deberá solicitar la lista a los servidores remotos
  5. Buscará en su archivo de configuración la dirección de estos, mapeada por las claves anteriores (debian, security).
  6. El proxy solicita el listado al servidor remoto
  7. El listado será cacheado en el repositorio correspondiente para esa dirección
  8. El proxy entrega a 192.168.1.5 el listado

Beneficios

Aquí les dejo unos resultados realizados desde el cliente, no especifico cuestiones técnicas, sólo uno sin servidor proxy y otro con servidor proxy. Debe ser evidente el beneficio de tener un bicho de estos andando.


192.168.1.5:/# aptitude update
Des:1 http://sft.if.usp.br stable Release.gpg [378B]
Des:2 http://sft.if.usp.br stable Release [58,2kB]
Des:3 http://security.debian.org stable/updates Release.gpg [189B]
Des:4 http://security.debian.org stable/updates Release [37,6kB]
Des:5 http://sft.if.usp.br stable/main Packages [5621kB]
Des:6 http://security.debian.org stable/updates/main Packages [277kB]
Des:7 http://sft.if.usp.br stable/main Sources [1653kB]
Descargados 7647kB en 1m26s (88,1kB/s).                                       
Leyendo lista de paquetes… Hecho

192.168.1.5:/# aptitude update
Des:1 http://192.168.1.1 stable Release.gpg [378B]
Des:2 http://192.168.1.1 stable/updates Release.gpg [189B]
Des:3 http://192.168.1.1 stable Release [58,2kB]
Des:4 http://192.168.1.1 stable/updates Release [37,6kB]
Des:5 http://192.168.1.1 stable/main Packages [5621kB]
Des:6 http://192.168.1.1 stable/main Sources [1653kB]
Des:7 http://192.168.1.1 stable/updates/main Packages [277kB]
Descargados 7647kB en 18s (417kB/s).                                          
Leyendo lista de paquetes… Hecho

Desventajas

  • El uso de espacio de disco. No sé si realmente es una desventaja, pero en algunos casos el espacio utilizado por esto repositorios locales puede ser muy grande.
  • Inconsistencias. Nuestro repositorio local podría contener versiones de archivos desactualizadas en comparación con el repositorio remoto. Ya que por defecto el repositorio local es válido por 2 días, pero podríamos ajustar esto con el parámetro interval

Notas finales

Mi red está formada sólo por equipos Debian y Ubuntu. Mi servidor proxy mantiene repositorio tanto de Debian (etch) y de Ubuntu 7.04 y 7.10. Para cada distribución y versión utilizo diferentes palabras claves, ya que cada uno tiene diferentes repositorios locales.

Acá les dejo un fragmento de mi archivo approx.conf


debian-etch          http://sft.if.usp.br/debian/
security-etch        http://security.debian.org/

ubuntu-feisty          http://ar.archive.ubuntu.com/ubuntu/
security-feisty          http://security.ubuntu.com/ubuntu

ubuntu-gutsy          http://archive.canonical.com/ubuntu
security-gutsy          http://security.ubuntu.com/ubuntu/
ubuntu-gutsy          http://archive.ubuntu.com/ubuntu/

Bibliografía