Entries for Apache2

Cuando tenemos un sitio en construcción, en el cuál sólo tenemos una pantalla de presentación, puede interesarnos que todas las peticiones redirijan a la página principal.

Para ello podemos utilizar mod_rewrite, el cuál ya se ha comentado antes en este blog. En principio se puede pensar que bastaría con:

RewriteEngine on
RewriteRule ^/(.+)$ / [R=302,L]

Con esto estamos indicando a Apache2 que cualquier cosa que no sea la raíz, ^/(.+)$, debe ser redirigido a , /, usando el código de redirección 302. El problema es que si enlazamos con algún estático: css, javascript, imágenes, ..., también será redirigido a la raíz.

Este comportamiento no nos interesa, así que vamos a añadir una condición. Suponiendo que todos nuestros estáticos están en /static/, bastará con añadir lo siguiente:

RewriteEngine on
RewriteCond %{REQUEST_URI} !^/static/
RewriteRule ^/(.+)$ / [R=302,L]

La idea es bastante sencilla. Disponemos de un sitio web en el que vamos a añadir MediaWiki en /wiki/. Así, por ejemplo, si nuestro dominio es http://www.plagaos.com/, en el cuál hay un proyecto Django en despliegue, vamos a tener http://www.plagaos.com/wiki/ sin que afecte al sitio. Además, MediaWiki hará uso de PostgreSQL.

Este es un tema que tenía un poco descuidado (muy mal por mi parte) y que ahora acabo de solucionarlo. logrotate permite configurar de una forma sencilla cómo, cuándo y dónde queremos hacer la rotación de los logs. Esta utilidad se suele ser usada por bastante software, como: apache2, apt, aptitude, dpkg, mysql-server, postgresql-common ó rsyslog.

En este caso, voy a explicar brevemente como podemos utilizar logrotate para los logs de nuestros sitios web. Aunque bien es cierto que existe una configuración para los logs generales de Apache, yo utilizo logs independientes para cada sitio que tengo desplegado, por lo que habrá que rotar de forma independiente cada uno de ellos.

Inicialmente, el despliegue para PlagaOS lo realicé en un subdominio de MenudoProblema (palgaos.menudoproblema.es). A los pocos días decidí comprar un nombre de dominio, por lo que ahora quiero redirigir todo el tráfico de http://plagaos.menudoproblema.es hacia http://www.plagaos.com.

Últimamente tengo aún menos tiempo, ya que estoy aprovechando PlagaOS para actualizar los módulos de MenudoProblema y crear algunos módulos que incorporaré más adelante. Pero aquí os dejo un pequeño problema:tras explorar la limitaciones de Django FlatPages decidí hacerme mi propio módulo de páginas estáticas. Lo desarrollé, lo incluí en la página del proyecto, hice el despliegue y como no, acabé haciendo un cambio en el modelo.

Continuando con la serie de artículos de la migración, ahora toca uno de como instalar Piwik. Hasta el momento Piwik es la única alternativa en su categoría y ésta es la única razón por lo que lo estoy utilizando. Otro día detallaré más en profundidad.

Django ofrece un panel de administración de forma automática. Voy a explicar brevemente como podemos forzar que todo lo que se realice a través del panel de administración vaya a través de una conexión segura: SSL.

Para ello vamos a hacer uso del módulo rewrite que ofrece Apache. Este módulo nos permite reescribir las peticiones antes de que se procesen. Esto se suele utilizar mucho en PHP para que la URI sea más bonita, cosa que en Django no es necesario.

Llevo un par de días investigando el tema de Certificados Digitales, SSL y HTTPS. Aprovechando que tengo que hacer un trabajo acerca de las Autoridades de Certificación (CA) y los Certificados Digitales estoy añadiendo un certificado para el blog. Y como no, ¡menudo problema!

$ sudo service apache2 restart
 * Restarting web server apache2
Syntax error on line 10 of /etc/apache2/sites-enabled/ssl:
Invalid command 'SSLEngine', perhaps misspelled or defined by a module not included in the server configuration
[fail]

Aprovechando el lanzamiento de TinyMCE 3.3.3 y que voy a actualizarlo en el servidor, voy a explicar como podemos configurar Django para que todo funcione bien. Para hacer uso de TinyMCE utilizo una aplicación de Django que está en los repositorios de Ubuntu, el cual instala como dependencia a TinyMCE. La aplicación en cuestion está en el paquete python-django-tinymce.

Actualmente este sitio está alojado en un servidor virtual que ofrece SliceHost. Por temas económicos, tengo contratado lo mínimo: 256 slice, que sólo me ofrece 256 MB de Ram. Y aquí es donde entra en juego Apache.

Llevo ya un tiempo trabajando en algunos proyectos con Django y Bazaar. Últimamente ha tocado dar el salto a producción (este blog es fruto de ello) y me he encontrado con algunos problemas de despliegue. Entre ellos cuando el proyecto está ubicado en un directorio diferente al que contiene a settings.py

Una vez desarrollado y testeado un sitio web, toca el despliegue en un servidor de producción. Desplegando uno de mis proyectos me encontré con que la administración que provee Django (Admin Sites) no cargaba ni CSS ni imágenes. Después de buscar un poco por la red he llegado a la siguiente solución (a mi parecer la más cómoda).