Configuración de un servidor local debian para joomla by Aula cero

INSTITUTO DE EDUCACIÓN SECUNDARIA I.E.S. CONSELLERIA - FAMILIA PROFESIONAL DE INFORMATICA Y COMUNICACIONES

Configuración de un servidor local Debian para Joomla y creacción de una pagina web.

PROYECTO DE ADMINISTRACIÓN DE SISTEMAS EN RED NÚMER AINF3/13

Javier Lleó Tomás Ivan Matalí

Índice de contenido La Web 1.0 ................................................................................................................................. 2 Características: .................................................................................................................. 2 Historia: ............................................................................................................................ 3 La Web 2.0 ................................................................................................................................. 4 Características: .................................................................................................................. 5 Software de servidor ......................................................................................................... 6 Lenguajes de programación en la Web 2.0.................................................................................. 8 PHP ................................................................................................................................... 8 SQL ................................................................................................................................... 8 HTML ............................................................................................................................... 8 XHTML ............................................................................................................................ 9 XML ................................................................................................................................. 9 CSS ................................................................................................................................. 10 AJAX .............................................................................................................................. 10 JavaScript ........................................................................................................................ 11 Introducción a Joomla .................................................................................................... 11 Conclusiones sobre la historia de la Web y los Lenguajes de Programación..................12 Por que no a XAMPP................................................................................................................ 13 Instalación de VirtualBox.......................................................................................................... 14 Instalación en Sistemas Microsoft...................................................................................14 Instalación en Sistemas Linux.......................................................................................... 18 Creación de la maquina Virtual en Virtual Box...............................................................19 Instalación de Debian 6.0 Squeeze en la maquina virtual..........................................................23 Notas finales del modo NAT...........................................................................................36 Instalación de openssh implementado en Debian 6.0 Squeeze en la maquina virtual................37 Instalación de las Guest Additions en la maquina virtual..........................................................40 Instalación de Apache 2 en la maquina virtual Debian 6.0 Squeeze..........................................43 La NO configuración de un VirtualHost para Joomla......................................................44 Configuración del modulo de Apache para SSL..............................................................45 Monitorización del uso de recursos de Apache2..............................................................51 La directiva RewriteEngine y el mod_rewrite.................................................................52 El archivo .htaccess (y por que no vamos a usarlo).........................................................54 El modulo mod_deflate.................................................................................................... 62 El modulo mod_cache...................................................................................................... 67 El modulo mod_security.................................................................................................. 71 El modulo mod_pagespeed.............................................................................................. 75 Instalación de PHP5......................................................................................................... 80 Las opciones y directivas Options, Indexes y FollowSymLinks......................................81 Los logs de Apache2 ....................................................................................................... 83 Instalación de Proftpd con SSL................................................................................................. 91 Configuración de Filezilla como cliente de FTP..............................................................96 Instalación de Mysql y Phpmyadmin....................................................................................... 100 Instalación de phpmyadmin.......................................................................................... 103 Joomla 2.5 ............................................................................................................................... 104 ¿Que es un CMS?........................................................................................................... 104 Descarga e instalación de Joomla 2.5............................................................................106 Instalar la Maquina Virtual...................................................................................................... 115

La Web 1.0 La Web 1.0 (1991-2003) es la forma más básica que existe, con navegadores de sólo texto bastante rápidos. Después surgió el HTML que hizo las páginas web más agradables a la vista, así como los primeros navegadores visuales tales como IE, Netscape, Explorer (en versiones antiguas), etc. La Web 1.0 es de sólo lectura. El usuario no puede interactuar con el contenido de la página (nada de comentarios, respuestas, citas, etc), estando totalmente limitado a lo que el Webmaster sube a ésta. Web 1.0 se refiere a un estado de la World Wide Web, y cualquier página web diseñada con un estilo anterior del fenómeno de la Web 2.0. Es en general un término que ha sido creado para describir la Web antes del impacto de la fiebre punto com en el 2001, que es visto por muchos como el momento en que el internet dio un giro.

Características: Algunos elementos de diseño típicos de un sitio Web 1.0 incluyen:  Páginas estáticas en vez de dinámicas por el usuario que la visita.  El uso de framesets o Marcos.  Extensiones propias del HTML como <bilnk> y <marquee>, etiquetas introducidas durante la guerra de navegadores web.  Libros de visitas online o guestbooks.  Botones GIF, casi siempre a una resolución típica de 88x31 pixels en tamaño promocionando navegadores web u otros productos.  Formularios HTML enviados vía email. Un usuario llenaba un formulario y después de hacer clic se enviaba a través de un cliente de correo electrónico, con el problema que en el código se podía observar los detalles del envío del correo electrónico.  No se podían adherir comentarios ni nada parecido.  Todas sus páginas se creaban de forma fija y muy pocas veces se actualizaban.

Historia: La World Wide Web comenzó con la introducción de Mosaic en 1993, un navegador web con interfaz gráfica desarrollado por un equipo en la Universidad de Illinois. Los fondos para Mosaic vinieron desde la High-Performance Computing and Communications Initiative, el programa de ayudas iniciado en 1991 por el entonces senador Al Gore. De hecho, la interfaz gráfica de Mosaic pronto se hizo más popular que el navegador Gopher, que en ese momento estaba principalmente basado en texto, y la WWW se convirtió en la interfaz preferida para acceder a Internet. Mosaic fue finalmente suplantado en 1994 por Netscape Navigator, que reemplazó a Mosaic como el navegador web más popular en el mundo. La competencia de Internet Explorer y una variedad de otros navegadores casi lo ha sustituido completamente. Incluso antes de la World Wide Web, hubo buscadores que intentaron organizar Internet. El primero de estos fue Archie de la Universidad McGill en 1990, seguido en 1991 por WAIS y Gopher. Los tres sistemas fueron anteriores a la invención de la World Wide Web pero todos continuaron indexando la Web y el resto de Internet durante varios años después de que apareciera la Web. A medida que la Web creció, se crearon los buscadores y los directorios web para localizar las páginas en la Web y permitir a las personas encontrar cosas. El primer buscador web completamente de texto fue WebCrawler en 1994. Antes de WebCrawler, sólo se podían buscar títulos de páginas web. Otro de los primeros buscadores, Lycos, fue creado en 1993 como un proyecto universitario, y fue el primero en conseguir éxito comercial. Durante los últimos años de 1990, tanto los directorios web como los buscadores web eran populares. Yahoo! (fundado en 1995) y AltaVista (fundado en 1995) fueron los respectivos líderes de la industria. Por agosto de 2001, el modelo de directorios había comenzado a ceder ante el de buscadores, mostrando el surgimiento de Google (fundado en 1998), que había desarrollado nuevos enfoques para el ordenamiento por relevancia. El modelo de directorios, aunque aún está disponible comúnmente, es menos utilizado que los buscadores. El ordenamiento por relevancia se convirtió por primera vez en una cuestión importante alrededor de 1996, cuando se hizo evidente que no era práctico revisar listas completas de resultados. Por consiguiente, los algoritmos para el ordenamiento por relevancia se han ido mejorando continuamente. El método PageRank de Google para ordenar los resultados ha sido bien recibido por la mayoría de la prensa, pero todos los principales buscadores refinan continuamente sus metodologías de ordenamiento con el objetivo de mejorar el orden de los resultados.

La Web 2.0 El término Web 2.0 comprende aquellos sitios web que facilitan el compartir información, la interoperabilidad, el diseño centrado en el usuario y la colaboración en la World Wide Web. Un sitio Web 2.0 permite a los usuarios interactuar y colaborar entre sí como creadores de contenido generado por usuarios en una comunidad virtual, a diferencia de sitios web estáticos donde los usuarios se limitan a la observación pasiva de los contenidos que se han creado para ellos. Ejemplos de la Web 2.0 son las comunidades web, los servicios web, las aplicaciones Web, los servicios de red social, los servicios de alojamiento de videos, las wikis, blogs, mashups y folcsonomías. El término Web 2.0 está asociado estrechamente con Tim O'Reilly, debido a la conferencia sobre la Web 2.0 de O'Reilly Media en 2004. Aunque el término sugiere una nueva versión de la World Wide Web, no se refiere a una actualización de las especificaciones técnicas de la web, sino más bien a cambios acumulativos en la forma en la que desarrolladores de software y usuarios finales utilizan la Web. El hecho de que la Web 2.0 es cualitativamente diferente de las tecnologías web anteriores ha sido cuestionado por el creador de la World Wide Web Tim Berners-Lee, quien calificó al término como "tan sólo una jerga" precisamente porque tenía la intención de que la Web incorporase estos valores en el primer lugar. Antes de la llegada de las tecnologías de la Web 2.0 se utilizaban páginas estáticas programadas en HTML que no eran actualizadas frecuentemente. El éxito de las .com dependía de webs más dinámicas (a veces llamadas Web 1.5) donde los sistemas de gestión de contenidos servían páginas HTML dinámicas creadas al vuelo desde una base de datos actualizada. En ambos sentidos, el conseguir hits (visitas) y la estética visual eran considerados como factores. Los teóricos de la aproximación a la Web 2.0 piensan que el uso de la web está orientado a la interacción y redes sociales, que pueden servir contenido que explota los efectos de las redes, creando o no webs interactivas y visuales. Es decir, los sitios Web 2.0 actúan más como puntos de encuentro o webs dependientes de usuarios más que como webs tradicionales.

Características: Se puede decir que una web está construida usando tecnología de la Web 2.0 si posee las siguientes características:  CSS, marcado XHTML válido semánticamente y Microformatos .  Técnicas de aplicaciones ricas no intrusivas (como AJAX).  Java Web Start.  Redifusión/Agregación de datos en RSS/ATOM.  URLs sencillas con significado semántico.  Soporte para postear en un blog.  Lenguajes JCC y APIs REST o XML.  Lenguaje JSON.  Algunos aspectos de redes sociales.  Mashup (aplicación web híbrida).  El sitio debe estar listo para la entrada de cualquier persona.  El sitio no debe actuar como un "jardín sin cosechar inminentemente": la información debe poderse introducir y extraer fácilmente.  Los usuarios deberían controlar su propia información.  Basada exclusivamente en la Web: los sitios Web 2.0 con más éxito pueden ser utilizados enteramente desde un navegador.  La existencia de links es requisito imprescindible. En general, cuando mencionamos el término Web 2.0 nos referimos a una serie de aplicaciones y páginas de Internet que utilizan la inteligencia colectiva para proporcionar servicios interactivos en red. Para compartir en la Web 2.0 se utilizan una serie de herramientas, entre las que se pueden destacar: Blogs: Un blog es un espacio web personal en el que su autor (puede haber varios autores autorizados) puede escribir cronológicamente artículos, noticias...(con imágenes y enlaces), pero además es un espacio colaborativo donde los lectores también pueden escribir sus comentarios a cada uno de los artículos (entradas/post) que ha realizado el autor. La blogosfera es el conjunto de blogs que hay en internet. Como servicio para la creación de blogs destacan Wordpress.com y Blogger.com

Wikis: En hawaiano "wiki" significa: rápido, informal. Una wiki es un espacio web corporativo, organizado mediante una estructura hipertextual de páginas (referenciadas en un menú lateral), donde varias personas elaboran contenidos de manera asíncrona. Basta pulsar el botón "editar" para acceder a los contenidos y modificarlos. Suelen mantener un archivo histórico de las versiones anteriores y facilitan la realización de copias de seguridad de los contenidos. Hay diversos servidores de wikis gratuitos. Redes sociales: Sitios web donde cada usuario tiene una página donde publica contenidos y se comunica con otros usuarios. Ejemplos: Facebook, Twitter, Tuenti, Hi5, Myspace, etc. También existen redes sociales profesionales, dirigidas a establecer contactos dentro del mundo empresarial (LinkedIn, Xing, eConozco, Neurona...). Entornos para compartir recursos: Entornos que nos permiten almacenar recursos o contenidos en Internet, compartirlos y visualizarlos cuando nos convenga. Constituyen una inmensa fuente de recursos y lugares donde publicar materiales para su difusión mundial. Existen de diversos tipos, según el contenido que albergan o el uso que se les da: - Documentos: Google Drive y Office Web Apps (SkyDrive), en los cuales podemos subir nuestros documentos, compartirlos y modificarlos. - Videos: Youtube, Vimeo, Dailymotion, Dalealplay... Contienen miles de vídeos subidos y compartidos por los usuarios. - Fotos: Picassa, Flickr... Permiten disfrutar y compartir las fotos también tenemos la oportunidad de organizar las fotos con etiquetas, separándolas por grupos como si fueran álbumes, podemos seleccionar y guardar aparte las fotos que no queremos publicar. - Agregadores de noticias: Digg, Meneame... Noticias de cualquier medio son agregadas y votadas por los usuarios. - Almacenamiento online: Dropbox, Google Drive, SkyDrive - Presentaciones: Prezi, Slideshare. - Plataformas educativas. - Aulas virtuales (síncronas). - Encuestas en línea .

Software de servidor La redifusión solo se diferencia nominalmente de los métodos de publicación de la gestión dinámica de contenido, pero los servicios Web requieren normalmente un soporte de bases de datos y flujo de trabajo mucho más robusto y llegan a parecerse mucho a la funcionalidad de Internet tradicional de un servidor de aplicaciones. El enfoque empleado hasta ahora por los fabricantes suele ser bien un enfoque de servidor universal, el cual agrupa la mayor parte de la funcionalidad necesaria en una única plataforma de servidor, o bien un enfoque plugin de servidor Web con herramientas de publicación tradicionales mejoradas con interfaces API y otras herramientas. Independientemente del enfoque 6

elegido, no se espera que el camino evolutivo hacia la Web 2.0 se vea alterado de forma importante por estas opciones. La web 1.0 principalmente trata lo que es el estado estático, es decir los datos que se encuentran en ésta no pueden cambiar, se encuentran fijos, no varían, no se actualizan. La Web 2.0 ha originado la democratización de los medios haciendo que cualquiera tenga las mismas posibilidades de publicar noticias que un periódico tradicional. Grupos de personas crean blogs que al día de hoy reciben más visitas que las versiones online de muchos periódicos. La Web 2.0 ha reducido considerablemente los costes de difusión de la información. Al día de hoy podemos tener gratuitamente nuestra propia emisora de radio online, nuestro periódico online, nuestro canal de vídeos, etc. Al aumentar la producción de información aumenta la segmentación de la misma, lo que equivale a que los usuarios puedan acceder a contenidos que tradicionalmente no se publican en los medios convencionales.

Lenguajes de programación en la Web 2.0 Desde los orígenes del Html hasta el moderno PhP, los lenguajes de programación Web han ido avanzando y reinventándose a la par que la World Wide Web. Continuaremos haciendo un breve resumen de “¿quien es quien?, para que el lector sepa finalmente lo fácil que le va a hacer la vida Joomla a la hora de programar paginas Web.

PHP PHP es un lenguaje de programación interpretado, diseñado originalmente para la creación de páginas web dinámicas. Es usado principalmente en interpretación del lado del servidor pero actualmente puede ser utilizado desde una interfaz de línea de comandos o en la creación de otros tipos de programas incluyendo aplicaciones con interfaz gráfica usando las bibliotecas Qt o GTK+. PHP es un Acrónimo recursivo que significa PHP Hypertext Pre-processor (inicialmente PHP Tools, o, Personal Home Page Tools). Fue creado originalmente por Rasmus Lerdorf en 1994; sin embargo la implementación principal de PHP es producida ahora por The PHP Group y sirve como el estándar de facto para PHP al no haber una especificación formal. Publicado bajo la PHP License, la Free Software Foundation considera esta licencia como software libre. Los scripts PHP: son los que ejecutan las acciones de consulta y realizan modificaciones en la base de datos convirtiendo los datos en simples páginas web interpretables por los navegadores de Internet y perfectamente inteligibles para los usuarios y administradores.

SQL El lenguaje de consulta estructurado o SQL es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones en éstas. Una de sus características es el manejo del álgebra y el cálculo relacional permitiendo efectuar consultas con el fin de recuperar -de una forma sencilla- información de interés de una base de datos, así como también hacer cambios sobre ella. Es un lenguaje de cuarta generación. La base de datos MySQL: es donde se guarda toda la información y la mayor parte de la configuración del sistema, de una forma ordenada y en distintas tablas, cada una de las cuales almacena información específica y determinada.

HTML Definiéndolo de forma sencilla, HTML es lo que se utiliza para crear todas las páginas web de Internet. Más concretamente, HTML es el lenguaje con el que se "escriben" la mayoría de páginas web. Los diseñadores utilizan el lenguaje HTML para crear sus páginas web, los programas que utilizan los diseñadores generan páginas escritas en HTML y los navegadores que utilizamos los usuarios muestran las páginas web después de leer su

contenido HTML. Aunque HTML es un lenguaje que utilizan los ordenadores y los programas de diseño, es muy fácil de aprender y escribir por parte de las personas. El lenguaje HTML es un estándar reconocido en todo el mundo y cuyas normas define un organismo sin ánimo de lucro llamado World Wide Web Consortium, más conocido como W3C. Como se trata de un estándar reconocido por todas las empresas relacionadas con el mundo de Internet, una misma página HTML se visualiza de forma muy similar en cualquier navegador de cualquier sistema operativo (en teoría).

XHTML El lenguaje XHTML es muy similar al lenguaje HTML. De hecho, XHTML no es más que una adaptación de HTML al lenguaje XML. Técnicamente, HTML es descendiente directo del lenguaje SGML, mientras que XHTML lo es del XML (que a su vez, también es descendiente de SGML). Las páginas y documentos creados con XHTML son muy similares a las páginas y documentos HTML. Las discusiones sobre si HTML es mejor que XHTML o viceversa son recurrentes en el ámbito de la creación de contenidos web, aunque no existe una conclusión ampliamente aceptada. Actualmente, entre HTML 4.01 y XHTML 1.0, la mayoría de diseñadores escogen XHTML. En un futuro cercano, si los diseñadores deben elegir entre HTML 5 y XHTML 1.1 o XHTML 2.0, quizás la elección sea diferente.

XML XML, siglas en inglés de eXtensible Markup Language (lenguaje de marcas extensible), es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). Es una simplificación y adaptación del SGML y permite definir la gramática de lenguajes específicos (de la misma manera que HTML es a su vez un lenguaje definido por SGML). Por lo tanto XML no es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades. Algunos de estos lenguajes que usan XML para su definición son XHTML, SVG, MathML. La tecnología XML busca dar solución al problema de expresar información estructurada de la manera más abstracta y reutilizable posible. Que la información sea estructurada quiere decir que se compone de partes bien definidas, y que esas partes se componen a su vez de otras partes. Entonces se tiene un árbol de trozos de información. Ejemplos son un tema musical, que se compone de compases, que están formados a su vez por notas. Estas partes se llaman elementos, y se las señala mediante etiquetas. Una etiqueta consiste en una marca hecha en el documento, que señala una porción de éste como un elemento. Un pedazo de información con un sentido claro y definido. Las etiquetas tienen la forma <nombre>, donde nombre es el nombre del elemento que se está señalando.

CSS Las hojas de estilo en cascada, CSS es un lenguaje usado para definir la presentación de un documento estructurado escrito en HTML o XML (y por extensión en XHTML). El W3C (World Wide Web Consortium) es el encargado de formular la especificación de las hojas de estilo que servirán de estándar para los agentes de usuario o navegadores. La idea que se encuentra detrás del desarrollo de CSS es separar la estructura de un documento de su presentación. Por ejemplo, el elemento de HTML <h1> indica que un bloque de texto es un encabezamiento y que es más importante que un bloque etiquetado como <H2>. Versiones más antiguas de HTML permitían atributos extra dentro de la etiqueta abierta para darle formato (como el color o el tamaño de fuente). No obstante, cada etiqueta <H1> debía disponer de la información si se deseaba un diseño consistente para una página y, además, una persona que lea esa página con un navegador pierde totalmente el control sobre la visualización del texto. Cuando se utiliza CSS, la etiqueta <H1> no debería proporcionar información sobre como va a ser visualizado, solamente marca la estructura del documento. La información de estilo separada en una hoja de estilo, especifica cómo se ha de mostrar <H1>: color, fuente, alineación del texto, tamaño y otras características. La información de estilo puede ser adjuntada tanto como un documento separado o en el mismo documento HTML. En este último caso podrían definirse estilos generales en la cabecera del documento o en cada etiqueta particular mediante el atributo "style".

AJAX Ajax, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones interactivas. Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones. Ajax es una tecnología asíncrona, en el sentido de que los datos adicionales se requieren al servidor y se cargan en segundo plano sin interferir con la visualización ni el comportamiento de la página. JavaScript es el lenguaje interpretado (scripting language) en el que normalmente se efectúan las funciones de llamada de Ajax mientras que el acceso a los datos se realiza mediante --XMLHttpRequest--, objeto disponible en los navegadores actuales. En cualquier caso, no es necesario que el contenido asíncrono esté formateado en XML. Ajax es una técnica válida para múltiples plataformas y utilizable en muchos sistemas operativos y navegadores dado que está basado en estándares abiertos como JavaScript y --Document Object Model-- (DOM).

JavaScript JavaScript es un lenguaje de scripting basado en objetos sin tipo y liviano, utilizado para acceder a objetos en aplicaciones. Principalmente, se utiliza integrado en un navegador web permitiendo el desarrollo de interfaces de usuario mejoradas y páginas web dinámicas. JavaScript se caracteriza por ser un lenguaje basado en prototipos, con entrada dinámica y con funciones de primera clase. JavaScript ha tenido influencia de múltiples lenguajes y se diseñó con una sintaxis similar al lenguaje de programación --Java--, aunque más fácil de utilizar para personas que no programan. Todos los navegadores modernos interpretan el código JavaScript integrado dentro de las páginas web. Para interactuar con una página web se provee al lenguaje JavaScript de una implementación del Document Object Model (DOM). El lenguaje fue inventado por Brendan Eich en la empresa Netscape Communications, la que desarrolló los primeros navegadores web comerciales. Apareció por primera vez en el producto de Netscape llamado Netscape Navigator 2.0. Tradicionalmente, se venía utilizando en páginas web HTML, para realizar operaciones y en el marco de la aplicación cliente, sin acceso a funciones del servidor. JavaScript se ejecuta en el agente de usuario, al mismo tiempo que las sentencias van descargándose junto con el código HTML.

Introducción a Joomla Joomla! está programado principalmente en lenguaje PHP (Hypertext Pre Procesor) y SQL (Structure Query Language). Utiliza Bases de datos relacionales, más específicamente MySQL. Tanto PHP como MySQL son programas Open Source de libre distribución y uso, y al ser Joomla! una aplicación WEB, funciona obviamente en servidores de páginas web. Existen también otro tipo de archivos que realizan importantes tareas dentro de Joomla! (archivos HTML, XHTML, XML, scripts Javascript, CSS, Ajax, etc), pero el motor fundamental de Joomla! lo constituyen los dos enunciados inicialmente.  ¿Qué es el sistema Joomla!? Joomla! es un software para crear sitios web autoadministrables, que funciona conectado a una base de datos. El sistema es gratuito y se puede personalizar 100% en su aspecto gráfico y en tu idioma. Joomla! es un Software Libre distribuido bajo Licencia GPL.  ¿Para qué puedo utilizar joomla!? Joomla! puede ser utilizado para crear desde sitios web básicos informativos, hasta portales web de alta complejidad como magazines, galerías de medios digitales, repositorios de documentos, portales de noticias, comunidades on line, entre muchas otras prestaciones.

Conclusiones sobre la historia de la Web y los Lenguajes de Programación Muy probablemente, si uno es un ser humano razonable, después de leer todo lo anterior se puede realizar una pregunta al aire, ¿es necesario saber, conocer y dominar todos los lenguajes de programación vistos anteriormente para programar una pagina web?. La respuesta es NO. El resumen hecho anteriormente solo pretende exponer sobre la mesa todo lo que puede llegar a utilizar Joomla a la hora de visualizar y programar un Web. Gracias a el desarrollo de los lenguajes de programación Web, Joomla es lo que es hoy en día. En cualquier caso, después de lo citado anteriormente se nos ha olvidado una cosa, ¿como vamos a hacer para que Joomla funcione en nuestro navegador y podamos realizar paginas web?, de eso trata este proyecto. A través de una maquina Virtual Debian 6.0 (Linux) instalada en el software Virtual Box y un servidor Apache configurado correctamente, operar con Joomla será un juego de niños.

Por que no a XAMPP Antes de decirle No a Xampp, primero tendremos que saber que es. XAMPP es un servidor independiente de plataforma, software libre, que consiste principalmente en la base de datos MySQL, el servidor web Apache y los intérpretes para lenguajes de script: PHP y Perl. El nombre proviene del acrónimo de X (para cualquiera de los diferentes sistemas operativos), Apache, MySQL, PHP, Perl. El programa está liberado bajo la licencia GNU y actúa como un servidor web libre, fácil de usar y capaz de interpretar páginas dinámicas. Actualmente XAMPP está disponible para Microsoft Windows, GNU/Linux, Solaris y MacOS X. Para que los mortales entiendan, Xampp es una solución completa que nos permite tener un servidor Web (para servir paginas Web) de una manera sencilla y rápida, entonces, se preguntará el lector. ¿Por que no lo usamos?. No lo vamos a usar por varios motivos, Xampp aunque es multiplataforma se suele implementar en sistemas operativos Microsoft, esto es debido a que, por ejemplo un usuario Linux (suele) prefiere instalarse cada “pieza” del software Xampp por su cuenta y así configurar cada una individualmente y no colectivamente como hace Xampp. Xampp es una solución de “siguiente”, “siguiente” muy al estilo Microsoft. Esto a muchos usuarios les parecerá cómodo, lo que Xampp no dice es que al implementarse en su Sistema Operativo esta iniciando una cantidad de servicios necesarios para el servidor Web como son: puerto 80 de Apache, puerto 19-21 de FTP, puerto 3306 de mysql, etc. Todo esto bien configurado puede quedar en un entorno seguro, pero no es de locos pensar, que un usuario Microsoft, acostumbrado al “siguiente”, “siguiente”, no va a prestar mucha atención a la configuración individual de cada pieza de software que incluye Xampp. Además estas configuraciones se quedarán “impregnadas” en el sistema operativo, de tal manera que cada vez que arranque su maquina, vaya a usar el entorno de programación Joomla o no, su maquina se preparará para dicho cometido, utilizando recursos que Ud. tal vez quiera usar para otros fines. La solución a todos estos problemas tanto de seguridad, como de limpieza del sistema así como de optimización de recursos la encontramos en la virtualización. Con una maquina virtual (en este caso, Debian), cada vez que queramos trabajar con el entorno de programación de Joomla, solo tendremos que hacer “doble clic” sobre el icono de la maquina virtual puesto en nuestro escritorio, abrir un navegador y trabajar. Al finalizar la sesión de trabajo, cerraremos el navegador, la maquina virtual y nuestro sistema estará listo para el resto de tareas, limpio y sin puertos extras abiertos hacia el exterior.

Instalación de VirtualBox Este paso es prioritario para la realización de este proyecto, el usuario tendrá que realizar los pasos tal como se describen a continuación para la correcta instalación del software de Oracle VM VirtualBox, que nos permitirá la virtualización-instalación de la maquina virtual Debian Squeeze, que vendrá preparada y lista con todos los servicios necesarios para la utilización segura y correcta de Joomla.

Instalación en Sistemas Microsoft 1º Abriremos un navegador al gusto (firefox, chrome, opera, etc). 2º Pegamos y copiamos en la barra de direcciones lo siguiente. http://download.virtualbox.org/virtualbox/4.2.12/VirtualBox-4.2.12-84980-Win.exe

1.- Hemos utilizado Firefox

2.- Una vez descargado...

3.- Botón derecho sobre la descarga y click

4.- Ejecutar

en abrir.

5.- Next (siguiente)

7.- Next (siguiente)

8. Yes.

9.- Install

10.- Next (siguiente)

11. Continuar

12. Continuar

13. Continuar

14. Continuar

15. Continuar

16. Finish

Instalación en Sistemas Linux 1º Abriremos una terminal 2º Abriremos un navegador al gusto (firefox, chrome, opera, etc). 3º Pegamos y copiamos en la barra de direcciones lo siguiente. https://www.virtualbox.org/wiki/Linux_Downloads

4º Seleccionamos nuestra distribución y arquitectura de procesador (32 bits o 64 bits) 5º Descargamos el paquete correspondiente. 6º Abrimos una terminal. 7º Nos situamos en el directorio de las descargas con (escribimos en la terminal): cd ~/Descargas/ 8º Instalamos (siempre con derechos administrativos): – Sistemas Debian y derivados dpkg -i nombredelpaquete.deb – Sistemas Red Hat y derivados. rpm -ivh nombredelpaquete.rpm

Si lo que quiere es instalar la maquina virtual que hemos realizado y empezar a trabajar con Joomla 2.5 salte estos capitulos y siga leyendo en la pagina 115. Si por el contrario lo que quiere es saber como hemos hecho la maquina siga leyendo.

Creación de la maquina Virtual en Virtual Box.

Abrimos VirtualBox y le damos a clic a nueva.

Le ponemos un nombre de nuestro gusto, en tipo seleccionamos Linux y en Versión ponemos Debian.

Le asignamos 512 Mb. de memoria ram. Aunque el sistema no va a tener entorno de escritorio le ponemos un poco más para no tener problemas.

Le damos clic en crear un disco duro virtual ahora. Seguimos con Crear. 20

Dejamos la opción por defecto VDI. Siguiente.

Dejamos la opción por defecto Reservado dinámicamente. Siguiente.

Escribimos un nombre para la unidad de disco duro (label) al gusto. Dejamos 8 Gb. De espacio para el disco duro virtual. Clic en crear.

Aquí tenemos la maquina lista, pero, sin el sistema operativo cargado, solo tenemos el hardware (virtual).

Instalación de Debian 6.0 Squeeze en la maquina virtual Una vez preparado el entorno de virtualización con VirtualBox y creado la maquina virtual Debian que alojara a dicho sistema, lo que nos falta es la instalación propia del sistema. Primero abriremos un navegador y descargaremos una imagen ISO. Ponemos en el navegador (barra de direcciones) lo siguiente. http://cdimage.debian.org/debian-cd/6.0.7/i386/iso-cd/debian-6.0.7-i386-netinst.iso

Una vez descargado el archivo abrimos desde el menú de aplicaciones Virtual Box.

Vamos a la pestaña configuración.

Se nos abre este nuevo cuadro de dialogo. Pinchamos clic en almacenamiento. Como podemos observar tenemos un controlador (virtual) Ide y un controlador (virtual) sata. En el ide hay una lectora de DVD (virtual) pinchada. El el sata esta nuestro disco duro (virtual) de 8 Gb.

Pinchamos clic en la lectora.

Situamos el ratón en la derecha de la pantalla y hacemos clic en el icono de la lectora (cuadro rojo).

Se abre un cuadro de dialogo nuevo. Aquí deberemos localizar en la carpeta de descargas de nuestro Pc la imagen previamente descargad. Una vez localizada, pinchamos en el archivo y le damos a abrir.

Como podemos ver nuestro cd de Debian (imagen ISO) se ha cargado en la lectora virtual. Clic en Aceptar. Ya tenemos nuestra maquina virtual lista. Hardware configurado e imagen del sistema operativo cargada en el lector. Solo nos falta encender la maquina.

Doble clic en Iniciar.

Bienvenido al mundo de la virtualización, esta a punto de instalar una maquina virtual. Ahora los pasos son idénticos a los que realizaríamos en una maquina convencional. La instalación del sistema operativo en el pc. A partir de este momento el ratón puede causar problemas. Con la tecla CTRL-DERECHA podemos mover el ratón desde la maquina virtual al escritorio de nuestro Pc. En cualquier caso muy atentos a LOS CURSORES, serán grandes aliados en la instalación junto a la tecla ENTER. Con ayuda de los cursores nos situamos en GRAPHICAL INSTALL y pulsamos la tecla ENTER. Vamos a iniciar la instalación del sistema operativo Debian 6.0 Squeeze (Linux).

Seleccionamos el idioma para la instalación y el sistema. Spanish.

1.- Seleccionamos la región

2.- Seleccionamos nuestro teclado.

3.- El instalador carga componentes.

4.- Poner nombre a la maquina.

5.- Nombre al dominio (Home).

6.- Contraseña de root

7.- Nombre para la cuenta del usuario

8.- Contraseña de usuario.

9.- Zona horaria.

10.- Particionado de discos (guiado). Utilizar todo el disco.

11.- Continuar (vemos el disco de 8Gb.)

12.-Seleccionamos–Todos los ficheros en una partición.

13.- Finalizar el particionado y escribir

14.- ¿Desea escribir los cambios en

los cambios en disco.

disco?. SI.

15.- Formateo de particiones.

16.- Instalando el sistema base.

17.- Configurar la región para el gestor

18.- Seleccionar el ftp. Elegimos

de paquetes (apt). España.

ftp.gva.es ya que es el más cercano a Valencia.

19.- Al no tener proxy, dejamos en blanco pulsamos continuar.

20.- El sistema esta configurando el y gestor de paquetes automáticamente.

21.- El programa de instalación continua.

22.- Nos pide que si queremos enviar automáticamente estadísticas sobre el uso de paquetes (software), ponemos que SI.

23.- Seleccionamos SOLO – Utilidades estándar del sistema.

24.- El sistema continua con la Instalación.

25.- Marcar SI a instalar el cargador

26.- El sistema continua la instalación.

de arranque GRUB.

26.- La instalación esta terminando...

27.- Instalación finalizada.

28.- Clic en continuar.

28.- El sistema se reinicia. 32

29. Una vez reiniciado aparece el grub. No TOCAR.

30.Lineas autómatas con comandos. Todo normal. El pc virtual esta arrancando.

Finalmente aparece la linea de comandos con el Login. Aquí será donde pondremos el nombre del usuario para luego poner su password y entrar en el sistema. Debian 6.0 Squeeze ya está instalado en nuestra maquina virtual VM VirtualBox. Nos queda la parte más divertida. Instalar los servicios que ofrecía Xampp pero individualmente, de tal manera que iremos afinando la maquina, poco a poco, servicio a servicio hasta que quede a nuestro gusto. Antes de iniciar dicho proceso, vamos a realizar un resumen de las configuraciones que hemos hecho en la maquina para que nos sirva de referencia en futuras consultas.

Fecha del proceso de instalación

1 de mayo de 2013

Versión de VM VirtualBox

4.2.12 - r84980

Versión Debian y arquitectura cpu

6.0.7 - I386

Versión y nombre de la imagen ISO

debian-6.0.7-i386-netinst.iso

Nombre VDI (disco duro virtual)

Debian 6.0 - Joomla.vdi

Nombre maquina virtual

Debian 6.0 - Joomla.vbox

Nombre de la maquina en Debian

debian-joomla

Nombre de dominio

Home

Contraseña de root

Aa12345678

Nombre del usuario

joomla

Contraseña del usuario

Aa12345678

Tamaño del disco raiz (/)

8.2 Gb.

Tipo de partición del disco raiz (/)

ext3

Dirección gestor de paquetes (sources.list)

ftp.gva.es

Version del Kernel

2.6.32-5-686

Direccion Ip Maquina Virtual: Logearse como root y usar el comando ⟶

cualesmiip - 10.0.2.15

Posibles problemas con la ip: Logearse como root y usar el comando ⟶

reiniciamac

Apagar la maquina: Logearse como root y usar el comando ⟶

apagame

Para entrar a Apache: Desde un navegador

Puerto 4443 https://127.0.0.1:4443

Para entrar a Joomla: Desde un navegador:

https://127.0.0.1:4443/administrator

Para entrar por FTP: Desde un cliente FTP (Filezilla, ftp, etc)

Puerto 2121 Dirección ip: 127.0.0.1

Para entrar por ssh: Desde un cliente ssh (Putty, openssh, etc)

Puerto 2222 ssh -p 2222 root@127.0.0.1

La maquina virtual tiene el adaptador de red (tarjeta de red virtual) configurada en modo NAT, la ip por defecto debe ser 10.0.2.15, dentro del segmento de red 10.0.2.0. Para comunicarnos con dicha maquina vamos a implementar un comando de VirtualBox que nos va a permitir hacer “port forwarding” y redireccionar todas las peticiones desde la maquina anfitrión y unos puertos concretos y definidos por nosotros hacia nuestra maquina virtual. De tal manera que para comunicarnos con dicha maquina lo único que debemos saber es el numero de redirección del puerto. Esto nos permite una interoperabilidad total entre los tres sistemas operativos anfitriones mas extendidos, Linux,Mac y Windows, sin tener que hacer configuraciones extras. Simplemente añadiremos la maquina virtual en el modo de agregar maquina y todo debería funcionar (como se verá al final del proyecto). Para implementar estas redirecciones hemos ejecutado los siguientes comandos, preparando dicha maquina virtual para que los servicios “oyentes” respondan adecuadamente a sus llamadas. VBoxManage modifyvm "VM name" --natpf1 "nombreservicio,protocolo,,puertolocal,,puertoserviciomaquinavirtual"

REDIRIGIR LLAMADAS LOCALES (ANFITRION) DEL PUERTO 2222 AL PUERTO 22 DEL HOST PARA SSH ⟶ VBoxManage modifyvm "Debian 6.0 - Joomla" --natpf1 "guestssh,tcp,,2222,,22" REDIRIGIR LLAMADAS LOCALES (ANFITRION) DEL PUERTO 8888 AL PUERTO 80 DEL HOST PARA APACHE ⟶ VBoxManage modifyvm "Debian 6.0 - Joomla" --natpf1 "guestapache,tcp,,8888,,80" REDIRIGIR LLAMADAS LOCALES (ANFITRION) DEL PUERTO 2121 AL PUERTO 21 DEL HOST PARA OPENFTP ⟶ VBoxManage modifyvm "Debian 6.0 - Joomla" --natpf1 "guestftp,tcp,,2121,,21" REDIRIGIR LLAMADAS LOCALES (ANFITRION) DEL PUERTO 4443 AL PUERTO 443 DEL HOST PARA APACHE SEGURO ⟶ VBoxManage modifyvm "Debian 6.0 - Joomla" --natpf1 "guestssl,tcp,,4443,,443" De esta manera nos aseguramos de que en la maquina virtual, una vez finalizadas las configuraciones, no se deberá hacer nada por parte del usuario final para poder utilizar Joomla 2.5 Es vital que la configuración de red se quede en modo NAT y con la ip 10.0.2.15, ya que los servicios instalados solo escucharan (por motivos de seguridad) en esta IP. Por eso se han implementado los comandos cualesmiip y reiniciamac para que el usuario final pueda comprobar que ese dato es correcto.

Notas finales del modo NAT En modo NAT, la máquina virtual está conectado a una red privada interna que VirtualBox hace invisible a los servicios de red y no se puede acceder a ellos desde otros equipos de la misma red o desde el anfitrión. Sin embargo, al igual que un router físico, VirtualBox puede seleccionar y redireccionar servicios disponibles para el mundo exterior a las maquinas virtuales a través del reenvío de puertos. Esto significa que VirtualBox escucha a ciertos puertos en el anfitrión y vuelve a enviar todos los paquetes que llegan allí a la maquina virtual, en el mismo o un puerto diferente. Esto también significa que no se puede ejecutar el mismo servicio en los mismos puertos en el anfitrión y en la maquina virtual. Tendrá que saber qué puertos utiliza el servicio y decidir qué puertos usar en el anfitrión (a menudo, pero no siempre tendrá que utilizar los mismos puertos en la maquina virtual y en el anfitrión). Puede utilizar cualquier puerto del anfitrión que no esté ya en uso por un servicio. Por ejemplo, para establecer conexiones NAT entrantes a un servidor ssh en la maquina virtual, utilice el siguiente comando: VBoxManage modifyvm "nombre de VM" --natpf1 "guestssh, tcp,, 2222,, 22" Con el ejemplo anterior, todo el tráfico TCP que llegan al puerto 2222 en cualquier interfaz de red del anfitrión será remitido al puerto 22 en la maquina virtual. El nombre del protocolo tcp es un atributo obligatorio a definir. El protocolo que se debe utilizar para el reenvío (UDP también podría usarse). El nombre de guestssh es puramente descriptivo. El número después de --natpf indica la tarjeta de red virtual. Para eliminar esta regla de reenvío, utilice el siguiente comando: VBoxManage modifyvm "nombre de VM" --natpf1 delete "guestssh" Si por alguna razón el cliente utiliza una dirección IP estática no asignada por el DHCP de virtualbox, es necesario especificar la IP cliente en la regla de reenvío: VBoxManage modifyvm "nombre de VM" --natpf1 "guestssh, tcp, 2222,10.0.2.19,22" Este ejemplo es idéntico al anterior, excepto que el motor NAT le dice al anfitrión que la dirección ip de la maquina virtual es 10.0.2.19. Para reenviar todo el tráfico entrante desde una interfaz del anfitrión a la maquina virtual, especifique la IP de ese interfaz de esta manera: VBoxManage modifyvm "nombre de VM" --natpf1 "guestssh, tcp, 127.0.0.1,2222,, 22"

Esto reenvía todo el tráfico TCP que llegué a la interfaz localhost (127.0.0.1) a través del puerto 2222 al puerto 22 en la maquina virtual. No es posible configurar conexiones NAT entrantes mientras la máquina virtual está en ejecución. Sin embargo, usted puede cambiar la configuración de una máquina virtual que este guardada actualmente (o apagada con una instantánea).

Instalación de openssh implementado en Debian 6.0 Squeeze en la maquina virtual Al usuario normal de Joomla, muy probablemente, este servicio no le diga nada, pero seguro que para un usuario mas avanzado le será muy útil, vamos a instalarlo y lo pondremos en marcha por dejar mas “puertas” con las que conectarnos con la maquina virtual. Instalamos el paquete (software) openssh-server, versión (1:5.5p1-6+squeeze3) Una vez logeados en la terminal como root tecleamos. apt-get install openssh-server Aceptamos la instalación de los paquetes con un si. Para comprobar que el servicio esta levantado podemos hacer: ps ax | grep sshd 853 ?

0:00 /usr/sbin/sshd

1177 pts/0

S+

0:00 grep sshd

Tambien podemos comprobar otra vez con: netstat -ntap | grep ssh tcp

0 10.0.2.15:22

0.0.0.0:*

LISTEN

853/sshd

Si hubiese cualquier problema con el servicio lo podemos “levantar” con el comando service ssh start Starting OpenBSD Secure Shell server: sshd. Una vez levantado el servicio vamos a su archivo de configuración y realizaremos los cambios pertinentes de tal manera que quedará en el sistema como sigue a continuación: vim /etc/ssh/sshd_config # Package generated configuration file # See the sshd_config(5) manpage for details # What ports, IPs and protocols we listen for Port 22 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: ListenAddress 10.0.2.15 Protocol 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 120 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Change to no to disable tunnelled clear text passwords #PasswordAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosGetAFSToken no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes #UseLogin no #MaxStartups 10:30:60

#Banner /etc/issue.net # Allow client to pass locale environment variables AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM yes

Comentar que la autenticación por ssh se hará a través del modulo PAM de linux, con usuarios del sistema, root está autorizado a logearse, la ip de escucha es la ya mencionada 10.0.2.15 en el puerto 22 y que el par de claves es el generado por defecto en la instalación del paquete. El resto de configuraciones queda en manos del usuario experto.

Instalación de las Guest Additions en la maquina virtual Uno de los motivos de instalar un servidor ssh, es la comodidad a la hora de transferir archivos y configuraciones entre el anfitrión y la maquina virtual. Debido a las limitaciones de “copy-paste” entre el sistema anfitrión y la maquina virtual, más si cabe ya que la maquina virtual no tiene entorno de escritorio, trabajaremos con ella conectados desde una terminal por ssh. ¿Que son las guest additions? Las Guest Additions o VirtualBox Guest Additions son un paquete especial con aplicaciones y controladores (drivers) que forman parte de VirtualBox y que deben instalarse en cada una de las máquinas virtuales para mejorar el rendimiento y añadir nuevas funciones. Si instalamos las Guest Additions en el sistema operativo virtual tendremos las siguientes características:  Integración del cursor del ratón: Gracias a esto podemos mover el ratón libremente entre la máquina virtual y la real sin necesidad de usar la “Host Key” para liberar/capturar el control del ratón. Osea, con las Guest Additions se instala un controlador para el ratón en el sistema virtual que se comunica con el controlador del sistema real permitiendo que el ratón funcione indistintamente en los dos sistemas haciendo más cómodo el usar la máquina virtual.  Mejor soporte de vídeo: el driver de vídeo que se instala con las Guest Additions nos ofrece no sólo una buena aceleración de vídeo, sino también resoluciones más altas que se ajustan automáticamente, los gráficos 2D y 3D para aplicaciones pueden ser acelerados por hardware y se puede redimensionar la pantalla de la máquina virtual; y es que el controlador de vídeo virtual que utiliza VirtualBox para cualquier sistema operativo virtualizado proporciona solamente funciones básicas.  Sincronización horaria: Las Guest Additions se encargan de mantener el tiempo sincronizado entre el sistema real y el virtual, y es que a veces el tiempo en el sistema virtual puede llevar una frecuencia diferente al sistema real; por ejemplo, como cuando pausas la maquina virtual que se congelaría el tiempo.  Carpetas compartidas: Es una de las características más importantes porque es una forma fácil de poder intercambiar archivos entre el sistema real y el virtualizado.  Ventanas compartidas: podemos llevar ventanas del sistema virtualizado al sistema anfitrión como si pertenecieran a este último.  Ventanas sin costuras: Esta característica consiste en mostrar una ventana del sistema virtual como si formara parte de nuestro sistema real.  Portapapeles compartido: Al igual que las carpetas compartidas es de gran utilidad. Gracias a esta característica podemos copiar y pegar el contenido del portapapeles independientemente de que estemos en la máquina virtual o real.  Entrada automática en Windows o inicio de sesión automático: Las Guest Additions proveen módulos para facilitar la autentificación automática del usuario en el inicio del sistema virtual.

 Directorios compartidos: es una forma sencilla para compartir archivos entre el sistema real y el sistema virtual. Se le especifica a la Virtual Box que un directorio del sistema real será compartido y ésta le presenta al virtual acceso a ese directorio como si estuvieran conectadas en red.  Comunicación entre el anfitrión y huésped: se utilizan las “Guest properties” como mecanismo de comunicación entre el sistema real y virtual. Con esto se puedes controlar, configurar o monitorizar el virtual. Bueno, todo esto es muy bonito y aunque a nuestro Debian virtualizado, no le hacen falta muchas de estas funciones, vamos a instalar las guest additions por una cuestión de dogma de fe. Si la empresa Oracle, junto a sus técnicos y programadores se han molestado en regalarnos este paquete extra, por algo será. Para instalar las Guest Additions. Con la maquina virtual abierta, nos logeamos en el sistema a través de ssh con cualquier cliente (putty, ssh, etc): ssh -p 2222 root@127.0.0.1 root@127.0.0.1's password: ponemos el password Aa12345678 Linux debian-joomla 2.6.32-5-686 #1 SMP Mon Feb 25 01:04:36 UTC 2013 i686 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Fri May 3 13:59:15 2013 from 10.0.2.2 root@debian-joomla:~# Una vez dentro del sistema: wget http://download.virtualbox.org/virtualbox/4.2.12/VBoxGuestAdditions_4.2.12.iso

Luego montamos la imagen con: mount -t iso9660 -o loop VBoxGuestAdditions_4.2.12.iso /media/cdrom0 Instalamos bzip2, ya que el script de Oracle VM VirtualBox lo necesita. apt-get install bzip2 Ejecutamos la instalación con: sh /media/cdrom0/VBoxLinuxAdditions.run

El programa de instalación compila unos módulos especiales para el kernel, así que puede tardar un rato. Si todo ha ido bien deberíamos ver algo como: Verifying archive integrity... All good. Uncompressing VirtualBox 4.2.12 Guest Additions for Linux............ VirtualBox Guest Additions installer Copying additional installer modules ... Installing additional modules ... Removing existing VirtualBox DKMS kernel modules ...done. Removing existing VirtualBox non-DKMS kernel modules ...done. Building the VirtualBox Guest Additions kernel modules ...done. Doing non-kernel setup of the Guest Additions ...done. You should restart your guest to make sure the new modules are actually used Installing the Window System drivers Installing X.Org Server 1.7 modules ...done. Setting up the Window System to use the Guest Additions ...done. You may need to restart the hal service and the Window System (or just restart the guest system) to enable the Guest Additions. Installing graphics libraries and desktop services components ...done. Como nos indica el script debemos reiniciar para disfrutar de las bondades de las guest additions. Lo hacemos con: reboot Debido a que vamos a montar un servidor de ftp, no debería ser un problema el intercambio de archivos entre la maquina virtual y el anfitrión. En cualquier caso al instalar las guest additions nos reservamos el “derecho” a compartir cualquier carpeta entre las maquinas mediante la interfaz gráfica de VM VirtualBox. Nota.- La maquina al terminar de arrancar da un “warning” con algún modulo de las guest additions. Después de revisar los logs de instalación y demás he llegado a la conclusión que el warning lo da por no disponer de entorno de escritorio (servidor X) y falla la carga del “corta y pega” entre el anfitrión y la maquina virtual. Es una suposición. En maquinas Microsoft no da el warning.

Instalación de Apache 2 en la maquina virtual Debian 6.0 Squeeze. Para la instalación de Apache seguiremos las recetas dadas en clase por Julio Contelles. Empecemos, Una vez logeados en la terminal con derechos administrativos: apt-get install apache2 Leyendo lista de paquetes... Hecho Creando árbol de dependencias Leyendo la información de estado... Hecho Se instalarán los siguientes paquetes extras: apache2-mpm-worker apache2-utils apache2.2-bin apache2.2-common libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap ssl-cert Paquetes sugeridos: apache2-doc apache2-suexec apache2-suexec-custom openssl-blacklist Se instalarán los siguientes paquetes NUEVOS: apache2 apache2-mpm-worker apache2-utils apache2.2-bin apache2.2-common libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap ssl-cert 0 actualizados, 10 se instalarán, 0 para eliminar y 0 no actualizados. Necesito descargar 2074 kB de archivos. Se utilizarán 6963 kB de espacio de disco adicional después de esta operación. ¿Desea continuar [S/n]? Pulsamos la tecla enter. Para comprobar que el servicio esta activo: ps axu | grep apache root 1361 0.0 0.7 7924 3708 ? Ss www-data 1365 0.0 0.4 7192 2072 ? S www-data 1369 0.0 0.8 229592 4492 ? Sl www-data 1370 0.0 0.8 229692 4524 ? Sl root 1602 0.0 0.1 3320 808 pts/0 S+

05:46 05:46 05:46 05:46 08:40

0:02 /usr/sbin/apache2 -k start 0:00 /usr/sbin/apache2 -k start 0:00 /usr/sbin/apache2 -k start 0:00 /usr/sbin/apache2 -k start 0:00 grep apache2

Podemos comprobar también con: netstat -ntap | grep 80 tcp6

0 :::80

:::*

LISTEN

1353/apache2

Si tuviéramos cualquier problema haríamos: service apache2 restart Restarting web server: apache2 ... waiting 43

Para probar definitivamente que todo esta correctamente, abrimos un navegador y en la barra de direcciones ponemos: http://127.0.0.1:8888/

Si todo ha ido bien, esto es lo que deberíamos ver. La redirección de puertos hecha por VM VirtualBox desde el puerto local 8888 es correcta y el servidor apache ya esta a la escucha en el puerto 80 de la maquina virtual esperando peticiones. Ahora vamos a ir afinando poco a poco Apache.

La NO configuración de un VirtualHost para Joomla. ¿Que es un Virtualhost? Trabajar con Hosts Virtuales consiste en ejecutar más de un sitio web en el mismo servidor. Es decir, mediante los hosts virtuales, Apache2 nos permite la posibilidad de alojar varios dominios en una sola máquina, cada uno con su sitio web. Como en este servidor solo vamos a ejecutar una instancia de Joomla 2.5, no vamos a crear un sitio virtual para Joomla, trabajaremos directamente con el sitio por defecto de apache, existen varios motivos. El primero, no queremos “marear” al usuario teniendo que editar el archivo host (tanto en Microsoft, como Linux, como Mac) de su maquina anfitrión para que el sitio en concreto apunte correctamente al servidor Apache. El segundo, no queremos implementar en esta maquina un servidor DNS, se podría hacer, para que el usuario final pudiese poner en la barra de direcciones www.joomlamicasa.net, pero no vamos a cargar la maquina con más servicios y no nos vamos a complicar la vida. La sencillez es una virtud. 44

Lo que si vamos a hacer, aunque estemos en un entorno local es implementar SSL, ¿por que?, por que no es complicado y la seguridad es lo primero. Imaginemos estar trabajando en una web corporativa con datos sensibles y algún deslamado se cuela en nuestro anfitrión, no nos haría mucha gracia que nos robaran o estropearan el trabajo. Implementando SSL, un intruso tendrá un poquito más complicado saber que estamos haciendo en nuestra maquina virtual. Queda claro que mantener las contraseñas de este manual por defecto no ayudara a este respecto, al final del mismo comentaremos como cambiarlas.

Configuración del modulo de Apache para SSL. ¿Que es SSL? ¿Que es SSL?, wikipedia —> Secure Sockets Layer (SSL; en español «capa de conexión segura») y su sucesor Transport Layer Security (TLS; en español «seguridad de la capa de transporte») son protocolos criptográficos que proporcionan comunicaciones seguras por una red, comúnmente Internet. En nuestro idioma, ssl puede implementarse en prácticamente cualquier servicio, ftp (sftp), http (https), telnet (ssh), etc, la función que realiza ssl es la de encriptar las comunicaciones entre dos puntos, de tal manera que cualquier oyente intermedio podrá escuchar el mensaje, pero este estará encriptado, dificultando enormemente su descifrado y entendimiento. ¿Como lo hacemos? En el fichero /etc/apache2/ports.conf ya tenemos configurado el puerto sobre el que escuchará el servidor seguro, el 443, en caso de cargarse el módulo SSL de apache. NameVirtualHost *:80 Listen 80 <IfModule mod_ssl.c> # SSL name based virtual hosts are not yet supported, therefore no # NameVirtualHost statement here Listen 443 </IfModule> Existe disponible un fichero de configuración por defecto para el sitio web seguro, /etc/apache2/sites-available/default-ssl. Nota: A diferencia de lo que ocurre con HTTP, en HTTPS no se pueden servir fácilmente múltiples sitios virtuales encriptados con SSL desde una misma IP. La razón está en que SSL trabaja en una capa inferior a HTTP y no es posible usar la cabecera Host para distinguir los sitios virtuales a través del nombre del sitio. (En la configuración típica, solo podremos usar un certificado compartido para todas las páginas que se sirvan por HTTPS desde un único servidor web, a menos que usemos una IP diferente para cada sitio) . Este es otro motivo añadido para no usar sitios virtuales.

Para todo ello, solo será necesario realizar los siguientes ajustes: 1. Activar el módulo SSL y habilitar el sitio seguro, vamos una terminal y tecleamos. a2enmod ssl a2ensite default-ssl service apache2 restart 2. Modificar el fichero de configuración del sitio SSL por defecto, se encuentra en, /etc/apache2/sites-enabled/default-ssl. Aunque en este fichero se pueden usar prácticamente las mismas directivas que para un sitio web normal, esto es, sin SSL, es importante saber que las líneas clave para activar SSL son (editamos con nano y descomentamos): nano /etc/apache2/sites- enabled/default-ssl SSLEngine on SSLCertificateFile SSLCertificateKeyFile

/etc/ssl/certs/ssl-cert-snakeoil.pem /etc/ssl/private/ssl-cert-snakeoil.key

Los certificados de snake oil (nombre descriptivo) se generan automáticamente tras la instalación del paquete ssl-cert de Debian y están asociados al hostname del sistema. Se pueden usar tal y como están, salvando las advertencias que nos mostrarán los navegadores, solo la primera vez que entremos, tendremos que aceptar la “confianza”. Comprobamos el servicio con: netstat -ntap | grep 443 tcp6

0 :::443

:::*

LISTEN

794/apache2

Finalmente ponemos en el navegador lo siguiente: https://127.0.0.1:4443/ Nos “saltará” la emergencia de “esta conexión no está verificada”. No problem.

Clic en Entiendo los riesgos

Clic en Añadir excepción

Clic en Confirmar excepción de seguridad

¡Todo ha ido bien!

Ya tenemos nuestro servidor web Apache trabando con encriptación. Para asegurarnos de que no vamos utilizar otro método de trabajo vamos a deshabilitar el sitio por defecto de apache en el puerto 80 con: a2dissite default Site default disabled. Run '/etc/init.d/apache2 reload' to activate new configuration! Reiniciamos Apache con: service apache2 restart Restarting web server: apache2[Fri May 03 21:26:39 2013] [warn] NameVirtualHost *:80 has no VirtualHosts ... waiting [Fri May 03 21:26:40 2013] [warn] NameVirtualHost *:80 has no VirtualHosts Apache nos avisa de que (obviamente) no hay sitios en el puerto 80, ya que hemos dejado solo el sitio por defecto seguro. Comprobamos con: http://127.0.0.1:8888

https://127.0.0.1:4443

No funciona. Correcto

Funciona. Correcto.

Sigamos, para deshabilitar definitivamente las conexiones al puerto 80, vamos a ir al archivo de configuración de Apache y le vamos a decir que no acepte conexiones en ese puerto de nadie. Editamos el archivo y comentamos las dos lineas que hemos subrayado: vim /etc/apache2/ports.conf # If you just change the port or add more ports here, you will likely also # have to change the VirtualHost statement in # /etc/apache2/sites-enabled/000-default # This is also true if you have upgraded from before 2.2.9-3 (i.e. from # Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and # README.Debian.gz # NameVirtualHost *:80 # Listen 80 <IfModule mod_ssl.c> # If you add NameVirtualHost *:443 here, you will also have to change # the VirtualHost statement in /etc/apache2/sites-available/default-ssl # to <VirtualHost *:443> # Server Name Indication for SSL named virtual hosts is currently not # supported by MSIE on Windows XP. Listen 443 </IfModule> <IfModule mod_gnutls.c> Listen 443 </IfModule> Para editar con vim debemos pulsar la tecla Insert. Una vez editado el texto, pulsamos la tecla ESC. En es momento salimos del modo de edición. Para poder introducir comandos pulsamos la tecla : (dos puntos), para finalizar escribimos un comando, en este caso la letra x (minúscula) acompañada del símbolo ! (admiración) que le dice a vim que queremos guardar y salir. Tal vez, parezca complicado, pero les aseguro que cuando te haces a vim y a su modo resaltado (syntax on) no puedes vivir sin él. Ya hemos deshabilitado cualquier navegación en texto plano, a partir de ahora todo el trafico entre la maquina virtual y nuestro anfitrión será encriptado. Para comprobar volvemos a usar el comando: netstat -ntap Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address tcp 0 0 0.0.0.0:111 tcp 0 0 10.0.2.15:22 tcp 0 0 0.0.0.0:36672 tcp 0 0 10.0.2.15:22 tcp6 0 0 :::443

Foreign Address 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 10.0.2.2:57027 :::*

State PID/Program name LISTEN 599/portmap LISTEN 841/sshd LISTEN 611/rpc.statd ESTABLISHED 1540/0 LISTEN 1788/apache2

Como podemos comprobar en la linea referente a Apache, el servidor web esta escuchando en el puerto 443 (puerto seguro) y aceptando peticiones de cualquier cliente en cualquier Ip, debido a que nosotros solo vamos a aceptar peticiones de la ip 10.0.2.15 tenemos que ajustar la configuración, así que vamos (primero) a editar el archivo del sitio seguro de Apache2. vim /etc/apache2/sites-enabled/default-ssl <IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@localhost DocumentRoot /var/www <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from 10.0.2.2 </Directory> <<------------------------El archivo continua, pero no ponemos el final---------------------->> ¿Por que restringimos la entrada de trafico por esta ip? Por que en el modo NAT que esta nuestra maquina virtual el gateway (puerta de enlace) por defecto es la 10.0.2.2, podemos comprobarlo con el comando: route -n Kernel IP routing table Destination Gateway 10.0.2.0 0.0.0.0 0.0.0.0 10.0.2.2

Genmask 255.255.255.0 0.0.0.0

Flags Metric Ref U 0 0 UG 0 0

Use 0 0

Iface eth0 eth0

Realmente esto no “acota” mucho de donde vienen las peticiones, así que debemos seguir “hurgando” para que realmente nuestro servidor solo responda a la IP que hemos elegido (10.0.2.15) como en el caso del servidor ssh. Cuando Apache se inicia, comienza a esperar peticiones entrantes en determinados puertos y direcciones de la máquina en la que se está ejecutando. Sin embargo, si quiere que Apache escuche solamente en determinados puertos específicos, o solamente en determinadas direcciones, o en una combinación de ambos, debe especificarlo adecuadamente. Esto puede además combinarlo con la posibilidad de usar hosts virtuales, funcionalidad con la que un servidor Apache puede responder a peticiones en diferentes direcciones IP, diferentes nombres de hosts y diferentes puertos. 49

La directiva Listen le indica al servidor que acepte peticiones entrantes solamente en los puertos y en las combinaciones de puertos y direcciones que se especifiquen. Si solo se especifica un número de puerto en la directiva Listen el servidor escuchará en ese puerto, en todas las interfaces de red de la máquina. Si se especifica una dirección IP y un puerto, el servidor escuchará solamente en la interfaz de red a la que pertenezca esa dirección IP y solamente en el puerto indicado. Se pueden usar varias directivas Listen para especificar varias direcciones IP y puertos de escucha. El servidor responderá a las peticiones de todas las direcciones y puertos que se incluyan. Por ejemplo, para hacer que el servidor acepte conexiones tanto en el puerto 80 como en el puerto 8000, puede usar: Listen 80 Listen 8000 Para hacer que el servidor acepte conexiones en dos interfaces de red y puertos específicos, use: Listen 192.170.2.1:80 Listen 192.170.2.5:8000 Las direcciones IPv6 deben escribirse entre corchetes, como en el siguiente ejemplo: Listen [2001:db8::a00:20ff:fea7:ccea]:80 Para realizar esta acción (siguiendo los consejos de la documentación oficial de apache) vamos a editar el fichero /etc/apache2/ports.conf; tecleamos en una terminal (Modificaremos las lineas subrayadas): vim /etc/apache2/ports.conf <IfModule mod_ssl.c> # If you add NameVirtualHost *:443 here, you will also have to change # the VirtualHost statement in /etc/apache2/sites-available/default-ssl # to <VirtualHost *:443> # Server Name Indication for SSL named virtual hosts is currently not # supported by MSIE on Windows XP. Listen 10.0.2.15:443 </IfModule> <IfModule mod_gnutls.c> Listen 10.0.2.15:443 </IfModule> Comprobamos con el comando ya repetido netstat: netstat -ntap | grep apache2 tcp

0 10.0.2.15:443

0.0.0.0:*

LISTEN

4359/apache2

Monitorización del uso de recursos de Apache2 Ahora vamos a insertar unas lineas dentro de nuestro sitio seguro por defecto para dicho cometido. Trabajaremos con el modulo status. Para activarlo teclear en la consola: a2enmod status Module status already enabled Viene activado por defecto, solo tenemos que añadir las siguientes lineas a nuestro sitio seguro; editamos con: vim /etc/apache2/sites-enabled/default-ssl Y añadimos las siguientes lineas al final del archivo: ##Activación del modulo mod_status para entrar por https://127.0.0.1:4443/server-status## ExtendedStatus On <Location /server-status> SetHandler server-status Order deny,allow Deny from all Allow from 10.0.2.2 </Location> #Fin del a activación para la maquina virtual## Para entrar a través del navegador y comprobar el estado del servidor solo tenemos que teclear en la barra de direcciones: https://127.0.0.1:4443/server-status La información que se puede conseguir a través de la página web sobre el consumo de recursos del servidor Apache es la siguiente: El tiempo de uptime. El total de accesos y de cantidad de información enviada. El total de accesos y de cantidad de información enviada. Algunos valores medios como el número de peticiones por segundo, número de bytes servidos por segundo o el número de bytes por petición.  El estado de cada proceso de Apache y su porcentaje de uso de la CPU.  Si se está utilizando el HTTPS muestra información sobre el estado de la caché SSL/TLS.  También, sobre Apache utilizado como proxy, activando la directiva ProxyStatus.    

La URL admite un par de parámetros opcionales: ?refresh=N —> para que el resultado se refresque cada N segundos. https://127.0.0.1:4443/server-status?refresh=10 ?auto—> sirve los resultados en modo texto para ser procesados fácilmente por otras herramientas. https://127.0.0.1:4443/server-status?auto

La directiva RewriteEngine y el mod_rewrite ¿Por que activar el mod_rewrite?, antes de nada debemos hacernos otra pregunta, ¿que son las “url amigables”? Las URL semánticas o URL amigables son aquellas URLs que son, dentro de lo que cabe, entendibles para el usuario. Lejos de las clásicas URLs de las páginas dinámicas llenas de variables GET y números difíciles de recordar, las URL semánticas están formadas con palabras relacionadas con el contenido de la página y fáciles de recordar. Estas se utilizan en los sitios web dinámicos (no estáticos) como Joomla. Por ello se están utilizando mucho más que las URL extensas. Las urls en las páginas dinámicas suelen tener este formato. Imaginemos que entramos en una página web a leer una noticia que habla sobre como crear URL amigables: http://www.miweb.com/index.php?seccion=noticias&id_noticia=133 Si tenemos conocimiento de programación web sabremos que estamos accediendo al archivo index.php en www.miweb.com, pasándole a este las variables sección e id_noticia con los valores "noticias" y 133 respectivamente. Si dentro de un tiempo queremos volver a esa página difícilmente recordaremos dicha url. Y a su vez si vemos esta URL sin entrar a la página nos será imposible saber de que trata. URL semántica Con la intención de hacer estas URLs más fáciles de entender y a su vez de recordar surgen las URL amigables. La URL anterior podría quedar de esta forma si la semantizamos: http://www.miweb.com/noticias/url-amigables.html De esta forma con sólo leer la url sabremos de lo que trata la página y se nos hará mucho más fácil de recordar en un futuro. Problema con los buscadores Cada día son más los sitios web que optan por mostrar este tipo de URLs con el fin de que sean indexadas, ya que los buscadores indexan las URL no semánticas sin agregar peso a las palabras adecuadas, devaluando el contenido de la página en los resultados orgánicos. De ahí que surja el nombre de "amigable", pues serán unas URL amigables para los buscadores. Dicho problema que dan las URL tradicionales ha sido el gran impulsor de semantizar muchas de las urls que encontramos en internet.

Ahora ya sabe el porque del “Mod Rewrite” para crear urls amigables, favoreciendo sobre todo el posicionamiento en buscadores (google) . También mejora la usabilidad del sitio web, al obtener direcciones más fáciles de recordar y/o usar para los usuarios. ACLARACIÓN IMPORTANTE: mod_rewrite no reescribe la url en la barra del navegador. Esto lo hacemos nosotros. Lo que hace mod_rewrite es traducir esa url amigable que nosotros usamos en nuestros enlaces, por la “url dinámica real” (la “fea”) que cargará el contenido correspondiente usando php y mysql (o la tecnología del servidor en cuestión). Para activar el modulo vamos a hacer dos cosas, la primera tecleamos en una terminal: a2enmod rewrite service apache2 restart Una vez activado el modulo, vamos a utilizarlo en nuestro sitio por defecto; editamos el archivo default-ssl, en la linea 10 y añadimos lo subrayado: vim /etc/apache2/sites-enabled/default-ssl <Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from 10.0.2.2 RewriteEngine On </Directory> Volvemos a reiniciar Apache2 con: service apache2 restart Comprobamos sintaxis con: apachectl configtest Syntax OK Por ahora el modulo esta activo y funcionando en el directorio donde vamos a instalar Joomla 2.5, ¡sigamos!.

El archivo .htaccess (y por que no vamos a usarlo) El archivo .htaccess (hypertext access) o archivo de configuración distribuida es un archivo en formato ASCII como el que cualquiera puede crear con el bloc de notas, permite definir diferentes directivas de configuración para cada directorio (con sus respectivos subdirectorios) sin necesidad de editar el archivo de configuración principal de Apache. Los archivos .htaccess son usados frecuentemente para especificar restricciones de seguridad para un directorio en particular, de aquí el sufijo “access“. Los servidores suelen usar el .htaccess para reescribir URLs largas y complejas, en otras más simples y fácilmente recordables, permiten bloquear a usuarios por su dirección IP y/o dominio, bloquear bots y arañas web. También permite controlar las páginas de errores cuando estos ocurren del lado del servidor. Al momento de crear un .htaccess se debe recordar que este no tiene una extensión como cualquier otro archivo, se debe guardar en modo ASCCI y no en binario. Programas como el bloc de notas de Microsoft Windows tienden a agregarle automáticamente la extensión .txt pero hay que quitarla. Otro punto a tener en cuenta es que el archivo debe tener permisos de lectura-escritura-ejecución (CHMOD) 644. Con esto hacemos que el archivo pueda ser usado por el servidor pero se previene que sea accedido a través del navegador. Más adelante veremos que el .htaccess también puede ser protegido mediante un par de lineas. Los .htaccess están habilitados por defecto, pero se puede dar el caso en que no lo esté. Este comportamiento se controla a través de la directiva AllowOverride. Gracias al .htaccess podemos controlar el comportamiento de nuestro sitios y aplicaciones Web para que estos sean un poco más seguros, hacer redirecciones, crear mensajes de error más personalizados, restringir el acceso a determinadas carpetas, evitar que se listen directorios específicos, etc. El .htaccess por lo general siempre estará ubicado en el directorio raíz de nuestros sitios Web, también puede estar ubicado en directorios específicos dentro de un servidor Web pero por regla general, debería existir uno en todo directorio raíz. Hay que tener en cuenta que al tener habilitado y configurado el archivo .htaccess, este tendrá un impacto negativo en nuestro sitio Web. La razón de esto es que cada vez que se haga una petición, se buscará en cada directorio posible si existe un archivo .htaccess, y de ser así se ejecutará cada directiva dentro de el. Esto genera cierta carga adicional a un sitio Web y puede degradar su performance. El archivo .htaccess tiene muchas posibilidades, pero visto desde el punto de vista de la seguridad, mencionemos algunas opciones a la hora de configurarlo: 1. Evitar que se liste el contenido de un directorio: Si no tenemos restricciones al momento de listar el contenido de cualquier directorio, este mostrará todo lo que tenga, por ejemplo si tenemos una carpeta llamada “imágenes” en nuestro sitio Web y escribimos directamente su URL en el navegador http://www.tusitio.com/imagenes/ nos mostrará su contenido. Si queremos evitar este tipo de comportamiento podemos usar las directivas Options All -Indexes dentro del .htaccess para evitar que se liste cualquier directorio.

Supongamos que tiene una carpeta llena de eBooks y no quieres que se acceda directamente a ella, pues con la directiva IndexIgnore * lo puede hacer. El comodín “*” indica que tome en cuenta todos los archivos dentro de una carpeta específica. Imaginemos ahora que por alguna razón desea permitir que se listen solo archivos HTML pero ninguno que sea .pdf o .doc, la directiva a usar sería IndexIgnore *.pdf *.doc. En caso contrario, si lo que se desea es permitir que se listen los directorios, sería suficiente con poner un .htaccess con la directiva Options +Indexes en el directorio que se quiera. 2. Evitar el acceso de archivos y carpetas Esto resultaría muy útil cuando queremos proteger archivos críticos, como los archivos de configuración. Un ejemplo de esto podría ser: <files archivo-configuracion.php> order allow,deny deny from all </files> Con esto evitamos que acceda directamente al archivo archivo-configuracion.php vía Web. Un modo de proteger al mismo .htaccess podría ser: <files .htaccess> Order allow,deny Deny from all </files> En el caso de las carpetas críticas o de cualquier otra también es igual. Una forma de evitar el acceso a ciertas carpetas podría ser redireccionándolas a la página principal del sitio Web, esto se conoce como redireccionamiento 301 y es útil en diferentes casos. Redirect 301 /carpeta/ http://www.tudominio.com/ Redirect 301 /carpeta/carpeta/index.html http://www.tudominio.com/ Expliquemos lo anterior: la directiva Redirect al igual que otras como RewriteRule requiere dos parámetros, url_patron y url_destino. Mediante estos parámetro lo que hacemos es indicar que si hay una petición del navegador a una determinada carpeta, lo redireccionamos de “forma elegante” a nuestra página de inicio. 3. Páginas de errores personalizadas Los servidores Web devuelven páginas que muestran un error específico, en caso de que este se haya producido; existen gran cantidad ellos, uno muy conocido es el 404 “Página no encontrada” o “Recurso no encontrado” o “Not found”. También existen otros conocidos como 401 “Authorization Required”, 403 “Forbidden”, 500 “Internal Server Error”. Por lo general estos errores se presentan en inglés ya que vienen desde el servidor, y por su puesto que no tendrán el mismo “look” de nuestro sitio.

Podríamos implementar páginas de errores más acorde a nuestro sitios, y en el idioma que queramos. Una forma de hacerlo puede ser: ErrorDocument 400 /error/badrequest.html ErrorDocument 401 /error/authreqd.html ErrorDocument 403 /error/forbid.html ErrorDocument 404 /error/notfound.html ErrorDocument 500 /error/serverr.html De esta forma estamos indicando que cuando se presente uno de estos errores, se mostrará una página que hayamos diseñado para ese fin. No solo se trata de una “mejor presentación” de los errores que se presenten, sino también se trata de llevar un control de los mismos. Trata de mantener tu archivo .htaccess liviano, recuerda que este es procesado siempre que se haga una petición 4. Evitar el hotlink El hotlink o “robo de ancho de banda” es algo (lamentablemente) muy común en Internet. Se trata de enlazar directamente a un recurso de un sitio Web a otro, como imágenes. La “víctima” sufre robo de ancho de banda (que se traduce en dinero) y el “ladrón” usa recursos que no le pertenecen. Pongamos un ejemplo para ilustrarlo mejor: en un sitio http://sitio-origen.com se ha publicado un artículo que contiene algunas imágenes; a algún lector le gustó el contenido y quiso (re)publicar el mismo artículo en su sitio http://otro-sitio.com y enlaza todas las imágenes desde su origen; cada vez que alguien vea el artículo en http://otro-sitio.com estará usando ancho de banda de http://sitio-origen.com al mostrar las imágenes. Para evitar esto, basta con poner las siguientes lineas en un .htaccess: RewriteEngine on RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://(www\.)?mi-dominio.com/.*$ [NC] RewriteRule \.(jpg|jpeg|gif|png|bmp)$ - [F] En el ejemplo anterior, si la petición a las imágenes (jpg|jpeg|gif|png|bmp) no viene directamente de mi-dominio.com no se permitirá el acceso. Si por el contrario queremos mostrar una imagen en lugar de las originales con algo como “No robes ancho de banda” agregaríamos la siguiente línea: RewriteRule \.(jpg|jpeg|gif|png|bmp)$ http://www.dominio.com/no-hotlink.gif [R,L] Hay que aclarar que si usamos una imagen lo ideal sería que no esté en nuestro servidor, sino estaríamos haciendo “la gracias del bobo” porque de igual forma se estaría usando ancho de banda. Esa imagen bien podría estar en algún servidor de imágenes gratuito. Para lo cual podría quedar como: RewriteRule \.(jpg|jpeg|gif|png|bmp)$http://www.servidor-imagenes.com/no-hotlink.gif [R,L]

5. Bloquear a usuarios o a sitios Esto puede resultar ser sumamente útil en muchos casos, tanto si se piensa que alguien puede estar tratando de fastidiarnos, evitar el spam, evitar el abuso de algunos Crawler (o araña Web), o por alguna otra razón. Para hacer uso de estas técnicas debe estar habilitado el módulo de Apache mod_rewrite, que en la mayoría de los casos está habilitado; es necesario para utilizar la directiva RewriteEngine on, de la que ya hemos hablado en el capitulo anterior. La forma de bloquear una dirección IP sería la siguiente: <Limit GET HEAD POST> order allow,deny deny from 000.000.000.000 deny from 111.000.000.000 deny from 222.000.000.000 allow from all </limit> Con esto estamos especificando que se bloqueen las tres direcciones IP puestas de ejemplo y se permita el resto. Otro ejemplo para bloquear spammers podría ser: RewriteEngine on RewriteCond %{REMOTE_HOST} 000.000.000.000 [OR] RewriteCond %{REMOTE_HOST} 111.000.000.000 [OR] Bloquear un sitio que se considere dañino: RewriteEngine on RewriteCond %{HTTP_REFERER} sitio-malo\.com [NC] RewriteRule .* - [F] O para bloquear múltiples sitios dañinos: RewriteEngine on RewriteCond %{HTTP_REFERER} sitio-malo\.com [NC,OR] RewriteCond %{HTTP_REFERER} sitio-malo2\.com RewriteRule .* - [F] Expliquemos lo anterior: RewriteEngine On es necesario para poder denegar el acceso a un “referente” (IP,Host,sitio web) La terminación [NC] al final de un dominio indica que este se leerá de forma no sensitiva, es decir que puede ser dominio.com, Dominio.com, DOMINIO.COM La [F] indica que rechace la petición, con lo cual el solicitante recibirá un error 403 “Forbidden”.

La diferencia entre bloquear un solo referente a varios es la terminación [NC, OR] al final del primer dominio del ejemplo, esto indica que aplicará la misma condición al siguiente dominio. Si al momento de probar alguno de estos ejemplo se genera el error “500 Internal Server” hay que agregar la siguiente línea: Options +FollowSymlinks Esto sucede en los casos en donde FollowSymLinks no está configurado. Nota: Todo (al menos los “legales”) programa como un navegador, un host, o todo software que realice peticiones a un sitio Web, debe identificarse, a eso se le llama “referente”, del ingles “referer“. Esto también se aplica a los bots o crawler que operan en Internet, como los de Google u otros buscadores que buscan actualizaciones en los sitios Web y enlazan las URL de cada sitio. Otra de las cosas que debemos evitar que sucedan en nuestros sitios Web son los site ripper o “destripador de sitios”. Estas pequeñas monstruosidades son programas offline que operan “en las sombras”, su objetivo es descargar todos los archivos de un sitio Web, para luego verlos sin conexión. Esto claramente puede ocasionar problemas en la seguridad, a parte de que estos programas son altos consumidores de ancho de banda. Existen muchos bots y rippers que pueden ocasionar daños a todo contenido online, y las listas pueden ser largas, pero pongamos algunos ejemplos reales para bloquear a estos indeseados: Options -Indexes RewriteEngine on #Spammers RewriteCond %{REMOTE_HOST} 12.226.240.248 [OR] RewriteCond %{REMOTE_HOST} 24.111.102.26 [OR] RewriteCond %{REMOTE_HOST} 24.117.121.113 [OR] RewriteCond %{REMOTE_HOST} 65.30.216.140 [OR] RewriteCond %{REMOTE_HOST} 67.87.64.23 [OR] #Abusivos RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^Bolt\ 0 [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot\@yahoo\.com [NC,OR] RewriteCond %{HTTP_USER_AGENT} CazoodleBot [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [NC,OR] RewriteRule ^.* - [F,L] #Bloquear bot abusivos por IP order allow,deny allow from all deny from 8.21.4.254 deny from 65.160.238.176/28 deny from 85.92.222.0/24 deny from 206.51.36.0/22 deny from 216.52.23.0/24

Cuando se utilicen reglas de escritura de URL agrega la opción [L] al final, esto le dirá al servidor que no procese más reglas 6. Obligar a que se use una conexión segura Si se dispone de un certificado SSL se pueden agregar las siguientes líneas para obligar a que en todo el sitio se haga uso de SSL: RewriteEngine On RewriteCond %{HTTPS} !on RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} Hay que hacer notar que si no se tiene un certificado SSL instalado, esto puede generar un error y no se pondrá tener acceso al sitio. Bueno, después de todo lo que hemos visto, uno se puede preguntar, ¿por que no usamos el archivo de configuración .htaccess?, bien sencillo, por una cuestión de funcionalidad, queremos que además de la seguridad, nuestro trabajo con Joomla 2.5 sea altamente productivo y sin retrasos, entonces, ¿por que hemos explicado todo lo anterior?. En el momento que termine su sitio web con Joomla, lo más probable es que quiera subirlo a algún hosting de internet, en ese momento, Ud. no podrá “tocar” los archivos de configuración de Apache2 y no tendrá más remedio que usar a .htaccess y volver a leer esta parte del manual.

El usuario www-data Hasta esta parte del manual hemos estado utilizando al usuario administrador (root) para hacer todas las tareas en nuestro servidor. Cualquier administrador de sistemas le dirá que este uso indiscriminado de la cuenta root es peligroso y no le falta razón. Por ese motivo durante la instalación de Debian 6.0 en capítulos anteriores, el sistema nos preguntó por un nombre de usuario, a lo que respondimos con el nombre de joomla (en minúsculas). Es hora ya de poner a este usuario a funcionar. Lo primero que haremos será darle permisos administrativos, para ello vamos a instalar el paquete sudo, este paquete como su descripción reza “Provide limited super user privileges to specific users!”, le otorga al usuario que elijamos permisos administrativos temporales. Instalamos con: apt-get install sudo Para editar el fichero y añadir al usuario Joomla, editamos con vi y añadimos en la linea 18 al nuestro usuario joomla (copiamos y pegamos lo subrayado): vim /etc/sudoers # /etc/sudoers # # This file MUST be edited with the 'visudo' command as root. # # See the man page for details on how to write a sudoers file. # Defaults

env_reset

# Host alias specification # User alias specification # Cmnd alias specification # User privilege specification root ALL=(ALL) ALL joomla ALL=(ALL) ALL # Allow members of group sudo to execute any command # (Note that later entries override this, so you might need to move # it further down) %sudo ALL=(ALL) ALL # #includedir /etc/sudoers.d Con esta última acción ya tenemos al usuario joomla con derechos administrativos, preparado para las futuras acciones. Sigamos. Existen dos usuarios básicos cuyos permisos debemos configurar para el adecuado funcionamiento del sitio web, ejecución de aplicaciones y almacenamiento de archivos: el usuario dueño del sitio. el usuario Apache. 60

En las distribuciones Debian de Linux, el usuario del servidor web Apache normalmente se llama www-data y debe encontrarse en el grupo www-data. En otras distribuciones de Linux se llama nobody o apache. Este usuario www-data debe tener acceso a los directorios públicos del sitio web para poder leer y mostrar sus contenidos. Para facilitar la administración del sitio web, añadimos al usuario administrativo al grupo www-data... sudo usermod -a -G www-data nombre-usuario En nuestro caso: sudo usermod -a -G www-data joomla Si estamos accediendo el servidor con el nombre-usuario (joomla en nuestro caso), podemos verificar que ha sido adicionado al grupo escribiendo... groups joomla joomla : joomla cdrom floppy audio dip www-data video plugdev Si hemos seguido las instrucciones correctamente desde el principio hasta aquí, nuestro usuario debe ser miembro del grupo www-data y el comando anterior debe listar su nombre, seguido de ambos grupos. A continuación, debemos asegurarnos de que nuestro directorio www publico (situado en /var/www) es parte del grupo www-data de Apache: ls -d /var/www 4,0K drwxr-xr-x 2 root root 4,0K may 3 20:37 /var/www Como podemos ver eso no es así, debido a que toda la instalación de Apache la hemos hecho como “root”, ese dato nos ha venido bien para proteger los archivos importantes del servidor web, pero ahora debemos asignar los permisos y propietario correctos a nuestra carpeta publica para la web donde instaremos Joomla 2.5. chgrp -R www-data /var/www Con este comando hacemos propietario de la carpeta /var/www al grupo de www-data (el grupo de apache). Ahora vamos a hacer a nuestro usuario joomla, propietario de toda la carpeta. chown -R joomla /var/www Si ahora listamos la carpeta publica: ls -d www/ 4,0K drwxr-xr-x 2 joomla www-data 4,0K may 3 20:37 www/ Otorgamos los permisos adecuados para que el directorio web y los archivos y directorios creados dentro del mismo sean visibles en la web, usamos el comando... chmod -R 2775 /var/www El 2 hace que sea permanente el permiso para los archivos creados en el futuro, el primer 7 da todos los permisos al usuario dueño del archivo, el segundo 7 da todos los permisos a los usuarios del grupo al cual pertenece el dueño (www-data de Apache) y el 5 indica permisos de lectura (r) y ejecución (x), pero no de escritura (w), para el resto del mundo. Con esto hemos configurado los permisos, usuarios y grupos para Joomla en Apache2. 61

El modulo mod_deflate El RFC2616, de 1999, definió el protocolo HTTP 1.1. En el apartado 14.3, el estándar habla de la cabecera para peticiones Accept-Encoding, que le permite al cliente de HTTP (normalmente un navegador) especificarle al servidor que acepta contenido comprimido, con el consiguiente ahorro de ancho de banda. En efecto, si tomamos una traza (paquete) de red (p.e. con WireShark) de una petición de un navegador (p.e. Iceweasel) a un servidor web, veremos que éste le dice al servidor web que acepta el contenido comprimido por gzip o por deflate (es decir, zlib): GET / HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.8) Gecko/20071004 Iceweasel/2.0.0.8 (Debian-2.0.0.8-1) Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/pn g,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive En Firefox, podemos usar el parámetro del about:config (poner en la barra de direcciones http://about:config) y buscar en la caja correspondiente la directiva network.http.acceptencoding para especificar exactamente qué queremos tener para esa entrada de la cabecera, siendo el valor por defecto gzip,deflate. Por su parte, el servidor web Apache 2 es capaz de atender esas peticiones de compresión por medio del módulo mod_deflate. En Debian, el módulo ya viene en el paquete estándar de apache2, para comprobar que tenemos el modulo, tecleamos en una terminal: dpkg -S deflate.load apache2.2-common: /etc/apache2/mods-available/deflate.load Ya viene activado por defecto. Para comprobarlo, utilizamos el comando: a2enmod deflate Module deflate already enabled Ahora tendremos que elegir las opciones de configuración que más nos puedan interesar. Como la compresión de según qué tipos de ficheros con según qué versiones de navegador puede dar problemas, una solución que nos comprime prácticamente todos los ficheros de texto típicos de una página sin crear mayores problemas es usar la directiva AddOutputFilterByType diciéndole que comprima ficheros HTML, CSS, JavaScript y de texto:

Para ellos editamos el fichero de configuración del modulo con: vim /etc/apache2/mods-available/deflate.conf <IfModule mod_deflate.c> # these are known to be safe with MSIE 6 AddOutputFilterByType DEFLATE text/html text/plain text/xml # everything else may cause problems with MSIE 6 AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/x-javascript application/javascript application/ecmascript AddOutputFilterByType DEFLATE application/rss+xml </IfModule> Esta linea sería la que deberíamos añadir (subrayada abajo), pero como vemos en las últimas versiones del modulo, este ya viene bien configurado, con lo que no es necesario hacer modificaciones. AddOutputFilterByType DEFLATE text/html text/plain text/css application/x-javascript Nota.- Nos avisa de que dichas configuraciones deben tener problemas con Microsoft Internet Explorer 6 (como no). Queda a su criterio el activar el modulo o no, por mi parte a Internet Explorer 6, lo pueden empaquetar con un lazo de regalo y enviarlo en un cohete espacial lejos del sistema solar (desde aquí un saludo a los creadores de XBILL).

Tras esto, es conveniente revisar que la sintaxis es correcta con un apache2ctl configtest y reiniciar el servidor para que se use la nueva configuración sin cortar las conexiones existentes al servidor web con un apache2ctl graceful. Tecleamos en una terminal lo siguiente: apache2ctl configtest Syntax OK apache2ctl graceful Tras aplicar estos cambios, la contestación del servidor web a la petición anterior del navegador será ésta, aceptando la compresión y enviando la página comprimida a continuación: HTTP/1.1 200 OK Date: Fri, 23 Nov 2007 16:14:42 GMT Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch7 X-Powered-By: PHP/5.2.0-8+etch7 Expires: Wed, 11 Jan 1984 05:00:00 GMT Last-Modified: Fri, 23 Nov 2007 16:14:43 GMT Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 22266 Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8

Si queremos comprobar el buen funcionamiento de este módulo, podemos usar el wget, versátil herramienta que nos permite descargar documentos desde línea de comandos mediante HTTP y FTP. Por defecto, el wget manda unas cabeceras muy sencillas: GET / HTTP/1.0 User-Agent: Wget/1.10.2 Accept: */* Host: 127.0.0.1:4443 Connection: Keep-Alive Vemos que usa HTTP 1.0 y no indica ningún Accept-Encoding. Sin embargo, podemos usar la opción de línea de comandos --header para modificar las cabeceras y aceptar compresión. Aquí, vemos que el fichero raíz de un servidor web (pagina de prueba de apache) ocupa 177 Bytes : wget --no-check-certificate https://127.0.0.1:4443/ --2013-05-05 11:24:58-- https://127.0.0.1:4443/ Connecting to 127.0.0.1:4443... conectado. WARNING: cannot verify 127.0.0.1's certificate, issued by `/CN=debian-joomla.Home': Self-signed certificate encountered. WARNING: certificate common name `debian-joomla.Home' doesn't match requested host name `127.0.0.1'. Petición HTTP enviada, esperando respuesta... 200 OK Longitud: 177 [text/html] Saving to: ìndex.html' 100%[=================================>] 177 --.-K/s in 0s 2013-05-05 11:24:58 (3,02 MB/s) - ìndex.html' saved [177/177] Si se pide comprimida:únicamente ocupa 144 Bytes wget --no-check-certificate --header="Accept-Encoding:gzip" https://127.0.0.1:4443 --2013-05-05 11:29:55-- https://127.0.0.1:4443/ Connecting to 127.0.0.1:4443... conectado. WARNING: cannot verify 127.0.0.1's certificate, issued by `/CN=debian-joomla.Home': Self-signed certificate encountered. WARNING: certificate common name `debian-joomla.Home' doesn't match requested host name `127.0.0.1'. Petición HTTP enviada, esperando respuesta... 200 OK Longitud: 146 [text/html] Saving to: ìndex.html.1' 100%[========================>] 146 --.-K/s in 0s 2013-05-05 11:29:56 (737 KB/s) - ìndex.html.1' saved [146/146]

Sin embargo, si examinamos este segundo fichero descargado ejecutando el comando file, vemos que no es el fichero HTML que esperábamos, sino un fichero comprimido con gzip: file index.html.1 index.html: gzip compressed data, from Unix Sería necesario descomprimir el fichero para encontrar que tiene el tamaño y el contenido esperado: Renombramos el archivo a su extensión correspondiente de gzip con: mv index.html.1 index.html.1.gz Descomprimimos con: gzip -d index.html.1.gz Listamos el fichero con: ls index.html.1 4,0K -rw-r--r-- 1 txavi txavi 177 may 3 18:05 index.html.1 Vemos que descomprimido pesa sus 177 bytes originales, para finalizar, comprobamos el tipo de fichero file index.html.1 index.html.1: HTML document text Comprimir las páginas web antes de enviarlas supone una gran ventaja en circunstancias de ancho de banda limitado. Sin embargo, no hay que olvidar que el servidor tiene que estar permanentemente comprimiendo ficheros, lo que puede ocasionar que la CPU no dé abasto. Por tanto, hay que tener muy presente, antes de habilitar esta opción, si en situaciones de carga extraordinaria la limitación de nuestro servidor web está en la carga de CPU o en el ancho de banda disponible. Finalmente, comentar que en la página www.http-compression.com podemos leer sobre qué navegadores soportan la compresión de las páginas, que son prácticamente todas las versiones modernas de los navegadores comunes: Firefox, Konqueror, Opera e Internet Explorer. Para una configuración extra, más avanzada y preparada para entornos de producción en algún servidor web público, la siguiente configuración extraída de la pagina http://www.letrasdehercules.com/?p=1360 nos sería de gran ayuda. No la implementaremos en nuestra maquina virtual, pero queda anotada por si al subir la web a un servidor publico se quisiera “afinar” más el modulo: 65

<ifModule mod_deflate.c> # TIPOS DE FICHEROS QUE SE COMPRIMEN AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE text/javascript AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-javascript # NIVEL DE COMPRESIÓN DeflateCompressionLevel 9 # NO USAR COMPRESIÓN EN NAVEGADORES QUE NO LO SOPORTAN BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html # CREAMOS UN LOG DE LAS COMPRESIONES DeflateFilterNote Input instream DeflateFilterNote Output outstream DeflateFilterNote Ratio ratio LogFormat ‘”%r” %{outstream}n/%{instream}n (%{ratio}n%%)’ deflate # NO COMPRIMIMOS IMÁGENES, FICHEROS COMPRIMIDOS Y PDFs SetOutputFilter DEFLATE SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ \ no-gzip dont-vary SetEnvIfNoCase Request_URI \ \.(?:exe|t?gz|zip|bz2|sit|rar)$ \ no-gzip dont-vary SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary </ifModule>

El modulo mod_cache En el capitulo anterior, probando el mod_deflate de Apache, vimos cómo conseguir que Apache comprima los contenidos antes de mandarlos. Sin embargo, parece un despropósito que el servidor web tenga que estar comprimiendo una y otra vez los mismos contenidos. Supone estar forzando al procesador a usar ciclos que pueden sernos necesarios para otra tarea en algo que debería de poder evitarse. Afortunadamente, gracias al módulo mod_cache, podemos conseguir evitar esta sobrecarga inútil para el servidor. En realidad, este módulo tiene su máxima utilidad para configurar Apache como servidor Proxy o como Proxy Inverso (mediante el mod_proxy), ya que gracias a la caché, podemos evitar que Apache vuelva a pedir el mismo contenido al servidor final repetidas veces. Para un servidor normal, no parece que una caché pueda proporcionarnos una gran mejora de rendimiento, incluso aunque cacheemos en memoria. Sin embargo, si lo combinamos con el mod_deflate, sí que podemos conseguir que los documentos servidos se almacenen ya comprimidos en la caché ahorrándonos así un elevado e inútil uso de la CPU causado por la compresión repetidas veces de lo mismo. Apache cachea a través del mod_cache, y proporciona sus servicios a través de otros tres módulos que dependen de él: mod_disk_cache, mod_mem_cache, mod_file_cache. El mod_file_cache es el menos flexible de los tres. Sirve para cachear ficheros concretos en disco o memoria, pero si modificamos alguno de dichos ficheros sólo podremos conseguir que Apache sirva la versión actualizada con un reinicio del servidor. El mod_mem_cache nos permite cachear los ficheros en memoria. Sin embargo, lo que teóricamente podría suponer una gran mejora de rendimiento del servidor, puede quedarse en mucho menos por dos motivos: Por un lado, forzar a Apache a usar una gran cantidad de memoria para cachear los ficheros del sistema puede causar que el sistema se vaya quedando corto de memoria para otras tareas llegando a swapear y causando que el rendimiento caiga en picado. Por otro lado, los sistemas operativos modernos hacen un excelente trabajo cacheando ficheros que se usan frecuentemente, especialmente si hay memoria de sobra. Además, saben perfectamente cuándo el fichero se ha modificado y hay que renovarlo en la caché y saben cuando hay que dejar de cachear porque el sistema se va quedando corto de memoria. ¿Realmente necesitamos que Apache cachée esos mismos ficheros?. El mod_disk_cache va almacenando en un directorio los documentos que se van solicitando, así como sus cabeceras. Si el mod_deflate está activo y hay unos clientes que aceptan compresión y otros que no, se cacheará el documento comprimido y sin comprimir. Por supuesto, no debemos olvidar que la caché del sistema operativo está actuando, así que estos ficheros de caché, si hay memoria suficiente, también serán cacheados en memoria por el kernel. Por tanto, el mecanismo de caché para almacenar el contenido comprimido que parece más conveniente en muchas situaciones es el del mod_disk_cache y en él nos vamos a centrar . 67

En Debian, podemos habilitar el mod_disk_cache y su dependencia, el mod_cache usando el comando a2enmod. a2enmod disk_cache Considering dependency cache for disk_cache: Enabling module cache. Enabling module disk_cache. Run '/etc/init.d/apache2 restart' to activate new configuration! Después de activarlo reiniciamos Apache: service apache2 restart Hay un archivo de configuración para el módulo que se encuentra en la carpeta de los módulos de Apache en, /etc/apache2/mods-available/disk_cache.conf, por defecto lleva los siguientes parámetros, editamos con vim: vim /etc/apache2/mods-available/disk_cache.con <IfModule mod_disk_cache.c> # cache cleaning is done by htcacheclean, which can be configured in # /etc/default/apache2 # # For further information, see the comments in that file, # /usr/share/doc/apache2.2-common/README.Debian, and the htcacheclean(8) # man page. # This path must be the same as the one in /etc/default/apache2 CacheRoot /var/cache/apache2/mod_disk_cache # This will also cache local documents. It usually makes more sense to # put this into the configuration for just one virtual host. #CacheEnable disk / CacheDirLevels 5 CacheDirLength 3 </IfModule> Con la directiva CacheRoot indicamos dónde queremos almacenar los ficheros de caché. Con la directiva #CacheEnable disk / (vemos que está comentada por defecto en Debian) activamos la caché de disco para todos los ficheros (/). Si tenemos varios servidores virtuales, esta directiva deberíamos de ponerla en la configuración del servidor virtual, ya que podemos no querer cachear los contenidos de todos ellos. El mod_disk_cache almacenará los documentos bajo CacheRoot pero usando una jerarquía de directorios un tanto críptica. Para que no se acumulen un gran número de ficheros en el mismo directorio, lo que penaliza severamente el rendimiento en muchos 68

sistemas de ficheros, crea un árbol de directorios de hasta CacheDirLevels (ver archivo de configuración pagina anterior) niveles y hasta con CacheDirLenght caracteres para cada nombre de directorios, no debiendo ser CacheDirLevels*CacheDirLength mayor de 20. Por ejemplo, con CacheDirLevels a 2 y CacheDirLength a 3, tras activar el módulo, si probamos a descargar contenidos con y sin compresión, encontraremos algo similar a esto en el CacheRoot: find /var/cache/apache2/mod_disk_cache/ /var/cache/apache2/mod_disk_cache/ /var/cache/apache2/mod_disk_cache/ReF /var/cache/apache2/mod_disk_cache/ReF/doS /var/cache/apache2/mod_disk_cache/ReF/doS/rODnhKXGMI6ovV@g.header.vary /var/cache/apache2/mod_disk_cache/ReF/doS/rODnhKXGMI6ovV@g.header.vary/O17 /var/cache/apache2/mod_disk_cache/ReF/doS/rODnhKXGMI6ovV@g.header.vary/O17/Br7 /var/cache/apache2/mod_disk_cache/ReF/doS/rODnhKXGMI6ovV@g.header.vary/O17/Br7/qI@hwNC5yYk1CAAQ.data /var/cache/apache2/mod_disk_cache/ReF/doS/rODnhKXGMI6ovV@g.header.vary/O17/Br7/qI@hwNC5yYk1CAAQ.header /var/cache/apache2/mod_disk_cache/ReF/doS/rODnhKXGMI6ovV@g.header /var/cache/apache2/mod_disk_cache/QCD /var/cache/apache2/mod_disk_cache/QCD/rx6 /var/cache/apache2/mod_disk_cache/QCD/rx6/QOskIIubUJNJmygQ.header.vary /var/cache/apache2/mod_disk_cache/QCD/rx6/QOskIIubUJNJmygQ.header.vary/SCw /var/cache/apache2/mod_disk_cache/QCD/rx6/QOskIIubUJNJmygQ.header.vary/SCw/3in /var/cache/apache2/mod_disk_cache/QCD/rx6/QOskIIubUJNJmygQ.header.vary/SCw/3in/PxoVDs1I9YrzsrMw.data /var/cache/apache2/mod_disk_cache/QCD/rx6/QOskIIubUJNJmygQ.header.vary/SCw/3in/PxoVDs1I9YrzsrMw.header /var/cache/apache2/mod_disk_cache/QCD/rx6/QOskIIubUJNJmygQ.header /var/cache/apache2/mod_disk_cache/WV7 /var/cache/apache2/mod_disk_cache/WV7/WLD /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/j3A /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/j3A/Zfi /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/j3A/Zfi/s1vDfLMvhTrcLz3Q.header /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/j3A/Zfi/s1vDfLMvhTrcLz3Q.data /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/2gD /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/2gD/U0F /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/2gD/U0F/0o2XTbizgzSFEtZw.header /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/2gD/U0F/0o2XTbizgzSFEtZw.data /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/y6D /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/y6D/Fls /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/y6D/Fls/02CqmIFDXTYoW8Eg.data /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/y6D/Fls/02CqmIFDXTYoW8Eg.header /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header

Vemos que los directorios tienen como máximo dos niveles y tres caracteres para el nombre: ReF/doS, QCD/rx6, WV7/WLD. Por otro lado, encontramos ficheros .data, que contienen el documento cacheado, y ficheros .header, con las cabeceras que aplican a dicho documento: Vemos (con el comando file) que algunos ficheros de contenido están comprimidos y otros no: file /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/j3A/Zfi/s1vDfLMvhTrcLz3Q.data /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/j3A/Zfi/s1vDfLMvhTrcLz3Q.data: ASCII text file /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/y6D/Fls/02CqmIFDXTYoW8Eg.data /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/y6D/Fls/02CqmIFDXTYoW8Eg.data: gzip compressed data, from Unix

En función de si el documentos se ha solicitado y cacheado comprimido o sin comprimir: cat /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/j3A/Zfi/s1vDfLMvhTrcLz3Q.header

http://www.example.com/style.css?Last-Modified: Mon, 26 Nov 2007 21:40:38 GMT ETag: "1bb8b0-105-d0a98180" Accept-Ranges: bytes Content-Length: 261 Vary: Accept-Encoding Date: Sun, 02 Dec 2007 12:12:51 GMT Expires: Mon, 03 Dec 2007 01:40:04 GMT Content-Type: text/css User-Agent: Wget/1.10.2 Accept: */* Host: www.example.com cat /var/cache/apache2/mod_disk_cache/WV7/WLD/hzVrlCKIU3NsSxGg.header.vary/y6D/Fls/02CqmIFDXTYoW8Eg.header

http://www.example.com/style.css?Last-Modified: Mon, 26 Nov 2007 21:40:38 GMT ETag: "1bb8b0-105-d0a98180" Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Date: Sun, 02 Dec 2007 12:12:45 GMT Expires: Mon, 03 Dec 2007 01:39:58 GMT Content-Type: text/css User-Agent: Wget/1.10.2 Accept: */* Host: www.example.com Accept-Encoding: gzip El mod_disk_cache va limpiando de la caché las entradas que han expirado, pero no gestiona un límite máximo de espacio en disco que se puede usar para la caché. Para evitar que crezca excesivamente, podemos usar la herramienta htcacheclean. Especificamos con -p el directorio de caché y con -l el límite de espacio que puede usar la caché: htcacheclean -v -t -p/var/cache/apache2/mod_disk_cache -l10M Statistics: size limit 10.0M total size was 40.0K, total size now 40.0K total entries was 16, total entries now 16 Lo normal es ejecutarlo periódicamente desde el cron o con la opción -D para que se quede funcionando como un demonio. Con ello logramos contener el tamaño de la caché al valor deseado. 70

El modulo mod_security ModSecurity™ es un firewall de aplicaciones Web embebible que se ejecuta como módulo del servidor web Apache, provee protección contra diversos ataques hacia aplicaciones Web y permite monitorizar tráfico HTTP, así como realizar análisis en tiempo real sin necesidad de hacer cambios a la infraestructura existente. Es un producto desarrollado por Breach Security y está disponible como Software Libre bajo la licencia GNU General Public License, a su vez, se encuentra disponible bajo diversas licencias comerciales. ModSecurity™ es una herramienta para detección y prevención de intrusos para aplicaciones Web. El módulo cuenta con diversas funcionalidades:  Filtrado de Peticiones: los pedidos HTTP entrantes son analizados por el módulo mod_security antes de pasarlos al servidor Web Apache, a su vez, estos pedidos son comparados contra un conjunto de reglas predefinidas para realizar las acciones correspondientes. Para realizar este filtrado se pueden utilizar expresiones regulares, permitiendo que el proceso sea flexible.  Técnicas antievasión: las rutas y los parámetros son normalizados antes del análisis para evitar técnicas de evasión.  Elimina múltiple barras (//)  Elimina directorios referenciados por si mismos (./)  Se trata de igual manera la \ y la / en Windows.  Decodificación de URL  Reemplazo de bytes nulos por espacios (%00)  Comprensión del protocolo HTTP: al comprender el protocolo HTTP, ModSecurity™ puede realizar filtrados específicos y granulares.  Análisis Post Payload: intercepta y analiza el contenido transmitido a través del método POST.  Log de Auditoría: es posible dejar traza de auditoría para un posterior análisis forense.  Filtrado HTTPS: al estar embebido como módulo, tiene acceso a los datos después de que estos hayan sido descifrados.  Verificación de rango de Byte: permite detectar y bloquear shellcodes, limitando el rango de los bytes.  Cinco fases de procesamiento, incluyendo: encabezados del pedido (request headers), cuerpo del pedido (request body), encabezados de respuesta (response headers), cuerpo de respuesta (response body) y almacenamiento en bitácora (logging).  Opciones de transformación por regla.

 Variables transaccionales.  Persistencia de datos (utilizado en seguimientos de direcciones IP, sesiones de aplicación, y usuarios de aplicación).  Soporte para ranking de anomalías y correlación básica de eventos (los contadores pueden ser automáticamente decrementados con el paso del tiempo, las variables pueden expirar).  Soporte para aplicaciones Web e IDS de sesión.  Soporte para XML (parseo, validación, XPath).  Bloqueo de IP Bueno, a primera vista parece otro pequeño monstruo dentro de Apache2, como se ha comentado mod_security es un producto privado, así que no viene cargado ni compilado con Apache2 ni esta en los repositorios de Debian. Lo primero será descargarnos el paquete, comprobamos la última versión en http://www.modsecurity.org/download/ seleccionamos el correspondiente tar/gz para Apache2 y descargamos: Nos situamos en la carpeta de las fuentes del usuario con: cd /usr/src Descargamos el paquete de las fuentes comprimido wget http://www.modsecurity.org/tarball/2.7.3/modsecurity-apache_2.7.3.tar.gz Descomprimimos con: tar zxvf modsecurity-apache_2.7.3.tar.gz Preparamos el entorno de compilación (software necesario) y descargamos unas librerías que le harán falta al modulo: apt-get install libxml2-dev liblua5.1-0 lua5.1 build-essential libxml2-dev libcurl3 libcurl4-openssl-dev apache2-prefork-dev Leyendo lista de paquetes... Hecho Creando árbol de dependencias Leyendo la información de estado... Hecho Se instalarán los siguientes paquetes extras: comerr-dev dpkg-dev g++ g++-4.4 krb5-multidev libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl libapr1-dev libaprutil1-dev libdb4.8-dev libdpkg-perl libexpat1-dev libglib2.0-0 libglib2.0-data libidn11-dev libkrb5-dev libldap2-dev libmysqlclient-dev libmysqlclient16 libpcre3-dev libpcrecpp0 libpq-dev libpq5 libsqlite3-dev libssh2-1 libssh2-1-dev libssl-dev libstdc++6-4.4-dev libtimedate-perl mysql-common pkg-config shared-mime-info uuid-dev zlib1g-dev Paquetes sugeridos: doc-base debian-keyring g++-multilib g++-4.4-multilib gcc-4.4-doc libstdc++6-4.4-dbg krb5-doc libcurl3-dbg db4.8-doc postgresql-doc-8.4 sqlite3-doc libstdc++6-4.4-doc Se instalarán los siguientes paquetes NUEVOS: apache2-prefork-dev build-essential comerr-dev dpkg-dev g++ g++-4.4 krb5-multidev libalgorithm-diff-perl libalgorithm-diffxs-perl libalgorithm-merge-perl libapr1-dev libaprutil1-dev libcurl3 libcurl4-openssl-dev libdb4.8-dev libdpkg-perl libexpat1-dev libglib2.0-0 libglib2.0-data libidn11-dev libkrb5-dev libldap2-dev liblua5.1-0 libmysqlclient-dev libmysqlclient16 libpcre3-dev libpcrecpp0 libpq-dev libpq5 libsqlite3-dev libssh2-1 libssh2-1-dev libssl-dev libstdc++6-4.4-dev libtimedate-perl libxml2-dev lua5.1 mysql-common pkg-config shared-mime-info uuid-dev zlib1g-dev 0 actualizados, 42 se instalarán, 0 para eliminar y 0 no actualizados. Necesito descargar 27,2 MB de archivos. Se utilizarán 85,9 MB de espacio de disco adicional después de esta operación. ¿Desea continuar [S/n]? Pulsamos la tecla enter.

Borramos el tar/gz por no dejar basura con: rm modsecurity-apache_2.7.3.tar.gz Entramos dentro del directorio: cd modsecurity-apache_2.7.3 Configuramos las variables del sistema y comprobamos las dependencias con: ./configure No nos da ningún error, así que vamos a compilar con: make No nos da ningún error,procedemos a instalar. make install Ahora debemos crear el archivo /etc/apache2/mods-available/mod_security2.load con el siguiente contenido (editamos con vim y añadimos) subrayado debajo: vim /etc/apache2/mods-available/mod_security2.load LoadFile /usr/lib/libxml2.so LoadFile /usr/lib/liblua5.1.so.0 LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so “Levantamos” el modulo con: a2enmod mod_security2 a2enmod unique_id Enabling module mod_security2. Enabling module unique_id. Run '/etc/init.d/apache2 restart' to activate new configuration! Copiamos la configuración recomendada de inicio por el fabricante del modulo: cp modsecurity.conf-recommended /etc/apache2/conf.d/modsecurity.conf Ahora ajustaremos la configuración de mod-security para apuntar los archivos de logs a donde queremos. Para ello, editamos el archivo de configuración: vim /etc/apache2/conf.d/modsecurity.conf Buscamos las lineas de abajo (subrayadas) las descomentamos (quitamos la almohadilla) y las dejamos de la siguiente forma (modificando la ruta, como abajo del todo): #SecDebugLog /opt/modsecurity/var/log/debug.log #SecDebugLogLevel 3 SecDebugLog /var/log/apache2/modsec_debug.log SecDebugLogLevel 3 73

Luego buscamos las lineas (tal vez estén descomentadas ya): # SecAuditLogType Serial # SecAuditLog /var/log/modsec_audit.log Las descomentamos y las dejamos de la siguiente forma: SecAuditLogType Serial SecAuditLog /var/log/apache2/modsec_audit.log Guardamos el archivo y salimos. A continuación preparamos los logs que vamos a usar y ponemos los permisos necesarios: touch /var/log/apache2/modsec_debug.log touch /var/log/apache2/modsec_audit.log chown root:root /var/log/apache2/modsec_* chmod 660 /var/log/apache2/modsec_* Ahora podemos decirle a Apache que verifique si todo esta OK en la configuración: apache2ctl configtest Si todo esta OK, veremos un hermoso: Syntax OK Podemos reiniciar Apache2: /etc/init.d/apache2 restart Luego de reiniciar, podemos mirar el errorlog de Apache, para ver si efectivamente cargo el ModSecurity. tail /var/log/apache2/error.log Y deberíamos ver algo similar a … [Sun May 05 12:44:50 2013] [notice] Apache/2.2.16 (Debian) mod_ssl/2.2.16 OpenSSL/0.9.8o configured -- resuming normal operations [Sun May 05 12:46:28 2013] [notice] caught SIGTERM, shutting down [Sun May 05 12:46:30 2013] [notice] Apache/2.2.16 (Debian) mod_ssl/2.2.16 OpenSSL/0.9.8o configured -- resuming normal operations [Sun May 05 21:06:06 2013] [notice] caught SIGTERM, shutting down [Sun May 05 21:06:08 2013] [notice] ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/) configured. [Sun May 05 21:06:08 2013] [notice] ModSecurity: APR compiled version="1.4.2"; loaded version="1.4.2" [Sun May 05 21:06:08 2013] [notice] ModSecurity: PCRE compiled version="8.2 "; loaded version="8.02 2010-03-19" [Sun May 05 21:06:08 2013] [notice] ModSecurity: LIBXML compiled version="2.7.8" [Sun May 05 21:06:09 2013] [notice] Apache/2.2.16 (Debian) mod_ssl/2.2.16 OpenSSL/0.9.8o configured -- resuming normal operations

El modulo mod_pagespeed Mod_pagespeed es un módulo creado por Google para el servidor Apache que optimiza su web antes de servirla, mejorando bastante el rendimiento y la latencia de la misma. Después de dos años de desarrollo, Google le ha quitado el cartel de beta, y esta siendo usado por más de 120.000 webs. Este módulo realiza todo el trabajo de optimización sin necesidad de modificar los archivos de nuestra web (JavaScript, CSS, imágenes…). El fin de esta herramienta es reducir el ancho de banda que gasta su web mejorando los recursos y aplicando prácticas de optimización, como quitar espacios y satos de línea de CSS, JavaScript y HTML y además optimiza las imágenes para que sean menos pesadas sin perder calidad. Puede configurarlo aplicando filtros que afectan a distintos tipos de archivos y optimizan de una forma u otra la web; distinguidos en dos tipos de filtros, los centrales que no alteran para nada la visualización y comportamiento de la web y otros más avanzados que podemos personalizar para optimizar al máximo nuestra web. Esta tecnología esta más que avalada por grandes empresas del sector del hosting como GoDaddy, Edge Cast y DreamHost. Google diseñó el modulo pagespeed como una manera fácil de aplicar prácticas comunes para optimizar y acelerar una página web. Por ejemplo, incluye funciones para optimizar imágenes, javascript, código CSS, HTML y XML. Puede utilizar la configuración por defecto para automatizar la optimización, o personalizar su servidor. Oficialmente Google ha lanzado versiones de mod_pagespeed disponibles para CentOS/Fedora y Debian/Ubuntu. Usted puede descargar la ultima versión directamente de Google. Lógicamente tiene que reiniciar Apache antes de poder utilizar mod_pagespeed, pero es buena idea configurar el módulo primero. El módulo se configura utilizando el archivo pagespeed.conf. El archivo se encontrará en diferentes directorios dependiendo de la versión de Linux: Debian/Ubuntu: /etc/apache2/mods-available CentOS/Fedora: /etc/httpd/conf.d El archivo de configuración del modulo está bien escrito, pero en inglés. Encuentre algunas de las opciones más importantes en la lista de abajo. Para deshabilitar una línea en el archivo, introduzca el símbolo # (almohadilla) al principio de la línea y será como una línea de comentario en Apache.  ModPagespeed on: Puede habilitar o deshabilitar pagespeed con esta línea. Utilice on para habilitar y off para deshabitar.  ModPagespeedDisallow: Utilice esta opción para excluir un directorio o archivo de las optimizaciones de pagespeed. Esto puede ser necesario en el caso de algunos archivos javascript. Ejemplos de uso: ModPagespeedDisallow */archivo1.js - este directivo deshabilita pagespeed para el archivo1.js en cualquier directorio.

ModPagespeedDisallow */directorio1/* - también puede excluir un directorio completo y sus archivos. ModPagespeedDisallow * - puede utilizar este directivo para excluir todos los directorios y archivos y habilitar directorios específicos.  ModPagespeedAllow: Igual a ModPagespeedDisallow, pero con efecto opuesto. Se utiliza para habilitar pagespeed para directorios o archivos específicos. No es necesario usar ModPagespeedAllow al menos que se ha utilizado ModPagespeedDisallow  AddOutputFilterByType MOD_PAGESPEED_OUTPUT_FILTER: El archivo puede contener dos líneas con este directivo, uno para habilitar el procesamiento de HTML y otro para XHTML y XML.  ModPagespeedFileCachePath y ModPagespeedGeneratedFilePrefix: Por defecto estos directivos señalan a /var/mod_pagespeed/cache/ y /var/mod_pagespeed/files/ respectivamente. Estos directorios son utilizado por pagespeed para guardar archivos optimizados. Puede cambiar los directorios, pero deben ser directorios existentes y pueden ser escritos (con derechos de escritura) por Apache ya que el módulo pagespeed no crea los directorios.  ModPagespeedRewriteLevel: Este directivo determina los filtros utilizados por pagespeed. Por defecto no hace falta configurar este directivo si desea utilizar los filtros principales. La opción por defecto es CoreFilters, pero también puede utilizar TestingCoreFilters para habilitar los filtros inestables o beta. Si desea escoger los filtros uno por uno, puede introducir ModPagespeedRewriteLevel PassThrough para habilitar sólo los filtros que prefiere.  ModPagespeedDisableFilters: Esta opción le permite excluir filtros específicos, por ejemplo si ocurren errores debido a un filtro en particular.  ModPagespeedEnableFilters: Esta opción le permite habilitar filtros no incluidos en Core. También se utiliza si decide usar la opción PassThrough para controlar lo filtros utilizados por el módulo pagespeed.  ModPagespeedShardDomain: Es una opción avanzada de pagespeed para distribuir los archivos optimizados por pagespeed entre varios sub-dominios del dominio principal. Por ejemplo, con un dominio principal de ejemplo.com, si se configuran sub-dominios como sub1.ejemplo.com, sub2.ejemplo.com, etc., entonces pagespeed los puede utilizar para distribuir los archivos optimizados. Esto es particularmente efectivo si tiene más de 30 recursos por página. No debe utilizar más de 4 sub-dominios ya que puede ralentizar la página en vez de acelerarla. La sintaxis es ModPagespeedShardDomain dominio_principal, subdominio2 subdominio3, subdominio4. Utilizando ejemplo.com, la línea para utilizar los dos sub-dominios sería ModPagespeedShardDomain ejemplo.com, sub1.ejemplo.com, sub2.ejemplo.com, sub3.ejemplo.com. Los dominios utilizados ya deben estar configurados en su servidor DNS. Debe tener cuidado con esta opción ya que los resultados pueden variar y no todos los javascripts funcionan con esta opción habilitada.

 ModPagespeedJpegRecompressionQuality: Esta opción le permite configurar la calidad de la imagen JPG creada por pagespeed con la opción rewrite_images. Por defecto, esta opción sólo remueve la información de la imagen. Pero se puede configurar para recomprimir sus imágenes JPG con una calidad más pequeña. Por ejemplo, si tiene muchas imágenes sin optimizar, puede usar ModPagespeedJpegRecompressionQuality 70 para reducir el tamaño del archivo de cada uno y acelerar más su página web. Filtros de pagespeed Pagespeed incluye una variedad de filtros. Los filtros designados Core son los filtros principales que se habilitan si utiliza el archivo pagespeed.conf por defecto. Aunque como ya se mencionó puede personalizar esa configuración y utilizar filtros específicos. El siguiente cuadro incluye una breve descripción de cada filtro e indica cuales forman parte de los filtros principales. Filtro

Principal

Descripción

add_head

Sí

Añade un elemento <head> en el documento si no está presente.

combine_heads

Sí

Combina elementos <head> si existe más de uno en el documento.

strip_scripts

Elimina scripts, como javascript para experimentos.

inline_import_to_link

Sí

Elimina @import para CSS del documento y los convierte en etiquetas equivalentes de <link>.

outline_css

Mueve grandes cantidades de comandos CSS a un archivo externo que se puede utilizar en un cache.

outline_javascript

Igual que la opción de CSS, mueve comandos de javascript a archivos externos para utilizar un cache.

move_css_above_scripts

Mueve elementos de CSS encima de las etiquetas <script> en el documento.

move_css_to_head

Mueve los elementos CSS al la parte head del documento.

combine_css

Sí

Combina elementos CSS en un elemento.

rewrite_css

Sí

Remueve espacios y comentarios de los archivos CSS.

rewrite_style_attributes

Cambia los atributos de estilo CSS utilizando el filtro rewrite_css.

_with_url

Sí

Cambia sólo los atributos de estilo CSS que contienen url.

flatten_css_imports

Mueve todos los CSS al documento que se utilizan por medio de un @import.

make_google_analytics_async

Convierte el código de Google Analytics a asincrónico.

rewrite_style_attributes

rewrite_javascript javascript.

Sí

Remueve espacios y comentarios de archivos de

combine_javascript

Combina archivos de javascript en un archivo

inline_css

Sí

Mueve archivos pequeños de CSS al documento HTML.

inline_javascript

Sí

Mueve archivos pequeños de javascript al documento HTML.

local_storage_cache

Mueve recursos inline al almacenamiento HTML5.

insert_ga

Agrega el código de Google Analytics a cada página.

rewrite_images

Sí

Optimiza imágenes, codificando cada uno de nuevo, eliminando pixeles extras, e incluyendo imágenes pequeñas inline en el documento

convert_jpeg_to_progressive

Convierte imágenes jpeg grandes en imágenes progresivos.

convert_png_to_jpeg

Convierte imágenes png o gif a jpeg.

convert_jpeg_to_webp

Convierte imágenes webp a jpeg para navegadores que pueden leerlo.

insert_image_dimensions

Agrega dimensiones a los atributos de la etiqueta img si no lo tiene.

inline_images

Sí

Incluido automáticamente por rewrite_images. Cambia imágenes pequeñas utilizando url de data:.

recompress_images

Sí

Incluido automáticamente por rewrite_images. Vuelve a comprimir las imágenes, eliminando el exceso de los metadatos y convirtiendo archivos gif en png.

resize_images

Sí

Incluido automáticamente por rewrite_images. Cambia el tamaño de imágenes para corresponder a las dimensiones especificadas en la etiqueta img.

inline_preview_images

Utiliza imágenes inline de baja calidad como marcadores de posición que serán reemplazadas con las imágenes originales una vez que la página web sea cargada.

resize_mobile_images

Igual que inline_preview_images pero para navegadores móviles.

remove_comments

Elimina comentarios en archivos HTML, pero no javascript o CSS.

collapse_whitespace

Elimina espacios en archivos HTML sin modificar las etiquetas pre, script,style y textarea.

elide_attributes

Elimina los atributos que no son significativos de acuerdo a la especificación HTML.

extend_cache

Sí

Extiende la vida de cache de todos los recursos mediante la firma de las direcciones URL con un hash de contenido.

sprite_images

Combina imágenes de fondo especificadas en CSS en un sprite

rewrite_domains

Cambia el dominio de recursos no configurados por pagespeed utilizando ModPagespeedMapRewriteDomain y ModPagespeedShardDomain

trim_urls

Acorta los URL al hacerlos relativos al URL de base.

remove_quotes

Elimina las comillas innecesarias en atributos HTML.

add_instrumentation

Agrega un archivo javascript a la página para medir la velocidad.

convert_meta_tags

Sí

Agrega un encabezado de respuesta para cada meta etiqueta con un atributo http-equiv equivalente.

defer_javascript

Retrasa la ejecución de archivos javascript hasta que la página termine de cargar. Esta opción puede acelerar la página web, pero también puede dar resultados extraños en algunos archivos javascript. Asegurase de probarlo de antemano.

lazyload_images

Carga las imágenes cuando son visibles en el navegador. Esta opción no siempre funciona, particularmente con algunos javascript.

Puede encontrar una descripción actualizada, aunque en inglés, de todos los filtros en la página web de Google para pagespeed. En general, si no quiere probar los filtros uno por uno, o configurar pagespeed, puede utilizar las opciones que tiene por defecto con buenos resultados. Solo las opciones más seguras y estables son incluidas entre el grupo de filtros marcados Core o principales. Las opciones por defecto funcionan muy bien para la mayoría de las páginas web y es poco probable que causen errores. Pero puede optimizar la configuración aún más con un poco de tiempo y experimentación. Bueno vamos a descargarlo y a ponerlo en funcionamiento. Para descargar: wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.deb Para instalar (con derechos administrativos): dpkg -i mod-pagespeed-beta_current_i386.deb Seleccionando el paquete mod-pagespeed-beta previamente no seleccionado. (Leyendo la base de datos ... 43383 ficheros o directorios instalados actualmente.) Desempaquetando mod-pagespeed-beta (de mod-pagespeed-beta_current_i386.deb) ... Configurando mod-pagespeed-beta (1.4.26.2-r2759) ... Enabling module pagespeed. Run '/etc/init.d/apache2 restart' to activate new configuration! Reiniciamos Apache con: service apache2 restart La instalación del modulo mod_pagespeed añadirá el repositorio de Google (/etc/apt/sources.list.d/mod-pagespeed.list ) para que el sistema se mantengá automáticamente al día. El archivo de configuración del modulo lo podemos editar con: /etc/apache2/mods-available/vim pagespeed.conf Dejaremos la configuración por defecto.

Instalación de PHP5 Para el buen funcionamiento de Joomla 2.5 es fundamental que el interprete de PHP este en funcionamiento, vamos a instalarlo con: apt-get install php5 Reiniciamos Apache2 con: service apache2 restart Este paquete instala los binarios necesarios y habilita php5 creando en /etc/apache2/modsenabled sendos enlaces php5.load y php5.conf a los respectivos ficheros del mismo nombre en /etc/apache2/mods-available. El contenido de /etc/apache2/mods-available/php5.load es: LoadModule php5_module /usr/lib/apache2/modules/libphp5.so Y el de /etc/apache2/mods-available/php5.conf será como: <IfModule mod_php5.c> <FilesMatch "\.ph(p3?|tml)$"> SetHandler application/x-httpd-php </FilesMatch> <FilesMatch "\.phps$"> SetHandler application/x-httpd-php-source </FilesMatch> # To re-enable php in user directories comment the following lines # (from <IfModule ...> to </IfModule>.) Do NOT set it to On as it # prevents .htaccess files from disabling it. <IfModule mod_userdir.c> <Directory /home/*/public_html> php_admin_value engine Off </Directory> </IfModule> </IfModule> 3. Podemos comprobar el funcionamiento, creando un fichero de nombre info.php, por ejemplo, con el siguiente contenido: vim info.php Luego escribimos: <? phpinfo(); ?> Bastaría ahora con copiarlo al directorio raíz de nuestro sitio web (/var/www/info.php) y escribir la dirección https://127.0.0.1:4443/info.php en un navegador. Si todo es correcto veremos una página con información sobre la configuración php de nuestro sistema. Con esto ya tenemos PHP instalado en el sistema y listo para que Joomla 2.5 use su interprete.

Las opciones y directivas Options, Indexes y FollowSymLinks • ServerName: indica el nombre que se le dará al servidor web. • DocumentRoot: indica el directorio raíz del sitio para el servidor. • DirectoryIndex: indica los ficheros que podrán actuar como página índice del sitio. Es conveniente organizar el sitio web mediante directorios, aunque es posible que Apache pueda acceder a otros que no se encuentran en la jerarquía del sitio que se ha definido, como por ejemplo para la ejecución de un script de una página dinámica. Se suele definir una estructura denominada contenedor para cada uno de los directorios a los que accederá Apache, incluyéndose una para el directorio raíz del sitio del servidor principal. Estas estructuras, se reconocen por una etiqueta de inicio con el formato <Directory nombre_directorio> y otra de fin </Directory>. Dentro de estas estructuras se definen directivas que por lo general, establecen distintos permisos sobre el directorio que tiene asociado. Directiva

Opciones

Options

None All

No establece ninguna opción. Establece todas las opciones. Permite visualizar páginas índice existentes en el Indexes directorio. FollowSymlinks Permite seguir los enlaces simbólicos del directorio. ExecCGI Admite la ejecución de scripts CGI.

AllowOverride None All FileInfo Order

allow,deny deny,allow

Allow

from all from IP from dominio

Deny

Función

from all from IP from dominio

No establece ninguna opción. El servidor no leerá los archivos .htaccess Establece todas las opciones. Permite usar las directivas especificadas en .htaccess Muestra la información de los archivos del directorio. Primero aplicará los permisos de allow y luego los de deny. Primero aplicará los permisos de deny y luego los de allow. Admite cualquier acceso al directorio. Admite cualquier acceso al directorio proveniente de la dirección IP indicada. Admite cualquier acceso al directorio desde el dominio especificado. Deniega cualquier acceso al directorio. Deniega cualquier acceso al directorio proveniente de la dirección IP indicada. Deniega cualquier acceso al directorio desde el dominio especificado.

La configuración de un sencillo servidor web, requerirá modificar la directiva de la sección DocumentRoot, indicando el directorio que ejercerá como ráiz del sitio web. Esta directiva tendrá asociada una estructura contenedora cuyo nombre de directorio coincidirá con el indicado en DocumentRoot. En nuestro caso el fichero a editar es /etc/apache2/sites-available/default-ssl dejándolo tal como se ve a continuación. <IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@localhost DocumentRoot /var/www <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/> Options FollowSymLinks AllowOverride None Order allow,deny allow from 10.0.2.2 RewriteEngine On </Directory>

Los logs de Apache2 Para administrar de manera efectiva un servidor web, es necesario tener registros de la actividad y el rendimiento del servidor así como de cualquier problema que haya podido ocurrir durante su operación. El servidor Apache ofrece capacidades muy amplias de registro de este tipo de información. Aquí explicamos cómo configurar esas capacidades de registro, y cómo comprender qué información contienen los ficheros de registro. Advertencia de seguridad Registro de Errores (Error Log) Registro de Acceso (Access Log) Rotación de los ficheros de registro Ficheros de registro redireccionados (Piped Logs) Hosts Virtuales Otros ficheros de registro Advertencia de seguridad Cualquiera que tenga permisos de escritura sobre el directorio en el que Apache esté escribiendo un archivo de registro puede con casi toda seguridad tener acceso al identificador de usuario con el que se inició el servidor, normalmente root. NO le de a nadie permisos de escritura sobre el directorio en que se almacenan los ficheros de registro sin tener en cuenta las consecuencias. Además, los ficheros de registro pueden contener información suministrada directamente por el cliente, sin sustituir. Es posible por tanto que clientes con malas intenciones inserten caracteres de control en los ficheros de registro. Por ello es necesario tener cuidado cuando se procesan los ficheros de registro originales. Registro de Errores (Error Log) El registro de errores del servidor, cuyo nombre y ubicación se especifica en la directiva ErrorLog, es el más importante de todos los registros. Apache enviará cualquier información de diagnóstico y registrará cualquier error que encuentre al procesar peticiones al archivo de registro seleccionado. Es el primer lugar donde tiene que mirar cuando surja un problema al iniciar el servidor o durante su operación normal, porque con frecuencia encontrará en él información detallada de qué ha ido mal y cómo solucionar el problema. El registro de errores se escribe normalmente en un fichero (cuyo nombre suele ser error_log en sistemas Unix y error.log en Windows y OS/2). En sistemas Unix también es posible hacer que el servidor envíe los mensajes de error al syslog o pasarlos a un programa. El formato del registro de errores es relativamente libre y descriptivo. No obstante, hay cierta información que se incluye en casi todas las entradas de un registro de errores. Por ejemplo, este es un mensaje típico. [Wed Oct 11 14:32:52 2012] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test

El primer elemento de la entrada es la fecha y la hora del mensaje. El segundo elemento indica la gravedad del error que se ha producido. La directiva LogLevel se usa para controlar los tipos de errores que se envían al registro de errores según su gravedad. La tercera parte contiene la dirección IP del cliente que generó el error. Después de la dirección IP está el mensaje de error propiamente dicho, que en este caso indica que el servidor ha sido configurado para denegar el acceso a ese cliente. El servidor reporta también la ruta en el sistema de ficheros (en vez de la ruta en el servidor web) del documento solicitado. En el registro de errores puede aparecer una amplia variedad de mensajes diferentes. La mayoría tienen un aspecto similar al del ejemplo de arriba. El registro de errores también contiene mensaje de depuración de scripts CGI. Cualquier información escrita en el stderr por un script CGI se copiará directamente en el registro de errores. El registro de errores no se puede personalizar añadiendo o quitando información. Sin embargo, las entradas del registro de errores que se refieren a determinadas peticiones tienen sus correspondientes entradas en el registro de acceso. El ejemplo de arriba se corresponde con una entrada en el registro de acceso que tendrá un código de estado 403. Como es posible personalizar el registro de acceso, puede obtener más información sobre los errores que se producen usando ese registro también. Si hace pruebas, suele ser de utilidad monitorizar de forma continua el registro de errores para comprobar si ocurre algún problema. En sistemas Unix, puede hacer esto usando, tail “mira” las últimas lineas del archivo error_log, con la opción -f se produce una mirada en vivo, no se lase de la terminal y se esta a la espera de cambios (como un modo depuración): tail -f error_log Registro de Acceso (Access Log) El servidor almacena en el registro de acceso información sobre todas las peticiones que procesa. La ubicación del fichero de registro y el contenido que se registra se pueden modificar con la directiva CustomLog. Puede usar la directiva LogFormat para simplificar la selección de los contenidos que quiere que se incluyan en los registros. Esta sección explica como configurar el servidor para que registre la información que usted considere oportuno en el registro de acceso. Por supuesto, almacenar información en el registro de acceso es solamente el principio en la gestión de los registros. El siguiente paso es analizar la información que contienen para producir estadísticas que le resulten de utilidad. Diferentes versiones de Apache han usado otros módulos y directivas para controlar la información que se almacena en el registro de acceso, incluyendo mod_log_referer, mod_log_agent, y la directiva TransferLog. Ahora la directiva CustomLog asume toda la funcionalidad que antes estaba repartida. El formato del registro de acceso es altamente configurable. El formato se especifica usando una cadena de caracteres de formato similar a las de printf(1) en lenguaje C. Hay algunos ejemplos en las siguientes secciones. Si quiere una lista completa de los posibles contenidos que se pueden incluir, consulte la documentación sobre las cadenas de caracteres de formato del mod_log_config.

Formato Común de Registro (Common Log Format) Una configuración típica del registro de acceso podría tener un aspecto similar a este. LogFormat "%h %l %u %t \"%r\" %>s %b" common CustomLog logs/access_log common Con esto se define el apodo (nickname) common y se le lo asocia con un determinado formato. El formato consiste en una serie de directivas con tantos por ciento, cada una de las cuales le dice al servidor que registre una determinada información en particular. El formato también puede incluir caracteres literales, que se copiarán directamente en el registro. Si usa el carácter comillas (") debe anteponerle una barra invertida para evitar que sea interpretado como el final la cadena de caracteres a registrar. El formato que especifique también puede contener los caracteres de control especiales "\n" para salto de línea y "\t" para tabulador. La directiva CustomLog crea un nuevo fichero de registro usando el apodo definido. El nombre del fichero de registro de acceso se asume que es relativo al valor especificado en ServerRoot a no ser que empiece por una barra (/). La configuración de arriba escribirá las entradas en el registro con el formato conocido como Formato Común de Registro (CLF). Este formato estándar lo pueden generar muchos servidores web diferentes y lo pueden leer muchos de los programas que analizan registros. Las entradas de un fichero de registro que respetan ese formato común tienen una apariencia parecida es esta: 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 Cada una de las partes de la entrada se explican a continuación. 127.0.0.1 (%h) Es la dirección IP del cliente (host remoto) que hizo la petición al servidor. Si la directiva HostnameLookups tiene valor On, el servidor intentará determinar el nombre del host y registrar ese nombre en lugar de la dirección IP. Sin embargo, no se recomienda que use esta configuración porque puede ralentizar significativamente las operaciones del servidor. En su lugar, es mejor usar un programa que realice esta tarea posteriormente sobre el registro, por ejemplo logresolve. Las direcciones IP que se registren no son necesariamente las direcciones de las máquinas de los usuarios finales. Si existe un servidor proxy entre el usuario final y el servidor, la dirección que se registra es la del proxy. Un "guión" significa que la información que debería ir en ese lugar no está disponible. En este caso, esa información es la identidad RFC 1413 del cliente determinada por identidad en la máquina del cliente. Esta información es muy poco fiable y no debería ser usada nunca excepto con clientes que estén sometidos a controles muy estrictos en redes internas. Apache ni siquiera intenta recoger esa información a menos que la directiva IdentityCheck tenga valor On.

frank Este es el identificador de usuario de la persona que solicita el documento determinado por la autentificación HTTP. Normalmente ese mismo valor se pasa a los scripts CGI con la variable de entorno REMOTE_USER. Si el código de estado de la petición (ver abajo) es 401, entonces no debe confiar en la veracidad de ese dato porque el usuario no ha sido aún autentificado. Si el documento no está protegido por contraseña, se mostrará un guión "-" en esta entrada. [10/Oct/2000:13:55:36 -0700] (%t) La hora a la que el servidor recibió la petición. El formato es: [día/mes/año:hora:minuto:segundo zona_horaria] day = 2*digit month = 3*letter year = 4*digit hour = 2*digit minute = 2*digit second = 2*digit zone = (`+' | `-') 4*digit Es posible mostrar la hora de otra manera especificando %{format} en el formato a usar en el registro, donde format se sustituye como se haría al usar strftime de la librería estándar de C. "GET /apache_pb.gif HTTP/1.0" (\"%r\") La línea de la petición del cliente se muestra entre dobles comillas. La línea de petición contiene mucha información de utilidad. Primero, el método usado por el cliente es GET. Segundo, el cliente ha hecho una petición al recurso /apache_pb.gif, y tercero, el cliente uso el protocolo HTTP/1.0. También es posible registrar una o más partes de la línea de petición independientemente. Por ejemplo, el formato "%m %U%q %H" registrará el método, ruta, cadena de consulta y protocolo, teniendo exactamente el mismo resultado que "%r". 200 Es el código de estado que el servidor envía de vuelta al cliente. Esta información es muy valiosa, porque revela si la petición fue respondida con éxito por el servidor (los códigos que empiezan por 2), una redirección (los códigos que empiezan por 3), un error provocado por el cliente (los códigos que empiezan por 4), o un error en el servidor (los códigos que empiezan por 5). La lista completa de códigos de estado posibles puede consultarle en la especificación de HTTP (RFC2616 sección 10). 2326 La última entrada indica el tamaño del objeto retornado por el cliente, no incluidas las cabeceras de respuesta. Si no se respondió con ningún contenido al cliente, este valor mostrará valor "-". Para registrar "0" en ese caso, use %B en su lugar.

Cómo usar varios registros de acceso Para crear varios registros de acceso solamente tiene que especificar varias directivas CustomLog en el fichero de configuración. Por ejemplo, las siguientes directivas crearán tres registros de acceso. El primero contendrá la información básica en Formato Común de Registro, mientras que el segundo y el tercero contendrán contendrán la información de los "referer" y de los navegadores usados. Las dos últimas líneas CustomLog muestran cómo reproducir el comportamiento de las directivas ReferLog y AgentLog. LogFormat "%h %l %u %t \"%r\" %>s %b" common CustomLog logs/access_log common CustomLog logs/referer_log "%{Referer}i -> %U" CustomLog logs/agent_log "%{User-agent}i" Este ejemplo también muestra que no es necesario definir un "apodo" con la directiva LogFormat. En lugar de esto, el formato de registro puede especificarse directamente en la directiva CustomLog. Registro Condicional Algunas veces es más conveniente excluir determinadas entradas del registro de acceso en función de las características de la petición del cliente. Puede hacer esto fácilmente con la ayuda de variables de entorno. Primero, debe especificar una variable de entorno que indique que la petición cumple determinadas condiciones. Esto se hace normalmente con SetEnvIf. Entonces puede usar la claúsula env= de la directiva CustomLog para incluir o excluir peticiones en las que esté presente la variable de entorno. Algunos ejemplos: # Marcar las peticiones de la interfaz loop-back SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog # Marcar las peticiones del fichero robots.txt SetEnvIf Request_URI "^/robots\.txt$" dontlog # Registrar lo que quede CustomLog logs/access_log common env=!dontlog Como otro ejemplo, considere registrar las peticiones de los angloparlantes en un fichero de registro, y el resto de peticiones en un fichero de registro diferente. SetEnvIf Accept-Language "en" english CustomLog logs/english_log common env=english CustomLog logs/non_english_log common env=!english 87

Aunque acabamos de mostar que el registro condicional es muy potente y flexible, no es la única manera de controlar los contenidos de los ficheros de registro. Los ficheros de registro son más útiles cuanta más información sobre la actividad del servidor contengan. A menudo es más fácil eliminar las peticiones que no le interesen procesando posteriormente los ficheros de registro originales. Rotación de los ficheros de registro Incluso en un servidor con una actividad moderada, la cantidad de información almacenada en los ficheros de registro es muy grande. El registro de acceso crece normalmente en 1MB por cada 10.000 peticiones. Por lo tanto, es necesario rotar periódicamente los registros moviendo o borrando su contenido. Esto no se puede hacer con el servidor funcionando, porque Apache continuará escribiendo en el antiguo registro mientras que el archivo esté abierto. En lugar de esto, el servidor debe ser reiniciado después de mover o borrar los ficheros de registro para que se abran nuevos ficheros de registro. Usando un reinicio graceful, se le puede indicar al servidor que abra nuevos ficheros de registro sin perder ninguna petición siendo servida o en espera de algún cliente. Sin embargo, para hacer esto, el servidor debe continuar escribiendo en los ficheros de registro antiguos mientras termina de servir esas peticiones. Por lo tanto, es preciso esperar algún tiempo después del reinicio antes de realizar ninguna operación sobre los antiguos ficheros de registro. Una situación típica que simplemente rota los registros y comprime los registros antiguos para ahorrar espacio es: mv access_log access_log.old mv error_log error_log.old apachectl graceful sleep 600 gzip access_log.old error_log.old Otra manera de realizar la rotación de los registros es usando ficheros de registro redireccionados (piped logs) de la forma en que se explica en la siguiente sección. Ficheros de registro redireccionados (Piped Logs) Apache es capaz de escribir la información del registro de acceso y errores mediante una redirección a otro proceso, en lugar de directamente a un fichero. Esta capacidad incrementa de forma muy importante la flexibilidad de registro, sin añadir código al servidor principal. Para escribir registros a una redirección, simplemente reemplace el nombre de fichero por el carácter "|", seguido por el nombre del ejecutable que debería aceptar las entradas de registro por su canal de entrada estándar. Apache iniciará el proceso de registro redireccionado cuando se inicie el servidor, y lo reiniciará si se produce algún

error irrecuperable durante su ejecución. (Esta última funcionalidad es la que hace que se llame a esta técnica "registro redireccionado fiable".) Los procesos de registros son engendrados por el proceso padre de Apache, y heredan el identificador de usuario de ese proceso. Esto significa que los programas a los que se redireccionan los registros se ejecutan normalmente como root. Es por ello que es muy importante que los programas sean simples y seguros. Un uso importante de los registros redireccionados es permitir la rotación de los registros sin tener que reiniciar el servidor. El servidor Apache HTTP incluye un programa simple llamado rotatelogs con este propósito. Por ejemplo para rotar los registros cada 24 horas, puede usar: CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common Tenga en cuenta que las comillas se usan para abarcar el comando entero que será invocado por la redirección. Aunque estos ejemplos son para el registro de acceso, la misma técnica se puede usar para el registro de errores. Otro programa para la rotación de los registros mucho más flexible llamado cronolog está disponible en un sitio web externo. Como ocurre con el registro condicional, la redirección de registros es una herramienta muy potente, pero no deben ser usados si hay disponible una solución más simple de procesado posterior de los registros fuera de línea. Hosts Virtuales Cuando se está ejecutando un servidor con muchos hosts virtuales, hay varias formas de abordar el asunto de los registros. Primero, es posible usar los registros de la misma manera que se usarían si hubiera solamente un host en el servidor. Simplemente poniendo las directivas que tienen que ver con los registros fuera de las secciones <VirtualHost> en el contexto del servidor principal, puede almacenar toda la información de todas las peticiones en los mismos registros de acceso y errores. Esta técnica no permite una recolección fácil de las estadísticas individuales de cada uno de los hosts virtuales. Si una directiva CustomLog o ErrorLog se pone dentro una sección <VirtualHost>, todas las peticiones de ese host virtual se registrarán solamente en el fichero especificado. Las peticiones de cualquier host virtual que no tenga directivas de registro específicas para él se registrarán en los registros del servidor principal. Esta técnica es muy útil si usa un pequeño número de hosts virtuales, pero si usa un gran número de ellos, puede ser complicado de gestionar. Además, puede a menudo provocar problemas con descriptores de fichero insuficientes.

Para el registro de acceso, se puede llegar a un buen equilibrio. Añadiendo información del host virtual al formato de registro, es posible registrar las operaciones de todos los hosts en un único registro, y posteriormente dividir el fichero con todos los registros en ficheros individualizados. Por ejemplo, considere las siguientes directivas. LogFormat "%v %l %u %t \"%r\" %>s %b" comonvhost CustomLog logs/access_log comonvhost El %v se usa para registrar el nombre del host virtual que está sirviendo la petición. Puede usar un programa como split-logfile para procesar posteriormente el registro de acceso y dividirlo en ficheros independientes para cada host virtual. Otros ficheros de registro Al iniciar, Apache guarda el identificador del proceso padre del servidor en el fichero logs/httpd.pid. Puede modificar el nombre de este fichero con la directiva PidFile. El identificador del proceso puede usarlo el administrador para reiniciar y finalizar el demonio (daemon) mediante el envío de señales al proceso padre; en Windows, use la opción de línea de comandos -k en su lugar. Para más información al respecto, consulte la documentación sobre parar y reiniciar Apache. Registro de actividad de scripts (Script Log) Para ayudar a la detección de errores, la directiva ScriptLog permite guardar la entrada y la salida de los scripts CGI. Esta directiva solamente debería usarla para hacer pruebas - no en servidores en producción. Puede encontrar más información al respecto en la documentación de mod_cgi. Registro de actividad de Rewrite (Rewrite Log) Cuando use las potentes y complejas funcionalidades de mod_rewrite, será casi siempre necesario usar la direcitiva RewriteLog para ayudar a la detección de errores. Este fichero de registro produce un análisis detallado de cómo actúa este módulo sobre las peticiones. El nivel de detalle del registro se controla con la directiva RewriteLogLevel.

Hasta ahora, nos hemos comunicado con el servidor a través de un tunel ssh, esto es muy cómodo para lanzar ordenes en la linea de comandos, pero no para la transmisión de archivos, para ello vamos a implementar un servidor FTP seguro.

Instalación de Proftpd con SSL Proftpd es un servidor ftp muy modular y con un fichero de configuración del estilo del de apache. Para realizar una instalación simple de proftpd en Debian podemos seguir los siguientes pasos, en una terminal, con derechos administrativos: apt-get install proftpd (Cuando pregunta si ejecutar proftpd desde inetd o independientemente -standalone- elegir independiente) Para deshabilitar el acceso anónimo hemos de editar el fichero de configuración, que se encuentra en /etc/proftpd/proftpd.conf y comentar (si no lo están ya) las siguientes líneas del bloque <Anonymous ~ftp>: #<Anonymous ~ftp> #User ftp #Group nogroup #UserAlias anonymous ftp #RequireValidShell off #DisplayLogin welcome.msg #DisplayChdir .message #<Directory *> #<Limit WRITE> # DenyAll #</Limit> #</Directory> #</Anonymous> Ahora vamos a asegurarnos que los usuarios quedan “encerrados” en sus directorios Home y no pueden “escalar” directorios. Vamos a la linea 33 descomentamos la siguiente directiva (lo dejamos como esta abajo). # Use this to jail all users in their homes DefaultRoot ~ Vamos a la linea 37 y la descomentamos dejándola así. # Users require a valid shell listed in /etc/shells to login. # Use this directive to release that constrain. RequireValidShell off

Para una configuración correcta del modo NAT, vamos a tener que hacer unos ajustes que han sido muy problemáticos debido a estar trabajando en un entorno virtual. En la linea 46 descomentamos y dejamos como queda a continuación. # In some cases you have to specify passive ports range to by-pass # firewall limitations. Ephemeral ports can be used for that, but # feel free to use a more narrow range. PassivePorts 50000 50003 Se han dejado reservados 4 puertos alternativos para la transferencia de ciertos comandos del protocolo ftp (como ls) junto a la subida y bajada de archivos del servidor. Debido ha esto se han tenido que añadir 4 reglas de redirección NAT más, además de las redirección hecha previamente del puerto 2121 del anfitrión al puerto 21 de la maquina virtual. Con la maquina apagada y en la terminal del anfitrión tecleamos: VBoxManage modifyvm "Debian 6.0 - Joomla" --natpf1 "ftppro, tcp,,50000,,50000" VBoxManage modifyvm "Debian 6.0 - Joomla" --natpf1 "ftp, tcp,,50001,,50001" VBoxManage modifyvm "Debian 6.0 - Joomla" --natpf1 "ftp2, tcp,,50002,,50002" VBoxManage modifyvm "Debian 6.0 - Joomla" --natpf1 "ftp3, tcp,,50003,,50003" Volvemos a iniciar la maquina y volvemos a editar el archivo /etc/proftpd/proftpd.conf. Vamos a la linea 51, descomentamos y dejamos como sigue: # If your host was NATted, this option is useful in order to # allow passive tranfers to work. You have to use your public # address and opening the passive ports used on your firewall as well. MasqueradeAddress 127.0.0.1 Con estas breves configuraciones cualquier cliente ftp como, Filezilla o GFTP debería bastarnos para trabajar. Vamos a descargarnos e instalarnos gFTP en la maquina anfitrión. Para sistemas Linux (tecleamos en una terminal) apt-get install gftp Aparecerá en el menú de aplicaciones, sección internet. Para sistemas Microsoft, descargaremos Filezilla: Ir a la pagina, descargar e instalar. http://sourceforge.net/projects/filezilla/files/FileZilla_Client/3.7.0/FileZilla_3.7.0_win32setup.exe/download

El funcionamiento es muy sencillo como se puede ver en la siguiente imagen:

De izquierda a derecha se arrastran archivos o carpetas para “subir” o “bajar” del servidor. Nos será de gran ayuda cuando estemos trabajando con Joomla 2.5 Nos queda un detalle, como queremos que el usuario joomla entre solo a la carpeta /var/www que es donde va a estar situado joomla, vamos cambiarle su directorio home por defecto del sistema, editamos con vim el fichero de usuarios: vim /etc/passwd Nos encontraremos esto: joomla:x:1000:1000:joomla,,,:/home/joomla:/bin/bash Debemos dejarlo como se ha indicado abajo: joomla:x:1000:33:joomla:/var/www:/bin/bash Y le añadimos una mascara de creación de archivos y directorios (en una terminal): umask 002 Con esto lo que conseguimos es que cada vez que entremos por ftp con el usuario de Joomla, establezcamos su directorio de trabajo en /var/www. y el grupo por defecto al que pertenece es el de apache www-data. 93

Proseguimos haciendo el servicio seguro, ahora, que hemos comprobado que funciona el ftp en modo pasivo, vamos a encriptar las comunicaciones entre el anfitrión y la maquina virtual Para utilizar transferencia segura (encriptada), usamos TLS (sucesor de SSL), vamos a la linea 129 del archivo /etc/proftpd/proftpd.conf y descomentamos lo siguiente (lo dejamos como esta abajo): # This is used for FTPS connections # Include /etc/proftpd/tls.conf Para que el servidor solo escuche en la ip 10.0.2.15, añadimos la siguiente linea al final del fichero: # We want the main server instance to listen on a specific IP DefaultAddress 10.0.2.15 Salimos y guardamos, ahora vamos a editar el archivo /etc/proftpd/tls.conf, lo editamos con vim: vim /etc/proftpd/tls.conf Descomentamos las lineas10,11 y 12 TLSEngine TLSLog TLSProtocol

on /var/log/proftpd/tls.log SSLv23

Vamos a generar el certificado de clave publica y la llave de la clave privada con este comando (como indica los comentarios del archivo de configuración). # # Server SSL certificate. You can generate a self-signed certificate using # a command like: # # openssl req -x509 -newkey rsa:1024 \ # -keyout /etc/ssl/private/proftpd.key -out /etc/ssl/certs/proftpd.crt \ # -nodes -days 365 # # The proftpd.key file must be readable by root only. The other file can be # readable by anyone. # # chmod 0600 /etc/ssl/private/proftpd.key # chmod 0640 /etc/ssl/private/proftpd.key # openssl req -x509 -newkey rsa:1024 -keyout /etc/ssl/private/proftpd.key -out /etc/ssl/certs/proftpd.crt -nodes -days 3650

Generating a 1024 bit RSA private key .........++++++ ............++++++ writing new private key to '/etc/ssl/private/proftpd.key' ----You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----Country Name (2 letter code) [AU]: SP State or Province Name (full name) [Some-State]:Valencia Locality Name (eg, city) []:Valencia Organization Name (eg, company) [Internet Widgits Pty Ltd]:Debian-Joomla Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:127.0.0.1 Email Address []: Contestamos a las preguntas para generar nuestra certificado y clave privada. Luego, como se indica en el comentario del archivo cambiaremos los permisos de la clave privada con: chmod 0600 /etc/ssl/private/proftpd.key En la linea 27 y 28 descomentamos, dejándolo como se ve a continuación. TLSRSACertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem TLSRSACertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key Seguimos en la linea 37 añadimos: TLSOptions

NoSessionReuseRequired

En la linea 46 descomentamos la verificación del cliente con: # Authenticate clients that want to use FTP over TLS? # TLSVerifyClient off En la linea 50, obligamos al servidor a no servir conexiones sin cifrar. # Are clients required to use FTP over TLS when talking to this server? # TLSRequired on Una vez guardados los cambios debería reiniciarse el servicio ejecutando el comando: /etc/init.d/proftpd restart 95

Configuración de Filezilla como cliente de FTP. Para poder comunicarnos con la carpeta publica del servidor por protocolo FTP seguro, instalaremos un cliente de FTP libre como es Filezilla: Instalación en clientes Linux apt-get install filezilla Instalación en clientes Microsoft Descargamos de la pagina del proyecto Filezilla. http://sourceforge.net/projects/filezilla/files/FileZilla_Client/3.7.0.1/FileZilla_3.7.0.1_win3 2-setup.exe/ Una vez descargado, ejecutamos el binario e instalamos. Para conectarnos seguimos:

Clic arriba a la izquierda en Abrir el gestor de Sitios

Clic en Nuevo sitio.

Rellenamos los campos como se ve en la imagen. Contraseña de joomla=Aa12345678 En el desplegable Server Type, seleccionamos FTPES – FTP sobre TLS/SSL explícito

Clic en conectar.

Nos aparece el certificado. Le damos clic en siempre confiar en el certificado.

Clic en Aceptar.

Ya esta configurado nuestro cliente para las transferencias seguras ftp.

Instalación de Mysql y Phpmyadmin MySQL es un servidor de bases de datos muy usado en el mundo Linux, especialmente en la programación de bases de datos para la Web. Para el funcionamiento de Joomla 2.5 necesitaremos una base de datos, esta va a ser mysql. Para gestionarla a través de un interface web, utilizaremos el paquete Phpmyadmin. Primero, instalar los paquetes cliente y servidor, en una terminal con derechos administrativos tecleamos: apt-get install mysql-client mysql-server (Si se pide una contraseña para el usuario root de MySQL, dejarla en blanco, de momento) Nota: El fichero de configuración del servidor mysql se encuentra en /etc/mysql/my.cnf y las bases de datos que vienen en el paquete, en el directorio /var/lib/mysql. Comprobamos si se está ejecutando el servidor con cualquiera de los siguientes procedimientos:  Viendo si se está ejecutando el demonio de mysql ps axu | grep mysql (Debería aparecer alguna línea con /usr/sbin/mysqld o similar)  Obteniendo el estado de su ejecución: service mysql status /usr/bin/mysqladmin Ver 8.42 Distrib 5.1.66, for debian-linux-gnu on i486 Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Server version Protocol version Connection UNIX socket Uptime:

5.1.66-0+squeeze1 10 Localhost via UNIX socket /var/run/mysqld/mysqld.sock 1 min 29 sec

Threads: 1 Questions: 318 Slow queries: 0 Opens: 287 Flush tables: 2 Open tables: 23 Queries per second avg: 3.573.  Inspeccionando el puerto de escucha del servidor: netstat -atunp | grep mysql tcp

0 127.0.0.1:3306

0.0.0.0:*

LISTEN

2742/mysqld

100

Vamos a ponerle una contraseña a root. El usuario root puede acceder al cliente de linea de comandos mysql tecleando el siguiente comando y sin introducir contraseña por lo que es conveniente ponerle una: mysql -u root Nota:para salir del interprete de mysql usar el comando quit; con punto y coma al final. Para ello usaremos el comando mysqladmin que viene con el paquete cliente de mysql de la siguiente forma: mysqladmin -u root password nuestracontraseña Nota: También se puede hacer con la sentencia update de mysql. A partir de ahora se deberá usar el comando “mysql -u root -p” para acceder al cliente mysql como root y con contraseña. En nuestro caso: mysqladmin -u root password Aa12345678 Para personalizar un poco la configuración. En el fichero de configuración de mysql, /etc/mysql/my.cnf, podemos realizar algunos ajustes, editamos con vim: vim /etc/mysql/my.cnf 

El puerto en que escucha por defecto es el 3306 y no es conveniente cambiarlo. Corresponde a la siguiente línea de dicho fichero:

port = 3306  Podemos indicar que los mensajes de error aparezcan en castellano con la siguiente línea de la sección [mysqld] del fichero de configuración: language = /usr/share/mysql/spanish  Activar la escucha en todos los interfaces. Por motivos de seguridad, el paquete Debian activa la red únicamente para la interfaz de loopback (127.0.0.1) usando la entrada bind-address de dicho fichero: bind-address = 127.0.0.1 Si queremos permitir conexiones desde otras máquinas, hay que hacer que el servidor escuche en la interface de red. Ello se realiza comentando la línea anterior, con lo cual se escuchará por todos los interfaces, o añadiendo o sustituyendo la IP por la IP del servidor (o por 0.0.0.0, si se desea escuchar por todas las interfaces). En nuestro caso lo dejaremos así: bind-address = 10.0.2.15 Después de guardar los cambios reiniciamos el servidor, ejecutando el comando: /etc/init.d/mysql restart Por último, con la maquina virtual apagada, añadiremos una regla NAT para el puerto 3306. En una terminal tecleamos: VBoxManage modifyvm "Debian 6.0 - Joomla" --natpf1 "msyql,tcp,,3306,,3306"

101

Ahora vamos a crear una base de datos para Joomla 2.5, en la terminal de nuestra maquina virtual tecleamos: mysqladmin -u root -p create joomla Enter password: ponemos nuestro password de root Aa12345678 Necesitamos que el usuario joomla (del sistema) pueda acceder desde cualquier sitio y con todos los permisos. Para ello accedemos a mysql como usuario root con: mysql -u root -p Una vez dentro del entorno de mysql en el que tendremos un prompt que empieza por mysql> Enter password: ponemos nuestro password de root Aa12345678 Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 36 Server version: 5.1.66-0+squeeze1 (Debian) Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> Empezamos con estas sentencias que terminan en ; (punto y coma) en las que daremos esos permisos al usuario Joomla. Donde pone password (primera sentencia), no poner la palabra password, sino la contraseña que elijamos. mysql> GRANT ALL ON joomla.* TO joomla@'%' IDENTIFIED BY 'password';

En nuestro caso: mysql> GRANT ALL ON joomla* TO joomla@'%' IDENTIFIED BY 'Aa12345678';

Para darle todo tipo de privilegios, tecleamos: mysql> FLUSH PRIVILEGES; Nota:para salir del interprete de mysql usar el comando quit; con punto y coma al final.

102

Instalación de phpmyadmin. Finalmente vamos a instalar el paquete phpmyadmin para administrar las bases de datos de MySQL a través de un entorno web. Para ello en una terminal, ejecute: apt-get install phpmyadmin (Si pregunta por el servidor web a configurar automáticamente elija apache2. De igual forma, si se pregunta si se desea configurar la base de datos para phpmyadmin con dbconfig-common responder que No) Nota: En el fichero de configuración del paquete de phpmyadmin (/etc/phpmyadmin/config.inc.php) se pueden personalizar algunos parámetros: tipo de autentificación, usuario que se conectará a la base de datos y contraseña, etc. Una vez instalado phpmyadmin,vamos a hacer que funcione dentro de nuestro sitio seguro, para que la administración web de php se haga con los certificados del servidor apache2 a través del puerto 4443. Copiamos la configuración de /etc/phpmyadmin/apache.conf a nuestro sitio seguro con: cat /etc/phpmyadmin/apache.conf >> /etc/apache2/sites-enabled/default-ssl Luego borramos el enlace simbólico que ha dejado la instalación de phpmyadmin en Apache con: rm /etc/apache2/conf.d/phpmyadmin.conf Comprobamos la sintaxis con: apachectl configtest Reiniciamos Apache2 con: service apache2 restart Y si todo ha ido bien deberíamos poder entrar al phpmyadmin a través del link: https://127.0.0.1:4443/phpmyadmin/

103

Joomla 2.5 ¿Que es un CMS? CMS son las siglas de Content Management System, que se traduce directamente al español como Sistema Gestor de Contenidos. Como su propio nombre indica, es un sistema que nos permite gestionar contenidos. En líneas generales, un CMS permitiría administrar contenidos en un medio digital y para el caso particular que nos ocupa, un CMS permitiría gestionar los contenidos de una web. Dicho de otra forma, un CMS es una herramienta que permite a un editor crear, clasificar y publicar cualquier tipo de información en una página web. Generalmente los CMS trabajan contra una base de datos, de modo que el editor simplemente actualiza una base de datos, incluyendo nueva información o editando la existente. Imaginemos un periódico o cualquier otra página medianamente compleja. Principalmente aquellas que tienen que ser actualizadas diariamente o varias veces por día, donde además, las personas que editan la información no tienen conocimientos de informática. A estos redactores se les tiene que facilitar el trabajo mediante una herramienta que les permita subir informaciones a la web y clasificarlas para que aparezcan en el lugar correcto. Por supuesto que estas personas no deben preocuparse con el código de la página ni las particularidades de programación de la plataforma donde esté alojada la web. Ellos sólo deben concentrarse en escribir las noticias, o cualquier tipo de contenidos y luego subirlas a la página por un sistema intuitivo y rápido. Una vez publicadas y clasificadas, las informaciones deben aparecer en la página web automáticamente, en los lugares donde haya decidido el editor. Una herramienta CMS generalmente contendrá una interfaz basada en formularios, a los que habitualmente se accede con el navegador, donde se pueden dar de alta los contenidos fácilmente. Esos contenidos luego aparecerán en la página en los lugares donde se ha indicado al darlos de alta. Por lo tanto, un CMS estará compuesto de dos partes, un back y un front, siendo el back la parte donde los administradores publican las informaciones y el front la parte donde los visitantes visualizan las mismas. Clasificación de CMS En el mundo de los CMS hay cientos de posibilidades y de variantes, ya sea por sus funcionalidades, casos de uso o por las tecnologías que se utilizan para crear las infraestructuras para la publicación y visualización de contenidos. Una primera clasificación de CMS se podría dar entre sistemas propietarios y no propietarios. Digamos que un sistema propietario es el primer ejemplo que podemos encontrar de CMS, puesto que son herramientas creadas a medida para actualizar una página web. Cualquier página que se haya creado e incluya un sistema para actualizarla a través de formularios, o cualquier interfaz que facilite la publicación, es un sistema CMS. En los inicios de la web no existían sistemas CMS, comerciales o gratuitos, para gestionar los contenidos de los sitios, por lo que se tenía que programar un sistema para poder

104

actualizarla rápidamente, propio para esa web. Por otra parte, tenemos los CMS no propietarios. Son sistemas que se han desarrollado por empresas o instituciones y que se disponibilizan para que sean utilizados para la creación de cualquier tipo de página web. Estos CMS no propietarios son, en muchos de los casos, completamente configurables, es decir, que sirven para producir cualquier tipo de web con cualquier clasificación de secciones y contenidos. Nota: Otras clasificaciones señalan que los sistemas propietarios son aquellos que son comerciales, dicho de otra forma, creados por una empresa y que se ofrecen para su uso en webs, sujetos a la compra de una licencia. En ese modo de entender la clasificación de CMS, los gestores de contenidos de pago serían sistemas propietarios, aunque no se hayan hecho a medida para una web específica, sino que sirvan para para desarrollar cualquier tipo de proyecto. Los sistemas propietarios, en este caso, estarían en contraposición con los sistemas CMS gratuitos. Otra manera de clasificar los CMS sería en función de la utilización de los mismos, ya sea para crear una web empresarial, una publicación como revista o periódico, un blog, un sistema e e-learning, un Wiki, una tienda, foro... Ejemplos de CMS Pdemos dar algunos ejemplos de CMS populares que existen en el mercado. Vignette: http://www.vignette.com/es Es un sistema CMS comercial, que dicho sea de paso, debe ser bastante caro. Es importante comentarlo por ser el primer sistema CMS comercial que apareció en el mercado. Drupal: http://drupal.org/ Uno de los CMS más populares, en este caso gratuito y open source. Creado en PHP y con posibilidad de utilizar varias bases de datos distintas, por defecto MySQL. Mambo: http://www.mamboserver.com/ Un sistema CMS libre y gratuito, creado en PHP. Joomla!: http://www.joomla.org/ Es un CMS de código libre, también creado en PHP. Surge como una mejora o ampliación de Mambo . Wordpress: http://wordpress.org/ El CMS para la creación de blogs por excelencia. El más utilizado y el mejor valorado, también creado en PHP y gratuito. OsCommerce: http://www.oscommerce.com/ El sistema gestor de contenidos de código libre, para la creación de una tienda más conocido y utilizado.

105

Descarga e instalación de Joomla 2.5 En una terminal logeados con el usuario joomla, situados en el directorio /var/www, comprobamos antes que estamos donde toca con: pwd /var/www Procedemos a la descarga con el siguiente comando: wget http://joomlacode.org/gf/download/frsrelease/17787/77434/Joomla_2.5.8-Spanish-Pack_Completo.tar.gz --2013-05-11 12:20:54-- http://joomlacode.org/gf/download/frsrelease/17787/77434/Joomla_2.5.8-Spanish-Pack_Completo.tar.gz Resolviendo joomlacode.org... 206.123.111.164 Connecting to joomlacode.org|206.123.111.164|:80... conectado. Petición HTTP enviada, esperando respuesta... 302 Found Localización: http://downloads.joomlacode.org/frsrelease/7/7/4/77434/Joomla_2.5.8-Spanish-Pack_Completo.tar.gz [siguiendo] --2013-05-11 12:20:54-- http://downloads.joomlacode.org/frsrelease/7/7/4/77434/Joomla_2.5.8-Spanish-Pack_Completo.tar.gz Resolviendo downloads.joomlacode.org... 206.123.111.167 Connecting to downloads.joomlacode.org|206.123.111.167|:80... conectado. Petición HTTP enviada, esperando respuesta... 200 OK Longitud: 5574050 (5,3M) [application/x-gzip] Saving to: `Joomla_2.5.8-Spanish-Pack_Completo.tar.gz' 100%[=================================================================>] 5.574.050

860K/s in 7,6s

2013-05-11 12:21:03 (718 KB/s) - `Joomla_2.5.8-Spanish-Pack_Completo.tar.gz' saved [5574050/5574050]

Descomprimimos con: tar xfz Joomla_2.5.8-Spanish-Pack_Completo.tar.gz Borramos el archivo comprimido porque ya no lo volveremos a necesitar: rm -f Joomla_2.5.8-Spanish-Pack_Completo.tar.gz Volvemos a establecer los permisos para la carpeta de Joomla, con este comando lo que hacemos es darle permisos totales al usuario propietario y a su grupo, en este caso al usuario joomla y al grupo www-data respectivamente. chmod -R 775 /var/www/ Antes de continuar con la instalación vamos a ajustar algunos parámetros de php, editamos su archivo de configuración con: sudo vim /etc/php5/apache2/php.ini En la linea 135 descomentamos estas dos lineas por seguridad: output_buffering Default Value: Off

106

En la linea 262 comentamos con un punto y coma delante: ;output_buffering = 4096 En la linea de 882, cambiamos el valor de para las subidas de archivos a Joomla, esta en un máximo de 2 Megas, lo cambiamos a 10 Megas. upload_max_filesize = 2M upload_max_filesize = 10M Reiniciamos Apache con: sudo service apache2 restart Salimos de la terminal y abrimos un navegador en el anfitrión el siguiente link: https://127.0.0.1:4443/installation/

Elegimos español, clic en siguiente (arriba a la derecha).

107

Comprobaciones previas. ¡Todo en verde!. ¡Adelante!. Clic en siguiente.

Aceptamos la licencia. Clic en siguiente.

108

Configuramos las opciones de Mysql. Tipo de Base de Datos: Mysql Nombre del host: localhost Usuario: joomla (minúsculas) Contraseña: Aa12345678 Nombre de la base de datos: joomla

Habilitar la capa FTP: No. Clic en siguiente. 109

Nombre del sitio: Debian-Joomla Email: Usuario del Administrador: admin Contraseña del Administrador: Aa12345678

Clic en Eliminar la carpeta de instalación.

110

Nos dice que la carpeta de instalación de eliminó correctamente. Clic en Administrador (arriba a la derecha).

Nombre de usuario: admin Contraseña: Aa12345678

111

Entramos en el panel de Administración. Vemos abajo a la izquierda como existe una actualización que debemos hacer.

Vamos a realizar la actualización. Clic en la actualización.

112

Clic en Instalar la actualización.

Vemos que la actualización se ha realizado correctamente.

113

Ya tenemos Joomla perfectamente instalado. Ahora nos queda comprender como se estructura Joomla 2.5. Para esta función, la de entender como funciona Joomla, sus plantillas, las categorías, los artículos, las extensiones, los módulos, los menús y la infinidad de funcionalidades que posee esta aplicación le remitimos al libro escrito por Hagen Graf - Joomla! 2.5 Guía para Principiantes (se adjunta a este documento en un archivo pdf de nombre j25es.pdf). Como su autor indica en el mismo texto “Este libro Puede ser leído gratuitamente, bien directamente en formato HTML en nuestro sitio web, o bien descargándolo en formato PDF”. En él encontrará todo lo necesario para entender y poder comenzar con la tarea que es el diseño web, nosotros desde aquí hemos preparado la maquina que le hará trabajar con Joomla de una manera segura y rápida.

114

Instalar la Maquina Virtual Una vez instalado VM VirtualBox, lo único que tiene que hacer es “Agregar” la maquina que hemos preparado. Para hacer esto: 1º Descomprima el archivo “Debian 6.0 – Joomla.zip” que hemos adjuntado a esta documentación. 2º Copie la carpeta “Debian 6.0 – Joomla” al lugar que prefiera de su disco duro. Recuerde donde. 3º Abra la aplicación VM VirtualBox , sitúese en el menú superior

115

4º En el menú “Máquina”, haga clic en “Agregar”

5º Se abrirá un menú de navegación de archivos, navegue hasta la carpeta que ha generado al descomprimir el archivo en el paso 1º. Seleccione el icono “Azul”. Clic en “Abrir”.

116

6º Ya tiene la maquina virtual cargada dentro de VM VirtualBox, clic en “Iniciar”

7º Una vez arrancado el sistema, aparecerá la linea de login, no es necesario que se logee, ya que Joomla ya funciona . Por si tiene curiosidad: user: joomla, contraseña: Aa12345678

117

Fecha del proceso fin de instalación V.1

12 de mayo de 2013

Versión de VM VirtualBox

4.2.12 - r84980

Versión Debian y arquitectura cpu

6.0.7 - I386

Versión Joomla

2.5.11

Usuario Joomla

admin

Contraseña

Aa12345678

Para entrar a Joomla (administración)

https://127.0.0.1:4443/administrator

Para entrar a Phpmyadmin

https://127.0.0.1:4443/phpmyadmin

Usuario Phpmyadmin

joomla

Contraseña phpmyadmin

Aa12345678

Para entrar por FTP (seguro): Desde un cliente FTP (Filezilla, ftp, etc) Ir a la pagina 96 para más detalles.

Puerto 2121 Dirección ip: 127.0.0.1 user: joomlaPassword: Aa12345678

Para entrar por ssh: Desde un cliente ssh (Putty, openssh, etc)

Puerto 2222 ssh -p 2222 joomla@127.0.0.1

DATOS DE LA MAQUINA VIRTUAL Usuario Administrador

root

Contraseña Administrador

Aa12345678

Usuario joomla

joomla

Contraeña joomla

Aa12345678

Direccion Ip Maquina Virtual: Usar el comando ⟶

sudo cualesmiip - 10.0.2.15

Posibles problemas con la ip: Usar el comando ⟶

sudo reiniciamac

Apagar la maquina: Usar el comando ⟶

sudo apagame

118

Bibliografía La realización de este proyecto ha estado supeditada a la siguiente documentación y sitios web: – El blog de Vicente Navarro Jover. Artículos sobre Linux, Debian, Windows, navegadores, WordPress, Apache, software libre y lo que se presente www.vicente-navarro.com – The water cooler of UbuntuForums, a place to discuss pretty much anything (within reason) www.ubuntuforums.org/ – Well-organized collection of free Joomla! Templates. www.joomla24.com – The Official ProFTPD web site. ProFTPD is a high-performance, extremely configurable, and most of all a secure FTP server. www.proftpd.org – La Biblia del Servidor Apache2 (Anaya Multimedia). Mohammed J. Kabir – Joomla! 2.5 - Cree Y Administre Sus Sitios Web. Didier Mazier – Joomla! 2.5 Guía para Principiantes. Hagen Graf – ModSecurity is an open source web application firewall. Working embedded in the web server, or standalone as a network appliance. www.modsecurity.org – Evaluates the performance of web pages and get suggestions on how to improve them. https://developers.google.com/speed/pagespeed/ – www.forums.virtualbox.org/ – Discussion ranging from desktop use to hardware and programming. www.forums.debian.net/

119

Anotaciones para la versión 2 de la maquina. Después de trabajar con la maquina virtual han quedado temas pendientes y mejorables para una segunda versión de la misma: – Durante la realización de este proyecto se ha publicado la versión Debian 7.0 estable, sería conveniente en una nueva versión de la maquina actualizarla. – Se han aplicado todo tipo de servicios seguros, queda pendiente la aplicación de una capa SSL al servidor de mysql, para que todas las consultas entre Joomla y la base de datos sean encriptadas. – El usuario Joomla y su directorio de trabajo /var/www deberían ponerse en otra partición, para que este usuario no tuviera derechos de escritura sobre la partición raíz del sistema. Siguiendo este hilo se debería “enjaular” al usuario en su directorio por defecto. – En esta versión de la maquina no se ha podido cargar mas plantillas en Joomla. – Igualmente no se han cargado más extensiones en Joomla. – Tampoco se han cargado más módulos en Joomla. – No se han repasado los modulo cargados de Apache, se deberían revisar para desactivar los que no fuesen necesarios. – Se deberían dar instrucciones claras de como cambiar las contraseñas por defecto. – Siguiendo este hilo, sería interesante desarrollar una pagina web dentro del servidor donde se pudieran administrar cosas sencillas, como las citadas contraseñas. – Se debería estudiar la posibilidad de tener los certificados de los servicios firmados por alguna entidad certificadora de los navegadores, al menos ver precios.

120