Don’t set Jetty’s <stopPort> to the same <port> where Jetty is running or you might run into some nasty-hard-to-debug problem.

Now a full explanation:

Imagine the following scenario,

Here we have to web services, A and B, both running on the same machine on Jetty webserver and one of them is listening for petitions on port 9090 (configured via de maven-jetty-plugin). Web service A has to request some data to B and process its reply. Nothing unusual.

So A issue a request to http://localhost:9090/<path> expecting an XML response as a result of doing it. But it gets nothing, nada, nichts.

Well, at this moment the first thing that came through my mind was that I did something wrong while coding or configurating any of the web services. So I checked everything, but it seemed right. My next move was to create a fake request with curl just to see what happened.

What happened misleaded me even more: web service B was responding. WTF!!

So I went one level down. I ran tcpdump. And what I got? I discovered that the main difference between the requests issued by web service A and curl was the ip version they used: web service A was using ipv4 and curl ipv6.

To force both requests (from the web service and curl) to use ipv4, I run curl against the web service B but now instead of localhost I used 127.0.0.1. And the response was empty, just like if the request came from web service A.

So I thought that all of my troubles had to do with the ip stack beeing used. And I wasted some hours
trying to figure out what was wrong with it.
As I was really desperate with all this, I download Jetty sources to debug it on eclipse. I wanted to know
what was happening with my requests. And here was were light came to me by chance. While debugging Jetty,
an incomming connection from  internet arraived to my <public_ip>:9090  (I guess it was someone doing some kind of portscanning) and got stuck on my breakpoints…

Mmmm, wait a moment…

Yep, internet addresses are ipv4 only (for most of us), so this ruled out any kind of problem with the ipv4 stack or shit. Now I began to see the light. This was some mess with the adresses.

Just to check I did an alias in my loopback interface to 127.0.0.2 and run again the request with curl to that ip. This time being successful. Ooook.

So, whats wrong with 127.0.0.1:9090?

Netstat output,

13:29:46 ~ $ netstat -f inet -an
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp4       0      0  127.0.0.1.9090         *.*                    LISTEN
tcp46      0      0  *.9090                 *.*                    LISTEN
...

Lsof output,

13:49:39 ~ $ lsof -i :9090
COMMAND PID     USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
java    239 madtrick   94u  IPv6 0x08c10f80      0t0  TCP *:websm (LISTEN)
java    239 madtrick   95u  IPv6 0x08c11460      0t0  TCP [::127.0.0.1]:websm (LISTEN)

I have two sockets listening on port 9090 and both belong to the same process (as reported by lsof), my Jetty Server.  But requests to 127.0.0.1:9090 are lost meanwhile requests to <any_other_ip>:9090 are processed by the server.

Lets try something, lets change the <stopPort> to 9091 and see what happens…
Request from web service A, OK.
Request from curl, OK.

Run netstat again,

13:59:50 ~ $ netstat -f inet -an
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp4       0      0  127.0.0.1.9091         *.*                    LISTEN
tcp46      0      0  *.9090                 *.*                    LISTEN
...

And lsof for ports 9090 and 9091,

14:00:48 ~ $ lsof -i :9090
COMMAND PID     USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
java    301 madtrick   93u  IPv6 0x08c10f80      0t0  TCP *:websm (LISTEN)

14:00:55 ~ $ lsof -i :9091
COMMAND PID     USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
java    301 madtrick   94u  IPv6 0x08c11460      0t0  TCP [::127.0.0.1]:xmltec-xmlmail (LISTEN)

So you see, Jetty opens another socket which listens on 127.0.0.1:<stopPort>  (lets call it jetty stop daemon) and being that an explicit address it has precedence over the catch all 0.0.0.0:9090 (where Jetty is listening). That’s why my requests to 127.0.0.1:9090 returned nothing.

This is what was happening before,

And this is whats happens now,

BOSH, the technology defined in this specification, essentially provides a “drop-in” alternative to a long-lived, bidirectional TCP connection …

For applications that require both “push” and “pull” semantics, BOSH is significantly more bandwidth-efficient and responsive than most other bidirectional HTTP-based transport protocols and the techniques now commonly known as “Ajax”…

That is, BOSH is quite similar to WebSockets

So, at this point is where mochiweb comes in. It will provide the framework for handling the HTTP requests where the BOSH requests themselves are wrapped. But before going any further lets explain how mochiweb works, with a picture:

What do we have here?

1. An HTTP request comes in, to the address and port mochiweb is configured.
2. If it’s a valid HTTP request, a mochiweb_request “object” is created and the handler function at the callback module (which is provided when mochiweb starts) is invoked with this mochiweb_request as a parameter. Give a look to this and this to get a grasp at parameterized modules if you wish to know more about “objects” on Erlang.

Easy, huh?

And what is all that about a BOSH manager? The BOSH manager handles the connection between the resource-client (for example a browser) and the resource-owner (for example a server). It has to keep HTTP connections opened to fake this bidirectional comunication. That is, the client ask for something about the resource and so it sends a request to the BOSH manager, the BOSH manager sends this same request to the server and waits for a reply. If a reply arrives, then it’s forwarded to the client. But aside from this, which is no more than plain-old AJAX, BOSH offers PUSH technologies. If any event happens at the server and the client has to be notified, the BOSH manager forwards the event to the client. That’s why it has to keep HTTP connections opened, it must have a valid path.

In Erlang, creating and destroying processes is extremely cheap, so what I wanted was  to spawn a new process for each single BOSH session (between one client and one or multiple servers). Lets give another picture:

On the picture above, there are two separate BOSH managers (each of them is a Erlang process) BM1 and BM2 which handler connections from one client to one server (BM1 ) and from another different client to two servers (BM2)

To complete the setup I used, I have to talk about StropheJS which is a library for writing xmpp clients (BOSH is an xmpp extension).

Well, once I have explained more or less what I’m doing with mochiweb and BOSH, lets got to the details.

First, lets talk about my callback module for mochiweb. It’s not a ver big one nor a complicated one, not because I don’t know how to move on but was the error I’ll talk later which didn’t allow me to progress. So ladys and gentleman here is my litle callback module:

-module(mochibosh).

-export([start/0, start/1, stop/0]).
-export([handler/1]).

-export([init/0]).

-record(mochibosh_state,{procs, xml_models}).

handler(Req) ->
 io:format("CALLBACK. Petition on port ~p  ~n", [inet:port(Req:get(socket))]),
 mochibosh ! Req,
 ok.

start() ->
 erlang:register(mochibosh, spawn_link(?MODULE, init, [])),
 start([{ip,"192.168.1.110"}, {port, 8888}]).

start(Options) ->
 Options2 = [{loop, {?MODULE, handler}} | Options],
 mochiweb_http:start(Options2).

stop() ->
 mochibosh ! exit,
 mochiweb_http:stop().

% Internal API

init() ->
 Models = init_xml_models(),
 loop(#mochibosh_state{procs = dict:new(), xml_models = Models}).

loop(State = #mochibosh_state{procs = Procs, xml_models = Models}) ->
 receive
 Request ->
 io:format("SPAWNED PROCESS. Request received on port ~p ~n", [inet:port(Request:get(socket))]),
 loop(State)
 end.

init_xml_models()->
 [{bosh_init, init_xml_model("bosh_init.xsd")}].

init_xml_model(Xsdfile) ->
 {ok, Model} = erlsom:compile_xsd_file(Xsdfile),
 Model.

It very easy. If want to use it, you cant fire a Erlang terminal and type mochibosh:start() and it will be up and running. The loop
option in the tuple that is passed to mochiweb_http:start is used to provide the callback module. In this case is the mochibosh module itself (?MODULE)

So what would happen if we try it….

In one terminal we fire the Erlang shell (erl) and start mochibosh:

20:38:25 mochibosh $ erl
Erlang R14A (erts-5.8) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.8  (abort with ^G)
1> mochibosh:start().
{ok,<0.34.0>}

In another terminal we issue a simple request with curl…

20:40:19 mochibosh $ curl -v http://192.168.1.110:8888
* About to connect() to 192.168.1.110 port 8888 (#0)
*   Trying 192.168.1.110... connected
* Connected to 192.168.1.110 (192.168.1.110) port 8888 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.21.0 (i386-apple-darwin10.2.0) libcurl/7.21.0 OpenSSL/1.0.0a zlib/1.2.5 libidn/1.19
> Host: 192.168.1.110:8888
> Accept: */*
>
^C

And meanwhile in the Erlang shell..

{ok,<0.34.0>}
CALLBACK. Petition on port {ok,8888}
SPAWNED PROCESS. Request received on port {ok,8888}

2>

GREAT!! Everything seems to work. So now, I decided to move on and begin to develop my BOSH manager.

As I sayed, I’ll be using StropheJS for the browser/client side. For testing purpouses I began using one of the examples shipped with the library: echobot.js .This example will issue a request for starting a BOSH session (among other things) and that is perfect for my testing pourposes. So lets, try.

(Imagin that the request is sent from echobot to the BOSH manager)

And I expecto to get the same reply from my callback module as when I tryed it with curl. Lets see:

CALLBACK. Petition on port {ok,8888}
SPAWNED PROCESS. Request received on port {error,einval}

WTF!!!!! What’s that of {error, einval}. Well, I can see that’s an error, but why? As this post is getting really big, I’ll leave the explanation for another one.

1. I installed this on a MacBook with a CoreDuo processor. By default macports will try to use all avaliable processors for the building stuff (2 on my case) with the -j option of Make. On my case this ended up with weird compilation errors (something like a race condition between the to make jobs). I fixed it setting the buildmakejobs to 1 (at /opt/etc/macports/macports.conf) so it used just one make job
2. The Makefile rule for the documentation at <package>/support/include.mk is wrong. The function that make should call at the edoc module is files/3 not file as it’s deprecated.

Enjoy!!

Por defecto, IRB siempre “escupirá” el valor resultante de evaluar la expresión introducida por el usuario. Aunque la mayoría de las veces eso está bien, hay otras en las que sacarias el corazón con una cucharilla de Té  a quien tuvieras delante por la crispación que produce esta “verbosidad”.

Me refiero a situaciones del tipo “quiero recorrer un array y listar el nombre de sus elementos con puts”, ejemplo:

ArrayEnorme.each do |element| puts "#{element.name}\n" end

Con el código anterior vamos a mostrar el nombre de cada elemento del Array. Hasta aquí todo normal. El problema de evaluar esto en IRB es que, si ArrayEnorme tiene bastantes elementos y cada elemento tiene bastantes atributos, las lineas que imprimos con el nombre de cada elemento quedaran “sepultadas” por un montón de datos inutiles. Es decir, si el buffer de nuestra consola no se ha llenado con estos datos inutiles (perdiendo así las lineas con el nombre de cada elemento) tendremos que hacer scroll ad-infinitum, que para el caso es casí como si se hubierán perdido.

Para evitar esto, os presento mi solución de andar por casa:

def toggle_output
context.return_format == "Output canceled\n" ? IRB.conf[:PROMPT][context.prompt_mode][:RETURN] : context.return_format = "Output canceled\n"
end

alias tgo toggle_output

Después de copiar las lineas anteriores en nuestro .irbrc podemos hacer pruebas:

madtrick::madtrick::$irb
irb(main):001:0> 2 + 1
=> 3
irb(main):002:0> toggle_output
Output canceled
irb(main):003:0> 2 + 1
Output canceled
irb(main):004:0> toggle_output
=> "=> %s\n"
irb(main):005:0> 2 + 1
=> 3

Y voila, ya podemos callar y dar voz a IRB cuando nos plazca.

El concepto que implementa sketches es sencillo: las modificicaciones que hagamos en nuestro editor de texto, se reflejan al instante en la sesión de irb. Es decir, si en el editor de texto creamos una clase y guardamos los cambios, la clase estará disponible automaticamente en la sesión de irb.

Su utilización es sencilla: arrancamos el IRB y lanzamos nuestro editor favorito con el comando sketch. A partir de ahí, el funcionamiento es como expliqué antes.

Mola : )

En el rdoc nos encontramos con la siguiente definición:

callcc {|cont| block } => obj

Generates a Continuation object, which it passes to the associated block. Performing a cont.call will cause the callcc to return (as will falling through the end of the block). The value returned by the callcc is the value of the block, or the value passed to cont.call. See class Continuation for more details. Also see Kernel::throw for an alternative mechanism for unwinding a call stack.

Un tanto críptico, ¿No?. Basicamente, callcc almacena la dirección de memoria y el contexto (en un objeto Continuation) de donde se le llamo. Sigue siendo raro,¿No?

Mejor un ejemplo. Sea el siguiente metodo:

 
counter = 0
 
def foo
exit if callcc{|$cont| } == 3
puts "hello world"
end
 
foo
 
$cont.call(counter += 1)

(Si ya se que las variables globales son malignas : ( )

Ejecutando el ejemplo:

madtrick::madtrick::$ruby test3.rb
hello world
hello world
hello world

Como se puede apreciar, se imprimen tres “hello world” con sólo una llamada al método foo.

¿Qué podemos extraer del ejemplo anterior?

• Cada llamada a la continuación ($cont) nos vuelve a llevar a linea donde se definió.
• Si en la llamada a la continuación pasamos algun parámetro, este es devuelto por callcc

Tambien podríamos utilizar los ejemplos del post anterior (Tail Call Optimization) para explicar el funcionamiento de callcc:

Calculo del factorial de un número:

class TCOTest
  # tail-recursive factorial
  def fact( n, acc = 1 )
    if n < 2 then
      acc
    else
       fact( n-1, n*acc ) 
    end
  end
 
  def fact_cc( n, acc = 1 )
    cont = callcc{|cont| cont}
    if n < 2 then
      acc
    else
       n, acc = n-1, n*acc
       cont.call cont 
    end
  end
 
  # length of factorial
  def fact_size( n )
    fact( n ).size
  rescue
    $!
  end
 
 
  # length of factorial
  def fact_size_cc( n )
    fact_cc( n ).size
  rescue
    $!
  end  
end

Si lo probamos en el irb vemos que fact_size_cc no da ningún tipo de problema mientras que la función fact_size (sí, por carecer Ruby de TCO) ya que nos quedamos sin espacio en la stack.

...
irb(main):009:0> t.fact_size 10000
=> #<SystemStackError: stack level too deep>
irb(main):010:0> t.fact_size_cc 10000
=> 14808

El otro ejemplo del post anterior, la función de Fibonacci:

En el ejemplo anterior, utilizábamos la palabra reservada redo junto con un método definido ad-hoc para poder realizar el cálculo:

  define_method(:acc) do |i, n, result|
    if i == -1
      result
    else
      i, n, result = i - 1, n + result, n
      redo
    end
 
def fib_redo(i)
   acc i,1,0
end

Pero tambien se podria haber hecho de esta otra forma:

def fib_call_cc(i, n = 1, result = 0)
  cont = callcc{|cont| cont}
  if i == -1
    result
  else
    i, n, result = i - 1, n + result, n
    cont.call cont
  end
end

En el ejemplo anterior se puede apreciar como el contexto se mantiene. En este caso para los valores i,n y result.

Si ejecutamos un simple benchmark (para n en 50000) para comparar redo vs callcc, obtenemos los siguiente:

 
madtrick::madtrick::$ruby test.rb 
Time for fib_redo:      0.390000   0.010000   0.400000 (  0.403986)
Time for fib_call_cc:   0.500000   0.000000   0.500000 (  0.519504)

redo ( 0.403986) es un poco más rápido que callcc ( 0.519504). Echándole un vistazo rapido al codigo de la máquina virtual de Ruby se entiende rápidamente el porque. redo esta implentado utilizando goto’s mientras que callcc es una llamada a una función que se encarga de guardar toda la información necesaria en un objeto Continuation, por lo que necesita más tiempo.

Para mas información sobre callcc, su funcionamiento y los continuations:

• Continuations
• Callcc
• Setjmp/longjmp, funciones en C con las que se puede implementar un comportamiento similar

En esta pagina lo explican bastante bien (entre otros tipos de recursividad), pero basicamente una función tail-recursive es aquella que no tiene ninguna operación pendiente de ejecutar tras la llamada recursiva. En estas funciones, la llamada recursiva puede ser substituida simplemente por un salto al comienzo de la función que se llama, con lo que se ahorra espacio en el stack. De esto ultimo se encarga el compilador y es lo que se conoce como Tail Call Optimization (TCO a partir de ahora).

Así que aparentemente la TCO mola, ¿No?

El problema es que Ruby no tiene implementada TCO en su maquina virtual con lo que independientemente de como estructuremos nuestras funciones recursivas, siempre estaremos limitados por el tamaño de nuestra Stack.

Pero siempre hay solución para todo y con Ruby, más. En ésta página dan dos soluciones para tener una pseudo-TCO.

Copio y pego la primera solución:

class Class
  # Sweet stuff!
  def tailcall_optimize( *methods )
    methods.each do |meth|
      org = instance_method( meth )
      define_method( meth ) do |*args|
        if Thread.current[ meth ]
          throw( :recurse, args )
        else
          Thread.current[ meth ] = org.bind( self )
          result = catch( :done ) do
            loop do
              args = catch( :recurse ) do
                throw( :done, Thread.current[ meth ].call( *args ) )
              end
            end
          end
          Thread.current[ meth ] = nil
          result
        end
      end
    end
  end
end
 
class TCOTest
  # tail-recursive factorial
  def fact( n, acc = 1 )
    if n < 2 then acc else fact( n-1, n*acc ) end
  end
 
  # length of factorial
  def fact_size( n )
    fact( n ).size
  rescue
    $!
  end   
end
 
t = TCOTest.new
 
# normal method
puts t.fact_size( 10000 )  # => stack level too deep
 
# enable tail-call optimization
class TCOTest
  tailcall_optimize :fact
end
 
# tail-call optimized method
puts t.fact_size( 10000 )  # => 14808

Esta solución consiste en jugar con catch’s,throw’s y Thread.current para relanzar el mismo método una y otra vez sin tener que crear un nuevo frame en el Stack, ya que el codigo del metodo se encuentra definido en un bloque y por tanto reutiliza el codigo.

La segunda opción:

def fib(i, n = 1, result = 0)
  if i == -1
    result
  else
    i, n, result = i - 1, n + result, n
    redo
  end
end
 
fib(10000)

Esta solución consiste en hacer uso de la palabra redo la cual reinicia la ejecución de cualquier loop o iterador. El problema con redo es que, como acabo de decir, solo se puede utilizar en loops o iteradores y el método fib anterior no es ninguno de ellos. Por lo que el autor de la página de que se extrajeron las soluciones dice:

Unfortunately, “The redo statement restarts the current iteration of a loop or iterator”, so it only throws a LocalJumpError

Gracias señor espartano.

Así es, esto es Ruby y siempre hay un workaround para todo. En este caso, consiste en crear un nuevo método cuyo cuerpo este contenido en un bloque.

define_method(:acc) do |i, n, result|
  if i == -1
    result
  else
    i, n, result = i - 1, n + result, n
    redo
  end
end
 
def fib(i)
  acc(i, 1, 0)
end
 
fib(10000)  # Yeah!

Y ya podemos utilizar redo. Fin!!

Para mas información, hay un thread en esta lista de correo en el que debaten sobre este tema: Ruby tail recursion.

• Paso 1 : Abrir en un editor el fichero handler.rb perteneciente a la gema starling-starling.
• Paso 2 : En el método Handler#set_data añadir la siguiente linea justo antes de hacer el pack para generar la variable internal_data.

  ...
  expiry = Time.now.to_i + expiry.to_i unless expiry.to_i == 0
  ...

• Paso 3 : Guarda y re-arranca el starling.Todo debería de ir como la seda.

Con esto, lo único que hemos hecho es corregir un pequeño bug que hay en Handler#get ya que en este método solo se devuelve un mensaje si su expiry es 0 o si expiry es mayor que now (now en este contexto es Time.now.to_i ). El fallo viene de comparar a now (valor unix time) con expiry el cual es solo un offset desde el momento en el que decidimos guardar un mensaje en starling.

  ...
  break if expiry == 0 || expiry >= now
 
  @expiry_stats[key] += 1
  expiry, data = nil
  ...

Con la linea que añadimos al método Handler#set_data forzamos que la comparación sea entre dos valores unix time.Uno refiriéndose al momento actual (now) y otro al momento en el que expirara el mensaje (la suma de Time.now.to_i en el momento del almacenarlo y el tiempo de vida del mensaje).

Tenemos que hacer push’es y pull’es a un repositorio git (mediante ssh).

Sencillo, ¿no?.Ahora tengamos en cuenta las siguientes consideraciones:

1. Estas operaciones las vamos a realizar tanto desde nuestra casa (a través de internet) como desde la red donde se encuentra el repositorio, siendo la dirección del repositorio – git.frusfrusfrus.net, la misma en ambos casos.
2. Por culpa de las hadas y de los proxies reversos, si las operaciones la realizamos desde casa el puerto sera el 2280 mientras que si las operaciones las realizamos desde la oficina el puerto será el 22.
3. Queremos que cualquier tipo de cambio en la configuración sea automático

La consideración tres es el motivo de este post, ya que la dos (la unica que plantea algún problema) se podria resolver con un parámetro en la linea de comandos.Es más cómodo  no tener que preocuparse ni de donde estamos, ni tener que acordarse de como era la estructura del comando.

Mi primera opción fue la de crear un script que se ejecutase cada vez que encendiera el ordenador, para lo cual ya le habia hechado un vistazo a esta documentación. Pero como David tuvo bien a decirme, quizás seria mejor hacerlo siempre que la interfaz de red se levantara.Realmente esto está mucho mejor ya que cubria un abanico de opciones más amplio (volver de hibernación, desactivar y activar de nuevo la tarjeta de red…) que la idea de crear  un Startup item.

¿Y como co%&o se yo cuando se levanta o se cae una interfaz de red en Mac OS X?

…google…google…google…google

Resulta que en Mac OS X  la gestión de las interfaces de red (entre otras muchas más cosas) las lleva un demonio: configd. Este demonio monitoriza el siguiente fichero, /Library/Preferences/SystemConfiguration/preferences.plist. Configd reacciona ante cualquier cambio que se refleje en este fichero, derivando a quien corresponda  la tarea de manejar el evento.

Si el evento tiene que ver con la red del sistema, configd hace entrar en juego al  Kicker.bundle – que se puede encontrar en /System/library/SystemConfiguration/Kicker.bundle.Lo interesante de este bundle es su fichero de configuración: Kicker.xml en el cual se especifica ante que eventos reaccionar y lo que es más importante, como.

Este es mi fichero Kicker.xml original

<pre lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
	<dict>
		<key>execCommand</key>
		<string>$BUNDLE/Contents/Resources/enable-network</string>
		<key>execUID</key>
		<integer>0</integer>
		<key>keys</key>
		<array>
			<string>State:/Network/Global/IPv4</string>
		</array>
		<key>name</key>
		<string>enable-network</string>
	</dict>
 
	<dict>
		<key>keys</key>
		<array>
			<string>State:/Network/Global/DNS</string>
			<string>State:/Network/Global/IPv4</string>
			<string>State:/Network/Global/IPv6</string>
			<string>State:/Network/Global/NetInfo</string>
		</array>
		<key>name</key>
		<string>network_change</string>
		<key>postName</key>
		<string>com.apple.system.config.network_change</string>
	</dict>
	<dict>
		<key>execCommand</key>
		<string>/usr/sbin/AppleFileServer</string>
		<key>execUID</key>
		<integer>0</integer>
		<key>keys</key>
		<array>
			<string>daemon:AppleFileServer</string>
		</array>
		<key>name</key>
		<string>AppleFileServer</string>
	</dict>
</array>
</plist>

La primera sección dict , indica que se debe de ejecutar el script enable-network cada vez que se reciba un evento de tipo State:/Network/Global/IPv4 lo cual puede indicar que la interfaz se levantó y ha obtenido una ip, que se ha realizado un cambio de ip, que la interfaz se ha desconectado…etc.

La segunda sección dict indica que ante todos esos eventos : State:/Network/Global/IPv4 , State:/Network/Global/IPv6 … se va a emitir una notificación con el nombre com.apple.system.config.network_change.Decir que principalmente quien hará uso de este notificación sera lookupd, como se puede observar en este extracto del sytem.log:

Feb 26 17:36:52 madtrick configd[39]: posting notification com.apple.system.config.network_change
Feb 26 17:36:52 madtrick lookupd[538]: lookupd (version 369.8) starting - Thu Feb 26 17:36:52 2009
...
Feb 26 19:46:16 madtrick configd[39]: posting notification com.apple.system.config.network_change
Feb 26 19:46:16 madtrick lookupd[667]: lookupd (version 369.8) starting - Thu Feb 26 19:46:16 2009

La tercera y ultima sección no es relevante a lo que estamos hablando, así que nada que comentar.

Bien.Llegados a este punto se me plantean dos opciones:

• Primera. Crear una nueva entrada en el fichero Kicker.xml para que un script se ejecute ante cualquier evento de tipo  State:/Network/Global/IPv4.
• Segunda. Capturar la notificacion com.apple.system.config.network_change y actuar en consecuencia.

Aparentemente la más interesante es la segunda.Es menos intrusiva y mas versatil,peeero tambien bastante mas complicada de afrontar de primeras.Por ello queda aplazada a la espera de que algún dia decida leer esto y  me plantee hacerlo.

Así que nos queda la primera opcion, ejecutar un script ante cada evento.

OJO: ANTES DE EDITAR Kicker.xml, HAZ UNA COPIA DE SEGURIDAD

Asi que nos ponemos manos a la obra y añadimos la siguiente sección dict al fichero Kicker.xml

	<dict>
		<key>execCommand</key>
		<string>/usr/bin/ssh-config</string>
		<key>execUID</key>
		<integer>501</integer>
		<key>keys</key>
		<array>
		<string>State:/Network/Global/IPv4</string>
		</array>
		<key>name</key>
		<string>ssh-config</string>
	</dict>

Donde /usr/bin/ssh-config es el script que se ejecutara ante cada cambio que afecte a la pila IPv4.

Para que los cambios tengan efecto, necesitamos matar el demonio configd y luego volver a levantarlo.

madtrick::madtrick::$sudo killall configd
madtrick::madtrick::$sudo configd
madtrick::madtrick::$ps aux | grep [c]onfigd

Nota:

Una par de ocasiones en las que realicé estas operaciones sobre configd la terminal se quedo “frita” y el ordenador no queria reiniciarse correctamente.

En otra, system.log indicaba (algo que no se, solo supongo) que se desactivaba la ejecucion del script  enable-network y ssh-config, motivando que cualquier cambio sobre las interfaces de red, no se viera reflejado en la ejecución de estos scripts

Feb 26 13:36:53 madtrick configd[4698]: posting notification com.apple.system.config.network_change
Feb 26 13:36:53 madtrick lookupd[4707]: lookupd (version 369.8) starting - Thu Feb 26 13:36:53 2009
Feb 26 13:36:53 madtrick configd[4698]:   target=enable-network: disabled

Desde mi punto de vista, considero esto normal ya que configd es un componente esencial para el correcto funcionamiento del sistema, por ello cualquier alteración en su funcionamiento (matarlo es un cambio bastante importante, ¿no?) es más que probable que derive en inestabilidad en el sistema.

Llegados a este punto, solo nos queda reiniciar el ordenador (por eso de no jugar mas con configd) y comprobar que nuestro script se ejecuta correctamente.

Por si alguien le interesa el script ssh-config , aqui esta.Lo unico que hace este script es cambiar el puerto para el host git.frusfrusfrus.net de 22 a 2280 o de 2280 a 22 dependiendo de si estoy trabajando desde la red donde se encuentra el repo  o desde casa, respectivamente.

Para terminar, aqui dejo una lista de los enlaces que me fueron utiles.

Networking on OS X

OS X: How to perform an action during fast user switch