Infosofía := 0×69AEE7

Trabajando en un proyecto, que lo tengo administrado bajo un repositorio en Subversion, me encontré con problemas al momento de realizar commit, vía web, de los cambios.

Obtenía el siguiente mensaje de error.

$ svn ci -m "cambios"
svn: Falló el commit (detalles a continuación):
svn: MKACTIVITY de '/svn/repos/projectNew/!svn/act/0a63fbb4-16d4-40b1-bc87-2f0dbd0eb709': 400 Bad Request (http://192.168.6.3)

Después de muchos idas y vueltas, pude hacerme con la solución. El problema surge de que el servidor de Subversión se encuentra detrás de un proxy web, específicamente un Squid, por lo tanto, cuando el cliente de Subversion se comunica con el servidor Subversion (vía HTTP), utiliza una serie de métodos que no eran interpretados por el proxy. Los métodos en cuestión pertenecen a un subconjunto del los métodos añadidos al HTTP por WebDAV.

Entonces, para poder solucionar esto, tendríamos que lograr que Squid interprete estos métodos. Por defecto, Squid no los interpreta pero los soporta, de modo que, tendremos que editar la configuración para indicárselo.

#  TAG: extension_methods
#       Squid only knows about standardized HTTP request methods.
#       You can add up to 20 additional "extension" methods here.
#
#Default:
# none
extension_methods REPORT MERGE MKACTIVITY CHECKOUT

Nota: Lo que está encerrado en rectángulo rojo es la configuración que debe ser agregada al archivo.

Una vez guardado los cambios, se debe reiniciar el servicio (/etc/init.d/squid force-reload) para que Squid tomé los cambios en la configuración.

Ahora si volvemos al cliente y probamos el commit no debería dar problemas

$ svn ci -m "cambios"
Enviando       informe/001.tex
Enviando       informe/002.tex
Enviando       informe/003.tex
Transmitiendo contenido de archivos .......
Commit de la revisión 87.

Referencias

• Métodos HTTP utilizados por Subversion[subversion.trigis.org]
• FAQ de Subversion[subversion.trigis.org]

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]

En
una de mis eufóricas búsquedas por internet me tropiezo ante este
paquete de Debian, el cual nos ofrece configurar una vaca
hablante/pensante; jaja, si correcto una VACA. Para probarlo

# aptitude install cowsay

Básicamente es un programa en Perl que genera una vaca en ASCII, la cual dice o piensa lo que el usuario le pase como argumento.

$ cowsay infosofía:=0x69AEE7
 ______________________
< infosofía:=0x69AEE7 >
 ———————-
        \   ^__^
         \   (oo)\_______
             (_ _)\            )\/\
                   | |—-w  |
                   | |        ||

O aquí tenemos la versión pensante de la vaca

# cowthink Como a caído el nivel de los post...
 _______________________________________
( Como a caído el nivel de los post... )
 ---------------------------------------
        o   ^__^
         o   (oo)\_______
              (_ _)\            )\/\
                     | |----w  |
                     | |        ||

Para finalizar, vale la pena mencionar que se puede cambiar el
aspecto de la vaca según su estado físico/emocional. Este se debe
especificar como parámetro al programa. Aquí dejo algunos:

-b

Vaca en modo Borg

-g

Modo codicioso

-d

Aparece muerta

-p

Estado de paranoia

-s

Petrificada

-t

Está cansada

-w

Lo contrario de -t

-y

Aspecto juvenil

Doxygen
es un sistema de generación de documentación. Aquí voy a mostrar como
instalarlo y una mínima configuración. Además dejo un ejemplo de la
salida generada en html.

Para instalar Doxygen sólo es necesario el siguiente paquete

$ aptitude install doxygen

Para mostrar cómo configurar doxygen nos valdremos del siguiente ejemplo. Por ejemplo mi proyecto lo tengo dentro de /var/www/proyecto1

Antes de configurarlo, tenemos que crear el archivo de
configuración. Para esto nos situamos en la raíz de nuestro proyecto (o
dónde les parezca que debería ser creado el archivo de configuración) y
hacemos

:/var/www/proyecto1# doxygen -g proyect1.cfg

Este archivo, nos permite modificar los parámetros del proceso de generación de documentación para ajustarse a nuestro proyecto.

Aquí dejo algunos de los puntos más importantes de la configuración:

# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
# base path where the generated documentation will be put.
# If a relative path is entered, it will be relative to the location
# where doxygen was started. If left blank the current directory will be used.

OUTPUT_DIRECTORY       = /var/www/proyecto1/doc

# The OUTPUT_LANGUAGE tag is used to specify the language in which all
# documentation generated by doxygen is written. Doxygen will use this
# information to generate all constant output in the proper language.
# The default language is English, other supported languages are:
# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional,
# Croatian, Czech, Danish, Dutch, Finnish, French, German, Greek, Hungarian,
# Italian, Japanese, Japanese-en (Japanese with English messages), Korean,
# Korean-en, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Russian,
# Serbian, Slovak, Slovene, Spanish, Swedish, and Ukrainian.

OUTPUT_LANGUAGE        = Spanish

# The INPUT tag can be used to specify the files and/or directories that contain
# documented source files. You may enter file names like "myfile.cpp" or
# directories like "/usr/src/myproject". Separate the files or directories
# with spaces.

INPUT                  = /var/www/proyecto1

# If the value of the INPUT tag contains directories, you can use the
# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
# and *.h) to filter out the source-files in the directories. If left
# blank the following patterns are tested:
# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py

FILE_PATTERNS          = *.php

# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
# will interpret the first line (until the first dot) of a JavaDoc-style
# comment as the brief description. If set to NO, the JavaDoc
# comments will behave just like the Qt-style comments (thus requiring an
# explicit @brief command for a brief description.

JAVADOC_AUTOBRIEF      = YES

En este enlace hay más ejemplos para la configuración. En sí el archivo está bastante documentado (:-P) y es suficiente por sí mismo.

Una vez terminado lo anterior nos situamos en la carpeta donde creamos el archivo de configuración, en este ejemplo en /var/www/proyecto1 y hacemos

# doxygen proyecto1.cfg

Esto generará la documentación en el directorio especificado en OUTPUT_DIRECTORY.

Dejo un pequeño ejemplo de cómo documentar una pequeña clase php.

Nota: Para que los comentarios sean generados en la salida, tiene que estar dentro de las etiquetas <?php ?>

La salida se genera dentro de /var/www/proyecto1/doc. Se
crean en este caso dos carpetas una html y la otra latex. Para ver la
documentación a través de la web, bastaría escribir la siguiente url en
su browser

http://localhost/proyecto1/doc/html

Dejo una imagen de como quedaría la clase anterior generada en html.

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

• http://wiki.rubyonrails.org/rails/pages/HowToUseMultipleGemRepositories
• http://lobotuerto.com/blog/2008/01/26/como-instalar-ruby-rubygems-y-rails-en-ubuntu-710-gutsy-gibbon/
• http://wiki.netbeans.org/RubyGems

Trabajando
en un proyecto utilizando las tecnologías JSP y Java, necesitaba
tenerlo en línea , por lo que levanté un Tomcat 5.5 en un Debian Etch,
toda la instalación y configuraciones no tuvieron mayores dificultades.
Pero cuando subía el WAR a través del Manager de Tomcat, no me desplegaba la aplicación, trate copiando directamente el war en /var/lib/tomcat5.5/webapps,
pero seguía con el mismo problema, no me reconocía el war y no me
dejaba ejecutarlo. Después de varios días investigando, encontré la
solución, no es una solución muy ingenieril, pero resuelve el problema
:-D.

WAR: Es un formato de archivo desarrollado por SUN,
que agrupa (agrega) todos los archivos de la aplicación en un único
archivo, bajo una estructura bien definida. Este archivo tiene una
estructura similar al JAR, pero se usa especialmente para archivos JSP, servelets, XML y otros objetos. Más información

El problema parece ser que viene del lado de los privilegios y la
seguridad del Tomcat, por esto al entrar al archivo de configuración (/etc/default/tomcat5.5)
y modificar una de sus variables, para deshabilitar la seguridad, pude
lograr que me desplegara la aplicación sin problemas. Acá dejo la
variable específica con el valor modificado

# Use the Java security manager? (yes/no, default: yes)
# WARNING: Do not disable the security manager unless you understand
# the consequences!
# NOTE: java-gcj-compat-dev currently doesn't support a security
# manager.
TOMCAT5_SECURITY=no

Recordar que una vez modificada, es necesario reiniciar Tomcat, /etc/init.d/tomcat5.5 restart.

Si alguien sabe como solucionar esto de una mejor manera, por favor
contactemé. De todos modos, si la encuentro antes prometo postearla.

Luego de varios días con depresiones derivadas de no encontrar una solución. Pude resolverlo, comparto aquí la solución.

Básicamente el problema es que al crear usuarios virtuales y luego tratar de conectarnos al servidor, nos falla el login.

pet@gatsu:/etc/pure-ftpd/conf# ftp localhost
Connected to localhost.
220---------- Welcome to Pure-FTPd [privsep] [TLS] ———-
220-You are user number 1 of 50 allowed.
220-Local time is now 02:58. Server port: 21.
220-This is a private system - No anonymous login
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 15 minutes of inactivity.
Name (localhost:alejandro): usuarioPedrito
331 User usuarioPredrito OK. Password required
Password:
530 Login authentication failed
Login failed.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

Y por más que cambiemos el password, el problema persiste.

Esto se debe a que Pure-ftp no esta utilizando el sistema de
autentificación para usuarios virtuales. Para solucionarlo, debemos ir
al directorio de autentificaciones /etc/pure-ftpd/auth. Aquí debemos encontrar dos links.

lrwxrwxrwx 1 root root 26 2006-10-25 12:42 65unix -> ../conf/UnixAuthentication
lrwxrwxrwx 1 root root 25 2006-10-25 12:42 70pam -> ../conf/PAMAuthentication

Estos links llevan a archivos de configuración para los diferentes
sistemas de autentificación que utiliza pure-ftp. Como puede verse, no
hay nada referido a nuestros usuarios virtuales, sólo sobre
autentificación de Unix y PAM. Otra cosa relevante de estos link es el
numero que se antepone al nombre. Pure-ftp prueba primero el sistema de autentificación de menor número.

Entonces simplemente tendremos que hacer un link al archivo PureDB
(archivo que maneja los usuarios virtuales) y el número en el nombre
del link, debe ser menor que los anteriores. Para esto, nos situamos en
la carpeta /etc/pure-ftpd/auth y ejecutamos el comando

ln -s ../conf/PureDB 50pure

Finalmente reiniciar el servidor.

Bibliografía

/usr/share/doc/pure-ftpd/README.Debian

www.linuxforums.org

Muchas
veces tenemos problemas al olvidarnos la contraseña de root de Mysql o
tomar la administración de un sistema en ejecución, donde el personal
no tiene documentado las usuario y contraseñas de Mysql. Estos
problemas pueden ser solucionados sin reinstalar Mysql, a través de un
modo de ejecución del servidor que salta los privilegios. De esta
manera podemos logearnos como root sin tener su contraseña y poder
modificar la vieja contraseña. Aquí comparto los pasos para lograrlo,
la explicación se basa en Debian y Ubuntu, en otras distribuciones
podría llegar requerir modificar los paths, pero el concepto es el
mismo.

1. Como primer paso paramos el servidor Mysql.

   
   # /etc/init.d/mysql stop
   

2. Ahora levantaremos el servidor sin privilegios. Para esto simplemente ejecutaremos el binario mysqld_safe pasandole como parámetro skip-grant-table. El ampersand al final indica que se ejecute el proceso en segundo plano.

   
   # /usr/bin/mysqld_safe --skip-grant-table &
   
   [1] 14836
   

3. Levantado el servicio, entramos a mysql como usuario root. Y una vez dentro, deberemos entrar a la base de datos llamada mysql. La cual mantienen información de administración del servidor.

   
   mysql -u root
   mysql>use mysql;
   

4. Para modificar el password, debemos actualizar el registro del
   usuario root. Los registros de los usuarios se encuentran en la tabla user. Así que simplemente haremos un update modificando el campo Password.

   
   update user set Password=PASSWORD('Nuevo_Password') where User='root';
   

   Nota: Respetar las mayúsculas.

5. Finalmente matamos el proceso anterior y volvemos a levantar el servidor.

   
   # kill -9 14836
   # /etc/init.d/mysql start
   

Bibliografía

• Raible’s Wiki

Desde hace unas semanas venimos traduciendo un HOWTO sobre los repositorios Debian, el cual se encuentra en inglés. El autor es Aaron Isotton.

La labor de traducción ha terminado, por lo que dejo un enlace hacia la traducción al español del HOWTO.

Este HOWTO está licenciado bajo GNU/FDL versión 1.1, por lo que dejo las fuentes en Latex del proyecto de traducción y una versión en PDF.

Infosofía:=0×69AEE7 agradece a Aaron Isotton por todas las molestias
y también a Mauricio Pasquier que contribuyó con el proyecto de
traducción.

Links de descargas

• Fuente
• Versión PDF

Acá dejo la solución a un error que ocurre al tratar de instalar Rails en Debian. Me base en un post[soulforged.net], que explica correctamente la solución del mismo, pero éste se basa en FreeBSD, de todos modos es un error propio de Ruby Gems y no del sistema operativo. El error en cuestión es

INFO: `gem install -y` is now default and will be removed
INFO: use –ignore-dependencies to install only the gems you list
ERROR: could not find rails locally or in a repository

Y sucede, una vez terminado de instalar Ruby y Ruby Gems, al trata de instalar
Rails. La solución es antes de intentar instalar Rails, ejecutar el siguiente
comando:

$ gem update --system

Es recomendado visitar el enlace que cité más arriba, porque trata sobre otros posibles errores y su solución.