Ambos son Internet Standard desde hace muy poco tiempo (quic, http/3) y vienen y/o dependen de un paquete de otros protocolos y especificaciones que no son poca cosa.

Aún así, mi idea es describir sus conceptos fundamentales en español, como para que lo entienda un estudiante de una asignatura de redes de una Universidad cualquiera; analizar sus pros y cons, y por último dejar algo de código de ejemplo como para poder entender desde el punto de vista de un programador dónde tiene lugar para hacer un aporte y dónde no.

Por algún motivo en la migración a HTTPS del blog (ocurrida hace bastante tiempo), los links a los diferentes recursos estaban rotos. Bueno, ya los arreglé.

Saludos

Agenda:

• Clase 1: Introducción Sockets API. Modelo OSI, entornos de ejecución.Introducción a Python. Socket API para UDP. Ejercicios.
  • Descargar en Formato ODP / Formato PDF.
  • Código de ejemplo: ZIP.
• Clase 2: Socket API para TCP. Código de ejemplo y ejercicios.
  • Descargar en Formato ODP / Formato PDF.
• Clase 3: Multiprogramación, concurrencia, paralelismo. Syscall fork() y relacionados. Ejemplos de servidor multiproceso. Procesos vs. Threads.
  • Descargar en Formato ODP / Formato PDF.
  • Código de ejemplo: ZIP.
• Clase 4: Sockets asincrónicos. Modelo de trabajo, syscall select(). Ejemplos de código. Introducción a Scapy.
  • Descargar en Formato ODP / Formato PDF.
  • Código de ejemplo: ZIP.

¡Saludos!

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:

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

Dejo el link para bajarlo en PDF.

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

Saludos

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

  LogLevel http2:info

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

Como siempre, preparar y hablar en público sobre un tema no es lo mismo que tener los conceptos algo desordenados, producto únicamente de la experiencia práctica; por lo que fue un desafío organizar tantas ideas algo deshilachadas… y acepté gustoso. De hecho, tengo un par de críticas que hacerme a mí mismo sobre cómo salió, como que por ejemplo, me quedaron cosas en el tintero y me llevó más tiempo de lo planificado.

De paso, subí también los slides que armé para la charla de HTTP/2, que vengo reeditando prácticamente todos los años en la cátedra de Teleinformática y Redes. Esta vez pude ir con el protocolo estandarizado para mostrarle a la gente.

En fin, los slides, para aquellos que les interesa, los dejé en la sección Charlas del blog. Pueden usarlo sin problemas para lo que deseen.

PD: Si buscan los íconos de los servicios de AWS como recursos para uso personal en la generación de contenido, acá están en múltiples formatos (SVG/EPS, Visio, Powerpoint, etc.).

Saludos

¡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

El video dura media hora, pero a mí me gustó muchísimo, aprendí mucho. Mikah Scott es una genia, y se propone investigar cómo customizar el firmware de una lectora/grabadora de CD/DVD/Blu-Ray, para dominarlo por completo, empezando por el microcontrolador ARM que posee. Por ejemplo, moviendo el láser en la posición que uno quiera y dispararlo. Habla un excelente y puntilloso inglés, así que se le entiende palabra por palabra, sugiero que lo vean incluso para practicar su inglés técnico.

Es muy interesante cómo usa Photoshop para visualizar el contenido de un firmware (?!??!?! ¡nunca se me hubiera ocurrido!), y cómo usa IDA (este sí es más lógico) para interpretar el código binario.

Además, usa vusb-analyzer en Ubuntu para visualizar el tráfico USB dumpeado con usbmon o similares, por ejemplo snifeado de una máquina virtual.

Por último, usa iPython para hacer que el ARM y el resto de los chips con los que interactúa (mt1939, dsp) haga lo que uno quiera (todavía está en avance).

Es increíble cómo en el ámbito de seguridad se usa Python (lo confirmé en la Ekoparty en estos días).

Insisto, se aprende muchísimo viendo este tipo de videos: herramientas, técnicas, trucos y fundamentalmente cómo abordar estos desafíos.

Saludos

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