En me baladant sur le forum ArchLinux, je suis tombé sur un sujet interressant. N'ayant rien d'autre à faire, je me suis amusé à faire en sorte que pacman vérifie l'authenticité du certificat de mon mirroir, et accessoirement que la communication puisse aussi être chiffrée.

Comment faire ?

Dans le fichier de configuration /etc/pacman.conf il y a une option nommée XferCommand. Voici ce qu'en dit la page de manuel:

XferCommand = /path/to/command %u
If set, an external program will be used to download all remote files. All instances of %u will be replaced with the download URL. If present, instances of %o will be replaced with the local file- name, plus a ".part" extension, which allows programs like wget to do file resumes properly.

This option is useful for users who experience problems with built-in http/ftp support, or need the more advanced proxy support that comes with utilities like wget.

Si cette variable est définie elle sera utilisée par pacman pour effectuer les différents téléchargements (autant celui des données concernant les dépots, que les paquets). On va donc utiliser une commande personnalisée qui se chargera entre autre de vérifier et d'utiliser le chiffrement à l'aide de SSL/TLS.

Mise en œuvre.

La mise en œuvre est très simple et se fait en 2 temps.

1. Écriture d'un script qui s'assure du téléchargement, de la vérification de l'authenticité du serveur et du chiffrement des canaux de communication.
2. Configuration de l'utilisation de ce script par pacman.

Écriture du script.

Ce script que j'ai nommé /usr/bin/ssl-pacman, ressemble à :

#!/bin/bash

case $1 in
    *.db.tar.gz)
        echo "Syncing repository : '$(basename $1 .db.tar.gz)'";;
    *.pkg.tar.gz)
        echo "Downloading package : '$(basename $1 .pkg.tar.gz)'";;
esac
/usr/bin/curl --ftp-ssl-reqd -# -w "Done !\n\n" -O $1

Toute la partie vérification de l'authenticité du serveur et chiffrement des canaux est prise en charge par curl.

Configuration de pacman.

La configuration ce fait simplement en ajoutant la ligne suivante dans la section [options] de /etc/pacman.conf :

XferCommand = /usr/bin/ssl-pacman %u

Enfin...

Voilà, c'est tout !! Il n'y a rien d'autre à faire.

Adaptations...

• Ajouter un certificat pour qu'il soit reconnu par curl: se référer à cette page.
• Ignorer la vérification du certificat (juste chiffrer les flux): ajouter l'option -k à la ligne appelant curl dans le script.
• Ne pas échouer en cas de non support du SSL/TLS par un miroir: utiliser l'option --ftp-ssl au lieu de --ftp-ssl-reqd dans la ligne appelant curl dans le script.
• Chiffrer uniquement le flux de controle: utiliser l'option --ftp-ssl-control au lieu de --ftp-ssl-reqd dans la ligne appelant curl dans le script.
• Autres soucis : lire la page de manuel de curl ou me contacter.

Édition (10 Février 2008) : Ce bogue à été corrigé sur les dépots de la distribution, le 19 Novembre 2007, avec la mise à disposition du paquet cpufrequtils-002-2 .

Juste une version légèrement modifiée du fichier /etc/rc.d/cpufreq fourni par le paquet cpufrequtils, qui met à jour la politique et les fréquence de fonctionnements sur tout les cœurs et/ou processeurs trouvés.

#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

# source application-specific settings
[ -f /etc/conf.d/cpufreq ] && . /etc/conf.d/cpufreq

case "$1" in
start)
stat_busy "Setting cpufreq governing rules"

    params=""
    if [ -n $governor ]; then
        mod="cpufreq_$governor"
        modprobe $mod > /dev/null 2>&1
        params="-g $governor"
        if [ $? -eq 0 ]; then
            if [ "$min_freq" != "" ]; then
                params="$params -d $min_freq"
            fi
            if [ "$max_freq" != "" ]; then
                params="$params -u $max_freq"
            fi
        else
            stat_busy "    Cannot load governor module '$governor'"
            stat_fail
            exit
        fi
    fi

    if [ "$params" != "" ]; then
        for cpu in /sys/devices/system/cpu/cpu*
        do
            cpufreq-set $params -c $(basename $cpu | sed -e 's/cpu//')
        done
        stat_done
    else
        stat_busy "    Invalid configuration in /etc/conf.d/cpufreq"
        stat_fail
    fi
;;
stop)
# nothing to do
;;
restart)
$0 start
;;
set)
# TODO: make callable... "cpufreq set 800MHz"
;;
*)
echo "usage: $0 {start|stop|restart}"  
esac
exit 0

J'ai proposé ce fichier comme solution au bogue n°6440 sur le bugtracker ArchLinux.

Dans un précédent billet, je m'inquiétais du sort réservé à kvm dans la version i686 de ArchLinux. Avec la sortie du noyau 2.6.22, les développeurs ont revus leur choix et intègrent à nouveau kvm dans la version i686:

[root@melody : ~]
# pacman -Q kernel26
kernel26 2.6.22.1-3

[root@melody : ~]
# zgrep KVM /proc/config.gz
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m

Et cerise sur la gateau, le paquet qemu contient un exécutable (/usr/bin/qemu-kvm) avec le support de kvm.

C'est donc une bonne nouvelle, même si, j'aurais (finalement) préféré la solution d'avoir les modules fournis dans un paquet séparé afin de suivre au plus prêt les versions de kvm.

NOTE: une mise à jour sur l'évolution de la situation de kvm avec la sortie du noyau 2.6.22 est disponible ici.

Le problème.

En mettant à jour ma distribution, j'ai eu la mauvaise surprise de constater la désactivation du support de kvm dans le noyau par défaut.

[root@melody : ~]
# pacman -Q kernel26
kernel26 2.6.21.5-1

[root@melody : ~]
# zcat /proc/config.gz | grep KVM
# CONFIG_KVM is not set

Je ne m'attarderais pas sur les raisons qui ont poussé les développeurs à faire ce choix (cf ce fil de discussion et ma réponse).

La solution: on package

Si comme moi vous souhaitez tout de même utiliser kvm sur votre ArchLinux (i686), il faut reconstruire les paquets nécessaires en se basant entre autre sur les travaux effectués par l'équipe de ArchLinux (x86_64). Les paquets à reconstruire sont au nombre de 3:

1. kvm-modules: Dans le PKGBUILD, n'hésitez pas à changer la ligne définissant la variable _kver afin que cette variable corresponde au noyau sur lequel vous souhaitez utiliser kvm.
2. gcc3: La compilation des dernières versions de l'exécutable qemu utilisé par kvm nécessite gcc 3.4.x, or ArchLinux fourni un gcc 3.3.x.
3. qemu-kvm: Pour finir il faut compiler le qemu fourni avec kvm.

Il faut noter que l'exécutable qemu produit est compatible avec le module kqemu présent dans le dépot extra.

Une capture d'écran pour la route.

Comme d'habitude, je ne pouvait pas faire un ticket sans une capture d'écran

Vous y voyez une fedora tournant dans ce qemu+kvm fraichement (ré)installé.

Un mal pour un bien ?

Bien que je ne sois pas d'accord avec cette suppression, elle a au moins le mérite de permettre d'utiliser des versions de kvm plus récentes que celles présentes dans les releases du noyau. Ainsi la version empaquetée ci dessus est la version kvm-28 qui supporte entre autre comme système invité (guest) Windows Vista, ce qui n'est pas possible avec la version kvm-17 fournie dans le noyau 2.6.21 .

J'ai soumis tout ces résultats sur le bugtracker d'ArchLinux en espérant qu'ils soient utiles.

Avec l'été qui approche, les fins d'après-midi s'avèrent souvent orageuses. Ayant récemment fait l'acquisition d'un nouveau PC, je me suis décidé à acheter une protection électrique pour ce dernier, j'ai donc investi dans un onduleur.

Le choix du modèle.

Évidement, l'onduleur doit permettre de passer outre les micros coupures et des surtensions, d'assurer une certaine autonomie sans électricité...mais surtout il doit pouvoir communiquer avec le PC afin d'indiquer à celui-ci que les batteries arrivent à bout, et lui permettre de ce fait de s'éteindre proprement .
Je me suis rappelé un article de GLMF parlant d'un programme de gestion des onduleurs nommé NUT et développé par un employé de la société MGE (dont le siège social n'est pas trop loin de chez moi ;) ). Avec toutes ces informations le choix est simple à faire, ce sera un modèle fait par cette société. Je me lance sans succès à la recherche d'un modèle intéressant parmi les 2~3 boutiques informatiques que je connais sur Grenoble. Ne trouvant pas de modèle me convenant sur place, je passe commande sur un site de VPC d'un pulsar Ellipse 1000 que je reçois quelques jours plus tard.

Déballage, Installation et configuration.

Bien entendu je déballe le tout en vue de l'installation. Parmi tout le nécessaire fourni on retrouve un CD d'accompagnement, que l'on ne regarde pas d'habitude étant réservé a Windows© et MacOS X©, mais cette fois c'est avec un plaisir certain qu'en le regardant l'on trouve des traces de distributions Linux (comme vous pouvez le voir sur la photo ci dessus). Les branchements effectués il est temps de passer à la partie logicielle de l'installation.
Comme je pouvais m'y attendre, celle si se fait sans soucis en suivant la documentation trouvée sur le site de NUT. Les fichiers de configurations sont relativement simple, puisque je n'utilise pas les capacités réseau de NUT, et que la plupart des valeurs par défaut proposées s'avèrent suffisantes.

/etc/ups/ups.conf: (déclaration de l'onduleur)

[slubups]
    driver = newhidups
    port = auto
    pollfreq = 30
    desc = "My UPS"

/etc/ups/upsd.conf: (le seul PC autorisé à se connecter au démon est le PC local)

ACL all 0.0.0.0/0
ACL localhost 127.0.0.1/32

ACCEPT localhost
REJECT all

/etc/ups/upsd/users: (un utilisateur pour l'administration de l'onduleur, et un autre pour la lecture des informations)

[admin]
    password = **un_mot_de_passe**
    allowfrom = localhost
    actions = SET
    instcmds = ALL

[localhostuser]
    password = **un_autre_mot_de_passe**
    allowfrom = localhost
    upsmon master

/etc/ups/upsmon.conf : (configuration du moniteur chargé d'éteindre le PC quand les batteries sont presques vides)

MONITOR slubups@localhost 1 localhostuser **un_autre_mot_de_passe** master
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h +0"
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower
NOTIFYFLAG ONLINE SYSLOG
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG COMMOK SYSLOG+EXEC
NOTIFYFLAG COMMBAD SYSLOG+EXEC
NOTIFYFLAG NOCOMM SYSLOG+EXEC
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

Je poursuis en adaptant légèrement le script de lancementfourni par le paquet ArchLinux. /etc/rc.d/upsd:

#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

OPTIONS="-u root"
PID=`pidof -o %PPID /usr/sbin/upsd`
case "$1" in
        start)  
                stat_busy "Starting UPSd Daemon"
                /usr/bin/upsdrvctl $OPTIONS start &> /dev/null
                [ -z "$PID" ] && /usr/sbin/upsd $OPTIONS &>/dev/null
                if [ $? -gt 0 ]; then
                        stat_fail
                else
                        add_daemon upsd
                        stat_done
                fi
                ;;
        stop)   
                stat_busy "Stopping UPSd Daemon"
                /usr/bin/upsdrvctl $OPTIONS stop &> /dev/null
                [ ! -z "$PID" ] && kill $PID &> /dev/null
                if [ $? -gt 0 ]; then
                        stat_fail
                else
                        rm_daemon upsd
                        stat_done
                fi
                ;;
        restart)
                $0 stop
                sleep 3
                $0 start
                ;;
        *)
                echo "usage: $0 {start|stop|restart}"
    esac
    exit 0

S'en suit l'automatisation du lancement du moniteur au démarrage du système,par l'ajout d'une ligne dans /etc/rc.local:

...
upsmon &
...

Je m'évite un redémarrage en lançant le service et le moniteur:

# /etc/rc.d/upsd start
# upsmon&

À partir de cet instant, mon PC est donc protégé des diverses variations électriques, et surtout si l'onduleur arrive en fin d'autonomie, il s'éteint proprement avant que les batteries ne soient entièrement vides.

Un peu plus loin.

Pour continuer, j'installe un client NUT pour surveiller depuis mon environnement graphique l'état de l'onduleur. Ci dessous vous pouvez voir une capture d'écran du client NUT que j'utilise (il se nomme knutclient ), qui comme vous pouvez le constater est assez complet quant aux informations données :

Le mot de la fin.

Je suis entièrement satisfait de mon achat, après un test, j'atteins 40 minutes d'autonomie sur l'onduleur, ce dernier alimentant :

• mon unité centrale.
• mon écran.
• mon modem-routeur.

Il ne me reste à trouver une solution pour que la détection de l'onduleur fonctionne autrement qu'en root pour que tout soit parfait.
Bref, si vous voulez protéger votre PC je ne saurais que conseiller de soutenir cette entreprise française qu'est MGE.