Hugo Jiménez - Administración Linux

Trivnet port 8200

Hugo Jiménez-Pérez — Sat, 27 Sep 2014 23:06:00 +0200

About the port 8200

This morning I scanned the open TCP/UDP ports of my server, just to check that everything were ok. Although, I knew that the port 8200 was open and configured by myself I didn't remember which...

About the port 8200

This morning I scanned the open TCP/UDP ports of my server, just to check that everything were ok. Although, I knew that the port 8200 was open and configured by myself I didn't remember which service corresponds to such a port. Then I used Google looking for a fast answer and NOTHING! just the same output than this obtained from nmap: TCP/UDP port 8200 -- Service trivnet1.

The obvious alternative was looking for the port number into the config files of my server:

hugo@lamaitre ~# grep -rn 'port.*8200' /etc/*
/etc/minidlna.conf:2:port=8200
/etc/minidlna.conf.dpkg-dist:2:port=8200
hugo@lamaitre ~#

that's all!

The TRIVNET protocol is used by minidlna that I installed last year, to connect my cell phone, my tablet and my TV for sharing media files and storing them on the server.

As the home page of the ReadyMedia (formerly MiniDLNA) says: " ... ReadyMedia is server software with the aim of being fully compliant with DLNA/UPnP-AV clients. It is developed by a NETGEAR employee for the ReadyNAS product line. ..."

Probably it is more convenient to use something more relevant as information about the trivnet service. Personally I prefer naming the service as UPnP since DLNA uses Universal Plug and Play (UPnP) for media management, discovery and control.

Creación de un proyecto en Mercurial

Hugo Jiménez-Pérez — Fri, 16 May 2014 01:35:00 +0200

Pasos básicos para crear un proyecto en Mercurial

Desde hace algunos meses utilizo TRAC para la administrción de mis proyectos personales. El código fuente de los proyectos de programación es almacenado en un servidor Mercurial asociado al servidor TRAC. A continuación doy los pasos básicos para crear un proyecto y subirlo a mi servidor.

Primero creamos un directorio, y dentro inicializamos el proyecto

# mkdir solsys
# cd solsys
# hg init

Ahora editamos el archivo .hg/hgrc y agregamos las líneas

# vi .hg/hgrc
[paths]
default = ssh://hg@localhost/hugo/solsys

Ahora agregamos algunos archivos y algunos directorios:

# hg add Makefile
# hg add solar_kernel.cu
# hg add include/
ajout de include/dot_product.h
ajout de include/init.h
ajout de include/solarsys.h

Y hacemos el commit

# hg commit -m "Primer entrega" -u hugo

Ahora clonamos la información hacia el servidor

# hg clone . ssh://hg@localhost/hugo/solsys

Y finalmente enviamos todos los archivos

# hg clone . ssh://hg@localhost/hugo/solsys

Después de tener una versión para distribuir (aunque sea la primera versión alfa) tenemos que poner un tag. Vayamos al directorio raíz del código y creemos el archivo .hgtags

# touch .hgtags
# hg  tag v0.1 -u hugo
abandon : working copy of .hgtags is changed (please commit .hgtags manually)

Y hacemos el commit manual y lo enviamos con push

# hg commit .hgtags -m "Primer tag" -u hugo
# hg push
pushing to ssh://hg@localhost/hugo/solsys
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

Cuando agregamos una nueva clave ssh o modificamos la nuestra, debemos actualizar con

# /usr/share/mercurial-server/refresh-auth

Tips de administración de TRAC

Hugo Jiménez-Pérez — Fri, 16 May 2014 00:29:00 +0200

Algunos tips para los proyectos con TRAC

Desde hace algunos meses utilizo TRAC para la administrción de mis proyectos personales. Esta página tiene como objetivo guardar un registro de los pasos que debo seguir para crear un nuevo proyecto incluyendo el código fuente en Mercurial.

# trac-admin directorio_del_proyecto initenv

ahora debemos proporcionar el nombre del proyecto:

Nom du projet [My Project]> La2010 for CUDA

Ahora debemos de dar información sobre la base de datos de TRAC. En nuestra instalación utilizamos PostgreSQL así que como ya está configurado presionamos ENTER sin agregar nada más

Connection à la base de données [sqlite:db/trac.db]>

A continuación hay que agregar los permisos del administrador

# trac-admin /var/opt/trac/solsys permission add admin TRAC_ADMIN

Despues hacemos un upgrade

# trac-admin /var/opt/trac/solsys upgrade

Finalmente vamos al directorio (si es que hemos hecho otras cosas) y lanzamos el comando:

# cd /var/opt/trac/
# tracd --port 8000 --auth="musym,musym/.htpass,localdomain"  /var/opt/trac/musym/

Y modificamos el archivo /var/opt/trac/solsys/config/trac.ini para que se vea de la siguiente manera:

# -*- coding: utf-8 -*-

[TracPM]
default_estimate = 4.0
estimate_pad = 0.0
hours_per_estimate = 1
milestone_type = milestone
parent_format = %s

[account-manager]
account_changes_notify_addresses = 

[attachment]
max_size = 262144
max_zip_size = 2097152
render_unsafe_content = false

[browser]
color_scale = True
downloadable_paths = /trunk, /branches/*, /tags/*
hide_properties = svk:merge
intermediate_color = 
intermediate_point = 
newest_color = (255, 136, 136)
oldest_color = (136, 136, 255)
oneliner_properties = trac:summary
render_unsafe_content = false
wiki_properties = trac:description

[changeset]
max_diff_bytes = 10000000
max_diff_files = 0
wiki_format_messages = true

[components]
tracext.hg.* = enabled
graphviz.* = enabled
tracopt.ticket.commit_updater.* = enabled
mastertickets.* = enabled
tracjsgantt.* = enabled

[header_logo]
alt = (please configure the [header_logo] section in trac.ini)
height = -1
link = 
src = site/your_project_logo.png
width = -1

[hg]
node_format = short
show_rev = yes

[inherit]
htdocs_dir = 
plugins_dir = 
templates_dir = 

[logging]
log_file = trac.log
log_level = DEBUG
log_type = log

[milestone]
stats_provider = DefaultTicketGroupStatsProvider

[milestone-groups]
closed = closed,rejected
closed.order = 0
closed.css_class = closed
closed.label = closed
closed.overall_completion = true
active = *
active.order = 1
active.css_class = open
active.label = active

[mimeviewer]
max_preview_size = 262144
mime_map = text/x-dylan:dylan, text/x-idl:ice, text/x-ada:ads:adb
mime_map_patterns = text/plain:README|INSTALL|COPYING.*
pygments_default_style = trac
pygments_modes = 
tab_width = 8
treat_as_binary = application/octet-stream, application/pdf, application/postscript, application/msword,application/rtf,

[notification]
admit_domains = 
always_notify_owner = false
always_notify_reporter = false
always_notify_updater = true
ambiguous_char_width = single
batch_subject_template = $prefix Batch modify: $tickets_descr
email_sender = SmtpEmailSender
ignore_domains = 
mime_encoding = none
sendmail_path = sendmail
smtp_always_bcc = 
smtp_always_cc = 
smtp_default_domain = 
smtp_enabled = false
smtp_from = trac@localhost
smtp_from_author = false
smtp_from_name = 
smtp_password = 
smtp_port = 25
smtp_replyto = trac@localhost
smtp_server = localhost
smtp_subject_prefix = __default__
smtp_user = 
ticket_subject_template = $prefix #$ticket.id: $summary
use_public_cc = false
use_short_addr = false
use_tls = false

[project]
admin = 
admin_trac_url = .
descr = My example project
footer = Visit the Trac open source project at
http://trac.edgewall.org/
icon = common/trac.ico
name = La2010 for CUDA
url = 

[query]
default_anonymous_query = status!=closed&cc~=$USER
default_query = status!=closed&owner=$USER
items_per_page = 100
ticketlink_query = ?status=!closed

[report]
items_per_page = 100
items_per_page_rss = 0

[revisionlog]
default_log_limit = 100
graph_colors = ['#cc0', '#0c0', '#0cc', '#00c', '#c0c', '#c00']

[roadmap]
stats_provider = DefaultTicketGroupStatsProvider

[search]
min_query_length = 3

[tags]
listtagged_items_per_page = 100

[ticket]
default_cc = 
default_component = 
default_description = 
default_keywords = 
default_milestone = 
default_owner = < default >
default_priority = major
default_resolution = fixed
default_severity = 
default_summary = 
default_type = defect
default_version = 
max_comment_size = 262144
max_description_size = 262144
preserve_newlines = default
restrict_owner = false
workflow = ConfigurableTicketWorkflow

[ticket-custom]
blocking = text
blocking.label = Blocking
blockedby = text
blockedby.label = Blocked By

[ticket-workflow]
accept = new -> assigned
accept.operations = set_owner_to_self
accept.permissions = TICKET_MODIFY
leave = * -> *
leave.default = 1
leave.operations = leave_status
reassign = new,assigned,reopened -> new
reassign.operations = set_owner
reassign.permissions = TICKET_MODIFY
reopen = closed -> reopened
reopen.operations = del_resolution
reopen.permissions = TICKET_CREATE
resolve = new,assigned,reopened -> closed
resolve.operations = set_resolution
resolve.permissions = TICKET_MODIFY

[timeline]
abbreviated_messages = True
changeset_collapse_events = false
changeset_long_messages = false
changeset_show_files = 0
default_daysback = 30
max_daysback = 90
newticket_formatter = oneliner
ticket_show_details = false

[trac]
authz_file = 
authz_module_name = 
auto_preview_timeout = 2.0
auto_reload = False
backup_dir = db
base_url = 
database = postgres://hugo:*******@localhost:5432/tracdb
debug_sql = False
default_charset = utf-8
default_date_format = iso8601
default_dateinfo_format = relative
default_handler = WikiModule
default_language = 
default_timezone = Europe/Paris
genshi_cache_size = 128
htdocs_location = 
ignore_auth_case = false
jquery_location = 
jquery_ui_location = 
jquery_ui_theme_location = 
mainnav = wiki, timeline, roadmap, browser, tickets, newticket, search
metanav = login, logout, prefs, help, about
mysqldump_path = mysqldump
never_obfuscate_mailto = false
permission_policies = DefaultPermissionPolicy, LegacyAttachmentPolicy
permission_store = DefaultPermissionStore
pg_dump_path = pg_dump
repository_dir = /var/lib/mercurial-server/repos/hugo/solsys
repository_sync_per_request = (default)
repository_type = hg
resizable_textareas = true
secure_cookies = False
show_email_addresses = false
show_ip_addresses = false
timeout = 20
use_base_url_for_redirect = False
use_xsendfile = false

[trac-jsgantt]
option.caption = Resource
option.colorby = priority
option.comp = 1
option.datedisplay = mm/dd/yyyy
option.dur = 1
option.enddate = 1
option.expandclosedtickets = 1
option.format = day
option.formats = day|week|month|quarter
option.hoursperday = 8.0
option.omitmilestones = 0
option.openlevel = 999
option.res = 1
option.sample = 0
option.schedule = alap
option.showdep = 1
option.startdate = 1
option.usermap = 1

[versioncontrol]
allowed_repository_dir_prefixes = 

[wiki]
ignore_missing_pages = false
max_size = 262144
render_unsafe_content = false
safe_schemes = cvs, file, ftp, git, irc, http, https, news, sftp, smb, ssh, svn, svn+ssh
split_page_names = false

Probablemente algún día expique el contenido del archivo.

CUDA 5.5 on Debian Jessie.

Hugo Jiménez-Pérez — Sat, 03 Aug 2013 13:04:00 +0200

How-To get CUDA 5.5 running on Debian Jessie

Unfortunatelly, Debian is not officially supported by the nVidia's CUDA SDK. For version older than 5.0 it is not a problem, however to compile the nVidia drivers on Debian testing for a new Kepler's based nVidia card is a little tricky.

Begin from the beginning:

I have an AMD based CPU with an integrated motherboard and a Zotac video card with a nVidia GTX 650i Boost chip. This chip is based on the new nVidia's Kepler technology which supports dynamic parallelization on the GPU. My interest is to have the on board Radeon video card as main display, and the nVidia GPU for scientific computing. This post is oriented to compiling the nvidia video driver in Debian Jessie (at this point the testing release) and configuring the CUDA 5.5 SDK for parallel development.

Turn off the XServer and delete the free driver nouveau

# apt-get install mercurial mercurial-common

El instalador de Debian, incluirá los paquetes Mercurial y Mercurial-common además de instalar el servidor de SSH . Si no tiene instalado Python el instalador también lo considerará y hará una primera configuración del sistema. Una vez que haya terminado verifique la instalación con

# hg --version

Una vez que tiene instalado mercurial-server, puede iniciar la configuración básica y trabajar directamente con los depósitos a través de SSH. La desventaja es que no tendrá una interfaz gráfica y en algunos casos eso puede ser un problema. El método que implementaremos crea un depósito (repository) de aplicaciones sobre una instalación de Apache2 funcional. Supondremos que tiene una instalación de Apache2 básica (vea instalación de Apache Web server).

Necesitará instalar el módulo libapache2-mod-wsgi mediante

# apt-get install libapache2-mod-wsgi

Recuerde que en Debian, los guiones de pre-instalación y de post-instalación le dejarán un entorno listo para continuar trabajando. Incluso, reiniciarán el servidor de Apache de manera automática.

Ahora debemos crear un servidor virtual que atienda únicamente las peticiones de mercurial a la manera de Debian. Cree el archivo mercurial dentro del directorio /etc/apache2/sites-available/ con el siguiente contenido

 <VirtualHost *:80>
    ServerName hg1.ejemplo.com
    ServerAdmin webmaster@hg1.ejemplo.com
    DocumentRoot /var/www/mercurial/htdocs
    ErrorLog /var/log/apache2/hg-error_log
    CustomLog /var/log/apache2/hg-access_log common

    WSGIScriptAliasMatch ^(.*)$ /var/www/mercurial/cgi-bin/hgwebdir.wsgi$1

    # To enable "daemon" mode, uncomment following lines. 
    # (Read mod_wsgi docs for more info)
    # WSGIDaemonProcess hg1.ejemplo.com 
    # user=USER 
    # group=GROUP 
    # threads=15 
    # maximum-requests=1000
    # some more interesting options (tested on mod_wsgi 2.0):
    # processes=2 
    # umask=0007 
    # display-name=wsgi-hg1.ejemplo.com 
    # inactivity-timeout=300
    # WSGIProcessGroup hg1.ejemplo.com

    <Directory /var/www/mercurial/htdocs>
        Options FollowSymlinks
        DirectoryIndex index.html

        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>

    <Directory /var/www/mercurial/cgi-bin>
        Options ExecCGI FollowSymlinks

        AddHandler wsgi-script .wsgi

        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

El ejemplo anterior se ha tomado del manual en línea de Mercurial para la instalación de modwsgi en Mercurial.

Ahora vaya al directorio /etc/apache2/sites-enabled y cree un enlace simbólico al archivo anterior de la forma

# cd /etc/apache2/sites-enabled
# ln -s ../sites-available/mercurial 011-mercurial

o utilice el comando

# a2ensite mercurial

(a2ensite="apache 2 enable site")

Cree los directorios donde se colocarán los proyectos y la configuración de mercurial

# mkdir -p /var/www/mercurial/htdocs
# mkdir /var/www/mercurial/cgi-bin

cree el archivo hgwebdir.config

SSL en Apache2

Instale el paquete que hará la creación de certificados qu es un wrapper para openssl

# apt-get install ssl-cert

Habilite el modulo de SSL para que funcione con apache

# a2enmod ssl

(a2enmod=apache2 enable module)

Configure openssl

# vi /etc/ssl/openssl.cnf

Si desea tener un certificado para un servidor de prueba... puede utilizar directamente el comando

# mkdir /etc/apache2/ssl
# cd /etc/apache2/ssl
# make-ssl-cert /usr/share/ssl-cert/ssleay.cnf  localcerts

La clave y el certificado se encuentran es el mismo archivo. Ahora separe en dos archivos que llamaremos site.key y site.pem y los colocamos en el mismo directorio con permisos 400 y 600 respectivamente.

# chmod 600 site.pem
# chmod 400 site.key

Creemos el archivo de contraseñas que se utilizará para acceder al depósito de mercurial

# mkdir /etc/apache2/htpasswd

# htpasswd -cm /etc/apache2/htpasswd/ht.passwd hugo

A continuación creamos el archivo del servidor virtual seguro y agregaremos la información del certificado y de la clave asignando la trayectoria completa de los archivos a las variables SSLCertificateFile y SSLCertificateKeyFile respectivamente. Cree el archivo /etc/apache2/sites-available/mercurial-ssl con el siguiente contenido

 <VirtualHost *:443>
       SSLEngine On
       SSLCertificateFile /etc/apache2/ssl/site.pem
       SSLCertificateKeyFile /etc/apache2/ssl/site.key
       # SSLCertificateChainFile /trayectoria/a/DigiCertCA.pem

       ServerName hg1.ejemplo.com
       ServerAdmin webmaster@hg1.ejemplo.com
       DocumentRoot /var/www/mercurial/htdocs/
       ErrorLog /var/log/apache2/ssl.hg-error.log
       CustomLog /var/log/apache2/ssl.hg-access.log common

       WSGIScriptAliasMatch ^(.*)$ /var/www/mercurial/cgi-bin/hgwebdir.wsgi$1

       <Directory /var/www/mercurial/htdocs>
               DirectoryIndex index.html
               AddHandler wsgi-script .wsgi
               Options ExecCGI
               Order allow,deny
               Allow from all
       </Directory>

       <Location / >
               AuthType Basic
               AuthName "Ejemplo - Mercurial Repository"
               AuthUserFile /etc/apache2/htpasswd/hg.passwd

               Require valid-user
       </Location>

</VirtualHost>

Active el sitio https://hg1.ejemplo.com que tiene configurado en el archivo mercurial-ssl y reinicie el servidor. Si todo marcha bien, tendrá su sitio Web seguro con soporte bajo SSL

# a2ensite mercurial-ssl
# /etc/init.d/apache2 restart

Para probar que su sitio Web seguro está funcionando ejecute el comando

# curl -k https://hg1.ejemplo.com

La opción -k le indica al comando curl que no haga la verificación del certificado , en caso de no utilizarla, recibirá un mensaje de error que no nos permitirá conocer el estado real de la instalación.

Ahora podrá conectarse a su sitio web seguro en la dirección https://hg1.ejemplo.com si está utilizando un navegador Web configurado de manera adecuada, recibirá un mensaje de precaución indicando que el sitio Web tiene un certificado de seguridad autorizado localmente. Si desea tener un certificado auténtico existen diversas compañías (como DigiCert ) que comercializan este tipo de certificados y usted sólo deberá ejecutar las tareas de copia y asignación de permisos en el directorio /etc/apache2/ssl, los demás pasos son equivalentes.

También puede crear un certificado de autenticidad (CA) para su propia compañía y designar sus trayectorias de autenticación internas. Le recomendamos revisar el manual de configuración y la página de preguntas frecuentes de Apache y OpenSSL directamente.

Instalación de Mercurial

Hugo Jiménez-Pérez — Mon, 26 Apr 2010 01:50:00 +0200

Instalación de Mercurial sobre Apache con autenticación SSL

En esta ocasión vamos a instalar el servidor de control de versiones Mercurial y utilizaremos Apache con mod_ssl como interfaz Web. Suponemos que el código que se alojará en ese servidor no es público, así que utilizaremos autenticación por contraseñas bajo SSL.

Instalación de Mercurial:

Para instalar Mercurial en un servidor que contendrá el código fuente de una applicación que deseamos distribuir debemos utilizar los siguienetes comandos como superusuario:

Para instalar el servidor de Mercurial en Debian, sólo se requiere utilizar el comando

# apt-get install mercurial mercurial-common

# hg --version

Necesitará instalar el módulo libapache2-mod-wsgi mediante

# apt-get install libapache2-mod-wsgi

 <VirtualHost *:80>
    ServerName hg1.ejemplo.com
    ServerAdmin webmaster@hg1.ejemplo.com
    DocumentRoot /var/www/mercurial/htdocs
    ErrorLog /var/log/apache2/hg-error_log
    CustomLog /var/log/apache2/hg-access_log common

    WSGIScriptAliasMatch ^(.*)$ /var/www/mercurial/cgi-bin/hgwebdir.wsgi$1

    # To enable "daemon" mode, uncomment following lines. 
    # (Read mod_wsgi docs for more info)
    # WSGIDaemonProcess hg1.ejemplo.com 
    # user=USER 
    # group=GROUP 
    # threads=15 
    # maximum-requests=1000
    # some more interesting options (tested on mod_wsgi 2.0):
    # processes=2 
    # umask=0007 
    # display-name=wsgi-hg1.ejemplo.com 
    # inactivity-timeout=300
    # WSGIProcessGroup hg1.ejemplo.com

    <Directory /var/www/mercurial/htdocs>
        Options FollowSymlinks
        DirectoryIndex index.html

        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>

    <Directory /var/www/mercurial/cgi-bin>
        Options ExecCGI FollowSymlinks

        AddHandler wsgi-script .wsgi

        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

El ejemplo anterior se ha tomado del manual en línea de Mercurial para la instalación de modwsgi en Mercurial.

Ahora vaya al directorio /etc/apache2/sites-enabled y cree un enlace simbólico al archivo anterior de la forma

# cd /etc/apache2/sites-enabled
# ln -s ../sites-available/mercurial 011-mercurial

o utilice el comando

# a2ensite mercurial

(a2ensite="apache 2 enable site")

Cree los directorios donde se colocarán los proyectos y la configuración de mercurial

# mkdir -p /var/www/mercurial/htdocs
# mkdir /var/www/mercurial/cgi-bin

cree el archivo hgwebdir.config

SSL en Apache2

Instale el paquete que hará la creación de certificados qu es un wrapper para openssl

# apt-get install ssl-cert

Habilite el modulo de SSL para que funcione con apache

# a2enmod ssl

(a2enmod=apache2 enable module)

Configure openssl

# vi /etc/ssl/openssl.cnf

Si desea tener un certificado para un servidor de prueba... puede utilizar directamente el comando

# mkdir /etc/apache2/ssl
# cd /etc/apache2/ssl
# make-ssl-cert /usr/share/ssl-cert/ssleay.cnf  localcerts

# chmod 600 site.pem
# chmod 400 site.key

Creemos el archivo de contraseñas que se utilizará para acceder al depósito de mercurial

# mkdir /etc/apache2/htpasswd

# htpasswd -cm /etc/apache2/htpasswd/ht.passwd hugo

 <VirtualHost *:443>
       SSLEngine On
       SSLCertificateFile /etc/apache2/ssl/site.pem
       SSLCertificateKeyFile /etc/apache2/ssl/site.key
       # SSLCertificateChainFile /trayectoria/a/DigiCertCA.pem

       ServerName hg1.ejemplo.com
       ServerAdmin webmaster@hg1.ejemplo.com
       DocumentRoot /var/www/mercurial/htdocs/
       ErrorLog /var/log/apache2/ssl.hg-error.log
       CustomLog /var/log/apache2/ssl.hg-access.log common

       WSGIScriptAliasMatch ^(.*)$ /var/www/mercurial/cgi-bin/hgwebdir.wsgi$1

       <Directory /var/www/mercurial/htdocs>
               DirectoryIndex index.html
               AddHandler wsgi-script .wsgi
               Options ExecCGI
               Order allow,deny
               Allow from all
       </Directory>

       <Location / >
               AuthType Basic
               AuthName "Ejemplo - Mercurial Repository"
               AuthUserFile /etc/apache2/htpasswd/hg.passwd

               Require valid-user
       </Location>

</VirtualHost>

Active el sitio https://hg1.ejemplo.com que tiene configurado en el archivo mercurial-ssl y reinicie el servidor. Si todo marcha bien, tendrá su sitio Web seguro con soporte bajo SSL

# a2ensite mercurial-ssl
# /etc/init.d/apache2 restart

Para probar que su sitio Web seguro está funcionando ejecute el comando

# curl -k https://hg1.ejemplo.com

Manejo de proyectos en Webistrano

Hugo Jiménez-Pérez — Wed, 21 Apr 2010 01:07:00 +0200

Creación de proyectos en Webistrano

Este artículo finaliza la instalación de Webistrano y la distribución de una aplicación simple. En los dos artículos anteriores se hizo la instalación de Capistrano y Webistrano, configurando Apache para que alojara a este último como un servidor Web Vitual. Aquí veremos el manejo básico de proyectos, etapas, equipos y usuarios en Webistrano.

Instalación de Capistrano-Webistrano| Instegración bajo Apache

Distribuyendo una aplicación no Rails

Ahora la parte divertida.

Capistrano clasifica las cosas en proyectos, etapas y recetas. Cada aplicación que desee que sea distribuida por Capistrano debe tener su propio proyecto. Cada proyecto debe tener una etapa al menos y opcionalmente permitir la configuración de etapas y de distribución.

Los equipos se deben de agregar de manera global y constituirán los objetivos de una distribución para un proyecto dado. Los equipos pueden incluir servidores de Web, de applicaciones y de bases de datos.

Las distribuciones en Capistrano se colocan en un subdirectorio dentro del directorio release que se nombra en base a la fecha y la hora de la distribución. De manera predeterminada se mantienen 5 liberaciones con la información para deshacer los cambios. Hasta el momento en que una distribución es exitosa se acualiza un enlace hacia ese directorio de distribución (simlink que lleva el nombre predeterminado de current y puede modificarse mediante la variable de configuración current_path). Este enlace es el que debe considerarse en la configuración del servidor de Apache (de hecho debe ser el valor de DocumentRoot).

Capistrano también crea un directorio compartido cuyo nombre es shared que se enlaza en cada liberación y se utiliza para almacenar las bitácoras y otros datos adicionales que deban mantenerse entre cada distribución.

Para aplicaciones que no sean de tipo Rails usted deberá utilizar el tipo de proyecto Pure File al momento de crearlo. Después de la creación del proyecto podrá agregar las variables de configuración específicas para ese proyecto. Se recomienda utilizar la opción :export en lugar de :checkout para la instrucciốn deploy_via para las distribuciones de producción de la aplicación subversion; de esta forma no se expondrán los directorios .svn. Utilice un usuario de SSH que tenga los permisos suficientes para crear directorios donde la distribución se lleve a cabo, o epecifique el valor de user_sudo en true y cree una variable de configuración runner admin_runner:admin_runner en el archivo /etc/sudoers.

Agregue una etapa para producción a su proyecto mediante production. En la página Manage Hosts agregue un equipo por cada servidor donde se instalará la applicación. Después agregue cada equipo como un objetivo target para la etapa production de su proyecto.

En este punto puede ejecutar la tarea Setup para la etapa production. Esta es una tarea que se ejecuta sólo una vez y simplemente crea los subdirectorios.

Asumamos que todo salió bien, intente entonces una distribución con Deploy y vea si finaliza son errores. Deberá tener cuidado de asignar los permisos adecuados a los directorios.

Para un entorno de aplicaciones PHP hay un par de tareas adicionales que vamos a ejecutar además de las tareas que realiza Capistrano. Realícelas creando recetas personalizadas en la página Manage Recipes en Webistrano. Las recetas son simplemente procedimientos escritos en Ruby. A continuación verá el código de estas recetas:

namespace :deploy do
    task :setup, :except => { :no_release => true } do
        dirs = [deploy_to, releases_path, shared_path]
        dirs += shared_children.map { |d| File.join(shared_path, d) }
        run "#{try_sudo} mkdir -p #{dirs.join(' ')} && #{try_sudo} chmod g+w #{dirs.join(' ')}"
        run "chmod 777 #{shared_path}/log"
    end
 
    task :finalize_update, :except => { :no_release => true } do
        run "mkdir -p #{latest_release}/app/tmp"
        run "chmod -R 777 #{latest_release}/app/tmp"
        run "rm -rf #{latest_release}/app/logs"
        run "ln -s #{shared_path}/log #{latest_release}/app/logs"
        run "cp #{latest_release}/public_html/.htaccess-production #{latest_release}/public_html/.htaccess"
        run "cp #{latest_release}/app/config/config-production.php #{latest_release}/app/config/config.php"
        run "cp #{latest_release}/app/config/db-default.php #{latest_release}/app/config/db.php"
        run "cp #{latest_release}/app/config/memcache-default.php #{latest_release}/app/config/memcache.php"
    end
end

Si aún no está familiarizado con Ruby, le diré que este código esencialmente sobrescribe dos tareas en el espacio de nombres :deploy.

El primer :setup simplemente duplica la funcionalidad de base discutida anteriormente (crear las liberaciones y los directorios compartidos) y cambia los permisos de acceso a dichos directorios.

La segunda tarea :finalize_update, realiza una serie de tareas de configuración para una aplicación PHP construida en mi framework. También notará que he eliminado el directorio de las bitácoras y el enlace al directorio de bitácoras compartidas. De esta forma todas las liberaciones enviarán sus bitácoras al mismo directorio.

Todos estos procedimientos son instrucciones en la línea de comandos. De manera alternativa, puede hacer una variedad de cosas explotando las capacidades del menguaje Ruby y de cualquier gem que usted escriba. Cosas como acceder a las APIs de CDN para eliminar imágenes, archivos JS o CSS del directorio de cache, etc.

Distribuyendo aplicaciones Django

En primera, lo mejor es que distribuya las aplicaciones Django mediante el módulo mod_wsgi. Para facilitar el proceso de distribución cree el guión app.wsgi de la siguiente forma:

1 import os
2 import sys
3
4 appdir = os.path.normpath(os.path.join(os.path.realpath(os.path.dirname(__file__)), '..'))
5 sys.path.insert(0, appdir)
6 os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
7 os.environ['PYTHON_EGG_CACHE'] = os.path.join(appdir, '.python-eggs')
8 import django.core.handlers.wsgi
9 application = django.core.handlers.wsgi.WSGIHandler()

Este código evita que usted escriba las trayectorias de archivo en los guiones wsgi (y por lo tanto que tenga que cambiarlos al momento de distribuirlos). El código asume la siguiente estructura de archivos:

.python-eggs (egg cache)
apps (apps path is added to python system path in settings.py)
public (where your .wsgi script resides)
site_media
templates
settings.py
settings-production.py (used for deploy)
urls.py
...

Si sigue esta convención, la siguiente receta de Capistrano trabaja muy bien:

01 namespace :deploy do
02 task :setup, :except => { :no_release => true } do
03 dirs = [deploy_to, releases_path, shared_path]
04 dirs += shared_children.map { |d| File.join(shared_path, d) }
05 run "#{try_sudo} mkdir -p #{dirs.join(' ')} && #{try_sudo} chmod g+w #{dirs.join(' ')}"
06 run "chmod 777 #{shared_path}/log"
07 end
08
09 task :finalize_update, :except => { :no_release => true } do
10 run "rm -rf #{latest_release}/logs"
11 run "ln -s #{shared_path}/log #{latest_release}/logs"
12 run "cp #{latest_release}/settings-production.py #{latest_release}/settings.py"
13 run "mkdir -p #{latest_release}/.python-eggs"
14 run "chmod 777 #{latest_release}/.python-eggs"
15 end
16 end

Instalación de Capistrano-Webistrano| Instegración bajo Apache

Instalando Webistrano 1.5 en Debian Squeeze II.

Hugo Jiménez-Pérez — Tue, 20 Apr 2010 17:53:00 +0200

Continuación de la instalación de Webistrano.

En este artículo configurará Webistrano para que se ejecute como un servidor virtual dentro de apache. El módulo passenger de apache permite esta integración.

Instalación de Capistrano-Webistrano| Manejo de proyectos en Webistrano

Phusion Passenger

Si usted desea tener un entorno adecuado para producción real puede utilizar Phusion Passenger. En una sesión de root instale el siguiente paquete:

# apt-get install libapache2-mod-passenger

Si usted está usando otra versió de Linux diferente a Debian, el proceso de installación es completamente distinto. Revise el sitio de ModRails para obtener información sobre el proceso de instalasión y configuración en otras distribuciones de Linux.

Los archivos pre-inst y post-inst del instalador dpkg configurarán los módulos en Apache, solo debemos verificar que los datos sean los correctos. Solo debe editar el archivo /etc/apache2/mods-available/passenger.conf para que contenga los valores correctos de su configuración. Debe verse de la siguiente manera

<IfModule mod_passenger.c> 
    PassengerRoot /usr/lib/ruby/1.8/phusion_passenger
    PassengerRuby /usr/bin/ruby 
</IfModule>

La variable PassengerRoot tiene el valor predeterminado de /usr así que este cambio siempre será necesario.

Ahora, cree un archivo llamado webistrano en el directorio /etc/apache2/sites-available/ y agregue la siguiente información

<VirtualHost *:80>
    ServerName webistrano.ejemplo.com
    DocumentRoot /var/opt/webistrano/public 
</VirtualHost>

Guarde el archivo y cree un enlace simbólico en el directorio /etc/apache2/sites-enabled con el comando

# cd /etc/apache2/sites-enabled/
# ln -s ../sites-available/webistrano webistrano

Reinicie Apache para que el servidor cargue la nueva configuración

# /etc/init.d/apache2 restart

y verifique que el servidor de bases de datos esté funcionando.

Ahora puede abrir su navegador Web y escribir http://webistrano.ejemplo.com, obtendrá una pantalla como la siguiente:

Vea que en la barra de direcciones del navegador, aparece la URL como http://webistrano.ejemplo.com/sessions/new a diferencia de la dirección del artículo anterior que era http://webistrano.localhost/sessions/new. La imagen NO está editada, es la original (y probablemente tenga el nombre en inglés porque eran mis pruebas).

Otro detalle. Si obtiene un mensaje que no existe esa dirección Web, entonces debe configurar su DNS, NIS, LDAP o archivo hosts para que traduzca la dirección lógica en numérica. Si está en su entorno de prueba (y está acostumbrado al manejo de la línea de comandos) puede agregar esta línea en el archivo /etc/hosts mediante el comando

# echo "127.0.0.1 webistrano.ejemplo.com" >> /etc/hosts

En un entorno de producción, deberá hacer una copia de respaldo del archivo /etc/hosts, editar el original para agregar

127.0.0.1 webistrano.ejemplo.com

y guardar el archivo de forma segura. Por supuesto, en un entorno de producción usted agregará el registro en su servidor DNS, NIS, LDAP o aquel que utilice para la resolución de nombres.

Ahora simplemente debe agregar entradas VirtualHost a su archivo /etc/apache2/sites-availables/webistrano para cada una de sus aplicaciones Rails. Agregue las directivas de configuración que mejor se adapten a su sistema.

Hasta la próxima...

Instalación de Capistrano-Webistrano| Manejo de proyectos en Webistrano

Instalando Webistrano 1.5 en Debian Squeeze I.

Hugo Jiménez-Pérez — Mon, 19 Apr 2010 17:53:00 +0200

Un pequeño tutorial de instalación de Webistrano.

Este tutorial esta pensado para aquellos administradores que utilizan Debian y deseean iniciar una administración centralizada de una red Linux-UNIX mediante SSH-BASH-Ruby.

Instegración bajo Apache| Manejo de proyectos en Webistrano

Hola a todos!

Ahora que debo trabajar con Webistrano y Capistrano para instalar un servidor de distribución de aplicaciones (Application Deployment), pensé que sería un excelente pretexto para escribir el tutorial... como muchos ya me conocerán, siempre hacemos la instalación, configuración, puesta a punto y los guiones en BASH para la administración general de los servidores y al final que queremos escribir las notas ya no tenemos tiempo.

En esta ocasión voy a escribir este tutorial al tiempo que estoy configurando los servidores, de forma que sea más fácil de seguir todos los pasos y de verificar los errores, bajo riesgo que algunos de ellos no se haya solucionado todavía.

Capistrano es una herramienta para distribución de aplicaciones y su objetivo es automatizar tareas remotas en uno o varios servidores. Capistrano ejecuta tareas de dministración en paralelo en los equipos remotos y permite llevar un control de cambios para recuperar el estado anterior de dichos equipos (bueno, en principio así debe ser). Esta herramienta es ideal para aquellos administradores que tienen a su cargo más de un servidor. Capistrano depende de Ruby, RubyGems, Apache 2.0, MySQL 5.0 y Subversion, y ya que en mi equipo yo tengo instalado Subversion, Apache y MySQL, solo daré los detalles de la instalación de las otras herramientas.

En una sesión de root escriba el comando

# apt-get install ruby rubygems rake 
# apt-get install libopenssl-ruby ruby1.8-dev libmysql-ruby libmysqlclient-dev

para instalar las herramientas y las diversas bibliotecas de las que depende Ruby y RubyGems.

Ahora debe escribir el comando

# gem install capistrano
# gem install rack -v=1.0.1
# gem install rails
# gem install mysql

para que Ruby instale Capistrano y las bibliotecas para comunicación segura sobre la red. Se instalarán seis paquetes que son Net::SSH, Net::SFTP, Net::SCP, Net::SSH::Gateway, HighLine y Capistrano.

El que quiera instalar capistrano de manera manual, puede descargar el código fuente desde el sitio Web de GitHub directamente en el siguiente enlace http://www.github.com/capistrano/capistrano Ahí mismo encontrará las instrucciones para su instalación.

Webistrano

La instalación de Webistrano se realiza manualmente de la siguiente forma:

Descargue el archivo compactado desde la página oficial descargas de Webistrano o puede hacer clic directamente sobre este enlace Webistrano 1.5
Una vez que haya terminado la descarga del achivo, descomprimalo en el directorio donde desee que se guarde
```
# cd /var/opt/ 
# unzip /ruta/a/descargas/webistrano-1.5.zip
```
Configure las tablas para webistrano en la base de datos y cree el usuario webistrano Setup the database tables and create a new webistrano user (obviously be conscious of your security preferences for access to your database in the host and password portions):
```
# mysqladmin -u root -p create webistrano
# mysql -u root -p
Enter password:****
mysql> CREATE USER 'webistrano'@'localhost' IDENTIFIED BY 'password'; 
mysql> GRANT ALL PRIVILEGES ON `webistrano`.* 
       TO 'webistrano'@'localhost' WITH GRANT OPTION;
```
Debe tener cuidado con los apóstrofes y la comilla, note que al asignar los privilegios se han utilizado comillas invertidas para determinar el nombre de la base de datos.
En el directorio donde decompactó Webistrano deberá deberá crear un archivo de configuración funcional. Para ello, entre al directorio de configuración
```
# cd config
```
y copie el archivo de ejemplo con
```
# cp database.yml.sample database.yml
```
y mantenga la versión original para poder iniciar una nueva configuración si algo no sale bien.
Edite este archivo para agregar la información sobre la configuración de la base de datos de MySQL. Esta información debe colocarse en la sección production. De manera predeterminada la aplicación utiliza un socket para nuestro caso vamos a utilizar las variables host: y port: de la siguiente forma
```
production:
  adapter: mysql
  database: webistrano
  username: root
  password: ********
  host: localhost
  port: 3306
```
Copie el archivo de ejemplo de la configuración de webistrano con
```
# cp webistrano_config.rb.sample webistrano_config.rb
```
y agregue la información de las cuentas de correo que recibirán las notificaciones.
Ahora le puede indicar a Rails que desea construir la base de datos que acaba de crear.
```
# RAILS_ENV=production rake db:migrate 
```
Ahora probemos si Webistrano está funcionando debidamente con
```
# ruby script/server -d -e production -p 3000  
```
Deberá tener una página igual a la siguiente

En el siguiente artículo veremos como atender de manera automática la administración general de Capistrano.

Hasta la próxima...

Instegración bajo Apache| Manejo de proyectos en Webistrano