Sunday, March 6, 2022

Configuración de iscsi + multipath en Centos 6.3

En este post voy a explicar como configuré iscsi + multipath en CentOS 6.3. El entorno puede que no sea aplicable 100% en la vida real pero puede servir para hacer prácticas tanto de iscsi como de multipath.

Para esto utilicé 3 máquinas virtuales de 512 MB de RAM cada una. A continuación coloco un esquema de red del laboratorio que construí:







La red de gestión es opcional, sin embargo es muy útil a la hora de instalar paquetes ya que los servidores tendrán acceso directo a los repositorios de CentOS. Esta red de gestión (si se usa) debe tener acceso al default gateway.

El motivo de colocar dos redes de storage separadas, es evitar conflictos con los paquetes arp de las tarjetas ethernet conectadas a una misma red.

Como dije al principio, esta estructura puede que no sea aplicable en la vida real ya que haciendo bonding con eth1 y eth2 tendríamos una sola red IP.

Características de los servidores
Servidor iscsi (Target) y cliente iscsi (Initiatior)
Distribución: Centos 6.3
NIC's: 3
RAM: 512 MB

Características de red
Este entorno fue montado con 2 máquinas virtuales, las tarjetas conectadas a la red 192.168.122.0/24 están en modo NAT con dhcp (pueden tener diracciones estáticas).

Las tarjetas de red conectadas a las redes 192.168.144.0/24 y 192.168.42.0/24 están en modo "host-only" con lo que no tienen comunicación con el exterior.

No es objetivo de este post explicar cómo se configura el entorno a nivel de máquinas virtuales.

Configuración del servidor iscsi (Target)

El target es el "servidor de storage", será el que proporcionará los LUN's a los clientes, sería como la cabina de discos.

Para configurar el target hay que instalar el paquete scsi-target-utils
yum install scsi-target-utils

Creamos el directorio /etc/tgt/temp para colocar ahí el archivo de configuración para las pruebas.

Editamos el archivo /etc/tgt/targets.conf y colocamos la siguiente línea

include /etc/tgt/temp/*.conf

Eso servirá para incluir cualquier archivo con extensión .conf que esté en
/etc/tgt/temp/

La línea
default-driver iscsi

debería estar descomentada también.

De ahora en adelante, todas las modificaciones las haremos en
/etc/tgt/temp/prueba.conf.

Nombre del target

La sintaxis del nombre está descrita en el rfc3721, este es un extracto:
 
Constructing iSCSI names using the iqn. format

   The iSCSI naming scheme was constructed to give an organizational
   naming authority the flexibility to further subdivide the
   responsibility for name creation to subordinate naming authorities.
   The iSCSI qualified name format is defined in [RFC3720] and contains
   (in order):

   -  The string "iqn."

   -  A date code specifying the year and month in which the
      organization registered the domain or sub-domain name used as the
      naming authority string.

   -  The organizational naming authority string, which consists of a
      valid, reversed domain or subdomain name.

   -  Optionally, a ':', followed by a string of the assigning
      organization's choosing, which must make each assigned iSCSI name
      unique.


Para nuestro primer ejemplo, utilizaremos el nombre
iqn.2012-08.local.centos:pool01

Creación del LUN

Para poder "servir" un LUN es necesario crearlo a nivel de sistema operativo. Para este ejemplo utilizaremos lvoles que serán utilizados por los clientes como LUN's.

Asumiendo que se dispone de un disco (/dev/sdb) de 1 GB, creamos el vg vg_iscsi.
pvcreate /dev/sdb
vgcreate vg_iscsi  /dev/sdb
lvcreate -m  lv_lun01 -l 500M vg_iscsi

El dispositivo que se servirá como LUN a los clientes es
/dev/vg_iscsi/lv_lun01

Editamos el archivo de configuración /etc/tgt/temp/prueba.conf y colocamos las siguientes líneas
<target iqn.2012-08.local.centos:pool01>
  backing-store /dev/vg_iscsi/lv_lun01
</target>

Nos aseguramos que el demonio tgtd se arranque con el sistema operativo
chkconfig tgtd on

y arrancamos el servicio
/etc/init.d/tgtd start


Para verificar que se estén sirviendo el LUN que configuramos, utilizamos el siguiente comando:
tgt-admin -s

 Target 1: iqn.2012-08.local.centos:pool01
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: null
            Backing store path: None
            Backing store flags:
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 524 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: rdwr
            Backing store path: /dev/vg_iscsi/lv_lun01
            Backing store flags:
    Account information:
    ACL information:
        ALL


Tenemos un LUN disponible para cualquier cliente.

Control de acceso

El control de acceso se hace por target, es decir, dentro de una directiva se colocan las IP's de las interfaces de red de los clientes a los que se quiere permitir el acceso a los LUN's publicados bajo dicho target.

También se puede controlar el acceso mediante usuario/password. Para más información, man targets.conf.

Para el ejemplo de este post, usaremos un solo LUN.

Para administrar todo lo relacionado con el servicio tgtd (añadir LUN's, eliminar LUN's, añadir, modificar, eliminar targets, etc), se utiliza el comando tgtadm.

Ninguna operación realizada con tgtadm es persistente y solo queda en memoria. Para actualizar el archivo de configuración hay que ejecutar
tgt-admin --dump > /etc/tgt/temp/prueba.conf

Es importante tomar en cuenta la advertencia que viene en el manual de tgt-admin con respecto a la opción --dump:

 Note: does not include detailed parameters, like write caching

Avisados están.

Ya tenemos el servidor configurado, faltan los clientes.


Configuración del cliente (initiator)

El cliente es cualquier máquina que vaya a hacer uso de algún LUN del servidor iSCSI, por lo tanto, cualquier máquina que vaya a necesitar discos de la SAN, es un cliente.

Para configurar el cliente debemos comenzar por instalar el paquete iscsi-initiator-utils
yum install iscsi-initiator-utils

 A continuación, editamos el archivo /etc/iscsi/initiatorname.iscsi y colocamos el nombre del initiator, puede ser el FQDN del host. En este ejemplo utilizaremos "cliente" como initiator name.
InitiatorName=cliente

Nos aseguramos que los servicios iscsi y iscsid arranquen en cada inicio del sistema operativo
chkconfig iscsi on
chkconfig iscsid on

Configuramos las interfaces de red que van a formar parte de la red iSCSI, en nuestro caso eth1 y eth2 (eth0 es para comunicarse con el "exterior").
iscsiadm -m iface -I eth1 -o new
iscsiadm -m iface -I eth1 -o update -n iface.hwaddress -v MAC

iscsiadm -m iface -I eth2 -o new
iscsiadm -m iface -I eth2 -o update -n iface.hwaddress -v MAC

donde:
-I es el nombre el la interfaz ethernet.
-n iface.hwaddress es el nombre del atributo.
-V MAC es para especificar la MAC address de la tarjeta ethernet.

En la primera línea creamos la interfaz y en la segunda le colocamos la MAC address al atributo iface.hwaddress.


Podemos revisar los contenidos de los archivos de configuración para cada interfaz haciendo
cat /var/lib/iscsi/ifaces/eth1
# BEGIN RECORD 2.0-872.41.el6
iface.iscsi_ifacename = eth1
iface.hwaddress = 00:50:56:37:B7:45
iface.transport_name = tcp
iface.vlan_id = 0
iface.vlan_priority = 0
iface.iface_num = 0
iface.mtu = 0
iface.port = 0
# END RECORD

Descubrimos los targets disponibles por cada interfaz
# iscsiadm -m discovery -t sendtargets -p 192.168.144.1 -I eth1
192.168.144.1:3260,1 iqn.2012-08.local.centos:pool01


# iscsiadm -m discovery -t sendtargets -p 192.168.42.1 -I eth2
192.168.42.1:3260,1 iqn.2012-08.local.centos:pool01


Ahora tenemos que hacer login en el target iqn.2012-08.local.centos:pool01 con cada una de las tarjetas
# iscsiadm -m node -l
Logging in to [iface: eth2, target: iqn.2012-08.local.centos:pool01, portal: 192.168.42.1,3260] (multiple)
Logging in to [iface: eth1, target: iqn.2012-08.local.centos:pool01, portal: 192.168.144.1,3260] (multiple)
Login to [iface: eth2, target: iqn.2012-08.local.centos:pool01, portal: 192.168.42.1,3260] successful.
Login to [iface: eth1, target: iqn.2012-08.local.centos:pool01, portal: 192.168.144.1,3260] successful.


Con esto ya deberíamos ver dos "discos", sdb y sdc.
# lsscsi
[1:0:0:0]    cd/dvd  NECVMWar VMware IDE CDR10 1.00  /dev/sr0
[2:0:0:0]    disk    VMware,  VMware Virtual S 1.0   /dev/sda
[11:0:0:0]   storage IET      Controller       0001  -
[11:0:0:1]   disk    IET      VIRTUAL-DISK     0001  /dev/sdb
[12:0:0:0]   storage IET      Controller       0001  -
[12:0:0:1]   disk    IET      VIRTUAL-DISK     0001  /dev/sdc


Ya tenemos el cliente configurado, esta información no se perderá durante el reboot. Podemos probar reiniciando el cliente y luego de que arranque, volvemos a ejecutar lsscsi y deberíamos obtener el mismo resultado.

Nos queda configurar el multiptah.


Configuración de multipath

Primero instalamos el multipath
 yum install device-mapper-multipath

Esto instalará dos paquetes, el device-mapper-multipath y el device-mapper-multipath-libs.

 El paquete de multipath no trae archivo de configuración, debemos copiar uno de /usr/share/doc/device-mapper-multipath-$VERSION/.

Para este caso, voy a copiar el multipath.conf.synthetic a /etc/multipath con el nombre multipath.conf.

Editamos el archivo /etc/multipath/multipath.conf y descomentamos toda la sección defaults y blacklist.

Creamos un enlace simbólico en /etc que apunte a
/etc/multipath/multipath.conf
 ln -s /etc/multipath/multipath.conf /etc/multipath.conf

Nos aseguramos que el multipathd arranque al inicio con el comando
 chkconfig multipathd on

Arrancamos el demonio de multipath
/etc/init.d/multipathd start

Ejecutamos el comando multipath -ll y deberíamos obtener una salida parecida a esta:
[root@cliente ~]# multipath -ll
1IET     00010001 dm-5 IET,VIRTUAL-DISK
size=500M features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
  |- 3:0:0:1 sdb 8:16 active ready running
  `- 4:0:0:1 sdc 8:32 active ready running


Indicando que el dispositivo "1IET     00010001" contiene a los dos path's sdb y sdc.

Esta es la configuración básica de multipath.

Hasta aquí este post, para más información, consultar el manual de multipath, tgt-admin y tgtadm



Saturday, June 18, 2016

Volando con la tablet (Nexus 7 2013)

Cuando haces el curso para obtener el PPL, te enseñan a navegar utilizando el mapa, la brújula y un cronómetro. En mi humilde opinión, es la mejor forma de aprender a navegar, aparte de que, si todo lo demás falla, siempre tendrás el mapa, la brújula y el reloj.

Lo que también es cierto es que cuando eres un dominguero y vuelas cuando puedes y no cuando quieres, el espacio de tiempo entre vuelo y vuelo se va alargando más de lo que uno quisiera. Una de las consecuencias de esto es que tus habilidades comienzan a mermar y para navegar "distancias aceptables" o ir a sitios nuevos, es mejor que tus habilidades de navegación no estén tan mermadas. Lamentablemente, para evitar eso, lo que hay que hacer es volar y volar cuesta y al menos en mi caso, el dinero no está en la listas de las cosas que me sobran.

¿Cómo puede hacer un dominguero para volar a sitios nuevos con relativa seguridad y que no le cueste un ojo (o dos) de la cara? La respuesta podría ser, ayudarse con un GPS.

Hay aviones que ya vienen con su propio GPS que está certificado por la autoridad competente y que son muy fiables, pero en mi caso, los aviones que acostumbro a volar, no tienen GPS incorporado.

Los GPS's portátiles de aviación son (como todo accesorio para este hobbie) costosos, por lo tanto, adquirir uno puede ser una gran inversión de dinero y en mi caso, prefiero utilizar ese dinero para pagar las horas de vuelo.

Afortunadamente, existen dispositivos móviles (teléfonos y tablets) que tienen un GPS que es "lo suficientemente bueno" para las cosas que hacemos los PPL's normalmente (velocidades de crucero cercanas a los 100 KTS, altitudes menores a 10000 ft, etc).

Estos GPS no están certificados por ninguna autoridad de aviación (al menos no por AESA que es la que me toca a mi), pero pueden servir como ayuda a la navegación, mitigando un poco la merma de capacidades producida por "volar poco".

Para más fortuna, debido al precio de estos aparatos, es posible contar con varios GPS's (teléfono + tablet por ejemplo), así que se tiene algo de redundancia en caso de que uno falle.

Pero no todo lo que brilla es oro y al menos en mi opinión, hay que tomarse con mucho cuidado esto de confiarse única y exclusivamente en un GPS no certificado para aviación y dejar de lado una buena planificación de vuelo y la navegación con un mapa.

No es un secreto que la meca de la aviación es USA y en mi caso, soy muy aficionado a ver videos en youtube de personas que vuelan allá, videos de la FAA, NTSB, de AOPA, etc. Es para mi como ver el futuro ya que ellos siempre están a la vanguardia en lo que a aviación se refiere.

Justamente, mirando videos de la FAA, NTSB, de AOPA y leyendo revistas, folletos etc., he visto que en USA ya han tomado en cuenta esta explosión de dispositivos de "alta tecnología" y su utilización en la aviación general y como no, han generado y siguen generando recomendaciones que me parecen muy importantes, siendo la básica, aprender a utilizar el dispositivo (homologado o no) para que no se convierta en una distracción [1].

Sea cual sea el GPS que se tenga, es necesaria una muy buena planificación del vuelo y siempre llevar un mapa actualizado porque, cualquier dispositivo puede fallar.

El hardware 

Cuando decidí que me compraría una tablet para utilizarla como dispositivo de ayuda a la navegación, estuve viendo lo que había en el mercado y en un pricipio, se queda uno abrumado con la cantidad de opciones que existen, así que intenté acotarlas. Necesitaba una tablet pequeña ya que la cabina de una Cessna 172 o una Piper PA-28 no son lugares espaciosos. Tampoco debería ser muy pequeña porque allá arriba, en verano y a baja altitud, eso se mueve muchísimo e intentar descifrar lo que muestra una pantalla pequeña en pleno vuelo, no es algo cómodo ni seguro.

En los múltiples videos que había visto, lo más común era observar tablets de 10 pulgadas o de 7. Yo me decanté por una de 7.

Google había sacado la Nexus 7 y tenía buenos comentarios. En el momento te tomar mi desición, ya habían sacado la Nexus 7 2013.

Curiosamente, esta generación de Nexus (la 2013) vino con un problema en el GPS y en el touch screen. El GPS no funcionaba correctamente y el touch screen era bastante errático.

Leyendo los foros en internet, los usuarios ponían verde a Google y a Asus, pero el problema, al menos el del GPS, estaba más o menos solucionado, o al menos así lo reportaban los foristas. El del touch screen tardó un poco más en reportarse como solucionado. Para mi tranquilidad, cuando compré mi Nexus, ambos problemas tenían solución, así que tenía una tablet de tamaño ideal, potente, con una pantalla espectacular y sin todo el "crapware" que le instalan los demás fabricantes.

Esta tablet había que ponerla en algún lado en la cabina y en los videos de youtube la había visto en los "cristales" del avión, en los mandos (joke mount) y en las piernas (con un piernógrafo).

La solución más rápida y barata fue la de ponerla en un piernógrafo, así que me compré otro (no son muy caros los que son simples) y ahí la puse.

Al principio funcionó bien, pero como era de esperarse, había que bajar mucho la vista para leer la información, cosa que no me tenía del todo contento.

Las opciones estrella de los youtubers eran los montajes RamMount. No son baratos pero si muy versátiles, así que ahorrando un poco, decidí invertir (nótese que puse invertir y no gastar ;) ) en un montaje para los mandos (joke mount).

Es muy cómodo, no obstaculiza la visión de los instrumentos y siempre tienes la información a la vista sin bajar la cabeza.

Este es un video de como queda la tablet en su montaje:



El Software

Actualmente, existe una gran cantidad de programas para planificación y seguimiento del vuelo, algunos de ellos realmente impresionantes. Aparte de eso, hay compañías que están en el negocio de la electronic fly bag y hacen un trabajo muy bueno con la cartografía en digital, cartas electrónicas georeferenciadas y un montón de cosas que atentan contra tu sueldo.

Lamentablemente (para mi), la mayoría de estos programas solo funcionan en iPad's o son muy costosos (Skydemon por ejemplo, es para Android pero la subscripción no es "para domingueros"), por lo que tuve que buscar algo que se adaptara a lo que tengo y a lo que puedo pagar.

Los requisitos que tenía que tener el programa "adecuado para mi" son los siguientes:

  1. Que funcione en Android, de esa manera tendría el programa en el teléfono y en la tablet (redundancia).

  2. De costar dinero, que fuese lo suficientemente accesible para mi presupuesto y que la licencia me permitiese utilizarlo, a la vez, en el teléfono y en la tablet por el mismo precio.

  3. Que pudiese utilizar mis propios mapas ya que tendría la facilidad de construirlos yo mismo con mis propias especificaciones.

  4. Que  pudiese leer archivos de espacio aéreo en OpenAir o, al menos, en KMZ o KML, de esta manera no esperaría por terceros a que se actualizaran dichos archivos.

  5. Que el programa tuviese un soporte "adecuado" es decir, que las bases de datos (si las tiene) tengan los datos de España y que se actualicen o se puedan actualizar fácilmente, además, que exista un desarrollo constante por si sale algún bug.

Después de mucho tiempo buscando encontré Fly is Fun que tiene todo lo que menciono arriba y es bastante bueno.

Esta aplicación se consigue en google play, tiene un foro de soporte, el desarrollador responde bastante rápido y cumple con todos los requisitos que pedía. Tampoco es muy cara, 12€ al momento de escribir esto.

Pienso hacer otro post mostrando algo del funcionmiento de la aplicación.

Conexión de audio

Esto es algo bien importante, como mencioné en otro post, tengo una aplicación que me avisa cada 30 minutos para cambiar el tanque de combustible, además de esto, Fly and Fun emite alertas sonoras cuando te aproximas a un espacio aéreo o cuando cambias de waypoint.

Al menos la alerta de cambio de tanque de combustible, es muy recomendable escucharla y resulta que el headset que tengo (Sennheiser HME95) trae un cable para conectar una fuente externa de audio.

La conexión de audio de la tablet está en su parte superior, así que para que el cable no moleste, coloco la tablet invertida en el joke mount así la conexión de audio queda hacia abajo y no tengo problemas con el cable.


Batería extra

Si bien es cierto que la batería de la tablet me puede durar hasta cuatro horas de navegación, recientemente me compré una batería portátil de 10.000 mA porque no quiero correr riesgos. Esta batería es realmente económica, pequeña y liviana y me sirve para cargar la tablet y el teléfono.

Bueno, esto es todo, el post ha quedado largo, espero que sea de utilidad.
___________

[1] The lost art of paying attention. FAA Safety Briefing Jan-Feb 2014, p8-11

Saturday, June 4, 2016

La bolsa de vuelo (fly bag)

En mi caso, el morral y esta es la historia.

Cuando comencé a hacer mi curso de PPL sabía que necesitaba un bolso (morral, mochila, etc.) donde llevar el cuaderno, libros, CR3, plotter, etc.

Tengo mucho tiempo llevando morrales para todos lados (oficina, viajes, etc.) ya que son muy cómodos y al estar colgados a la espalda, tienes las manos libres.

Cuando comencé a hacer mis prácticas de vuelo, seguí con mi morral (Puma) que me había comprado inicialmente, en el que me cabe todo lo que necesitaba y es super liviano.

Pero también es cierto que la tentación siempre está ahí, ¿cuál tentación? pues la de comprarte un "bolso de piloto" que supuestamente está diseñado específicamente para pilotos y por pilotos. El problema es que son bastante caros y para llevar las cosas que llevaba, el Puma era perfecto, así que continué con mi Puma incluso hasta después de terminar mi entrenamiento.

Una vez que ya eres piloto, comienzas a "comprar cositas", en mi caso, una tablet para tener mi programa de navegación, un "joke mount" para poner la tablet cómodamente en los mandos, una batería portátil y así, más y más cosas y se fue llenando el bolso hasta que llegó un momento en que era realmente incómodo sacar y meter cosas con facilidad y mantenerlas ordenadas.

Llegó el momento "perfecto" para comparme ese bolso de piloto que "debía" tener, que está diseñado por y para pilotos... pero ufff, el precio seguía siendo algo que me frenaba y mira que vi precios y opciones.

Un día, pensando (aveces pasa) sobre mi "problema", se me ocurrió que un morral podría servir siempre y cuando fuese lo bastante amplio y con los suficientes compartimentos para meter todo. El Puma era un modelo simple pero hay muchos modelos más. Fue entonces cuando mi "dilatada experiencia" en backpacks (morrales para laptops) me ayudó. Qué tal si miraba backpacks espaciosos para usarlos como bolsas de vuelo?

Los backpacks los hay en una gran variedad de modelos, tamaños, precios y marcas. Dedicándome a lo que me dedico, se por experiencia que Targus es una muy buena marca, así que comencé con Targus.

Me metí en Amazon a ver bolsos y bolsos, a leer opiniones, capacidades, etc. Efectivamente, los backpacks son más baratos que las "bolsas de piloto", imagino que el mercado es más amplio (el de los backpacks).

Al final me decidí por el Targus Drifter (https://www.amazon.es/gp/product/B0067PN5ZE/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1). Tiene cinco compartimentos y una gran cantidad de bolsillos y  no es muy pesad.

Cabe todo lo que llevo y aún sobra por si me antojo de más cosas y todo queda bién separado y organizado.

Esta es una foto que muestra todo lo que llevo actualmente.



El precio que tiene me parece bastante competitivo dada la capacidad y la cantidad de compartimetos y bolsillos que tiene y aunque no sea Jeppesen, es Targus y en mi experiencia, Targus es muy muy bueno.

Friday, May 27, 2016

Ahora con Piper

Después de obtener el PPL viene la etapa "post-licencia", es la etapa en donde ni el dinero ni el tiempo sobra pero quieres seguir volando porque para eso te sacaste la licencia. También por seguridad ya que la única manera de no oxidarte es volar contínuamente.

En mi caso, continué volando con mi escuela (Aerofan), en la que compré un pack de 10 horas. Esto tiene sus ventajas, conoces la escuela, conoces la aeronave y esto te da la tranquilidad necesaria para disfrutar de esas horas en las que eres PPL oficialmente. Pero como todo, alquilar el avión en una escuela tiene sus contras también. Como es una escuela, su función es dar instrucción por lo que el uso del avión es mucho más estricto. ¿A qué me refiero? a que no puedes reservar el avión por un día y solo volar 3 horas (irte por la mañana a un aeródromo, almorzar y luego regresarte antes del ocaso), no puedes llevarte el avión y hacer "noche" en algún pueblo y traerte el avión al día siguiente, por ejemplo.

Para esas cosas, es mejor un club. Me habían hablado del Club de Vuelo TAS y me habían hablado muy bién de él. El único "contra" que le veía es que no tenían Cessna's, solo Piper's lo que supondría "soltarme" en ese avión.

Lo estuve pensando durante algún tiempo, estuve preguntando a otras personas que también venían de Cessna y me decían que, aunque son diferentes, no lo son demasiado y que era bueno probar otro tipo de aeronave.

Al final me animé, me hice socio del club y comencé mis vuelos de familiarización con la Piper para "soltarme" en ese avión.

Antes de alquilar unas horas en la Piper (Una PA-28-151 en principio) me estudié el manual del piloto (POH) y las checklist normales y de emergencia. Aquí los primeros cambios.

La Piper tiene un selector de combustible que no tiene posición de "Both" como la Cessna 172, por lo que hay que cambiar de tanque manualmente, los flaps son mecánicos no eléctricos como en la 172 por lo que en los precedimientos de emergencia, puedes apagar el master y sigues con mando sobre los flaps. Las velocidades (V speed's) son diferentes, así que tienes que borrar esa impronta que te hiciste durante el curso y aprenderte otras, menos mal que no son tan diferentes.

La Piper tiene bomba de combustible por lo que hay que acordarse de encenderla y apagarla cuando sea necesario. Nota importante: A los que venimos de Cessna siempre se nos olvida poner o quitar la bomba y cambiar de tanque de combustible.

Eso, en cuanto a lo que puedes ver "desde afuera".

Una vez dentro de la cabina, la cosa también cambia bastante y es bueno tomarse su tiempo para ver donde está todo, para eso los vuelos de familiarización. En mi caso, una foto de la cabina como wallpaper me ayudó bastante también, sobre todo a la hora de repasar los procedimientos de emergencia.

Una de las tantas advertencias que me hizo el instructor en el primer vuelo de familiarización es que a la Piper "le pesa el morro" es decir, que a la hora de la recogida tenía que estar más vivo que con la Cessna. Otra importante, la Piper es un avión de ala baja con lo que el efecto suelo se nota muchísimo más que con la Cessna que es ala alta.

Meterse en el avión es incómodo, tiene una sola puerta (la 172 tiene dos) así que me lo estoy pensando para llevar a una persona mayor o de "poca" movilidad ya que hay que subirse al ala y luego meterse en esa "espaciosa" cabina.

En mi primer vuelo de familiarización hicimos lo acostumbrado, fuimos a la "zona de los plásticos" a practicar virajes, pérdidas, fallos de motor, etc. Lo normal para irme acostumbrando al nuevo avión.

En las maniobras ya me pude dar cuenta de que si, le pesa el morro a la Piper y de que el trim es incómodo comparado con la 172.

La visibilidad es otra cosa que cambia mucho, al ser la Piper un avión de ala baja, te falta como un "techo" y te sientes más descubierto, pero es solo una sensación. Los virajes en circuito son mucho más fáciles porque nunca pierdes de vista a la pista.

Como sientes que el avión "pesa más" piensas que no va a planear "tanto" como la 172 pero es solo una sensación, planea bien es solo cuestión de acostumbrarse.

En las tomas tienes que estar más pendiente del alabeo ya que es más fácil tocar el piso con el plano en un ala baja que en un ala alta. El efecto suelo se nota un montón, malo para campos cortos, otra cosa que hay que cuidar.

Con respecto alcambo de tanques de combustible, según normas del club, debe hacerse cada 30 minutos, lo que te obliga a estar muy muy pendiente de los aforadores. Para facilitarme el trabajo y como medida extra de seguridad, instalé una aplicación en la tablet que es un timer y lo activo en el punto de espera antes de la prueba de motor. La aplicación que uso es A HIIT Interval Timer (para Android).

Con respecto al club, si, es otra cosa, al no haber un instructor contigo siempre, tu te "sientes más responsable" de todos los procedimientos en tierra. En Aerofan siempre hay, al menos, un instructor en la parte de operaciones con el que siempre puedes comentar algo o pedirle consejo. En TAS hay siempre un instructor de guardia pero al estar en una oficina del lado tierra del aeropuerto, cuando llegas al avión estás solo y eso es una sensación diferente, hasta parece que el avión fuese tuyo :).

El club organiza eventos en los que te puedes anotar como parrilladas, fly-in's, etc. y tiene un "servicio" de anuncios en el cual puedes quedar con alguien para no volar solo y así conocer a más miembros del club.

Con TAS, alquilas por horas y no tienes que pre-pagar un pack, así que solo tienes que tener saldo disponible para reservar las horas que quieres volar.

Al momento de escribir este post, llevo 20,9 horas con el club y he volado una Piper Cherokee Warrior, una Piper Cherokee Warrior II y una Piper Archer.

Disclaimer: Este post no es un "publi-reportaje" sobre TAS, es solo mi experiencia. Hay otras compañías con las que se pueden alquilar horas, por ejemplo Fly and Fun que tiene una Cessna 172  bien cuidada y con un Garmin 1000, por ejemplo. No he volado con ellos pero ganas no me faltan, un Garmin 1000 atrae mucho ;)

Tuesday, August 4, 2015

Túneles de ssh

Este post no pretende ser la guía definitiva para hacer túneles de ssh, lo que si pretende es mostrar algunas situaciones que tengo que vivir a diario y que, con túneles de ssh, pueden hacerse más llevaderas.

Para empezar, la mayoría de los administradores de sistemas tenemos que acceder a servidores remotos para realizar nuestro trabajo diario. Estos servidores, la mayoría de las veces, no son alcanzables directamente desde nuestra estación de trabajo, por lo tanto, necesitamos acceder a ellos mediante otro servidor al que llamamos de diferentes maneras, jump server, servidor de salto, máquina de administración, etc, etc.

Los administradores de unix nos sentimos muy afortunados cuando este jump server es unix (generalmente Linux) ya que se nos hace la vida muchísimo más fácil.

Voy a poner varias situaciones que se me presentan diariamente y que gracias a los túneles de ssh puedo afrontar de una manera cómoda.

1.- Ejecutar una aplicación gráfica en un servidor remoto

Cuando hay que pasar por un jump server, la cosa ya no es tan fácil como poner "-X" al ssh. Es aquí donde el túnel de ssh hace su magia.

La cuestión es la siguiente: hacer un túnel desde la estación de trabajo, que pase por el jump server y finalice en el servidor remoto de manera que pueda iniciar una sesión de ssh que haga X forwarding (-X) y pueda ejecutar la aplicación gráfica en el servidor de destino y que se muestre en mi estación de trabajo.

El dibujo de abajo lo explica mejor:







Para realizar esto debemos asumir lo siguiente:

A.- El jump server tiene un servidor ssh.
B.- En nuestra estación de trabajo tenemos un servidor X.
C.- El servidor de destino tiene ssh.

Los comandos serían como lo siguiente:

Establecer el túnel:
[ estacion ] ssh -L 2222:servidor:22 usuario-jumpserver@jump_server

Conectarse y ejecutar la aplicación gráfica:
[ estacion ] ssh -X -p 2222 usuario-servidor@localhost
[ servidor ] appX


Explicación:
ssh -L 2222:servidor:22 Estamos abriendo un túnel que va desde nuestra estación de trabajo en el puerto 2222 y termina en "servidor" en el puerto 22

usuario-jumpserver@jump_server Aquí estamos entrando en "jump_server" con el usuario "usuario-jumpserver", de esta manera el túnel se realiza desde nuestra estación de trabajo, a través del jump server y finaliza en "servidor"

ssh -X -p 2222 usuario-servidor@localhost Aquí estamos iniciando una sessión de ssh con "XForwarding" (-X) en el puerto 2222 (-p 2222) de nuestra estación de trabajo (el inicio del túnel) con el usuario "usuario-servidor" que debe ser un usuario válido en "servidor"

appX Ejecutar la aplicación en el servidor "servidor"


2.- Conectarse por remote desktop a un servidor windows a través del jump server

Alguna vez hemos tenido que conectarnos por rdesktop a una máquina con windows. Utilizando un tunel de ssh podemos conectarnos a ese servidor windows con la herramienta rdesktop de una manera sencilla:

[ estacion ] ssh -L 3389:servidor:3389 usuario@jumpserver

Explicación:
ssh -L 3389:servidor:3389 Creamos un túnel de ssh en nuestra estación de trabajo que escuchará en el puerto 3389 cuyo extremo será el servidor "servidor" en el puerto 3389

usuario@jumpserver El túnel pasará a través de "jumpserver" autenticándonos como "usuario"

Ahora solo hay que hacer lo siguiente en nuestra estación de trabajo

[ estacion ] rdesktop localhost


3.- Túnel reverso de ssh

ADVERTENCIA: Esto puede meterte en problemas con tu administrador de redes/sistemas. No me hago responsable del uso que se haga de esto. Esto es solo una demostración de concepto.

Analicemos el siguiente escenario. Se tiene una estación de trabajo detrás de una red corporativa. Desde esta estación de trabajo se puede hacer ssh a una máquina en Internet. La estación de trabajo no es accesible desde internet.

Pues bien, con ssh es posible establecer un túnel desde la estación de trabajo hasta esta "máquina en Internet" y luego poder conectarse desde esa "máquina en Internet" a la estación de trabajo y así poder operar desde "Internet" como si se estuviese en el lugar de trabajo.

Esto es "ideal" para trabajar desde la casa sin molestos clientes de VPN que solo sirven en windows o en ciertas "versiones de Linux".

Nota: Se asume que el router de la casa está configurado para hacer posible la conexión a "desktop.home" por ssh desde fuera. No es objetivo de este post mostrar como realizar esto.

Este sería el procedimiento:

[ estacion ] ssh -R 2022:localhost:22  usuario-home@desktop.home

Luego en desktop.home hacer lo siguiente:

[ desktop.home ] ssh -p 2022 usuario-estacion@localhost

Explicación:
ssh -R 2022:localhost:22  Establezco un túnel que va desde desktop.home en el puerto 2022 a estacion en el puerto 22

usuario-home@desktop.home usuario y nombre de la "máquina de Internet".


4.- Túnel de ssh multi saltos (multihop)

Aquí rizamos el rizo :) En este caso, necesitamos acceder a un servidor mediante varios jump servers. Aplicamos lo que he explicado anteriormente pero con recursividad :)

Este dibujo trata de explicar el escenario que propongo.




Como se ve, "Servidor" solo es alcanzable desde "Jump Server 2" y aunque bastaría con llegar a "Jump Server 2" para tener una sesión de ssh, abrir una aplicación gráfica en "Servidor", que se mostrara en nuestra estación de trabajo, sería imposible.

Para hacerlo posible, creamos dos túneles de ssh, el segundo "dentro" o utilizando el primero.

Primer túnel, desde la estación de trabajo hasta "Jump Server 2" utilizando a "Jump Server 1"

[ estacion ] ssh -L 2222:Jump_Server_2:22 usuario-jump_server_1@jump_server_1

Segundo túnel, utilizando el primero (que "comienza" en el puerto 2222),  desde nuestra estación de trabajo hasta "Servidor"

[ estacion ] ssh -p 2222 -L 2223:Servidor:22  usuario-jumpserver2@localhost

Para conectarnos al servidor de destino realizamos lo siguiente:

[ estacion ] ssh -p 2223 usuario-servidor@localhost



Espero que esto sea de utilidad.

Friday, November 1, 2013

PPL ... al fin.


Pues si, el día domingo 6 de octubre de 2013 aprobé el exámen práctico para la obtención de la licencia de piloto privado de avión, PPL (A), en Madrid, España.

¿Qué es PPL?, es, literalmente, Private Pilot License, es una licencia que te permite, según  el reglamento de la Unión Europea Nº 1178/2011 del 3 de noviembre de 2011, sección 2, FCL.205.A (a), hacer lo siguiente:

"Las atribuciones del titular de una PPL(A) son actuar sin remuneración como piloto al mando o copiloto en aviones o TMG que participen en operaciones no comerciales."

TMG significa motovelero de turismo.

En cristiano, que puedo alquilarme una avionetica tipo Cessna 172 y darme un paseo.

¿Para qué obtener esta licencia? ¿qué hago con eso? Desde muy pequeño siempre me ha gustado la aviación, recuerdo que en 4º de primaria ya leía libros sobre aviones caza. Recuerdo también que los "simuladores" de la empresa Microprose hacían preguntas para poder acceder al juego, las preguntas consistían en que te ponían la silueta de algún caza y debías responder a qué avión pertenecía. Nunca necesité "la hoja de claves" del juego, siempre me resultó muy facil identificar correctamente la silueta.

La primera vez que me monté en un avión ligero fue en Puerto Rico en 2005, un gran piloto (y mejor persona), Pedro Fernández, me invitó a dar una vuelta en una Cessna 177 RG Cardenal. Aquello no fue normal, otra cosa, tenía ya horas de "vuelo" en flight simulator, pero aquello fue tocar el cielo.

La experiencia se repitió una vez más y qué puedo decir, fue lo máximo.

Cuando llegué a España, y gracias a un regalo de mi novia (hoy mi esposa), pude hacerme un vuelo de bautizo en un ULM (ultraligero motorizado), una Tecnam P96 en el aeródromo de Casarubios del Monte (LEMT). Otra vez tocando el cielo, esta vez pude llevar el ULM con ayuda del instructor.

Después de este vuelo de bautizo y animado por mi esposa, hice el curso de ULM, ya estaba volando. Aprobé mis exámenes práctico y teórico y obtuve mi licencia.

A pesar de tener la licencia de ULM, la escuela requería que hiciese un depósito de 1000 € y aprobar otro exámen interno para poder alquilarme el ULM a mi solo e irme por los pueblos de España. Esa situación me hizo plantearme hacer el curso del PPL ya que:
  • Podría despegar y aterrizar en aeropuertos controlados.
  • Podría meterme en espacios aéreos VFR (todos menos el A).
  • Podría volar solo (sin instructor) cuando tuviese mi licencia.
  • Podría volar aviones más "grandes".


Pues bien, las condiciones económicas estaban dadas para poder pagarme el curso, así que comencé a averiguar en qué escuela hacerlo. Después de leer varios foros y varias opiniones, me fuí a el aeródromo de Cuatro Vientos (LECU) en Madrid a preguntar en las diferentes escuelas que existían, tal y como me lo habían sugerido en los foros.

Como era de esperarse, múltiples impresiones, cantidad de información, precios, opciones, etc. Al final me decidí por Aerofan por varias razones, por precio, flexibilidad de horarios en las clases teóricas, podía asistir a tantas clases como quisiera, no tenían restricción de tiempo para hacer el curso aparte de los que pone la Agencia Estatal de Seguridad Aérea (AESA) y Aviación Civil.

Requisitos

Para poder optar a la licencia de piloto privado hay que tener 16 años y un certificado médico, al menos Clase II. Ambos requisitos los cumplía. Por ese lado estaba bien, sin problemas para comenzar el curso.

Material

El material que debía tener para comenzar el curso es el siguiente:

  • Un plotter.
  • Un CR3.
  • Carta aeronáutica. Yo compré la Jeppesen LE-2 1:500000 vfr+gps.
  • Dos lápices grasos (rojo y negro).
  • Piernógrafo.
  • Drenador.
  • Los "libros de Adsuar" (opcional, ojo con esto).


El piernógrafo y el drenador son exclusivamente para hacer las prácticas, así que, si como yo, se quiere dejar los vuelos para el final, no es necesario que se compren a la primera.

Sobre los libros de Adsuar, yo compré la colección completa para el PPL y ahora no estoy seguro si fue una decición acertada y me explico. Con todo respeto para el señor Adsuar, los libros para el PPL están redactados de una manera bastante enrevesada, pareciera que el autor lo que quiere es demostrar que sabe mucho (lo cual no dudo) pero a nivel pedagógico, en mi humilde opinión, deja bastante que desear. He leido "algún" libro técnico a lo largo de mi vida y opino que este señor debería revisar su redacción para que fuese más clara, concisa y con menos adornos literarios, al final son libros técnicos, no ensayos de prosa.

Sin embargo, los libros de Adsuar sirven y mucho, como libros de consulta una vez que ya se ha aprendido el temario. En resúmen, no son libros para aprender desde cero, son libros de consulta para aclarar alguna duda.

Si, me he quedado a gusto :) es mi blog :)

El curso de PPL

El curso lo comencé el 12 de septiembre de 2011, las clases teóricas eran de 7:00 pm a 9:00 pm, así que salía de la oficina a las 5:00 para no comerme el tráfico de la M-30 y el del Paseo de Extremadura. Llegaba a Cuatro Vientos temprano, así que me daba tiempo de poner la frecuencia de la torre en el scanner o de echarme una pequeña ciesta en el carro ;).

El curso de PPL consta de 9 materias teóricas:

  • Principios de vuelo.
  • Procedimientos operacionales.
  • Comunicaciones VFR.
  • Conocimiento general de la Aeronave (CGA).
  • Performance y planificación del vuelo.
  • Navegación.
  • Meteorología.
  • Derecho aeronáutico.
  • Factores humanos.


Mi primera clase teórica fue principios de vuelo. Es física básicamente, aerodinámica. El instructor muy dedicado, explicaba muy bien, me dió muy buena impresión.

A lo largo de todo el curso todos los instructores que me tocaron (cinco en total) en las teóricas, se esmeraron por enseñarnos las cosas, desde aquí se los agradezco de corazón. Sé lo que es dar cursos y a esas horas del día, con los alumnos bastante "espesos", es de admirar.

A los que se inician en esto, mi recomendación es que acudan a clase, no es lo mismo leerse un libro (y menos los de Adsuar) a que te expliquen con una pizarra y te aclaren las dudas. Reitero, hay que ir a clase!!!!

Exámenes teóricos

Llegó el día en el que me tenía que presentar a exámen. Solo había tenido tiempo para preparar tres materias, me presenté a principios de vuelo, comunicaciones y procedimientos operacionales.

A mi me tocó la época de la transición entre el sistema de exámenes por convocatoria y los exámenes "electrónicos" en SENASA (Servicios y Estudios para la Navegación Aérea y la Seguridad Aeronáutica S.A.). Las tres primeras materias las presenté en la modalidad de convocatorias. El lugar era el mismo Cuatro Vientos que se llenaba de gente de todas partes de España que venían dos o tres días a presentar exámenes (arcaico completamente, pero hay más).

Aprobé las tres materias, ya me había quitado tres de encima.

La próxima vez que fuí a presentar exámenes fue ya en la nueva modalidad que consistía en ir a SENASA y presentar exámenes en una computadora (como cualquier exámen de certificación de HP-UX, Cisco, etc). Aquello fue un caos al principio, en teoría se usaban los bancos de preguntas europeos, pero luego en la práctica y según contaba la gente, en los exámenes de PPL(A) salían preguntas de ATPL (Air Transport Pilot Licese), del PPL de helicóptero, preguntas mal formuladas, mal traducidas, no dejaban usar calculadora a los PPL's, etc., etc. Al final los problemas se resolvieron y la cosa comenzó a funcionar "decentemente", sin embargo, la gente tenía (y tiene al momento de escribir este post) que seguir viniendo a Madrid a presentar unos exámenes, eso si, en unas Sparc.... siglo XXI....

Preparación de los exámenes

Como me tocó presentar en dos modalidades diferentes, la preparación de los exámenes también fue algo diferente.

Modalidad de convocatorias

Para esta modalidad conseguí una cantidad enorme de test's. En teoría, eran preguntas que habían salido en exámenes anteriores, el problema es que algunas estaban mal redactadas, aveces una misma pregunta tenía respuestas diferentes como buena, al final dependes de la memoria de la persona que haya tenido la amabilidad de recordar la pregunta y las respuestas. Sin embargo, pude estudiar así.

La cuestión con los test's es que no puedes estudiar solo con ellos, hay que estudiar el tema, entenderlo, ir a clases y ya luego, para fijar conocimientos, los test's.

Pues bien, para principios de vuelo, comunicaciones y procedimientos operacionales fui a todas las clases, investigué por internet, usé los libros de Adsuar (OMG!!!!), me leí varios anexos al convenio de Chicago y al final si, muchos test's para reafirmar conocimientos y para ir viendo más o menos el tiempo que demoraba en contestar. El resultado, las tres aprobadas :)

Modalidad "SENASA"

Ya para cuando me tocó presentar con esta modalidad, habían muchas personas contando sus experiencias en el foro de extracrew.com (hilo de las preguntas que han salido en el PPL). Recomiendo leer este hilo y recopilar todas las preguntas (y respuestas) que los foristas amablemente colocan. Son un recurso de incalculable valor. También, en la lista interna que tenemos algunos alumnos de la escuela, habían experiencias previas con SENASA (desde aquí mil gracias a todos).

Aquí lo mismo, asistir a clases, investigar por internet, recopilar las preguntas de otros, hacer test's y.... me quedó performance la primera vez que me presenté en la modalidad "SENASA". ¿Por qué? porque la materia se llama performance y planificación del vuelo y en el libro de Adsuar (OMFG!!!!), de planificación del vuelo nada, en clase nos dieron algunas nociones y en el exámen me salieron preguntas "curiosas" del "trip fuel" del demonio que jamás había visto. Pues nada, a preguntar a los instructores, a comentarlas en el foro y en la lista y si, se encontró respuesta :)

Después de esta tanda hice un parón, resulta que me invitaron a una boda (la mía) y tuve que dejar de estudiar por razones obvias.

Después que pasó todo el asunto de la boda, retomé el estudio y decidí tratar de sacarme el resto de materias en dos tandas. En la primera iría "contra" performance porque esa espinita me la sacaba yo porque si.

Pues bien, "cayó" performance y también cayeron las demás. La última tanda la terminé en enero del 2013

Como consejo reitero, pasarse por el foro de extracrew y recopilar todas las preguntas del hilo del PPL, estudiar concienzudamente y asistir a clase.

Fase práctica

Al quitarme de encima las teóricas (son una verdadera losa), llegaba el momento "dulce". Ahora solo me tocaba volar y volar las 45 horas que me exigen para la obtención de la licencia.

Si uno piensa que ya ha pasado el tiempo de estudiar, mejor pensar de nuevo. Hay que estudiar y mucho, hay que leerse el manual del avión, el análisis de maniobras, poner en práctica todo lo que, en teoría, has aprendido de las nueve materias, hay que aprenderse el circuito de LECU, hay que aprender a hablar en la frecuencia común, hay que quitarse el miedo de hablar con los ATC's, etc., etc., pero se hace con un gusto...

Las primeras clases prácticas son realmente abrumadoras, la cantidad de información que debes procesar no es normal pero bueno, para eso uno está ahí, ¿no? ¿quién dijo miendo?. Yo venía de volar ULM's, pero es muy muy diferente volar una C172, para que se me entienda, es como andar en bicicleta y luego en un camión.

La Cessna 172 me parecía pesadísima, muy grande, estaba acostumbrado a que, con el ULM, metes gases y enseguida sube y con la 172 nanai nanai, como no se tire de los cuernos después de meter gases, no se sube. A la hora de la recogida con full flaps, aquello era un ladrillo, era cómico escuchar al instructor hablando del efecto suelo, WTF???!!!!! si aquello se caía como una piedra!!!!!!

Siempre iba "por detrás" del avión, pero bueno, se está aprendiendo... aún hoy no creo que yo vaya muy "por delante" ;)

Las horas transcurren más rápido de lo que uno piensa (y quiere) y llega el día de la suelta, el momento en que debes demostrar lo que has aprendido (básicamente porque de ello depende tu vida ;) ).

Después de la suelta vienen los vuelos solos "supervisados", donde el instructor de turno le reza a todos los santos para que no te pase nada, te reportes sobre S (sierra) y traigas el avión en una pieza. Lo digo por experiencia, vi a una instructora hacer un abismo en Operaciones de la escuela, caminando de lado a lado esperando esa frase ansiada "Cuatro Vientos torre, Aerofan XXX sobre S, instrucciones para el circuito".

En esos solos supervisados es donde ya uno comienza a sentirse piloto, el asiento de al lado está vacío, el avión pesa menos y no hay nadie para salvarte el c.... si haces algo mal... y se disfruta un mundo.

Luego viene el triangular, el mío fue LECU - LEVD - LEMT - LECU. Segunda  vez que cruzaba la sierra de Madrid, primera vez que subía a 8500 ft. Entrar en Valladolid es interesante, fue la primera vez que entraba en una pista de 3 km. Que el controlador de torre te "recite" el METAR estando acostumbrado al ATIS de LECU hace la experiencia más peculiar si se quiere y ya encontrarse el aeropuerto desierto... bueno, no, estaba el señor de la cafetería..... en fin, el tema político-aeroportuario lo discutiré en otro post... o no.

Después del triangular, el tiempo comienza a pasar muy muy rápido, quedan pocas horas para el exámen práctico y quieres que el tiempo retroceda pero no la (poca) experiencia adquirida.

Mi recomendación, "comprimir" lo más que se pueda las horas para estar "suelto" en el momento del exámen. Hay que tratar de colocar las sesiones lo más seguidas que se pueda (aunque la meteo te lo ponga difícil). En mi caso puse 3 horas el sábado y el domingo me examiné.

El exámen práctico

Es el momento más raro de todo el curso, quieres que llegue pero estás c...., asustado. Sentía que no sabía nada (tampoco es que sepa mucho en realidad), que no estaba listo para el exámen, en cristiano, que estaba muy pichón.

Le pregunté a los instructores cómo me veían y me decían que bien, que no me preocupara... no sirvió de nada, de sábado para domingo la intranquilidad aumentó :(

Pero bueno, traté de distraerme y de pensar en lo que había dicho "Eddie" Malacara sobre el exámen práctico, así que la suerte estaba echada. Aquí les dejo el video, lo recomiendo (está en inglés).



El exámen transcurrió tranquilamente, el examinador, ese si es pedagógico, intenta hacerte sentir tranquilo y al final las cosas salen. No fue muy diferente de una clase, creo que los instructores nos preparan correctamente para el exámen.

Si estás cerca de examinarte en la parte práctica, mira el video de Eddie y confía en tus instructores.

El papeleo

Después de aprobar el práctico viene el pago de tasas, entregar la hoja del triangular donde las oficinas ARO pusieron el sellito y esperar a que llamen de la escuela para decirte que tu licencia ha llegado.

¿Y ahora qué?

Yo me encuentro en esta etapa, tengo mi licencia, no me sobra el tiempo y tampoco el dinero y las ganas de volar están en su máximo nivel (¿tienen un mínimo? ;) ). Afortunadamente, hay personas que como yo, escriben cosas en su blog para que luego puedan servir a los que vienen detrás, es el caso de Gonzalo. En su blog el relata cómo fue su etapa "post licencia" y aunque mal de muchos consuelo de tontos, es últil saber que no estamos solos y que si se puede volar después. Desde aquí un saludo a Gonzalo.

Vencimientos y plazos

Otra cosa que hay que tener muy en cuenta después que se tiene una licencia (PPL en mi caso) es el tema de los plazos de renovación. Según el reglamento de la Unión Europea  Nº 1178/2011 el período de validez de la habilitación de clase monomotor de un solo piloto es de 2 años. Por si hay duda, colocaré la sección:

"FCL.740 Validez y renovación de las habilitaciones de clase y tipo
(a) El período de validez de las habilitaciones de clase y tipo será de 1 año, excepto para las habilitaciones de clase monomotor de un solo piloto, que tendrán un período de validez de 2 años, a menos que se determine otra cosa de acuerdo con los datos de idoneidad operacional, establecidos de acuerdo con la Parte 21."

Por lo tanto, después que nos dan la licencia, tenemos 2 años para revalidar la habilitación.

La revalidación viene descrita en el siguiente apartado que copio literalmente:

Nota: Actualización del 17 de marzo de 2015, aquí en inglés

FCL.740.A Revalidación de habilitaciones de clase y tipo-aviones
b) Revalidación de habilitaciones de clase monomotor de un solo piloto.
1)
Habilitaciones de clase de avión monomotor de pistón y TMG. Para la revalidación de una habilitación de clase de avión monomotor de pistón de un solo piloto o la habilitación de clase TMG, el solicitante tendrá que:
i)
superar una verificación de competencia en la clase correspondiente de acuerdo con el apéndice 9 de la presente Parte con un examinador en los 3 meses precedentes a la fecha de caducidad de la habilitación; o
ii)
completar 12 horas de vuelo en la clase correspondiente en los 12 meses anteriores a la fecha de caducidad de la habilitación, incluidas:
6 horas como piloto al mando;
12 despegues y 12 aterrizajes, y
un curso de actualización de al menos 1 hora con un instructor de vuelo (FI) o un instructor de habilitación de clase (CRI). Los solicitantes estarán exentos de esta formación de actualización si han superado una verificación de competencia de habilitación de clase o tipo o una prueba de pericia o evaluación de competencia en cualquier otra clase o tipo de avión.

Creo que está claro, no tengo nada que agregar.

Sobre la experiencia reciente, la norma dice lo siguiente:

FCL.060 Experiencia reciente
b) Aviones, helicópteros, aeronaves de despegue vertical, dirigibles y planeadores. Un piloto no operará una aeronave en transporte aéreo comercial o transporte de pasajeros:

     1) como piloto al mando o copiloto a menos que haya llevado a cabo, en los 90 días anteriores, al menos 3 despegues, aproximaciones y aterrizajes en una aeronave del mismo tipo o clase o un FFS que represente dicho tipo o clase. Los 3 despegues y aterrizajes deben llevarse a cabo en operaciones multipiloto o monopiloto, dependiendo de las atribuciones del piloto


Este último punto también depende de las normas internas de la escuela/aeroclub donde se alquile el avión, es posible que sean más restrictivos.

Eso es todo, me quedó un post larguísimo.

Tuesday, September 10, 2013

Apache Traffic Server en Debian Wheezy

Este post es solo un ejemplo simple de configuración de Apache Traffic Server como proxy inverso (reverse proxy).

Wikipedia tiene esta definición para proxy inverso:

Un proxy inverso (reverse proxy en inglés) es un servidor proxy situado en el alojamiento de uno o más servidores web. Todo el tráfico procedente de Internet y con destino en alguno de esos servidores web es recibido por el servidor proxy. Hay varias razones para ello:

  • Seguridad: el servidor proxy es una capa adicional de defensa y por lo tanto protege a los servidores web.
  • Cifrado / Aceleración SSL: cuando se crea un sitio web seguro, habitualmente el cifrado SSL no lo hace el mismo servidor web, sino que es realizado en un equipo ajeno equipado incluso con hardware de aceleración SSL/TLS.
  • Distribución de Carga: el proxy puede distribuir la carga entre varios servidores web. En ese caso puede ser necesario reescribir la URL de cada página web (traducción de la URL externa a la URL interna correspondiente, según en qué servidor se encuentre la información solicitada).
  • Caché de contenido estático: Un proxy inverso puede descargar de trabajo a los servidores web almacenando contenido estático como imágenes u otro contenido gráfico. También puede almacenar contenido generado dinámicamente pero que pueda ser en alguna medida reutilizable.
No tengo nada que agregar a la definición :)

En este post voy a poner un ejemplo de configuración de Apache Traffic Server (ATS) como proxy inverso para caché de contenido estático.

Entorno de prueba

El entorno de prueba que utilicé es una máquina virtual con Debian Wheezy donde correrán los dos bloques funcionales que utilizaré, el ATS y apache como servidor web. Lo siguiente es un resúmen del entorno de pruebas para que quede claro:
  • ATS escuchando en el puerto 8080
  • Apache escuchando en el puerto 80
ATS necesita al menos un servidor DNS así que tuve que montar uno sencillo en la máquina de prueba. No voy a describir el proceso porque no es el objetivo de este post, lo que describiré es la configuración básica.
  • Zona "int" con un registro A (ats.int) apuntado a 127.0.0.1
  • La zona inversa ya viene configurada con el paquete bind9
Con el servidor DNS funcionando (hay que asegurarse de que funciona) proseguimos con la instalación.

Instlación

Instalamos ATS con el siguiente comando:
# aptitude install trafficserver

ATS es un producto un poco "raro", no se maneja ni se configura como cualquier otro producto de software libre. Tiene varios archivos de configuración con un formato muy poco usual. Para esta demostración de concepto necesitamos "tocar" los siguientes archivos (o saber que existen):
  • records.config: Es el archivo principal de configuración y contiene las directivas principales que gobiernan el comportamiento de ATS.
  • remap.config: En este archivo están las redirecciones a los servidores "reales".
  • splitdns.config: Aquí es donde le indicamos los servidores DNS que vamos a utilizar además de configurar el comportamiento en lo que a resolución de nombres se refiere para cada dominio.

Para esta prueba vamos a dejar muchas configuraciones por defecto y solo modificaremos las que nos interesan, insisto, _para esta prueba_. En cristiano, que hay que leerse el manual, esto no es " la guía definitiva de ATS".

Con el ATS instalado, el siguiente paso es arrancarlo. Editamos el archivo /etc/default/trafficserver y colocamos la variable TC_START en "yes"
TC_START=yes

Ahora arrancamos ATS
# /etc/init.d/trafficserver start

En /var/log/syslog debería aparecer algo como esto:
traffic_cop[10778]: --- Cop Starting [Version: Apache Traffic Server - traffic_cop - 3.0.5 - (build # 5918 on Jun  9 2012 at 18:37:39)] ---
traffic_cop[10778]: can't get passwd entry for the admin user
traffic_cop[10778]: can't get passwd entry for the admin user
traffic_cop[10778]: traffic_manager not running, making sure traffic_server is dead
traffic_cop[10778]: spawning traffic_manager
traffic_manager[10779]: NOTE: --- Manager Starting ---
traffic_manager[10779]: NOTE: Manager Version: Apache Traffic Server - traffic_manager - 3.0.5 - (build # 5918 on Jun  9 2012 at 18:33:34)
traffic_server[10789]: NOTE: --- Server Starting ---
traffic_server[10789]: NOTE: Server Version: Apache Traffic Server - traffic_server - 3.0.5 - (build # 5918 on Jun  9 2012 at 18:36:30)
traffic_server[10789]: {1081143632} STATUS: opened /var/log/trafficserver/diags.log

Ok, ahora toca configurarlo, para eso utilizaremos el comando traffic_line (ya dije que ATS era muy raro).

Configuración

Cambiamos el propietario del estos archivos de manera temporal.
# cd /etc/trafficserver
# chown trafficserver records.config remap.config splitdns.config

Le diremos a ATS es que no guarde copias de los archivos de configuración (esto es una prueba)
#traffic_line -s proxy.config.admin.number_config_bak -v 0

Cache status en los encabezados HTTP (para debugging)
# traffic_line -s proxy.config.http.insert_response_via_str -v 1

Cuando hacer caché de cada objeto (mirar documentación)
# traffic_line -s proxy.config.http.cache.when_to_revalidate -v 4

No necesita encabezados especiales para hacer caché de un objeto.
# traffic_line -s proxy.config.http.cache.required_headers -v 0

Server mappings 

Ahora es cuando le indicamos a ATS lo que va a hacer con las peticiones, es decir, las reglas que debe seguir para manejar las peticiones que vienen desde "afuera". Para esto editamos el archivo /etc/trafficserver/remap.config y colocamos lo siguiente al final del archivo:

map http://ats.int:8080 http://ats.int

Resolución DNS

ATS usa los servidores DNS del /etc/resolv.conf, en este caso, para que use nuestro servidor DNS que es donde tenemos la zona de pruebas "int", debemos editar el archivo /etc/trafficserver/splitdns.config y colocar lo siguiente:
dest_domain=int named=127.0.0.1

y le decimos que lo use
# traffic_line -sproxy.config.dns.splitDNS.enabled -v 1

Hemos finalizado, falta recargar la configuración
# traffic_line -x

Devolvemos el cambio de propietario de los archivos de configuración
# chown root.root records.config remap.config splitdns.config


Pruebas

Ahora toca probar lo que hicimos, para esto, creamos un archivo html de prueba en /var/www con el siguiente contenido:
<html>
<head>Prueba</head>
<body>
hola, esto es una prueba
</body>
</html>

Editamos el /etc/hosts y añadimos el alias ats.int a 127.0.0.1. Esto es para poder utilizar el nombre ats.int con la herramienta GET.

Probamos con el siguiente comando:
$ GET -Ue http://ats.int:8080/prueba.html

Deberíamos obtener algo parecido a esto:
GET http://ats.int:8080/prueba.html
User-Agent: lwp-request/6.03 libwww-perl/6.04
200 OK
Connection: close
Date: Tue, 10 Sep 2013 13:22:28 GMT
Via: http/1.1 murphy (ApacheTrafficServer/3.0.5 [cMsSfW])
Accept-Ranges: bytes
Age: 0
ETag: "4e-4b-4e6073106eb8b"
Server: ATS/3.0.5
Vary: Accept-Encoding
Content-Length: 75
Content-Type: text/html
Last-Modified: Tue, 10 Sep 2013 13:07:48 GMT
Client-Date: Tue, 10 Sep 2013 13:22:28 GMT
Client-Peer: 127.0.0.1:8080
Client-Response-Num: 1

<html>
<head>Prueba</head>
<body>
hola, esto es una prueba
</body>
</html>


Es importante verificar la cadena "[cMsSfW]" del encabezado Via que nos está diciendo:
cM: cache miss (el objeto no está en el caché)
sS: served (el objeto lo proporcionó el "servidor original")
fW: writen (el objeto fue escrito en el caché)

En cristiano, que el archivo prueba.html no estaba en el caché, que lo fue a buscar en el servidor, lo encontró, lo mandó al cliente http y lo guardó en caché. Es lo que se esperaba, no?

Ahora volvemos a ejecutar el mismo comando:
$ GET -Ue http://ats.int:8080/prueba.html
GET http://ats.int:8080/prueba.html
User-Agent: lwp-request/6.03 libwww-perl/6.04
200 OK
Connection: close
Date: Tue, 10 Sep 2013 13:22:28 GMT
Via: http/1.1 murphy (ApacheTrafficServer/3.0.5 [cHs f ])
Accept-Ranges: bytes
Age: 317
ETag: "4e-4b-4e6073106eb8b"
Server: ATS/3.0.5
Vary: Accept-Encoding
Content-Length: 75
Content-Type: text/html
Last-Modified: Tue, 10 Sep 2013 13:07:48 GMT
Client-Date: Tue, 10 Sep 2013 13:27:45 GMT
Client-Peer: 127.0.0.1:8080
Client-Response-Num: 1


<html>
<head>Prueba</head>
<body>
hola, esto es una prueba
</body>
</html>

Observemos de nuevo el encabezado Via, tiene la siguiente cadena "[cHs f ]"  y vemos que tiene un cH, es decir un cache Hit, que quiere decir que el objeto pedido está en el caché y de ahí lo envió al cliente http sin irlo a buscar al servidor original. Es lo que se esperaba de un proxy caché, no?

Se puede seguir haciendo pruebas, por ejemplo, limpiar el caché (ver documentación), hacer un tail -f al access.log de apache y verificar que el apache registra la primera petición del objeto (normal, no está en el caché) y que en posteriores peticiones, no se registra nada en el access.log de apache.

Eso es todo, ya tenemos a ATS funcionando.