Servidor Web Apache

En esta serie de artículos, que hoy empezamos e iremos enriqueciendo, vamos a hablaros sobre este magnífico servidor web, con solera y mucha documentación, y soportado por cualquier distribución GNU/Linux que se precie. Cómo sabéis nosotros solemos trabajar con servidores Debian based, o bien openSUSE. Yo que soy el que controla de Debian, y comienzo el artículo haré referencia a esta distribución, pero como siempre, tened en cuenta que todos los comandos son los mismos independientemente de la distro que uséis en vuestro servidor, lo único que cambiará son las rutas de los diferentes archivos de configuración, y el usuario bajo el que corre el servicio httpd, apache2.

Virtual Host

En la ruta:

 /etc/apache2/sites-available

tenéis o iréis teniendo los diferentes archivos de configuración de los hosts virtuales, para que lo entendáis rápidamente, deberíamos tener uno por cada dominio alojado en nuestro sitio, incluso por cada subdominio, eso ya según gustos.

Son ficheros de texto que suelen, es opcional, llevar extensión, o en Linux terminación, de archivo .conf como la mayoría de ficheros de configuración.

En las distros Debian suelen venir estos dos por defecto:

default-ssl y default

Yo no los suelo utilizar, y creo uno para cada proyecto / dominio.

Por ejemplo si quisiéramos configurar un nuevo virtual host en nuestro VPS, para un dominio digamos cursosprogramacionweb.com, un posible fichero de configuración para el sitio podría ser este:

<VirtualHost *:80>
 ServerAdmin webmaster@localhost
 ServerName www.cursosprogramacionweb.com
 ServerAlias cursosprogramacionweb.com
 DocumentRoot /var/www/dominios/cursosprogramacionweb.com/www
<Directory /var/www/dominios/cursosprogramacionweb.com/www/>
 Options -Indexes FollowSymLinks MultiViews
 AllowOverride All
 Order allow,deny
 allow from all
 </Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
# Possible values include: debug, info, notice, warn, error, crit, alert, emerg.
 LogLevel warn
 CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Podría llamarse perfectamente cursosprogramacionweb.com.conf, y lo podéis generar copiando, pegando y modificando/personalizando el código anterior, con la orden nano o con vuestro editor preferido:

nano /etc/apache2/sites-available/cursosprogramacionweb.com.conf

Una vez creado el VirtualHost lo habilitamos con a2enmod

Además de los ficheros de configuración de la ruta que os hemos comentado para sistemas Debian:

/etc/apache2/sites-available

existen dos comandos relacionados,
1) el que permite habilitar un sitio es a2ensite (apache2 enable site) cuya sintaxis es esta:

a2ensite <nombredelfichero.conf>

Para el ejemplo con el que estamos jugando sería ejecutar este comando:

a2ensite cursosprogramacionweb.com.conf

2) y el que permite deshabilitarlo,a2dissite (apache2 disable site) cuya sintaxis es esta:

a2dissite <nombredelfichero.conf>

Para el ejemplo con el que estamos jugando sería ejecutar este comando:

a2dissite cursosprogramacionweb.com.conf

Y como siempre tras cualquier cambio, reiniciáis el servicio, o bien para estos comando recargamos la configuración:

service apache2 reload|restart

Así pues si decidimos crear el virtual host definido en el archivo cursosprogramacionweb.com.conf, lo habilitamos y reseteamos el servicio web.
Para leer más:

Proyecto de ejemplo

Por ejemplo, hoy me dispongo a montar un proyectito para probar un gestor de anuncios clasificados (osclass), es la primera vez que uso este CMS, así que junto a vosotros voy a crearme un fichero llamado:

 osclass.conf

(en la carpeta ya mencionada /etc/apache2/sites-available) y su contenido será este:

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        ServerName www.traspasoobrador.com
        ServerAlias traspasoobrador.com
        DocumentRoot /var/www/dominios/traspaso/osclass/www

        <Directory /var/www/dominios/traspaso/osclass/www/>
                Options -Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Se puede mejorar mucho, por ejemplo la directiva AllowOverride All hay que mejorarla, no me gusta dejar el valor All, pero no conozco mucho este CMS y de momento dejaré All, ya iré afinando, así que de momento podéis intentar reventarnos por ahí 😉

En el VirtualHost se aprecia una ruta del sistema de archivos, ahí es donde voy a ubicar los contenidos del CMS.

/var/www/dominios/traspaso/osclass/www/

Además me gusta que cada dominio tenga un usuario Linux, y que este usuario, junto con el usuario / grupo bajo el que trabaja Apache se hagan cargo del directorio en cuestión.

Directivas importantes de un Virtual Host

Normalmente hay que fijarse en las directivas:

  1. ServerName es el fqdn (el nombre completo) por el que responde este VirtualHost concreto.
  2. ServerAlias: es la forma en la que me gusta que si no incluyen las www en el navegador, también se despache este VirtualHost
  3. DocumentRoot: es una carpeta, que debe existir, y cuyo propietario, a mi personalmente me gusta diferenciar por dominio, de ahí que después en el laboratorio práctico demos de alta un usuario Linux, y grupo (www-data en Debian) estén correctamente configurados.

Y después para cada directorio, normalmente para el raíz que acabamos de definir con DocumentRoot, se establecen unas opciones:

Options -Indexes FollowSymLinks MultiViews 

evita que se muestren los archivos y carpetas de una url del servidor que no contenga un archivo por defecto (index.html, index.php, default.aspx).

AllowOverride All

es importante que leáis acerca de esta directiva, aquí está establecida a “All” en plan “perezoso”, para que básicamente si colocáis un .htaccess en alguna carpeta descendiente de la raíz DocumentRoot se respete.
Si no sabéis que es eso de un fichero .htaccess no sufráis, ya lo sabréis, o si sois un@s ansias haced un poquito de RTFM 😉

Añadir usuario linux para la web

Para añadir el usuario Linux, que sea propietario de la carpeta raíz DocumentRoot del sitio utilizamos el comando useradd, lo preferimos a la versión interactiva adduser, ya que conseguimos más control sobre lo que se hace, y lo mejor de todo se puede reutilizar en scripts para acciones masivas (dar de alta 30 dominios nuevos):

useradd -d /var/www/vhosts/traspaso/osclass -m -G www-data -s /bin/bash osclass

Descripción:

-d, --home-dir DIR_PERSONAL   directorio personal de la nueva cuenta
-m, --create-home             crea el directorio personal del usuario
-G, --groups GRUPOS           lista de grupos suplementarios de la nueva cuenta
-s, --shell CONSOLA consola de acceso de la nueva cuenta
osclass es el nombre de usuario que queremos añadir

Ya tenéis más pistas para poder reventarnos 😉

A continuación le ponemos una clave mediante el comando passwd:

passwd osclass
Introduzca la nueva contraseña de UNIX: 
Vuelva a escribir la nueva contraseña de UNIX: 
passwd: contraseña actualizada correctamente

Podemos comprobar que todo va bien conectando vía telnet, no, es broma, vía ssh:

ssh osclass@traspasoobrador.com -p #####

Las almohadillas son el puerto donde tenéis escuchando ssh, espero que no tengáis SSH en el puerto por defecto de lo contrario, si es un sitio público cambiar el puerto de SSH.

De hecho a partir de ahora, para que no rompamos permisos deberíamos trabajar con este usuario que es dueño y señor de su directorio.

Suplantar al usuario osclass

Recordad que para suplantar un usuario, nuestro usuario osclass, usaremos el comando su, si no queremos salir de la sesión ssh actual, o abriremos otra consola con el ssh osclass@… comentado hace dos párrafos.

su osclass

Como se aprecia en el VirtualHost la carpeta final /var/www/dominios/cursosprogramacionweb.com/www (donde irá ubicada la web) no coincide con la del usuario recién creado. Tiene la subcarpeta adicional www, ya que no mola nada que queden expuestos ficheros como:

ls -la
-rw-r--r-- 1 classos classos 220 dic 30 2012 .bash_logout
-rw-r--r-- 1 classos classos 3392 dic 30 2012 .bashrc
-rw-r--r-- 1 classos classos 675 dic 30 2012 .profile

Carpeta para el proyecto web

A continuación hacemos la carpeta para alojar el CMS:

mkdir www

En esa carpeta descomprimimos el CMS que podemos descargar en ZIP desde la página oficial osclass.org.

Como en todo proyecto e instalación de CMS, daremos de alta un usuario de base de datos y durante el proceso de instalación se lo proporcionaremos.

Este paso lo hemos descrito por ejemplo en el artículo donde os explicamos el nacimiento de sospedia.net y si necesitáis más información para realizar un setup rápido del entorno lamp también tenéis disponible este tutorial.

Como en toda instalación, una vez configurado el VirtualHost hace falta habilitar el sitio, para ello disponemos del comando a2ensite:

a2ensite osclass.conf 
Enabling site osclass.conf.
To activate the new configuration, you need to run:
 service apache2 reload

Como el propio comando indica, debemos recargar la configuración de apache mediante el comando:

service apache2 reload

Instalación de osclass.org

Ahora en un navegador cargamos la url y comenzamos la instalación:

Comenzamos la instalación pinchando en el botón ‘Install‘ y BOOOM !!!

oc-content/uploads -> ha de ser "escribible"

oc-content/downloads -> lo mismo

oc-content/languages -> también

Aunque la ayuda del programa de instalación, nos sugiere dar estos permisos para todos (chmod a## a=all):

Requirements help:

  • uploads folder has to be writable, i.e.: chmod a+w

Problemas con los permisos osclass.org

Vamos a intentar primero dárselos solo al grupo sobre el que trabaja apache, para ello primero vamos a hacer un chown recursivo por si se rompió algún permiso, y después tiramos de chmod y establecemos permisos para el grupo. Estando en la carpeta:

/var/www/vhosts/traspaso/osclass/

Lanzamos estos comandos:

chown -R osclass:www-data www/
chmod -R g+w www/

Y probamos a seguir pinchando en el “Try again“:

osclass proceso de instalación

osclass proceso de instalación

Y podemos comprobar, al menos de momento, que habiendo dado permiso de escritura sólo al grupo, parece que nuestro servidor cumple los requisitos:

osclass - habiendo dado permiso de escritura sólo al grupo, parece que nuestro servidor cumple los requisitos

osclass – habiendo dado permiso de escritura sólo al grupo, parece que nuestro servidor cumple los requisitos

Continuamos presionando el botón ‘Run the install‘.

Base de datos

Nos aparece la típica pantalla para introducir las credenciales de la base de datos. Las introducimos.
Os recomiendo utilizar un prefijo para las tablas distinto del sugerido, ya que oc_ en el caso de que nos veamos comprometidos es un prefijo que todo intruso conocerá, no por como dicen los “vende humos” os permita tener en la misma base de datos varias instancias diferentes del CMS.
Rellenamos todos los campos al gusto y continuamos.

Además según veo en el caso de no haber previsto el usuario / clave y base de datos, si conocemos el usuario root de MySQL o MariaDB nos deja crearla en este momento.

Si no sabéis como dar de alta un usuario para la base de datos MySQL o MariaDB, podéis seguir este pequeño “howto”. Si tenéis instalado phpMyadmin en vuestro servidor podéis ver este videotutorial, si no recuerdas como se crea un usuario y una base de datos usando este panel. Por cierto, si usas phpMyAdmin deberías adoptar alguna medida de seguridad como la descrita en este artículo.

Resto de información osclass.org

En la siguiente pantalla se pide información de acceso al CMS, a su backend, así como el título, email y país / municipio donde queremos operar con nuestros anuncios clasificados.

osclass - evitar utilizar el usuario "admin" por defecto, por el mismo comentario que los prefijos de las tablas

osclass – evitar utilizar el usuario “admin” o el usuario por defecto que os ofrezca cualquier CMS

Como siempre, evitar utilizar el usuario “admin” por defecto, por el mismo comentario que los prefijos de las tablas, cualquiera que quiera intentar reventaros el CMS lo tiene más fácil, que no imposible.

Como veis podemos reducir nuestro nicho de clasificados a nivel País / Ciudad / Municipio

Una vez le demos al botón ‘Next’, mensaje graciosete de los programadores:

Osclass has been installed. Were you expecting more steps? Sorry to disappoint you

Y ya lo tenemos.
Procedemos a probarlo dándole al botón ‘”Finish and go to the administration panel”‘

osclass - entrando por primera vez al dashboard

osclass – entrando por primera vez al dashboard

Cambio del idioma osclass.org

Lo primero para los quisquillosos suele ser el cambio de idioma del panel. Para ello desde Settings / Languages, añadimos. Pero además si queréis que todo sea automático podéis desde la pestaña “Connect” vincular vuestra instalación con vuestro usuario en osclass.org.

osclass - conectar con el market

osclass – conectar con el market

Si hacéis esta conexión, solo queda localizar es_ES, descargarlo y activarlo:

osclass - descargar idioma y activarlo desde el market

osclass – descargar idioma y activarlo desde el market

Y finalmente, activarlo o comprobar que lo está tanto en el frontend como en el backend:

osclass - activar el idioma tanto en el frontend como en el backend

osclass – activar el idioma tanto en el frontend como en el backend

Si intentáis deshabilitar Inglés:

en_US can't be disabled because it's the default language

Pero podemos establecer Español como idioma por defecto para ello “Settings / General“. Al mismo tiempo podemos establecer la moneda a EUR. Especificar que día empieza la semana. Establecer los formatos de fecha y hora. Y muchas cosas más. A mi personalmente me gusta activar las actualizaciones automáticas para idiomas y plugins.

Con esto ya se debería ver la parte pública (front-end) en nuestro idioma, para que también se vea en Español la parte privada (back-end) debéis cerrar la sesión del panel y volverla a iniciar.

Algunas configuraciones iniciales osclass.org

Una vez lo tenemos, conviene rápidamente que activemos desde “Anuncios / Configuración” todas las restricciones que consideremos necesarias:

  • Sólo los usuarios registrados pueden publicar anuncios
  • Poned un tiempo de espera en segundos para el siguiente anuncio, para poner un poco más difícil el tema SPAM
  • Los usuarios deben validar sus anuncios
  • No es necesario que los usuarios registrados validen sus anuncios (a mi no me gusta dejarla marcada)
  • Recuerda que primero debes configurar reCAPTCHA.
  • Notificar al administrador cuando se añade un anuncio
  • En el Aviso de caducidad a mi me gusta poner algo, 5, 2 días, cada uno lo que considere oportuno

Bots y SPAM osclass.org

Un paso que no se nos debe pasar es conseguir una key tanto de:

  • https://akismet.com/wordpress/ (https://en.support.wordpress.com/api-keys/)
  • https://www.google.com/recaptcha/admin#list

Una vez las tengamos iremos a Configuración / Spam y Bots y procederemos a su configuración.

Pero esto lo seguiremos viendo, de momento esto es todo por hoy, espero que os haya gustado, que veáis el potencial de este CMS que os presentamos, y por supuesto que os sirva en vuestros futuros desarrollos.

Se me olvidaba … si te gustó comparte en tus redes sociales! Y si tienes algún problema pregunta!

See you soon!!!

2 comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.