Archivo

Archivo para la categoría ‘sysadmin’

CORE Network Emulator

miércoles, 31 de enero de 2018 5 comentarios

Investigando herramientas de simulación/emulación de redes con fines educativos, un amigo pasó esta página, bastante nutrida por cierto, con un listado de simuladores/emuladores de red, recomendando probar CORE.

C.O.R.E., acrónimo de Common Open Research Environment, fue un proyecto inicialmente de Boeing (sí, la de los aviones) y que ahora es sponsoreado por el Laboratorio de Investigación Naval de los Estados Unidos. Le dediqué un rato a revisar qué tal funcionaba, y aquí está lo que pude probar.

A priori, resulta que la última versión (4.8) está en los repos de Ubuntu 16.04, por lo que fue fácil la instalación [1]:

marcelo@marcelo-notebook:~$ apt-cache search core-network
 core-network - intuitive network emulator that interacts with real nets (metapackage)
 core-network-daemon - intuitive network emulator that interacts with real nets (daemon)
 core-network-gui - intuitive network emulator that interacts with real nets (GUI)

Se instalan esos paquetes y listo el pollo, las dependencias son básicas (TCL/TK y quagga):

marcelo@marcelo-notebook:~$ sudo apt install core-network core-network-gui
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias 
Leyendo la información de estado... Hecho
Se instalarán los siguientes paquetes adicionales:
 core-network-daemon libev4 libtcl8.5 libtk-img libtk8.5 quagga tcl8.5 tk8.5
Paquetes sugeridos:
 libtk-img-doc snmpd tcl-tclreadline
Se instalarán los siguientes paquetes NUEVOS:
 core-network core-network-daemon core-network-gui libev4 libtcl8.5 libtk-img libtk8.5 quagga tcl8.5 tk8.5
0 actualizados, 10 nuevos se instalarán, 0 para eliminar y 2 no actualizados.
Se necesita descargar 3.905 kB de archivos.
Se utilizarán 16,4 MB de espacio de disco adicional después de esta operación.
¿Desea continuar? [S/n]

Usarlo es tanto como ejecutar «core-gui» y empezar a armar el mapa de la red tal como se ve en el video de la página que citó Mauro:

Vista de Red - CORE

Vista de Red – CORE

El direccionamiento lo hace automáticamente (aunque es configurable, haciéndole doble click a cada nodo):

… y la configuración del ruteo se hace sola (ver más abajo cómo), por lo que luego de armar esa red sencilla, ambos hosts («PC» y «Server») se ven automáticamente.

Luego de armar la red, se le da al botón de «Play» y se ejecuta todo. Todos los nodos son Linux (nada de emulación routers Cisco ni nada como sucede con GNS3), y acá viene lo interesante:

  • Todos son containers (LXC) del mismo host de uno, pero sin estar en un chroot (?!?),
  • Es extremadamente rápido gracias a LXC, pero «raro» ya que todo corre en el mismo filesystem de la máquina de uno (puedo ir a mi home directamente desde cada nodo).
  • Dado que es un container, todos los kernels guest son los mismos del host.
  • ¡El software que se ejecuta es el mismo del host! Es decir, si digo que este nodo va a tener Apache (servicio «HTTP»), hay que instalar el paquete apache2 en el host, no en el guest. No hay imagen de máquina virtual ni nada por el estilo como pasa con otros emuladores.
  • El directorio que te abre al entrar a cada guest es/tmp/pycore.<PID>/<nombredelhost>.conf/
  • La configuración de los servicios/apps que va a usar en cada host la genera el entorno antes de darle «Play» en /tmp/pycore.<PID>/<nombredelhost>.conf/, por ejemplo:

Uno puede ir y editar los archivos en el directorio etc.apache2/ que generó el sistema una vez que se le dio ejecución, o puede hacerlo antes, tocando en el botón «Services» de la configuración del host:

Y luego en el ícono de llave inglesa:
Este es un ps desde el guest Server:

root@Server:/tmp/pycore.34211/Server.conf# ps faxu
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 9676 1708 ? S 12:20 0:00 /usr/sbin/vnoded -v -c /tmp/pycore.34211/Server -l /tmp/pycore.34211/Server.log -p /tmp/pycore.34211/Server.pid -C /tmp/pycore.34211/Server.conf
root 46 0.0 0.0 65508 3096 ? Ss 12:20 0:00 /usr/sbin/sshd -f /etc/ssh/sshd_config
root 52 0.0 0.0 56680 3772 ? Ss 12:20 0:00 /usr/sbin/apache2 -k start
www-data 53 0.0 0.0 411412 3504 ? Sl 12:20 0:00 \_ /usr/sbin/apache2 -k start
www-data 54 0.0 0.0 411412 3504 ? Sl 12:20 0:00 \_ /usr/sbin/apache2 -k start
root 110 0.0 0.0 23848 3968 pts/19 Ss 12:20 0:00 /bin/bash
root 236 0.0 0.0 39932 3316 pts/19 R+ 12:22 0:00 \_ ps faxu
root@Server:/tmp/pycore.34211/Server.conf#

Este es el running-config generado por core-network de un router (r1), entrando a Quagga con vtysh:Así que ahí vemos que define OSPF automáticamente:

Respecto a si se pueden guardar/cargar laboratorios completos, sí se puede, en el formato «imn» (ya que CORE es un fork de Imunes, y heredó su formato). Algo muy interesante es que se puede configurar el QoS de cada link, haciéndole doble click a cada línea (no lo probé):

Y que te grafica el ancho de banda en tiempo real de la red:

Por último, para hacer capturas de tráfico es bastante sencillo, probé dos opciones:

  1. Se corre en cada nodo que se desea un tcpdump guardando el tráfico, queda en el «home» de cada container guest (/tmp/pycore.<PID>/<nombredelhost>.conf/), y uno desde el host directamente ejecuta Wireshark y lo abre.
  2. Pude guardar todo el tráfico de la red en una única captura (esto, con netkit, no lo pudimos hacer de forma directa). Para ello, primero se arranca el entorno de simulación; esto hace que se creen dinámicamente los bridges a nivel de host y las interfaces virtuales de cada container, adjuntas a cada bridge (el virbr0 de la captura es de Virtualbox, ignórenlo):

Y bueno, para hacer la captura de toda la red al mismo tiempo, hay que decirle a Wireshark que capture en todos los bridges:

Filtré porque aparece tráfico OSPF todo el tiempo, lógicamente. Es cuestión de desactivarlo por defecto (configurando el servicio Quagga/Zebra). Un detalle de capturar así es que hay que ordenar por tiempo, porque el packet number queda desordenado. Pero ordenando por tiempo, lo seguí y aparentemente (hice un ping, nada más) el orden se mantiene (el «reloj» sería el host).

El manual está acá, parece que se pueden hacer muchísimas cosas más (entornos distribuidos, scripting automatizado en Python, etc.):
https://downloads.pf.itd.nrl.navy.mil/docs/core/core-html/index.html

Parece ser una muy buena herramienta para simular entornos de red, practicar y aprender sobre protocolos.

[1] Resulta que hace poco lo sacaron de Debian/Ubuntu, porque claro, el entorno gráfico se ejecuta como usuario normal, pero al abrir la consola de cualquier nodo que uno creó entra a la VM como root (y recuerden que no se está dentro de un chroot, con lo cual es root en el host con acceso al filesystem):

https://github.com/coreemu/core/issues/117

No lo solucionaron, entonces Debian los sacó, por ende no está en Debian Stretch. Igual maintainer del paquete tiene un repositorio personal para Debian/Ubuntu:

http://eriberto.pro.br/core/

Saludos

Categories: codear, linux, sysadmin, ubuntu-ar Tags:

Nuevo Documento: «HTTP/2. Un nuevo protocolo para la web» (v1.0)

sábado, 6 de mayo de 2017 Sin comentarios

Les comparto el documento que armé dentro del marco del grupo de Teleinformática y Redes de la Universidad Nacional de Luján sobre el protocolo HTTP/2, a modo de recopilación, traducción y simplificación de todo lo que anda dando vueltas en la web. La idea es ir actualizándolo y completándolo a medida que pase el tiempo.

Dejo el link para bajarlo en PDF.

Se aceptan sugerencias, comentarios y críticas, por qué no. 🙂

Saludos

Categories: codear, linux, sysadmin, web Tags:

Habilitando HTTP/2 en Apache sobre Ubuntu 16.04 sin PPAs

martes, 14 de marzo de 2017 Sin comentarios

Una de las cosas que me sorprendió de la versión de Apache 2.4.18 incluida en Ubuntu 16.04 (y también en Ubuntu 16.10) es que el módulo mod_http2 no está habilitado por ser considerado «experimental» por el proyecto Apache.

Discusiones de si debe estar o no al margen, esta característica funciona mayormente bien y no tiene fallas importantes. En mi caso evalué un par de alternativas:

  • Compilar un server nuevo desde los fuentes es poco práctico, ya que la integración de Apache lograda por el empaquetado de Debian/Ubuntu es mala o dificultosa como mínimo, además de tener que compilar por futuras actualizaciones de seguridad.
  • Confiar en un repositorio PPA ajeno (como indican otros posts) también es un problema, más aún bajo ciertos entornos.

Es por esto que, buscando una alternativa diferente, encontré una manera relativamente fácil, rápida y «con actualizaciones» de habilitar el módulo HTTP/2 sobre el mismo Apache 2.4.18 que trae Ubuntu 16.04/16.10.

Dado que el módulo http2 se incluye en los fuentes, es posible compilarlo y copiarlo nuevamente a la instalación de Apache creada por el paquete Ubuntu. Como requisito, hay que tener los repositorios deb-src habilitados en el archivo /etc/apt/sources.list.

Luego se debe instalar libnghttp2-dev, descargar el paquete fuente de apache2 y compilarlo sin hacer ningún cambio. Los comandos para hacer esto son, como usuario con permisos de sudo sobre el sistema:

$ sudo apt-get install libnghttp2-dev
$ mkdir apache2
$ cd apache2
$ apt-get source apache2
$ sudo apt-get build-dep apache2
$ cd apache-2.4.18
$ fakeroot debian/rules binary

Después, copiar el módulo compilado (mod_http2.so) al directorio de módulos del apache, crear un archivo .load en /etc/apache2/mods-available y ejecutar a2enmod http2 para que Apache lo cargue. Luego, se reinicia el servicio y listo.

$ sudo cp debian/apache2-bin/usr/lib/apache2/modules/mod_http2.so /usr/lib/apache2/modules/
$ cat << EOF > /tmp/http2.load
LoadModule http2_module /usr/lib/apache2/modules/mod_http2.so
<IfModule http2_module>
  LogLevel http2:info
</IfModule>
EOF
$ sudo cp /tmp/http2.load /etc/apache2/mods-available/http2.load
$ sudo a2enmod http2
$ sudo service apache2 restart

Y listo. Luego resta configurar algunas de las opciones del módulo e incorporarlo en los VirtualHosts que necesitemos, indicando «Protocols h2 http/1.1».

Para más info de cómo instalarlo, leer acá.

Saludos

Categories: codear, linux, sysadmin, web Tags:

Fedora Day Buenos Aires 2014

miércoles, 10 de diciembre de 2014 Sin comentarios

La comunidad Fedora Argentina se complace en anunciar el evento más importante de Fedora en el país hasta el momento:

¡El Sábado 13 de Diciembre los esperamos en la UTN de Medrano 951, CABA, para celebrar el Fedora Day!

Será un día con charlas de varios ponentes de Argentina y Latinoamérica, donde se hablará del futuro de la distribución y de varias tecnologías como Ovirt, Docker, Openshift, etc. También estaremos celebrando el Release Party de la nueva versión de Fedora, Fedora 21, ¡con la posibilidad de instalarlo en sus computadoras o en un pendrive para llevarlo!

Si desean participar en el evento no duden en registrarse de forma gratuita en el siguiente link [1].

También iremos actualizando la información del Fedora Day en la página oficial [2] y en la wiki de Fedora [3].

Si estás interesado en dar una charla sobre «inserte tema aquí» relacionado con Fedora no dudes en registrarte en nuestra lista de correos [4] y enviarnos tu propuesta.

En Fedora es muy importante para nosotros la comunidad y es por eso que estamos buscando nuevos colaboradores. Si estás interesado, no te pierdas nuestras charlas al respecto o acercate a cualquier colaborador el día del evento.

Ante cualquier duda o consulta por favor contactate con Matías <delete@fedoraproject.org> o con Rino <villadalmine@fedoraproject.org>

¡¡¡Los esperamos!!!

Saludos,
Fedora Argentina

1. http://goo.gl/zYsClS
2. http://fedoraday.com
3. https://fedoraproject.org/wiki/Fedora_Day_Buenos_Aires_2014
4. https://lists.fedoraproject.org/mailman/listinfo/argentina

Categories: codear, linux, sysadmin Tags:

Comparando costos de Amazon EC2 y Google Computing Engine

miércoles, 17 de septiembre de 2014 Sin comentarios

Estuve mirando y por suerte son prácticamente similares las tablas disponibles en cada site (EC2 / GCE) y es relativamente sencillo compararlas [1][2].

Para sus Data Centers en USA, establecí las siguientes relaciones:

  • En las versiones de VMs «standard«, los precios son exactamente iguales, con configuraciones llamativamente similares.
  • En las versiones «high memory«, es más barato Google (la mitad), aunque Amazon te da el doble de CPUs por una VM con la misma cantidad de memoria.
    Ej: Google te da 4 CPUs / 26 GB de RAM y Amazon en cambio te da 8 CPUs para su configuración de 26 GB de RAM. Dado que estamos en «high memory«, igualé a cantidad de memoria disponible para luego decir «Google es la mitad de barato».
  • En las versiones «large» («high cpu» de Google), Amazon es un 15% más caro para igual cantidad de CPUs, pero te da el doble de memoria en sus VMs.

Observaciones:

  • Se desprende de lo anterior Amazon EC2 ofrece perfiles más simétricos que Google comparando la relación de cantidades de CPU/Memoria. Puede ser útil para algunas aplicaciones o no, ya que va obviamente asociado al costo.
  • Amazon tiene configuraciones con más CPUs ya que llega a 32 CPUs y más memoria también: 244 GB; Google llega a 16 CPUs y 104 GB de memoria.
  • No comparé tamaños de almacenamiento, asumo que no tiene tanta relevancia para nuestra aplicación (se disponen de varias decenas de GB en disco en ambos).
  • Amazon dice que te incluye discos de estado sólido (SSD). Google te cobra ambos (?) 0,04 USD por GB/mes el disco estándar, 0,325 USD GB/mes el SSD.
  • Fundamental para la región en la que vivo: Amazon tiene Data Center en San Pablo (Brasil), Google no; sólo sirve VMs desde USA, Europa y Asia/Pacífico.
  • Amazon tiene diferentes tipo de instancias, en este caso comparé las «Bajo demanda» aka «Dedicadas» (según el lugar que se mire en la documentación), que son las más caras. Las otras son tipo prepagas («Instancias Reservadas»), donde según entiendo, uno abona un importe fijo y después usa X cantidad de tiempo y se descuenta del fijo.
    Hay otros tipos de instancias pero no se ajustan a nuestro uso («Instancias Puntuales» y «Instancias optimizadas para EBS»). En este apartado, pareciera que Amazon tiene largamente muchas más ofertas y más desarrollo del negocio que Google.

Bonus Track: versus Linode.com

  • Linode tiene hasta 20 CPUs / 96 GB RAM máximo [3].
  • Linode es mucho más barato que ambos; es más simple su tabla de precios y más «1 a 1» la distribución de CPUs / RAM (4GB / 4CPUs, 8 GB / 6 CPUs, y así hacia arriba), además de que da bastante más storage en SSD.
    Por ejemplo, 4 GB / 4 CPUs en Linode: USD 0,06/hora (USD 40/mes), mientras que en Amazon estamos en USD 0,28/hora por 15GB / 4 CPUs o USD 0,105/hora por 3,75GB / 2 CPUs. Eso sí, Linode está en USA (Newark/Atlanta/Dallas/Fremont), Europa (Londres) y Asia (Tokio), no en Sudamérica.
  • Comparando Linode contra GCE:
    • 1 Linode (2 GB de RAM/ 2 CPUs / 3 TB transfer / 48 GB SSD): U$S 20/mes.
    • 1 GCE (1,70 GB RAM / CPUs «shared» (?) / 48 GB SSD): U$S 33.29/mes (no dicen si hay límite de transferencia).
  • A Linode lo conocemos los que estamos «en la pomada», y hay casos en donde suena mucho mejor «lo tengo repartido en la nube de Amazon/Google», nobleza obliga.

[1] http://aws.amazon.com/es/ec2/purchasing-options/dedicated-instances/
[2] https://cloud.google.com/products/compute-engine/
[3] https://www.linode.com/pricing

¿Sugerencias, comentarios?

Saludos

Categories: codear, linux, sysadmin, web Tags: