Un petit billet pour annoncer que je suis passé de FreeBSD à ArchLinux sur mon serveur@home. Pourquoi ? Pourquoi pas. J’avais envie de quelque chose de plus simple et aussi un peu de changer. Merci le disque dur externe de 1 To pour faire les sauvegardes nécessaires :)

Comme j’utilise déjà ArchLinux depuis quelques années sur mon netbook et mon autre machine, la transition s’est évidemment faite sans aucun accroc. Tout marche comme il faut, le seul point un peu délicat concernant l’installation : impossible d’installer grub1 sur des disques GPT, malgré ce que dit le wiki. Utiliser LVM et mdadm pour faire du raid5 et du raid1 a aussi été nouveau. Au revoir ZFS, et à bientôt j’espère… Ou btrfs, qui sait ?

Ayant acquis une certaine expérience dans ces deux OS, je me suis dit, pourquoi ne pas faire un petit comparatif des points noirs qui m’ennuient et des fonctionnalités que j’aime utiliser au quotidien ?

FreeBSD

• (+) Les jails : c’est tout simplement très pratique, cela permet d’isoler les différents services sur une machine pour des raisons de sécurité et de stabilité (si un composant ne fonctionne plus à cause d’une mauvaise manip ou d’une mise à jour foireuse, uniquement ce système là est affecté et pas les autres)
• (+) Excellente documentation, le handbook est la référence et les manpages sont aussi très détaillées ; par exemple security(7). Il faut également lire /etc/UPDATING avant de mettre à jour pour se renseigner les changements éventuels à faire manuellement.
• (+) On peut se faire un système 100% ZFS avec GPT, et c’est vraiment très bon.
• (+/-) Distinction entre le système de base (noyau, userland) et les logiciels tiers, autant dans l’organisation que dans le processus de mise à jour. Cela permet un contrôle plus fin des mises à jour mais est également plus complexe pour les néophytes.
• (++/-) Les ports : c’est pratique et il y a beaucoup de logiciels tiers disponibles facilement, mais malheureusement la compilation prend du temps s’il n’y a pas de paquets. Quand on souhaite installer un logiciel qui ne s’y trouve pas, c’est souvent bien plus difficile (à cause du fait que FreeBSD utilise comme préfixe /usr/local pour tous les logiciels tiers) à compiler.
• (-) Les mises à jour sont horriblement lentes, surtout avec CVS.
• (-) Lenteur de portupgrade(1). C’est un outil tiers facultatif mais qui facilite l’installation, la mise à jour et la gestion des ports.
• (-) Beaucoup de ports ne sont plus à jour depuis belle lurette. Par exemple games/stepmania-devel date de 2007.

ArchLinux

• (+) Beaucoup plus simple que FreeBSD à utiliser et à administrer.
• (+) Pacman est très rapide et fait bien son travail. De manière générale, le système de paquets est bien fait (groupes, providers, …). Les mises à jour sont très simples à effectuer.
• (+) Rolling release. C’est un très gros bonus. Au lieu d’avoir tout un tas de mises à jour d’un coup (une date définie arbitrairement), elles arrivent en même temps que leur publication en upstream. On a par exemple le nouveau noyau Linux dès qu’il est distribué. Cela permet de distiller les gros problèmes de mise à jour, c’est psychologiquement moins déprimant.
• (++) Système d’init basé sur BSD et non sur sysvinit. Ça rend la gestion des daemons et la création de tels scripts de démarrage beaucoup plus simple. Et quand on se casse pas la tête grâce à un système plus simple qui fournit les fonctionnalités dont j’ai besoin (qui honnêtement utilise les runlevels ?), c’est très bon.
• (++/-) L’AUR, permet la création de paquets tiers par la communauté, très pratique mais aucune garantie concernant leur sécurité ou leur pérennité. La plupart sont néanmoins bien maintenus ; on peut lire le PKGBUILD avant l’installation pour vérifier que rien de malveillant n’est fait.
• (+) Wiki correct.
• (-) Pas de jails, donc il faut faire très attention à la sécurité et à l’organisation de la machine.

Partager/enregistrer ce post

Seulement voila : le port stepmania date de 2007 et a de grandes chances de ne plus jamais être mis a jour. Il faut donc compiler à la main. C’est pas difficile du tout, sauf que là je suis apparemment le seul blaireau a avoir essayé, je n’ai rien touvé à ce sujet sur la toile. Comme j’ai réussi a avoir un jeu 100% utilisable, voici les étapes à suivre :

1. Étape préliminaire : assurez-vous de ne pas avoir pulseaudio d’installé. Si vous l’avez, StepMania va se connecter dessus au lieu d’utiliser le driver OSS, et croyez-moi, c’est injouable tellement il y a des artefacts audio et de la latence.

2. svn co https://svn.stepmania.com/svn/trunk/stepmania
   cd stepmania

3. Ajoutez « -liconv » à la ligne commencant par « LIBS = @LIBS@ -lpthread -lrt » dans src/Makefile.am
4. Appliquez le patch suivant pour compiler avec la version  1.4 de la libpng (et d’autres trucs pour que ça marche) :

   Index: src/RageSurface_Load_PNG.cpp
   ===================================================================
   --- src/RageSurface_Load_PNG.cpp	(revision 28355)
   +++ src/RageSurface_Load_PNG.cpp	(working copy)
   @@ -140,7 +140,7 @@
   
    	/* Expand grayscale images to the full 8 bits from 1, 2, or 4 bits/pixel */
    	if( color_type == PNG_COLOR_TYPE_GRAY && bit_depth < 8 )
   -		png_set_gray_1_2_4_to_8( png );
   +		png_set_expand_gray_1_2_4_to_8( png );
   
    	/* These are set for type == PALETTE. */
    	RageSurfaceColor colors[256];
   Index: src/arch/ArchHooks/ArchHooks_Unix.cpp
   ===================================================================
   --- src/arch/ArchHooks/ArchHooks_Unix.cpp	(revision 28355)
   +++ src/arch/ArchHooks/ArchHooks_Unix.cpp	(working copy)
   @@ -12,7 +12,9 @@
    #include "archutils/Unix/AssertionHandler.h"
    #include <unistd.h>
    #include <sys/time.h>
   +#include <sys/wait.h>
   
    #if defined(CRASH_HANDLER)
    #include "archutils/Unix/CrashHandler.h"
    #endif
   Index: src/RageSurface_Save_PNG.cpp
   ===================================================================
   --- src/RageSurface_Save_PNG.cpp	(revision 28355)
   +++ src/RageSurface_Save_PNG.cpp	(working copy)
   @@ -103,7 +103,7 @@
   
    	if( setjmp(pPng->jmpbuf) )
    	{
   -		png_destroy_read_struct( &pPng, &pInfo, png_infopp_NULL );
   +		png_destroy_read_struct( &pPng, &pInfo, NULL );
    		return false;
    	}

5. CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure --without-ffmpeg
   

   Et oui, comme d’habitude, les Linuxiens sont crades et rangent tout dans /usr, et ils n’ont même pas la délicatesse d’aller voir dans /usr/local. Scandaleux.

6. Installez textproc/gsed et changez dans src/Makefile chaque occurence de sed par gsed. Oui, c’est crade, c’est encore une histoire de syntaxe qui change.

7. make

8. ./src/stepmania

Et admirez le résultat. Aucun problème de latence (merci a l’autosync quand même).

Partager/enregistrer ce post

Le problème viendrait de :

1. Une carte de mauvaise qualité (Marvell 88E8053)
2. Un driver msk(4) peu testé et donc rempli de bugs potentiels

La seule façon de rétablir la connexion est de redémarrer la machine. Ce qui pose problème quand on a accès à la machine en question uniquement par SSH la majorité du temps…  J’ai donc réalisé un petit script (vraiment fait à la vite), faisant office de solution de secours, qui fait automatiquement redémarrer la machine si un watchdog timeout a été détécté. Cela permet de ne pas complètement bloquer l’accès via SSH.

Il suffit donc de lancer ce script en cronjob (effectué par root, bien sûr) :

#!/bin/sh

LOGFILE="/var/log/check_msk0"
DATE=`date`

CLEAN=`echo | grep zero`
LOGDATE=`date "+%b %d"`
TIMEOUTS=`cat /var/log/messages | grep "msk0: watchdog timeout" | tail | grep "$LOGDATE"`

if [ "$TIMEOUTS" = "$CLEAN" ]
then
 echo "$DATE OK, no timeouts." >> $LOGFILE
 echo OK.
else
 echo "$DATE WATCHDOG TIMEOUT, initiating reboot..." >> $LOGFILE
 echo Rebooting in 15 seconds. Press ^C to abort.
 sleep 15
 cp /var/log/messages /var/log/messages.timeout
 echo > /var/log/messages
 /sbin/reboot
fi

Inutile de préciser que j’ai commandé une nouvelle carte réseau, plus adaptée pour un serveur, et que cette solution est vraiment temporaire…

Partager/enregistrer ce post

Désolé pour la petite indisponibilité d’environ une semaine, la faute à un bloc d’alim qui a rendu l’âme…

Bon, j’en ai en attendant profité pour mettre à jour le système, avec :

• Une nouvelle alim, et un onduleur, pour ne pas avoir des soucis de FS corrompu
• Quatre disques de 1.5 TB en RAID10, grâce à ZFS. Ce système de fichiers est réellement génial.
• FreeBSD 8.0 avec Apache qui tourne dans une jail :-)

Partager/enregistrer ce post

Cependant, il n’a pas été porté sous FreeBSD, bien qu’il fonctionne bien sous Linux. Heureusement, grâce à quelques hacks simples, il est possible d’utiliser GoatTracker sous FreeBSD.

Avant tout, vérifiez que vous avez les ports/packages SDL d’installés, ainsi que GNU Make (“gmake”) différent du BSD Make par défaut (“make”). Il y a quelques différences dans la structure des Makefiles donc il faut utiliser l’un ou l’autre en fonction de ce qu’on compile.

Ensuite, procurez vous GoatTracker à cette adresse : http://covertbitops.c64.org/ (rubrique “Tools”).

Unzippez les sources dans un répertoire spécial crée à cette occasion, et placez vous dedans.

Avant de compiler GoatTracker, il faut compiler 2 outils qui seront nécessaires : datafile et dat2inc.

Placez vous donc dans le répertoire src/bme. Avant de lancer gmake, il faut modifier le Makefile car il est adapté à une machine Linux. Or, les machines Linux n’utilisent quasiment pas le préfixe /usr/local pour les includes. Le Makefile va donc chercher SDL_types.h dans /usr/include, alors qu’il est situé dans /usr/local/include. Pour corriger cela, il suffit d’ajouter ceci aux CFLAGS : -I/usr/local/include. Le makefile étant ici extrêmement simple, rajoutez cela aux deux appels à gcc.

Vous pouvez ensuite lancer la compilation avec gmake. Une fois que c’est terminé, vous devez copier ces deux exécutables produits dans votre $PATH, donc en gros vous devez copier les fichiers datafile et dat2inc dans /usr/local/bin.

Ensuite, placez vous dans le répertoire src. Cette fois, le Makefile est un peu plus complexe, vous devez rajouter -I/usr/local/include à la fin de la ligne CFLAGS= dans le fichier makefile.common. La compilation se passe ensuite sans problèmes.

Vous pouvez enfin jouer avec GoatTracker, l’exécutable étant situé dans le sous dossier linux/ et commencant par gt2. Enfin, voici une preuve que ça fonctionne :

Partager/enregistrer ce post