Archivo

Archivo para la categoría ‘codear’

Charlas: Introducción a AWS y a HTTP/2

martes, 13 de septiembre de 2016 Sin comentarios

Hace unos días tuve el placer de dar una charla en el CIDETIC, perteneciente a la Universidad Nacional de Luján, respecto a los servicios de cloud computing en general y a los de Amazon Web Services en particular.

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

Categories: codear, linux, ubuntu-ar 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:

Pwning hardware

sábado, 1 de noviembre de 2014 1 comentario

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

Categories: codear, linux, personal, programación, python 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:

Migrando Host de VMs KVM de Ubuntu 12.04 a 14.04

viernes, 16 de mayo de 2014 5 comentarios

En estos días arranqué la tarea de migrar Máquinas Virtuales de Hosts Ubuntu 12.04 (entorno QEmu-KVM/Libvirt) a Ubuntu 14.04, para testear que esté funcionando todo ok, y me encontré con dos particularidades:

1) Por defecto, las interfaces de red no se llaman más «ethX» ni se guían como antes con el archivo en /etc/udev/rules.d/70-net-persistent.rules, sino que ahora son medio raras («p2p1», «p5p4», «eno1», «enp2s0», etc). Acá está explicado el por qué del cambio [1]. A priori no me gusta nada este cambio, por no respetar ninguna convención como sí lo hacía ethX, y encima por ser un cambio por defecto, pero como todo… supongo que me acostumbraré. Es adaptarse o morir; no es un capricho de Ubuntu, sino de udev.

2) ¡No hace falta más configurar un bridge en el host! Ahora se usa el driver de kernel macvtap [2][3][4][5], que uno lo selecciona en el administrador virt-manager. Así que para el host no habría que cambiar la configuración; para recordarlo, en un host Ubuntu 12.04 pasábamos de esto:

auto eth0
 iface eth0 inet static
 address 192.168.1.18
 netmask 255.255.255.0
 gateway 192.168.1.1
 dns-nameservers 192.168.1.1 192.168.1.2

a esto (cambia eth0 por br0, y las líneas de bridge):

auto br0
 iface br0 inet static
 address 192.168.1.18
 netmask 255.255.255.0
 gateway 192.168.1.1
 dns-nameservers 192.168.1.10 192.168.1.15
 bridge_ports eth0
 bridge_stp off
 bridge_fd 0
 bridge_maxwait 0

Ahora en Ubuntu 14.04 no hace falta tocar nada, ya que la interfaz principal sigue siendo la misma, aún cuando haya VMs que salgan directamente puenteadas por dicha interfaz. Lo que sí, por cada VM puenteada con el driver macvtap se va a crear una interfaz en el host, quedando así, digamos:

macvtap0 Link encap:Ethernet HWaddr 52:54:00:1e:b5:29
 inet6 addr: fe80::5054:ff:fe1e:b529/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 RX packets:437 errors:0 dropped:0 overruns:0 frame:0
 TX packets:71 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:500
 RX bytes:36313 (36.3 KB) TX bytes:6617 (6.6 KB)

 p2p1 Link encap:Ethernet HWaddr 44:87:fc:ef:96:be
 inet addr:192.168.1.18 Bcast:192.168.1.255 Mask:255.255.255.0
 inet6 addr: fe80::4687:fcff:feef:96be/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 RX packets:15346 errors:0 dropped:46 overruns:0 frame:0
 TX packets:16615 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:2096838 (2.0 MB) TX bytes:4714920 (4.7 MB)

Esto seguramente es más rápido que lo anterior, por diferentes motivos, pero tiene un lado feo, y es que de esta manera los guests no pueden comunicarse con el host [6]. Apliqué la «less painful solution» de esa wiki, y fue crear una red NAT aislada entre el host y sus guests, todo de manera gráfica desde virt-manager. Fue bastante simple, y aunque no me guste que tenga que haber una interfaz en el guest únicamente para comunicarse con el host, funciona bien y en mi caso esto es para necesidades muy puntuales (emergencia casi siempre).

En resumen, esto fue para darles un pantallazo de algunos de los cambios que vamos a tener que hacer cuando migremos a 14.04. Estos cambios también están en RHEL 7, ya que son todos cambios de proyectos upstream, así que no nos ahorramos este trabajo yendo para aquel lado tampoco.

[1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
[2] http://seravo.fi/2012/virtualized-bridged-networking-with-macvtap
[3] http://virt.kernelnewbies.org/MacVTap
[4] http://libvirt.org/formatnetwork.html#examplesDirect
[5] http://www.linux-kvm.com/content/simple-bridged-networking-virt-manager-using-macvtap
[6] http://www.furorteutonicus.eu/2013/08/04/enabling-host-guest-networking-with-kvm-macvlan-and-macvtap/

Saludos!

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