ZenTech - freebsd

Le log qui se voulait plus gros que le boeuf

hr — Thu, 21 Feb 2008 17:52:00 +0100

C'est généralement au moment où on se retrouve avec une partition pleine que l'oubli de la rotation des logs refait surface. C'est ultra-classique et pourtant... Mais nous allons prendre les devants pour que lighty ne soit pas un mangeur d'espace.

Sur FreeBSD, le gestionnaire de rotation de log de base s'appelle newsyslog(8), il est configuré par le fichier /etc/newsyslog.conf (newsyslog.conf(5)). Je suis habitué à logrotate(8) et j'aime bien conserver tous mes fichiers de logs d'activité web, je vais donc faire la même chose avec newsyslog(5). Je souhaite donc faire tourner mes logs tous les jours à minuit, compresser les logs passés et les conserver ad vitam eternam. Ces contraintes donnent l'entrée suivante dans le fichier de configuration :

# lighttpd rotates
/var/log/lighttpd/lighttpd.access.log   www:www   640  366 *   @T00   JC

il faut spécifier un champ de gestion d'appartenance (propriétaire et groupe), lighttpd écrit les logs avec les droits www:www et ils seront déplacés en changeant le propriétaire en root:www.Les fichiers seront créés avec les droits 640, le champ suivant spécifie que les fichiers sont sauvegardés 366 fois avant d'éliminer les fichiers les plus anciens (1 an). Les 2 champs suivant provoquent une rotation à minuit tous les jours. Le dernier champ précise qu'on compresse les archive de log en bzip2 et que le fichier est créé si il n'existe pas.
Le champ 'count' n'est pas exhaustivement décrit dans la page de man, et j'espérais pouvoir utiliser une valeur qui me permettrait d'avoir un nombre infini de fichiers de logs. La lecture du code source m'a confirmé que je ne pouvais pas utiliser le même type de fonctionnement que pour logrotate(8).

Une entrée doit être créée pour chaque fichier de log de chaque vhost.

Un blog bien sous tout rapport

hr — Thu, 14 Feb 2008 16:39:00 +0100

Ce blog est un dotclear 2 installé sur un système FreeBSD et servi par un lighty. J'ai choisi dotclear pour la possibilité de gérer de multiples blogs à partir d'un seul code, wordpress ne donnait pas cette possibilité simplement au moment de mon choix. Mon premier déploiement n'a pas été fait dans les règles FreeBSD, il est temps de remédier à cet insupportable état de fait.

Les applications web sont déployées dans /usr/local/www sous FreeBSD, le contenu des sites se trouve dans /usr/local/www/data.

# cd /usr/local/www
# tar zxvf ~/src/dotclear-2.0-beta7.tar.gz
# mv dotclear dotclear2

Le renommage du répertoire permet d'éviter un conflit dans l'éventualité de l'installation d'un dotclear 1.

Une fois le blog installé, il faut le configurer. La configuration de lighty est très simple, il suffit d'ajouter l'alias suivant pour un blog qui est atteint par http://www.bon.org/blog par exemple :

alias.url += (
        "/blog" => "/usr/local/www/dotclear2"
)

La suite de la configuration a déjà été abordée dans un autre billet.

Finalement la modification est assez mineure et revient uniquement à modifier le chemin d'alias pour tous les blogs hormis celui par défaut et ajouter un alias pour celui-ci.

ALETER Out of memory

hr — Wed, 13 Feb 2008 18:29:00 +0100

Si comme Doris vous avez de petits problèmes de mémoire avec dotclear 2 (dc2 beta7) lors du chargement de la page d'administration des utilisateurs, le problème vient probablement de MySQL.

Je me retrouve actuellement devant l'erreur suivante lorsque j'essaie d'administrer mes utilisateurs via l'interface d'administration :

Out of memory; restart server and try again (needed 65528 bytes) (1037)

Le problème me semble venir du serveur MySQL, une petite recherche google me conforte dans cette idée, je mets donc un peu de code de debug dans admin/users.php et je me retrouve avec cette requête SQL dantesque générée par la fonction getUsers() :

SELECT U.user_id,user_super,user_status,user_pwd,user_name,user_firstname,user_displayname,user_email,user_url,user_desc, user_lang,user_tz, user_post_status,user_options, count(P.post_id) AS nb_post FROM dc_user U LEFT JOIN dc_post P ON U.user_id = P.user_id WHERE NULL IS NULL GROUP BY U.user_id,user_super,user_status,user_pwd,user_name,user_firstname,user_displayname,user_email,user_url,user_desc, user_lang,user_tz,user_post_status,user_options ORDER BY U.user_id ASC  LIMIT 30 OFFSET 0;

Je comprends bien pourquoi mon petit serveur râle, devant l'adversité je me plie et je reconfigure mon serveur dans /var/db/mysql/my.cnf en modifiant une seule ligne :

sort_buffer_size = 128K

Après un redémarrage du serveur MySQL, tout rentre dans l'ordre et everybody is content.

HAL> Affirmative, Dave, I read you.

hr — Fri, 11 Jan 2008 17:39:00 +0100

Ah la vacuité d'une session IRC sur un canal dirigé par un automate. Quoi de plus extraordinaire que pouvoir connaitre la météo de Felletin dans la Creuse ou d'avoir une blague carambar à la demande. En ce moment je fais beaucoup de python, donc je me suis penché sur le problème pour un ami. Je vais essayer de vous exposer les clés de l'utilisation d'irclib pour construire un automate irc simple.

L'automate est présenté ci-après, ses fonctions sont simplement la connexion à un serveur irc local sur le port 6667 et l'entrée dans le canal #test. L'automate s'attend à lire des commandes préfixées de '!' dans le canal. La commande !cycle demande à l'automate de partir et revenir sur le canal, la commande !die provoque la déconnexion du serveur puis l'arrêt de l'automate. Le script de l'automate ci-après se trouve en téléchargement ici et peut être lancé par la commande python mybot.py.

import sys
try:
    from ircbot import SingleServerIRCBot
    import irclib
except ImportError, e:
    print e
    sys.exit(1)

class pybot(SingleServerIRCBot):
    def __init__(self, server, nick, realname, chan):
        SingleServerIRCBot.__init__(self, server, nick, realname)
        self.chan = chan
        self.nick = nick

    ## Event callbacks
    def on_welcome(self, c, e):
        if self.chan:
            c.join(self.chan)

    def on_join(self, c, e):
        who = e.source().split('!', 1)
        if who[0] == self.nick:
            c.privmsg(e.target(), 'Hello world!')

    def on_pubmsg(self, c, e):
        msg = e.arguments()[0].strip()
        if msg.startswith('!'):
            cmd = msg[1:].split(' ', 1)[0]
            self.trigger(c, e, cmd)

    ## Command triggers
    def trigger(self, c, e, cmd):
        try:
            getattr(self, 'cmd_%s' % cmd)(c, e)
        except AttributeError:
            pass

    def cmd_cycle(self, c, e):
        chan = e.target()
        c.part(chan, 'cycle')
        c.join(chan)

    def cmd_die(self, c, e):
        SingleServerIRCBot.die(self, 'Argh')

## Here comes the real script
if __name__ == '__main__':
    server = [('localhost', 6667)]
    nick = 'monbot'
    realname = 'monbot'
    channel = '#test'

    bot = pybot(server, nick, realname, channel)
    try:
        bot.start()
    except KeyboardInterrupt:
        bot.connection.disconnect("Ctrl-C m'a tuer")
        bot.connection.close()

La librairie irclib est basée sur la gestion d'évènements, des méthodes vont être lancées sur apparition d'un évènement au sens IRC. Les méthodes de l'objet pybot commençant par 'on_' sont les méthodes de gestion d'évènements, par exemple lorsqu'un message est envoyé sur un canal (PUBMSG) la méthode on_pubsmg() est appelée. La création de l'automate se base sur la surcharge des méthodes de gestion d'évènements. Ces méthodes ont toutes la même définition d'appel :

def on_foo(self, c, e):
    [...]

La variable c est un objet ServerConnection, cet objet permet de manipuler tout ce qui concerne le serveur irc d'où provient l'évènement. On peut par exemple rejoindre un canal (c.join()) ou envoyer un message à un canal ou une personne (commande PRIVMSG via c.privmsg()). La variable e est un objet Event, elle permet d'obtenir toutes les informations sur l'évènement qui a provoqué l'appel de la méthode. L'origine de l'évènement (e.source()), la destination de cet évènement (e.target()) ou encore les arguments de cet évènement (e.arguments()). Toutes les informations sur ces 2 méthodes se trouvent dans le module irclib (pydoc irclib).

A partir de la connaissance de ces éléments de base, la construction d'un automate devient assez simple. Si l'automate doit effectuer des tâches régulières, les méthodes execute_at() et execute_delayed() (héritage de l'objet IRC parent de SingleServerIRCBot) peuvent être utilisées. Plus d'information sur irclib devrait se trouver sur mon wiki.

Il est également possible d'utiliser twisted.words pour effectuer la même chose mais ça me semble une librairie un peu imposante pour un simple automate.

Il faut noter qu'on peut faire également le même genre de chose en Perl.

WOPR> Global Thermonuclear War

hr — Thu, 03 Jan 2008 18:33:00 +0100

Dans mon parcours d'initiation à python, je me suis retrouvé face à un problème existentiel (ce qui donne tout le caractère initiatique au parcours, le problème, parce qu'il est existentiel ... laisse tomber). Lors de l'utilisation du module cmd, comment gérer correctement les interruptions classiques que sont ctrl+D (EOF) et ctrl-C (SIGINT).

Ci-après, un squelette pour la gestion des 2 signaux évoqués. Juste après ci-après, les quelques explications qui s'imposent.

import sys
import cmd

class shell(cmd.Cmd):
    def __init__(self):
        cmd.Cmd.__init__(self)

    # Let's handle ctrl+D signals and quit gently
    def do_EOF(self, str):
        # CLEAN HERE
        return 1

if __name__ == "__main__":
    console = shell()
    try:
        console.cmdloop()
    except KeyboardInterrupt:
        # CLEAN HERE
        sys.exit(0)

`ctrl-D` ou la fin du monde

Le manuel de cmd nous dit :

An end-of-file on input is passed back as the string 'EOF'.

Ce qui signifie que la combinaison de touches ctrl+D revient à gérer la commande EOF, la méthode appelée est donc do_EOF().
Une autre information à propos de cmdloop() donnée dans le manuel est :

This method will return when the postcmd() method returns a true value. The stop argument to postcmd() is the return value from the command's corresponding do_*() method.

Donc si la méthode do_EOF() retourne simplement 1, la boucle va tout bêtement s'arrêter.

`ctrl-C` ou la fin de l'univers

En Python, l'utilisation de ctrl-C lève l'exception KeyboardInterrupt, en capturant cette interruption, on permet au script de sortir de façon maitrisée.

Evolution

Il est conseillé d'ajouter des actions de nettoyage au niveau des commentaires # CLEAN HERE pour permettre une sortie de la console vraiment sans encombre. Il reste encore à trouver un moyen élégant d'utiliser ctrl-c pour annuler la ligne en cours et récupérer l'invite vierge sans quitter cmd.cmdloop()
Attention toutefois, ce code n'a pas été testé dans un environnement microsoft. Les signaux ne sont surement pas traités de la même façon, ça n'étonnera personne.

A chacun sa petite fiche de présence

hr — Sun, 11 Nov 2007 12:52:00 +0100

J'aime bien avoir des logs d'accès séparés par vhost sur mes serveurs, ça permet de simplifier la recherche d'erreur et la construction de statistiques. Comme je gère mes vhosts par un script, j'ai pensé que rajouter la création automatique de logs d'accès serait un plus. C'est toujours ça qui ne sera pas oublié lors de l'ajout d'un nouveau vhost.
Au passage, j'ai rajouté le document-root automatique, les données d'un site virtuel doivent se trouver dans un répertoire du nom de son fichier de configuration.

# ./include_vhost -h
Usage: include_dir [-hptx] [-d docroot_path] [-l log_path] <dir>
    -h      displays this help
    -d      Automatic document-root specification
    -l      Add vhost access logs in log_path
    -p      print the parsed config files and exit (default behaviour)
    -t      test the config files
    -x      specify a lighttpd binary (default /usr/local/sbin/lighttpd)

Si les logs doivent se trouver dans /var/log/lighttpd, que les sites se trouvent dans /usr/local/www/data et que les fichiers de configurations de vhost sont dans /usr/local/etc/lighttpd/vhost.d, on obtient l'appel suivant au script :

./include_vhost -l /var/log/lighttpd -d /usr/local/www/data /usr/local/etc/lighttpd/vhost.d

Au passage, le script change de nom étant donné qu'il se spécialise vraiment dans la gestion de fichiers de configuration d'hôte virtuel.

Pour information, je n'ai pas rajouté les logs d'erreur dans cet automate, pour la simple et bonne raison que la documentation de configuration déconseille de placer plusieurs appels à server.errorlog dans la configuration de lighty.

Je veux bien prendre mais pas de là

hr — Sat, 21 Jul 2007 22:14:00 +0200

C'est toujours autant amusant de jouer avec lighttpd, mais parfois on se trompe dans un fichier de configuration et là, c'est le drame. Mon script include_dir ne permet pas de savoir quel fichier de configuration est brokmut lors de l'utilisation de lighttpd -p -f lighttpd.conf. C'est maintenant chose faite, avec la nouvelle version toujours téléchargeable au même endroit. Au passage, il est passé en license beerware

# ./include_dir -h
Usage: include_dir [-hptx] <dir>
    -h      displays this help
    -p      print the parsed config files and exit (default behaviour)
    -t      test the config files
    -x      specify a lighttpd binary (default /usr/local/sbin/lighttpd)
# ./include_dir -t vhost.d/
>>> Testing vhost.d/www.vhost1.org
Syntax OK
>>> Testing vhost.d/www.vhost2.org
2007-07-21 22:28:47: (configfile.c.833) source: vhost.d/www.vhost2.org line: 3 pos: 21 parser failed somehow near here: (EOL) 
>>> Testing vhost.d/www.vhost3.org
Syntax OK

httpd.zero = enable

hr — Fri, 30 Mar 2007 18:55:00 +0200

Toujours à m'amuser avec asparttpd et je me dis que ce serait sympa de pouvoir utiliser le mécanisme auquel je me suis habitué pour les vhosts. Un dossier vhost.d et un fichier de conf par vhost dans ce répertoire.

Rien de plus facile en fait, grâce à include_shell je lance un script de ma composition, ce script est un bête bout de sh qui inclut tous les fichiers du répertoire donné en argument au script. Ca donne ce genre de chose :

#### vhosts
include_shell "./include_dir vhost.d"

et le script :

#!/bin/sh

# I prefer doing nothing if no dir is given on command line
# that way I do not break anything
if [ "$#" = "0" ]; then
        exit 0
fi

# exclude vim temporary files
# configuration file has to have the vhost domain name
for site in $(ls $1 | grep -v .swp); do
        echo "\$HTTP[\"host\"] == \"$site\" {"
        cat $1/$site
        echo "}"
        echo
done

l'utilisation d'un petit lighttpd -p -f lighttpd.conf permet de s'assurer que tout fonctionne correctement, on remarque également que de cholis commentaires sont ajoutés pour faciliter la lecture. Le script include_dir est présent dans le même répertoire que le fichier de configuration de lighttpd (je sais, c'est sale).

Et si on mangeait light

hr — Fri, 30 Mar 2007 16:54:00 +0200

Il y a toujours un moment dans la vie où on se dit qu'on mange trop lourd et qu'il faudrait faire attention et que j'ai pris du gras de là. il n'y a pas longtemps c'est ma passerelle qui m'a dit ça. Alors hop un p'tit coup de régime, un avis de la part d'un ami diététicien et c'est parti. lighttpd s'installe sans probléme sur un freebsd6.2 (lighttpd-1.4.13_2) et dès le premier démarrage, sans php, HAHAHA la blague.

[root@backdoor ~]# ps ax -o 'user pid %cpu %mem command' -w|grep www
www      36654  0.0  0.7 /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd/lighttpd.conf

A titre de comparaison, le port apache-1.3.37_2 sous freebsd, lancé avec la conf par défaut me donne ça :

[root@backdoor ~]# ps ax -o 'user pid %cpu %mem command' -w|grep www
www      49868  0.0  0.8  2716  2136  ??  S     2:25PM   0:00.01 /usr/local/sbin/httpd
www      49869  0.0  0.8  2716  2136  ??  S     2:25PM   0:00.01 /usr/local/sbin/httpd
www      49870  0.0  0.8  2716  2136  ??  S     2:25PM   0:00.01 /usr/local/sbin/httpd
www      49871  0.0  0.8  2716  2136  ??  S     2:25PM   0:00.01 /usr/local/sbin/httpd
www      49872  0.0  0.8  2716  2136  ??  S     2:25PM   0:00.01 /usr/local/sbin/httpd

La bonne blague donc, il suffit ensuite d'installer php en version FastCgi et de donner le chemin vers le binaire fcgi à lighttpd :

fastcgi.server = ( ".php" => ((
        "bin-path" => "/usr/local/bin/php-cgi",
        "socket" => "/tmp/php.socket")))

Un petit restart et des processus php-cgi apparaissent dans le sillage de notre serveur http sous aspartame.

Dans la foulée je m'installe un dotclear2 et à condition de mettre une petite série de règles de réécriture, je peux même me faire de jolies URL pour les billets.

url.rewrite-once += (
    "^/blog/(archive.*)" => "/blog/index.php/$1",
    "^/blog/(category.*)" => "/blog/index.php/$1",
    "^/blog/(feed.*)" => "/blog/index.php/$1",
    "^/blog/(page.*)" => "/blog/index.php/$1",
    "^/blog/(post.*)" => "/blog/index.php/$1",
    "^/blog/(tag.*)" => "/blog/index.php/$1",
    "^/blog/(trackback.*)" => "/blog/index.php/$1"
)
$HTTP["url"] =~ "/blog/(CHANGELOG|db|inc|cache|plugins)" {
    url.access-deny = ("")
}

Alors pour résumer, un fichier de configuration simpilissime à prendre en main, un système de modules niquel, une empreinte mémoire aussi imposante qu'un PEZ et un système de vhosts que ma mère peut comprendre. Une vraie tuerie, seul bémol, l'absence de système ala .htaccess qui, il faut l'avouer, est carrément convi (mais consommateur à chaque accès).