El 43 Grupo del Ejército del Aire es el encargado de operar a los hidroaviones de lucha contra incendios, operando aviones Canadair CL-215T y Bombardier 415. Con base en Torrejón, operan en todo el territorio español, estableciéndose destacamentos durante la temporada en diversas zonas de España: Talavera de la Reina, Matacán, Lavacolla, Pollensa, Zaragoza, Albacete y Málaga. El Ministerio de Defensa produjo el siguiente vídeo sobre la historia del grupo. Disfrutarlo.
En el día de ayer el Ejército del Aire ha llevado a cabo en el Polígono de tiro de las Bárdenas Reales (Navarra) el ejercicio Sirio fase Tormenta, donde participan sistemas de armas con capacidad de ataque al suelo. El grueso de la flota corresponde a los EF-18 (C.15), pero también han participado en el mismo dos Eurofighter (C.16) y dos F-5M (AE-9). Además se ha contado con el apoyo del Escuadrón de Apoyo al Despliegue Aéreo (EADA), Escuadrón de Zapadores Paracaidistas (EZAPAC) y Unidad Médica Aérea de Apoyo al Despliegue (UMAAR). El JEMA ha publicado un video con algunas imágenes del
En el ejercicio Sirio participa la práctica totalidad de de las unidades de combate del Ejército del Aire, con la finalidad de adiestrar y evaluar cual es el nivel de las Fuerzas Aéreas. Pueden intervenir otras unidades de las Fuerzas Armadas. Es el único ejercicio anual donde se utiliza fuego real.
En esta pequeña serie de entradas sobre la configuración de red en VMware Fusion falta tratar la configuración de NAT (Network address translation). Este mecanismo permite que todas las direcciones de una red determinada, sean traducidas usando la dirección de la interfaz del Mac. Por ejemplo, si la interfaz vmnet4 que están usando nuestras máquinas virtuales tiene el rango 10.0.2.0/24, y la interfaz de salida de nuestro Mac es la en0 con IP 192.168.1.100, al tener activado el NAT, se producirá una traducción de direcciones en los paquetes IP1, cambiándose la dirección IP y el puerto origen. La dirección IP será asignada a la que tenga la interfaz de salida del Mac y el puerto origen a uno que se tenga disponible para esa misión. La configuración puede verse en la siguiente captura de pantalla
Configuración NAT
Cuando se activa el NAT en una interfaz de VMware fusion se genera un fichero de texto con estructura INI con la configuración. Este fichero se llama nat.conf y estará en la ruta /Library/Preferences/VMware Fusion/iface. Para la interfaz vmnet4, la ruta completa sería /Library/Preferences/VMware Fusion/vmnet4/nat.conf.
El fichero de configuración de nat tiene varias secciones. La configuración general se encuentra en la sección [host]. La configuración para el NAT de conexiones tcp en [tcp] y las comunicuaciones que usen udp en [udp]. Si queremos exponer servicios que corren en nuestras máquinas virtuales a través de la dirección IP que tenga configurada la máquina anfitrión será necesario configurar el mapeo tanto de conexiones TCP como de posible tráfico UDP. Eso se hace en las secciones [incomingtcp] e [incomingudp]. Además se puede configurar parámetros de DNS en la secciión [dns] y parámetros de NetBIOS en la sección [netbios]. Esta última sección no se usa en MacOS X.
La configuración general se realiza en la sección [host]. Aquí se especifica cuál es la dirección de la pasarela de NAT, la máscara de la red, la interfaz que se está configurando. Estos tres parámetros se configuran a través de la propiedades ip, netmask y device. Por ejemplo:
[host]
ip = 10.0.2.2
netmask = 255.255.255.0 device = vmnet4
En la sección [host] existe unas propiedades que nos permite controlar el comportamiento del NAT, en concreto, si se debe permitir el modo activo del protocolo FTP (activeFTP) , si se permite que los paquetes que lleguen al proceso de NAT tengan cualquier dirección Mac - no las asignadas por VMware Fusion - (allowAnyOUI), si se quiere quiere que cuando se desactive la interfaz de red en el anfitrion resetee las conexiones TCP (resetConnectionOnLinkDown) y si no se deben permitir las conexiones hacia la dirección IP de la pasarela NAT (resetConnectionOnDestLocalHost). Por defecto, estos cuatros parámetros tienen el valor 1 y por tanto están activados en la configuración de la la red que se está haciendo NAT
En las secciones [tcp] y [udp] se controlan los tiempos de expiración (timeouts) que el proceso encargado del NAT esperará para dar por finalizada una conexión NAT. En el caso de TCP, se utiliza la clave timeWaitTimeout, con un valor en segundos, que por defecto es 30. Cuando se cierra una conexión TCP, el último estado del protocolo es el llamado TIME_WAIT donde se espera para que el otro extremo de la conexión reciba el asentimiento que le hemos mandado. En el caso de UDP la propiedad es timeout y su valor por defecto es 60 segundos, indicando el tiempo que va a existir un mapeo en UDP mientras no exista tráfico.
Sin embargo, para lo que se modifica este fichero realmente es para establecer reglas de NAT que hagan que servicios que se ejecutan en cualquiera de las máquinas virtuales que tienen acceso a la red que se está configurando se vean a través de la dirección IP del Mac que hace de anfitrión. Por ejemplo, si se tiene un servicio que usa el protocolo en la IP 10.0.2.10:443 y se quiere que se vea en 192.168.1.100:443 - asumo que esta es la dirección del Mac -, la sección [incomingtcp] se configuraría con la siguiente entrada.
[incomingtcp]
443 = 10.0.2.10:443
El formato es portmac = IP:port, donde portmac es el puerto que usará en la máquina anfitriona, IP es la en la red interna y port es el puerto en la máquina donde está el servicio. Se puede añadir las líneas que se deseen. El formato para [incomingudp] es el mismo. Comentar que después de modificar el fichero nat.conf de cualquier inteface es necesario rearrancar los servicios de red:
baldurgate:Library root$./vmnet-cli --stop
Stopped all configured services on all networks
baldurgate:Library root$./vmnet-cli --start
Enabled hostonly virtual adapter on vmnet1
Started DHCP service on vmnet1
Started NAT service on vmnet8
Enabled hostonly virtual adapter on vmnet8
Started DHCP service on vmnet8
Started all configured services on all networks
No he hablado de las secciones [dns] y [netbios] ya que sólo se utilizan cuando el anfitrión en Windows. El proceso donde está implementada la funcionalidad del NAT , vmnet-natd, es multiplataforma, y por tanto da soporte a esas opciones aunque no se utilicen en el Mac.
Hoy en España hay elecciones municipales y autonómicas. Recordad que:
Pero sobre todo, estimado elector, recuerde que los políticos españoles son un fiel reflejo de sus votantes: No piense que los políticos son una especie diferente al ciudadano de a pie.
Las herramientas de captura de tráfico de red que trae OS X, que se apoyan sobre la interfaz bpf (Berkeley Packet Filter) no puede capturar tráfico en las interfaces de las máquinas virtuales. Si se intenta poner a escuchar tráfico en una de las interfaces vmnet, que se tenga configurada , por ejemplo con el tcpdump, el sistema devolverá un error:
baldurgate:terron root$tcpdump -n -i vmnet5
tcpdump: vmnet5: No such device exists
(BIOCSETIF failed: Device not configured)
baldurgate:terron root$
Sin embargo, VMware Fusion tiene un programa que nos permite capturar todo el tráfico que vaya por las diferentes interfaces virtuales que se definan, vmnet-sniffer. Este programa se encuentran, si se instala por defecto en /Applications/VMware Fusion.app/Contents/Library. Es necesario pasarle la interfaz de la que se quiere pasar. Por ejemplo, si se quiere capturar tráfico desde la interfaz vmnet8:
baldurgate:Library root$./vmnet-sniffer -e vmnet8La opción -e hace que imprima las cabeceras ethernet. Si se desea, se puede grabar el tráfico que va capturando en un fichero con ayuda de la opción -w nombre de fichero. Posteriormente, este fichero puede analizarse con tcpdump o wireshark
len 195 src 00:50:56:cc:ca:08 dst ff:ff:ff:ff:ff:ff IP src 172.16.221.1 dst 172.16.221.255 UDP src port 17500 dst port 17500
Utilizo vim como programa editor para programar, normalmente usando los lenguajes Python y C. En C, suelo usar librerías como las glib y me interesa que las constantes, tipos y funciones también puedan controlarse desde el resaltado de sintaxis.
El resaltado de sintaxis en C está implementada en el fichero $VIMRUNTIME/syntax/c.vim. En el mismo se definen las instrucciones necesarias para que funcione el resalado de sintaxis editando código fuente en C. El problema que me planteaba es ver, si fuera posible, modificar el comportamiento de dicho plugin, pero sin necesidad de editar el fichero original. Concretamente, me interesaba añadir los tipos de datos que usa glib (gdouble, gchar, guchar, ...), algunas de sus constantes (TRUE, FALSE) o bien de los tipos de datos de otras librerías.
Durante el proceso de inicialización, vim busca diversos archivos con órdenes, para cargarlos y ejecutar las instrucciones que hay en los mismos. En el caso de Unix, el principal archivo de configuración es $HOME/.vimrc. Posteriormente cargará los plugins donde el sistema los tenga almacenados.Lo interesante, y es lo que se va a aprovechar para añadir nuestras modificaciones al comportamiento de c.vim , es que después de cargar los plugins, vim buscará en $HOME/.vim/after/ por ficheros de scripts para ejecutar órdenes. Cuando se activa el resaltado de sintaxis en un buffer de texto con código C se ejecuta el fichero $VIMRUNTIME/syntax/c.vim. Inmediatamente después, vim intentará ver si existe el fichero $HOME/.vim/after/syntax/c.vim o el directorio $HOME/.vim/after/syntax/c/*.vim. En el primer caso ejecutará las órdenes que existan en dicho fichero. En el segundo buscará todos los ficheros *.vim en el subdirectorio y los ejecutará. De esta manera vamos a poder modificar el comportamiento del resaltado de sintaxis y adaptarlo a nuestros gustos.
Por ejemplo, si quiero que vim utilice los mismos colores para mostrar los tipos de datos de glib gfloat, gint, guint, etc, lo que voy a hacer es crear un fichero en $HOME/.vim/after/syntax/c/glib.vim con el siguiente contenido
1 " GLIB types
2 syn keyword cType gchar guchar gint guint gboolean
3 syn keyword cType gsize gdouble gfloat gssize
Puede verse el resaltado de sintaxis en acción en este listado código:
1 #include <glib.h>
2 #include <stdio.h>
3 #include <stdlib.h>
4
5 int main(int argc, char **argv)
6 {
7 gchar * text;
8 gdouble *num;
9 gsize size;
10 }
Como puede verse, hemos añadido a un grupo de sintaxis determinado, cType una serie de palabras que cuando el plugin c.vim analice el texto para resaltar la sintaxis, las interpretará como tipos de datos. La orden que se encarga de hacer esta modificación es syntax keyword, puede abreviarse como syn keyword, seguida del grupo que se quiere modificar y las palabras que usan para ello. Algunos grupos del plugin de C son cType - los tipos de datos - o cConstant - para las constantes -. Pueden verse todos los tipos definidos si en un fichero de código fuente en C con el resaltado de sintaxis activado, en modo comandos escribimos :syn
Hay muchos de los pertenecientes al autodenominado mundo de la cultura que se han quejado amargamente de la subida del IVA para actividades que se pueden denominar culturales: Maribel Verdú, Pedro Almodovar, la unión de actores. Todos se quejan. Lo interesante es ver a estos mismos señores apoyando opciones políticas que defienden más control por parte del Estado y más impuestos. Pero como ellos son la cultura, ellos son especiales y sus actividades no tienen que pagar los impuestos de los demás. En el fondo, no deja de ser el mismo fenómeno que se reflejaba en el informe de la Fundación BBVA: Values and Worldviews: Todo el mundo quiere más Estado, pero eso sí que lo paguen otros.
Y sin tan malo es para las actividades que ellos desarrollan esa subida de IVA, ¿por qué ha de ser bueno para la venta de ordenadores, los alimentos o la electricidad?
El pasado 1 de Mayo se celebró en el Aeródromo Militar de Poyensa el III Encuentro Internacional de Hidroaviones. El Ejército del Aire estuvo representado por aviones apagafuegos del 43 Grupo, la Patrulla Acrobática Paracaidista (PAPEA) y helicópteros del Ala 4. El Gabinete del JEMA ha publicado un vídeo con algunas de las actuaciones de las unidades del Ejército
Curiosamente, el domingo al medio día vi alguno de los hidroaviones en ruta hacía su base de origen sobrevolar Benicassim.
Cuando se está compilando un programa, puede que sea necesario compilar varios ficheros para crear una librería estática que se utilizará para enlazar su contenido con varios ejecutables, aunque posteriormente, dicha librería no se instalará en el sistema. El sistema de autotools tiene una serie de macros que permiten realizar esta labor con una pequeña configuración.
Para empezar, es necesario que el fichero configure.ac incluya la macro AC_PROG_RANLIB:
1 dnl Esto es un comentario
2 dnl Esta macro fuerza a una versión mínima de autoconf
3 AC_PREREQ([2.59])
4 AC_INIT([tut4],[1.0],[cterron@users.sourceforge.net],[tut4.tar.gz],[https://sourceforge.net/p/autotutorial/])
5 dnl Necesitamos el compilador de C
6 AC_CONFIG_HEADERS([config.h])
7 AC_PROG_CC
8 AC_PROG_RANLIB
9 dnl Init automake
10 AM_INIT_AUTOMAKE
11 dnl Debe de ir al final de la plantilla. Genera el fichero config.status
12 AC_CONFIG_FILES([Makefile])
13 AC_OUTPUT
Ahora supongamos que se quiere crear la librería libtest.a que vamos a enlazar para generar el fichero tut4. La librería se generará a partir de los ficheros de código fuente test1.c, test2.c y test3.c. Las macros que utilizaremos en el fichero Makefile.am permitirán que se genere toda la lógica que permite la compilación de la librería. Veamos un fichero de ejemplo:
1 bin_PROGRAMS= tut4
2 tut4_SOURCES = tut4.c
3 # Creación de la librería
4 noinst_LIBRARIES = libtest.a
5 libtest_a_SOURCES = test1.c test2.c test3.c
6 libtest_a_CFLAGS = -DTEST="Defined"
7 tut4_LDADD = libtest.a
La primera macro es la que define la librería que se quiere crear noinst_LIBRARIES, definiendo el nombre de la librería que se quiere crear. Si esta librería es libtest.a, los prefijos que se va a usar para definir las fuentes y los flags serán libtest_a_ . Se añade la librería al binario que le va a utilizar con nombre_binario_LDADD.
Como el resto de la serie, el código se puede encontrar en repositorio autotutorial, en SourceForge.
Esta es la segunda de una serie de entradas donde quiero describir la configuración de las redes que utiliza VMware Fusion
Fusion tienen tres mecanismos para virtualizar las redes.
Cuando se instala por primera vez, Fusion va a crear dos interfaces virtuales, vmnet1 y vmnet8. vmnet1 es la intefaz host only, es una red que no se ve fuera del entorno de virtualización. Varias máquinas conectadas a esta red se verán entre ellas y con la configuración por defecto, con el Mac. vmnet8 es la intefaz NAT que por defecto configura Fusion. Las máquinas conectadas a esta red, por defecto podrán conectarse a otras redes a través de los mecanismos del NAT.
¿Dónde están los diferentes ejecutables de los procesos que he mencionado anteriormente?. Bien, como muchos programas de MacOS X , son un Bundle, es decir un directorio que agrupa un conjunto de recursos, entre otros los ejecutables de los programas. Por defecto, Fusion se instala en el directorio /Applications/VMware Fusion.app. Dentro del mismo, en la ruta Contents/Library nos encontraremos los diversos ejecutables usados para implementar las diferentes funciones del producto. Para el funcionamiento de las interfaces de redes los ejecutables que nos interesan serán vmnet-cli y vmnet-cli.
En la versión 6.x Fusion almacena sus archivos de configuración en el directorio /Library/Preferences/VMware Fusion. De los ficheros que hay en el mismo nos interesará a la hora de configurar la red el fichero networking que es una plantilla a partir de la cual se generarán la información que se almacena en los directorios vmnet* con la configuración de las interfaces. Dentro de cada directorio, existirá un fichero de configuración de dhcp , dhcpd.conf que será utilizado para proveer las direcciones en cada una de las subredes virtuales que se creen. Si además existe NAT en la red, existirá un fichero nat.conf con la configuración de la misma. Estos ficheros de configuración son usados por los procesos de Fusion para poder dar servicio sobre las redes virtuales.
Las interefaces virtuales sólo están presentes en el sistema cuando está ejecutándose el proceso de Fusion. Esto puede comprobarse con la ayuda del programa ifconfig -a , donde veremos interfaces llamadas vmnet1, vmnet8 por defecto si está en funcionamiento.
Una de las primeras tareas de configuración que se pueden plantear en este entorno es cambiar el direccionamiento de las redes que utiliza por defecto Fusion para su intefaz vmnet1, aquella que sólo da conectividad entre las máquinas conectadas a él. Por ejemplo, en mi sistema, si arranco Fusion y en el mac utilizo el ifconfig para ver su configuración:
baldurgate:VMware Fusion root$ifconfig vmnet1
vmnet1: flags=8863
ether 00:50:56:c0:00:01
inet 192.168.159.1 netmask 0xffffff00 broadcast 192.168.159.255
La red utiliza el direccionamiento 192.168.159.0/24 para proveer direcciones. Supongamos que se quiere configurar usando el direccionamiento 192.168.100.0/24. La manera más sencilla es editar la plantilla /Library/Preferences/VMware Fusion/networking para que utilice dicho rango de direcciones y hacer que el propio Fusion reescriba los ficheros dentro del directorio vmnet1 con ayuda del programa vmnet-cli. Posteriormente reiniciamos usando este mismo programa los procesos encargados de dar soporte a la red virtual. Si se edita la plantilla la sección que nos interesa es esta:
answer VNET_1_DHCP yes
answer VNET_1_DHCP_CFG_HASH 5E190C04568D690AE581FDFE8FF0B201744BF181
answer VNET_1_HOSTONLY_NETMASK 255.255.255.0
answer VNET_1_HOSTONLY_SUBNET 192.168.159.0
answer VNET_1_VIRTUAL_ADAPTER yes
Cambiándose por
answer VNET_1_DHCP yes
answer VNET_1_DHCP_CFG_HASH 5E190C04568D690AE581FDFE8FF0B201744BF181
answer VNET_1_HOSTONLY_NETMASK 255.255.255.0
answer VNET_1_HOSTONLY_SUBNET 192.168.100.0
answer VNET_1_VIRTUAL_ADAPTER yes
Ahora como root nos vamos al directorio del bundle donde están los programas encargados de configurar la red y ejecutamos las siguientes órdenes:
baldurgate:Library root$pwd
/Applications/VMware Fusion.app/Contents/Library
baldurgate:Library root$./vmnet-cli --configure
Stopped DHCP service on vmnet1
Disabled hostonly virtual adapter on vmnet1
Stopped DHCP service on vmnet8
Stopped NAT service on vmnet8
Disabled hostonly virtual adapter on vmnet8
Stopped all configured services on all networks
Backed up existing network settings to backup file "/tmp/vmware.b74CtC"
Restored network settings
baldurgate:Library root$./vmnet-cli --stop
Stopped all configured services on all networks
baldurgate:Library root$./vmnet-cli --start
Enabled hostonly virtual adapter on vmnet1
Started DHCP service on vmnet1
Started NAT service on vmnet8
Enabled hostonly virtual adapter on vmnet8
Started DHCP service on vmnet8
Started all configured services on all networks
He añadido la orden pwd para que se vea el directorio del sistema desde donde se están ejecutando las órdenes. Ahora se puede comprobar con ifconfig que se ha cambiado correctamente la interfaz
baldurgate:VMware Fusion root$ifconfig vmnet1
vmnet1: flags=8863
ether 00:50:56:c0:00:01
inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.159.255
Es interesante ver el fichero de configuración para la interfaz vmnet1 que ha generado el sistema. El fichero dhcpd.conf es un fichero de configuración para el servidor de dhcp del ISC. Asigna el rango de direcciones de DHCP que van a recibir las máquinas que se conecten a dicha interfaz y deja configurada la primera direccion fija para que la use el Mac para conectarse con las máquinas virtuales que tengan interfaces en esa red.