Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.motor.php on line 1013
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.glob.php on line 123
Strict Standards: mktime(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: mktime(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: mktime(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: mktime(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: mktime(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: mktime(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: mktime(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: mktime(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146 Hugo Jiménez - Administración Linux
http://www.hugo-jimenez.fr/categorie4/administracion-linux
esAbstracting time and space Strict Standards: mktime(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146
Strict Standards: date(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d278016625/htdocs/hugo_home/core/lib/class.plx.date.php on line 146 Sat, 27 Sep 2014 23:06:00 +0200PluXmlTrivnet port 8200
http://www.hugo-jimenez.fr/article18/trivnet-port-8200
http://www.hugo-jimenez.fr/article18/trivnet-port-8200<H2 class="title">About the port 8200</h2>
<p>
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...
</p><H2 class="title">About the port 8200</h2>
<p>
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 <i>nmap</i>: TCP/UDP port 8200 -- Service <b>trivnet1</b>.
</p>
<p>
The obvious alternative was looking for the port number into the config files of my server:
<pre>
<b>hugo@lamaitre ~#</b> grep -rn 'port.*8200' /etc/*
/etc/minidlna.conf:2:port=8200
/etc/minidlna.conf.dpkg-dist:2:port=8200
<b>hugo@lamaitre ~#</b>
</pre>
that's all!
</p>
<p>
The TRIVNET protocol is used by <a href="http://minidlna.sourceforge.net/">minidlna</a> 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.
</p>
<br>
<p>
As the home page of the <a href="http://minidlna.sourceforge.net/">ReadyMedia</a> (formerly MiniDLNA)
says: <i>" ... 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. ..." </i>
</p>
<p>
Probably it is more convenient to use something more relevant as information about the <i>trivnet</i> service.
Personally I prefer naming the service as UPnP since
<a href="http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance">DLNA</a> uses
<a href="http://en.wikipedia.org/wiki/Universal_Plug_and_Play">Universal Plug and Play</a>
(UPnP) for media management, discovery and control.
</p>Sat, 27 Sep 2014 23:06:00 +0200Hugo Jiménez-PérezCreación de un proyecto en Mercurial
http://www.hugo-jimenez.fr/article16/creacion-de-un-proyecto-en-mercurial
http://www.hugo-jimenez.fr/article16/creacion-de-un-proyecto-en-mercurial<H2>Pasos básicos para crear un proyecto en Mercurial</H2><p>
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.
</p>
<li>
Primero creamos un directorio, y dentro inicializamos el proyecto
<pre>
# mkdir solsys
# cd solsys
# hg init
</pre>
</li>
<li>
Ahora editamos el archivo <i>.hg/hgrc</i>
y agregamos las líneas
<pre>
# vi .hg/hgrc
[paths]
default = ssh://hg@localhost/hugo/solsys
</pre>
Ahora agregamos algunos archivos y algunos directorios:
<pre>
# 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
</pre>
Y hacemos el commit
<pre>
# hg commit -m "Primer entrega" -u hugo
</pre>
Ahora clonamos la información hacia el servidor
<pre>
# hg clone . ssh://hg@localhost/hugo/solsys
</pre>
Y finalmente enviamos todos los archivos
<pre>
# hg clone . ssh://hg@localhost/hugo/solsys
</pre>
</li>
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
<i>.hgtags</i>
<pre>
# touch .hgtags
# hg tag v0.1 -u hugo
abandon : working copy of .hgtags is changed (please commit .hgtags manually)
</pre>
Y hacemos el commit manual y lo enviamos con <i>push</i>
<pre>
# 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
</pre>
Cuando agregamos una nueva clave ssh o modificamos la nuestra, debemos actualizar con
<pre>
# /usr/share/mercurial-server/refresh-auth
</pre>Fri, 16 May 2014 01:35:00 +0200Hugo Jiménez-PérezTips de administración de TRAC
http://www.hugo-jimenez.fr/article15/tips-de-administracion-de-trac
http://www.hugo-jimenez.fr/article15/tips-de-administracion-de-trac<H2>Algunos tips para los proyectos con TRAC</H2><p>
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.
</p>
<pre>
# trac-admin directorio_del_proyecto initenv
</pre>
ahora debemos proporcionar el nombre del proyecto:
<pre>
Nom du projet [My Project]> La2010 for CUDA
</pre>
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
<pre>
Connection à la base de données [sqlite:db/trac.db]>
</pre>
A continuación hay que agregar los permisos del administrador
<pre>
# trac-admin /var/opt/trac/solsys permission add admin TRAC_ADMIN
</pre>
Despues hacemos un upgrade
<pre>
# trac-admin /var/opt/trac/solsys upgrade
</pre>
Finalmente vamos al directorio (si es que hemos hecho otras cosas) y lanzamos
el comando:
<pre>
# cd /var/opt/trac/
# tracd --port 8000 --auth="musym,musym/.htpass,localdomain" /var/opt/trac/musym/
</pre>
Y modificamos el archivo /var/opt/trac/solsys/config/trac.ini para que se vea de la siguiente manera:
<pre>
# -*- 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<br /><a href="http://trac.edgewall.org/">http://trac.edgewall.org/</a>
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
</pre>
<p>
Probablemente algún día expique el contenido del archivo.
</p>Fri, 16 May 2014 00:29:00 +0200Hugo Jiménez-PérezCUDA 5.5 on Debian Jessie.
http://www.hugo-jimenez.fr/article14/cuda-5-5-on-debian-jessie
http://www.hugo-jimenez.fr/article14/cuda-5-5-on-debian-jessie<h3>How-To get CUDA 5.5 running on Debian Jessie</h3>
<p>
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.
</p><h3>Begin from the beginning:</h3>
<p>
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 <i>nvidia</i> video driver in Debian Jessie (at this point the testing release)
and configuring the CUDA 5.5 SDK for parallel development.
</p>
<p>
Turn off the XServer and delete the free driver <i>nouveau</i>
</p>
<pre>
# apt-get install mercurial mercurial-common
</pre>
<p>
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
</p>
<pre>
# hg --version
</pre>
<p>
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 <a href="http://www.hugo-jimenez.fr/rss/categorie4#">instalación de Apache Web server</a>).
</p>
<p>
Necesitará instalar el módulo <i>libapache2-mod-wsgi</i>
mediante
</p>
<pre>
# apt-get install libapache2-mod-wsgi
</pre>
<p>
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.
</p>
<p>
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
<i>/etc/apache2/sites-available/</i> con el siguiente contenido
</p>
<pre>
<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>
</pre>
<p>
El ejemplo anterior se ha tomado del manual en línea de Mercurial para la instalación de
<a href="http://mercurial.selenic.com/wiki/modwsgi">modwsgi en Mercurial</a>.
</p>
<p>
Ahora vaya al directorio <i>/etc/apache2/sites-enabled</i> y cree un enlace simbólico al archivo anterior
de la forma
</p>
<pre>
# cd /etc/apache2/sites-enabled
# ln -s ../sites-available/mercurial 011-mercurial
</pre>
<p>
o utilice el comando
</p>
<pre>
# a2ensite mercurial
</pre>
<p>
(a2ensite="apache 2 enable site")
</p>
<p>
Cree los directorios donde se colocarán los proyectos y la configuración de mercurial
</p>
<pre>
# mkdir -p /var/www/mercurial/htdocs
# mkdir /var/www/mercurial/cgi-bin
</pre>
<p>
cree el archivo <i>hgwebdir.config</i>
</p>
<h3>SSL en Apache2</h3>
<p>
Instale el paquete que hará la creación de certificados qu es un wrapper para openssl
</p>
<pre>
# apt-get install ssl-cert
</pre>
<p>
Habilite el modulo de SSL para que funcione con apache
</p>
<pre>
# a2enmod ssl
</pre>
<p>
(a2enmod=apache2 enable module)
</p>
<p>
Configure openssl
</p>
<pre>
# vi /etc/ssl/openssl.cnf
</pre>
<p>
Si desea tener un certificado para un servidor de prueba... puede utilizar directamente
el comando
</p>
<pre>
# mkdir /etc/apache2/ssl
# cd /etc/apache2/ssl
# make-ssl-cert /usr/share/ssl-cert/ssleay.cnf localcerts
</pre>
<p>
La clave y el certificado se encuentran es el mismo archivo. Ahora separe en dos archivos
que llamaremos <i>site.key</i> y <i>site.pem</i> y los colocamos en el mismo directorio con permisos 400 y 600
respectivamente.
</p>
<pre>
# chmod 600 site.pem
# chmod 400 site.key
</pre>
<p>
Creemos el archivo de contraseñas que se utilizará para acceder al depósito de mercurial
</p>
<pre>
# mkdir /etc/apache2/htpasswd<br />
# htpasswd -cm /etc/apache2/htpasswd/ht.passwd hugo
</pre>
<p>
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
<i>SSLCertificateFile</i> y <i>SSLCertificateKeyFile</i> respectivamente.
Cree el archivo <i>/etc/apache2/sites-available/mercurial-ssl</i> con el siguiente contenido
</p>
<pre>
<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>
</pre>
<p>
Active el sitio <i>https://hg1.ejemplo.com</i> que tiene configurado en el archivo <i>mercurial-ssl</i>
y reinicie el servidor. Si todo marcha bien, tendrá su sitio Web seguro con soporte bajo SSL
</p>
<pre>
# a2ensite mercurial-ssl
# /etc/init.d/apache2 restart
</pre>
<p>
Para probar que su sitio Web seguro está funcionando ejecute el comando
</p>
<pre>
# curl -k https://hg1.ejemplo.com
</pre>
<p>
La opción <i>-k</i> le indica al comando <i>curl</i> 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.
</p>
<p>
Ahora podrá conectarse a su sitio web seguro en la dirección
<i>https://hg1.ejemplo.com</i> 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 <a href="http://www.digicert.com/ssl-certificate-installation-apache.htm">DigiCert</a> ) que comercializan este tipo de certificados y usted
sólo deberá ejecutar las tareas de copia y asignación de permisos en el directorio
<i>/etc/apache2/ssl</i>, los demás pasos son equivalentes.
</p>
<p>
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 <a href="http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html">Apache y OpenSSL</a> directamente.
</p>Sat, 03 Aug 2013 13:04:00 +0200Hugo Jiménez-PérezInstalación de Mercurial
http://www.hugo-jimenez.fr/article13/instalacion-de-mercurial
http://www.hugo-jimenez.fr/article13/instalacion-de-mercurial<h3>Instalación de Mercurial sobre Apache con autenticación SSL</h3>
<p>
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.</p><h3>Instalación de Mercurial:</h3>
<p>
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:
</p>
<p>
Para instalar el servidor de Mercurial en Debian, sólo se requiere utilizar el comando
</p>
<pre>
# apt-get install mercurial mercurial-common
</pre>
<p>
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
</p>
<pre>
# hg --version
</pre>
<p>
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 <a href="http://www.hugo-jimenez.fr/rss/categorie4#">instalación de Apache Web server</a>).
</p>
<p>
Necesitará instalar el módulo <i>libapache2-mod-wsgi</i>
mediante
</p>
<pre>
# apt-get install libapache2-mod-wsgi
</pre>
<p>
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.
</p>
<p>
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
<i>/etc/apache2/sites-available/</i> con el siguiente contenido
</p>
<pre>
<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>
</pre>
<p>
El ejemplo anterior se ha tomado del manual en línea de Mercurial para la instalación de
<a href="http://mercurial.selenic.com/wiki/modwsgi">modwsgi en Mercurial</a>.
</p>
<p>
Ahora vaya al directorio <i>/etc/apache2/sites-enabled</i> y cree un enlace simbólico al archivo anterior
de la forma
</p>
<pre>
# cd /etc/apache2/sites-enabled
# ln -s ../sites-available/mercurial 011-mercurial
</pre>
<p>
o utilice el comando
</p>
<pre>
# a2ensite mercurial
</pre>
<p>
(a2ensite="apache 2 enable site")
</p>
<p>
Cree los directorios donde se colocarán los proyectos y la configuración de mercurial
</p>
<pre>
# mkdir -p /var/www/mercurial/htdocs
# mkdir /var/www/mercurial/cgi-bin
</pre>
<p>
cree el archivo <i>hgwebdir.config</i>
</p>
<h3>SSL en Apache2</h3>
<p>
Instale el paquete que hará la creación de certificados qu es un wrapper para openssl
</p>
<pre>
# apt-get install ssl-cert
</pre>
<p>
Habilite el modulo de SSL para que funcione con apache
</p>
<pre>
# a2enmod ssl
</pre>
<p>
(a2enmod=apache2 enable module)
</p>
<p>
Configure openssl
</p>
<pre>
# vi /etc/ssl/openssl.cnf
</pre>
<p>
Si desea tener un certificado para un servidor de prueba... puede utilizar directamente
el comando
</p>
<pre>
# mkdir /etc/apache2/ssl
# cd /etc/apache2/ssl
# make-ssl-cert /usr/share/ssl-cert/ssleay.cnf localcerts
</pre>
<p>
La clave y el certificado se encuentran es el mismo archivo. Ahora separe en dos archivos
que llamaremos <i>site.key</i> y <i>site.pem</i> y los colocamos en el mismo directorio con permisos 400 y 600
respectivamente.
</p>
<pre>
# chmod 600 site.pem
# chmod 400 site.key
</pre>
<p>
Creemos el archivo de contraseñas que se utilizará para acceder al depósito de mercurial
</p>
<pre>
# mkdir /etc/apache2/htpasswd<br />
# htpasswd -cm /etc/apache2/htpasswd/ht.passwd hugo
</pre>
<p>
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
<i>SSLCertificateFile</i> y <i>SSLCertificateKeyFile</i> respectivamente.
Cree el archivo <i>/etc/apache2/sites-available/mercurial-ssl</i> con el siguiente contenido
</p>
<pre>
<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>
</pre>
<p>
Active el sitio <i>https://hg1.ejemplo.com</i> que tiene configurado en el archivo <i>mercurial-ssl</i>
y reinicie el servidor. Si todo marcha bien, tendrá su sitio Web seguro con soporte bajo SSL
</p>
<pre>
# a2ensite mercurial-ssl
# /etc/init.d/apache2 restart
</pre>
<p>
Para probar que su sitio Web seguro está funcionando ejecute el comando
</p>
<pre>
# curl -k https://hg1.ejemplo.com
</pre>
<p>
La opción <i>-k</i> le indica al comando <i>curl</i> 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.
</p>
<p>
Ahora podrá conectarse a su sitio web seguro en la dirección
<i>https://hg1.ejemplo.com</i> 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 <a href="http://www.digicert.com/ssl-certificate-installation-apache.htm">DigiCert</a> ) que comercializan este tipo de certificados y usted
sólo deberá ejecutar las tareas de copia y asignación de permisos en el directorio
<i>/etc/apache2/ssl</i>, los demás pasos son equivalentes.
</p>
<p>
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 <a href="http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html">Apache y OpenSSL</a> directamente.
</p>Mon, 26 Apr 2010 01:50:00 +0200Hugo Jiménez-PérezManejo de proyectos en Webistrano
http://www.hugo-jimenez.fr/article11/manejo-de-proyectos-en-webistrano
http://www.hugo-jimenez.fr/article11/manejo-de-proyectos-en-webistrano<h3>Creación de proyectos en Webistrano</h3>
<p>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.</p><br />
<p>
<a href="http://www.hugo-jimenez.fr/?article10/instalando-webistrano">Instalación de Capistrano-Webistrano</a>|
<a href="http://www.hugo-jimenez.fr/?article9/instalando-webistrano">Instegración bajo Apache</a>
</p>
<h3>Distribuyendo una aplicación no Rails</h3>
<h3>Ahora la parte divertida.</h3>
<p>
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.
</p>
<p>
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.<br />
</p>
<p>
Las distribuciones en Capistrano se colocan en un subdirectorio dentro del directorio <i>release</i>
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 (<i>simlink</i> que lleva el nombre predeterminado
de <i>current</i> y puede modificarse mediante la variable de configuración
<i>current_path</i>). Este enlace es el que debe considerarse en la configuración del
servidor de Apache (de hecho debe ser el valor de <i>DocumentRoot</i>).<br />
</p>
<p>
Capistrano también crea un directorio compartido cuyo nombre es <i>shared</i> 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.<br />
</p>
<p>
Para aplicaciones que no sean de tipo <i>Rails</i> usted deberá utilizar el tipo de proyecto <i>Pure File</i>
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 <i>:export</i> en lugar de <i>:checkout</i>
para la instrucciốn <i>deploy_via</i> para las distribuciones de producción de la aplicación <i>subversion</i>;
de esta forma no se expondrán los directorios <i>.svn</i>. 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 <i>user_sudo</i>
en <i>true</i> y cree una variable de configuración <i>runner admin_runner:admin_runner</i> en el archivo
<i>/etc/sudoers</i>.<br />
</p>
<p>
Agregue una etapa para producción a su proyecto mediante <i>production</i>. En la página <i>Manage Hosts</i>
agregue un equipo por cada servidor donde se instalará la applicación. Después agregue cada equipo
como un objetivo <i>target</i> para la etapa <i>production</i> de su proyecto.<br />
</p>
<p>
En este punto puede ejecutar la tarea <i>Setup</i> para la etapa <i>production</i>. Esta es una
tarea que se ejecuta sólo una vez y simplemente crea los subdirectorios.<br />
</p>
<p>
Asumamos que todo salió bien, intente entonces una distribución con <i>Deploy</i> y vea si finaliza son errores.
Deberá tener cuidado de asignar los permisos adecuados a los directorios. <br />
</p>
<p>
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 <i>Manage
Recipes</i> en Webistrano. Las recetas son simplemente procedimientos escritos en Ruby.
A continuación verá el código de estas recetas:
</p>
<pre>
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
</pre>
<p>
Si aún no está familiarizado con Ruby, le diré que este código esencialmente sobrescribe dos tareas en el
espacio de nombres <i>:deploy</i>.<br />
</p>
<p>
El primer
<i>:setup</i> simplemente duplica la funcionalidad de base discutida anteriormente
(crear las liberaciones y los directorios compartidos) y cambia los permisos de
acceso a dichos directorios.
</p>
<p>
La segunda tarea
<i>:finalize_update</i>, 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.
</p>
<p>
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.
<h3>Distribuyendo aplicaciones Django</h3>
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:
<div class="command" style="margin:8pt; color:yellow; background: #000000;padding:5pt;">
1 import os<br />
2 import sys<br />
3 <br />
4 appdir = os.path.normpath(os.path.join(os.path.realpath(os.path.dirname(__file__)), '..'))<br />
5 sys.path.insert(0, appdir)<br />
6 os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'<br />
7 os.environ['PYTHON_EGG_CACHE'] = os.path.join(appdir, '.python-eggs')<br />
8 import django.core.handlers.wsgi<br />
9 application = django.core.handlers.wsgi.WSGIHandler()<br />
</div>
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:
<div class="command" style="margin:8pt; color:yellow; background: #000000;padding:5pt;">
.python-eggs (egg cache)<br />
apps (apps path is added to python system path in settings.py)<br />
public (where your .wsgi script resides)<br />
site_media<br />
templates<br />
settings.py<br />
settings-production.py (used for deploy)<br />
urls.py<br />
...
</div>
Si sigue esta convención, la siguiente receta de Capistrano trabaja muy bien:
<div class="command" style="margin:8pt; color:yellow; background: #000000;padding:5pt;">
01 namespace :deploy do<br />
02 task :setup, :except => { :no_release => true } do<br />
03 dirs = [deploy_to, releases_path, shared_path]<br />
04 dirs += shared_children.map { |d| File.join(shared_path, d) }<br />
05 run "#{try_sudo} mkdir -p #{dirs.join(' ')} && #{try_sudo} chmod g+w #{dirs.join(' ')}"<br />
06 run "chmod 777 #{shared_path}/log"<br />
07 end<br />
08 <br />
09 task :finalize_update, :except => { :no_release => true } do<br />
10 run "rm -rf #{latest_release}/logs"<br />
11 run "ln -s #{shared_path}/log #{latest_release}/logs"<br />
12 run "cp #{latest_release}/settings-production.py #{latest_release}/settings.py"<br />
13 run "mkdir -p #{latest_release}/.python-eggs"<br />
14 run "chmod 777 #{latest_release}/.python-eggs"<br />
15 end<br />
16 end
</div>
<p>
<a href="http://www.hugo-jimenez.fr/?article10/instalando-webistrano">Instalación de Capistrano-Webistrano</a>|
<a href="http://www.hugo-jimenez.fr/?article9/instalando-webistrano">Instegración bajo Apache</a>
</p>Wed, 21 Apr 2010 01:07:00 +0200Hugo Jiménez-PérezInstalando Webistrano 1.5 en Debian Squeeze II.
http://www.hugo-jimenez.fr/article9/instalando-webistrano
http://www.hugo-jimenez.fr/article9/instalando-webistrano<h3>Continuación de la instalación de Webistrano.</h3>
En este artículo configurará Webistrano para que se ejecute
como un servidor virtual dentro de apache. El módulo <i>passenger</i>
de apache permite esta integración.<p>
<a href="http://www.hugo-jimenez.fr/?article10/instalando-webistrano">Instalación de Capistrano-Webistrano</a>|
<a href="http://www.hugo-jimenez.fr/?article11/manejo-de-proyectos-en-webistrano">Manejo de proyectos en Webistrano</a>
</p>
<h3>Phusion Passenger</h3>
<p>
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:
</p>
<pre>
# apt-get install libapache2-mod-passenger
</pre>
<p>
Si usted está usando otra versió de Linux diferente a Debian, el
proceso de installación es completamente distinto. Revise el sitio de
<a href="http://www.modrails.com/install.html">ModRails</a> para obtener información
sobre el proceso de instalasión y configuración en otras distribuciones de Linux.
</p>
<p>
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
<i>/etc/apache2/mods-available/passenger.conf</i> para que contenga los valores correctos de su
configuración. Debe verse de la siguiente manera
</p>
<pre>
<IfModule mod_passenger.c>
PassengerRoot /usr/lib/ruby/1.8/phusion_passenger
PassengerRuby /usr/bin/ruby
</IfModule>
</pre>
<p>
La variable PassengerRoot tiene el valor predeterminado de <i>/usr</i> así que este
cambio siempre será necesario.
</p>
<p>
Ahora, cree un archivo llamado <i>webistrano</i> en el directorio <i>/etc/apache2/sites-available/</i>
y agregue la siguiente información
</p>
<pre>
<VirtualHost *:80>
ServerName webistrano.ejemplo.com
DocumentRoot /var/opt/webistrano/public
</VirtualHost>
</pre>
<p>
Guarde el archivo y cree un enlace simbólico en el directorio <i>/etc/apache2/sites-enabled</i>
con el comando
</p>
<pre>
# cd /etc/apache2/sites-enabled/
# ln -s ../sites-available/webistrano webistrano
</pre>
<p>
Reinicie Apache para que el servidor cargue la nueva configuración
</p>
<pre>
# /etc/init.d/apache2 restart
</pre>
<p>
y verifique que el servidor de bases de datos esté funcionando.
</p>
<p>
Ahora puede abrir su navegador Web y escribir <i>http://webistrano.ejemplo.com</i>,
obtendrá una pantalla como la siguiente:
</p>
<div style="padding: 10pt; float:left;">
<a href="http://www.hugo-jimenez.fr/data/images/webistrano.ex-login.png"><img src="http://www.hugo-jimenez.fr/data/images/webistrano.ex-login.png.tb" alt="Webistrano" /></a>
</div>
<br />
<p>
Vea que en la barra de direcciones del navegador, aparece la URL como
<i>http://webistrano.ejemplo.com/sessions/new</i> a diferencia de la dirección del
artículo anterior que era <i>http://webistrano.localhost/sessions/new</i>. La imagen
NO está editada, es la original (y probablemente tenga el nombre en inglés
porque eran mis pruebas).
</p>
<p>
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 <i>/etc/hosts</i> mediante el comando
</p>
<pre>
# echo "127.0.0.1 webistrano.ejemplo.com" >> /etc/hosts
</pre>
<p>
En un entorno de producción, deberá hacer una copia de respaldo del
archivo <i>/etc/hosts</i>, editar el original para agregar
</p>
<pre>
127.0.0.1 webistrano.ejemplo.com
</pre>
<p>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.
</p>
<p>
Ahora simplemente debe agregar entradas <i>VirtualHost</i> a su archivo
<i>/etc/apache2/sites-availables/webistrano</i> para cada una de sus aplicaciones Rails.
Agregue las directivas de configuración que mejor se adapten
a su sistema.
</p>
Hasta la próxima...
<p>
<a href="http://www.hugo-jimenez.fr/?article10/instalando-webistrano">Instalación de Capistrano-Webistrano</a>|
<a href="http://www.hugo-jimenez.fr/?article11/manejo-de-proyectos-en-webistrano">Manejo de proyectos en Webistrano</a>
</p>Tue, 20 Apr 2010 17:53:00 +0200Hugo Jiménez-PérezInstalando Webistrano 1.5 en Debian Squeeze I.
http://www.hugo-jimenez.fr/article10/instalando-webistrano
http://www.hugo-jimenez.fr/article10/instalando-webistrano<h3>Un pequeño tutorial de instalación de Webistrano.</h3>
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.<p>
<a href="http://www.hugo-jimenez.fr/?article9/instalando-webistrano">Instegración bajo Apache</a>|
<a href="http://www.hugo-jimenez.fr/?article11/manejo-de-proyectos-en-webistrano">Manejo de proyectos en Webistrano</a>
</p>
<p>Hola a todos!</p>
<p>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.</p>
<p>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.</p>
<p>
<a href="http://www.capify.org/">Capistrano</a> 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 <a href="http://www.ruby-lang.org/es/">Ruby</a>,
<a href="http://rubyforge.org/projects/rubygems/">RubyGems</a>,
<a href="http://www.apache.org">Apache 2.0</a>,
<a href="http://www.mysql.com">MySQL 5.0</a> y
<a href="http://subversion.tigris.org/">Subversion</a>, 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.
</p>
<p>
En una sesión de <i>root</i> escriba el comando
</p>
<pre>
# apt-get install ruby rubygems rake
# apt-get install libopenssl-ruby ruby1.8-dev libmysql-ruby libmysqlclient-dev
</pre>
<p>
para instalar las herramientas y las diversas bibliotecas de las que depende Ruby y RubyGems.
</p>
<p>
Ahora debe escribir el comando
</p>
<pre>
# gem install capistrano
# gem install rack -v=1.0.1
# gem install rails
# gem install mysql
</pre>
<p>
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.
</p>
<p>
El que quiera instalar capistrano de manera manual, puede descargar el código fuente
desde el sitio Web de <a href="http://www.github.org">GitHub</a> directamente en el siguiente enlace
<a href="http://www.github.com/capistrano/capistrano">http://www.github.com/capistrano/capistrano</a>
Ahí mismo encontrará las instrucciones para su instalación.
</p>
<p>
</p>
<h3>Webistrano</h3>
La instalación de Webistrano se realiza manualmente de la siguiente
forma:<br />
<ul>
<li>Descargue el archivo compactado desde la página oficial
<a href="http://wiki.github.com/peritor/webistrano/download">descargas de Webistrano</a>
o puede hacer clic directamente sobre este enlace
<a href="http://github.com/downloads/peritor/webistrano/webistrano-1.5.zip">Webistrano 1.5</a>
</li>
<li>
Una vez que haya terminado la descarga del achivo, descomprimalo en el directorio donde desee que
se guarde
<pre>
# cd /var/opt/
# unzip /ruta/a/descargas/webistrano-1.5.zip
</pre>
</li>
<li>
Configure las tablas para webistrano en la base de datos y
cree el usuario <i>webistrano</i>
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):
<pre>
# 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;
</pre>
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.
</li>
<li>
En el directorio donde decompactó Webistrano deberá deberá
crear un archivo de configuración funcional. Para ello, entre al directorio de
configuración
<pre>
# cd config
</pre>
y copie el archivo de ejemplo con
<pre>
# cp database.yml.sample database.yml
</pre>
y mantenga la versión original para poder iniciar una nueva configuración
si algo no sale bien.
<br />
</li>
<li>
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
<i>production</i>. De manera predeterminada la aplicación utiliza un <i>socket</i>
para nuestro caso vamos a utilizar las variables host: y port: de la siguiente forma
<pre>
production:
adapter: mysql
database: webistrano
username: root
password: ********
host: localhost
port: 3306
</pre>
</li>
<li>
Copie el archivo de ejemplo de la configuración de webistrano con
<pre>
# cp webistrano_config.rb.sample webistrano_config.rb
</pre>
y agregue la información de las cuentas de correo que recibirán las
notificaciones.
</li>
<li>
Ahora le puede indicar a Rails que desea construir la base de datos que acaba de crear.
<pre>
# RAILS_ENV=production rake db:migrate
</pre>
</li>
<li>
Ahora probemos si Webistrano está funcionando debidamente con
<pre>
# ruby script/server -d -e production -p 3000
</pre>
Deberá tener una página igual a la siguiente<br />
<a href="http://www.hugo-jimenez.fr/data/images/webistrano-login.png"><img src="http://www.hugo-jimenez.fr/data/images/webistrano-login.png.tb" alt="" />
</a>
</li>
</ul>
<p>En el siguiente artículo veremos como atender de manera automática la administración
general de Capistrano.
</p>
Hasta la próxima...
<p>
<a href="http://www.hugo-jimenez.fr/?article9/instalando-webistrano">Instegración bajo Apache</a>|
<a href="http://www.hugo-jimenez.fr/?article11/manejo-de-proyectos-en-webistrano">Manejo de proyectos en Webistrano</a>
</p>Mon, 19 Apr 2010 17:53:00 +0200Hugo Jiménez-Pérez