• Author: guille
  • Published: Jan 30th, 2007
  • Comments: None

Dried tomatoes: The sun at home on rainy days

tomatesDried tomatoes are one of the typical Italian ingredients. They are delicious with a large array of dishes: pasta sauce, salads, sandwiches,…

They are also one of the easiest recipes to do. Just take tomatoes, cut them in four, sprinkle some salt and leave them on a long, hot, dry and sunny day. Does it sound like summer in Madrid? It does. If you have a flat roof, of course.

One of the problems I have at the moment is:

  • I don’t have a flat roof.
  • I don’t have a long, hot, dry and sunny day. It’s indeed winter.

Alternative solutions had then to be found. I actually found one. Among many others.

The solution, as many might have guessed already, is to use an oven. Not very ecological, but a good point is, it’s a fire-and-forget recipe. I love those, as I don’t have often the time to cook properly (lately, I do not have the time at all…).

For the many people that are not able to speak french, I will add here here the recipe, as well as my experiences. 

Ingredients:

  • A dozen tomatoes
  • 2 teaspoons of salt
  • 2 teaspoons of sugar
  • Some cooking salt
  • Some thyme and rosemary (or whatever you want: marjoram,…)

Recipe:

  1. Cut the tomatoes in 4 pieces. Add salt and let soak for at least 30 minutes.
  2. Preheat the oven at 100ºC.
  3. Put the tomatoes over an anti-adherent paper (or aluminium paper) and sprinkle with the cooking salt and the herbs.
  4. Cook for 2 hours. Turn the tomatoes as needed and cook for an additional 2 or 3 hours until done.
  5. Put in a previously sterilized can and cover with good quality olive oil.

Notes:

  • Try to turn the tomato on its three sides: with the skin under, and its two sides. Try to finish with the side that has the skin under.
  • If you are in a hurry, increase the oven to 120-130ºC. If you increase it more, take care not to burn the tomatoes. The quality will be lower though.
  • Be patient, the tomatoes should be completely dried before canning them!
  • The oven consumes a lot of energy. Do as many tomatoes as you can at the same time. They last long, so let’s save as much energy as possible. Of course, if you can use the sun to dry, it’s even better.
  • This recipe can be made with different kind of tomatoes, from the Italian variety to the cherry tomatoes.
  • Don’t forget to use the tomato flavored oil afterwards!
  • Wait one week before consumption, the oil needs time to get the aromas.

That’s it. Now it’s time to enjoy the result!

  • Author: guille
  • Published: Jan 22nd, 2007
  • Comments: None

Restaurante hindú: Moharaj

rajasthani_menMe gusta todo tipo de cocinas, pero entre todas he de destacar las cocinas asiáticas. Probablemente el hecho de que mi pareja sea japonesa es una de las razones, pero incluso antes de conocerla los aromas y delicias asiáticas me apasionaban. De hecho, una de mis respuestas preferidas a “¿Te gusta el curry?” a sido siempre “¿Cual de todos? ¿El indio, indonesio, chino, japonés, tailandés,…?”.

Naturalmente, y por mucho que exista en muchos paises, el rey incontestado del curry (al menos en el imaginario colectivo) ha sido siempre India. Finalmente, la comida India se basa principalmente en el curry. Y el curry, no siendo más que una mezcla de especias, da lugar a una variedad casi infinita de aromas y sabores.

Comprenderá el lector entonces mi insistencia por visitar ese restaurante del que me hablaba mi amigo Alejandro desde hacía tiempo, ese restaurante que era BBB (Bueno, Bonito y Barato). Tras mucho tiempo y muchos esfuerzo le convencí, y fuimos tres parejas.

Lo primero, la dirección (ver mapa):

Moharaj
Restaurante hindú
C/ Buenavista, 42
28012 Madrid
España

Metro Lavapiés

Tel: 91 539 28 29
Tel: 91 528 52 89
Movil: 660 033 141
Movil: 630 745 275
Página web: http://www.moharaj.com/

Hay que tener cuidado porque parece ser que existe otro Moharaj en la calle Ave María, 26, muy cerca del nuestro, pero diferente.

26/07/07: He probado este restaurante y he escrito otra reseña aquí.

Los dueños del restaurante, Abdul y Tipu (o al menos así dicen en su tarjeta de visita), nos reservaron una acogida muy agradable y estuvimos conversando con ellos mientras nos preparaban la mesa (el restaurante estaba lleno y tuvimos que esperar un rato).

Habiendo probado comida india en diferentes lugares del mundo, puedo decir que el menú parece auténtico. Personalmente odio decidir, así que siempre acabo pidiendo a los camareros que nos traigan lo que quieren. En este caso Abdul nos confeccionó un menú variado en el que entraban todo tipo de carnes y verduras, así como diferentes sabores, desde el picante al dulce pasando por sabores más agridulces. Todo esto fue acompañado por diferentes panes y arroces.

La decoración del restaurante es muy básica, un poco cutre pero en ningún caso de mal gusto como se puede ver en algunos lugares donde los elefantes dorados supuéstamente indios no hacen sino insultar a la vista. Los manteles son de papel y los platos de porcelana regular, pero siempre limpios. Pero todo eso no le quita nada al encanto del lugar, dado principalmente por la calidad de la comida y la amabilidad de los camareros.

Desde un punto de vista puramente económico el lugar es imbatible. Pagamos 15€ por persona contando cervezas, comida en abundancia y propina. Y cuando digo comida en abundancia es eso, comida en abundancia, como mis amigos podrán confirmar.

Uno de los puntos positivos de este restaurante (al menos para mí) es que tiene un servicio a domicilio, algo muy cómodo para esas tardes en las que no apetece cocinar.

Para concluir diré que es este uno de esos sitios que merece la pena descubrir, de esos que no
brillan en apariencia pero que dan a menudo la mejor y más auténtica
comida. Personalmente, volveré. Y les llevaré a amigos.

26/07/07: Me he enterado de que van a reformar el local, o al menos la cocina, y que las obras estarán acabadas a partir de Agosto del 2007. Aprovecharán para aumentar la variedad de su menú.

24/09/07: En efecto, han reformado todo el restaurante. Ahora es más amplio y más bonito. Además han mejorado su cocina (ahora tiene horno) y han aumentado su oferta de menú… y el precio, aunque todavía está dentro de lo razonable (40€ para una comida para 2 grandes comilones).

  • Author: guille
  • Published: Jan 21st, 2007
  • Comments: None

Mermelada de tomate y fresones

mermeladaEstamos en la época de los fresones. En estos momentos, estas frutas de sabor intenso y precio variable están en lo mejor de su forma. En efecto, al menos en Madrid, el precio puede variar entre menos de 2€ a más de 5€ el kilo, prácticamente de un día para otro. Así que hay que aprovechar los días de precios bajos para crear reservas. Si posible, reservas que duren mucho mucho tiempo.

¿Cual es la mejor manera de crear reservas, especialmente tratándose de frutas? Pues sí, la mermelada. Así que comentando comentando quedé con Mireia, una amiga valenciana, para hacer no sólo mermelada de fresones, sino también de tomate, una especialidad de su región.

Pero ¿Quién sabe realmente la diferencia entre mermeladas, confituras,…? Así que antes de empezar, unas definiciones:

  • Mermelada: Se hacen con frutas 

    peladas y cortadas, cocidas en azúcar.

  • Confituras: Las frutas estánmenos troceadas que en las mermeladas y su proporción de azúcar

    es superior. Tambíen son mas espesas.

  • Compotas: Son frutas cocidasen almíbar. Se comen frías o calientes.
  • Jalea: Son jugos de frutas con azúcar y agua. Estas suelen llevar gelatina o pectina.

Las recetas que utilizamos fueron las siguientes:

Mermelada de fresones:

2 kg de fresones
1.5 kg de azúcar
1/2 manzana rallada
El zumo de un limón

  1. Se cortan los fresones en trozos no demasiado pequeños (la talla reduce luego).
  2. Se ponen en capas los fresones y el azucar en una cacerola, empezando y acabando con una capa de azucar. Se deja reposar unas horas.
  3. Se mezcla el contenido de la cacerola y se ponen a hervir a fuego muy lento hasta que espese.
  4. Se envasa la mermelada en recipientes previamente esterilizados.

Mermelada de tomate:

2 kg de tomates
1.5 kg de azúcar
1/2 manzana rallada
Dos ramitas de canela
El zumo de un limón y su cáscara

  1. Se ponen los tomates en agua hirviendo cortando una cruz en la
    parte de abajo, se pelan (sí, para eso servía la cruz, para
    facilitarlo) y se les quitan los jugos y las simientes, guardando solo la pulpa.
  2. Se trocea la pulpa o se pasa por el mixer. Las abuelas dicen que
    troceándolo obtiene una textura más agradable. Los vagos decimos que
    con el mixer es más rápido y el sabor no cambia.
  3. Se mezclan todos los ingredientes y se ponen a hervir a fuego muy lento hasta que espesen.
  4. Se envasa la mermelada en recipientes previamente esterilizados.

El experimento salió relativamente bien. A pesar de que tomó bastante tiempo el que espesara la mermelada (especialmente en el caso de la mermelada de tomate) finalmente tomó una textura adecuada.

Algunas notas sobre la elaboración de las mermeladas:

  • En estas mermeladas no se ha utilizado pectina. Hubiera sido más fácil probablemente, pero menos auténtico.
  • Cuando dice añadir la cáscara de limón quiere decir eso, que se añada la cáscara del limón, con la parte blanca y todo, y no solo la ralladura del limón como nosotros inteligentemente hicimos. En efecto la pectina, que es el agente espesante de la mermelada, se encuentra en la parte blanca de la piel.
  • En esta receta se ha añadido media manzana a cada una de las dos mermeladas, más que por el sabor por el hecho de que no espesaban y empezaba a preocuparme. En efecto, la manzana tiene un alto grado de pectina. A pesar de todo, esto le ha añadido un agradable toque.
  • En realidad, para que la pectina de la manzana tenga realmente efecto habría que añadir una manzana cortada en dos y con piel, cuanto más verde mejor (incluso Reineta), y sacarla cuando se haya puesto blanda. O rayar la manzana y poner el corazón y la piel en un saquito que se sacará una vez la mermelada terminada.

Acabaré insistiendo en la importancia de usar jarrones esterilizados correctamente para la conservación de los productos. Se deben hervir los recipientes en agua durante 15-30 minutos, antes y después de rellenarlos, aunque una solución más cómoda que he descubierto por Internet es la de esterilizar en la reja superior del lavavajillas! En efecto, se aconseja este tipo de esterilizado para los biberones de los bebés. Y si funciona para ellos, también funciona para nosotros.

Puesta al día, 30 Enero 2007:

No se debe utilizar el lavavajillas para esterilizar! Se debe utilizar el agua hirviendo, y unicamente para los alimentos ácidos (con un pH de menos de 4,6).

  • Author: guille
  • Published: Jan 12th, 2007
  • Comments: 7

Django’s FastCGI init.d script for Linux

server_startupUpdate 15 Jan 2007: I have updated the post as I’ve found a better implementation of this script. Indeed, in my previous solution I was running the server as root. Now I’ve simplified the script, eliminated the wrapper and I’m running my servers as a different user (www-data in my case).

In the constant search for the perfect deployment, I’ve decided to have a look at the Django FastCGI option. The idea is to launch several FastCGI servers with Nginx as a proxy redirecting the requests.

The deployment proposed implies that “in most cases you’ll be starting the FastCGI process on your own”. And, of course, we will be stopping it on our own as well. For this they propose this script:

#!/bin/bash

# Replace these three settings.
PROJDIR="/home/user/myproject"
PIDFILE="$PROJDIR/mysite.pid"
SOCKET="$PROJDIR/mysite.sock"

cd $PROJDIR
if [ -f $PIDFILE ]; then
    kill `cat -- $PIDFILE`
    rm -f -- $PIDFILE
fi

exec /usr/bin/env - \
  PYTHONPATH="../python:.." \
  ./manage.py runfcgi socket=$SOCKET pidfile=$PIDFILE

 It’s a short script, and it works just well. But I was looking for a bit more flexibility. So I decided to develop my own init.d script.

The init.d script is called fastcgi,
an admittedly unimaginative name :-) The main requirement is that it
should integrate without problems with the init.d scripts, and that it
should allow to transparently and uniformly start, stop and restart
FastCGI processes for several Django sites with minimum configuration.

#! /bin/sh
### BEGIN INIT INFO
# Provides:          FastCGI servers for Django
# Required-Start:    networking
# Required-Stop:     networking
# Default-Start:     2 3 4 5
# Default-Stop:      S 0 1 6
# Short-Description: Start FastCGI servers with Django.
# Description:       Django, in order to operate with FastCGI, must be started
#                    in a very specific way with manage.py. This must be done
#                    for each DJango web server that has to run.
### END INIT INFO
#
# Author:  Guillermo Fernandez Castellanos
#          .
#
# Version: @(#)fastcgi 0.1 11-Jan-2007 guillermo.fernandez.castellanos AT gmail.com
#

#### SERVER SPECIFIC CONFIGURATION
DJANGO_SITES="site1 site2 site3"
SITES_PATH=/path/to/sites
RUNFILES_PATH=$SITES_PATH/run
HOST=127.0.0.1
PORT_START=3000
RUN_AS=www-data
#### DO NOT CHANGE ANYTHING AFTER THIS LINE!

set -e

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="FastCGI servers"
NAME=$0
SCRIPTNAME=/etc/init.d/$NAME

#
#       Function that starts the daemon/service.
#
d_start()
{
    # Starting all Django FastCGI processes
    PORT=$PORT_START
    for SITE in $DJANGO_SITES
    do
        echo -n ", $SITE"
        if [ -f $RUNFILES_PATH/$SITE.pid ]; then
            echo -n " already running"
        else
            start-stop-daemon --start --quiet \
                       --pidfile $RUNFILES_PATH/$SITE.pid \
                       --chuid $RUN_AS --exec /usr/bin/env -- python \
                       $SITES_PATH/$SITE/manage.py runfcgi \
                       host=$HOST port=$PORT pidfile=$RUNFILES_PATH/$SITE.pid
            chmod 400 $RUNFILES_PATH/$SITE.pid
        fi
        let "PORT = $PORT + 1"
    done
}

#
#       Function that stops the daemon/service.
#
d_stop() {
    # Killing all Django FastCGI processes running
    for SITE in $DJANGO_SITES
    do
        echo -n ", $SITE"
        start-stop-daemon --stop --quiet --pidfile $RUNFILES_PATH/$SITE.pid \
                          || echo -n " not running"
        if [ -f $RUNFILES_PATH/$SITE.pid ]; then
           rm $RUNFILES_PATH/$SITE.pid
        fi
    done
}

ACTION="$1"
case "$ACTION" in
    start)
        echo -n "Starting $DESC: $NAME"
        d_start
        echo "."
        ;;

    stop)
        echo -n "Stopping $DESC: $NAME"
        d_stop
        echo "."
        ;;

    restart|force-reload)
        echo -n "Restarting $DESC: $NAME"
        d_stop
        sleep 1
        d_start
        echo "."
        ;;

    *)
        echo "Usage: $NAME {start|stop|restart|force-reload}" >&2
        exit 3
        ;;
esac

exit 0

The variables of the script are:

  • SITES_PATH: The folder where all the sites are stored, a site per folder. The folder structure i supposed to be a common folder ($SITES_PATH, in
    our case) where each site has a known folder ($SITES_PATH/www_guindilla_eu/,
    $SITES_PATH/www_haruki_eu/, $SITES_PATH/complu_haruki_eu/) where all configuration files
    are stored (manage.py, settings.py,…). More info about this here.
  • DJANGO_SITES: The names of the folders where the different sites are.
  • RUNFILES_PATH: The path to the folder where .pid and .socket files (if using Unix sockets) are stored.
  • HOST: The IP address of the host.
  • PORT_START: Each server will be running in a different port. The first server will run on PORT_START, the second on PORT_START+1, etc.
  • RUN_AS: We want the FastCGI servers to run under a
    different user than root. RUN_AS is this user. You can put the username
    or the UID of the user.

In order to use, configure the initial variables, put the fastcgi file in the /etc/init.d/ directory and execute update-rc.d /etc/init.d/fastcgi defaults in a terminal. This way the daemon will be automagically be started at each system start-up.

The script is generally pretty easy to understand. Some sensitive parts are:

  • #HOST=`/sbin/ifconfig | /bin/sed -n -e ‘s/\(.*\)inet addr:\(.*\)B.*$/\2/p’`
    In my script I used the IP address 127.0.0.1. Sometimes we simply want
    to use the IP of the server. This line finds this address automatically.
  • d_start() start-stop-daemon can store the pid file of the daemon it starts in $RUNFILES_PATH. But this requires root access, and by using the option –chuid $RUN_AS we loose the ability to write root-only folders. So we delegate the pid file writting to manage.py. Another problem is, the stored pid would correspond to the FastCGI process while start-stop-daemon will consider the env pid. Thus, what will happen when doing two consecutive fastcgi start is
    that a new FastCGI process will not be spawned, but the pid file will
    be overwritten with a more recent pid, thus making any further fastcgi stop
    command break. The solution is to manually check for already existent
    process (by checking that their pid files exist) and launching the
    FastCGI processes otherwise.
  • The d_start() function will increase the port used by one for each different server, starting from the $PORT_START onwards.
  • d_stop() start-stop-daemon
    is used here, although there is no real need. The pid files are removed
    once the FastCGI process stopped in order to identify which sites are
    running.

This script uses TCP sockets for communication, but it is really simple to modify it in order to use Unix domain sockets:

  • The sockets will be stored with the .pid files, and have the same name but with the.socket extension.
  • Replate the argument runfcgi socket=$RUNFILES_PATH/$SITE.socket pidfile=$RUNFILES_PATH/$SITE.pid by runfcgi host=$HOST port=$PORT pidfile=$RUNFILES_PATH/$SITE.pid in all the script. Use this last value whenever you need to identify the socket.
  • Remove the HOST and PORT variables from the fastcgi file.

And that’s it. Your script will work with Unix domain sockets.

Of course, the script is far from perfect:

  • It is the first of the kind I do and my sh mastery is pretty low.
  • It does not have a finely grained site management. All are treated alike.
  • The port management is done a bit ad-hoc and could cause some configuration synchronization issues if not treated with care.
  • The FastCGI server does not work under root, but still has some flaws.
    For example, the .pid files can be read by www-data and can not be
    written in /var/run/. This is due to the fact that Django’s manage.py
    does not seem to have an option to downscale to a lower-permission user
    as www-data.
  • The script is known to be working in Debian and Ubuntu based systems, but will not work on Gentoo due to it’s particular init.d system. It should work at is in other Redhat based systems (Mandriva, Suse,…), although this has not been confirmed.

Still, I think it is a script that can be
useful and that will save me an important amount of time. And it’s like
a kid, no matter how ugly it is, it’s mine and I love it :-)

Any feedback would be greatly appreciated!

 

**** OLD POST FOLLOWS FOR REFERENCE **** 

In the constant search for the perfect deployment, I’ve decided to have a look at the Django FastCGI option. The idea is to launch several FastCGI servers with Nginx as a proxy redirecting the requests.

The deployment proposed implies that “in most cases you’ll be starting
the FastCGI process on your own”
. And, of course, we will be stopping it on our own as well. For this they propose this script:

#!/bin/bash

# Replace these three settings.
PROJDIR="/home/user/myproject"
PIDFILE="$PROJDIR/mysite.pid"
SOCKET="$PROJDIR/mysite.sock"

cd $PROJDIR
if [ -f $PIDFILE ]; then
    kill `cat -- $PIDFILE`
    rm -f -- $PIDFILE
fi

exec /usr/bin/env - \
  PYTHONPATH="../python:.." \
  ./manage.py runfcgi socket=$SOCKET pidfile=$PIDFILE

 It’s a short script, and it works just well. But I was looking for a bit more flexibility. So I decided to develop my own init.d script.

The first thing I did was to write a wrapper around the python manage.py command. I saved it in /www/run/django_fcgi :

 #! /bin/sh

[ $# = 4 ] || echo -n "Usage: $0 django_site ip port pid_file"

DJANGO_SITE=$1
IP=$2
PORT=$3
PID_FILE=$4

/usr/bin/env python $DJANGO_SITE/manage.py runfcgi \
                    host=$HOST port=$PORT pidfile=$PID_FILE

This script will make the use of the start-stop-daemon easier. Of course, this wrapper is not strictly necessary, as the command line can be directly executed in the init.d script, but this wrapper makes it more convenient.

Then comes the proper init.d script. I called it fastcgi, an admittedly unimaginative name :-) The main requirement is that it should integrate without problems with the init.d scripts, and that it should allow to transparently and uniformly start, stop and restart FastCGI processes for several Django sites with minimum configuration.

#! /bin/sh
### BEGIN INIT INFO
# Provides:          FastCGI servers for Django
# Required-Start:    networking
# Required-Stop:     networking
# Default-Start:     2 3 4 5
# Default-Stop:      S 0 1 6
# Short-Description: Start FastCGI servers with Django.
# Description:       Django, in order to operate with FastCGI, must be started
#                    in a very specific way with manage.py. This must be done
#                    for each DJango web server that has to run.
### END INIT INFO
#
# Author:  Guillermo Fernandez Castellanos
#          .
#
# Version: @(#)fastcgi 0.1 11-Jan-2007 guillermo.fernandez.castellanos AT gmail.com
#

#### SERVER SPECIFIC CONFIGURATION
#HOST=`/sbin/ifconfig | /bin/sed -n -e 's/\(.*\)inet addr:\(.*\)B.*$/\2/p'`
DJANGO_SITES="complu_haruki_eu www_haruki_eu www_guindilla_eu"
SITES_PATH=/www
DAEMON=/www/run/django_fcgi
RUNFILES_PATH=$SITES_PATH/run
HOST=127.0.0.1
PORT_START=3000
#### DO NOT CHANGE ANYTHING AFTER THIS LINE!

set -e

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="FastCGI servers"
NAME=$0
SCRIPTNAME=/etc/init.d/$NAME

# Gracefully exit if the package has been removed.
test -x $DAEMON || exit 0

#
#       Function that starts the daemon/service.
#
d_start()
{
    # Starting all Django FastCGI processes
    PORT=$PORT_START
    for SITE in $DJANGO_SITES
    do
        echo -n ", $SITE"
        # As $DAEMON is a shell script, the process runs with the name "bash",
        # not "$DAEMON".
        # Thus I can not use the start-stop-daemon method here.
        # start-stop-daemon --start --quiet --pidfile $RUNFILES_PATH/$SITE.pid \
        # --exec $DAEMON -- $SITES_PATH/$SITE $HOST $PORT $RUNFILES_PATH/$SITE.pid \
        if [ -f $RUNFILES_PATH/$SITE.pid ]; then
            echo -n " already running"
        else
            $DAEMON $SITES_PATH/$SITE $HOST $PORT $RUNFILES_PATH/$SITE.pid
        fi
        let "PORT = $PORT + 1"
    done
}

#
#       Function that stops the daemon/service.
#
d_stop() {
    # Killing all Django FastCGI processes running
    for SITE in $DJANGO_SITES
    do
        echo -n ", $SITE"
        start-stop-daemon --stop --quiet --pidfile $RUNFILES_PATH/$SITE.pid \
                          || echo -n " not running"
        if [ -f $RUNFILES_PATH/$SITE.pid ]; then
           rm $RUNFILES_PATH/$SITE.pid
        fi
    done
}

ACTION="$1"
case "$ACTION" in
    start)
        echo -n "Starting $DESC: $NAME"
        d_start
        echo "."
        ;;

    stop)
        echo -n "Stopping $DESC: $NAME"
        d_stop
        echo "."
        ;;

    restart|force-reload)
        echo -n "Restarting $DESC: $NAME"
        d_stop
        sleep 1
        d_start
        echo "."
        ;;

    *)
        echo "Usage: $NAME {start|stop|restart|force-reload}" >&2
        exit 3
        ;;
esac

exit 0

The variables of the script are:

  • SITES_PATH: The folder where all the sites are stored, a site per folder.
  • DJANGO_SITES: The names of the folders where the different sites are.
  • DAEMON: The path to our wrapper.
  • RUNFILES_PATH: The path to the folder where .pid and .socket files (if using Unix sockets) are stored.
  • HOST: The IP address of the host.
  • PORT_START: Each server will be running in a different port. The first server will run on PORT_START, the second on PORT_START+1, etc.

In order to use, configure the initial variables, put the fastcgi file in the /etc/init.d/ directory and execute update-rc.d /etc/init.d/fastcgi defaults in a terminal. This way the daemon will be automagically be started at each system start-up.

The script is generally pretty easy to understand. Some sensitive parts are:

  • #HOST=`/sbin/ifconfig | /bin/sed -n -e ‘s/\(.*\)inet addr:\(.*\)B.*$/\2/p’` In my script I used the IP address 127.0.0.1. Sometimes we simply want to use the IP of the server. This line finds this address automatically.
  • d_start() start-stop-daemon stores the pid file of the daemon it starts in $RUNFILES_PATH. The problem is, this stored pid correspond to the FastCGI process while start-stop-daemon will consider the bash wrapper pid. Thus, what will happen when doing two consecutive fastcgi start is that a new FastCGI process will not be spawned, but the pid file will be overwritten with a more
    recent pid, thus making any further fastcgi stop command break. The solution is to manually check for already existent process (by checking that their pid files exist) and launching the FastCGI processes otherwise.
  • The d_start() function will increase the port used by one for each different server, starting from the $PORT_START onwards.
  • d_stop() start-stop-daemon is used here, although there is no real need. The pid files are removed once the FastCGI process stopped in order to identify which sites are running.

This script uses TCP sockets for communication, but it is really simple to modify it in order to use Unix domain sockets:

  • The sockets will be stored with the .pid files, and have the same name but with the.socket extension.
  • Modify the wrapper so it uses: /usr/bin/env python $DJANGO_SITE/manage.py runfcgi socket=$SOCKET pidfile=$PIDFILE
  • Replace the argument $HOST $PORT by $RUNFILES_PATH/$SITE.socket in all the script. Use this last value whenever you need to identify the socket.
  • Remove the HOST and PORT variables from the fastcgi file.

And that’s it. Your script will work with Unix domain sockets.

Of course, the script is far from perfect:

  • It is the first of the kind I do and my sh mastery is pretty low.
  • It does not have a finely grained site management. All are treated alike.
  • The port management is done a bit ad-hoc and could cause some configuration synchronization issues if not treated with care.
  • The script is known to be working in Debian and Ubuntu based systems, but will not work on Gentoo. I could not test it in other systems (RH, Fedora,…).

Still, I think it is a script that can be useful and that will save me an important amount of time. And it’s like a kid, no matter how ugly it is, it’s mine and I love it :-)

Any feedback would be greatly appreciated!

  • Author: guille
  • Published: Jan 8th, 2007
  • Comments: 1

One week server downtime

crybabyIn order to start the year in a positive note, I screwed my network. Indeed, it has been down for a week. The downtime was due to a router failure and my holidays at 2000km from home. It was very bad luck indeed!

It took me a little while to reconfigure everything and make sure my recent changes were still working, but now everything it’s running again.

This should teach me to never do important changes without thorough testing (that part was done) and without having someone at hand to reboot the hardware!

I almost forgot, Happy New Year!

© 2006,2007,2008,2009,2010 Guillermo Fernández Castellanos | Header images by Nick Lobeck