En este documento veremos el proceso y comandos básicos para instalar servicios en un sistema operativo Ubuntu.

Partiremos de un Ubuntu Server al cual accederemos vía SSH.

Tecnologías a implementar

SERVER – HOST

En la primera fase prepararemos el sistema para acceso remoto con seguridad baja. En la segunda fase securizaremos el servidor.

Servicios y herramientas:

• SSH
• Apache2
• PHP
• MySQL
• FTP
• CMD o PuTTY para conexión SSH
• Workbench
• VS Code vía SSH
• FileZilla cliente

1. Conexión SSH

Primero comprobamos si SSH está instalado:

dpkg -l | grep openssh-server

Si aparece openssh-server, está instalado. Si no:

sudo apt install ssh

Una vez instalado, desde Windows o PuTTY:

ssh usuario@ipdelservidor

2. Instalación de Apache2

Instalamos Apache:

sudo apt install apache2

Esto permitirá responder a peticiones HTTP por el puerto 80.

Si la máquina usa IP dinámica, consulta la IP con:

ifconfig

(Instalar net-tools si no lo tienes: sudo apt install net-tools)

Al acceder desde un navegador a la IP del servidor, deberías ver la página por defecto de Apache.

La carpeta web se encuentra en:

/var/www/html

Aquí podrás crear tus documentos HTML.

3. Instalación de MySQL Server

Instalamos MySQL:

sudo apt install mysql-server

Ejecutamos script de configuración:

mysql_secure_installation

Las preguntas:

1. Set root password? → Y
2. Remove anonymous users? → Y
3. Disallow root login remotely? → Y
4. Remove test database? → Y
5. Reload privilege tables now? → Y

Reinicia el servicio:

sudo systemctl restart mysql

Acceso:

sudo mysql -u root -p

3.1 Conexión remota a MySQL

Debemos modificar el archivo mysqld.cnf:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Busca:

bind-address = 127.0.0.1

Cámbialo por:

0.0.0.0

(Así permitimos conexiones remotas.)

Políticas de contraseñas MySQL

Valores: LOW = 0, MEDIUM = 1, STRONG = 2.

Ver configuración actual:

SHOW VARIABLES LIKE 'validate_password%';

Cambiar política:

SET GLOBAL validate_password.policy=LOW;

También puedes personalizar los requisitos:

SET GLOBAL validate_password.length = 6;
SET GLOBAL validate_password.number_count = 0;

Según queramos podemos cambiar el valor por LOW, MEDIUM o STRONG
Ejemplos de contraseñas:

LOW:
12345678
password

MEDIUM
Estudiante123@
Codificador NINZA$100
demoPass#00

Esta es la recomendada, por defecto solicita

• La contraseña debe tener al menos 8 caracteres.
• El recuento de mayúsculas y minúsculas es 1 (al menos 1 letra en minúscula y 1 letra enmayúscula)
• El recuento de números es 1
• El número mínimo de caracteres especiales es 1

Otra forma de cambiar la politica de contraseñas sería:

mysql>SET GLOBAL validate_password.policy=0;
mysql>SET GLOBAL validate_password.policy=1;
mysql>SET GLOBAL validate_password.policy=2;

Tambien podemos personalizar los requisitos de cada una, ejemplo:

mysql>SET GLOBAL validate_password.length = 6;
mysql>SET GLOBAL validate_password.number_count = 0;

Ahora que las reglas para una contraseña válida están claras, puedes crear un usuario con
una contraseña válida

3.2 Creación de usuario MySql

Crear usuario:

CREATE USER 'user'@'127.0.0.1' IDENTIFIED BY 'Estudiante123@';
CREATE USER 'user'@'%' IDENTIFIED BY 'Estudiante123@';

Al crear el usuario ponemos entre la @ primero el nombre y luego desde donde vamos a
permitir que se conecte. si es desde localhost, una ip determinada o cualquier sitio.

Ejemplos:

CREATE USER ‘user’@’127.0.0.1’ IDENTIFIED BY ‘Estudiante123@’;

crearemos un usuario con contraseña MEDIUM y que solo se pueda conectar desde
localhost

CREATE USER ‘user’@’%%’ IDENTIFIED BY ‘Estudiante123@’;

Asignar permisos:

GRANT CREATE, ALTER, DROP, INSERT, UPDATE, DELETE, SELECT, REFERENCES, RELOAD 
ON *.* TO 'user'@'%' WITH GRANT OPTION;

Aplicar cambios:

FLUSH PRIVILEGES;

3.3 Conexión desde Workbench

Ahora que ya tenemos configurado nuestro gestor de mysql y hemos puesto que se pueda
acceder desde cualquier Ip, instalamos Workbench en nuestro host y nos conectamos.

En el cliente, instala Workbench y conecta usando:

• IP del servidor
• Puerto 3306
• Usuario creado
• Contraseña asignada

4. Instalación del servicio FTP (VSFTPD)

Instalar:

sudo apt install vsftpd

Hacemos backup del archivo de configuración:

sudo cp /etc/vsftpd.conf /etc/vsftpd.conf_old

Editar configuración:

sudo nano /etc/vsftpd.conf

Pegar:

listen=NO
listen_ipv6=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
chroot_local_user=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
ssl_enable=NO
pasv_enable=YES
pasv_min_port=10000
pasv_max_port=10100
allow_writeable_chroot=YES

Como hemos realizado una copia de seguridad podemos borrar su contenido, otro truco
para muchos archivos de configuración en linux es comentar las lineas anteriores con #, o
simplemente poner la nueva configuración al final del documento.

*Ubuntu en algunas versiones, viene con un firewall llamado UFW. En este caso le debemos
de decir que abra el puerto 20, 21 y los del 10000 al 10100 para su correcto funcionamiento

Abrir puertos en UFW:

sudo ufw allow from any to any port 20,21,10000:10100 proto tcp

Reiniciar servicio:

sudo systemctl restart vsftpd

4.1 Acceso vía FTP desde el cliente

Para transmitir archivos via FTP al servidor podemos usar cualquier programa de
transmisión de archivos como Filezilla-client

Utiliza FileZilla-client y conecta usando:

• IP del servidor
• Usuario FTP
• Contraseña
• Puerto 21

Cada usuario tendrá acceso a su carpeta.

4.2 Acceso FTP a la carpeta web de Apache

Dado que nuestro objetivo es montar un servidor web, debemos tener la opción de poder
acceder a las carpetas de de apache html, para poder transmitir los archivos de una web,
imagenes, etc.

Existe varios modos, veamos el que considero mas sencillo para inicial. Que consiste en
crear un usuario donde su carpeta personal sea la www de Apache2 y dar permisos a esta
carpeta.

Creamos un usuario cuyo directorio sea la carpeta web:

sudo useradd -m ftpuser
sudo passwd ftpuser

*Con la opción -m indicamos que nos cree una carpeta para el usuario

Finalmente, podemos editar el archivo /etc/passwd para cambiar la carpeta al que el usuario
tendrá acceso.

sudo nano /etc/passwd   ← Cambia el directorio del usuario.

También podrías jugar con los grupos de usuarios en Linux, para dar acceso a diferentes
usuarios, algunos comandos útiles que podrías repasar podrían ser:

Modificar grupos/permisos:

sudo chgrp -R ftpuser www
sudo groupadd grupo
sudo adduser usuario grupo
sudo chmod -R 775 www

5. Instalación del intérprete PHP

Instalamos PHP y módulos:

sudo apt install php libapache2-mod-php php-mysql php-cli

php: el propio interprete, si queremos una versión especifica podriamos poner php8.1, php7,
etc.

libapache2-mod-php: Libreria que permite trabajar a apache2 con php (Imprescindible en
nuestro caso)

php-mysql: Libreria que permite hacer conexiones desde php a mysql (Imprescindible si
hacemos app con acceso a bases de datos).

php-cli: Aunque para un servidor web no es necesario, si es util para ejecutar scripts de php
directamente en la terminal, para temas de mantenimiento, tareas crontab, envio de
mensajes, etc.

Una vez instalado puede comprobar la versión instalada con:

php -v

Crear archivo de prueba:

sudo nano /var/www/html/version.php

Contenido:

<?php
phpinfo();
?>

Dar permisos:

sudo chmod 775 version.php

Probar desde el navegador: http://IP/version.php

Ejecución PHP desde terminal

Crear archivo:

sudo nano infosys.php

Contenido:

<?php 
$os = php_uname(); 
$cpu = shell_exec('cat /proc/cpuinfo | grep "model name" | head -n 1'); 
$memTotal = shell_exec('cat /proc/meminfo | grep MemTotal'); 
$memFree = shell_exec('cat /proc/meminfo | grep MemFree'); 
$disk = shell_exec('df -h'); 

echo "Información del Sistema:\n";
echo "Sistema Operativo: $os\n";
echo "Procesador: $cpu\n"; 
echo "Memoria Total: $memTotal"; 
echo "Memoria Libre: $memFree\n"; 
echo "Espacio en Disco:\n$disk\n"; 
?>

Ejecutar:

php infosys.php

6. Acceso por SSH desde un IDE – Visual Studio Code

Instalar VSCode: https://code.visualstudio.com/Download

Instalar extensión: Remote – SSH

Crear conexión:

1. Clic en icono de conexión remota.
2. Add New SSH Host.
3. Indicar un nombre sin espacios.
4. Elegir dónde guardar el archivo de configuración.
5. Indicar sistema operativo remoto (Linux).
6. Escribir parámetros:

Host Mi_conexion
  HostName 192.168.x.x
  User ubuntu

Una vez guardado, podrás acceder desde VS Code, abrir carpetas del servidor y usar la terminal integrada.

El objetivo de esta práctica es aprender a utilizar archivos .htaccess en un servidor Apache para configurar:

• Autenticación
• Gestión de errores
• Redirecciones
• Reescritura de URLs
• Cabeceras de seguridad
• Control de indexación en buscadores
• Ocultación y restricción de carpetas
• Optimización mediante caché y compresión

Se realizará de forma práctica para observar los efectos directamente.

Requisitos

• Apache instalado y funcionando
• Permisos para editar archivos en /var/www/html/ o carpeta equivalente

Parte 1: Activación de .htaccess en Apache

1. Editar el VirtualHost y localizar:

<Directory /var/www/html>
   AllowOverride None
   Require all granted
</Directory>

2. Cambiar None por All:

AllowOverride All

3. Reiniciar Apache:

sudo systemctl restart apache2

4. Crear un archivo /var/www/html/.htaccess con este contenido:

AddDefaultCharset UTF-8

Si no hay errores, el .htaccess está funcionando.

Para editar el VirtualHost típico en Ubuntu/Debian:

1. Abrir el archivo de sitio por defecto:

sudo nano /etc/apache2/sites-available/000-default.conf

2. Buscar un bloque <VirtualHost *:80> que contiene algo como:

<VirtualHost *:80>
    DocumentRoot /var/www/html
    ...
    <Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>

3. Aquí vive la línea “AllowOverride” que decide si .htaccess es un ciudadano con derechos o un fantasma ignorado. Cambiar AllowOverride None por AllowOverride All.
4. Guardar, cerrar y reiniciar Apache:

sudo systemctl restart apache2

Parte 2: Autenticación Básica con .htaccess

1. Crear una carpeta /var/www/html/admin/ con un index.html.
2. Crear /var/www/html/.htpasswd generando un usuario:

htpasswd -c /var/www/html/.htpasswd admin

3. Crear /var/www/html/admin/.htaccess:

AuthType Basic
AuthName "Zona restringida"
AuthUserFile /var/www/html/.htpasswd
Require valid-user

Entrar a http://servidor/admin y probar el acceso.

htpasswd

htpasswd es una pequeña herramienta de Apache que fabrica archivos de credenciales para la autenticación HTTP básica. Básica significa sin florituras: usuario/contraseña codificados en Base64 y enviados en cabecera; útil para poner una puerta rápida delante de una carpeta, una página de administración o un endpoint casero.

Funciona generando un fichero (normalmente .htpasswd) con uno o varios usuarios y sus contraseñas hash. Este fichero luego lo consumes desde .htaccess o desde la configuración del VirtualHost.

1. Abres la terminal en tu servidor.
2. Ejecutas:

htpasswd -c /ruta/al/fichero/.htpasswd nombreusuario

El -c crea el fichero. Si ya existe y quieres añadir otro usuario, lo omites:

htpasswd /ruta/al/fichero/.htpasswd otro_usuario

Al ejecutar, te pedirá contraseña y te la meterá en el fichero con hash. El algoritmo por defecto suele ser bcrypt/MD5 APR según versión; lo importante es que nunca guarda contraseñas en claro.

Un .htpasswd típico se ve así:

juan:$apr1$9tDRSv/.v8BxP1kF/Np7A.
maria:$apr1$OQy4dRxr$2aCdBORded8HNoo.t2GxU.

Luego en .htaccess pones la compuerta:

AuthType Basic
AuthName "Zona restringida"
AuthUserFile /ruta/al/fichero/.htpasswd
Require valid-user

El navegador, al entrar en esa carpeta, lanzará un cuadro de login del siglo pasado (que sigue cumpliendo su función). En HTTPS está bien para control de acceso simple; en HTTP es como mandar postales sin sobre.

Parte 3: Gestión de Errores Personalizados

1. Crear 404.html y 403.html en la raíz.
2. Añadir en /var/www/html/.htaccess:

ErrorDocument 404 /404.html
ErrorDocument 403 /403.html

3. Probar introduciendo una URL inexistente.

Parte 4: Cabeceras de Seguridad

Añadir en /var/www/html/.htaccess:

Header set X-Frame-Options "DENY"
Header set X-Content-Type-Options "nosniff"
Header set X-XSS-Protection "1; mode=block"
Header set Referrer-Policy "no-referrer-when-downgrade"
Header set Permissions-Policy "geolocation=()"

Explicación breve:

• X-Frame-Options: DENY Esta prohíbe que tu página se cargue dentro de un <iframe> de otra página. ¿Para qué sirve? Para evitar el clickjacking, un truco donde otra web maliciosa mete la tuya en un iframe invisible y coloca botones encima, de manera que el usuario cree estar haciendo una cosa y está pulsando otra. Con DENY, el navegador dice “no me meto en iframes de nadie” y así se acaba el truco de magia.
• X-Content-Type-Options: nosniff Los navegadores suelen ser listillos: si reciben un archivo con un tipo incorrecto, intentan adivinarlo (“sniffing MIME”). Eso abre una puerta curiosa: si subes un .png que en realidad es JavaScript con una cabecera errónea, algunos navegadores podrían intentar ejecutarlo. Con nosniff el navegador promete no “oler” el tipo y usar sólo lo declarado. Evita ciertos vectores de XSS y descarga ejecutable camuflada.
• X-XSS-Protection: 1; mode=block Esto es un modo antiguo del filtro anti-XSS integrado en algunos navegadores. Le indica al navegador que si detecta un ataque de Cross-Site Scripting reflejado, bloquee la carga de la página en vez de intentar sanearla. Hoy en día está un poco de capa caída (Chrome lo retiró en favor de Content-Security-Policy) pero en entornos legacy todavía es un salvavidas aceptable.
• Referrer-Policy: no-referrer-when-downgrade Cada vez que pulsas un enlace, el navegador suele enviar una cabecera Referer (sin la segunda “r”, por herencia histórica) indicando desde qué página vienes. Esa miguita de pan puede revelar urls privadas, parámetros de sesión o rutas internas. no-referrer-when-downgrade ordena no enviar el Referer cuando pasas de HTTPS a HTTP (es decir, no “degradar” seguridad). Existen políticas más estrictas (strict-origin, no-referrer, etc.), pero esta ya reduce filtraciones triviales.
• Permissions-Policy: geolocation=() Aquí entramos en una política moderna que controla APIs del navegador. Es como darle a tu web un panel de permisos: cámara, micrófono, geolocalización, sensores… geolocation=() significa “no concedo geolocalización a nadie, ni siquiera a mí”. Puedes ser más granular, por ejemplo geolocation=(self) permitiría sólo a tu propio dominio. Eso reduce el “exceso de curiosidad” del navegador y de scripts de terceros.
• El resumen conceptual es que no protegen tu código del mal, sino que recortan la superficie de comportamiento del navegador, reduciendo trucos clásicos: iframes invisibles, tipos MIME engañosos, ejecución de scripts inesperados y filtración de metadatos. Es parecido a darle menos herramientas a un niño travieso: no podrá arreglar un coche, pero tampoco desmontar la casa.

Más allá de estas cabeceras existen otras piezas más finas como Content-Security-Policy (CSP), que es una gramática entera para decir “qué scripts, imágenes, estilos y conexiones están permitidos”. CSP convierte el navegador en una especie de sandbox configurable, y ahí es donde el mundo del XSS moderno se vuelve deporte olímpico.

Parte 5: Redirecciones HTTP

1. Redirección permanente (301):

Redirect 301 /viejo.html /nuevo.html

2. Temporal (302):

Redirect 302 /promo /promo-2026

Recomendación: usar 301 solo cuando sea definitivo.

Cuando haces una redirección 302 (Found / Moved Temporarily) estás diciendo dos cosas:

— Primero: “el recurso sigue existiendo en la URL original, pero por ahora estoy sirviendo desde otra URL”.

— Segundo: “no actualices tus mapas, no caches esto como definitivo”.

Consecuencias prácticas:

1. Los navegadores no la memorizan como algo fijo.
   No guardan en disco que la URL ha cambiado. Si mañana quitas la redirección, el navegador volverá a pedir la original sin pelearse contigo. Es como poner un cartel de “pasen por la puerta lateral mientras pintamos la principal”.
2. Los buscadores no transfieren ‘peso’ SEO.
   A diferencia de un 301, Google y compañía no asumen que la URL nueva es la buena. Mantienen la original en sus índices. Es la forma de decirles: “no reorganices tu mapa, solo estoy haciendo obras”.
3. No cambia los enlaces de terceros.
   Si un usuario sigue un enlace desde otra web, la redirección lo mueve, pero esa web no actualizará su enlace, porque no hay garantía de permanencia.
4. Sirve para pruebas y mantenimiento.
   Si estás desplegando un nuevo diseño, probando un AB testing o moviendo tráfico durante un rato, una 302 te da una especie de reversibilidad instantánea.

En contraste, un 301 (Moved Permanently) es como una mudanza registrada en el ayuntamiento: los navegadores pueden cachearla, los buscadores actualizan índices y pasan “autoridad” a la nueva URL, y los cambios tardan más en revertirse porque todos asumen que era definitivo.

Lo temporal no cambia la cartografía del navegador ni del buscador, solo redirige el tráfico en tiempo real. Es útil cuando estás probando algo, cuando tienes dudas o cuando quieres mantener la puerta original como referencia verdadera. Luego, cuando estés seguro de la mudanza, ya haces el 301 y los mapas del mundo cambian de sitio.

Parte 6: Reescritura de URLs con mod_rewrite

La reescritura de URLs permite transformar una URL solicitada por el navegador en otra diferente de forma interna, sin que el usuario lo note. Se utiliza para crear URLs más limpias, eliminar extensiones (.php, .html) o implementar un patrón MVC (Front Controller).

6.1 Activación del módulo

Activar el módulo responsable de la reescritura:

sudo a2enmod rewrite
sudo systemctl restart apache2

Sin este módulo, las reglas de reescritura no funcionarán.

6.2 Requisito en el VirtualHost

Dentro del VirtualHost debe estar permitido el uso de .htaccess. En el bloque <Directory> debe existir:

AllowOverride All

Si estuviera en None, Apache ignorará las reglas del .htaccess.

6.3 Ejemplo simple: eliminar extensión

Crear un archivo hola.html en el DocumentRoot (/var/www/html/).

Crear o editar el .htaccess en el mismo directorio con:

RewriteEngine On
RewriteRule ^hola$ hola.html [L]

• RewriteEngine On → activa el motor de reescritura
• RewriteRule ^hola$ hola.html → si se solicita /hola, entregar hola.html
• [L] → indica que esta es la última regla si coincide

Prueba

Acceder en el navegador:

http://servidor/hola

Aunque el archivo real sea hola.html, el navegador verá una URL sin extensión.

6.4 Ejemplo avanzado: patrón MVC (Front Controller)

Este patrón es común en frameworks y sitios dinámicos. La idea es que todas las peticiones que no sean archivos ni carpetas reales se envían a index.php.

6.4.1 Código

En el .htaccess del DocumentRoot:

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php?route=$1 [L,QSA]

6.4.2 Explicación de las condiciones

• RewriteCond %{REQUEST_FILENAME} !-f
  → si lo solicitado no es un archivo físico
• RewriteCond %{REQUEST_FILENAME} !-d
  → si lo solicitado no es un directorio

6.4.3 Explicación de la regla

• ^(.+)$ → coincide con cualquier ruta solicitada
• index.php?route=$1 → envía la ruta al script index.php mediante el parámetro route
• [L,QSA]:
  • L → última regla si coincide
  • QSA → preserva parámetros existentes (?id=3 etc.)

6.5 Demostración práctica

Crear un archivo index.php con:

<?php
echo "Ruta solicitada: " . ($_GET['route'] ?? 'ninguna');
?>

Acceder desde el navegador a distintas rutas:

http://servidor/productos
http://servidor/usuarios/editar/7
http://servidor/pepito

Salida esperada:

Ruta solicitada: productos
Ruta solicitada: usuarios/editar/7
Ruta solicitada: pepito

Esto confirma que index.php captura todas las rutas y puede decidir qué controlador o vista cargar.

6.6 Caso especial: archivos reales

Si se accede a:

/style.css
/logo.png
/index.php

o cualquier recurso físico, NO pasa por la reescritura porque las condiciones lo impiden:

RewriteCond %{REQUEST_FILENAME} !-f   → archivo físico
RewriteCond %{REQUEST_FILENAME} !-d   → directorio físico

De esta forma no se rompe el funcionamiento del sitio.

6.7 Uso habitual en aplicaciones web

Este sistema se utiliza para:

• URLs amigables para SEO
• Frameworks PHP (Laravel, Symfony, CodeIgniter)
• Paneles de administración
• APIs REST
• Front Controllers (único punto de entrada)

En lugar de:

index.php?route=usuarios/listar

se obtiene:

/usuarios/listar

más limpio y apto para buscadores.

La reescritura de URLs no cambia el archivo real que se ejecuta, solo traduce internamente la ruta.
El usuario ve una URL limpia y el servidor recibe una ruta estructurada para procesar.

Parte 7: Control del Listado de Directorios

Para evitar que se muestren archivos:

Options -Indexes

Crear una carpeta sin index.html y comprobar el resultado.

Parte 8: Forzar HTTPS

Añadir:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Requiere certificado SSL configurado.

Parte 9: Cacheo y Compresión

Cache de archivos (si mod_expires activado):

<IfModule mod_expires.c>
   ExpiresActive On
   ExpiresByType image/jpeg "access plus 30 days"
   ExpiresByType text/css "access plus 7 days"
   ExpiresByType application/javascript "access plus 7 days"
</IfModule>

Compresión (si mod_deflate activado):

SetOutputFilter DEFLATE

Cuando decíamos “cache de archivos (si mod_expires activado)” nos referíamos a una función del servidor web Apache diseñada para decirle al navegador cuánto tiempo puede guardar ciertos archivos sin volver a descargarlos.

En castellano llano:

La caché es la costumbre del navegador de guardar copias locales de cosas que ya descargó (como imágenes, CSS o JavaScript) para no pedirlas de nuevo al servidor cada vez que visitas la página. Si ya tienes el logo en tu disco, ¿para qué volver a bajarlo?

El módulo mod_expires es una parte de Apache que permite controlar cuánto dura esa copia local, poniendo un “fecha de caducidad” en las respuestas.

Si lo activas y configurás reglas como:

ExpiresByType image/png "access plus 30 days"

Estás diciendo: “los archivos PNG pueden vivir 30 días en la caché del navegador”.

¿Resultado práctico? La primera visita carga todo desde el servidor, las siguientes cargan desde disco; la web vuela y el servidor descansa.

Esencialmente, es un acuerdo temporal entre servidor y navegador, parecido a:

– Servidor: “Este archivo apenas cambia, guárdalo un mes”.
– Navegador: “Perfecto, no te molesto hasta que pase ese mes”.

En el ecosistema web, la caché es una de las razones por las que las páginas parecen “instantáneas” después de la primera visita, y una forma elegante de reducir gasto de CPU, ancho de banda y tiempo de espera. Sin caché, cada visita sería como entrar por primera vez en un supermercado cada día: todo el mundo preguntando todo el rato dónde están los pasillos.

Parte 10: Interacción con Buscadores (SEO y Indexación)

robots.txt

Crear en raíz del sitio:

User-agent: *
Disallow: /admin/
Disallow: /backup/

Nota: los bots maliciosos pueden ignorarlo.

Evitar indexación con HTTP (X-Robots-Tag)

En .htaccess:

Header set X-Robots-Tag "noindex, nofollow"

Usos habituales:

• PDFs
• Paneles internos
• Carpetas privadas

Bloquear bots por User-Agent

Ejemplo:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} googlebot [NC]
RewriteRule ^ - [R=403]

Parte 11: Ocultación y Restricción de Carpetas

Impedir acceso web a una carpeta:

Dentro de la carpeta crear .htaccess:

Require all denied

O por archivo:

<FilesMatch "\.(sql|bak|zip|tar)$">
   Require all denied
</FilesMatch>

Restringir por IP:

Require ip 192.168.1.0/24

Evitar ejecución de PHP en carpetas de subida:

<FilesMatch "\.(php|phtml)$">
   Require all denied
</FilesMatch>

Muy útil en uploads/ o storage/.

Con .htaccess es posible:

• Restringir acceso
• Personalizar errores
• Crear URLs amigables
• Controlar bot y rastreadores
• Proteger información sensible
• Forzar HTTPS
• Mejorar SEO
• Mejorar rendimiento

Advertencia para producción:

• .htaccess se evalúa en cada petición
• Incrementa carga del servidor
• En grandes entornos se recomienda configurar desde VirtualHost

Un servicio es un proceso de fondo (daemon) que se ejecuta sin cliente directo: servidor web, base de datos, cupón/leche… cosas que viven en silencio.

systemd organiza los servicios como units (unidades). Una unit puede ser:

• service → servicios
• timer → programadores sustitutos del cron
• mount → puntos de montaje
• socket → servicios socket-activados
• y más fauna, pero hoy nos interesa el zoológico *.service.

¿Qué hace systemctl?

systemctl permite:

• Iniciar/detener un servicio.
• Habilitarlo o deshabilitarlo en arranque.
• Ver logs y estado.
• Ver dependencias.

Su sintaxis general:

systemctl <acción> <unidad>

Ejemplo:

systemctl start apache2.service

Ver servicios instalados

Esto ayuda a explorar el sistema:

Servicios activos ahora mismo:

systemctl list-units --type=service --state=running

systemctl list-units --type=service

Servicios instalados en el sistema (cargados y no cargados):

systemctl list-unit-files --type=service

Estado de un servicio

Es la acción más frecuente.

systemctl status apache2.service

Muestra:

• PID
• Logs recientes
• “Loaded” (si está instalado)
• “Active” (si está corriendo)

La magia aquí es que systemd integra parte del journal, así que ya da contexto.

Iniciar / Detener / Reiniciar

Aquí es donde la clase empieza a levantar humo.

Iniciar servicio:

sudo systemctl start apache2.service

Detener:

sudo systemctl stop apache2.service

Reiniciar de forma limpia:

sudo systemctl restart apache2.service

Recargar configuración sin detener el servicio (si lo soporta, como Nginx):

sudo systemctl reload nginx.service

Para puristas: restart tira y relanza, reload solo recarga configuración.

Habilitar en el arranque

Esto conecta systemd con los “targets” (equivalentes modernos de runlevels).

Habilitar:

sudo systemctl enable apache2.service

Deshabilitar:

sudo systemctl disable apache2.service

Comprobar si está habilitado:

systemctl is-enabled apache2.service

Esto crea o elimina enlaces simbólicos en /etc/systemd/system/.

Ver logs de un servicio

journalctl es el diario íntimo del sistema. Útil para debugging y para descubrir que olvidaste escapar ese símbolo en la config de Postfix.

Logs recientes del servicio:

journalctl -u apache2.service

Logs en tiempo real (“modo Matrix”):

journalctl -u apache2.service -f

Logs de hoy con timestamps:

journalctl -u apache2.service --since today