Instalación de Redmine en Debian Squeeze + Apache2 + Passenger + mySql

Redmine es una herramienta para la gestión de proyectos y el seguimiento de errores escrita usando el framework Ruby on Rails. Incluye un calendario y unos diagramas de Gantt para la representación visual de la línea del tiempo de los proyectos. Es software libre y de código abierto, disponible bajo la Licencia Pública General de GNU v2.

Vamos a instalar redmine desde los archivos fuentes bajados de la página oficial, en un servidor Debian Squeeze con servidor web Apache2 con el módulo passenger y el gestor de base de datos mysql. Partimos de los dos artículos anteriores escritos en esta página: Introducción a Ruby on Rails con Debian Squeeze y Instalación de aplicaciones Ruby on Rails con Apache2+Passenger.

1) Descargamos los ficheros fuentes de la página oficial, nosotros vamos a descargar la versión 1.3.0. La descomprimimos y lo guardamos en /var/www, de esta manera en la carpeta /var/www/redmine-1.3.0 tendremos la aplicación guardada.

2) Creamos la base de datos y un usuario mysql para acceder a dicha base de datos:

create database redmine character set utf8;
grant all privileges on redmine.* to 'redmine'@'localhost' identified by 'my_password';

3) Configuramos los datos de acceso a la base de datos, para ello:

cd /var/www/redmine-1.3.0
cp config/database.yml.example config/database.yml

Y editamos el fichero dejándolo de la siguiente manera:

production:
  adapter: mysql
  database: redmine
  host: localhost
  username: redmine
  password: my_password
  encoding: utf8

4) Generamos una identificador de inicio

rake generate_session_store

Y migramos la base de datos:

RAILS_ENV=production rake db:migrate

En este paso obtenemos un error, ya que necesito la versión 1.1.0 de la gema rack. para ello:

gem install rack -v 1.1.0

Por último realizamos la configuración inicial con:

RAILS_ENV=production rake redmine:load_default_data

y escogemos el idioma , en nuwstro caso “es”.

5) Podemos comprobar su funcionamiento usando el servidor web webrick:

ruby script/server -b 192.168.100.10 -e production

y accediendo a la URL http://192.168.100.10:3000

6) Para que funcione usando apache2 con el módulo passenger, nos aseguramos que el módulo passenger y el módulo rewrite estén activos:

a2enmod passenger
a2enmod rewrite

Y creamos un fichero de configuración de un virtual host de la siguiente manera:

<VirtualHost *:80>
SetEnv RAILS_ENV production

ServerAdmin webmaster@localhost

DocumentRoot /var/www/redmine-1.3.0/public
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/redmine-1.3.0/public>
Order allow,deny
allow from all
AllowOverride All
 </Directory>
...

Reiniciamos el servicio y probamos a acceder a la página con la URL http://192.168.100.10

Posted in General at enero 17th, 2012. No Comments.
Tags: , , ,

Instalación de aplicaciones Ruby on Rails con Apache2+Passenger

Siguiendo con la serie de artículos introductorios a la programación con Ruby on Rails vamos a mostrar como implantar una aplicación ya desarrollada usando el servidor web Apache2 y el módulos passenger que nos permite que Apache ejecute código Ruby. Este tutorial mostrará la instalación y configuración del servidor web Apache2 par que sea capaz de servir la aplicación “videoclub” que habíamos construido en este otro artículo.

Lo primero que vamos a hacer es instalar el servidor y el módulo passenger que nos permite la ejecución de aplicaciones implementadas con Ruby, para ello:

aptitude install apache2 libapache2-mod-passenger

A continuación copiamos nuestro proyecto al directorio de trabajo del servidor web:

cp -R ~/proyectos/videoclub /var/www

Hacemos que dicho directorio sea propiedad del usuario ww-data:

chown -R www-data:www-data /var/www/videoclub

Por último editamos el fichero /etc/apache2/sites-available/default, donde encontramos la configuración del sitio web definido por defecto, y lo editamos dejándolo similar al siguiente:

<VirtualHost *:80>
SetEnv RAILS_ENV development

        ServerAdmin webmaster@localhost

        DocumentRoot /var/www/videoclub/public
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/videoclub/public>
                Order allow,deny
                allow from all
        </Directory>
....

Reiniciamos el servidor web:

/etc/init.d/apache2 restart

Y ya podemos acceder a nuestra aplicación, por ejemplo, desde el mismo servidor visitando la URL hhtp://localhost/peliculas

Posted in General at enero 9th, 2012. No Comments.
Tags: ,

Introducción a Ruby on Rails con Debian Squeeze

Ruby on Rails, también conocido como RoR o Rails es un framework de aplicaciones web de código abierto escrito en el lenguaje de programación Ruby, siguiendo el paradigma de la arquitectura Modelo Vista Controlador (MVC). Trata de combinar la simplicidad con la posibilidad de desarrollar aplicaciones del mundo real escribiendo menos código que con otros frameworks y con un mínimo de configuración. El lenguaje de programación Ruby permite la metaprogramación, de la cual Rails hace uso, lo que resulta en una sintaxis que muchos de sus usuarios encuentran muy legible. Rails se distribuye a través de RubyGems, que es el formato oficial de paquete y canal de distribución de bibliotecas y aplicaciones Ruby.

Podemos indicar que los diferentes elementos del sistema son los siguientes:

  • Ruby, el intérprete del lenguaje de programación
  • RubyGems, el gestor de paquetes de Ruby
  • Ruby on Rails, el framework para desarrollo de aplicaciones web en Ruby

Instalación

  1. Instalación de ruby: aptitude install ruby
  2. Instalación de rybygems: aptitude install rubygems
    • Para actualizar la versión de ruby:  gem update –system
    • Para ver los módulos (gemas) instalados: gem list
    • Para instalar un módulos: gem install módulo
  3. Instalación de Rails: aptitude install rails 
  4. Si vamos a usar mysql debemos instalar el driver mysql para RoR:
    aptitude install mysql-server
    aptitude install libmysqlclient-dev
    gem install mysql

Mi primera aplicación

Vamos a construir una aplicación que me permita insertar, modificar, listar y borrar los datos de una tabla. Una aplicación con estas características implementada en una lenguaje de programación Web tradicional,  por ejemplo PHP, conlleva la escritura de mucho código, además si utilizamos una base de datos MySQL nuestro código sólo será válido para este gestor de base de datos y tendremos que conocer el lenguaje SQL compatible con él. Veremos que la construcción de esta aplicación con RoR es muy sencilla utilizando las herramientas que nos ofrece. Vamos a crear una aplicación que nos permita la gestión de una base de datos de películas.

Creando un esqueleto

Lo primero que tenemos es que construir los ficheros y directorios de una aplicación base, para ello:

mkdir Proyectos
cd Proyectos
rails videoclub

Nuestra aplicación se va a llamar videoclub. Una aplicación rails se encuentra en el subdirectorio app y se compone de los siguientes directorios:

apis – las librerías que su programa requiere fuera de Rails mismo.
controllers – Los controladores
helpers – Los helpers
models – Los modelos. Básicamente las clases que representan los datos que nuestra aplicación manipulará.
views – Las vistas, que son archivos rhtml (como JSP o ASP).
views/layouts – Los diseños. Cada controlador tiene su propio diseño, donde se pondrán las cabeceras y pies de página.
config – Archivos de configuración. La configuración de la base de datos se encuentra aquí.
script – Utilerías para generar código y ejecutar el servidor.
public – La raíz del directorio virtual. Cualquier contenido que usted encuentre aquí será publicado en su aplicación directamente. En una nueva aplicación, usted puede encontrar las páginas web para los errores 404 y 500, las imágenes, javascripts, estilos, etcétera.
test – Los archivos para las pruebas funcionales y de unidad.

Configuración de la base de datos

El siguiente paso es configurar el acceso a nuestra base de datos, para ello modificamos el siguiente fichero:

cd videoclub
nano config/database.yml

Y lo configuramos de la siguiente manera:
development:
  adapter: mysql
  database: videoclub_dev
  host: localhost
  username: root
  password: password_del_root

test:
  adapter: mysql
  database: videoclub_test
  host: localhost
  username: root
  password: password_del_root

production:
  adapter: mysql
  database: videoclub_prod
  host: localhost
  username: root
  password: password_del_root

Si nos damos cuenta podemos ejecutar nuestra aplicación en tres entornos: desarrollo, test y producción, cada una de ellas tiene características distintas, y en cada uno de ellas podemos utilizar base de datos distintas. Por defecto estamos trabajando en el entorno de desarrollo.

Ahora podemos crear las bases de datos que necesitamos con la siguiente orden:

rake db:create:all

Probando nuestra aplicación

RoR posee un servidor web que es apropiado para hacer pruebas, para mostrar nuestra aplicación ejecutamos el servidor WEBrick:

ruby script/server

Con esta instrucción el servidor web es accesible sólo desde localhost, si queremos acceder desde otro cliente tenemos que indicarle la dirección IP dpnde se encuentra alojado, en este caso:

ruby script/server -b direccion_ip

Por defecto el servidor web funciona en el puerto 3000, de tal forma que podemos acceder a la página principal de nuestro proyecto:

Creando un andamio

Un andamio es una estructura que nos permite crear los recursos necesarios para gestionar una tabla en nuestra base de datos, vamos a crear un andamio (scafford) que nos permita gestionar una tabla de películas, con tres campos: título, descripción y URL de la carátula, para ello:

ruby script/generate scaffold Pelicula titulo:string descripcion:text url_caratula:string

De esta manera hemos creado un modelo de datos que podemos ver en el fichero creado en el directorio db/migrate, en mi caso:

nano db/migrate/20120107183925_create_peliculas.rb

class CreatePeliculas < ActiveRecord::Migration
  def self.up
    create_table :peliculas do |t|
      t.string :titulo
      t.text :descripcion
      t.string :url_caratula

      t.timestamps
    end
  end

  def self.down
    drop_table :peliculas
  end
end

Y migramos nuestro modelo a nuestro gestor de base de datos, con lo que se creara la tabla películas, con la siguiente instrucción:

rake db:migrate

A continuación iniciamos nuestro servidor web y accedemos a la siguiente URL, y ya tenemos funcionando nuestra aplicación: http://dirección_servidor:3000/peliculas

Espero que os haya funcionado.

Posted in General at enero 7th, 2012. No Comments.
Tags: ,

Nuevas revistas libres; Libresfera, CBEX123

Libresfera es una nueva revista que tiene como finalidad la promoción y difusión de la cultura libre. Como se indica en su página web:

Libresfera es una nueva revista en la que todo el mundo podrá colaborar, enviar sus artículos, imágenes, entrevistas… La temática será variada, pero siempre relacionada con contenidos abiertos. Todo pensado para tener informados a los lectores de como esta el panorama cultural libre.

En la página Proyecto Autodidacta podemos encontrar manuales de distintos aspectos de la informática en forma de comics, la revista CBEX123 es la recopilación que han hecho de esos comics de diferentes temas: software, hardware,… Pueden ser de gran utilidad para impartir las clases de informática de la ESO.

Estas dos nuevas revistas, y la actualización de los últimos números de las revistas Tuxinfo, FullCicle Magazine, Planetix, Atix,… los puedes encontrar en nuestra sección de Revistas Informáticas.

Posted in General at diciembre 1st, 2011. No Comments.
Tags: ,

Configuración de un servidor DNS esclavo

Siguiendo con los manuales sobre el servidor DNS Bind9, vamos a realizar la práctica de instalar un servidor esclavo, que contenga la réplica de las configuraciones de zonas que están definidas en el servidor maestro.

Los equipos que van a ser configurados como servidor maestro y esclavo son los siguientes:

  • bobesponja: Dirección ip 10.0.0.1 -> Servidor dns primario o maestro
  • patricio: Dirección ip 10.0.0.2 -> Servidor dns secundario o esclavo

Los servidores DNS que vamos a configurar van a tener autoridad para la zona examplo.com.

Lo primero que tenemos que hacer es configurar el servidor BIND primario para que solo acepte peticiones hacia los dominios de los cuales es un Servidor de Dominio, (los dominios de los cuales el va a ser un name server) y también las direcciones IP de los servidores BIND esclavos. Para ello en el archivo /etc/bind/named.conf.options hago las siguientes modificaciones:

options {
directory “/var/cache/bind”;
allow-query { 10.0.0.1/24; } ;
allow-transfer { none; };

...

auth-nxdomain no;    # conform to RFC1035
recursion no;
};

acl slaves {
10.0.0.2/24;           // patricio
};

Vamos a explicar cada una de las directivas:

  • allow-query { 10.1.1.1/28; } ; :  IP del servidor Primario de DNS
  • allow-transfer { none; }; : Con este parámetro restringimos la transferencia de zonas a Servidores DNS esclavos que no estén autorizados. Esta es una buena medida de seguridad, ya que evitamos que personas ajenas se enteren de las direcciones IP que están dentro de la zona de DNS de un dominio.
  • acl slaves { 10.0.0.2/24; }; : Listado de acceso (access list) de los servidores de DNS esclavos.

A continuación vamos a configurar la zona de resolución directa para nuestra zona en el servidor maestro, para ello creamos un archivo db.example.compara configurar la zona example.com, en /var/cache/bind:

@ IN SOA example.com. root.example.com. (
    1 ; Serial
    604800 ; Refresh
    86400 ; Retry
    2419200 ; Expire
    604800 ) ; Default TTL

    IN NS bobesponja.example.com.
    IN NS patricio.example.com.

bobesponja       IN A 10.0.0.1
patricio	 IN A 10.0.0.2
www              IN A 10.0.0.3

Suponemos que ne la dirección 10.0.0.3 vamos a tener un servidor web. Del mismo modo configuramos la zona de resolución inversa, creando el fichero db.0.0.10 en el mismo directorio:

@ IN SOA example.com. root.example.com. (
    1 ; Serial
    604800 ; Refresh
    86400 ; Retry
    2419200 ; Expire
    604800 ) ; Default TTL

    IN NS bobesponja.example.com.
    IN NS patricio.example.com.

1      IN PTR bobesponja.example.com.
2      IN PTR patricio.example.com.
3      IN PTR www.example.com.

A continuación en el fichero /etc/bind/named.conf.local definimos las zonas indicando quien puede hacer una petición de resolución de nombre al dominio y a quien le damos permiso para que pueda copiar las zonas, que en este caso solo seria a los servidores de DNS esclavos.

De esta manera en el fichero /etc/bind/named.conf.local del servidor maestro:

zone "example.com" {
type master;
file "db.example.com";
allow-query { any; };
allow-transfer { slaves; };
notify no;
};

zone "0.0.10.in-addr.arpa" {
type master;
file "db.0.0.10";
allow-query { any; };
allow-transfer { slaves; };
notify no;
};
  • allow-query { any; }; Cualquier computadora puede hacer una petición de DNS a este dominio.
  • allow-transfer { slaves; }; Con este parámetro le damos permiso a los servidores esclavos de DNS que puedan hacer una copia de la zona de DNS

En el caso del DNS esclavo tendremos que definir las zonas indicando donde se encuentra en DNS maestro, el fichero /etc/bind/named.conf.local del servidor esclavo quedaría de la siguiente forma:

zone "example.com" {
type slave;
masters { 10.0.0.1; };
file "db.example.com";
allow-query { any; };
};

// Archivo para búsquedas inversas
zone "0.0.10.in-addr.arpa" {
type slave;
masters { 10.0.0.1; }
;file "db.0.0.10";
allow-query { any; };
};
  • masters {  10.0.0.1;  }; Definimos a quien le debe pedir una copia de la zona de DNS para el dominio example.com que en nuestro caso seria el servidor de DNS primario.

Por último reiniciaremos el servicio de BIND en el servidor primario de DNS antes que los secundarios. Esto lo hacemos con el siguiente comando:

/etc/init.d/bind9 restart

Después de reiniciar el servicio, verificamos en el el “syslog” que nuestros servidores de DNS secundarios estén copiando la zona de DNS para example.com. Encontraremos un registro similar a este:

Nov 21 21:46:37 dns named[893]: client 10.0.0.2#39128: transfer of 'example.com/IN': IXFR started
Nov 21 21:46:37 dns named[893]: client 10.0.0.2#39128: transfer of 'example.com/IN': IXFR ended

Y ya podemos hacer la prueba de configurar un cliente para que use como servidores DNS nuestras máquinas bobesponja y patricio, y comprobar que si alguna de las dos están apagadas, la otra es la que resuelve.

Un saludo a todos.

Posted in General at noviembre 23rd, 2011. No Comments.
Tags: , ,

Problemas con DNS dinámico en Debian Squeeze

Llevo unos días preparando  la clase de DNS dinámico con bind9. Para ello he seguido algunos tutoriales muy interasantes que pudes encontrar en internet: DNS dinámico con Bind9, de Mario Carrión (antiguo alumno del ciclo), DNS dinámico “Desde lo alto del Cerro” de mi compañero Alberto Molina o este manual que elaboramos para un curso del CEP: DNS dinámico.

Sin embargo no había forma de actualizar el servidor DNS cuando un cliente recibía una nueva IP desde el servidor DHCP.

El problema está en la versión de BIND 9.7.2. En esta versión en el momento que configuramos la posibilidad de la actualización del servidor, por ejemplo en el fichero /etc/bind/named.conf

include "/etc/bind/rndc.key";
controls
{
  inet 127.0.0.1 port 953
  allow { 127.0.0.1; } keys {"rndc-key";};
};

Se producía un error que podíamos ver en el fichero de logs /var/log/syslog:

named[1577]: managed-keys-zone ./IN: loading from master file managed-keys.bind failed: file not found

El problema esta causado porque en la configuración no se ha incluido el fichero /etc/bind/bind.keys que contiene la clave pública para permitir la actualización del servidor por DNSSEC. Para arreglarlo podemosañadir ese fichero a la configuración, en /etc/bind/named.conf:

include "/etc/bind/bind.keys";

Y para evitar que se se escriban los errores en el registro:

touch /var/cache/bind/managed-keys.bind
chown bind:bind /var/cache/bind/managed-keys.bind

Espero que sea de utilidad.

Posted in General at noviembre 21st, 2011. No Comments.
Tags: , ,