Fundamentos de Routing
Este curso recorre los principios esenciales del routing IP, desde cómo un router toma decisiones y construye su tabla de rutas hasta el direccionamiento, VLSM, CIDR y diseño de redes IP. A partir de esa base, introduce los tres grandes paradigmas del routing moderno: vector distancia, estado del enlace y path vector, profundizando en protocolos como RIP, OSPF, IS-IS, EIGRP y BGP con enfoque práctico, de diseño y de troubleshooting. El curso es básicamente el libro de Fundamentos de Routing que escribí hace 15 años pero puesto al día, por ejemplo la parte de IPv6 ha cambiado bastante desde entonces.

eVPN en el Centro de Datos
Este curso explica cómo construir un fabric de centro de datos moderno con VXLAN BGP EVPN, cubriendo tanto la arquitectura física como la lógica del entorno. Recorre el diseño del underlay y del overlay, la gestión del tráfico BUM, los servicios L2 y L3 multi-tenant, la conectividad exterior mediante border leafs y, además, aborda cómo migrar desde redes Ethernet clásicas a un modelo EVPN de forma ordenada y realista.

SCION
Este curso presenta SCION como una arquitectura de Internet de nueva generación diseñada para aportar más seguridad, disponibilidad y control del camino extremo a extremo que el modelo basado en BGP. Explica sus fundamentos, su arquitectura por ISDs y ASes, el funcionamiento de sus planos de control y datos, sus mecanismos criptográficos, el uso de multipath y alta disponibilidad, así como su despliegue real y su posible papel en la evolución futura de Internet.

Ultra Ethernet
Este curso analiza Ultra Ethernet como la propuesta abierta del Ultra Ethernet Consortium para redes de IA y HPC a gran escala. Parte de los fundamentos de DMA, RDMA, DCB y RoCE, y avanza hacia el transporte UET, el spraying por paquete, la gestión de congestión, la seguridad extremo a extremo, la integración con Linux y Libfabric, y los escenarios de despliegue en infraestructuras pensadas para entrenamiento de IA y computación de altas prestaciones.

Los cursos están divididos en módulos, que serían lo equivalente a capítulos si fuera un libro para independizar temas.

Espero que lo disfrutéis y sobre todo que os sirva de ayuda.

Los cursos los tenéis en la sección de formación, mirad arriba en la barra del blog pero si os da pereza os dejo aquí el enlace directo https://www.eduardocollado.com/cursos/

El punto de partida fue algo invisible para el usuario pero bastante crítico por dentro. La forma en que EasyPodcast resolvía las URLs de los episodios era secuencial, con un coste que crece conforme crece la biblioteca. Se añadió un índice en la base de datos y se pasó a una búsqueda logarítmica. En podcasts con muchos episodios, la diferencia se nota de inmediato. De paso, se corrigió un bug con las URLs absolutas que generaba inconsistencias al resolver enlaces.

A mediados de mes llegó la versión 1.5.0 con algo que llevaba tiempo pendiente: el panel de administración ahora habla varios idiomas. Español, inglés, alemán, catalán, gallego, francés, portugués e italiano. El selector está accesible desde el propio panel y desde configuración, y el sistema envuelve todos los textos de la interfaz. Nada de parches a medias.

Pero si hay una versión del mes, esa es la 1.6.0. El editor Markdown desaparece y lo sustituye Jodit, un editor WYSIWYG completo que funciona tanto en episodios como en páginas. Edición visual real, sin necesidad de aprender ninguna sintaxis. Además, el contenido pasa a un campo específico y el feed RSS ahora incluye HTML completo en el campo content:encoded, que es como debe ser. También se introduce un campo de descripción corta pensado para SEO y para listados, separando por fin el resumen del contenido largo.

En esa misma versión, y en la 1.6.1 que vino justo después, llegaron varias cosas más. EasyPodcast ahora tiene una API REST completa que expone episodios, páginas, configuración, redes sociales, estadísticas y caché, con autenticación por Bearer token y documentación integrada en el propio panel. También se añadió un grabador de audio directo desde el navegador, con un detalle importante: si hay errores de validación al guardar, la grabación no se pierde. El 2FA gana la opción de recordar el dispositivo durante siete días, que reduce la fricción sin comprometer la seguridad. Y se añade una herramienta para detectar y eliminar audios e imágenes huérfanos que llevan tiempo ocupando espacio sin que nadie los use. Por último, cuando un episodio no existe, el servidor devuelve un 404 real en lugar de fallar en silencio. Pequeño detalle, gran diferencia para el SEO.

Las versiones 1.6.3 y 1.6.4, ya a finales de mes, se centraron en estabilidad. La grabación de audio ya no se pierde si hay errores de validación, el actualizador en Docker deja de sobrescribir el .htaccess, lo que causaba bucles de redirección HTTPS en setups con reverse proxy, y tras actualizar se muestra el changelog de la versión que acaba de instalarse. Cambios pequeños, pero el tipo de cosas que en producción real marca la diferencia entre un dolor de cabeza y que todo funcione.

Para cerrar el mes, el 28 llegó la 1.7.0 con un sistema de temas visuales. Seis opciones: Default, Agua, Fuego, Invierno, Hacker y Monocromo. Se aplican en servidor, sin JavaScript de por medio, lo que significa que no hay ningún destello al cargar la página. El antiguo modo oscuro basado en localStorage desaparece y lo sustituye este sistema, bastante más sólido y coherente.

En resumen, marzo ha sido menos de funcionalidades aisladas y más de evolución real del producto. Mejor base técnica, mejor experiencia de edición, más control vía API y más personalización visual. EasyPodcast está empezando a comportarse más como una plataforma completa que como una herramienta de publicación simple, y este mes lo deja bastante claro.

De todos modos os paso el contenido:

en robots.txt (para pedirlo educadamente)

# ── Crawlers de IA / LLM ─────────────────────────────────

# OpenAI
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

# Anthropic
User-agent: anthropic-ai
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

# Google IA (Gemini / Bard training)
User-agent: Google-Extended
Disallow: /

# Meta
User-agent: FacebookBot
Disallow: /

# Perplexity
User-agent: PerplexityBot
Disallow: /

# You.com
User-agent: YouBot
Disallow: /

# Common Crawl (usado para entrenar LLMs)
User-agent: CCBot
Disallow: /

# Cohere
User-agent: cohere-ai
Disallow: /

# Diffbot
User-agent: Diffbot
Disallow: /

# ByteDance / TikTok
User-agent: Bytespider
Disallow: /

# Apple
User-agent: Applebot-Extended
Disallow: /

# Otros scrapers conocidos
User-agent: ImagesiftBot
Disallow: /

User-agent: magpie-crawler
Disallow: /

User-agent: DataForSeoBot
Disallow: /

User-agent: AI2Bot
Disallow: /

User-agent: Omgilibot
Disallow: /

User-agent: Timpibot
Disallow: /

User-agent: FriendlyCrawler
Disallow: /

En el .htaccess (para bloquear esos .user-agents)

<IfModule mod_rewrite.c>
RewriteCond %{HTTP_USER_AGENT} (GPTBot|ChatGPT-User|OAI-SearchBot|anthropic-ai|ClaudeBot|Claude-Web|Google-Extended|FacebookBot|PerplexityBot|YouBot|CCBot|cohere-ai|Diffbot|Bytespider|Applebot-Extended|ImagesiftBot|magpie-crawler|DataForSeoBot|AI2Bot|Omgilibot|Timpibot|FriendlyCrawler) [NC]
RewriteRule .* - [F,L]
</IfModule>

Foto de Markus Spiske: https://www.pexels.com/es-es/foto/hombre-policia-uniforme-de-espaldas-4682719/

El problema es que yo uso Linux. Más concretamente KDE Plasma, que es mi escritorio de toda la vida. Y claro, NotchPrompter es solo para Mac.

Solución obvia: portarlo a Linux.

Qué hace

Una ventana sin marcos que se queda siempre encima de todo y va pasando el texto que tú le metas. Sin más. Lo que hace cualquier teleprompter, pero sin que te instale media internet en el proceso.

Cuando acercas el ratón aparece una barrilla con los controles. Cuando lo alejas, desaparece. Puedes cambiar la velocidad, el tamaño del texto, editar el guion al vuelo o cargar un .txt desde disco.

Los colores son del esquema Catppuccin Mocha porque soy así de friki con estas cosas.

Qué no hace

Pues a diferencia de la original para Mac, esta no escucha por donde vas, así que tendrás que estar un poco más atento para regular la velocidad o pausar el texto.

Por qué PyQt6 y no otra cosa

Porque soy usuario de KDE Plasma y quería algo que funcionara bien de verdad, no una app web disfrazada ni dependencias de GNOME. PyQt6 te da acceso directo a Qt, que es lo que usa KDE por debajo. El resultado es una ventana nativa, ligera y que se comporta como debe.

El script instalado pesa 25 KB. Veinticinco kilobytes. Que conste.

Cómo instalarlo

Si tienes Debian o Ubuntu, descarga el .deb de la página de releases y:

sudo apt install ./kdeteleprompter_1.0.1_all.deb

Listo. Las dependencias las gestiona apt solo, no tienes que hacer nada más. Aparece en el lanzador de aplicaciones de KDE y todo.

Si prefieres tirarlo desde el código fuente:

pip install PyQt6
python3 kdeteleprompter.py

Los atajos que molan tener memorizados

┌─────────┬───────────────────────┐
│ Tecla   │     Para qué          │
├─────────┼───────────────────────┤
│ Espacio │     Play / Pausa      │
├─────────┼───────────────────────┤
│ R       │  Volver al principio  │
├─────────┼───────────────────────┤
│ + / -   │ Más o menos velocidad │
├─────────┼───────────────────────┤
│ Ctrl+E  │ Editar el guion       │
├─────────┼───────────────────────┤
│ Escape  │ Cerrar                │
└─────────┴───────────────────────┘

El código está en GitHub, la licencia es MIT porque el código original era MIT y hay que respetar las licencias, es libre, abierto, lo que quieras:

github.com/educollado/KDETeleprompter

Si le ves algo mejorable o te peta en tu máquina, abre un issue y lo miramos.

Puedes leer la documentación oficial de EasyPodcast en https://www.easypodcast.eu/.

Llevo tiempo dándole vueltas a una cosa: ¿cómo algo tan sencillo como publicar un podcast se ha convertido en una especie de gymkana tecnológica?

La opción fácil es darse de alta en una plataforma, pagar una cuota, aceptar quince pantallas de configuración, conectar servicios que no sabes muy bien para qué sirven… y al final tú solo querías subir un audio y que el RSS funcionase. La otra opción es montarte un WordPress, instalar un plugin enorme, instalar 10.000 dependencias y al final del todo tienes un podcast, pero creo que a veces no es lo que queremos.

Así que un día quería montar un podcast nuevo y no me apetecía ninguna de las dos opciones, y de ahí salió EasyPodcast.

EasyPodcast es un gestor sencillo para publicar podcasts usando PHP y SQLite. Nada de infraestructuras ni de ingeniería aeroespacial, nada de depender de terceros, nada de cosas que no se pueden controlar. Lo mejor: hacérselo uno mismo. Lo subes a tu servidor, lo configuras y te pones a publicar en 5 minutos. Como debería ser. Vamos, que no hace falta pedir audiencia en el Vaticano para sacar un episodio.

Yo quería algo que hiciera estrictamente lo necesario y ni una línea más. Al publicar un episodio, se guarda en SQLite, se actualiza el feed RSS y se muestra en la web pública. Punto.

Uso SQLite porque me parece una maravilla infravalorada. Un archivo y listo. No necesitas montar un servidor de base de datos aparte ni complicarte la vida. Al final son muy pocos datos y realmente no lo necesitas, sobre todo si es un proyecto personal. Pero incluso para algo más serio, SQLite es suficiente.

Si ya tienes un VPS pequeño o tu propio servidor, lo puedes tener funcionando antes de que termine el café.

No pretende competir con plataformas gigantes ni con soluciones empresariales. No es su guerra. EasyPodcast es para quien quiere control, simplicidad y autonomía. Para quien prefiere tener su feed RSS en casa, bajo su dominio, sin que mañana alguien cambie las condiciones y te deje mirando a Cuenca. Que ya nos conocemos.

El panel de administración es limpio y directo. Subes el audio, rellenas los datos del episodio y a correr. No hay tutorial de 40 minutos en YouTube para entenderlo. Si sabes usar un formulario web, sabes usar EasyPodcast. Y si sabes algo de PHP, además puedes abrir el código y entender qué está pasando. Sin magia negra.

Con el tiempo le he ido añadiendo las cosas que de verdad hacen falta. Las descripciones de los episodios se escriben en Markdown con vista previa en tiempo real, porque escribir en un textarea pelado en 2025 no tiene ningún sentido. Al subir un MP3, escribe automáticamente los metadatos ID3, incluida la portada, para que el episodio llegue bien presentado a cualquier app de podcast. Hay sitemap, Open Graph y datos estructurados JSON-LD, porque si publicas algo, que al menos Google se entere. Y hay un sistema de copias de seguridad integrado para exportar e importar la base de datos y los ficheros, que uno no quiere depender solo de que el servidor no se muera. Por si acaso.

A partir de la versión 0.7 también tiene modo oscuro, que ya sé que parece una tontería, pero cuando son las once de la noche y estás preparando el episodio de la semana, lo agradeces.

¿Es perfecto? No. Ni lo pretende. Es pequeño a propósito. Es mantenible a propósito. Es sencillo a propósito. Porque a veces lo mejor no es añadir más cosas, sino quitar las que sobran. Que eso parece que cuesta más.

En el fondo, EasyPodcast nace de una idea muy básica: si el estándar del podcasting es abierto y el RSS es abierto, ¿por qué necesitamos intermediarios para publicar un mp3?

Cómo instalarlo

La instalación es de las más sencillas que he podido hacer. Sin SSH, sin consola, sin complicaciones. Solo necesitas un servidor con PHP.

1. Descarga el instalador: ve al repositorio EasyPodcast-Installer en GitHub y descarga el archivo instalar.php. También puedes descargarlo directamente desde este enlace: descargar instalar.php (clic derecho → Guardar como).
2. Súbelo a tu servidor: copia instalar.php en el directorio raíz donde quieres instalar EasyPodcast. Ese directorio debería estar vacío (o ser el único archivo que haya en él).
3. Abre el instalador en el navegador: accede a https://tu-dominio.com/instalar.php y sigue los tres pasos del asistente: comprobación de compatibilidad, verificación del directorio e instalación.
4. Listo: el instalador descarga la última versión de EasyPodcast desde GitHub, extrae los archivos, crea la base de datos SQLite y te redirige al panel de administración en /admin.php. El propio instalador intenta borrarse solo al terminar; si no puede, bórralo tú manualmente antes de empezar a usar la aplicación.

Requisitos mínimos: PHP 8.0+ con las extensiones pdo_sqlite, sqlite3, zip, gd, fileinfo y xmlwriter. La mayoría de hostings compartidos modernos los tienen activados por defecto.

Si eres de los que tiene servidor propio, te gusta trastear y prefieres depender de ti mismo antes que de una plataforma con suscripción mensual, igual te encaja. Puedes ver el código completo en github.com/educollado/EasyPodcast y ver un ejemplo real funcionando en aratospodcast.com.

La verdad es que me haría mucha ilusión si lo probarais, porque nunca se sabe y a lo mejor es lo que estabais buscando.

En la era digital actual, la seguridad de las redes se ha convertido en una preocupación primordial para organizaciones de todos los tamaños. Con la creciente sofisticación de los ataques cibernéticos, es imperativo que las infraestructuras de TI no solo estén protegidas por medidas de seguridad perimetral tradicionales, como firewalls y antivirus, sino también por sistemas avanzados de detección y prevención de intrusiones. Estos sistemas son esenciales para identificar, alertar y, en algunos casos, responder automáticamente a actividades maliciosas antes de que puedan causar daño significativo.

Los Sistemas de Detección de Intrusiones (IDS) juegan un papel crucial en la defensa en profundidad, monitoreando el tráfico de red y/o la actividad en los sistemas para detectar patrones de comportamiento sospechosos o conocidos de ataques. Al operar como los centinelas de la red, los IDS proporcionan una capa adicional de seguridad que ayuda a identificar y mitigar las amenazas en tiempo real o de manera retrospectiva, permitiendo a los equipos de seguridad investigar y responder a los incidentes de manera informada.

Dentro del ámbito de los IDS, existen varias herramientas poderosas y ampliamente adoptadas, cada una con sus propias fortalezas, capacidades y enfoques únicos para la detección de intrusiones. En este artículo, nos centraremos en tres de las herramientas más prominentes y sofisticadas disponibles para sistemas Linux: Snort, Suricata y Zeek.

Snort es uno de los IDS más antiguos y ampliamente utilizados en el mundo. Desarrollado por Sourcefire y ahora bajo el amparo de Cisco, Snort es una herramienta de detección basada en firmas que inspecciona el tráfico de red en busca de patrones específicos que indican posibles intrusiones. Su amplia base de usuarios y su conjunto de reglas actualizadas continuamente lo convierten en una solución de confianza para muchas organizaciones.

Suricata, por otro lado, es un sistema de detección, prevención e inspección de intrusiones de próxima generación. Desarrollado por la Open Information Security Foundation (OISF), Suricata es conocido por su capacidad para realizar análisis de tráfico en tiempo real, utilizando técnicas de detección basadas en firmas, anomalías y protocolos. Es altamente escalable y puede procesar grandes volúmenes de tráfico, aprovechando las capacidades de procesamiento multihilo.

Zeek (anteriormente conocido como Bro) se distingue por su enfoque en el análisis de eventos de red de alta fidelidad y la generación de registros detallados de actividad. A diferencia de Snort y Suricata, que se centran en la detección basada en firmas, Zeek proporciona un marco flexible para el análisis de tráfico que permite a los usuarios escribir sus propios scripts de detección. Esto lo hace excepcionalmente poderoso para identificar comportamientos anómalos y complejos en la red que pueden no ajustarse a las firmas de ataque conocidas.

La selección entre Snort, Suricata y Zeek depende de varios factores, incluidas las necesidades específicas de seguridad de la red, la infraestructura existente, los recursos disponibles y la experiencia técnica del equipo de seguridad. Al entender las capacidades y limitaciones de cada herramienta, las organizaciones pueden implementar una solución de detección de intrusiones robusta y efectiva, fortaleciendo significativamente su postura de seguridad en red.

¿Qué es un Sistema de Detección de Intrusiones (IDS)?

Un Sistema de Detección de Intrusiones (IDS) es una herramienta esencial dentro de la ciberseguridad, diseñada para identificar y alertar sobre intentos de intrusión o actividades maliciosas en una red o sistema. Su principal objetivo es monitorear y analizar tanto el tráfico de red como el comportamiento de los sistemas para detectar acciones sospechosas que podrían indicar una amenaza de seguridad. Esto incluye desde intentos de acceso no autorizado hasta ataques más sofisticados, como el malware, el phishing, y otros tipos de ciberataques.

Definición y Objetivo de un IDS

La definición formal de un IDS se centra en su capacidad para identificar patrones de comportamiento anormal o firmas de ataques conocidos, basándose en un conjunto predefinido de reglas o criterios. Estos sistemas se diseñaron con el objetivo de proporcionar una capa adicional de seguridad, complementando las defensas perimetrales tradicionales como firewalls y soluciones antivirus. Al hacerlo, los IDS desempeñan un papel crucial en la detección temprana de posibles incidentes de seguridad, permitiendo a los administradores de red tomar medidas proactivas para mitigar los riesgos antes de que se produzcan daños significativos.

Tipos de IDS

Los sistemas de detección de intrusiones se clasifican generalmente en dos categorías principales, basados en su enfoque de monitoreo:

• IDS Basados en Red (NIDS): Estos sistemas se centran en el análisis del tráfico de red que pasa por puntos estratégicos de la red, buscando patrones de tráfico sospechosos o anomalías. Los NIDS son especialmente efectivos para identificar ataques dirigidos a múltiples sistemas dentro de la red, ya que tienen una visión global del tráfico de red.
• IDS Basados en Host (HIDS): A diferencia de los NIDS, los HIDS se instalan en dispositivos individuales y monitorean las actividades internas de ese sistema, incluyendo el sistema de archivos, los registros de eventos del sistema y las operaciones de los usuarios. Estos sistemas son capaces de detectar cambios maliciosos en los archivos del sistema, intentos de escalada de privilegios y otras amenazas específicas del host.

Además de estos dos tipos principales, existen variantes híbridas y especializadas de IDS que combinan características de ambos enfoques, ofreciendo una detección de amenazas más comprensiva y adaptativa.

Integración en una Estrategia de Seguridad en Profundidad

La integración de IDS en una estrategia de seguridad en profundidad es fundamental para establecer una defensa robusta contra las amenazas cibernéticas. La seguridad en profundidad se basa en la aplicación de múltiples capas de defensa distribuidas a lo largo de la infraestructura de TI, con el fin de proteger los datos en todos los niveles. Los IDS complementan otras medidas de seguridad al proporcionar detección de amenazas en tiempo real y análisis detallado del comportamiento de la red y de los sistemas.

La implementación efectiva de un IDS dentro de esta estrategia implica no solo su configuración y mantenimiento continuo sino también la integración con otros componentes de seguridad, como sistemas de prevención de intrusiones (IPS), firewalls, sistemas de gestión de eventos e información de seguridad (SIEM) y soluciones de respuesta ante incidentes. Esto permite a las organizaciones no solo detectar amenazas de manera proactiva sino también responder de manera rápida y efectiva, minimizando así el impacto de los ataques.

En conclusión, los sistemas de detección de intrusiones son componentes críticos dentro de la arquitectura de seguridad de cualquier organización. Su capacidad para detectar actividades sospechosas o maliciosas en tiempo real, junto con su integración en una estrategia de seguridad en profundidad, los convierte en herramientas indispensables para la protección contra una amplia gama de ciberamenazas. Al elegir e implementar el tipo adecuado de IDS, las organizaciones pueden fortalecer significativamente su postura de seguridad y su capacidad para responder a incidentes de seguridad.

Snort

Snort es un sistema de prevención y detección de intrusiones de red (NIDS/NIPS) ampliamente reconocido y utilizado en el mundo de la seguridad informática. Desde su creación en 1998 por Martin Roesch, Snort ha evolucionado de ser una simple herramienta de detección de intrusiones a convertirse en un sofisticado sistema de prevención de intrusiones, gracias a su capacidad para analizar el tráfico de red en tiempo real, identificar patrones de ataques y realizar acciones correctivas automáticas.

Historia y Desarrollo de Snort

Snort fue lanzado inicialmente como un proyecto de código abierto, lo que permitió que una comunidad global de desarrolladores y profesionales de seguridad contribuyera a su desarrollo y mejora continua. A lo largo de los años, Snort ha recibido varias actualizaciones significativas que han ampliado sus capacidades de detección y prevención de intrusiones, así como su eficiencia y facilidad de uso. En 2013, Snort fue adquirido por Cisco Systems, lo que marcó el comienzo de una nueva era de desarrollo y soporte profesional, garantizando que Snort siguiera siendo relevante y efectivo frente a las amenazas cibernéticas en constante evolución.

Características Principales

• Detección Basada en Firmas: Snort utiliza un extenso conjunto de firmas de ataques, que son patrones de datos que corresponden a comportamientos conocidos de amenazas. Esto permite a Snort identificar y bloquear una amplia gama de ataques, desde intentos de intrusión hasta malware y actividad de exfiltración de datos.
• Análisis de Protocolos: Snort es capaz de inspeccionar y analizar varios protocolos de red, incluidos HTTP, FTP, SMTP, y muchos otros. Esta capacidad permite a Snort detectar anomalías y ataques que se llevan a cabo a través de protocolos específicos, mejorando la precisión de la detección.
• Prevención de Intrusiones: Además de detectar ataques, Snort puede actuar como un sistema de prevención de intrusiones, bloqueando el tráfico malicioso antes de que alcance los sistemas objetivo. Esto se logra mediante la integración de Snort con dispositivos de control de tráfico de red, como firewalls y switches.

Arquitectura y Componentes Principales

• Preprocesadores: Los preprocesadores son módulos en Snort que preparan el tráfico de red para el análisis, realizando tareas como la normalización de protocolos, la decodificación de flujos y la detección de anomalías. Esto permite a Snort analizar el tráfico de manera más eficiente y efectiva.
• Motor de Detección: El corazón de Snort es su motor de detección, que utiliza algoritmos y patrones de firmas para analizar el tráfico de red en busca de indicadores de ataques. El motor de detección es altamente configurable, permitiendo a los usuarios ajustar la sensibilidad y las especificaciones de detección según las necesidades de su entorno.
• Salidas de Alerta: Cuando Snort detecta una actividad sospechosa, genera alertas que pueden ser enviadas a varios destinos, como archivos de registro, consolas de administración de seguridad o sistemas de gestión de eventos e información de seguridad (SIEM). Esto facilita la monitorización y respuesta rápida a incidentes de seguridad.

Comunidad y Soporte

• Reglas de Snort: Una de las fortalezas de Snort es su sistema de reglas, que es mantenido tanto por la comunidad de usuarios como por equipos profesionales. Las reglas definen los patrones de tráfico que Snort debe buscar y pueden ser personalizadas para satisfacer las necesidades específicas de cualquier red. La comunidad de Snort juega un papel crucial en el desarrollo y actualización constante de estas reglas, asegurando que Snort pueda detectar las últimas amenazas.
• Snort3: La última versión importante de Snort, Snort3, introduce varias mejoras significativas sobre las versiones anteriores, incluyendo una arquitectura completamente reescrita para mejorar el rendimiento y la eficiencia, un sistema de configuración simplificado y capacidades avanzadas de inspección de tráfico. Snort3 representa el compromiso continuo de la comunidad y Cisco para mantener a Snort a la vanguardia de la detección y prevención de intrusiones.

En conclusión, Snort se mantiene como una herramienta indispensable en el arsenal de cualquier profesional de seguridad de redes, ofreciendo capacidades robustas de detección y prevención de intrusiones respaldadas por una comunidad activa y un soporte profesional sólido. Su arquitectura flexible y sistema de reglas potente permiten a Snort adaptarse a una amplia gama de entornos y desafíos de seguridad, haciendo de él una solución de confianza para proteger contra las amenazas cibernéticas modernas.

Suricata

Suricata es un sistema de detección, prevención e inspección de intrusiones de alto rendimiento, desarrollado por la Open Information Security Foundation (OISF). Es conocido por su capacidad para realizar un análisis en profundidad del tráfico de red, utilizando tanto la detección basada en firmas como la detección de anomalías para identificar amenazas. Suricata se distingue por su enfoque en el rendimiento, la escalabilidad y la capacidad de manejar grandes volúmenes de datos en tiempo real.

Historia y Desarrollo de Suricata

Suricata fue lanzado en 2009 por la OISF, con el objetivo de proporcionar una herramienta de detección de intrusiones de próxima generación que fuera de código abierto, altamente escalable y fácil de integrar con otros sistemas de seguridad. Desde su lanzamiento, Suricata ha recibido el apoyo de una comunidad activa de desarrolladores y usuarios que contribuyen a su desarrollo continuo, mejoras en las características y actualizaciones regulares para mantenerse al día con las nuevas amenazas de seguridad.

Características Distintivas

• Multihilo: Suricata está diseñado para ser multihilo, lo que le permite procesar grandes cantidades de tráfico de red de manera eficiente al distribuir la carga de trabajo a través de varios núcleos de procesador. Esta característica hace que Suricata sea especialmente adecuado para entornos de alta demanda, donde el rendimiento y la capacidad de respuesta son críticos.
• Detección Basada en Firmas y en Anomalías: Suricata utiliza un sistema híbrido de detección que combina la detección basada en firmas, para identificar patrones de ataque conocidos, con la detección de anomalías, para identificar comportamientos sospechosos o desconocidos. Esto le permite detectar una amplia gama de amenazas, desde ataques conocidos hasta actividades maliciosas novedosas o sofisticadas.
• Soporte para IPv6 y TLS: En reconocimiento a la evolución de las redes modernas, Suricata ofrece soporte completo para IPv6, permitiendo a las organizaciones proteger sus redes mientras adoptan la última generación de protocolos de Internet. Además, Suricata puede inspeccionar el tráfico cifrado TLS, lo que es esencial para detectar amenazas en conexiones seguras que de otro modo estarían ocultas.

Arquitectura y Flujo de Trabajo

La arquitectura de Suricata está diseñada para maximizar el uso eficiente de los recursos y la escalabilidad. Al utilizar un enfoque multihilo, Suricata puede distribuir el análisis de tráfico a través de varios núcleos de CPU, lo que permite un procesamiento más rápido y la capacidad de manejar volúmenes de tráfico elevados sin degradar el rendimiento. Suricata también implementa una arquitectura de flujo de trabajo que procesa el tráfico de red en etapas, desde la captura de paquetes hasta el análisis de protocolos, la detección de amenazas y la generación de alertas, optimizando el flujo de trabajo para una detección eficaz y precisa.

Integración y Soporte

• Open Information Security Foundation (OISF): Suricata es un proyecto de la OISF, una fundación dedicada al desarrollo de herramientas de seguridad de red de código abierto. La OISF proporciona soporte y recursos para la comunidad de Suricata, facilitando el desarrollo continuo y la adopción de la herramienta en la industria.
• Actualizaciones de Reglas: Suricata se beneficia de un sistema de actualización de reglas dinámico, con contribuciones tanto de la comunidad como de proveedores comerciales. Esto asegura que Suricata esté siempre equipado con las últimas definiciones de amenazas, permitiendo a los usuarios detectar y responder a las amenazas emergentes de manera oportuna. Además, Suricata es compatible con las reglas de Snort, lo que permite a los usuarios aprovechar una amplia base de datos de firmas de ataques conocidos.

Suricata representa una solución robusta y de vanguardia en el ámbito de la detección y prevención de intrusiones, destacándose por su rendimiento, escalabilidad y flexibilidad. La combinación de características avanzadas, como el procesamiento multihilo, la detección híbrida y el soporte para tecnologías emergentes, junto con el fuerte soporte de la OISF y una comunidad activa, hacen de Suricata una elección preferente para organizaciones que buscan proteger sus redes contra una amplia gama de amenazas de seguridad.

Zeek (anteriormente Bro)

Zeek es un potente marco de análisis de seguridad de red que se distingue por su enfoque en la inspección de tráfico en profundidad y el análisis de eventos de red. Originalmente conocido como Bro, el proyecto fue renombrado a Zeek en 2018 para reflejar mejor su evolución y capacidades más allá de una herramienta de detección de intrusiones tradicional. Zeek se ha establecido como una solución de seguridad de red flexible y poderosa, apreciada por su capacidad para analizar el tráfico de red en detalle y proporcionar un contexto rico para la actividad de red, lo que facilita la detección de comportamientos maliciosos y anomalías.

Historia y Cambio de Nombre de Bro a Zeek

El sistema fue desarrollado inicialmente en 1994 por Vern Paxson en Lawrence Berkeley National Laboratory como una herramienta de monitoreo de red. Bro fue diseñado para interpretar lo que sucede en la red desde un punto de vista semántico, llenando el vacío entre el análisis de paquetes tradicional y el alto nivel de abstracción de las intrusiones. Con el tiempo, Bro evolucionó para incluir capacidades de análisis de tráfico más sofisticadas, convirtiéndose en una plataforma completa para la seguridad de la red. En 2018, para reflejar su amplio espectro de capacidades y alejarse de las connotaciones negativas asociadas al término «bro», el proyecto fue renombrado a Zeek.

Enfoque y Características

• Análisis de Eventos de Red: Zeek se centra en convertir el tráfico de red en eventos de alto nivel, permitiendo una comprensión detallada de la actividad de la red. A diferencia de las herramientas de detección de intrusiones basadas en firmas, Zeek analiza los patrones de comportamiento y las conexiones entre eventos, lo que lo hace efectivo en identificar amenazas sofisticadas y ataques sin firmas conocidas.
• Scripting Flexible: Una de las características más potentes de Zeek es su lenguaje de scripting, que permite a los usuarios escribir sus propios scripts para extender la funcionalidad de Zeek, personalizar el análisis de tráfico y adaptar la herramienta a las necesidades específicas de su entorno de red. Esto hace de Zeek una herramienta extremadamente versátil y adaptable.
• Menos Dependiente de Firmas: A diferencia de otros sistemas de detección de intrusiones, Zeek no depende principalmente de las firmas de ataques conocidos para detectar anomalías. En su lugar, analiza el contexto y el comportamiento del tráfico de red, lo que le permite detectar actividades sospechosas basadas en patrones de comportamiento y anomalías, incluso si el ataque es nuevo o desconocido.

Arquitectura y Uso

La arquitectura de Zeek se basa en su motor de eventos, que procesa el tráfico de red y genera eventos de alto nivel para análisis. Los scripts de Zeek definen cómo se analizan y responden a estos eventos, permitiendo una gran personalización. Los usuarios pueden escribir scripts para realizar una amplia gama de tareas, desde la detección de ataques específicos hasta la recolección de estadísticas de red y la generación de registros detallados. Esta capacidad de personalización hace que Zeek sea adecuado para una variedad de entornos de red, desde pequeñas empresas hasta grandes infraestructuras corporativas.

Comunidad y Recursos Disponibles

• Paquetes de Scripts: La comunidad de Zeek ofrece una amplia gama de paquetes de scripts para diferentes propósitos, desde la detección de malware y exfiltración de datos hasta el análisis de protocolos específicos. Estos paquetes permiten a los usuarios ampliar rápidamente las capacidades de Zeek para satisfacer sus necesidades específicas.
• Formación y Documentación: Zeek cuenta con un extenso conjunto de recursos de formación y documentación para ayudar a los nuevos usuarios a familiarizarse con la herramienta y para asistir a los usuarios experimentados en la personalización y extensión de Zeek. La comunidad de Zeek organiza regularmente talleres, webinars y conferencias para proporcionar formación y compartir conocimientos.
• Comunidad Activa: La comunidad de Zeek es una de sus mayores fortalezas, con un amplio soporte disponible a través de listas de correo, canales de Slack y foros de discusión. Los usuarios pueden colaborar, compartir conocimientos y obtener ayuda de otros profesionales de seguridad.

En resumen, Zeek ofrece una plataforma potente y flexible para el análisis de seguridad de red, destacándose por su enfoque en el análisis de eventos, la flexibilidad de scripting y la capacidad de adaptarse a una amplia gama de entornos de red. Con el apoyo de una comunidad activa y recursos extensos, Zeek continúa siendo una herramienta valiosa para profesionales de la seguridad que buscan una comprensión profunda y detallada de la actividad de su red.

Comparación y Casos de Uso

Al elegir entre Snort, Suricata y Zeek para la seguridad de la red, los profesionales deben considerar varios factores críticos, incluidos el rendimiento, la facilidad de uso, la flexibilidad y el soporte comunitario. Cada uno de estos sistemas de detección de intrusiones ofrece ventajas únicas y puede ser más adecuado para ciertos entornos y necesidades de seguridad.

Comparación Directa

• Rendimiento:
  • Snort es ampliamente reconocido por su robustez y ha sido el estándar de oro en la detección basada en firmas durante muchos años. Sin embargo, puede no ser tan eficiente en el procesamiento de grandes volúmenes de tráfico de red como Suricata, debido a su arquitectura monohilo en versiones anteriores (antes de Snort 3).
  • Suricata se destaca por su capacidad de procesamiento multihilo, lo que le permite manejar grandes volúmenes de datos con mayor eficacia, haciendo de Suricata una opción preferida para redes de alto rendimiento.
  • Zeek no se centra primariamente en la detección basada en firmas sino en el análisis de eventos de red, lo que requiere un enfoque diferente en términos de rendimiento. Su capacidad para generar análisis detallados y registros de eventos lo hace valioso para investigaciones de seguridad y monitoreo de red en tiempo real, aunque esto puede requerir recursos computacionales significativos para el procesamiento.
• Facilidad de Uso:
  • Snort tiene una curva de aprendizaje moderada, especialmente para configurar y personalizar reglas. Sin embargo, su amplia adopción y vasta documentación facilitan encontrar guías y soporte.
  • Suricata ofrece configuraciones y opciones avanzadas que pueden ser intimidantes para los nuevos usuarios, pero su soporte para reglas de Snort y la adición de capacidades de procesamiento multihilo lo hacen atractivo para usuarios con necesidades de rendimiento específicas.
  • Zeek requiere una comprensión más profunda de los scripts y el análisis de eventos de red, lo que puede presentar una curva de aprendizaje más pronunciada. Sin embargo, ofrece flexibilidad sin precedentes para aquellos dispuestos a adentrarse en su lenguaje de scripting.
• Flexibilidad:
  • Snort y Suricata ofrecen flexibilidad en términos de detección de intrusiones y prevención, con Suricata proporcionando capacidades avanzadas de procesamiento de tráfico gracias a su arquitectura multihilo.
  • Zeek sobresale en términos de flexibilidad debido a su poderoso lenguaje de scripting, que permite a los usuarios adaptar la herramienta a una amplia gama de escenarios de seguridad específicos.
• Soporte Comunitario:
  • Snort disfruta de un vasto soporte comunitario, con una gran base de usuarios y desarrolladores contribuyendo a su conjunto de reglas y documentación.
  • Suricata también cuenta con una comunidad activa, respaldada por la OISF, y beneficia de actualizaciones regulares y un flujo constante de nuevas características.
  • Zeek tiene una comunidad única orientada a investigadores y profesionales de seguridad que comparten scripts, herramientas y mejores prácticas, proporcionando un recurso valioso para usuarios avanzados.

Elección Dependiendo del Contexto Específico

• Tamaño de la Red:
  • Para redes de gran tamaño y alto volumen de tráfico, Suricata puede ser la mejor opción debido a su capacidad de procesamiento multihilo y eficiencia en el manejo de grandes volúmenes de datos.
  • En redes más pequeñas o en entornos donde el análisis detallado es más crítico que el volumen de tráfico, Snort y Zeek pueden ser más adecuados.
• Recursos Disponibles:
  • Organizaciones con recursos limitados pueden preferir Snort por su amplia base de usuarios y soporte comunitario.
  • Aquellas con la capacidad de invertir en hardware más potente para el análisis de tráfico podrían inclinarse por Suricata o Zeek.
• Nivel de Experiencia Técnica:
  • Snort puede ser una buena entrada para aquellos nuevos en la detección de intrusiones, mientras que Suricata ofrece una opción robusta para aquellos con algo más de experiencia.
  • Zeek es particularmente adecuado para usuarios con un alto nivel de experiencia técnica que desean una personalización profunda y análisis detallado.

La elección entre Snort, Suricata y Zeek debe basarse en una evaluación cuidadosa de las necesidades específicas de seguridad, recursos disponibles y experiencia técnica. Cada herramienta tiene sus fortalezas y puede ser la mejor opción en diferentes contextos. La consideración de estos factores ayudará a garantizar que se elija la solución más adecuada para proteger la infraestructura de red contra amenazas.

Implementación y Mejores Prácticas para Sistemas de Detección de Intrusiones (IDS)

La implementación de un Sistema de Detección de Intrusiones (IDS) es una parte crucial de la estrategia de seguridad en cualquier organización. Su correcta configuración y mantenimiento pueden significar la diferencia entre detectar a tiempo una intrusión potencialmente devastadora y dejar pasar inadvertida una amenaza. Aquí se detallan algunos consejos y mejores prácticas para la implementación efectiva de un IDS, así como para la gestión de alertas y la respuesta a incidentes.

Implementación Efectiva de un IDS

• Monitoreo del Tráfico de Red:
  • Cobertura Completa: Asegúrate de que el IDS tenga visibilidad sobre todo el tráfico de red relevante. Esto puede implicar la colocación estratégica de sensores IDS en puntos clave de la red donde el tráfico de datos es más significativo.
  • Análisis de Tráfico Cifrado: Considera la capacidad del IDS para manejar tráfico cifrado, dado que muchas amenazas ahora se ocultan dentro de conexiones seguras. La descifrado, cuando sea legal y éticamente apropiado, puede ser necesario para una inspección profunda del paquete.
• Ajuste de la Configuración:
  • Personalización: Ajusta las configuraciones y reglas del IDS según el entorno específico de tu red y las políticas de seguridad de tu organización. Lo que funciona para una red puede no ser adecuado para otra.
  • Minimización de Falsos Positivos y Negativos: Trabaja continuamente en el ajuste de las reglas para reducir los falsos positivos, que pueden sobrecargar al equipo de seguridad, sin incrementar los falsos negativos, que representan amenazas no detectadas.
• Actualización Regular de las Reglas:
  • Mantente Actualizado: Las amenazas evolucionan constantemente, por lo que es crucial mantener el sistema de detección de intrusiones actualizado con las últimas reglas y firmas de ataques.
  • Suscripciones a Fuentes de Inteligencia de Amenazas: Utiliza fuentes de inteligencia de amenazas para enriquecer las capacidades de detección del IDS, permitiendo que el sistema reconozca las últimas tácticas, técnicas y procedimientos utilizados por los atacantes.

Gestión de Alertas y Respuesta a Incidentes

• Priorización de Alertas:
  • Clasificación de Alertas: Desarrolla un sistema para clasificar alertas basado en su gravedad y potencial impacto, lo que permitirá a tu equipo centrarse primero en las más críticas.
  • Contextualización: Incorpora contexto a las alertas para ayudar en la rápida evaluación de su importancia. Esto incluye datos sobre los activos afectados, vulnerabilidades conocidas y correlación con otros eventos de seguridad.
• Procesos de Respuesta a Incidentes:
  • Planes de Respuesta Predefinidos: Establece procedimientos y planes de respuesta específicos para diferentes tipos de alertas. Esto debe incluir pasos claros para la contención, erradicación y recuperación de incidentes.
  • Automatización: Donde sea posible, automatiza las respuestas a incidentes comunes para acelerar la resolución y reducir la carga de trabajo manual del equipo de seguridad.
• Revisión y Aprendizaje Continuo:
  • Análisis Post-Incidente: Después de un incidente, realiza un análisis detallado para entender qué sucedió, cómo se detectó la amenaza, cómo se respondió y cómo se puede mejorar la detección y respuesta en el futuro.
  • Capacitación y Sensibilización: Asegúrate de que todos los miembros del equipo de seguridad estén continuamente capacitados en las últimas tendencias de ciberseguridad, técnicas de ataque y estrategias de defensa.

Implementar y mantener un IDS eficazmente es una tarea compleja que requiere un enfoque proactivo y un compromiso con la mejora continua. Al seguir estas mejores prácticas, las organizaciones pueden fortalecer significativamente su capacidad para detectar y responder a las amenazas de seguridad, protegiendo así sus activos críticos y manteniendo la integridad de sus sistemas y datos.

Conclusión

Los Sistemas de Detección de Intrusiones (IDS) representan una faceta crítica de la ciberseguridad, crucial para la protección integral de las infraestructuras de Tecnologías de la Información (TI). A medida que el panorama de amenazas evoluciona con ataques cada vez más sofisticados y diversificados, la necesidad de implementar y mantener IDS eficientes se hace más evidente. Estas herramientas no solo ofrecen la capacidad de detectar actividades maliciosas en tiempo real, sino que también proporcionan una visión profunda del tráfico de red, lo que permite a los equipos de seguridad identificar patrones sospechosos y responder adecuadamente antes de que se materialicen daños significativos.

La importancia de los IDS dentro de la infraestructura de TI trasciende la simple detección de ataques. Estos sistemas juegan un papel vital en la estrategia de defensa en profundidad, complementando otras medidas de seguridad como firewalls, sistemas de prevención de intrusiones (IPS), y soluciones antivirus. Al monitorear continuamente el tráfico de red y los sistemas host para detectar actividades anómalas o maliciosas, los IDS proporcionan una capa adicional de seguridad que fortalece la postura general de ciberseguridad de una organización.

La elección del IDS adecuado, sin embargo, no es una decisión que deba tomarse a la ligera. Cada herramienta de IDS, ya sea Snort, Suricata o Zeek, viene con sus propias fortalezas, debilidades y áreas de especialización. La decisión de implementar una solución específica debe basarse en una evaluación detallada de las necesidades específicas de seguridad de la organización, la infraestructura de red existente, los recursos disponibles, y el nivel de experiencia técnica del equipo de seguridad.

Para redes de alto rendimiento que manejan grandes volúmenes de datos, Suricata, con su capacidad de procesamiento multihilo, puede ofrecer la eficiencia necesaria. Para organizaciones que buscan una solución madura y ampliamente soportada con una gran base de reglas, Snort podría ser la opción preferida. Por otro lado, Zeek se destaca por su flexibilidad y capacidad de análisis detallado del tráfico, lo que lo hace ideal para entornos que requieren un alto grado de personalización y análisis forense.

En última instancia, la implementación exitosa de un IDS requiere no solo la selección de la herramienta adecuada, sino también un compromiso continuo con las mejores prácticas de configuración, mantenimiento y respuesta a incidentes. Esto incluye el ajuste regular de la configuración para minimizar los falsos positivos, la actualización constante de las reglas para detectar las últimas amenazas, y el desarrollo de un proceso efectivo de gestión de alertas y respuesta a incidentes.

Los IDS son, sin duda, componentes indispensables de una estrategia de seguridad robusta. Sin embargo, su eficacia está intrínsecamente ligada a la habilidad de la organización para integrarlos adecuadamente dentro de su ecosistema de seguridad, personalizarlos según las necesidades únicas del entorno, y responder de manera efectiva a las alertas generadas. En el contexto actual de amenazas cibernéticas en constante evolución, la capacidad de una organización para proteger sus activos de información depende en gran medida de su enfoque proactivo hacia la seguridad de la red, en el cual los IDS juegan un papel central.

Referencias

La implementación y gestión eficaces de los Sistemas de Detección de Intrusiones (IDS) como Snort, Suricata y Zeek requieren acceso a una amplia gama de recursos de aprendizaje y soporte. A continuación, se presenta una lista de referencias útiles, incluyendo documentación oficial, estudios de caso, tutoriales y recursos comunitarios para cada uno de estos sistemas.

Snort

• Documentación Oficial: La documentación oficial de Snort proporciona una guía exhaustiva sobre la instalación, configuración y operación de Snort. Disponible en: https://www.snort.org/documents
• Tutoriales: Los tutoriales de Snort, disponibles en su sitio web oficial y en plataformas como YouTube, ofrecen instrucciones paso a paso para usuarios de todos los niveles.
• Recursos Comunitarios: La comunidad de Snort en https://www.snort.org/community es un lugar excelente para encontrar soporte, compartir configuraciones y discutir las mejores prácticas.
• Estudios de Caso: Diversos estudios de caso sobre la implementación de Snort en entornos empresariales pueden ser encontrados a través de búsquedas en internet, proporcionando perspectivas reales sobre su aplicación y beneficios.

Suricata

• Documentación Oficial: La Open Information Security Foundation (OISF) mantiene una documentación detallada de Suricata, que es esencial para cualquier implementación. Disponible en: https://suricata.readthedocs.io/en/suricata-6.0.0/
• Tutoriales: Hay una amplia gama de tutoriales disponibles en línea para ayudar a los usuarios a comenzar con Suricata, desde la configuración inicial hasta el análisis avanzado de tráfico.
• Recursos Comunitarios: El foro de Suricata en https://forum.suricata.io/ y otros grupos en plataformas de redes sociales son excelentes recursos para obtener soporte y consejos de la comunidad.
• Estudios de Caso: Investigaciones y publicaciones específicas sobre el uso de Suricata en diferentes sectores industriales pueden proporcionar una visión valiosa sobre su adaptabilidad y eficacia.

Zeek

• Documentación Oficial: La documentación de Zeek es un recurso invaluable que ofrece una visión completa sobre cómo utilizar y personalizar Zeek. Disponible en: https://docs.zeek.org/en/current/
• Tutoriales: Los tutoriales específicos de Zeek, que van desde configuraciones básicas hasta el desarrollo de scripts avanzados, son accesibles a través de su sitio web oficial y plataformas de aprendizaje en línea.
• Recursos Comunitarios: La comunidad de Zeek, accesible en https://zeek.org/get-involved/, ofrece una amplia gama de recursos, incluyendo una lista de correo, Slack y eventos como ZeekWeek para fomentar el aprendizaje y la colaboración.
• Estudios de Caso: Los estudios de caso sobre Zeek ofrecen insights sobre cómo esta herramienta se ha implementado en entornos complejos para resolver problemas de seguridad específicos.

Estos recursos representan puntos de partida esenciales para aquellos interesados en profundizar en la teoría y práctica de los IDS. Ya sea que estés buscando implementar un nuevo sistema de detección de intrusiones, optimizar una configuración existente o simplemente expandir tu conocimiento en el área, la documentación oficial, tutoriales, recursos comunitarios y estudios de caso proporcionan una base sólida sobre la cual construir tu experiencia.

El tema social es muy interesante, pero a mi me ha llamado la atención el tema de los bots, porque se hablaba de un bot llamado CCBot que debe de ser un bot con un gusto excelente porque por esta web ya ha pasado, de hecho este año lleva ya 688 visitas, que no son muchas, pero sí las suficientes para haber visto lo que le interesaba y haberlo procesado.

Además tenemos el bot GPTBot que ha visitado este humilde blog ya 1495 veces.

No se qué hará ese bot en concreto, pero parece ser que alimenta a Common Crawl, uno de los mayores conjuntos de datos de IA. El bot BGPBot supongo que como su nombre indica es el bot de ChatGPT y GPT-4.

El tema aquí está en que si esos bots revisan tu web y luego sirven el contenido desde sus aplicaciones, por supuesto sin mencionar desde donde lo han obtenido, al final la gente va a dejar de revisar las webs.

Ante esto hay quien prefiere bloquear estos bots, realmente los user-agent que usan, ¿pero como se hace?, simplemente modificando en el .htaccess de tu web y añadiendo un par de líneas como estas:

#BLOQUEAR CRAWLERS INDESEADOS
RewriteCond %{HTTP_USER_AGENT} (CCBot|GPTBot) [NC]
RewriteRule .* - [R=403,L]

Obviamente a la lista podéis añadir todos aquellos bots que consideréis indeseables para vuestra web.

Ahora, ¿esto sirve para algo? Pues sí, si una visita se identifica con un bot de ese tipo le dará un 403 y no podrá cargar la web.

Todo tiene su user-agent, por ejemplo, si usáis Firefox el user-agent será Mozilla/5.0, pero esto es cambiable, para hacerlo podéis seguir los siguientes pasos:

1. Abrir about:config
2. Aceptar el aviso
3. Buscar general.useragent.override, que no va a estar.
4. Pinchar en cadena y en el botón +
5. Ahora te saldrá un recuadro para rellenar, ahí puedes poner el user-agent que quieras

Una vez cambiado el user-agent cuando visites una web saldrá el user-agent que le hayas puesto ahí.

Foto de cabecera de Mat Kedzia: https://www.pexels.com/es-es/foto/foto-de-primer-plano-de-la-arana-2091017/

La presentación versó en una introducción a Vyos en el Centro de Datos, porque al fin y al cabo es lo que usamos en Tecnocrática para la red.

La presentación fue muy amena, al menos a mi me resultó muy amena gracias a aquellas personas que asistieron y que quiero darles las gracias de nuevo.

La presentación se grabó, pero en la grabación no se ve muy bien lo que se estaba proyectando así que he vuelto a grabarla para que podáis tener las diapos.

El vídeo lo tenéis en el canal de You Tube que hemos abierto en Tecnocrática (https://www.youtube.com/@TecnocraticaNet)

De todos modos aquí debajo os dejo las configuraciones usadas:

VyOS1
=====
configure
set system host-name vyos1
set interfaces ethernet eth1 address 198.51.100.1/24
set interfaces loopback lo address 192.0.2.1/32

set protocols ospf area 0 network '198.51.100.0/24'
set protocols ospf area 0 network '192.0.2.1/32'
set protocols ospf interface eth1
set protocols ospf redistribute connected


VyOS2
=====
configure
set system host-name vyos2
set interfaces ethernet eth1 address 198.51.100.2/24
set interfaces loopback lo address 192.0.2.2/32

set protocols ospf area 0 network '198.51.100.0/24'
set protocols ospf area 0 network '192.0.2.2/32'
set protocols ospf interface eth1
set protocols ospf redistribute connected


VyOS3
=====
configure
set system host-name vyos3
set interfaces ethernet eth1 address 198.51.100.3/24
set interfaces loopback lo address 192.0.2.3/32

set protocols ospf area 0 network '198.51.100.0/24'
set protocols ospf area 0 network '192.0.2.3/32'
set protocols ospf interface eth1
set protocols ospf redistribute connected


=============
LABORATORIO 2
=============

VyOS3
=====
set protocols ospf default-information originate


set interfaces ethernet eth2 address 203.0.113.1/24


set protocols ospf area 0 network '203.0.113.0/24' ?????????????


VyOS4
=====
configure
set system host-name vyos4
set interfaces ethernet eth0 address 203.0.113.2/24


VyOS3
=====
configure
set protocols bgp system-as '15954'
set protocols bgp neighbor 203.0.113.2 address-family ipv4-unicast
set protocols bgp neighbor 203.0.113.2 remote-as 100
set protocols bgp address-family ipv4-unicast import
set protocols bgp parameters router-id '203.0.113.1'


set protocols bgp address-family ipv4-unicast network 192.168.150.0/24


set policy route-map Todo rule 1 action 'permit'
set protocols bgp neighbor 203.0.113.2 address-family ipv4-unicast route-map export 'Todo'
set protocols bgp neighbor 203.0.113.2 address-family ipv4-unicast route-map import 'Todo'


VyOS4
=====
configure
set protocols bgp system-as 100

set protocols bgp neighbor 203.0.113.1 address-family ipv4-unicast
set protocols bgp neighbor 203.0.113.1 remote-as 15954
set protocols bgp address-family ipv4-unicast import
set protocols bgp parameters router-id 203.0.113.2




set policy route-map Todo rule 1 action 'permit'
set protocols bgp neighbor 203.0.113.1 address-family ipv4-unicast route-map export 'Todo'
set protocols bgp neighbor 203.0.113.1 address-family ipv4-unicast route-map import 'Todo'

Red Alert: ICANN and Verisign Proposal Would Allow Any Government In The World To Seize Domain Names

En esta noticia se hacen eco de unos posibles cambios en la política de nombres de dominio en la extensión .net. Según esa noticia se estaría preparando una modificación que permitiría a cualquier Gobierno / Autoridad Administrativa / Autoridad Gubernamental / Tribunal Competente…. denieguen, cancelen, redirijan o transfieran cualquier dominio registro de nombres, en otras palabras, se podrían confiscar dominio por cualquier entidad con «autoridad» y claro, esto pues podría supone un problema.

De momento este borrador sólo afecta a los dominios con extensión .net, pero podría afectar a los .com en un futuro no muy lejano.

El documento en cuestión está vivo en https://itp.cdn.icann.org/en/files/registry-agreement/redline-proposed-amendment-2017-net-registry-agreement-11-04-2023-en.pdf, pero os dejo una copia también por aquí por si queréis verla o si desapareciese.

Estos cambio son bastante preocupantes y en la web de freespeech.com ponen una serie de ejemplos que se podrían dar si esta nueva versión de la normativa entrase en juego.

1. El gobierno de China ordena que se suspendan (o simplemente se transfieran al gobierno chino) los nombres de dominio que operan sitios web que critican sus políticas.
2. El gobierno de Rusia, en guerra con Ucrania, ordena la transferencia de nombres de dominio pro-ucranianos al control del gobierno ruso.
3. El gobierno de Ucrania, en guerra con Rusia, ordena la transferencia de nombres de dominio prorrusos al control del gobierno ucraniano.
4. El gobierno de Texas ordena que los nombres de dominio a favor del aborto se transfieran al gobierno de Texas.
5.  El gobierno talibán en Afganistán ordena que los nombres de dominio a favor del aborto y aquellos que promueven la educación de las niñas sean transferidos al gobierno.
6.  El gobierno de Irán ordena que todos los nombres de dominio en todo el mundo con contenido «para adultos» (es decir, pornografía) se transfieran al gobierno iraní.
7. El gobierno de Tuvalu, (que ya licencia el registro .TV para recaudar fondos) que enfrenta una crisis económica debido al cambio climático, ordena que cada punto-net de 2 letras, 3 letras y una palabra sea transferido al gobierno de Tuvalu, con el fin de subastar los nombres de dominio para recaudar nuevos fondos para ellos mismos.
8. Un gobierno en Argentina lanza un nuevo programa cuyo nombre resulta ser idéntico al nombre de dominio propiedad de una empresa francesa durante los últimos 25 años. El gobierno de Argentina ordena que se les transfiera el nombre de dominio, sin compensación por la expropiación.
9. El gobierno de Italia está molesto por una empresa de redes sociales que opera desde China y ordena que el nombre de dominio de la empresa china se transfiera al gobierno italiano.
10. El gobierno del Reino Unido está molesto porque el software publicado por una empresa sueca tiene cifrado de extremo a extremo. Ordena transferir el nombre de dominio de la empresa sueca al gobierno del Reino Unido.

Si esto se permitira a todo el mundo imaginad el descontrol que esto podría ser. Por suerte de momento está todo en borrador y es probable que no salga adelante, pero hay que andar con cuidado, porque estas cosas pasan cada vez más a menudo

Pero hoy no quiero hablar de proxmox, sino de proxmox backup server, que es el servicio de backup de proxmox.

La instalación es muy similar a la de proxmox VE, el hipervisor, y para entrar en vez de utilizar el puerto 8006 se utilizará el puerto 8007, lo cual, no se lo digáis a nadie, pero permite instalar el PBS en el mismo servidor que el Proxmox VE.

Instalar ambos softwares en el mismo hipervisor está bien si lo que queremos es un laboratorio o si tenemos dos servidores y hacemos copias cruzadas. De todos modos, que se pueda no significa que sea buena idea. Recordad que no todo lo que se puede hacer es buena idea, se puede beber lejía, pero yo no lo haría.

PBS tiene cuatro cosas muy graciosas que le hacen ser un software maravilloso:

1. La deduplicación en las copias de seguridad, es decir, el backup va a ocupar muy poquito espacio.En el caso de KVM que las copias son muy rápidas y ligeras. En LXC el backup no es tan eficiente, pues hace copia de la máquina completa.
2. Retención y rotación de backups. Puedes tener las copias de seguridad y retenerlas con la antigüedad que quieras, por ejemplo backups cada hora, día, semana, mes, año. Una maravilla vamos.
3. Por supuesto la integración con Proxmox VE es total y absoluta.
4. PBS hace replicación entre PBS, con lo cual puedes tener siempre un backup externo en otro lado porque siempre va a estar sincronizado con tu PBS principal

PBS es un componente integral de la plataforma de virtualización Proxmox VE, y se integra perfectamente con el hipervisor Proxmox VE para proporcionar una solución de copia de seguridad completa. PBS ofrece una amplia gama de características, como la capacidad de realizar copias de seguridad de forma incremental, comprimir y cifrar los datos de respaldo, y programar copias de seguridad de manera automática.

PBS utiliza la tecnología de copia de seguridad basada en Zstandard y deduplicación de datos, lo que permite reducir significativamente el tamaño de las copias de seguridad y, por lo tanto, el espacio de almacenamiento requerido. También es compatible con varios tipos de almacenamiento de respaldo, como discos duros, almacenamiento de red (NAS) y sistemas de almacenamiento en la nube.

• Por si no lo conocéis Zstandard es un algoritmo de compresión muy rápido que se distribuye de forma gratuita con licencia BSD. Es un algoritmo desarrollado en Facebook, un lugar donde se hacen cosas muy interesantes.
• Y la deduplicación lo que hace es ir buscando trozos de 4KB y le asigna un hash a cada uno. Al final si se ve un bloque duplicado no se guarda y sólo se almacenan bloques únicos, por eso el ahorro de espacio es tan salvaje. La deduplicación no es sólo no guardar dos veces el mismo fichero, sino que va mucho más allá, es algo mucho más sesudo y complicado de implementar, pero PBS nos lo ofrece gratis.

PBS es una solución maravillosa, pero como os contaba en el audio anterior si tenemos el PBS en nuestras oficinas tenemos que tener en cuenta que sólo en electricidad nos va a costar unos 70 euros al mes, además de la amortización de hardware, control de discos, el que la sala no sea lo más adecuado, etc…

Así que una opción estupenda es tener el PBS en un Centro de Datos externo o incluso si tenéis el Proxmox VE en un Centro de Datos tener las copias en otro Centro de Datos.

La opción tradicional consiste en levantar un servidor nuevo en otro Centro de Datos, o bien usar un servicio de PBS remoto como el que ofrecemos nosotros en Tecnocrática, es cuestión de echar números y mirar qué es lo que más nos interesa. También se puede usar nuestro PBS para replicar el PBS que tengas

Pensar que la cantidad de datos que necesitáis de PBS es muy baja gracias a la deduplicación, así que quizás os interese hacer los backups en un PBS externo como el nuestro. Nosotros en Tecnocrática, por cierto cobramos 50 euros al mes el Tera usado y neto en el PBS que es mucho menso de lo que realmente se hace backup por lo que os he contado antes. Además en ese servicio nosotros nos encargamos de todo y tú sólo tienes que preocuparte de que las copias de seguridad se lancen.

Os recomiendo que os deis una vuelta por el resto de los vídeos ya que los tenéis muy interesantes: https://commons.wikimedia.org/wiki/Category:EsLibre_2021

Voy a contaros paso a paso qué es lo que he hecho:

Obtener el tráfico de netflow

Para ello me he contectado por ssh al netflow de turno y he generado un fichero pcap con el tráfico que quería capturar que era el que enviaba uno de los routers:

tcpdump -i eth1 src 10.0.0.0.1 -w mi_router.pcap

Con esto generamos el fichero mi_router.pcap, obviamente en mi caso el fichero no se llama así y la IP tampoco es esa, cada uno tendrá que poner los datos que le correspondan, pero la 10.0.0.1 es la IP origen desde la que se generan los flujos con dirección al netflow.

Ahora bajamos ese fichero con un scp o lo que sea al ordenador local, en mi caso un portátil.

Abrimos Wireshark

Ahora abrimos ese fichero con wireshark, entramos en cualquier paquete y oh, sorpresa, no se puede ver nada de nada:

El tráfico de Netflow viene en la parte de abajo, dentro del Data de UDP, así que si habéis llegado hasta aquí que sepáis que aún os queda un paso.

Decodificar

Ahora vamos a la sección de arriba y con el botón derecho le damos a «Decode as» y en la columna Current seleccionamos CFLOW.

Le damos aceptar y mágicamente ya podemos ver la información de Netflow, en este caso podéis ver una respuesta a una petición de DNS:

• mango: Nombre con el que queremos identificarnos en los registros, puede ser lo que querramos y recordad que si queremos que haya espacios en medio pondremos — (dos guiones)
• abcdef: Nuestro ID de cliente
• nextdns.io: esto siempre tiene que ser así

Antes de realizar la modificación de la configuración de TLS con Cloudflare para adaptarla a TLS con NextDNS yo os recomendaría guardar un backup, con:

cp /etc/stubby/stubby.yml /etc/stubby/stubby.yml.cloudflare

Una vez hecho esto simplemente comentamos las líneas correspondientes de Cloudflare y añadimos las de NextDNS y os quedará un fichero como este:

root@GL-MT300N-V2:/etc/stubby# cat stubby.yml
#NOTE: See '/etc/stubby/stubby.yml.default' for original config file and descriptions

resolution_type: GETDNS_RESOLUTION_STUB

dns_transport_list:
  - GETDNS_TRANSPORT_TLS

tls_authentication: GETDNS_AUTHENTICATION_REQUIRED

tls_query_padding_blocksize: 128

edns_client_subnet_private : 0

round_robin_upstreams: 0

idle_timeout: 10000

listen_addresses:
  - 127.0.0.1@53535
  -  0::1@53535

upstream_recursive_servers:
# IPv6 addresses
# # Cloudflare IPv6
#  - address_data: 2606:4700:4700::1111
#    tls_port: 853 
#    tls_auth_name: "cloudflare-dns.com"

# # Cloudflare IPv6 secondary
#  - address_data: 2606:4700:4700::1001
#    tls_port: 853
#    tls_auth_name: "cloudflare-dns.com"

# # Quad 9 IPv6
#  - address_data: 2620:fe::10
#    tls_auth_name: "dns.quad9.net"

# IPv4 addresses
# # Cloudflare servers
#  - address_data: 1.1.1.1
#    tls_port: 853
#    tls_auth_name: "cloudflare-dns.com"
                      
# # Cloudflare servers secondary     
#  - address_data: 1.0.0.1          
#    tls_port: 853                  
#    tls_auth_name: "cloudflare-dns.com"

# Quad 9 service
#  - address_data: 9.9.9.10
#    tls_auth_name: "dns.quad9.net"

# NextDns service
  - address_data: 45.90.28.0
    tls_port: 853
    tls_auth_name: "mango-abcdef.dns1.nextdns.io"
  - address_data: 2a07:a8c0::0
    tls_port: 853
    tls_auth_name: "mango-abcdef.dns1.nextdns.io"
  - address_data: 45.90.30.0
    tls_port: 853
    tls_auth_name: "mango-abcdef.nextdns.io"
  - address_data: 2a07:a8c1::0
    tls_port: 853
    tls_auth_name: "mango-abcdef.nextdns.io"

Una vez hecho el cambio simplemente reiniciar el servicio y a funcionar con tus DNSs de NextDNS en Gl.iNet.

/etc/init.d/stubby restart

Configuración en Cisco

interface gigabitethernet4/1
    switchport mode trunk
    switchport trunk allowed vlan 100, 200
    switchport trunk native vlan 1

interface gigabitethernet 1/1
    switchport mode access
    switchport access vlan 100

En Cumulus Linux es un poco más complicado y la configuración sería del estilo:

Configuración en Cumulus Linux

auto bridge
iface bridge
    bridge-ports swp1 swp2 swp3
    bridge-vlan-aware yes
    bridge-stp on
    bridge-vid 100 200
    bridge-pvid 1

auto swp1
iface swp1
    bridge-access 100

Ambas configuraciones son más o menos equivalentes, la diferencia principal estriba en que en cisco hay PVST+ y en Cumulus Linux se comparte la instancia de spanning entre las dos vlans porque estamos utilizando vlan aware.

Con esta configuración en dos switches conseguiríamos que dos PCs se vieran directamente a través de ellos utilizando el puerto swp2 de ambos switches, de momento el swp3 lo dejamos sin uso:

También hablé de Cúmulus aquí y aquí.

Foto de cabecera de Vikas Sawant desde Pexels

Básicamente montar un servicio de Icecast básico es instalar el software icecast2 y configurarlo..

Una vez configurado ya podemos transmitir en directo desde nuestras cosas, pero … ¿Cómo puedes hacer para que icecast siga transmitiendo aunque no estemos transmitiendo?

Lo que se tiene que hacer es montar un automatizador, el más sencillo es sin duda es ezstream.

Realmente lo más sencillo es contratar todo montado y que nos pongan un panel como Centova, pero quizás queramos ahorrarnos ese dinero, sobre todo si lo que queremos es hacer transmisiones amateur.

Lo primero será tener un fichero de configuración de ejemplo, os pego una configuración mía:

<!--
   EXAMPLE: MP3 playlist stream WITHOUT reencoding

   This example streams a playlist that contains only MP3 files. No other file
   formats may be listed. Since ezstream will not be doing any reencoding, the
   resulting stream format (bitrate, samplerate, channels) will be of the
   respective input files.
 -->
<ezstream>
    <url>http://xxxxxxx.eduardocollado.com:8000/musica</url>
    <!--
      If a different user name than "source" should be used, set it in
      <sourceuser/>:   --> 
    <sourceuser>usuario_secreto</sourceuser>

    <sourcepassword>password_secreta</sourcepassword>
    <format>MP3</format>
    <filename>/home/mp3/podcast/playlist.txt</filename>
    <!-- Once done streaming playlist.m3u, exit: -->
    <stream_once>0</stream_once>
    <shuffle>0</shuffle>
   
    <svrinfoname>Musica libre</svrinfoname>
    <svrinfourl>https://www.eduarodcollado.com</svrinfourl>
    <svrinfogenre>Talk</svrinfogenre>
    <svrinfodescription>Stream de musica libre sin derechos y tecnologia</svrinfodescription>
    <svrinfobitrate>128</svrinfobitrate>
    <svrinfochannels>2</svrinfochannels>
    <svrinfosamplerate>44100</svrinfosamplerate>
    <svrinfopublic>0</svrinfopublic>
</ezstream>

En la siguiente línea indico cual es el host donde hay que hacer el streaming, el ezstream no tiene por qué estar en el mismo servidor que el icecast

<url>http://xxxxxxx.eduardocollado.com:8000/musica</url>

Ahora tendremos que indicar el usuario y contraseña de ese stream:

<sourceuser>usuario_secreto</sourceuser> 
<sourcepassword>password_secreta</sourcepassword>

Inidicamos el formato de la transmisión, en mi caso mp3:

<format>MP3</format>

Ahora indicamos la lista con los ficheros de audio

<filename>/home/xxxxx/musica/playlist.txt</filename>

El fichero con la lista tendría una pinta tal que así:

root@icecast:~# cat /home/musica/playlist.txt 
/home/mmusica/cctrax/Echo_Delta_-_Blu_Eon_mp3_320_kbps/01_Mistyfog.mp3
/home/musica/cctrax/Echo_Delta_-_Blu_Eon_mp3_320_kbps/02_Morph.mp3
/home/musica/podcast/podcast-130-ipsec.mp3
/home/musica/cctrax/Echo_Delta_-_Blu_Eon_mp3_320_kbps/03_Inly.mp3
[...]

Este fichero puede ser todo lo largo que queráis.

Las dos líneas siguiente son bastante importantes y nos indican cómo trabajar con la lista de ficheros:

<stream_once>0</stream_once>
<shuffle>0</shuffle>

Le decimos que puede hacer streaming más de una vez, para que haga un bucle y le decimos que no lo haga de forma aleatoria, es decir, que lea los ficheros de forma secuencial.

Las siguientes líneas ya no son tan importantes.

Algo que tenemos que tener en cuenta es que quizás queramos tener más de un stream en el servidor, para ello podemos lanzar tantos procesos ezstream como queramos, lo único que tenemos que tener en cuenta es que por defecto icecast sólo permite dos streams y eso lo podemos cambiar en:

$cat /etc/icecast2/icecast.xml
[...]
    <limits>
        <clients>100</clients>
        <sources>10</sources>
[...]

Donde pone sources es donde lo definimos. Obviamente luego tenemos que reiniciar el servicio.

Por supuesto tenemos más métodos de automatización, muchos más completos como liquidsoap, pero no ten sencillos.

El comando rename nos va a facilitar muchísimo la vida y podemos hacer cosas muy interesantes.

Por ejemplo, queremos sustituir todos los espacios en los nombres por guiones bajos, además queremos quitar los paréntesis, los guiones medios y los &, ¿cómo podemos hacer todo esto?

rename 's/ /_/g' *
rename 's/\$//g' *
rename 's/\(//g' *
rename 's/\)//g' *
rename 's/\-//g' *

El comando rename para hacer las sustituciones funciona de forma similar a como se hace una búsqueda en vi, así que si sabéis buscar en vi sabéis usar este comando.

Para hacer las sustituciones tendremos que escribir después de rename ‘s/LO_QUE_QUERAMOS_BUSCAR/POR_LO_QUE_QUEREMOS_CAMBIAR/g‘.

Hay que tener en cuenta que a lo mejor es necesario que escapemos caracteres. Por ejemplo si queremos sustituir un & lo suyo es escaparlo con \&.

La cadena entera empezará por s y terminará por g, es todo lo que tenemos que tener en cuenta.

Espero que os sea de utilidad.

Existen varias opciones más complicadas y más sencillas, pero hoy os quiero presentar la opción más sencilla posible, al menos la más sencilla que he encontrado, se llama Podcast Generator.

Esta aplicación necesita solo php, no necesita ni bases de datos ni nada  excepcional, con lo que es perfecta para usuarios que no quieran calentarse la cabeza o que no quieran ningún tipo de complejidad técnica.

Además, el requerir solo php y no mysql hace que en muchos hosters el precio del alojamiento baje muchísimo, por ejemplo en Neodigit hospedar con Podcast Generator un podcast como A Ratos Podcast que tiene 53 capítulos con una calidad mínima por episodio de 128kbps estaría en torno a los 6 euros al mes, pero ampliar tendría un coste de 1,2 euros por cada 50 capítulos aproximadamente, obviamente si son capítulos de 2 horas pues son menos y si son de 5 minutos pues son más los que se pueden subir.

También tiene la ventaja al no tener base de datos que el mantenimiento es más sencillo. Podéis probarlo y ver sus características en http://www.podcastgenerator.net, pero que nadie siga almacenando sus audios por ahí si no es por algún tipo de opción personal.

El software además permite personalizar plantillas de una forma más o menos sencilla, esto no es trivial, y permite hacer muchas cosas. Cualquier duda con el software lo podemos ver sin problemas.

Ya tenemos un nuevo CMS, esta vez más especializado, espero que os guste.

A ese conector DB-15 conectábamos un transceptor AUI / RJ45 y en ese transceptor pinchábamos nuestro cable RJ45.

Transceptores de esos yo creo que tengo todavía alguno en alguna caja en casa, pero no os imaginéis el transceptor como un transceptor de un SFP, estos eran muchísimo más grandes y toscos.

Esos transceptores eran Ethernet y cuando digo Ethernet quiero decir 10-Base-T, es decir, 10Mbps.

Luego salieron los puertos Fast Ethernet a 100Mbps, esto era increíble, podíamos hacer cosas maravillosas como router on stick, pasar vlans, era una cosa increíble, teníamos routers que solo tenían un puerto, o al menos solo usábamos un puerto, todo cabía en 100Mbps.

Posteriormente pasamos a puertos de 1Gbps, a 10Gbps, y ahí se desmadró la cosa.

Del 10G pasamos al 40G que usaban unos interfaces llamados QSFP+ que permitían despeinar ese 40G en 4 puertos de 10G, con adaptadores obviamente.

De ahí pasamos al 100G y así como el que no quiere la cosa al 400G, usando la misma analogía que se usó al pasar del 10G a 40G.

Pues bien, esto ha cambiado de tal manera que a día de hoy, Noviembre de 2018 me encuentro en mi mesa escribiendo sobre redes a 400G.

A la red cada día se le exige más y más, se le exige tanto que a veces cuesta creer que se pueda llegar a hacer más, pero siempre tenemos gente que consigue estirar más y más la capacidad de la red para seguir prestando servicios.

Y claro, no solo velocidad se pide, sino también eficiencia, agilidad … en fin… todo lo que pase por la mente, pero siendo un poco más concretos cada vez es más común pedir a la red el análisis de tráfico a tiempo real, obviamente los buffers tienen que ser más grandes, pero por otro lado se pide que la latencia baje

Obviamente todo esto no se puede ofrecer con la tecnología existente, así que hay que adaptar conectores y tecnología óptica, de hecho en 400G los transceptores son QSFP-DD (Quad Small Form Factor – Double Density).

En cuanto a fabricantes metidos en este berenjenal tenemos varios como son Cisco, Juniper, Huawei o Fujitsu. Aquí se quedan fuera otros como Mikrotik, los cuales no tienen ni la capacidad ni la fuerza necesaria para entrar en este tipo de tecnologías en esta fase tan temprana.

Mientras Huawei ha centrado sus esfuerzos de 400G en el switch Huawei CE9860X, en el que recaerá gran parte de la innovación. El CE9860X actualmente soporta 128 puertos de 100G Cisco ya tiene listos cuatro modelos para ser lanzados a lo largo del 2019

• Nexus 9316D-GX, un switch de 16 puertos y 1U de altura que, según Cisco, funcionará bien en aplicaciones de aplicaciones de infraestructura centrada en la aplicación (ACI).
• Nexus 93600CD-GX, que ofrece 28 puertos de 100GbE y 8 puertos de 400GbE en una sola U para backbone.
• Nexus 3408-S, que cuenta con un chasis de 4U y ocho ranuras que admite 128 puertos de 100GbE o 32 puertos de 400GbE a través de módulos de expansión de tarjeta de línea.
• Nexus 3432D-S, un switch de 1U con 32 puertos de 10/40/100 / 400GbE nativos y 2x200GbE y 4×50 / 100GbE.

El año que viene me parece que vamos a ver el despegue de equipos con puertos de 400G, al menos podremos ver cómo fabricantes empiezan a sacarlos por todas partes., sino tiempo al tiempo.

En mi caso cree la cuenta de Twitter en Marzo de 2007, y claro, casi 12 años después las cosas han cambiado, mi vida ha cambiado y no tengo ni idea de qué he escrito en los 26500 tweets que llevaba escritos, así que he decidido hacer limpieza, por higiene más que nada.

Lo primero que haces es buscar en la propia red social si es posible eliminar tweets antiguos y favoritos, y sí, es posible, pero uno a uno, y claro, borrar 26500 tweets uno a uno no es viable, en absoluto es una opción, así que empiezas a buscar servicios online.

Servicios online hay varios, pero todos tienen el mismo problema, borran hasta 3000 tweets, y ¿qué pasa con los demás 23500? ¿se van a quedar ahí?, pues si sólo usas estos servicios online es así, vas a tener 23500 tweets que no vas a poder borrar, pero tranquilo, que tampoco los vas a ver a no ser que tengas el enlace.

Por alguna razón que desconozco Twitter sólo te muestra los últimos 3000 tweets (ó 3200, no recuerdo muy bien), así que una vez los borres con esos servicios online no vas a ver tweets, pero estarán ahí, de hecho en el perfil de Twitter verás que tienes tweets, aunque no puedas verlos.

Si os parece bien voy a describiros el proceso que he seguido para eliminar el contenido de la red social y hacer un poco de higiene digital a mi persona.

Hacer un backup de vuestros tweets

Lo primero es hacer un backup de vuestros tweets, porque una cosa es quererlos borrar y otra muy diferentes quererlos perder, además, esta información la vamos a necesitar para el borrado de tweets, con lo que además de ser interesante tener una copia de seguridad de vuestra información es necesario.

Para hacer el backup de vuestros tweets tenéis que ir en vuestro perfil a Configuración y Privacidad y después más abajo a Tu archivo de Tweets. ahí lo podéis solicitar. Os llegará un correo al cabo de unas horas con un enlace para descargarlo, será un archivo .zip.

Borrar los tweets

Si al abrir el .zip os encontráis con un fichero tweets.csv entonces estaréis en mi mismo caso y tendréis que bajaros https://github.com/koenrh/delete-tweets, o clonar obviamente, en mi caso he clonado que es más fácil.

Este repositorio contiene un script en python que va borrar el contenido de nuestra cuenta de Twitter, así que tenéis que tener instalado Python y pip en vuestro PC.

Para poderlo ejecutar necesitaréis las claves del API de Twitter, podéis conseguirlas en api.twitter.com y ahí declarando una nueva aplicación. Para cargarlas como variables de entorno en Linux tendréis que hacer lo siguiente:

export TWITTER_CONSUMER_KEY="xxxxxxxxxxxxx"
export TWITTER_CONSUMER_SECRET="xxxxxxxxxxxxx"
export TWITTER_ACCESS_TOKEN="xxxxxxxxxxxxx"
export TWITTER_ACCESS_TOKEN_SECRET="xxxxxxxxxxxxx"

En otros sistemas operativos no tengo muy claro como se haría.

Una vez tengáis esto copiáis en este directorio el fichero tweets.csv que habéis obtenido de vuestro backup.

Bien, una vez cargadas las variables de entorno ya podéis ejecutar el script.

# python ./deletetweets.py -h
usage: deletetweets.py [-h] -d DATE [-r {reply,retweet}]

Delete old tweets.

optional arguments:
-h, --help show this help message and exit
-d DATE Delete tweets until this date
-r {reply,retweet} Restrict to either replies or retweets

Así que tendréis que indicar desde qué fecha queréis que borre, si es desde hoy 2 de Noviembre de 2018 sería así:

# python ./deletetweets.py -d 2018-11-2

Y empezará a borrar los tweets:

.
.
.
Deleting tweet #148406602 (2007-07-13)
Deleting tweet #148732832 (2007-07-13)
Deleting tweet #147859102 (2007-07-13)
Deleting tweet #148133142 (2007-07-13)
Deleting tweet #148144692 (2007-07-13)
Deleting tweet #146365992 (2007-07-12)
Deleting tweet #146406372 (2007-07-12)
Deleting tweet #146406982 (2007-07-12)
Deleting tweet #146687632 (2007-07-12)
Deleting tweet #146700722 (2007-07-12)
Deleting tweet #146850332 (2007-07-12)
Deleting tweet #147053022 (2007-07-12)
Deleting tweet #147062252 (2007-07-12)
Deleting tweet #147186782 (2007-07-12)
Deleting tweet #147192762 (2007-07-12)
Deleting tweet #145003742 (2007-07-11)
Deleting tweet #145004962 (2007-07-11)
Deleting tweet #145021302 (2007-07-11)
Deleting tweet #145131432 (2007-07-11)
.
.
.

Este proceso puede tardar, y de hecho tarda horas, así que armaros de paciencia y es muy probable que os falle, así que si os falla volvéis a empezar el script, pero ajustando la fecha hasta la que hayáis borrado.

Borrado de favoritos

Una vez hayáis borrado los tweets querréis seguramente borrar los favoritos, ya os digo, podéis ir uno por uno, pero seguramente el proceso se va a demorar semanas o meses, así que mucho mejor automatizar la tarea.

Para borrar los favoritos yo he usado un script también de github: https://github.com/martinshelton/Purge-Twitter-Faves.

Una vez descargado tenéis que abrir el fichero favorite_purge.py e introducir ahí vuestras claves de Twitter y vuestro usuario de Twitter.

Después es ejecutarlo y esperar, también unas cuantas horas.

Con esto ya tenéis vuestros datos eliminados y podéis seguir usando vuestra propia cuenta de Twitter sin perder followers ni hacer nada extraño. Y lo mejor, sin depender de servicios de terceros.

Espero que os haya sido útil.

Instalar y mantener un sitio WordPress seguro, y rápido es algo que todos queremos y deseamos, pero que muy pocos lo consiguen. Internet está lleno de WordPress desactualizados, pesados y/o inseguros, y tampoco es cuestión de volverse loco ni obsesivo con la seguridad, simplemente hay que instalar la herramienta de forma correcta y realizar un mantenimiento de periódico de actualizaciones y ajustes necesarios.

En el post de hoy quiero daros una guía para poder instalar un WordPress de forma adecuada con los pasos que personalmente creo que son interesantes, obviamente habrá muchas más opciones por Internet, pero esta es la forma que yo recomiendo.

Instalación

El primer paso será obviamente instalar Wordress, para ello realizaremos una instalación estándar, la única diferencia que recomiendo es que cuando nos pregunte por el prefijo de la base de datos no lo dejemos en wp_, seguro que podemos ser mucho más creativos y poner otras cosas como epsteuagi_vlodaor_ o cualquier cosa que se nos pase por la cabeza en ese momento.

[…]simplemente hay que instalar la herramienta de forma correcta y realizar un mantenimiento de periódico de actualizaciones y ajustes necesarios[…]

No os cuento como realizar una instalación básica de WordPress pues tenéis miles de tutoriales para hacer esto, símplemente recordar cambiar el prefijo de las tablas de la base de datos.

Una vez instalado lo primero va a ser establecer el esquema de URL, a lo que nosotros queramos, esto lo haremos en Ajustes – Enlaces Permanentes.

El siguiente paso puede ser si queréis quitar el famoso category, cuando entras en una categoría, pero no cambiarlo por otra cosa, sino directamente quitarlo, a mi me resulta muy molesto tener ese category u otra palabra ahí en medio, por eso siempre recomiendo quitarlo, el problema es que si lo quitamos poniendo en la misma página en la que estamos un punto «.» en Categoría Base nos van a fallar otras cosas en el futuro, y si váis directamente a modificar en el .htaccess también, así que hay que modificar dentro de WordPress, para eso hay un plugin muy tontorrón que se llama No Category Base (WPML) y que lo hará por vosotros, esto obviamente no es necesario ni va a hacer que nuestro sitio sea más seguro, pero siempre quedará mejor que las URLs no tengan cosas en medio que estorben y como estábamos en la sección de establecer los enlaces permanentes era interesante comentarlo aquí.

Certificado SSL

Ahora vamos a activar el SSL, es decir, el https, para ello lo primero que vais a necesitar es un certificado, puede ser desde un Let’s Encrypt hasta el certificado más caro que os podáis imaginar, esto tenéis que preguntarlo en vuestro hosting, entiendo que estando en 2018 esto estará ya superado, así que no deberíais de encontrar ningún problema para ello. Una vez instalado podéis cambiar a mano la URL base de vuestro Wordress e ir con mucho cuidado o instalar otro plugin, en este caso se llama Really Simple SSL que lo hará todo por vosotros.

Siguiente paso arreglar un poco el .htaccess, necesitamos que todo esto que estamos montando funcione correctamente, así que vamos a editar el fichero .htaccess y vamos a añadir las siguientes líneas para solucionar problemas del strict transport, entiendo que vuestro dominio va a ser con www, si lo queréis sin www tenéis que modificar las dos últimas líneas.

<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000; preload" env=HTTPS
</IfModule>
#FORZAR A www con HTTPS
RewriteEngine On
RewriteCond %{HTTP_HOST} ^vuestro_dominio.com [NC]
RewriteRule ^(.*)$ https://www.vuestro_dominio.com/$1 [L,R=301]

Ahora ya está nuestro WordPress instalado con https, con las URLs como queremos y si lo consultamos con http:// nos va a responder siempre con https:, esto empieza a tomar forma.

Seguridad

El siguiente aso será potenciar la seguridad del sitio, esto lo vamos a hacer modificando permisos de ficheros, añadiendo líneas en el .htaccess y con plugins, la combinación de las tres cosas.

Todos los ficheros estarán en 644 y los directorios en 755, esto es fundamental y tiene que ser así.

Ahora llegamos a un tema peliagudo, hay muchos sitios que recomiendan que se cambie la base del wp-content y del wp-admin. Cambiar el wp-content, esto se recomienda como una acción que hay que realizar sí o sí, pero el wp-content se ve perfectamente en el código fuente que genera WordPress por qué se ha cambiado y wp-admin sí podría ser interesante si nuestro servidor no puede ofrecernos una capa de seguridad basada en fail2ban para evitar ataques de fuerza bruta, bueno, se pueden cambiar, no hay problema, pero yo relego la parte del wp-admin a la seguridad que proporciona el servidor gracias al fail2ban evitando ataques de fuerza bruta o más fácil restringiendo el acceso por .htaccess. El cambio se puede hacer fácilmente con el plugin WP better security, pero yo no utilizo ese plugin.

En el .htaccess bloqueo el spam referido, es decir, que nos puedan meter comentarios en vuestro WordPress desde cualquier sitio que nos sea el propio post, esto os va a quitar muchísimo spam, y lo que también hago es bloquear el acceso al xmlrpc.php y al wp-login desde mis IPs, ojo que también lo que hago es permitir acceso al xmlrpc.php desde el rango 192.0.64.0/18, ese es el direccionamiento de Automatic, si no permitís esto no os funcionará el Jetpack.

También nos vamos a proteger de la ejecución de ficheros que ahí no deberían de estar.

# BLOQUEO SPAM NO REFERIDO
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_REFERER} !^http(s)?://([^.]+\.)?vuestro_dominio\.com [NC]
RewriteCond %{REQUEST_URI} /wp-comments-post\.php [NC]
RewriteRule .* - [F,L]
</IfModule>
#BLOQUEO AL xmlrpc.php
<Files xmlrpc.php>
order deny,allow
deny from all
allow from x.x.x.x
allow from x.x.x.x
allow from 192.0.64.0/18
</Files>
#BLOQUEO ACCESO AL wp-config.php
<files wp-config.php>
order allow,deny
deny from all
allow from x.x.x.x
allow from x.x.x.x
</files>
# FICHEROS QUE NO DEBERIAN ESTAR
<IfModule mod_alias.c>
RedirectMatch 403 (?i)(^#.*#|~)$
RedirectMatch 403 (?i)/readme\.(html|txt)
RedirectMatch 403 (?i)\.(ds_store|well-known)
RedirectMatch 403 (?i)/wp-config-sample\.php
RedirectMatch 403 (?i)\.(7z|bak|bz2|com|conf|dist|fla|git|inc|ini|log|old|psd|rar|tar|tgz|save|sh|sql|svn|swo|swp)$
</IfModule>

Y ahora vamos a por los plugins, que también hay que ponerlos, los que os recomiendo son: Akismet Anti-Spam, All In One WP Security, Block Bad Queries (BBQ) y WP fail2ban, os voy contando para que sirve cada uno y cual es el objetivo de cada uno de los plugins.

• Akismet Anti-Spam: Este plugin está desarrollado por Automatic y es un antispam, al instalarlo hay que registrarlo en la web de WordPress, nos da el enlace, no tiene mayor complicación, si es para uso personal podemos elegir si pagamos o no y cuanto queremos pagar.
• All In One WP Security: Este es uno de esos plugins enormes que hacen de todo, aquí tendréis que ver las opciones que más os interesen, a mi me gusta mucho la parte de exploración donde nos revisa los ficheros modificados y podremos detectar automáticamente si hay modificación de ficheros. Luego hay otras opciones que no utilizo como por ejemplo la del antispam porque akismet es mucho mejor, o la de bloqueos porque lo relego en otros plugins que lo hacen mejor.
• Block Bad Queries (BBQ): Gracias a BBQ evitaremos peticiones maliciosas por http, inyecciones de código, etc… este plugin es muy recomendable.
• WP fail2ban: Para poder utilizar este plugin tu hosting tiene que soportarlo, en el caso de Neodigit se soporta sin problemas ya que los servidores están configurados para integrar el plugin con los firewalls. Cualquier intento de ataque de fuerza bruta será bloqueado por el firewall y no por el php, lo cual hará que no baje el rendimento de la web, si lo hicieramos con algún plugin de seguridad, el rendimento de la web se vendría abajo pues aunque no mostremos la página tendremos que procesar esa petición.

Por supuesto además de instalar plugins es totalmente necesario estar atentos a las actualizaciones que vayan surgiendo y a la posible obsolescencia de plugins y temas, ya que es por los temas y plugins no mantenidos por donde suelen venir todos los problemas de WordPress.

Optimización

Llegamos un punto que es importante para la calidad de nuestro sitio, pero que no va a hacer que sea más seguro, sino más rápido y va a mejorar la experiencia del usuario.

Para optimizar lo más importante es elegir bien el tema y tenerlo cuidado y trabajado, pero si eso no lo podemos hacer al menos que podamos hacer otras cosas, pero que nunca van a sustituir a la elección correcta del tema, sólo podrán complementarlo.

Definir en el .htaccess los expires necesarios:

<IfModule mod_expires.c>
ExpiresDefault                              "access plus 1 month"
ExpiresByType text/html                     "access plus 1 seconds"
ExpiresByType text/xml                      "access plus 1 seconds"
ExpiresByType text/plain                    "access plus 1 seconds"
ExpiresByType application/xml               "access plus 1 seconds"
ExpiresByType application/json              "access plus 1 seconds"
ExpiresByType application/rss+xml           "access plus 1 hour"
ExpiresByType text/css                      "access plus 1 month"
ExpiresByType text/javascript               "access plus 1 month"
ExpiresByType application/javascript        "access plus 1 month"
ExpiresByType application/x-javascript      "access plus 1 month"
ExpiresByType image/x-ico                   "access plus 1 month"
ExpiresByType image/x-icon                  "access plus 1 month"
ExpiresByType image/gif                     "access plus 1 month"
ExpiresByType image/png                     "access plus 1 month"
ExpiresByType image/jpe                     "access plus 1 month"
ExpiresByType image/jpg                     "access plus 1 month"
ExpiresByType image/jpeg                    "access plus 1 month"
ExpiresByType font/truetype                 "access plus 1 month"
ExpiresByType font/opentype                 "access plus 1 month"
ExpiresByType application/x-font-woff       "access plus 1 month"
ExpiresByType video/ogg                     "access plus 1 month"
ExpiresByType audio/ogg                     "access plus 1 month"
ExpiresByType video/mp4                     "access plus 1 month"
ExpiresByType video/webm                    "access plus 1 month"
ExpiresByType image/svg                     "access plus 1 month"
ExpiresByType image/svg+xml                 "access plus 1 month"
ExpiresByType application/pdf               "access plus 1 month"
ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
</IfModule>

Y ahora pasaremos a los plugins que hay que instalar que son básicamente cinco: AMP, Autoptimize, WP Super Cache, WP-Sweep y Heartbeat Control

• AMP: Este plugin nos adaptará las páginas al AMP de Google, se supone que Google funcionará con AMP si puede y las páginas cargarán más rápidas
• Autoptimize: Realiza una optimización de html, css y javascript, con esto conseguiremos mejorar el tiempo de carga de nuestras webs.
• WP-Sweep: Limpieza de bases de datos. La base de datos de WordPress si no se mantiene limpia va creciendo hasta el infinito, haciendo que nuestro WordPress cada vez sea más y más lento.
• WP Super Cache: Un plugin de caché indispensable que tiene una relación usabilidad, facilidad y resultado excelentek, hay otros como W3 Total Cache, pero la dificultad que nos ofrece hace que no merezca la pena.
• Heartbeat Control: Este plugin va a modificar el tiempo entre chequeos del API de WordPress, lo que hará que use muchos menos recursos y que el servidor funcione mejor.

Solo agregar que es de total importancia que la versión de php sea superior a la 7.0 que mejora el rendimiento enormemente, en Neodigit ya tenemos la versión 7.2 en estado alpha, pero totalmente usable, este blog es prueba de ello :).

Espero que este post os sirva para poder configurar correctamente vuestro WordPress.

La respuesta a todo esto es usar Radius para la autenticación remota. Acceder por Radius nos va a permitir configurar los usuarios en un único lugar, un servidor Radius, y que gracias a esa configuración cada usuario podrá acceder a todos los routers, mucho más fácil y gestionable que ir configurando usuarios por todas partes y luego gestinar eso, que se vuelve inmanejable.

¿Para hacer esto qué vamos a necestar? pues un servidor radius y uno o muchos Mikrotiks. Obviamente aquí os voy a mostrar como hacerlo con Mikrotiks, pero se puede hacer con cualquier otra cosa que soporte Radius, que es la mayoría de cosas.

Servidores Radius hay muchísimos, pero para el ejemplo voy a utilizar Freeradius sobre una Ubuntu 16.04.02.

La instalación es tan sencilla como:

sudo apt-get install freeradius

Una vez instalado tendremos que añadir el cliente, es decir, el router que vamos a permitir conectarse al radius para autenticar en el fichero /etc/freeradius/clients.conf

client 192.168.91.214/32 {
	secret = password
	shortname = MikroTik
}

En este caso la IP 192.168.91.214, es la IP de mi router Mikrotik y la contraseña de autenticación es la palabra password. Esto simplemente indica que desde esa IP se pueden hacer peticiones.

Ahora configuraremos un usuario, eso lo haremos en el fichero /etc/freeradius/users con el siguiente contenido:

edu Cleartext-Password := "password"

Aquí le decimos que el usuario edu tiene de contraseña la palabra password

Con esto ya tendríamos la parte de Radius configurada para poder tener control de acceso a los routers, sin más, así de fácil.

Ahora en el mikrotik tendremos que configurar:

/radius
add address=192.168.91.213 secret=password service=login
/radius incoming
set accept=yes
/user aaa 
set use-radius=yes

Hemos hecho dos cosas, le hemos dicho que el servidor Radius es la IP 192.168.91.213 con contraseña password, esto tiene que coincidir con lo que hemos dicho en el servidor Radius en el fichero clients.conf. Y además le hemos dicho que ese servidor Radius se utilizará para login, es decir, para acceder al equipo.

Este último punto es interesante porque podemos tener un servidor radius de gestión, para acceder a los equipos y otro por ejemplo para pppoe o temas similares.

Y muy importante, le diremos que utilice Radius.

Radius va a funcionar siempre una vez que no haya funcionado la autenticación local.

Os dejo un pantallazo para que lo veáis en acción, no lo he comentado pero para poder ver lo que hace el servidor radius es con el comando sudo freeradius -X, si tenéis otra instancia de freeradius tendréis que matarla.

ACTUALIZACION: Si os ha interesado podéis escuchar el capítulo 37 del podcast.

El otro día empezamos a hablar un poco de red en docker y os comenté como enlazar un puerto externo a uno interno con -p puerto_externo:puerto_de_docker pero claro, eso está bien si ejecutamos un sólo contenedor, pero ¿qué ocurre si estamos ejecutando varios?, llevar el control de los puertos puede ser complejo así que tenemos la opción de la gestión dinámica de puertos.

Para ver los puertos asignados dinámicamente lo hacemos con docker port y el nombre

edu@thinkpad ~ # docker run --name nc -p 80 -p 443 -d nextcloud
edu@thinkpad ~ # docker port nc 
443/tcp -> 0.0.0.0:32768
80/tcp -> 0.0.0.0:32769

A mi personalmente me gusta fijar los puertos siempre que sea posible, pero la opción ahí está.

Y si queremos fijar un puerto, pero UDP podemos indicarlo

docker run -p 1234:1234/udp -d imagen

Imaginad un servidor de DNS dockerizado, pues ahí podríamos mostrar un puerto udp, el 53.

Ahora vamos a ir un poco más allá y vamos a conectar por red dos contenedores. Para ello tenemos la opción de conectarlos vía el host, vía el mapeo de puertos definido antes, no creo que haga falta hablar más de ello, o bien, directamente, de un contenedor a otro, pero sin usar el host.

Una opción es la del enlace directo, en la que tenemos una arquitectura cliente servidor, donde el cliente se lanza con la opción –link que lo que hace es meter en el fichero de hosts el contenedor que queramos.

edu@thinkpad ~ # docker run -ti --name servidor ubuntu bash
root@46096ba9221f:/#
edu@thinkpad ~ # docker run -ti --name cliente --link servidor ubuntu:latest bash
root@ab6b148a4b59:/# cat /etc/hosts
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
ff00::0	ip6-mcastprefix
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters
172.17.0.2	servidor 46096ba9221f
172.17.0.3	ab6b148a4b59

Pero claro, lo suyo es crear una red para aquellos contenedores que se quieran ver entre sí.

La red se crea con docker network create y docker nos asignará un direccionamiento con su NAT y todo.

edu@thinkpad ~ # docker network create red_interna
3c259b15e3850f62540ed8e1ba3b6ed6610c78d8f531a3d401868fbff34f362d
edu@thinkpad ~ # docker run -ti --rm --net=red_interna --name servidor2 ubuntu bash

Hay una cosa que podemos hacer y es limitar el acceso a la red de docker vía el PAT en función de la IP que accede, por ejemplo.

docker run -p 127.0.0.1:8080:80/tcp

En el vídeo de hoy instalo y juego un poco con Ghost. La instalación la hago en docker por ser mucho más fácil.

Este vídeo es mi primer contacto con Ghost y bueno, no está mal, ya me contaréis al ver el vídeo.

En el vídeo de hoy os cuento cuanto dinero nos cuesta tener un PC encendido 24 horas en España, sólo tengo en cuenta el coste de la luz, no pongo ni coste de conexión ni de recambios ni mano de obra ni nada, sólo luz.

Obviamente en el cálculo del vídeo no he tenido en cuenta la parte fija de la factuara, al final se nos va prácticamente a 0,20 el kwh pero bueno, tampoco quería entrar ahí.

Tened en cuenta que al luz en casa se puede caer, se puede caer la conexión a internet en casa, en fin, pueden pasar muchas cosas.

¿Realmente es más barato poner una web en casa que en un hosting?

Empiezo a hablar en el minuto 3:18

Tenemos varias formas de hacer staging en cualquier lado, de hacerlo por nosotros mismos sin tener que contratar nada extraño a nadie, hay multitud de herramientas que nos pueden ayudar a ello, pero antes vamos a contestar a la pregunta de antes.

¿Qué es el Staging? Es un proceso en el cual cogemos una web, en nuestro caso un Worpdress ya que estamos haciendo WordPress Staging y copiamos todos los ficheros a un directorio, copiamos la base de datos y empezamos a trabajar.

Pues bien, en el screencast de hoy os cuento como funciona el plugin, con los aciertos y los errores, he preferido no cortar cuando me he equivocado para que vosotros os podáis ahorrar esos momentos.

Enlaces:

Plugin WP Staging – DB & File Duplicator & Migration: https://es.wordpress.org/plugins/wp-staging/

Javier Archeni hablaba en el último capítulo de su podcast República Web que WordPress es como un martillo y recordando a Maslow se preguntaba si podíamos tratar a todos los problemas de desarrollo de páginas webs como si fueran clavos, os dejo el audio completo por si os interesa.Yo pienso un poco como Javier Archeni, y aún personalemente siendo un defensor de WordPress pienso que «hay que utilizar la herramienta correcta para cada tarea concreta«, esta última frase lamentablemente no se de quien y seguramente quedará como sabiduría popular, pero tiene mucha razón.

Un ejemplo claro y concreto, en la página principal de https://www.eduardocollado.com tengo un par de reproductores de audio, uno para cada uno de mis podcasts y su momento quería poner los dos reproductores uno al lado del otro, algo que no es complicado, pero el pensamiento en modo WordPress nos hace pensar de forma errónea.

Siguiendo el pensamiento WordPress lo que tendría que hacer era buscar un plugin para hacer esto, porque para mucha gente todo se soluciona poniendo plugins, siguiendo este pensamiento es probable llegar al pensamiento que necesitaba un builder de páginas en WordPress, un Site Origin o similar y usando esa herramienta podría poner las dos columnas, ahora, ¿eso es lo mejor? pues rotundamente no, eso si se me permite creo que es una cochinada porque dependeríamos de un plugin de por vida y tendríamos una caja negra en una de nuestras páginas.

Ahora, ¿cómo lo haríamos con otro razonamiento?, voy a explicaros el razonamiento que he seguido yo, que pudiera parecer más complicado, pero es porque seguramente tengamos ya la cabeza formada al «WordPress’ style«, lo primero es pensar en las posibilidades que nos ofrece WordPress y crearíamos un tema hijo, un child theme, luego crearía un código CSS para hacer las dos columnas, en mi caso este:

@media only screen and (min-width: 600px) {
	.columna_izquierda{
		width:47%;
		padding:0 5pt 0 0;
		float:left;
	}
}
@media only screen and (min-width: 600px) {
	.columna_derecha{
		width:47%;
		padding:0 0 0 5pt;
		float:right;
	}
}

Y ahora en la página donde quisiera poner los reproductores pondría este código, poniendo el editor en modo HTML obviamente:

<div class="columna_izquierda">
COLUMNA DE LA IZQUIERDA
</div>
<div class="columna_derecha">
COLUMNA DE LA DERECHA
</div>

Y con esto ya tendríamos el código sin depender de ningún plugin, sin tener una caja negra que nos «encochine» el código y si os dedicáis al desarrollo web estas líneas son más que obvias, así que poco se puede decir más a favor.

Ahora, hay mucha gente que quizás no sepa de CSS lo suficiente como para poner este código de cabeza, pues bien, pueden usar Google y buscar soluciones, exactamente igual que se hace para otras cosas.

El que no avanza corre el riesgo de quedarse atrás y WordPress en ese aspecto es muy peligroso, puede hacernos ser más cómodos y no os lo recomiendo.

Recordad que tengo audios donde explico cosas, como por ejemplo cómo crear un child-theme, o cómo modificar el CSS de un child-theme, con esos audio y un poco de búsqueda en internet tenéis lo suficiente para modificar un tema sin tener que recurrir a plugins extraños, porque al final WordPress no son sólo plugins y temas.

Este es el resultado:

La nueva versión viene con una serie de mejoras como nuevas funciones de API y algo que a mi personalmente me gusta mucho y son las «acciones en lote personalizadas«, de las que ya se habló en Octubre en el artículo Using Custom Bulk Actions del blog de WordPress, esto nos va a dar una flexibilidad brutal a la hora de hacer cosas.

La nueva versión también permite que cada una de las personas que colaboran en el WordPress pueda tener el panel de administración en un idioma diferente y por fin se elimina la necesidad de logarse una vez se termina la instalación inicial, nunca comprendí por qué era necesario logarse al terminar la configuración inicial, siempre me pareció un paso absurdo y redundante, pues ya no es necesario pasar por ahí.

Pero además de todas estas mejoras lo que los usuarios van a ver es el tema, el twenty seventeen que viene con una serie de mejoras muy apreciables y que saltan mucho a la vista.

El nuevo tema viene con la posibilidad de poner vídeo directamente en la cabecera, algo que ya hace tiempo se está volviendo bastante común y que empezaba a ser una necesidad.

También el editor de personalización del nuevo tema:

Para insertar el vídeo tenemos que ir a Cabecera multimedia y subir un vídeo o si queréis ahorrar ancho de banda, algo muy recomendable, podéis insertar una URL de YouTube como en este ejemplo:

Y algo que me parece muy interesante es el menú de CSS Adicional, en el que se pueden hacer aquellos ajustes necesarios sin tener que crear temas hijos ni modificaciones extrañas, una autentica maravilla.

En cuanto al rendimimiento tengo que decir que no he notado mejoría, la mejoría grande se notó al cambiar a php 7, pero una vez hecho eso no he notado nada más.

Espero que esta pequeña pincelada os muestre un poco las mejoras que hay en esta nueva versión de WordPress.

Existen varios plugins para WordPress que hacen esto y por supuesto también tenemos la opción del htaccess manual para limitar el acceso, para ello limitamos a todos los rangos geolocalizados en el país que queremos permitir, o los que no queramos permitir, como queramos.

Hay un servicio que a mi me gusta mucho que es IP2Location el cual genera el htaccess, aunque también tienen plugin para WordPress.

Ahora tenemos que tener en cuenta que el htaccess no va a hacer que no llegue tráfico de ciertos países, va a hacer que no sirvamos la web, pero no que nuestro Apache devuelva la conexión, así que ante caso de ataque de DDoS no sirve.

Y luego otras opciones en las que se ejecuta un php para ver si hay que filtrar la conexión ahí además de consumir una conexión de Apache además la procesamos.

Entonces ¿para qué nos sirve esto? Filtrar países es una buena solución si nuestro negocio o web está únicamente enfocada a un único país. También puede servirnos si tenemos alguna web con alguna vulnerabilidad que siempre es explotada desde determinados países, sí, estas cosas pasan y son muy comunes aunque parezca mentira, aunque lo mejor es arreglarlo hay mucha gente que lo único que puede hacer es limitar el acceso.

En la mayoría de clientes de OpenVPN es posible agregar el fichero de configuración y después adjuntar los ficheros de certificados sin problemas, pero lamentablemente existen casos como en la configuración de OpenVPN en un iPhone donde no es posible agregar los ficheros (a no ser que tengas iTunes).

En ese caso lo que tenemos que hacer es adaptar nuestro fichero de configuración. Si en un inicio es algo así:

client
dev tun
proto udp
remote my-server-1 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1
comp-lzo
verb 3

Y además tenemos los ficheros ta.key, client.key, client.crt y ca.crt.

Ahora lo que queremos es incorporar esos ficheros dentro del fichero de configuración, para ellos simplemente convertiremos nuestro fichero en algo parecido a esto:

client
dev tun
proto udp
remote my-server-1 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1
comp-lzo
verb 3
<ca>
-----BEGIN CERTIFICATE-----
AQUÍ VA EL CONTENIDO DE ca.crt
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
AQUÍ VA EL CONTENIDO DE client.crt
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
AQUÍ VA EL CONTENIDO DE client.key
-----END RSA PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
AQUÍ VA EL CONTENIDO DE ta.key
-----END OpenVPN Static key V1-----
</tls-auth>

Pues este es todo el secreto

Así que vamos a hacer un formulario que pida el nombre del CD, el autor y todas las canciones junto con la duración de cada una.

Para que quede mono el formulario podemos ir a lo fácil y usar bootstrap, para definir los cuadros podemos ir a shoelace.io que es una web que nos ayudará a crear los cuadros de una forma muy fácil y visual, en mi caso:

El código que nos ha generado es el siguiente:

<div class="container">
    <div class="row">
        <div class="col-md-offset-1 col-md-4"></div>
        <div class="col-md-4"></div>
    </div>
    <div class="row">
        <div class="col-md-offset-1 col-md-6"></div>
        <div class="col-md-2"></div>
    </div>
    <div class="row">
        <div class="col-md-offset-1 col-md-6"></div>
        <div class="col-md-2"></div>
    </div>
</div>

Obviamente para estas cajas no es necesario usar ninguna aplicación externa, pero que sepáis que existe, a mi me ha venido muy bien.

En cuanto tenemos esto procedemos a meter nuestro formulario ahí dentro.

<div class="container">
    <h3>Formulario de canciones de CD</h3>
    <form action="relleno_de_cds.php" id="formulario" method="post">
    <div class="row">
        <div class="col-md-offset-1 col-md-4"><label>Nombre CD</label></div>
        <div class="col-md-4"><input class="form-control" name="nombre_cd" type="text"/></div>
    </div>
    <div class="row">
        <div class="col-md-offset-1 col-md-6"><label>T&iacute;tulo canci&oacute;n</label></div>
        <div class="col-md-2"><label>Duraci&oacute;n</label></div>
        <div class="col-md-1"><input type="button" class="btn btn-success" id="add_cancion()" onClick="addCancion()" value="+" /></div>
    </div>
    <!-- El id="canciones" indica que la función de JavaScript dejará aquí el resultado -->
    <div class="row" id="canciones">
    </div>
    </form>
</div>

Como primer paso hemos rellenado la plantilla que nos ha generado la aplicación de antes para usar los campos para distribuir el formulario, sólo hemos añadido un pequeño detalle, y es ese botón «+» que han en la segunda caja y que solo ocupa una columna. La distribución de las columnas es la de bootstrap.

Por supuesto en la cabecera hemos metido el css indicado

<!-- Latest compiled and minified CSS -->
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous">

Y en cuanto al javascript utilizado la función addCancion() que lo que hace es añadir al div canciones, el último y que aparece vacío en el HTML de arriba dos cajas más con los inputs del formulario.

Por supuesto, cada vez que se le da al «+» verde se crea una nueva fila

<script>
a = 0;
function addCancion(){
        a++;

        var div = document.createElement('div');
        div.setAttribute('class', 'form-inline');
            div.innerHTML = '<div style="clear:both" class="cancion_'+a+' col-md-offset-1 col-md-6"><input class="form-control" name="cancion_'+a+'" type="text"/></div><div class="cancion_'+a+' col-md-2""><input class="form-control" name="duracion_'+a+'" type="text"/></div>';
            document.getElementById('canciones').appendChild(div);document.getElementById('canciones').appendChild(div);
}
</script>

El formulario en un navegador al final queda como la imagen que os pongo a continuación:

El código completo, todo juntito, es el siguiente:

<!DOCTYPE html>
<html>
<head>

<!-- Latest compiled and minified CSS -->
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous">


<script>
a = 0;
function addCancion(){
        a++;

        var div = document.createElement('div');
        div.setAttribute('class', 'form-inline');
            div.innerHTML = '<div style="clear:both" class="cancion_'+a+' col-md-offset-1 col-md-6"><input class="form-control" name="cancion_'+a+'" type="text"/></div><div class="cancion_'+a+' col-md-2""><input class="form-control" name="duracion_'+a+'" type="text"/></div>';
            document.getElementById('canciones').appendChild(div);document.getElementById('canciones').appendChild(div);
}
</script>


</head>

<body>
<div class="container">
    <h3>Formulario de canciones de CD</h3>
    <form action="formulario2.html" id="formulario" method="get">
    <div class="row">
        <div class="col-md-offset-1 col-md-4"><label>Nombre CD</label></div>
        <div class="col-md-4"><input class="form-control" name="nombre_cd" type="text"/></div>
    </div>
    <div class="row">
        <div class="col-md-offset-1 col-md-6"><label>T&iacute;tulo canci&oacute;n</label></div>
        <div class="col-md-2"><label>Duraci&oacute;n</label></div>
        <div class="col-md-1"><input type="button" class="btn btn-success" id="add_cancion()" onClick="addCancion()" value="+" /></div>
    </div>
    <!-- El id="canciones" indica que la función de JavaScript dejará aquí el resultado -->
    <div class="row" id="canciones">
    </div>
    </form>
</div>

</body>
</html>

Lo primero, crear el repositorio, para ello tenemos tres opciones, crear el repositorio en blanco, clonar un repositorio que tengamos en el disco o bien clonar un repositorio que esté en un servidor remoto

Iniciar repositorios

git init -> creamos repositorio en blanco

git clone /path/al/repositorio -> clonamos un repositorio local

git clone usuario@servidor:/path/al/repositorio -> clonamos un repositorio remoto

En git tenemos que tener en cuenta que tenemos tres estados, el directorio de trabajo, el Index donde está lo que vamos a guardar y HEAD que es lo guardado, vamos a verlo con un ejemplo.

Añadir ficheros al repositorio

Para añadir ficheros del directorio de trabajo al Index

git add <fichero>

git add * -> Esto añade todos los ficheros

En este punto tenemos los ficheros añadidos al Index, y ahora tenemos que pasarlos al HEAD, para ello hay que hacer commit

git commit -m «Mensaje para el commit»

Ahora el fichero está en el HEAD, pero todavía no está en el repositorio, para ponerlo en el repositorio

git push origin master

Donde master es la rama del repositorio donde vamos a poner nuestro commit.

Branches

Para crear branches (ramas) lo hacemos con

git checkout -b mi_rama

Para volver otra vez al master

git checkout -b master

Y para borrar mi_rama

git branch -d mi_rama

Pero claro, esto es sólo local, no hemos subido nada a ningún sitio, para subirlo como antes

git push origin mi_rama

Actualizar

Para actualizar nuestro repositorio local con el repositorio remoto

git pull

Y para mezclar con otra rama

git merge <branch>

En caso de conflictos puede que sea necesario añadir ficheros con

git add <fichero>

Pero podemos ver las diferencias antes de aplicarlas con

git diff <branch_origen> <branch_destino>

Etiquetas

Para añadir etiquetas para las versiones de nuestro software se puede hacer con

git tag 0.0.1 7ace24e166

En ese comando hemos puesto una etiqueta a la versión 0.0.1 y hemos indicado los 10 primeros caracteres del commit que lo hemos sacado de hacer

$ git log
commit 7ace24e1665fed899a0edf7e3670ae2ea6466a19
Author: Eduardo Collado <edu@tecnocratica.net>
Date: Sun Nov 13 20:28:51 2016 +0100

Primera subida

Reemplazar cambios locales

Si queremos volver atrás a la versión del HEAD de un fichero concreto

git checkout — <nombre_de_fichero>

Y si lo que queremos es tirar atrás todo el último cambio

git fetch origin
git reset –hard origin/master

De todos modos aquí os dejo un tutorial muy interesante que encontré en YouTube en un castellano perfecto

El esquema de base de datos será el siguiente:

Las relaciones serán 1 a muchos entre la tabla contactos y las tablas telefonos y e-mails.

Teniendo esto sabemos que necesitaremos 3 modelos que son contact, phone y email (ponemos los nombres en inglés para la pluralización de Rails), las tablas se llamarán igual.

En cuanto a controladores necesitaremos también uno por modelo para definir las acciones de CRUD que son new, create, index, show, edit, update, delete y destroy.

rails new contacts -d mysql

Y en mysql

mysql> CREATE DATABASER contacts_development;
mysql> GRANT ALL PRIVILEGES ON contacts_development.* TO 'edu'@'localhost' IDENTIFIED AS 'superpassword';

Y pondremos en el fichero /config/database.yml los datos:

username: edu 
password: superpassword

Y generamos los controllers

$ rails generate controller contacts new create index show edit update delete destroy
$ rails generate controller phones new create index show edit update delete destroy
$ rails generate controller emails new create index show edit update delete destroy

Ahora generamos los modelos y creamos las tablas

$ rails generate model contact
$ rails generate model phone
$ rails generate model email

Establecemos las relaciones entre tablas

/app/model/contact.rb

class Contact < ApplicationRecord 
    has_many :phones 
    has_many :emails 
end

/app/model/phone.rb

class Phone < ApplicationRecord
  belongs_to :contact 
end

/app/model/email.rb

class Email < ApplicationRecord
  belongs_to :contact
end

En nuestro caso no va a afectar mucho, pero al poner belongs_to y usar Rails 5, como es mi caso, está actuando el presence validator, que por defecto no viene activado en Rails 4, esto quiere decir que si no hay contacto no podemos crear ni teléfono ni email, algo que por otro lado tiene toda la lógica.

Pues llegados a este punto inicial ya podemos empezar a trabajar en nuestro CRUD y crear la página web con el formulario.

Para tener una apariencia «mona» vamos a poner la cabecera de bootstrap en nuestro layout por defecto y creamos las migraciones, es decir, la estructura de las tablas:

app/layouts/application.html.erb

<!DOCTYPE html>
<html>
  <head>
    <title>Contacts</title>
    <%= csrf_meta_tags %>

    <%= stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <!-- Latest compiled and minified CSS -->
    <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous">
    <%= javascript_include_tag 'application', 'data-turbolinks-track': 'reload' %>
    <!-- Latest compiled and minified JavaScript -->
    <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous"></script>
  </head>

  <body>
    <div class="container">
      <%= yield %>
    </div>
  </body>
</html>

db/migrate/20161113143332_create_contacts.rb

class CreateContacts < ActiveRecord::Migration[5.0]
  def change
    create_table :contacts do |t|
      t.string :nombre, :null => false
      t.string :apellidos, :null => false
      t.string :calle
      t.string :poblacion
      t.string :provincia
      t.string :pais
      t.timestamps
    end
  end
end

db/migrate/20161113143340_create_phones.rb

class CreatePhones < ActiveRecord::Migration[5.0]
  def change
    create_table :phones do |t|
      t.string :telefono
      t.string :contacts_id
      t.timestamps
    end
  end
end

db/migrate/20161113143345_create_emails.rb

class CreateEmails < ActiveRecord::Migration[5.0]
  def change
    create_table :emails do |t|
      t.string :email
      t.string :contacts_id
      t.timestamps
    end
  end
end

Ahora ya podemos migrar

$ rake db:migrate
== 20161113143332 CreateContacts: migrating ===================================
-- create_table(:contacts)
   -> 0.0359s
== 20161113143332 CreateContacts: migrated (0.0360s) ==========================

== 20161113143340 CreatePhones: migrating =====================================
-- create_table(:phones)
   -> 0.0368s
== 20161113143340 CreatePhones: migrated (0.0369s) ============================

== 20161113143345 CreateEmails: migrating =====================================
-- create_table(:emails)
   -> 0.0411s
== 20161113143345 CreateEmails: migrated (0.0412s) ============================

Sólo nos queda configurar una ruta por defecto en nuestro archivo de rutas y a hacer formularios

Rails.application.routes.draw do
  root 'contacts#index'
  match ':controller(/:action(/:id))', :via => [:get, :post]
  # For details on the DSL available within this file, see http://guides.rubyonrails.org/routing.html
end

Parece ser que en versiones posteriores de Rails se va a eliminar la ruta por defecto, pero mientras podremos seguirla utilizando.

Fijaros que la ruta por defecto la hemos creado sólo para dos verbos, get y post cuando lo suyo es que hubiéramos definido los 4 verbos get, post, patch, delete que se definen en REST.

También hemos definido que la página principal será el index de contacts.

Vamos a ir a construir el index del view contacts:

<h1>Lista de contactos</h1>
<p><%= link_to("Añadir contacto", {:controller => 'contacts', :action => 'new'}, data: { turbolinks: false } , :class => "btn btn-success" ) %></p>

<table class="table table-striped" summary="Contact List">
  <tr class="header">
    <th>
      Apellidos
    </th>
    <th>
      Nombre
    </th>
    <th>
      Acciones
    </th>
  </tr>
  <% @contact.each do |t| %>
  <tr>
    <td>
      <%= t.apellidos %>
    </td>
    <td>
      <%= t.nombre %>
    </td>
    <td>
      <%= link_to("Detalles", {:action => 'show', :id => t.id}, data: { turbolinks: false }, :class => "btn btn-primary") %>
      <%= link_to("Editar", {:action => 'edit', :id => t.id}, data: { turbolinks: false }, :class => "btn btn-primary") %>
      <%= link_to("Borrar", {:action => 'delete', :id => t.id}, data: { turbolinks: false }, :class => "btn btn-primary") %>
    </td>
  </tr>
  <% end %>
</table>

Los botones están así porque es la forma de definirlos en bootstrap y los turbolinks están en false porque si no falla en el momento en el que se entre desde otro enlace o se tire atrás.

Arriba hemos definido el enlace a new, así que aquí lo ponemos

<h1>Añadir Contacto</h1>
<table class="table table-striped" summary="Add Task" >
    <tr class="header">
        <th></th>
        <th>Contenido</th>
    </tr>
    <tr>
            <th>Apellidos</th>
            <%= form_for(:contact, :url => {:action => 'create', :id => @contact.id}) do |f| %>
            <td><%= f.text_field(:apellidos) %></td>
    </tr>
    <tr>
            <th>Nombre</th>
            <td><%= f.text_field(:nombre) %></td>
    </tr>

</table>
        <%= submit_tag("Añadir", :class => "btn btn-primary") %>
        <% end %>

Esto es realmente un formulario form_for en el que solicitamos los apellidos y el nombre, para que esto funcione en el controller tenemos que tener esta configuración

  def new
    @contact = Contact.new
  end

  def create
    @contact = Contact.new(contact_params)
    @contact.save
    redirect_to(:action => 'index')

  private
    def contact_params
      params.require(:contact).permit(:nombre, :apellidos, :id, :poblacion, :provincia, :pais)
    end

Hemos utilizado un método privado en create para que desde new sólo se pasen los parámetros definidos, ni más ni menos, al método contact_params no se puede acceder desde fuera. El formulario se añadiría en new, pero el se valida en create, donde no hay nada en la vista porque hemos creado una redirección al index.

Ahora vamos a hacer el editar que es igual al crear

app/views/contacts/edit.html.erb

<h1>Editar Contacto</h1>
<table class="table table-striped" summary="Add Task" >
    <tr class="header">
        <th></th>
        <th>Contenido</th>
    </tr>
    <tr>
            <th>Apellidos</th>
            <%= form_for(:contact, :url => {:action => 'update', :id => @contact.id}) do |f| %>
            <td><%= f.text_field(:apellidos) %></td>
    </tr>
    <tr>
            <th>Nombre</th>
            <td><%= f.text_field(:nombre) %></td>
    </tr>

</table>
        <%= submit_tag("Editar", :class => "btn btn-primary") %>
        <% end %>

Y en el controller

  def edit
    @contact = Contact.find(params[:id])
  end

  def update
    @contact = Contact.find(params[:id])
    @contact.update_attributes(contact_params)
    redirect_to(:action =>'index')
  end


  private
    def contact_params
      params.require(:contact).permit(:nombre, :apellidos, :id, :poblacion, :provincia, :pais)
    end

La única diferencia es que aquí para editar lo hacemos fijándonos en el parámetro :id

Partiendo de aquí el resto sería muy parecido, diferencias las tendríamos en borrar donde tendríamos que borrar los emails asociados y los teléfonos

  def delete
    @contact = Contact.find(params[:id])
  end


  def destroy
    @contact = Task.find(params[:id])
    @phone = Action.where(contact_id: @contact)
    @phone.each do |t|
      t.destroy
    @email = Action.where(contact_id: @contact)
    @email.each do |t|
      t.destroy
    end
    @contact.destroy
    redirect_to(:action => 'index')
  end

Con esto ya tendríamos una web de contactos, y a vosotros os dejo la creación de las páginas para los teléfonos y los emails.

El problema que tiene vim, además de su lenta curva de aprendizaje es la personalización, los plugins, etc… alrededor de vim hay un Mundo y lograr la personalización perfecta es muy laborioso.

Sin embargo, hoy encontré vim-bootstrap, una web que sólo tiene una función, generar el archivo de configuración de vim, seleccionas los lenguajes que quieres utilizar  y descargas un fichero llamado generate.vim, el cual copias en lugar de .vimrc y al arrancar vim todo se configurará sólo como por arte de magia.

Una maravilla, después de probarlo no vais a querer usar otra cosa, en serio, totalmente recomendable.

La única pega que le he encontrado es que al instalar html el código tiene dos líneas con unos saltos de carro feotes que hay que arreglarlos, pero nada más, os dejo el screencast.

• nombres
• administradores
• direcciones_ip
• servidores

El objetivo es poder definir las relaciones de forma que un administrador es una persona que tiene nombre y apellidos, ese administrador puede gestionar varios servidores, los cuales a su vez pueden ser gestionados por varios administradores, y cada servidor puede tener varias direcciones IP, pero cada dirección IP sólo puede estar en un servidor y en un interfaz.3

Si nos fijamos bien hay otra relación que no está definida entre tablas que es dirección IP e interfaz, es una relación uno a uno y como tal se puede incluir en una misma tabla, pero para nuestro ejemplo hemos separado administradores y el nombre de los mismos.

Lo primero que vamos a hacer como crear el proyecto, crear la base de datos, dar permisos a un usuario, configurar acceso al mysql en rails y crear las tablas, así que vamos a hacerlo todo seguido.

ubuntu@ronr:~$ rails new gestionips -d mysql
ubuntu@ronr:~$ mysql -u root -p
mysql> CREATE DATABASE gestionips_development;
mysql> GRANT ALL PRIVILEGES ON gestionips_development.* TO 'edu'@'localhost' IDENTIFIED BY 'password';
ubuntu@ronr:~$ vim gestionips/config/database.yml
    default: &default
    adapter: mysql2
    encoding: utf8
    pool: 5
    username: edu
    password: password
    socket: /var/run/mysqld/mysqld.sock
ubuntu@ronr:~/gestionips$ rails generate model nombre
ubuntu@ronr:~/gestionips$ rails generate model administrador
ubuntu@ronr:~/gestionips$ rails generate model direccion_ip
ubuntu@ronr:~/gestionips$ rails generate model servidor
ubuntu@ronr:~/gestionips/db/migrate$ vim 20161101142603_create_nombres.rb
  class CreateNombres < ActiveRecord::Migration[5.0]
    def change
      create_table :nombres do |t|  
        t.string("nombre", :limit => 25, :null => false)
        t.string("apellidos", :limit => 50, :null => false)
        t.timestamps
      end
    end
  end
  end
ubuntu@ronr:~/gestionips/db/migrate$ vim 20161101142608_create_administradors.rb
  class CreateAdministradors < ActiveRecord::Migration[5.0]
    def change
      create_table :administradors do |t|
        t.timestamps
      end
    end
  end
ubuntu@ronr:~/gestionips/db/migrate$ vim 20161101142620_create_direccion_ips.rb
  class CreateDireccionIps < ActiveRecord::Migration[5.0]
    def change
      create_table :direccion_ips do |t|
        t.string("ip",:limit => 15, :null => false)
        t.string("interfaz", :limit => 25, :null => false)
        t.timestamps
      end
    end
  end
ubuntu@ronr:~/gestionips/db/migrate$ vim 20161101142626_create_servidors.rb
  class CreateServidors < ActiveRecord::Migration[5.0]
    def change
      create_table :servidors do |t|
        t.string("nombre", :limit => 50, :null => false)
        t.timestamps
      end
    end
  end
ubuntu@ronr:~/gestionips$ rake db:migrate

Una vez hecho esto ya podemos concentrarnos en las relaciones, ya que lo único que hemos hecho ha sido crear las tablas vacías con los campos que se indicaban en el diagrama.

Ahora vamos a meter unos datos dummy en la base de datos para empezar a trabajar, para ello desde la consola de rails entrando como rails console desde el directorio raiz del proyecto:

nombre=Nombre.new(:nombre => "Eduardo", :apellidos => "Collado Cabeza")
nombre.save
nombre=Nombre.new(:nombre => "Maria", :apellidos => "Altamirano García")
nombre.save
nombre=Nombre.new(:nombre => "Norma", :apellidos => "Delgado Bugarín")
nombre.save
nombre=Nombre.new(:nombre => "Carlos", :apellidos => "Díaz Cruz")
nombre.save
direccion=DireccionIp.new(:ip => "12.12.43.12", :interfaz => "eth0")
direccion.save
direccion=DireccionIp.new(:ip => "56.21.123.14", :interfaz => "eth1")
direccion.save
direccion=DireccionIp.new(:ip => "121.32.5.7", :interfaz => "eth2")
direccion.save
direccion=DireccionIp.new(:ip => "173.11.53.122", :interfaz => "eth3")
direccion.save
servidor=Servidor.new(:nombre => "SRV-Rails1")
servidor.save
servidor=Servidor.new(:nombre => "SRV-Rails2")
servidor.save
servidor=Servidor.new(:nombre => "SRV-Rails3")
servidor.save
servidor=Servidor.new(:nombre => "SRV-Rails4")
servidor.save

La tabla de administradores sólo tiene una columna que es ID, por eso no hemos rellenado nada después iremos creando según lo necesitemos, así que ya podemos empezar a trabajar.

Relación uno a uno

Entre las tablas nombres y administradores tenemos una relación uno a uno y vamos a decir que nombre tiene un administrador y que un administrador pertenece a un nombre, así que editamos ambos modelos:

ubuntu@ronr:~/gestionips/app/models$ vim nombre.rb 
  class Nombre < ApplicationRecord
    has_one :administrador
  end
ubuntu@ronr:~/gestionips/app/models$ vim administrador.rb
  class Administrador < ApplicationRecord
    belongs_to :nombre
  end

En la clase Administrador le hemos dicho que pertenece a nombre, es decir, es una llave foránea a la llave de la tabla nombre, así que tenemos que crear esa columna en la base de datos:

ubuntu@ronr:~/gestionips$ rails generate migration CrearForeignKeyEnAdministradoclass CrearForeignKeyEnAdministrador < ActiveRecord::Migration[5.0]
    def change
      add_column("administradors","nombre_id","string")
    end
  end

Y ejecutaremos el migrate

ubuntu@ronr:~/gestionips$ rake db:migrate

Si fueramos atrás en versiones y volvieramos tendríamos que volver a introducir los datos dmmy que hemos puesto antes, ya que se borrarían las tablas con drop y al recrearlas lo haría sin contenido.

En este momento entraríamos en la consola de rails para crear las cuatro relaciones uno a uno de nombre y administrador

ubuntu@ronr:~/gestionips$ rails console
irb(main):001:0> nombre=Nombre.find(1)
  Nombre Load (0.4ms)  SELECT  `nombres`.* FROM `nombres` WHERE `nombres`.`id` = 1 LIMIT 1
=> #<Nombre id: 1, nombre: "Eduardo", apellidos: "Collado Cabeza", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 16:54:09">
irb(main):002:0> administrador=Administrador.new()
=> #<Administrador id: nil, created_at: nil, updated_at: nil, nombre_id: nil>
irb(main):003:0> nombre.administrador=administrador
  Administrador Load (0.4ms)  SELECT  `administradors`.* FROM `administradors` WHERE `administradors`.`nombre_id` = '1' LIMIT 1
   (0.2ms)  BEGIN
  SQL (0.4ms)  INSERT INTO `administradors` (`created_at`, `updated_at`, `nombre_id`) VALUES ('2016-11-01 17:00:13', '2016-11-01 17:00:13', '1')
   (5.3ms)  COMMIT
=> #<Administrador id: 5, created_at: "2016-11-01 17:00:13", updated_at: "2016-11-01 17:00:13", nombre_id: "1">
irb(main):004:0> nombre=Nombre.find(2)
  Nombre Load (0.5ms)  SELECT  `nombres`.* FROM `nombres` WHERE `nombres`.`id` = 2 LIMIT 1
=> #<Nombre id: 2, nombre: "Maria", apellidos: "Altamirano García", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 16:54:09">
irb(main):005:0> administrador=Administrador.new()
=> #<Administrador id: nil, created_at: nil, updated_at: nil, nombre_id: nil>
irb(main):006:0> nombre.administrador=administrador
  Administrador Load (0.3ms)  SELECT  `administradors`.* FROM `administradors` WHERE `administradors`.`nombre_id` = '2' LIMIT 1
   (0.1ms)  BEGIN
  SQL (0.2ms)  INSERT INTO `administradors` (`created_at`, `updated_at`, `nombre_id`) VALUES ('2016-11-01 17:00:13', '2016-11-01 17:00:13', '2')
   (12.9ms)  COMMIT
=> #<Administrador id: 6, created_at: "2016-11-01 17:00:13", updated_at: "2016-11-01 17:00:13", nombre_id: "2">
irb(main):007:0> nombre=Nombre.find(3)
  Nombre Load (0.7ms)  SELECT  `nombres`.* FROM `nombres` WHERE `nombres`.`id` = 3 LIMIT 1
=> #<Nombre id: 3, nombre: "Norma", apellidos: "Delgado Bugarín", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 16:54:09">
irb(main):008:0> administrador=Administrador.new()
=> #<Administrador id: nil, created_at: nil, updated_at: nil, nombre_id: nil>
irb(main):009:0> nombre.administrador=administrador
  Administrador Load (0.4ms)  SELECT  `administradors`.* FROM `administradors` WHERE `administradors`.`nombre_id` = '3' LIMIT 1
   (0.1ms)  BEGIN
  SQL (0.2ms)  INSERT INTO `administradors` (`created_at`, `updated_at`, `nombre_id`) VALUES ('2016-11-01 17:00:13', '2016-11-01 17:00:13', '3')
   (5.6ms)  COMMIT
=> #<Administrador id: 7, created_at: "2016-11-01 17:00:13", updated_at: "2016-11-01 17:00:13", nombre_id: "3">
irb(main):010:0> nombre=Nombre.find(4)
  Nombre Load (0.3ms)  SELECT  `nombres`.* FROM `nombres` WHERE `nombres`.`id` = 4 LIMIT 1
=> #<Nombre id: 4, nombre: "Carlos", apellidos: "Díaz Cruz", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 16:54:09">
irb(main):011:0> administrador=Administrador.new()
=> #<Administrador id: nil, created_at: nil, updated_at: nil, nombre_id: nil>
irb(main):012:0> nombre.administrador=administrador
  Administrador Load (0.5ms)  SELECT  `administradors`.* FROM `administradors` WHERE `administradors`.`nombre_id` = '4' LIMIT 1
   (0.2ms)  BEGIN
  SQL (0.5ms)  INSERT INTO `administradors` (`created_at`, `updated_at`, `nombre_id`) VALUES ('2016-11-01 17:00:14', '2016-11-01 17:00:14', '4')
   (5.2ms)  COMMIT
=> #<Administrador id: 8, created_at: "2016-11-01 17:00:14", updated_at: "2016-11-01 17:00:14", nombre_id: "4">

Se ve más claro si vemos la tabla directamente en MySQL como se ha rellenado la columna nombre_id

mysql> select * from administradors;
+----+---------------------+---------------------+-----------+
| id | created_at          | updated_at          | nombre_id |
+----+---------------------+---------------------+-----------+
|  5 | 2016-11-01 17:00:13 | 2016-11-01 17:00:13 | 1         |
|  6 | 2016-11-01 17:00:13 | 2016-11-01 17:00:13 | 2         |
|  7 | 2016-11-01 17:00:13 | 2016-11-01 17:00:13 | 3         |
|  8 | 2016-11-01 17:00:14 | 2016-11-01 17:00:14 | 4         |
+----+---------------------+---------------------+-----------+
4 rows in set (0,00 sec)

mysql> select * from nombres;
+----+---------+--------------------+---------------------+---------------------+
| id | nombre  | apellidos          | created_at          | updated_at          |
+----+---------+--------------------+---------------------+---------------------+
|  1 | Eduardo | Collado Cabeza     | 2016-11-01 16:54:09 | 2016-11-01 16:54:09 |
|  2 | Maria   | Altamirano García  | 2016-11-01 16:54:09 | 2016-11-01 16:54:09 |
|  3 | Norma   | Delgado Bugarín    | 2016-11-01 16:54:09 | 2016-11-01 16:54:09 |
|  4 | Carlos  | Díaz Cruz          | 2016-11-01 16:54:09 | 2016-11-01 16:54:09 |
+----+---------+--------------------+---------------------+---------------------+
4 rows in set (0,00 sec)

Relación uno a muchos

Ahora vamos a ver la relación entre servidores y direcciones IP. Un servidor puede tener varias direcciones IP, pero cada dirección IP sólo puede estar en un servidor.

Aquí hay que decir que los métodos disponibles son los siguientes:

• servidor.direccion_ip
• servidor.direccion_ip << direccion_ip (añadir al array)
• servidor.direccion_ip = direccion_ip, direccion_ip (introducimos todo el array)
• servidor.direccion_ip.delete(direccion_ip) (borramos el objeto)
• servidor.direccion_ip.destroy(direccion_ip) (borramos el objeto y de la base de datos)
• servidor.direccion_ip.clear (borramos todo)
• servidor.direccion_ip.empty? (preguntamos si está vacío el array)
• servidor.direccion_ip.size (preguntamos el tamaño del array)

Si lo trasladamos a lenguaje Rails tenemos que un servidor has_many :direccionesip

Así procedemos a configurar el fichero

ubuntu@ronr:~/gestionips/app/models$ vim servidor.rb 
  class Servidor < ApplicationRecord
    has_many :direccion_ip
  end
ubuntu@ronr:~/gestionips/app/models$ vim direccion_ip.rb
  class DireccionIp < ApplicationRecord
    belongs_to :servidor
  end

Y como tenemos belongs_to en direccion_ip significa que tenemos que crear una Foreign Key apuntando a servidor mediante una nueva migración

ubuntu@ronr:~/gestionips$ rails generate migration CrearForeignKeyEnDireccionIp
ubuntu@ronr:~/gestionips$ vim db/migrate/20161101172341_crear_foreign_key_en_direccion_ip.rb
  class CrearForeignKeyEnDireccionIp < ActiveRecord::Migration[5.0]
    def change
      add_column("direccion_ips","servidor_id","string")
    end
  end
ubuntu@ronr:~/gestionips$ rake db:migrate

Y entramos en la consola de rails. Vamos a asignar todas las IPs que tenemos en los datos dummy al primer servidor

ubuntu@ronr:~/gestionips$ rails console
Running via Spring preloader in process 7156
Loading development environment (Rails 5.0.0.1)
irb(main):001:0> servidor=Servidor.find(1)
  Servidor Load (0.4ms)  SELECT  `servidors`.* FROM `servidors` WHERE `servidors`.`id` = 1 LIMIT 1
=> #<Servidor id: 1, nombre: "SRV-Rails1", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 16:54:09">
irb(main):002:0> direccionip = DireccionIp.find(1)
  DireccionIp Load (0.4ms)  SELECT  `direccion_ips`.* FROM `direccion_ips` WHERE `direccion_ips`.`id` = 1 LIMIT 1
=> #<DireccionIp id: 1, ip: "12.12.43.12", interfaz: "eth0", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 16:54:09", servidor_id: nil>
irb(main):003:0> servidor.direccion_ip << direccionip
   (0.3ms)  BEGIN
  SQL (0.6ms)  UPDATE `direccion_ips` SET `updated_at` = '2016-11-01 17:29:50', `servidor_id` = '1' WHERE `direccion_ips`.`id` = 1
   (4.2ms)  COMMIT
  DireccionIp Load (0.7ms)  SELECT `direccion_ips`.* FROM `direccion_ips` WHERE `direccion_ips`.`servidor_id` = '1'
=> #<ActiveRecord::Associations::CollectionProxy [#<DireccionIp id: 1, ip: "12.12.43.12", interfaz: "eth0", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 17:29:50", servidor_id: "1">]>
irb(main):004:0> direccionip = DireccionIp.find(2)
  DireccionIp Load (0.7ms)  SELECT  `direccion_ips`.* FROM `direccion_ips` WHERE `direccion_ips`.`id` = 2 LIMIT 1
=> #<DireccionIp id: 2, ip: "56.21.123.14", interfaz: "eth1", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 16:54:09", servidor_id: nil>
irb(main):005:0> servidor.direccion_ip << direccionip
   (0.4ms)  BEGIN
  SQL (0.5ms)  UPDATE `direccion_ips` SET `updated_at` = '2016-11-01 17:29:58', `servidor_id` = '1' WHERE `direccion_ips`.`id` = 2
   (7.9ms)  COMMIT
=> #<ActiveRecord::Associations::CollectionProxy [#<DireccionIp id: 1, ip: "12.12.43.12", interfaz: "eth0", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 17:29:50", servidor_id: "1">, #<DireccionIp id: 2, ip: "56.21.123.14", interfaz: "eth1", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 17:29:58", servidor_id: "1">]>
irb(main):006:0> direccionip = DireccionIp.find(3)
  DireccionIp Load (0.5ms)  SELECT  `direccion_ips`.* FROM `direccion_ips` WHERE `direccion_ips`.`id` = 3 LIMIT 1
=> #<DireccionIp id: 3, ip: "121.32.5.7", interfaz: "eth2", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 16:54:09", servidor_id: nil>
irb(main):007:0> servidor.direccion_ip << direccionip
   (0.2ms)  BEGIN
  SQL (0.6ms)  UPDATE `direccion_ips` SET `updated_at` = '2016-11-01 17:30:03', `servidor_id` = '1' WHERE `direccion_ips`.`id` = 3
   (7.4ms)  COMMIT
=> #<ActiveRecord::Associations::CollectionProxy [#<DireccionIp id: 1, ip: "12.12.43.12", interfaz: "eth0", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 17:29:50", servidor_id: "1">, #<DireccionIp id: 2, ip: "56.21.123.14", interfaz: "eth1", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 17:29:58", servidor_id: "1">, #<DireccionIp id: 3, ip: "121.32.5.7", interfaz: "eth2", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 17:30:03", servidor_id: "1">]>
irb(main):008:0> direccionip = DireccionIp.find(4)
  DireccionIp Load (0.4ms)  SELECT  `direccion_ips`.* FROM `direccion_ips` WHERE `direccion_ips`.`id` = 4 LIMIT 1
=> #<DireccionIp id: 4, ip: "173.11.53.122", interfaz: "eth3", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 16:54:09", servidor_id: nil>
irb(main):009:0> servidor.direccion_ip << direccionip
   (0.2ms)  BEGIN
  SQL (0.5ms)  UPDATE `direccion_ips` SET `updated_at` = '2016-11-01 17:30:08', `servidor_id` = '1' WHERE `direccion_ips`.`id` = 4
   (7.6ms)  COMMIT
=> #<ActiveRecord::Associations::CollectionProxy [#<DireccionIp id: 1, ip: "12.12.43.12", interfaz: "eth0", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 17:29:50", servidor_id: "1">, #<DireccionIp id: 2, ip: "56.21.123.14", interfaz: "eth1", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 17:29:58", servidor_id: "1">, #<DireccionIp id: 3, ip: "121.32.5.7", interfaz: "eth2", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 17:30:03", servidor_id: "1">, #<DireccionIp id: 4, ip: "173.11.53.122", interfaz: "eth3", created_at: "2016-11-01 16:54:09", updated_at: "2016-11-01 17:30:08", servidor_id: "1">]>

Y si vemos en MySQL vemos que todas las IPs se han asignado al servidor_id 1, es decir, al primero:

mysql> mysql> select * from direccion_ips;
+----+---------------+----------+---------------------+---------------------+-------------+
| id | ip            | interfaz | created_at          | updated_at          | servidor_id |
+----+---------------+----------+---------------------+---------------------+-------------+
|  1 | 12.12.43.12   | eth0     | 2016-11-01 16:54:09 | 2016-11-01 17:29:50 | 1           |
|  2 | 56.21.123.14  | eth1     | 2016-11-01 16:54:09 | 2016-11-01 17:29:58 | 1           |
|  3 | 121.32.5.7    | eth2     | 2016-11-01 16:54:09 | 2016-11-01 17:30:03 | 1           |
|  4 | 173.11.53.122 | eth3     | 2016-11-01 16:54:09 | 2016-11-01 17:30:08 | 1           |
+----+---------------+----------+---------------------+---------------------+-------------+
4 rows in set (0,00 sec)

Relación muchos a muchos

Para establecer esta relación y cumplir las formas normales es necesario crear una tabla join intermedia. Esta tabla estará compuesta únicamente por las dos claves foráneas y no tendrá tampoco la clave primaria (id) que crea por defecto Rails, así que habrá que quitársela con :id => false en la migración.

El nombre de la tabla será igual al nombre de las dos tablas unidas por guión y dispuestas por orden alfabético, en nuestro caso será administradors_servidors (el plural este tan raro es el que hace Rails añadiendo simplemente una s)

ubuntu@ronr:~/gestionips$ rails generate migration CreateAdministradors_ServidorsJoin
ubuntu@ronr:~/gestionips$ ubuntu@ronr:~/gestionips$ vim db/migrate/20161101175712_create_administradors_servidors_join.rb
  class CreateAdministradorsServidorsJoin < ActiveRecord::Migration[5.0]
    def change
      create_table :administradors_servidors, :id => false do |t|
        t.integer("administrador_id")
        t.integer("servidor_id")
      end
      add_index :administradors_servidors, ["administrador_id","servidor_id"], :name => 'admin_index'
    end
  end
ubuntu@ronr:~/gestionips$ rake db:migrate

En el index hemos tenido que añadir

, :name => 'admin_index'

porque nos daba este error en el rake db:migrate

Index name 'index_administradors_servidors_on_administrador_id_and_servidor_id' on table 'administradors_servidors' is too long; the limit is 64 characters
/home/ubuntu/gestionips/db/migrate/20161101175712_create_administradors_servidors_join.rb:7:in `change'

Ahora en los dos modeles involucrados tendremos que poner has_and_belongs_to_many :el_otro_modelo.

has_and_belongs_to_many :el_otro_modelo

ubuntu@ronr:~/gestionips/app/models$ vim administrador.rb 
  class Administrador < ApplicationRecord
    belongs_to :nombre
    has_and_belongs_to_many :servidor
  end
ubuntu@ronr:~/gestionips/app/models$ vim servidor.rb 
  class Servidor < ApplicationRecord
    has_many :direccion_ip
    has_and_belongs_to_many :administrador
  end

Y ahora vamos introduciendo datos a base de buscar un administrador, un servidor y enlazarlos

irb(main):032:0> administrador=Administrador.find_by_id(6)
  Administrador Load (0.9ms)  SELECT  `administradors`.* FROM `administradors` WHERE `administradors`.`id` = 6 LIMIT 1
=> #<Administrador id: 6, created_at: "2016-11-01 17:00:13", updated_at: "2016-11-01 17:00:13", nombre_id: "2">
irb(main):033:0> servidor=Servidor.find(4)
  Servidor Load (0.8ms)  SELECT  `servidors`.* FROM `servidors` WHERE `servidors`.`id` = 4 LIMIT 1
=> #<Servidor id: 4, nombre: "SRV-Rails4", created_at: "2016-11-01 16:54:11", updated_at: "2016-11-01 16:54:11">
irb(main):034:0> administrador.servidor << servidor
   (0.6ms)  BEGIN
  SQL (0.6ms)  INSERT INTO `administradors_servidors` (`administrador_id`, `servidor_id`) VALUES (6, 4)
   (9.0ms)  COMMIT
  Servidor Load (0.9ms)  SELECT `servidors`.* FROM `servidors` INNER JOIN `administradors_servidors` ON `servidors`.`id` = `administradors_servidors`.`servidor_id` WHERE `administradors_servidors`.`administrador_id` = 6
=> #<ActiveRecord::Associations::CollectionProxy [#<Servidor id: 4, nombre: "SRV-Rails4", created_at: "2016-11-01 16:54:11", updated_at: "2016-11-01 16:54:11">, #<Servidor id: 4, nombre: "SRV-Rails4", created_at: "2016-11-01 16:54:11", updated_at: "2016-11-01 16:54:11">]>

En MySQL se vería así:

mysql> select * from administradors_servidors;
+------------------+-------------+
| administrador_id | servidor_id |
+------------------+-------------+
|                5 |           1 |
|                5 |           2 |
|                5 |           3 |
|                6 |           4 |
|                7 |           2 |
|                7 |           3 |
|                7 |           4 |
|                8 |           4 |
+------------------+-------------+
8 rows in set (0,00 sec)

Lo primero será crear el proyecto de Rails indicando que queremos mysql como motor de bases de datos, eso se hacía con la opción -d y luego mysql.

$ rails new railsymysql -d mysql
create
create README.rdoc
create Rakefile
create config.ru
create .gitignore
[...]
Use `bundle show [gemname]` to see where a bundled gem is installed.
run bundle exec spring binstub --all
* bin/rake: spring inserted
* bin/rails: spring inserted

El proyecto se llamará railsymysql y con esto ya tenemos creada la estructura de ficheros necesaria.

Ahora lo primero será generar un modelo, al que vamos a llamar Usuario (los modelos se generan en singular en Rails)

~/railsmysql$ rails generate model Usuario
Running via Spring preloader in process 465
invoke active_record
create db/migrate/20161030125505_create_usuarios.rb
create app/models/usuario.rb
invoke test_unit
create test/models/usuario_test.rb
create test/fixtures/usuarios.yml

Al crear el modelo creamos el fichero de migración inicial para definir nuestra base de datos y definimos el modelo en si como ActiveRecord

Antes de nada como tenemos vamos a usar MySQL tendremos que crear la base de datos y configurar el fichero /config/database.yml

[...]
default: &default
adapter: mysql2
encoding: utf8
pool: 5
username: edu
password: password
socket: /var/run/mysqld/mysqld.sock

development:
<<: *default
database: railsmysql_development
[...]

En mi caso voy a usar de usuario edu y como contraseña password, así que configuramos esto en el mysql

mysql> CREATE DATABASE railsmysql_development;
Query OK, 1 row affected (0,00 sec)

mysql> GRANT ALL PRIVILEGES ON railsmysql_development.* TO "edu"@"localhost" IDENTIFIED BY "password";
Query OK, 0 rows affected, 1 warning (0,00 sec)

En este punto procedemos a crear una tabla usuarios (plural del modelo) con sus campos, en este caso db/migrate/20161030125505_create_usuarios.rb

class CreateUsuarios < ActiveRecord::Migration
  def change
    create_table :usuarios do |t|
      t.column "nombre", :string, :limit => 25, :null => false
      t.string "apellidos", :limit => 50
      t.string "email", :limit => 40
      t.timestamps null: false
    end
  end
end

Y generaremos la migración

ubuntu@ronr:~/railsmysql$ rake db:migrate
== 20161030125505 CreateUsuarios: migrating ===================================
-- create_table(:usuarios)
-> 0.0474s
== 20161030125505 CreateUsuarios: migrated (0.0475s) ==========================

Y comprobamos en MySQL que se haya aplicado todo bien:

mysql> use railsmysql_development;
Database changed
mysql> show tables;
+----------------------------------+
| Tables_in_railsmysql_development |
+----------------------------------+
| schema_migrations                |
| usuarios                         |
+----------------------------------+
2 rows in set (0,00 sec)

mysql> show columns from usuarios;
+------------+-------------+------+-----+---------+----------------+
| Field      | Type        | Null | Key | Default | Extra          |
+------------+-------------+------+-----+---------+----------------+
| id         | int(11)     | NO   | PRI | NULL    | auto_increment |
| nombre     | varchar(25) | NO   |     | NULL    |                |
| apellidos  | varchar(50) | YES  |     | NULL    |                |
| email      | varchar(40) | YES  |     | NULL    |                |
| created_at | datetime    | NO   |     | NULL    |                |
| updated_at | datetime    | NO   |     | NULL    |                |
+------------+-------------+------+-----+---------+----------------+
6 rows in set (0,00 sec)

Ahora vamos a añadir una nueva columna, que se llame nickname y que vaya después de apellidos

ubuntu@ronr:~/railsmysql$ rails generate migration Nickname
Running via Spring preloader in process 753
invoke active_record
create db/migrate/20161030133824_nickname.rb

Y editamos el fichero de la migración

class Nickname < ActiveRecord::Migration
 def change
 add_column("usuarios","nickname",:string, :limit => 40, :after => "email")
 end
end

Y ejecutamos la migración comprobando que termina, que vuelve al inicio (VERSION=0) y que vuelve al final:

ubuntu@ronr:~/railsmysql$ rake db:migrate
== 20161030133824 Nickname: migrating =========================================
-- add_column("usuarios", "nickname", :string, {:limit=>40, :after=>"email"})
 -> 0.0637s
== 20161030133824 Nickname: migrated (0.0638s) ================================

ubuntu@ronr:~/railsmysql$ rake db:migrate VERSION=0
== 20161030133824 Nickname: reverting =========================================
-- remove_column("usuarios", "nickname", :string, {:limit=>40, :after=>"email"})
 -> 0.0683s
== 20161030133824 Nickname: reverted (0.0705s) ================================

== 20161030125505 CreateUsuarios: reverting ===================================
-- drop_table(:usuarios)
 -> 0.0161s
== 20161030125505 CreateUsuarios: reverted (0.0163s) ==========================

ubuntu@ronr:~/railsmysql$ rake db:migrate
== 20161030125505 CreateUsuarios: migrating ===================================
-- create_table(:usuarios)
 -> 0.0410s
== 20161030125505 CreateUsuarios: migrated (0.0412s) ==========================

== 20161030133824 Nickname: migrating =========================================
-- add_column("usuarios", "nickname", :string, {:limit=>40, :after=>"email"})
 -> 0.0643s
== 20161030133824 Nickname: migrated (0.0644s) ================================

Ahora ya podemos ver como en MySQL se ha creado

mysql> show columns from usuarios;
+------------+-------------+------+-----+---------+----------------+
| Field      | Type        | Null | Key | Default | Extra          |
+------------+-------------+------+-----+---------+----------------+
| id         | int(11)     | NO   | PRI | NULL    | auto_increment |
| nombre     | varchar(25) | NO   |     | NULL    |                |
| apellidos  | varchar(50) | YES  |     | NULL    |                |
| email      | varchar(40) | YES  |     | NULL    |                |
| nickname   | varchar(40) | YES  |     | NULL    |                |
| created_at | datetime    | NO   |     | NULL    |                |
| updated_at | datetime    | NO   |     | NULL    |                |
+------------+-------------+------+-----+---------+----------------+
7 rows in set (0,00 sec)

Una vez creado vamos a editar el campo nickname para que no pueda ser NULL y que sea un índice. Podríamos hacerlo deshaciendo los cambio y volviendo a una versión anterior, nuestro caso podríamos ver el status y luego decidir ir a la versión 20161030125505 y luego editar el fichero de migración, pero sería muy fácil.

ubuntu@ronr:~/railsmysql$ rake db:migrate:status

database: railsmysql_development

Status Migration ID Migration Name
--------------------------------------------------
up 20161030125505 Create usuarios
up 20161030133824 Nickname

Lo que queremos es crear una nueva migración que no sea reversible, es decir, crear una tabla es reversible porque se borra, pero modificar un campo no es directamente reversible ya que hay que indicar el cambio que hay que hacer y ya no nos serviría el método change de la migración teniendo que definir el método up y el método down.

ubuntu@ronr:~/railsmysql$ rails generate migration ModificarNickname
Running via Spring preloader in process 1184
      invoke  active_record
      create    db/migrate/20161030135054_modificar_nickname.rb

Y modificaríamos el fichero de migración cambiando el método change por up y por down, muy importante que down se ejecute de forma simétria a up, primero lo último que hizo up y terminar por lo primero que se ejecutó en el método up.

class ModificarNickname < ActiveRecord::Migration
  def up
    change_column("usuarios","nickname",:string,:limited => 40, :null => false)
    add_index("usuarios","nickname")
  end
  def down
    remove_index("usuarios","nickname")
    change_column("usuarios","nickname",:string,:limited => 40, :null => true)
  end
end

Y comprobamos que todo funciona perfectamente

ubuntu@ronr:~/railsmysql$ rake db:migrate
== 20161030135054 ModificarNickname: migrating ================================
-- change_column("usuarios", "nickname", :string, {:limited=>40, :null=>false})
   -> 0.0636s
-- add_index("usuarios", "nickname")
   -> 0.0381s
== 20161030135054 ModificarNickname: migrated (0.1019s) =======================

ubuntu@ronr:~/railsmysql$ rake db:migrate VERSION=0
== 20161030135054 ModificarNickname: reverting ================================
-- remove_index("usuarios", "nickname")
   -> 0.0228s
-- change_column("usuarios", "nickname", :string, {:limited=>40, :null=>true})
   -> 0.0779s
== 20161030135054 ModificarNickname: reverted (0.1009s) =======================

== 20161030133824 Nickname: reverting =========================================
-- remove_column("usuarios", "nickname", :string, {:limit=>40, :after=>"email"})
   -> 0.0619s
== 20161030133824 Nickname: reverted (0.0651s) ================================

== 20161030125505 CreateUsuarios: reverting ===================================
-- drop_table(:usuarios)
   -> 0.0242s
== 20161030125505 CreateUsuarios: reverted (0.0244s) ==========================

ubuntu@ronr:~/railsmysql$ rake db:migrate
== 20161030125505 CreateUsuarios: migrating ===================================
-- create_table(:usuarios)
   -> 0.0433s
== 20161030125505 CreateUsuarios: migrated (0.0434s) ==========================

== 20161030133824 Nickname: migrating =========================================
-- add_column("usuarios", "nickname", :string, {:limit=>40, :after=>"email"})
   -> 0.0628s
== 20161030133824 Nickname: migrated (0.0629s) ================================

== 20161030135054 ModificarNickname: migrating ================================
-- change_column("usuarios", "nickname", :string, {:limited=>40, :null=>false})
   -> 0.0714s
-- add_index("usuarios", "nickname")
   -> 0.0295s
== 20161030135054 ModificarNickname: migrated (0.1012s) =======================

Ahora ya tenemos la tabla creada en nuestra base de datos y lo que vamos a hacer es jugar con los datos es guardarlos, buscarlos, modificarlos y borrarlos.

Para introducir datos lo que vamos a hacer es crear un objeto instanciado con el modelo Usuario, tal y como lo hemos creado antes.

Para hacer todo esto lo haremos desde la consola de rails. Hay que fijarse que además nos muestra el comando SQL que ejecuta.

ubuntu@ronr:~/railsmysql$ rails console
Running via Spring preloader in process 1371
Loading development environment (Rails 4.2.6)
irb(main):001:0> datos = Usuario.new(:nombre => "Eduardo", :apellidos => "Collado Cabeza", :email => "asd@asd.com", :nickname => "ecollado")
=> #<Usuario id: nil, nombre: "Eduardo", apellidos: "Collado Cabeza", email: "asd@asd.com", nickname: "ecollado", created_at: nil, updated_at: nil>
irb(main):002:0> datos.save
   (0.3ms)  BEGIN
  SQL (0.6ms)  INSERT INTO `usuarios` (`nombre`, `apellidos`, `email`, `nickname`, `created_at`, `updated_at`) VALUES ('Eduardo', 'Collado Cabeza', 'asd@asd.com', 'ecollado', '2016-10-30 14:07:44', '2016-10-30 14:07:44')
   (8.3ms)  COMMIT
=> true

Y en MySQL veremos reflejada la inserción

mysql> mysql> select * from usuarios;
+----+---------+----------------+-------------+----------+---------------------+---------------------+
| id | nombre  | apellidos      | email       | nickname | created_at          | updated_at          |
+----+---------+----------------+-------------+----------+---------------------+---------------------+
|  1 | Eduardo | Collado Cabeza | asd@asd.com | ecollado | 2016-10-30 14:07:44 | 2016-10-30 14:07:44 |
+----+---------+----------------+-------------+----------+---------------------+---------------------+
1 row in set (0,00 sec)

Ahora ya sabemos insertar datos en la base de datos ahora tenemos que buscar, para ello podemos hacerlo con el campo clave, el ID que automáticamente nos ha generado rails o por cualquier campo.

Para bucar por campo ID o usando search_by_xxxx

irb(main):019:0> Usuario.find(4)
  Usuario Load (0.7ms)  SELECT  `usuarios`.* FROM `usuarios` WHERE `usuarios`.`id` = 4 LIMIT 1
=> #<Usuario id: 4, nombre: "Björk", apellidos: "Guðmundsdóttir", email: "bguomindsdf@islandia.com", nickname: "sugarcubes", created_at: "2016-10-30 14:20:00", updated_at: "2016-10-30 14:20:00">
irb(main):020:0> Usuario.find_by_apellidos("Gato")
  Usuario Load (0.8ms)  SELECT  `usuarios`.* FROM `usuarios` WHERE `usuarios`.`apellidos` = 'Gato' LIMIT 1
=> #<Usuario id: 5, nombre: "Isidoro", apellidos: "Gato", email: "elgatoisidoro@gately.com", nickname: "gatelycat", created_at: "2016-10-30 14:21:14", updated_at: "2016-10-30 14:21:14">

Vamos a moficar el apellido a Isidoro Gato, con el id número 5 y le vamos a poner de apellido Gato con Botas en vez de Gato

irb(main):001:0> a_modificar = Usuario.find_by_apellidos("Gato")
  Usuario Load (0.5ms)  SELECT  `usuarios`.* FROM `usuarios` WHERE `usuarios`.`apellidos` = 'Gato' LIMIT 1
=> #<Usuario id: 5, nombre: "Isidoro", apellidos: "Gato", email: "elgatoisidoro@gately.com", nickname: "gatelycat", created_at: "2016-10-30 14:21:14", updated_at: "2016-10-30 14:21:14">
irb(main):002:0> a_modificar.apellidos="Gato con Botas"
=> "Gato con Botas
irb(main):003:0> a_modificar.save
   (0.4ms)  BEGIN
  SQL (1.1ms)  UPDATE `usuarios` SET `apellidos` = 'Gato con Botas', `updated_at` = '2016-10-30 14:29:07' WHERE `usuarios`.`id` = 5
   (6.6ms)  COMMIT
=> true

Y MySQL vemos el cambio

mysql> select * from usuarios;
+----+---------+------------------+--------------------------+------------+---------------------+---------------------+
| id | nombre  | apellidos        | email                    | nickname   | created_at          | updated_at          |
+----+---------+------------------+--------------------------+------------+---------------------+---------------------+
|  1 | Eduardo | Collado Cabeza   | asd@asd.com              | ecollado   | 2016-10-30 14:07:44 | 2016-10-30 14:07:44 |
|  2 | Maria   | Peña Hernandez   | mph@asd.com              | mpena      | 2016-10-30 14:17:38 | 2016-10-30 14:17:38 |
|  3 | Alberto | Smith Garcia     | cholo@jotmeil.com        | cholo      | 2016-10-30 14:18:20 | 2016-10-30 14:18:20 |
|  4 | Björk   | Guðmundsdóttir   | bguomindsdf@islandia.com | sugarcubes | 2016-10-30 14:20:00 | 2016-10-30 14:20:00 |
|  5 | Isidoro | Gato con Botas   | elgatoisidoro@gately.com | gatelycat  | 2016-10-30 14:21:14 | 2016-10-30 14:29:07 |
+----+---------+------------------+--------------------------+------------+---------------------+---------------------+
5 rows in set (0,00 sec)

Aquí el problema es que hemos tenido que hacer tres cosas

1. Buscar
2. Modificar
3. Guardar

Y lo podemos hacer juntando los pasos 2 y 3 mediante update_attributes, vamos a volver a ponerle de apellidos simplemente Gato

irb(main):004:0> a_modificar = Usuario.find_by_apellidos("Gato con Botas")
  Usuario Load (0.7ms)  SELECT  `usuarios`.* FROM `usuarios` WHERE `usuarios`.`apellidos` = 'Gato con Botas' LIMIT 1
=> #<Usuario id: 5, nombre: "Isidoro", apellidos: "Gato con Botas", email: "elgatoisidoro@gately.com", nickname: "gatelycat", created_at: "2016-10-30 14:21:14", updated_at: "2016-10-30 14:29:07">
irb(main):005:0> a_modificar.update_attributes(:apellidos => "Gato")
   (0.3ms)  BEGIN
  SQL (0.7ms)  UPDATE `usuarios` SET `apellidos` = 'Gato', `updated_at` = '2016-10-30 14:31:50' WHERE `usuarios`.`id` = 5
   (8.4ms)  COMMIT
=> true

El resultado en ambos casos sería el mismo, sólo que con update_attributes nos ahorramos el guardar.

Ya sólo nos quedaría borrar un registro, eso lo haremos con destroy, que no es lo mismo que delete, en nuestro caso usaremos siempre destroy.

irb(main):008:0> a_modificar = Usuario.find_by_apellidos("Gato")
  Usuario Load (0.8ms)  SELECT  `usuarios`.* FROM `usuarios` WHERE `usuarios`.`apellidos` = 'Gato' LIMIT 1
=> #<Usuario id: 5, nombre: "Isidoro", apellidos: "Gato", email: "elgatoisidoro@gately.com", nickname: "gatelycat", created_at: "2016-10-30 14:21:14", updated_at: "2016-10-30 14:31:50">
irb(main):009:0> a_modificar.destroy
   (0.1ms)  BEGIN
  SQL (0.4ms)  DELETE FROM `usuarios` WHERE `usuarios`.`id` = 5
   (11.8ms)  COMMIT
=> #<Usuario id: 5, nombre: "Isidoro", apellidos: "Gato", email: "elgatoisidoro@gately.com", nickname: "gatelycat", created_at: "2016-10-30 14:21:14", updated_at: "2016-10-30 14:31:50">

Ya sólo nos quedaría algo para bordar este post, que serían los named scopes, que vendría a ser algo parecido a una macro de SQL que nos permitirá reutilizar código y hacer la lectura y escritura de nuestro código más sencilla.

Los named scopes se llaman como si fueran métodos de ActiveRelation y requieren sintaxis lambda.

   scope :active, lambda {where(:active => true)}

O con parámetros

   scope :with_content_type, lambda {|ctype| where(:content_type => true)}

Se definen en el directorio /app/models dentro de los modelos correspondientes, en nuestro caso definiremos una nueva columna en la base de datos y crearemos un scope para sacar todos aquellos visibles e invisbles:

ubuntu@ronr:~/railsmysql$ rails generate migration Visible
Running via Spring preloader in process 1506
      invoke  active_record
      create    db/migrate/20161030144303_visible.rb
ubuntu@ronr:~/railsmysql$ vim db/migrate/20161030144303_visible.rb

Y configuraremos el fichero de esta manera

class Visible < ActiveRecord::Migration
  def change
    add_column("usuarios","visible", :boolean, :default =>true, :after => "nickname")
  end
end

Luego haremos la migración

ubuntu@ronr:~/railsmysql$ rake db:migrate
== 20161030144303 Visible: migrating ==========================================
-- add_column("usuarios", "visible", :boolean, {:default=>true, :after=>"nickname"})
   -> 0.1167s
== 20161030144303 Visible: migrated (0.1168s) =================================

Y configuraremos en el fichero del modelo, en nuestro caso app/models/usuario.rb

class Usuario < ActiveRecord::Base
        scope :visible, lambda {where(:visible => true)}
        scope :invisible, lambda {where(:visible => false)}
        scope :ordenado, lambda {order("usuarios.id ASC")}
        scope :nuevos_primero, lambda {order("usuarios.id DESC")}
end

Así tendremos por ejemplo:

irb(main):009:0* Usuario.visible
  Usuario Load (0.8ms)  SELECT `usuarios`.* FROM `usuarios` WHERE `usuarios`.`visible` = 1
=> #<ActiveRecord::Relation [#<Usuario id: 1, nombre: "Eduardo", apellidos: "Collado Cabeza", email: "asd@asd.com", nickname: "ecollado", visible: true, created_at: "2016-10-30 14:07:44", updated_at: "2016-10-30 14:07:44">, #<Usuario id: 2, nombre: "Maria", apellidos: "Peña Hernandez", email: "mph@asd.com", nickname: "mpena", visible: true, created_at: "2016-10-30 14:17:38", updated_at: "2016-10-30 14:17:38">, #<Usuario id: 3, nombre: "Alberto", apellidos: "Smith Garcia", email: "cholo@jotmeil.com", nickname: "cholo", visible: true, created_at: "2016-10-30 14:18:20", updated_at: "2016-10-30 14:18:20">, #<Usuario id: 4, nombre: "Björk", apellidos: "Guðmundsdóttir", email: "bguomindsdf@islandia.com", nickname: "sugarcubes", visible: true, created_at: "2016-10-30 14:20:00", updated_at: "2016-10-30 14:20:00">]>
irb(main):010:0> Usuario.invisible
  Usuario Load (0.7ms)  SELECT `usuarios`.* FROM `usuarios` WHERE `usuarios`.`visible` = 0
=> #<ActiveRecord::Relation []>
irb(main):011:0> Usuario.ordenado
  Usuario Load (0.7ms)  SELECT `usuarios`.* FROM `usuarios`  ORDER BY usuarios.id ASC
=> #<ActiveRecord::Relation [#<Usuario id: 1, nombre: "Eduardo", apellidos: "Collado Cabeza", email: "asd@asd.com", nickname: "ecollado", visible: true, created_at: "2016-10-30 14:07:44", updated_at: "2016-10-30 14:07:44">, #<Usuario id: 2, nombre: "Maria", apellidos: "Peña Hernandez", email: "mph@asd.com", nickname: "mpena", visible: true, created_at: "2016-10-30 14:17:38", updated_at: "2016-10-30 14:17:38">, #<Usuario id: 3, nombre: "Alberto", apellidos: "Smith Garcia", email: "cholo@jotmeil.com", nickname: "cholo", visible: true, created_at: "2016-10-30 14:18:20", updated_at: "2016-10-30 14:18:20">, #<Usuario id: 4, nombre: "Björk", apellidos: "Guðmundsdóttir", email: "bguomindsdf@islandia.com", nickname: "sugarcubes", visible: true, created_at: "2016-10-30 14:20:00", updated_at: "2016-10-30 14:20:00">]>
irb(main):012:0> Usuario.nuevos_primero
  Usuario Load (0.7ms)  SELECT `usuarios`.* FROM `usuarios`  ORDER BY usuarios.id DESC
=> #<ActiveRecord::Relation [#<Usuario id: 4, nombre: "Björk", apellidos: "Guðmundsdóttir", email: "bguomindsdf@islandia.com", nickname: "sugarcubes", visible: true, created_at: "2016-10-30 14:20:00", updated_at: "2016-10-30 14:20:00">, #<Usuario id: 3, nombre: "Alberto", apellidos: "Smith Garcia", email: "cholo@jotmeil.com", nickname: "cholo", visible: true, created_at: "2016-10-30 14:18:20", updated_at: "2016-10-30 14:18:20">, #<Usuario id: 2, nombre: "Maria", apellidos: "Peña Hernandez", email: "mph@asd.com", nickname: "mpena", visible: true, created_at: "2016-10-30 14:17:38", updated_at: "2016-10-30 14:17:38">, #<Usuario id: 1, nombre: "Eduardo", apellidos: "Collado Cabeza", email: "asd@asd.com", nickname: "ecollado", visible: true, created_at: "2016-10-30 14:07:44", updated_at: "2016-10-30 14:07:44">]>

Una vez se ha creado el entorno en Rails, en mi caso en una máquina LXC procedemos a empezar a trabajar con ella.

Lo primero es crear un tunel para que cuando desde nuestra máquina abramos localhost:3000 se abra realmente el puerto 3000 del contenedor donde tenemos instalado Rails, en mi caso utilizo la aplicación gSTM (Gnome SSH Tunnel Manager) que podéis instalarla desde la fuente o con

apt-get install gstm

En la máquina donde hay que correr rails es importante saber que tenemos que instalar nuestra llave ssh para no tener que poner el password todo el rato.

ssh-copy-id ubuntu@10.0.3.252

Una vez hecho eso la configuración del gSTM quedará tal y como se ve en la imagen de la izquierda.

Otra cosa que tenemos que hacer es preparar nuestro editor de textos, en mi caso el Sublime 2, para ello la forma más fácil es montar por ssh esa máquina en nuestro Ubuntu usando el navegador de archivos de Ubuntu.

Una vez montado el directorio remoto nos lo dejará en un directorio del estilo

/run/user/1000/gvfs/sftp:host=10.0.3.252,user=ubuntu/home/ubuntu/prueba

Pues abrimos ese directorio con el Sublime y ya estaremos modificando los ficheros directamente en nuestra máquina virtual.

Y por si «metemos la gamba» en algún momento es interesante configurarse el git, para ello en el directorio donde esté nuestro proyecto:

git init

git add . && git commit -m ‘nuevo proyecto en rails’

Pues llegados a este punto ya podemos empezar a escribir código

Creando una página

Con casi total seguridad lo primero que vamos a querer es escribir una página de inicio, para ello tendremos que crear un controlador y una acción que nos generará el primer fichero.

Desde el directorio raiz del proyecto:

rails generate controller home index

Donde home es el controlador e index es la acción. Esto nos va a generar el directorio /app/views/home y dentro encontraremos index.html.erb que será nuestra página.

Pero también nos va a generar el fichero donde definiremos las acciones que será /app/controllers/concerns/home_controler.rb.

Y por último saber que nos va a generar el layout que es donde vamos a controlar todos los aspectos genéricos, es decir, las cabeceras html de los ficheros. Ese fichero en este caso será /app/views/layouts/application.html.rb.

Creando código

La página por defecto de rails la querremos cambiar por el index que acabamos de crear, para ello en el fichero /app/config/routes.rb que encontraremos algo como:

get ‘home#index’

podremos

root ‘home#index’

el get de arriba lo quitaremos pues ya no lo necesitamos, y a partir de este momento la acción index del controlador home será nuestra página principal.

Y ya podemos modificar el fichero de acción de /app/views/home/index.html.erb la acción poniendo por ejemplo

<h1>Bienvenidos</h1>
<p>Esta es mi primera página en rails y se modifica en: /app/views/home/index.html.erb</p>

y al abrir el navegador en el puerto 3000 veremos justo esta página.

Si quisieramos crear otra acción dentro del mismo controlador tendríamos que crear un fichero nuevo en el directorio del controlador que será la acción correspondiente, por ejemplo blog.html.erb dentro de /app/views/home, luego tendríamos que modificar el fichero routes.rb poniendo una línea como esta:

 get ‘/blog’ => ‘home#blog’

Y, aunque no es necesario si es bueno hacerlo, modificando el home_controller.rm y añadiendo una acción vacía

def blog

end

Y ahora al ver la página http://localhost:3000/blog veremos la página que hemos creado, en este caso como no hemos creado contenido estará en blanco.

Y ahora si queremos añadir elementos comunes a las dos páginas lo que podemos hacer es editar el fichero /app/views/layouts/application.html.erb y poner un pequeño menú:

<a href=»/»>Inicio</a> | <a href=»/blog»>Blog</a>

O incluso cambiar el CSS incluyendo el bootstrap tirando de CDN metiendo este otro código

<!– Latest compiled and minified CSS –>
<link rel=»stylesheet» href=»https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css» integrity=»sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u» crossorigin=»anonymous»>

Esto ahora lo podemos ver en un screencast que seguro que queda más claro.

En el screencast instalo sobre una Ubuntu 16.04 limpia corriendo en LXC Ruby versión 2.3.1 con rbenv y Rails versión 4.2.6 con Mysql.

Si queréis ver como funciona LXC podéis ver mi post anterior titulado LXC en Ubuntu 16.04 y si queréis profundizar un poco más podéis leer Control de recursos en LXC, memoria y CPU.

Obviamente si queréis le podéis poner los mismos colores que Twitter y así tendréis un clon perfecto, al final es poco más que una plantilla.

Todo tiene su público y hay gente que usa Twitter, gente que usa status, o cualquier otra opción de microblogging, o incluso gente que usa otras aplicaciones de microblogging.

También es posible que queramos en nuestra empresa, escuela o comunidad tener una herramienta de este estilo y que funcione en nuestra intranet, en fin, hay muchísimas posibildiades, cada uno tendrá las suyas y si esto le vale pues perfecto.

Yendo al grano os comento, yo tengo creado uno en micro.eduardocollado.com y lo instalé porque quería tomar notas que no salieran en Twitter, no todo tiene porque estar en Twitter.

El tema en concreto ser llama P2 y lo podéis descargar desde este enlace, donde pone «Descarga P2 Classic para tu sitio de WordPress alojado en otra empresa.«

Los pasos serían los siguientes:

Paso 1: Modificar el fichero wp-config.php

El primer paso consiste en editar el fichero wp-config.php en nuestro servidor y poner las siguientes dos líneas:

/* Multisite */
define( ‘WP_ALLOW_MULTISITE’, true );

Paso 2: Desactivar los plugins, todos

Para poder continuar tenemos que desactivar todos los plugins, y cuando digo todos es todos, posteriormente los podremos volver a activar, así que no hay que preocuparse.

Paso 3: Finalizar la configuración del wp-config.php y modificar el .htaccess

Ahora si vamos a Herramientas – Configuración de Red nos indicará los cambios que tenemos que hacer en el wp-config.php y el .htaccess.

En mi caso en el wp-config.php tuve que añadir las siguientes líneas justo encima de la línea con el contenido /* ¡Eso es todo, deja de editar! Feliz blogging */

Esta información se nos proporciona en Ajustes – Configuración de la red.

Y quedó así:

[…]
define(‘MULTISITE’, true);
define(‘SUBDOMAIN_INSTALL’, true);
define(‘DOMAIN_CURRENT_SITE’, ‘eduardocollado.com’);
define(‘PATH_CURRENT_SITE’, ‘/’);
define(‘SITE_ID_CURRENT_SITE’, 1);
define(‘BLOG_ID_CURRENT_SITE’, 1);

También se nos indica que tenemos que modificar el fichero .htaccess y ponerle este contenido:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ – [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]

No os preocupéis por el .htaccess antiguo, aunque si queréis podéis guardar una copia.

Paso 4: Terminar de configurar nuestro WordPress Multisite

Para terminar de configurar nuestro WordPress Multisite tendremos que ir a Ajustes – Ajustes de red y rellenar ahí las opciones que queramos, como por ejemplo quien puede crear nuevos blogs, cuotas por usuarios, etc… A esto es importarle dedicarle un rato para configurar adecuadamente nuestro WordPress Multisite.

Paso 5: Configurar el servidor (DNSs y Apache)

Para explicar este punto voy a utilizar la configuración de los servidores cloud de Neodigit y no otros, pero al final la idea subyacente es la misma, solo que en Neodigit siempre será muchísimo más sencillo de hacer.

Para configurar el DNS simplemente irémos a la zona DNS de nuestro dominio y crearemos una entrada comodín (wildcard) para que resuelvan todos los subdominios. La configuración será la siguiente:

Y ahora configuraremos el alias de host para nuestro dominio en Multidominio/Cloud – Alojamiento que corresponda – Subdominio – Alias de Host:

Y podremos una entrada del tipo:

*.dominio.tld

Nota: Obviamente es necesario tener contratado un servidor cloud o un multidominio.

Paso 6: Empezar a trabajar

Aquí nos volveremos a logar en nuestro wordpress y nos iremos a nuestro blog primigenio para volver a activar los plugins desactivados.

Y una vez hecho eso irémos a Mis Sitios – Blog y podremos entrar en el blog que queramos.

Simple y fácil

Para limitar memoria y CPU tenemos que utilizar el comando lxc-cgroup y utilizar los modificadores de kernel que vienen descritos en: http://www.mjmwired.net/kernel/Documentation/cgroups/memory.txt que son los siguientes

tasks # attach a task(thread) and show list of threads
 cgroup.procs # show list of processes
 cgroup.event_control # an interface for event_fd()
 memory.usage_in_bytes # show current usage for memory
 (See 5.5 for details)
 memory.memsw.usage_in_bytes # show current usage for memory+Swap
 (See 5.5 for details)
 memory.limit_in_bytes # set/show limit of memory usage
 memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
 memory.failcnt # show the number of memory usage hits limits
 memory.memsw.failcnt # show the number of memory+Swap hits limits
 memory.max_usage_in_bytes # show max memory usage recorded
 memory.memsw.max_usage_in_bytes # show max memory+Swap usage recorded
 memory.soft_limit_in_bytes # set/show soft limit of memory usage
 memory.stat # show various statistics
 memory.use_hierarchy # set/show hierarchical account enabled
 memory.force_empty # trigger forced move charge to parent
 memory.pressure_level # set memory pressure notifications
 memory.swappiness # set/show swappiness parameter of vmscan
 (See sysctl's vm.swappiness)
 memory.move_charge_at_immigrate # set/show controls of moving charges
 memory.oom_control # set/show oom controls.
 memory.numa_stat # show the number of memory usage per numa node

memory.kmem.limit_in_bytes # set/show hard limit for kernel memory
 memory.kmem.usage_in_bytes # show current kernel memory allocation
 memory.kmem.failcnt # show the number of kernel memory usage hits limits
 memory.kmem.max_usage_in_bytes # show max kernel memory usage recorded

memory.kmem.tcp.limit_in_bytes # set/show hard limit for tcp buf memory
 memory.kmem.tcp.usage_in_bytes # show current tcp buf memory allocation
 memory.kmem.tcp.failcnt # show the number of tcp buf memory usage hits limits
 memory.kmem.tcp.max_usage_in_bytes # show max tcp buf memory usage recorded

Para limitar en un contenedor la memoria a 128M lo haríamos con el comando:

lxc-cgroup -n nombre_contenedor memory.limit_in_bytes 128M

Si nuestro servidor tiene 4 cores (0,1,2,3)  y queremos asignar el core 1 y 3 a un contenedor lo haríamos con el comando:

lxc-cgroup -n nombre_contenedor cpuset.cpus 1 3

Y llegamos al momento de limitar la swap que debería de ser algo del estilo:

lxc-cgroup -n nombre_contenedor memory.memsw.limit_in_bytes 128M

Sin embargo a mi esto no me ha funcionado, y no he encontrado otra forma de hacerlo, seguramente algo del kernel que tengo instalado en mi portátil. La idea es limitar la memoria total incluyendo swap a la memoria RAM para que de facto la memoria swap sea 0, pero como ya he comentado no me funciona, si alguien consigue que funcione que lo comente por favor.

Tenemos que tener en cuenta que todos los comandos que hemos usado hasta ahora sólo nos sirven para la ejecución en vivo, pero no para el arranque, si queremos que arranquen con estas opciones habría que modificar el fichero de configuración que se encuentra en

/var/lib/lxc/nombre_contenedor/config

Y ahí añadiríamos las opciones deseadas, siguiendo este formato y usando las opciones de arriba:

#Limite de memoria
lxc.cgroup.memory.limit_in_bytes = 256M

#Limite de CPU a 1 core
lxc.cgroup.cpuset.cpus = 1

Lo primero será instalar el lxc, para ello simplemente:

sudo apt-get install lxc

Una vez instalado comprobaremos que esté todo bien, habilitado y soportado en el kernel:

Una vez está instalado podemos proceder a ver las plantillas que tenemos ya preinstaladas:

Y procedemos a instalar una de ellas, en nuestro caso una ubuntu con:

edu@thinkpad:~$ sudo lxc-create -n ubuntu-lxc -t ubuntu

Aquí ubunut-lxc es el nombre del contenedor y puede ser cualquier cosa. Si hubiermos escrito al final

-- --release xenial

le estaríamos diciendo la release concreta que quisieramos.

Una vez veamos por pantalla

##
# The default user is 'ubuntu' with password 'ubuntu'!
# Use the 'sudo' command to run tasks as root in the container.
##

ya tenemos preparado el contenedor para ser usado.

Para ver los contenedores que tenemos podemos poner

sudo lxc-ls --fancy

Y podremos trabajar con ellos, los comandos básicos para trabajar con los lxc serían los siguiente (ubuntu-lxc es el nombre de mi contenedor, cambiar por el nombre que se quiera):

sudo lxc-ls --fancy: Listado de contenedores
sudo lxc-create -n ubuntu-lxc -t ubuntu -- --release xenial: Crear contenedor 
sudo lxc-start -n ubuntu-lxc -d: Arrancar contenedor 
sudo lxc-console -n ubuntu-lxc: Conectar a la consola, para salir de la misma Ctrl-a + q
sudo lxc-stop -n ubuntu-lxc: Parar el contenedor
sudo lxc-destroy -n ubuntu-lxc: Destruir el contenedor
sudo lxc-clone -o ubuntu-lxc -n nuevo-ubuntu-lxc: Clonar el contenedor

Aquí os dejo un pequeño vídeo para que podáis ver el proceso,  veréis que he instado dos contenedores, el primero se ha bajado todo de ubuntu y el segundo como ya estaban los ficheros en la caché local ha tardado un par de segundos en instalarse.

Y que no os pase como a mi, para salir de la consola es Ctrl-a + q

Por poner un ejemplo, quizás parezca un poco absurdo, pero creerme que no lo es, imaginad que os vais a pasar unos días fuera de casa y os lleváis vuestro teléfono IP, el cual no tiene wifi, pero os lo lleváis porque estáis muy contentos con él y los softphones que hay para linux son bastante peores, ya que no disponen de cancelación de ruido de fondo entre otras cosas.

Estáis fuera y con un móvil podéis hacer teetering y generar una Wifi, a la cual os conectáis con el portátil, pero … ¿cómo os conectáis con el teléfono?, no se puede a priori.

Bueno, sí se puede, para ello os comparto una de mis recetas de usos veraniegos

1. Instalar un servidor de DHCP, ojo, no es necesario que arranque siempre por defecto, puede ser que no estemos siempre con la necesidad de generar DHCP.
2. Instalar un firewall para hacer NAT del teléfono (o red local generada).
3. Importantísimo, habilitar el fordwarding en el linux.

Estos tres pasos los tengo hechos en mi portátil con una Ubuntu 16.04.

Para instalar un servidor de DHCP:

sudo apt-get install isc-dhcp-server

Esto obviamente no es ciencia, ahora la configuración aunque no es muy complicada, os pego la que he usado en mi caso, os pego sólo lo que he añadido en el fichero /etc/dhcp/dhcpd.conf:

option subnet-mask 255.255.255.0;
option broadcast-address 192.168.89.255;
option routers 192.168.89.1;
option domain-name-servers 8.8.8.8,8.8.4.4;
option domain-name "eduangi.com";

subnet 192.168.89.0 netmask 255.255.255.0 {
range 192.168.89.10 192.168.89.100;
}

En mi caso la red que he levantado para usar el teléfono y crear una lan donde me haga falta es la 192.168.89.0/24.

También hay que añadir al fichero /etc/default/isc-dhcp-server donde yo he añadido

INTERFACES="enx803f5d093ea8"

Sí, mi ethernet se llama así :(, es un adaptador USB.

Y ahora lo más importante es que el servicio no arranque por defecto, para ello simplemente

sudo update-rc.d isc-dhcp-server disable

Genial, ahora vamos a por el siguiente paso, el NAT, para ello necesitaremos tener instalado iptables y agregar la regla siguiente:

sudo iptables -t nat -A POSTROUTING -s 192.168.89.0/24 -o tun0 -j MASQUERADE

Obviamente esta regla hace referencia a la red que yo me he dado de alta para tener mi teléfono corriendo y cada uno deberá de modificarsela. En cuanto a -o tun0 hace referencia a que quiero que el tráfico quiero que salga por la Open VPN  que tengo corriendo en el portátil porque como ya he comentado la voy a usar para conectar un teléfono y obviamente la centralita no tiene IP pública.

Y para habilitar el forwarding simplemente ejecutaremos como root:

echo 1 > /proc/sys/net/ipv4/ip_forward

Ahora, como configurar esto va por gustos, en mi caso como hay he comentado antes al arrancar si quiero usar esa red me gusta levantarla a mano y esto es:

sudo /etc/init.d/isc-dhcp-server start
sudo iptables -t nat -A POSTROUTING -s 192.168.89.0/24 -o tun0 -j MASQUERADE
sudo -i
echo 1 > /proc/sys/net/ipv4/ip_forward

Así que si tenéis la necesidad de levantar alguna red ethernet y conectarla a la wifi de vuestro linux ya sabéis como, aunque si sois gente «normal» quizás no necesitéis esto jamás, pero … nunca se sabe.

De momento Nextcloud proporciona el software pare el servidor y cliente para móvil Android, el cliente de escritorio todavía está en camino, pero irá llegando poco a poco.

De momento Nextcloud, que se ha formado como empresa independiente en Alemania, ofrece un servicio muy similar a Owncloud, pero prometen mejorar todo lo anterior.

De momento si queréis actualizar de Owncloud a Nextcloud el proceso es extremadamente fácil, lo único que hay que hacer es subir Nextcloud al servidor y poner ahí los directorios data y config el resto funcionará o debería de funcionar solo.

De momento yo ya he actualizado mi owncloud personal a nextcloud a ver qué tal funciona, de momento muy bien, y ya iremos hablando más sobre este fantástico producto que se puede instalar en proveedores como Neodigit para poder almacenar nuestros datos en un buen CPD.

Os dejo el Hangout para que podáis verlo y enteraros de primera mano.

En entornos empresariales el modelo de una red de nivel 2 es fantástico pues permite tener los dispositivos en la misma red y que todos se vean entre si, además hablamos de dispositivos físicos como impresoras o PCs que rara vez van a moverse de sitio.

Ahora imaginemos un entorno de máquinas virtuales donde cada máquina es de un cliente y que no quiere que otros clientes vean su máquina por nivel 2, además, queremos poder mover la máquina de hipervisor, e incluso de rack o CPD. Imaginemos un entorno en el que lo queremos limpio sin multitud de vlans ni problemas de spanning tree.

Existen soluciones parciales, como trill u otras cerradas similares. Luego tenemos soluciones que nos permiten mover máquinas virtuales entre hipervisores, pero todas tienen una cosa en común, hay que «casarse con el proveedor de red y/o virtualización» y eso es algo que va en contra de la forma de trabajar que tenemos en Tecnocrática o en Neodigit.

Nosotros nos encontramos con ese problema en el momento de definir la plataforma de virtualización ya que queríamos ofrecer una serie de servicios que o no podíamos ofrecer con plataformas como VMWare o simplemente no eran soluciones competitivas ni en tiempo ni en dinero.

Ante esa situación lo que hicimos fue encerrarnos durante unos meses para intentar encontrar una solución, y al final la solución salió, por una parte una solución propia para el tema de los hipervisores de la que no puedo ofrecer muchos detalles al no estar directamente en mi área, pero totalmente automatizada y la solución de red que voy a pasar a describir a continuación y que se basa en anunciar rutas /32 dentro de nuestra red, una para cada servidor.

Al anunciar /32 lo que conseguimos es una granularidad total de la red, el problema es que el modelo de 3 capas de Cisco, que hasta ese día para mi era algo sagrado dejó de servir.

La forma de hacerlo consiste en ejecutrar uno o varios routers virtuales en cada hipervisor y hacer ahí los anuncios de routing, es decir, la solución fue llevar el nivel 3 directamente al hipervisor, sin vlans, sin nivel 2. Sin querer nos encontramos con un servicio nivel 3 puro desde el punto de tránsito hasta la propia máquina virtual, pero extremadamente flexible.

Una vez teníamos la teoría y alguna maqueta rudimentaria el siguiente paso era la automatización desde el panel de control que desarrollamos para nuestros servicios y que fuera el panel de control el que configurara los servidores virtuales y los routers.

Por supuesto no valía eso de crear plantillas y clonar pues eso requería de un trabajo de mantenimiento de plantillas totalmente absurdo pudiendo tener otras soluciones como PXE que sirve para configurar servidores, y ojo, fijaros que cosa tan curiosa, pero con PXE también podíamos levantar máquinas Debian con Quagga, es decir, routers de forma automática.

En nuestra solución el servidor que se aprovisionaba tenía que pasar por varios estados, el primero era autoconfigurarse por PXE y una vez configurado tenía que levantar con el direccionamiento público.

Una vez configurado el servidor éste arrancaba con la siguiente configuración de red.

# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 31.47.76.xxx
netmask 255.255.255.255
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx
dns-search neodigit.net

post-up route add 10.10.10.10 dev eth0
post-up route add default gw 10.10.10.10

Como podéis ver la máquina tiene una IP y una máscara /32 y un gateway 10.10.10.10.

Para hacer esto todos los routers son iguales y tienen una pata, donde se conectan las máquinas virtuales que tienen la IP: 10.10.10.10/24 y la MAC: 00:80:10:10:10:10, todos iguales, por cierto, la mac es de un Commodore, por si alguien quiere ver qué router usamos la MAC le dirá que un Commodore, esta fue una licencia poética, pero nos permite que si movemos una máquina de hipervisor su gateway esté donde esté tendrá la misma IP y la misma MAC.

Ahora, el interfaz del router con al IP 10.10.10.10 correrá proxy arp. Antes de que nadie lo diga existe una opinión muy extendida que el rendimiento con proxy arp baja, pero claro, en este escenario podemos levantar tantos routers como queramos, así que el rendimiento nos da básicamente lo mismo porque nos cuesta lo mismo tener un router cada 200 máquinas que cada 10, así que en este escenario el rendimiento no es un problema, además es todo automático, nosotros no tocamos manualmente ningún equipo.

Para anunciar el servidor lo único que hacemos es inyectar una ruta /32 a la IP del servidor por el interfaz de proxy arp y esta se redistribuye automáticamente en el protocolo de routing, en nuestro caso y de momento OSPF, pero como es independiente a la plataforma es cambiable por otros.

Si queremos mover una máquina de hipervisor, o de país, lo único que hacemos es mover la máquina virtual borrar la ruta del router viejo y añadirla al nuevo, esta se redistribuirá automáticamente y a funcionar.

Además se pueden dar otro tipo de soluciones más imaginativas, por ejemplo un hipervisor en Madrid, otro en Miami, el de Miami, los dos con la misma IP y sincronizándose por otro interfaz, el de Madrid se anuncia con un coste y el Miami con un coste muy penalizado, si cae el de Madrid automáticamente la máquina de Miami cogería todo el tráfico y ya tendríamos un servicio de BRS.

Las posibilidades como podéis ver son enormes y nos abren un mundo de posibilidades casi infinito.

Este post es un resumen de una presentación hecha en el esNOG 17 en Barcelona el 12 de Mayo de 2016. La presentación la podéis descargar desde el siguiente enlace: Modelo de distribución sin VLANs para centros de datos virtualizados: El enfoque tecnócrata.

15 Mayo de 2016 – ACTUALIZACIÓN

Ya tengo el enlace al vídeo de la charla, así que aquí os la dejo.

Lo primero es saber qué es quagga, además de una especie de cebra extinta. Quagga se creó como fork de Zebra hace ya algunos años, si no recuerdo mal en el 2001 ó 2002, quizás algún año después, tras una discusión en la lista bastante agria sobre el uso que estaba haciendo el creador de Zebra con el software y las pocas actualizaciones que sufría el mismo, tampoco voy a meterme en esos charcos ya que esto lo comento de memoria y hace algunos años de aquello y tampoco voy a dedicar tiempo en buscar esos correos.

Quagga es un software formado por un conjunto de demonios que ejecutan distintos protocolos de routing y que convierten cualquier caja con GNU/Linux en un router totalmente funcional. Esto cuando salió el software era un poco extraño usarlo, pero el precio de los routers de la época lo justificaba, hoy en día el uso de routers en máquinas virtuales le dan una nueva vida al software y abren un buen abanico de posibilidades que ya iremos comentando.

Pues vamos a ver el proceso de instalación paso a paso.

Lo primero sería tener una distribución de Linux instalada, en mi caso voy a utilizar una Debian 8, obivamente si por alguna razón queréis instalar este software en distribuciones basadas en RedHat, Arch u otras tendréis que tener en cuenta que habrá diferencias.

Pero antes de instalar el software tenemos que tener una cosa clara, estamos instalando un router, es decir, el tráfico va a entrar por un interfaz y va a salir por otro, es decir, hay que habilitar el ip forwarding, que no se nos olvide:

# echo «1» > /proc/sys/net/ipv4/ip_forward

Y para que arraqneu siempre por defecto sin que tengamos que volver a configurar nada:

# echo «net.ipv4.ip_forward = 1» >> /etc/sysctl.conf

Si no tenemos el ip forwarding habilitado en nuestra caja linux Quagga no funcionará bien, a ver, funcionará pero no enviará tráfico, será como un pisapapeles software, podremos comprobarlo con show ip forwarding en zebra o con vtysh, que ya lo veremos otro día, esto es malo:

root@debian:/etc/quagga# vtysh -c «show ip forwarding»
IP forwarding is off

Esto es bueno:

root@debian:/etc/quagga# vtysh -c «show ip forwarding»
IP forwarding is on

Bien, ya podemos dejarnos de cosas raras y proceder a instalar el software y los ficheros de ejemplo:

apt-get install quagga quagga-doc

Ahora prepararemos los ficheros de configuración que vamos a necesitar, para este ejemplo vamos a utilizar zebra.conf y ospfd.conf. Los ficheros estarán en el directorio /usr/share/doc/quagga/examples/

root@debian:/usr/share/doc/quagga/examples# ls
babeld.conf.sample isisd.conf.sample ripd.conf.sample zebra.conf.sample
bgpd.conf.sample ospf6d.conf.sample ripngd.conf.sample
bgpd.conf.sample2 ospfd.conf.sample vtysh.conf.sample

De todos estos ficheros copiaremos zebra.conf.sample y ospfd.conf.sample y los llevaremos a /etc/quagga, obviamente los renombraremos quitando el .sample

# cp/usr/share/doc/quagga/examples/zebra.conf.sample /etc/quagga/zebra.conf
# cp /usr/share/doc/quagga/examples/ospfd.conf.sample ospfd.conf

Texto obsoleto y eliminado el 10/05/2018

Ahora ya podemos habilitar los demonios que vamos a utilizar, para ello editaremos el fichero /etc/quagga/daemons

vim /etc/quagga/daemons

zebra=yes
bgpd=no
ospfd=yes
ospf6d=no
ripd=no
ripngd=no
isisd=no
babeld=no

Actualización texto añadido el 10/05/2018

Ahora ya podemos habilitar los demonios que vamos a utilizar, para ello ejecutaremos los siguientes comandos:

/usr/sbin/zebra –dk
/usr/sbin/ospfd –d
/usr/sbin/bgpd –d
/usr/sbin/isisd -d
/usr/sbin/ripd -d
/usr/sbin/…

donde -d significa arrancar en modo demonio y -k significa que no puedan ser eliminadas las rutas del kernel

Y reiniciamos quagga

# /etc/init.d/quagga restart

Y ya podemos entrar por telnet a la configuración de zebra y de ospf. Hay que tener en cuenta que a cada demonio se entra por un puerto diferente, aunque también podemos utilizar el nombre del puerto.

zebra:2601
ripd: 2602
ripng: 2603
ospfd: 2604
bgpd: 2605
ospf6d:  2606

Ahora sí, vamos a por esa configuración.

root@debian:/etc/quagga# telnet localhost zebra
Trying ::1…
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.

Hello, this is Quagga (version 0.99.23.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification

Password:

La contraseña por defecto es zebra (se puede ver en el fichero zebra.conf) y como podéis ver la configuración es muy similar a la configuración de IOS de Cisco, con lo cual si estáis mínimamente acostumbrados a tratar con routers Cisco la parte de configuración resulta trivial

Router> en
Password:
Router# sh run
Router# sh running-config

Current configuration:
!
hostname Router
password zebra
enable password zebra
!
interface eth0
ipv6 nd suppress-ra
!
interface eth1
ipv6 nd suppress-ra
!
interface lo
!
!
!
line vty
!
end

Y a partir de aquí podemos trabajar, en mi caso en la misma red que el interfaz eth1 tengo otros dos routers corriendo OSPF para poder ver algo con este router, así que configuraremos en el eth1 la IP 1.1.1.3/24 y luego una configuración estándar de OSPF.

Sin embargo hay que tener en cuenta una cosa y es que Quagga tiene un pequeño problema en la instalación, al menos en Debian y es que Quagga no tiene permisos para escribir sus propios ficheros de configuración, así que para solucionar eso tenéis que cambiar el propietario de los ficheros en el directorio /etc/quagga y ajustar los permisos:

# chown -R quagga:quaggavty
# chmod 640 /etc/quagga/*.conf

Por favor, no hagáis eso tan horrible de chmod 777, es bastante desagradable ;-).

Una vez hecho esto ya podemos guardar configuraciones

root@debian:/etc/quagga# telnet localhost 2601
Trying ::1…
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.

Hello, this is Quagga (version 0.99.23.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification

Password:
Router> en
Password:
Router# conf t
Router(config)# int eth1
Router(config-if)# ip ad 1.1.1.3/24
Router(config-if)# exit
Router(config)# exit
Router# wr
Configuration saved to /etc/quagga/zebra.conf
Router#

Y una vez hecho esto a la configuración del OSPF, para el ejemplo pongo la más sencilla posible.

root@debian:/etc/quagga# telnet localhost 2604
Trying ::1…
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.

Hello, this is Quagga (version 0.99.23.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification

Password:
ospfd> en
ospfd# conf t
ospfd(config)# router ospf
ospfd(config-router)# network 0.0.0.0/0 area 0
ospfd(config-router)# exit
ospfd(config)# exit
ospfd# wr

Y ahora si vamos a zebra y hacemos un show ip route veremos lo siguiente:

Router# sh ip rou
Codes: K – kernel route, C – connected, S – static, R – RIP,
O – OSPF, I – IS-IS, B – BGP, A – Babel,
> – selected route, * – FIB route

O 0.0.0.0/0 [110/11] via 1.1.1.1, eth1, 00:00:14
K>* 0.0.0.0/0 via 192.168.1.1, eth0
O 1.1.1.0/24 [110/10] is directly connected, eth1, 00:00:15
C>* 1.1.1.0/24 is directly connected, eth1
O>* 31.47.76.123/32 [110/30] via 1.1.1.2, eth1, 00:00:14
C>* 127.0.0.0/8 is directly connected, lo
O>* 127.0.0.1/32 [110/10] is directly connected, lo, 00:00:20
K>* 169.254.0.0/16 is directly connected, eth0
O 192.168.1.0/24 [110/10] is directly connected, eth0, 00:00:20
C>* 192.168.1.0/24 is directly connected, eth0
Router#

Como podéis ver tenemos rutas con la O de OSPF aprendidas por este router. Por supuesto podemos ver los vecinos de OSPF de la misma manera que los veríamos en un router Cisco:

Un ataque de DDoS no consiste en algo más complejo que mandar mucho tráfico hacia un destino más o menos concreto, puede ser una IP o un grupo de las mismas y lo peor es que es relativamente fácil hacerlo, contratarlo mejor dicho.

Existen servicios online, llamados pruebas de estrés, que te permiten contratar una gran avalancha de tráfico para poder probar el comportamiento de tu red ante ese tipo de situaciones, lo que pasa es que nadie te pregunta si el ataque la prueba de estrés que estás contratando es contra tu red o contra la de un tercero.

El ataque puede ser de muchos tipos, pero al final lo más habitual consiste en llenar los tránsitos (conexiones a Internet) de los ISPs de basura y muchos ISPs lamentablemente no saben defenderse ante eso y mueren, al menos durante un rato.

La solución mágica pasa por tener uno o varios equipos que supuestamente sirven para eso y lo que hacen es limpiar el tráfico, pero tienen un pequeño problema, el tránsito ya te lo han llenado con lo que por mucho tráfico que limpien ya no va a quedar hueco para que el tráfico bueno pase. Este tipo de soluciones sirven para aquellos que tienen redes enormes.

Otra opción es que los tránsitos te ofrezcan el servicio de mitigación, lo que pasa es que las soluciones que ofrecen pasan por entregarte el tráfico mitigado a través de un túnel GRE, en fin, prefiero no opinar sobre una solución en la que te entregan el tráfico encapsulado en un túnel GRE. Por supuesto el tráfico mitigado tendrá un coste totalmente inasumible para la mayoría de ISPs.

Y luego está la opción del Blackhole, que es la más simple, barata y efectiva, sólo tiene un pequeño problema, que consiste en que el atacado es sacado de Internet, por decirlo de otra manera se borra la existencia del atacado de Internet entonces ya no le pueden atacar, pero claro, tampoco puede prestar servicio.

El proceso de blackhole consiste en utilizar la propiedad transistiva del atributo opcional community de BGP. De esta manera lo que hacemos es anunciar a nuestros tránsitos un prefijo /32 a la IP atacada con una community que defina esa IP como blackhole y nuestro transito pondrá dentro de su red una ruta a null, o lo que estime, de forma que esa IP no será accesible desde Internet.

Ahora la gracia, desde que empieza el ataque hasta que los tránsitos están llenos el tiempo que tenemos para reaccionar es muy poquito y va desde unos pocos segundos hasta dos o tres minutos, pero normalmente no va más allá, así que hay que ser muy rápido en detectar y aplicar el blackhole.

Podríamos automatizarlo, pero tendríamos que tener muy claro que no estamos incurriendo en un falso positivo, recordemos que el proceso de blackhole tiene el efecto de tirar a nuestro cliente y eso no se puede hacer a la ligera, tenemos que tener muy claro que no estamos incurriendo en falsos positivos.

También podríamos hacerlo de forma manual, pero claro, eso implica que alguien tiene que estar pendiente el tráfico constantemente y como hemos dicho el tiempo de reacción es realmente bajo.

Por supuesto ni que decir tiene que si uno es un ISP pequeñito y no tiene gente siempre dentro de la red si le atacan, como le saturarán los tránsitos, no podrá entrar para poner medidas a no ser que tenga algún sistema un tanto original porque la típica VPN para acceder por nuestra red no sirve, claro, la red está saturada.

Y ahora la segunda parte, has conseguido meter el blackhole y has parado el ataque, pero claro, tienes el cliente tirado, ¿cómo sabes si el ataque ya ha parado?, pues no, no lo sabes, así que con muchísimo cuidado tienes que probar levantar el blackhole y esperar a ver qué pasa, por supuesto teniendo preparado todo para volver a meter el blackhole de nuevo. Por supuesto se puede hacer de forma automática o no.

Por supuesto existen otras soluciones, a veces más imaginativas, a veces abocadas a un fracaso estrepitoso, pero que no sea por falta de ganas.

Lo primero será bajar la imagen para instalar, para ello tenemos dos opciones la primera sería la imagen de x86, que aunque se puede instalar en una máquina virtual no es lo recomendable, y la opción buena que sería la de instalar la imagen de  Cloud Hosted Router. En cuanto a diferencias, además de los drivers, están el licenciamiento, el Cloud Hosted Router tiene la opción de licenciar de por vida, eso sí, limita el ancho de banda efectivo a 1Mbps, pero para hacer pruebas es más que suficiente, siempre y cuando no requieras otras características, en mi caso prefiero usar licencias de 60 días para pruebas sin limitaciones ni de ancho de banda ni de protocolos.

• Imagen: http://www.mikrotik.com/download
• Licencia: https://www.mikrotik.com/client/

Pero antes de nada tenemos que instalarlo, en mi caso voy a instalarlo en un Virtualbox, aunque podemos utilizar cualquier otro software de virtualización.

Empezaremos creando la máquina virtual definida con Linux y Otro Linux 64-bits.

En cuanto a la memoria dependiendo del servicio que vaya a ejecutar, pero para pruebas con 512Mb es más que suficiente, realmente con 64Mb es más que suficiente para la mayoría de servicios que no requieren trabajar con tablas de routing grandes.

El disco duro lo bajaremos de la sección de descargas de la web de mikrotik, en mi caso he seleccionado VDI.

Y quedaría terminar de definir la máquina, en mi caso le he definido 4 redes, una de ellas un adaptador puente y he deshabilitado tanto el USB como el puerto serie.

Y al arrancar ya tendremos nuestra máquina virtual funcionando entrando con usuario admin y sin contraseña.