Archivo

Archivo para la categoría ‘sysadmin’

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:

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, Uncategorized Tags: