Tunnel SSH, et rien d’autre

Un commentaire sur Tunnel SSH, et rien d’autre

juin 16, 2011 at 9:33 Categorie :Serveurs

SSH est un outil très polyvalent. Dans certains cas, presque trop !
Oui je sais je suis provocateur. Je vous explique : il y a peu, j’ai voulu fournir une connexion « tunnelisée » à un collègue pour raisons professionnelles. Pour ça, comme vous le savez peut être, SSH et sa fonction de tunneling est idéal.
Je ne vais pas expliquer comment faire du SSH tunneling, Internet est déjà rempli d’articles à ce sujet.
Mon problème à moi, était de fournir cette fonction de tunnel, et absolument rien d’autre.
En effet, on a tendance à l’oublier, mais ouvrir un compte et donner un accès SSH c’est, par défaut, donner énormément de droits. Lecture sur la plupart des répertoires de la machine et exécution de scripts, en sont deux parmi les plus dangereux. Quand la machine est prévue à l’origine en tant que serveur familial et qu’on décide de faire confiance à tous ceux qui y ont accès, le prêt d’une partie de cette machine à un extérieur prend des allures de jeu dangereux et oblige à revoir en profondeur la gestion des comptes.

En mode fainéant, au plus simple, j’ai cherché à atteindre mon but de limitation drastique des droits. Plusieurs étapes sont nécessaires :

– Création d’un compte

sudo adduser invite

Pour ma part, j’ai mis un mot de passe super compliqué que je me suis empressé d’oublier. Je préfère en effet la gestion par clef privé/publique, qui permet une bien meilleure granularité.

– Connexion avec le nouvel utilisateur, puis création d’une clef et copie de sa partie publique dans le magasin des clefs de confiance

sudo su - invite
ssh-keygen
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

La clef privée qui a été générée (id_rsa sans extension) au coté de la clef publique sera celle qu’il faudra fournir à votre invité pour qu’il se connecte.

– Création d’un script très limité faisant office de shell. Par défaut, une connexion SSH exécute un shell (celui défini dans le fichier /etc/passwd pour l’utilisateur), et c’est ce shell qui est chargé de communiquer grâce à ses entrées/sorties standard avec l’utilisateur distant. Un shell standard (bash, sh) permet beaucoup trop de chose. Un shell limité à sa plus simple expression est ce qu’il nous faut. Et si on le codait nous même? En voilà le contenu :

#!/bin/sh
/bin/echo "Bienvenue.
Acces invite restreint, pas de shell !
q pour quitter"
read ans
while [ "$ans" != "q" ]
do
/bin/echo "q (pour quitter) est la seule touche valide"
read ans
done
exit 0

Que fait-il ? Rien, à part attendre la frappe de la lettre « q » qui mettra fin à la connexion. Difficile de faire plus simple.
Placer ce fichier dans un coin de votre disque, en n’oubliant pas de le rendre exécutable à coup de chmod +x

– Arrivé ici, je connais bon nombre de linuxiens qui s’empresserait d’aller coller le chemin du script dans la ligne de /etc/passwd correspondant à l’utilisateur invité. Grave erreur. Si en effet, l’utilisateur se retrouverait alors par défaut connecté à notre nouveau « shell », ceci ne serait que par défaut. Une simple option de la ligne de commande du SSH client permet de choisir le shell de son choix. La solution est d’utiliser les restrictions permises par l’utilisation d’une authentification par clef privée. C’est tout simple, il suffit de rajouter juste avant la clef dans authorized_keys un paramètre forçant la commande exécutée à la connexion de l’utilisateur. Ce qui nous donne par exemple :

command="/home/invite/login.sh" ssh-rsa AAAAB3NT[...]B68w== invite@spammeur.net

– Que nous reste-il à faire? Arrivé ici, l’utilisateur ne peut plus se connecter autrement qu’avec notre shell bidon, mais peut tout à fait exécuter des tunnels, comme nous le souhaitons. Cependant, SSH est vicieux et fourni encore d’autres services. Je pense en particulier au SFTP. Avec un accès SFTP, l’invité est capable d’aller modifier le fichier authorized_keys de son compte pour retirer la restriction de scripts… Réduisant à néant nos efforts pour le limiter ! On pourrait protéger ce fichier par root, et coupler ensuite la protection avec un chrootage « des familles » pour empêcher de surcroît l’indiscret de fouiller le disque, mais faisons au plus simple.
On édite /etc/ssh/sshd_config et on commente comme ceci la ligne suivante :

#Subsystem sftp /usr/lib/openssh/sftp-server

NB : pour une raison inconnue, chez moi commenter cette ligne n’a pas suffit. Qu’à cela ne tienne, aux grands maux les grands remèdes :

sudo mv /usr/lib/openssh/sftp-server /usr/lib/openssh/sftp-serverNO

– On n’oublie pas de recharger sshd avec les nouveaux paramètres :
/etc/init.d/sshd reload

– Dernière chose pour les petits distraits : n’oubliez pas de configurer votre serveur FTP pour empêcher l’accès de l’utilisateur « invite ». De même avec tous les services que vous possédez et qui peuvent se baser sur l’authentification système.

Pfioui, la sécurité, ça n’est pas une mince affaire.

Brève : copier coller indenté dans vi

Aucun commentaire sur Brève : copier coller indenté dans vi

mai 24, 2011 at 9:13 Categorie :Codage

Ah… vi !

On aimerait pouvoir l’oublier, et pourtant on y revient tout le temps. Super puissant selon les ayatollah du kernel, c’est quand même plutôt une vraie plaie pour le reste de l’humanité. En étant honnête, un avantage lui est universellement reconnu : il est disponible sur toutes les plateformes *nix. Si c’est vaguement POSIX, alors vous pouvez taper « vi » et vous êtes sur de disposer d’un éditeur de texte! Bref, ceci en fait l’outil de secours par excellence, et je considère du coup que tout bon informaticien se prétendant un minimum technique doit savoir se dépatouiller -au moins basiquement- avec.

Bref, cet article est surtout une brêve parce que je sais très bien, dans la plus pure tradition de ce blog, que je ne me souviendrai plus comment faire la prochaine fois que je tenterai un copier coller indenté dans vi. Vous ne voyez pas de quoi je parle? Je vous explique. Certaines versions packagés par les distributions les plus récentes incluent des options par défaut qui peuvent être dérangeantes, voir horripilantes. Je pense en particulier à l’indentation automatique. A chaque retour à la ligne, l’indentation de la ligne précédente est conservée. Ça part d’une bonne intention… Mais lorsque on copie colle une belle structure XML, déjà indentée, on est bien marri de se trouver devant un immonde paté structuré n’importe comment car les indentations se sont du coup additionnées.

Hop la solution est ici :

:set paste

L’opération inverse :

:set nopaste

De rien, bonne journée avec vi !

Récupérer un flux XMLTV pour Nolife-TV

2 commentaires sur Récupérer un flux XMLTV pour Nolife-TV

octobre 31, 2010 at 10:03 Categorie :Codage | PC Home Cinema

MISE A JOUR : Cet article n’a plus de sens, car nolife diffuse maintenant son programme TV directement en XMLTV.
Vous trouverez ce flux ici :
http://www.nolife-tv.com/noair/noair_xmltv.xml
Merci à eux !

La bizarre chaîne Nolife, diffusée sur les réseaux TV des opérateurs ADSL, possède quelques émissions intéressantes. Cependant, son statut de petite chaîne artisanale l’exclut d’emblée des sites de programmes TV. Difficile alors de s’y retrouver, notamment quand comme moi on préfère user des fonctions PVR de son Media Center plutôt que du direct.

Heureusement avec un peu d’effort on peut s’en sortir facilement. Nolife diffuse en effet ses programmes dans un format XML « propriétaire », facilement transposable dans un XML plus standard respectant la norme XMLTV. J’ai trouvé au détour d’un forum la feuille XSL d’un généreux donateur qui s’occupe de cette transformation.

Mais cela n’est pas encore parfait. En effet la programmation issue de ce flux « Noair » est pour le moins exhaustive, puisque le détail de tous les clips est donné. Ce qui mène rapidement à quelque chose de complètement illisible… C’est pourquoi j’ai codé rapidement un petit script python, basé sur la librairie XML SAX, qui regroupe  les programmes de même titre et consécutifs.

Il est disponible, en pièce jointe : xmltv-nolife

Note :

  1. Il faut que le programme « xsltproc » soit installé.
  2. Le paramètre « programmes » du script Python recense les différents programmes de Nolife. On ne peut pas en effet se contenter du titre fourni par « noair » car celui ci contient quasiment tout le temps un sous titre dépendant de l’émission du jour.
  3. Il y a une dépendance vers un module python d’Eclipse. Si je n’inclue pas de fichier j’ai un problème d’encodage à l’exécution. J’avoue avoir la flemme de chercher pourquoi. Si vous trouvez, merci de me laisser un commentaire.

Gestion multi-serveur de Mumble par dbus

Aucun commentaire sur Gestion multi-serveur de Mumble par dbus

septembre 18, 2010 at 7:14 Categorie :Logiciels | Serveurs

Mumble est un excellent serveur vocal open-source, qui se veut le concurrent direct de projets commerciaux comme TeamSpeak ou Ventrilo. Il a pour énorme avantage sa faible latence et son excellente qualité audio.

Comme tout serveur de ce genre, il a été créé dans l’optique d’héberger plusieurs instances sur une seule et même machine. Bien entendu comme dans tous les cas de multi serveurs, la configuration automatique est rarement suffisante. Ce point est rarement couvert par les tutoriels trouvables sur Internet, pour la simple raison que ces pas à pas s’adressent principalement à des utilisateurs aux besoins simples. Voici donc un petit bloc note rapide sur sa configuration.

Mumble est pilotable par dbus. Bien que vieillissant et destiné à être remplacé par Ice, je continue à utiliser ce protocole car l’environnement Ice est parfois plus difficile à mettre à place. Avant toute chose, il faut activer dbus dans le fichier de configuration. Je vous laisse positionner le paramètre « dbus » à la valeur « system » dans le fichier (usuellement /etc/mumble/mumble-server.ini). Attention, par l’activation de cette interface de cette manière, toute personne ayant accès à un shell de votre machine devient de facto capable de gérer mumble avec les droits administrateurs.

Je vous présente ensuite ici quelques commandes, qui sont je crois nécessaires et suffisantes à la compréhension de la configuration de son serveur. Avec elles, vous aurez un panorama de ce qu’il est possible de faire :

Lister les méthodes possibles :

dbus-send --system --dest=net.sourceforge.mumble.murmur --type=method_call
     --print-reply / org.freedesktop.DBus.Introspectable.Introspect

Récupérer la configuration du serveur par défaut :

dbus-send --system --print-reply --dest=net.sourceforge.mumble.murmur
     --type=method_call / net.sourceforge.mumble.Meta.getDefaultConf

Paramètrer le mot de passe du serveur par défaut :

qdbus --system net.sourceforge.mumble.murmur / net.sourceforge.mumble.Meta.setSuperUserPassword
     1 supahsecret

Paramètrer le mot de passe du deuxième serveur :

dbus-send --system --print-reply --dest=net.sourceforge.mumble.murmur --type=method_call /
    net.sourceforge.mumble.Meta.setConf int32:2 string:password string:"supersecret2"

Récupérer la configuration du serveur 1 :

dbus-send --system --print-reply --dest=net.sourceforge.mumble.murmur --type=method_call /
    net.sourceforge.mumble.Meta.getAllConf int32:1

Ces commandes ne sont pas exhaustives, mais suffisent à comprendre comment marche l’interaction entre Mumble et dbus. Pour le reste, débrouillez-vous !

à la configuration de son

Un serveur mail Zimbra familial

Aucun commentaire sur Un serveur mail Zimbra familial

septembre 15, 2010 at 5:51 Categorie :Zimbra

Zimbra, le groupware open-source, est un outil de messagerie extrêmement puissant, principalement destiné aux entreprises ou aux grosses associations.
En connaissant cette orientation, lorsqu’on décide de s’installer son propre serveur de mail personnel , Zimbra n’est évidemment pas le premier nom qui vient à l’esprit. On pense plus naturellement à quelque chose comme Roundcube, en conjonction avec divers backend comme le vénérable Postfix et le sympathique Dovecot, ce qui semble bien plus simple et plus adapté à un usage familial.

Et pourtant, après quelque essais, je pense maintenant que Zimbra a parfaitement sa place dans le cercle privé.  Ce n’est pas parce qu’on est un particulier qu’on n’a pas l’usage d’outils avancés de partage de documents, de messagerie instantané, ou de synchronisation avec des clients mobiles. De même, pourquoi ne pas bénéficier du support de qualité offert par une société aux reins solides (d’autant plus après son rachat par Yahoo puis VMware), avec tout ce que cela implique en termes de mises à jours, de suivi, et de pérennité.

Et contrairement aux idées reçues, il est parfois plus simple d’installer un énorme logiciel (que certains qualifieraient à tort d’usine à gaz), que de se battre à intégrer différents petits composants les uns avec les autres. Bien sûr le coté formateur d’une telle installation composite est très appréciable. Mais pour ma part j’ai déjà donné (venu, vu, appris, et passé à la dimension supérieure), et j’apprécie dorénavant de ne lancer qu’un seul script pour installer la dernière version de mon MTA, de Amavis, de l’indispensable SpamAssassin, du serveur IMAP sécurisé, tout en récupérant plein de nouveautés pour la très pratique interface web (et je passe d’autres composants tout aussi indispensable).

Voilà, c’est pour toutes ces raisons que j’ai installé un serveur Zimbra pour mon usage personnel (et familial in extensio, ce serait dommage de garder un tel outil pour soi). Cela n’est pas allé sans quelque gymnastique, bien entendu… Et voilà pourquoi vous lisez cet article : profitez de mes quelques notes, qui je l’espère serviront à d’autres dans l’établissement de leur propre serveur de mail personnel.

Zimbra à travers un Apache déjà existant

Zimbra vient avec son propre serveur HTTP.
Cependant, il est fréquent pour un serveur personnel, d’avoir déjà un LAMP ou autre, qui héberge divers sites ou service. Il est donc plus pratique de garder son propre Apache sur le port standard 80, et de mettre Zimbra sur un autre port (c’est faisable depuis l’interface d’administration qui elle est accessible sur le port 7071 en HTTPS. Dans cet exemple j’ai 82 en HTTP et 445 en HTTPS)
Tout d’abord, chercher sur internet selon votre distribution, il vous faut installer et activer mod_proxy.
Ensuite je pars du principe que vous utiliser les VirtualHost, tant ceux ci sont pratiques.

<VirtualHost *:80>
    ServerName <nom_hote_virtuel>
    ServerAlias <autrenom>
    # Très important pour ne pas transformer votre serveur en open proxy !
    ProxyRequests Off
    # Le proxypass permet de transférer la requête à un autre serveur
    ProxyPass / http://<hote_reel_serveur_zimbra>:82/
    # Le proxypassreverse permet de réécrire les pages html afin
    #de faire pointer les liens à vers l'hôte virtuel et non
    # pas vers le nom d'hôte / port réel.
    ProxyPassReverse / http://<hote_reel_serveur_zimbra>:82/
    <Location "/">
        Order deny,allow
        Allow from all
    </Location>
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost *:443>
    DocumentRoot "/var/www/"
    ServerName <server>
    ServerAlias <autrenom>
    # n'oubliez pas de configurer vous même selon l'emplacement de vos certificats
    SSLEngine on
    SSLCertificateFile <chemin>/server.crt
    SSLCertificateKeyFile <chemin>/server.key
    ProxyRequests Off
    SSLProxyEngine on
    ProxyPass / https://<hote_reel_serveur_zimbra>:445/
    ProxyPassReverse / https://<hote_reel_serveur_zimbra>:445/
    <Location "/">
        Order Deny,Allow
        Allow from all
        BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
    </Location>
</VirtualHost>
</IfModule>

Gérer le spam

Une de mes premières actions a été d’empêcher la suppression du spam. Bien que SpamAssassin soit très efficace, il faut peupler sa base heuristique avant qu’il ne soit capable de trier le bon grain de l’ivraie. En attendant, il est donc sage de réduire à zéro le nombre de spam supprimé, en permettant tout de même le déplacement dans le dossier spam de votre boite mail en  cas de doute.
Ceci se fait depuis l’interface d’administration (paramètres globaux, onglet AS/AV)

Un petit bonus : si le nom de domaine que vous utilisez n’est pas le même que le nom d’hôte de la machine, alors il est possible que vos comptes spams ne soient plus vraiment cohérents avec votre installation. Pour définir de nouveaux comptes spam, vous pouvez passer ces commandes avec l’utilisateur zimbra :

zmprov mcf zimbraSpamIsSpamAccount <adressemailspam>@domain.com
zmprov mcf zimbraSpamIsNotSpamAccount <adresseemailPASspam>@domain.com

Si vous êtes vicieux, laissez trainer l’adresse de spam partout sur Internet. Vous aurez un magnifique pot à miel pour peupler votre base de données à peu de frais.

Optimiser les ressources consommées par Zimbra

Zimbra est très demandeur de ressources, aussi bien CPU que mémoire. En cause : les très nombreux processus d’arrière plan comme par exemple l’indexation, ou encore pour « troller » un peu, le choix du Java. Si votre Zimbra n’est pas très sollicité, alors autant limiter ses ressources dès le départ afin qu’il n’empiète pas sur d’autres services temps réel de votre machine (serveur vocal, etc.)

On commence par un renice régulier des processus de zimbra dans la crontab. Ceci est nécessaire car les processus disparaissent et sont relancés très fréquemment :

*/5 * * * * renice 19 -u zimbra > /dev/null

Pour limiter le nombre de thread disponibles pour les clients, utilisez ces commandes :

zmprov ms this.server.name zimbraHttpNumThreads 50
zmprov ms this.server.name zimbraPop3NumThreads 5
zmprov ms this.server.name zimbraImapNumThreads 10

Pour info, vous pouvez utiliser « zmprov gs » pour récupérer les valeurs actuelles, ce qui vous permettra de vous rendre compte qu’elles sont réellement trop élevées pour une utilisation personnelle.

Passons à la mémoire. Lancez cette commande :

zmlocalconfig mailboxd_java_heap_memory_percent

Vous voyez en lisant le résultat que Zimbra consomme de la mémoire en fonction du total disponible sur votre machine. Plus vous en avez, plus Zimbra va en prendre. C’est pratique, mais ces valeurs sont encore une fois trop importantes pour un faible nombre d’utilisateurs. Pourquoi ne pas les modifier à la baisse? :

zmlocalconfig -e mailboxd_java_heap_memory_percent=25
# Le serveur embarqué mysql fonctionne
# sur le même principe : sabrons le lui aussi !
zmlocalconfig -e mysql_memory_percent=20

Si vous avez comme moi installé le package Debian sur Ubuntu , car la version finale pour votre distribution préférée tardait trop à venir, vous avez peut être un bug qui conduit à une indisponibilité de l’application au bout de quelques heures. Dans ce cas voici un moyen d’éliminer ce bug en gérant les ressources manuellement :

zmlocalconfig -e ldap_read_timeout=0
zmlocalconfig -e ldap_connect_timeout=0

Ensuite éditez /opt/zimbra/jetty/etc/jetty-setuid.xml et mettez la limite de filedescriptor a 524288.
Editez /etc/security/limits.conf  et ajoutez ceci :

root soft nofile 524288
root hard nofile 524288

Empêcher l’open relay SMTP mais permettre les envois locaux

Un vrai danger pour votre machine ! Si celle ci est configurée en open relay, alors toutes machines connectées à internet peut se servir de votre serveur pour envoyer des spams.  Les conséquences sont dramatiques, avec en tête une surconsommation de ressources, et un rapide référencement sur les listes RBL, ce qui conduira votre serveur à être blacklisté par tous les grands services mail destinataires.
Par défaut Zimbra est configuré de façon à empêcher l’open relay. Cependant cela peut être trop restrictif, et vous pouvez avoir besoin de permettre à des services de votre machine d’envoyer des mails par eux mêmes. Pour cela mettez en liste blanche les adresses locales :

mprov modifyServer zimbra.example.com zimbraMtaMyNetworks '127.0.0.0/8 XXX.XX.X.X/32'

Activer le pooling automatique des adresses externes

Afin de d’optimiser l’utilisation de votre nouveau serveur, vous allez certainement configurer une récupération automatique des mails sur votre ancienne adresse. Heureusement, la quasi totalité des fournisseurs permet d’utiliser le protocole POP, ce qui nous permet facilement d’atteindre cet objectif.
Par défaut, pour économiser des ressources dans les environnements avec beaucoup d’utilisateurs, cette récupération de mail externe ne se fait que sur demande de l’utilisateur. Dans le cas d’un serveur familial, le surcoût engendré par un pooling automatique est minime comparé aux avantages ergonomiques. Tout d’abord :

zmprov mc default zimbraDataSourcePop3PollingInterval 10m

Si ça ne suffit pas (notamment pour les comptes externes déjà créés qui risquent de ne pas prendre en compte la modification), effectuez la configuration au niveau de l’utilisateur :

zmprov ma user@domain.com zimbraDataSourcePollingInterval 5m

Ou enfin pour être bien sur, faites le au niveau du compte externe :

zmprov mds user@domain.com [external IMAP/POP account data source name] zimbraDataSourcePollingInterval 15m

Pour récupérer les noms des comptes externes, utilisez cette commande :

zmprov gds user@domain.com

Pour tout annuler, remettez à zéro les valeurs.

Conclusion

Je vais faire court : Si vous avez d’autres astuces, direction les commentaires !

Apache, SSL et hôtes virtuels

Aucun commentaire sur Apache, SSL et hôtes virtuels

septembre 8, 2010 at 11:18 Categorie :Serveurs

J’ai fréquemment lu sur Internet qu’utiliser les hôtes virtuels, en partageant le même couple IP/port par Apache sur SSL était impossible.

La raison avancée est simple : les hôtes virtuels utilisent un champ de l’entête de la requête HTTP pour déterminer quel est le site concerné par la demande. Le problème qui gêne le bon fonctionnement des hôtes virtuels, est que cette entête est chiffrée puisque l’envoi des entêtes intervient après la présentation des certificats. Donc impossible d’identifier le site avant d’avoir envoyé les certificats, alors que cet envoi de certificats requiert d’avoir choisi le site. La boucle est bouclée, les débutants arrêtent de chercher sur les forums, et les achats d’IP supplémentaires augmentent chez les loueurs de serveurs dédiés.

C’était à moitié vrai, c’est complètement faux maintenant. C’est le problème d’Internet : on revient rarement en arrière corriger un vieux message sur les forums. Et les moteurs de recherche étant ce qu’ils sont, de vieilles pages plus du tout actuelles peuvent très bien remonter en haut des recherches.  Mais je diverge.

Donc malgré ce que vous pouvez lire, Apache est maintenant tout à fait capable de gérer les hotes virtuels en SSL.
Comment ? Au choix :
1- Apache (du moins en version 2.3 ou dans la branche 2.2 depuis 2.2.12 grâce à un backport) supporte les extensions SNI, qui permettent au navigateur de présenter le nom de domaine avant d’établir la connexion chiffrée. L’usage de cette extension requiert un navigateur compatible, ce qui inclut tous les navigateurs récents mais exclut le diabolique IE6 (encore et toujours lui). C’est une solution idéale si vous êtes prêts à passer outre ce vieux navigateur qui n’a que trop servi.
2- En utilisant le plus récent TLS, au lieu de SSL, avec le problème étendu de support par les navigateurs. Au passage, c’est la solution d’avenir, mais il vaut mieux l’oublier en attendant qu’il soit plus répandu.
3- Avec une solution plus vieille, qui a ses limitations, mais qui a fait ses preuves dans certains cas particuliers : un seul et même certificat pour tous les sites. On comprend vite qu’avec cette méthode, le problème énoncé en début d’article n’en est plus un. Alors que de base -pour une sécurité accrue- les certificats SSL sont signés à destination d’un seul et unique nom de domaine, il existe donc des variantes permettant les domaines multiples. Vous avez au choix les coûteux certificats wildcard ou l’utilisation de l’extenstion altName. Je vais encore réduire le spectre des solutions et choisir de parler ici du « altName », qui nous autorise à déterminer des noms alternatifs pour notre serveur. Je n’ai pas trouvé directement d’aides  sur Internet couvrant ce sujet du début à la fin avec des commandes simples qui se suffisent à elles-mêmes. D’où ceci :

Un rapide pas-à-pas détaillé

Placez vous dans un répertoire de travail (que je vous laisse créer). On commence par une génération de clés 1024 bits si vous n’en avez pas déjà une :

openssl genrsa -out server.key 1024

On copie ensuite le fichier de configuration d’openssl :

cp /etc/ssl/openssl.cnf .

On édite ce fichier. Dans la section [req] on ajoute (ou décommente) :

[req]
req_extensions = v3_req

Dans la section [v3_req], on ajoute alors la liste des domaines alternatifs sous cette forme :

subjectAltName= DNS:domaine1.org, DNS:autrealternative.domaine1.org, DNS:encoreunautre.com

Maintenant on génère une requête de signature. Si vous êtes riche, vous pouvez utiliser le fichier .csr ainsi généré pour faire certifier votre domaine auprès d’un organisme de confiance comme Thawte ou Verisign. Cela évitera les messages d’avertissement des navigateurs se connectant à votre site sécurisé. Voici la commande pour créer cette requête de signature :

openssl req -new -out server.csr -key server.key -config openssl.cnf

Au lieu d’envoyer votre demande chez les américains, si vous êtes près de vos sous et/ou dans un cadre amateur, ne vous gênez pas pour auto-signer votre certificat :

openssl x509 -req -in server.csr -out server.crt -signkey server.key -extfile openssl.cnf -extensions v3_req

Voilà, vous avez ainsi dans votre répertoire de travail deux fichiers (la clé et le certificat) qui sont suffisants pour faire tourner votre Apache en mode sécurisé !
N’oubliez pas d’activer mod_ssl dans Apache et d’ajouter dans votre configuration d’hôtes virtuels HTTPS les lignes suivantes :

SSLEngine on
SSLCertificateFile <chemin>/server.crt
SSLCertificateKeyFile <chemin>/server.key

Avant de partir, prenez connaissances des limitations de cette solution :  d’une part cette extension n’est pas reconnue par certains très vieux navigateurs (mais, puisque même l’horrible IE6 le fait, on va arrêter les chipotages et remettre au placard Netscape…), et d’autre part tous vos sites alternatifs sont présents dans le certificat en clair, ce qui veut dire que n’importe qui établissant la connexion SSL, peut savoir que ces sites existent sur votre machine.

MythTV et l’extinction automatique pour une machine bureautique/frontend/backend

2 commentaires sur MythTV et l’extinction automatique pour une machine bureautique/frontend/backend

septembre 3, 2010 at 10:03 Categorie :PC Home Cinema

L’une des fonctions d’un Media Center, peut être la plus impressionnante à l’usage,  est sa faculté à se transformer en un puissant magnétoscope numérique.
Une fois bien configuré, mon chouchou MythTV est capable de renvoyer au vestiaire le fameux TiVo, qui est pourtant déjà une petite révolution dans l’usage et la consommation de programmes télévisuels. La consommation différée et massive, à l’origine difficile par l’usage de supports magnétiques volumineux et nombreux, a pris un tournant avec l’apport du numérique, sa facilité de stockage et l’usage ergonomique des outils intelligents qu’il propose.

Pour atteindre cet objectif de super-magnétoscope, il faut avoir bien configurer une option essentielle : l’allumage et l’exctinction automatique de la machine. D’une part pour ne rater aucun enregistrement pour cause de machine éteinte, et d’autre par pour ne pas voir sa facture d’électricité drastiquement augmenter. Bien que simple à énoncer,  cette fonction est très complexe à mettre en oeuvre. Et pourquoi donc? Premièrement, le PC n’a pas été pensé pour ça; et deuxièmement, le grand nombre d’installations possibles rend l’automatisation de la configuration très difficile à mettre en oeuvre. Choix a donc été fait de laisser l’utilisateur final se débrouiller pour faire monter la sauce de lui même. Il faut alors se retrousser les manches et ne pas avoir peur de scripter son installation.

Après cette longue introduction, j’en viens enfin à expliquer le double but de ce billet. D’une part pour faire ce qui n’est pas fait souvent dans les howto, à savoir expliquer ce qui se passe réellement derrière la scène (à l’instar de mon précédent billet sur LIRC). Et d’autre part pour couvrir un exemple pas vraiment explicité dans les différents tutos que j’ai pu trouver : la machine MythTV frontend+backend+desktop.

AVERTISSEMENT : Cet article, qui se veut un complément et non un tutorial aveugle, est donc à apprécier en parallèle de la lecture du howto de mythtv.org sur le sujet.

Allumage et extinction de MythTV, behind the scenes

Le réveil d’un PC à une heure précise se fait par l’utilisation d’une fonction ACPI présente dans la plupart des BIOS des machines vendues au grand public. Cette fonction est activable dans les menus de votre système au démarrage, et charge est ensuite à l’OS de prévoir une interface permettant l’accès en écriture à cette horloge. C’est heureusement le cas de GNU/Linux qui présente généralement le pseudo fichier /sys/class/rtc/rtc0/wakealarm pour cette tâche. Je n’irais pas plus loin, il y a déjà abondance de matière sur le sujet sur Internet.

Petit exercice de logique : le backend de MythTV, seul à être au courant de l’heure du prochain enregistrement, doit  être celui qui configure l’heure du réveil par l’utilisation de cette interface. Afin de ne pas écrire à tout bout de champ dans la petite mémoire de la carte mère, et risquer ainsi de la corrompre ou de l’user, cette écriture doit se faire logiquement à l’arrêt de la machine afin d’assurer son réveil. Ceci implique tout aussi logiquement que MythTV soit l’acteur principal de cet arrêt. Afin de déterminer qu’une machine peut être arrêtée, MythTV va donc utiliser un certain nombre de règles basiques :

  • Est ce que qu’un frontend est connecté ?
  • Est ce qu’un enregistrement est en cours?
  • Est ce qu’un enregistrement arrive très bientôt, et est-il trop tard pour faire un arrêt?

1- Backend seul

Si toutes les réponses à ces questions sont négatives, alors MythTV provoque un arrêt. Et avant d’éteindre la machine, MythTV va écrire dans la mémoire de l’alarme pour le réveil.  Les options (commande d’arrêt, commande d’écriture dans la mémoire, différentes variables temporelles) sont accessibles depuis la configuration du backend.

Si tout s’est bien passé,  vous ne raterez pas votre fantastique Théma « L’histoire des pâtes » sur Arte. Génial non? Pas si vite, ne partez pas !! Il subsiste de nombreux problèmes. Le problème d’une telle solution est son manque de souplesse, car elle ne s’applique que pour une machine faisant office de backend seul. Un exemple : ma mythbox, à la fois frontend et backend, est configurée pour lancer une session et un frontend automatiquement au démarrage. C’est indispensable à mon avis si son usage principal est de traîner sous votre TV et non pas dans un grenier. Comment en effet envisager un Media Center qui afficherait au démarrage une odieuse fenêtre de login ou un simple environnement de bureau?
Le problème d’un tel démarrage dirigé vers un frontend, c’est que la machine ne s’arrêtera  jamais, même à la fin de l’enregistrement, car un frontend sera toujours connecté.

2- Backend et frontend.

Bien sûr, les développeurs/utilisateurs de MythTV ont  pensé à çà, et ont créé MythWelcome. Nous voilà donc dans le cas d’une machine frontend + backend avec démarrage automatique de session et de frontend.
MythWelcome est un sympathique programme qui sera lancé à la place de votre frontend et déterminera que faire : si le démarrage semble être manuel (si aucun programme à enregistrer n’est visible dans la tranche horaire à venir), alors un frontend est lancé par dessus. Si le démarrage est automatique, MythWelcome reste le seul programme lancé, et comme il ne se connecte pas au backend, ce dernier éteindra la machine en se croyant tout seul.
Autre situation : le fontend est lancé par MythWelcome; à la fin de la session, on quitte MythTV; MythWelcome repasse alors au premier plan et l’extinction peut avoir lieu dès que le backend l’a décidé.
Comme MythWelcome possède d’autres atouts dans sa manche (plage horaire de réveil automatique, verrouillage empêchant l’extinction), les développeurs ont choisi de lui confier à lui et son partenaire « mythshutdown », plutôt qu’au backend, la logique de gestion de l’arrêt de la machine. Les options (commande d’arrêt, commande d’écriture), sont désormais du ressort de MythWelcome et configurables depuis son interface. Il est bien sur nécessaire de configurer le backend afin qu’il délègue sa gestion à MythWelcome. Ceci explique l’usage de la commande mythshutdown que l’on constate dans les différents tutos sur le sujet disponibles sur Internet : le backend délègue le contrôle à cet outil bien pratique qui utilise les paramètres de MythWelcome.

Une petite subtilité que j’ai apprise à mes dépends : La commande

Command to set Wakeup Time             : mythshutdown --setwakeup $time

est un piège. Elle n’écrit en fait pas dans l’heure de réveil du bios, seulement dans la base de données. C’est en effet la commande

Server halt command                    : mythshutdown --shutdown

qui s’occupe de l’écriture, ainsi que de l’arrêt de la machine. Le but de ce changement est de permettre à MythWelcome de prendre en compte les plages de réveil quotidienne que vous pouvez configurer.
C’est une différence de fonctionnement fondamentale avec la configuration « simple » de MythTV vu dans le paragraphe « backend seul ». Vous aurez besoin de cette information si vous avez un problème et chercher à debugger votre environnement.

Super ! Voilà donc le cas d’un frontend + backend couvert. Mais qu’en est-il des autres combinaisons impliquant un backend?

3- Le combo backend et desktop.

Celui ci est vicieux. On souhaite se servir de son PC pour autre chose qu’un « simple » enregistreur Media Center.
La seule difficulté est d’empêcher MythTV d’éteindre le PC lorsqu’aucun frontend n’est connecté. MythWelcome et sa fonction de lock peuvent être utilisés pour ça, mais ce serait un détournement de sa fonction, loin d’être ergonomique qui plus est : qui aimerait voir un écran bizarre d’enregistreur numérique se lancer à l’ouverture de sa session alors qu’il souhaite juste aller consulter ses mails? Non, la solution est encore une fois décrite sur le wiki de mythtv (rubrique desktop user). On fait un petit script détectant si un utilisateur est connecté au système. Si oui, alors MythTV n’a pas le droit d’éteindre la machine. Tout simple et évident. Dans cette configuration, c’est le setup de MythTV qui est responsable de la configuration de cet ensemble, aidé d’un script de pré-extinction contrôlant les utilisateurs connectés. Ceci implique aussi d’empêcher toute extinction manuelle du système (ou alors avec un script utilisant mythshutdown).  On veillera donc du coup  à autoriser uniquement les utilisateurs à se « déconnecter », probablement par la configuration de votre environnement de bureau.

Le véritable problème arrive, avec la dernière combinaison impliquant un backend. Et c’est sur ce point que je n’ai pas vraiment vu de tutos sur Internet.

Le triple combo backend-frontend-desktop

Voilà la situation : une machine enregistrant la télévision en arrière plan, servant principalement de frontend, mais pouvant aussi dépanner pour n’importe quel tâche habituellement dévolue à la bureautique (photos, mail, vidéos de lolcat sur internet).

Dans cette configuration, voici le cahier des charges :

  • Allumage automatique sur le frontend
  • Pas d’extinction automatique si en cours d’usage bureautique
  • Allumage automatique pour un enregistrement
  • Extinction automatique après un enregistrement suite à un allumage automatique

Le point 1 et 4 implique l’utilisation de MythWelcome.
Le point 2 implique l’utilisation du script de détection d’utilisateur connecté.
Problème : si une session est lancée au démarrage, accompagnée de MythWelcome, alors le script de détection d’utilisateur connecté empêchera toujours MythTV d’éteindre la machine, ce qui ne respecte pas le point numéro 4.

Une solution sous entendue par les tutos du site MythTV, mais jamais énoncée directement, est d’utiliser la fonction de lock offerte par MythWelcome. En verrouillant l’arrêt, on se prémunit du problème et on peut alors utiliser son PC de façon bureautique. Le problème est qu’il faut ensuite enlever ce verrou, soit en lançant de nouveau MythWelcome, soit par une ligne de commande, raccourci, ou touche de télécommande configurée de façon adéquate. On a vu mieux au niveau ergonomie.
Lorsque j’ai configuré une telle machine pour mon environnement familial, j’avais des besoins très clairs : aucune contrainte superflue. Le verrou de MythWelcome dans cette situation d’usage bureautique en était clairement une. MythWelcome doit se faire complètement oublier. Si je veux cliquer sur le menu K et demander l’arrêt de l’ordinateur, je veux pouvoir le faire sans penser à déverrouiller l’extinction automatique qui doit avoir lieu.

La solution à mon problème est une petite modification toute bête du script de détection de l’utilisateur :

# Check to see if anyone is currently logged in. Return zero if not and 1 if so.
# Echoed text appears in log file. It can be removed and --quiet added to the
# grep command once you are satisfied that mythTV is working properly
result=1
#
if
    mythshutdown --check
then
    echo mythshutdown ok to shut
    result=0
else
    result=1
    echo mythshutdown not ok to shut
    echo result : $result
exit $result
fi
#
if
    w | grep -v grep | grep " 0 user"
then
    echo `date` " No one is logged in, ok to shut down." #>> /home/mythtv/.mythtv/extinction.log
    result=0
else
    echo `date` " Someone is still logged in, do not shut down?" #>> /home/mythtv/.mythtv/extinction.log
    if
        ps -edf | grep mythwelcome | grep -v grep
    then
        echo `date` " Mythwelcome is launched, so its ok to shut" #>> /home/mythtv/.mythtv/extinction.log
        result=0
    else
        echo `date` " No mythwelcome, no shutdown" #>> /home/mythtv/.mythtv/extinction.log
        result=1
    fi
fi
#
echo result : $result
exit $result

Ce script est à lancer en prérequis de tout arrêt. C’est à dire qu’il faut le placer à « Pre Shutdown check-command » dans la configuration de MythTV, à la place du « mythshutdown –check » mentionné pour la mise en place de MythWelcome. C’est d’ailleurs pour cette raison que la première tache de ce script est d’appeler « mythshutdown –check » pour effectuer les vérifications qui lui sont liées.

Ce script vérifie si un utilisateur est connecté. Si non, alors l’arrêt est autorisé (c’est par exemple le cas d’un utilisateur qui s’est déconnecté de la session). Si oui, alors il vérifie si MythWelcome est lancé. Si MythWelcome n’est pas lancé, alors c’est qu’on est en train de faire un usage bureautique de sa machine et qu’il ne faut pas s’éteindre. Mais si MythWelcome est lancé, alors nous avons là une exception à la règle interdisant l’arrêt si un utilisateur est connecté, et il est donc possible d’éteindre la machine.  Ce script étant lancé par le backend MythTV après ses propres vérifications (frontend lancé?), on ne risque pas d’interrompre une session de visualisation malgré le fait que MythWelcome soit toujours lancé lorsqu’on utilise le frontend. Vous m’avez suivi j’espère?

Bonus : Déconnexion par la touche d’une télécommande

Dans ce cadre, j’ai eu à rechercher comment déconnecter l’utilisateur par l’action d’une touche de la télécommande (toujours dans l’optique de s’affranchir au maximum des contraintes du retour à MythWelcome). Voici la commande magique valable pour KDE 4:

/usr/bin/qdbus org.kde.ksmserver /KSMServer logout 0 2 0

Il est ensuite facile de combiner cette commande avec LIRC et irexec pour qu’une touche lance le processus « sûr » d’arrêt de votre machine. Vous pouvez aussi utiliser mythshutdown à la place pour que l’arrêt soit direct plutôt que temporisé.

Pre Shutdown check-command

MythTV, les SSD et le démarrage trop rapide

Aucun commentaire sur MythTV, les SSD et le démarrage trop rapide

août 29, 2010 at 2:56 Categorie :PC Home Cinema

Souvent, les nouvelles technologies ont des problèmes de jeunesse. Fréquemment, elles n’apportent pas vraiment tous les bénéfices auxquelles on s’attendait. Et parfois même, elles marchent trop bien.

La drôle d’expérience que j’ai eu l’occasion de vivre avec un SSD fait partie de ce dernier cas.

Un des avantages du disque SSD, bien connu et qui fait baver de nombreux adeptes des benchmark, est la rapidité de démarrage du système. Dans le contexte d’un PC Home Cinema, cette caractéristique en fait un véritable « must-have », un petit plus pouvant drastiquement améliorer le WAF. C’est donc tout naturellement que, après l’achat, j’ai pris un plaisir non dénué de fierté puéril à découvrir que mon système pouvait être « prêt » (frontend MythTV lancé) en moins de 20 secondes, départ arrêté depuis grub, et ce sans optimisation particulière et alors même que j’utilise un environnement de bureau plutôt lourd (KDE). Bref, tout à fait ce que j’attendais.

Mais oh, surprise, les démons de l’informatique ont déterminé qu’il était important de me fournir matière à article, et ont donc introduit un effet de bord particulièrement vicieux : mon système démarre parfois trop vite. Ou plus exactement, MythTV se lance trop rapidement ! Alors même que je ne suis pas passé au massivement parallèle Upstart, restant fidèle au bon vieux init de System V que je maîtrise bien, le démarrage pourtant essentiellement séquentiel de mon système arrive quand même à faire des siennes. J’explique :

Symptôme : le vilain écran me demandant de rentrer les paramètres du backend à la main apparaît une fois sur deux, car le backend mentionné dans la configuration n’est pas joignable.
Cause : l’interface réseau est trop lente à se rendre disponible, les logiciels sont chargés bien plus vite que la normale, et les requêtes TCP à destination d’autres machines de mon réseau local n’aboutissent parfois  pas au moment du démarrage.
Remède : un petit script quick-and-dirty super simple qui ping ma machine principale avant de lancer MythTV. Il suffit ensuite d’appeler ce script par votre lanceur habituel en lieu et place du lanceur du frontend MythTV.

#!/bin/bash

killall mythfrontend
killall mythwelcome

ping -c2 192.168.0.1 > /dev/null
result=$?
while [ $result -ne 0 ]
do
sleep 1
#bonus : vous pouvez glisser ici un petit réveil par le réseau.
#wakeonlan -i 192.168.0.255 <adresse_mac>
ping -c2  > /dev/null
result=$?
done

mythfrontend &

Bonus

La même chose peut être valable pour lancer le backend sur une machine trop rapide. Il faut donc adapter le script /etc/init.d/mythbackend et ajouter le même genre de test simplet.
Je vous offre une petite subtilité gratuite qui mérite à elle seule cette section bonus : attention à ne pas oublier de commenter l’éventuelle ligne « set -e » ! Celle-ci à pour intéressante (et détestable dans notre cas) particularité de commander l’interruption complète du script dès lors qu’une des commandes n’a pas retourner le code ok (zéro en bash). Vous vous doutez bien que cette option est invalidante quand on cherche à tester par ping une machine susceptible de ne pas répondre.

MP3 : faire sauter les caractères spéciaux

Aucun commentaire sur MP3 : faire sauter les caractères spéciaux

août 21, 2010 at 12:25 Categorie :Logiciels

Les amateurs de musique numérique vous le diront : avoir une collection musicale conséquente et « propre » sur son PC relève de la gageure.

En effet, à moins d’avoir acheté toute sa bibliothèque sur une boutique spécialisée (et encore), on se retrouve bien vite avec un ensemble hétéroclite de tags, de noms de fichiers, et de coverart.  Un tout incohérent qui ne facilite pas la recherche ou la gestion.

Heureusement d’excellents logiciels peuvent vous aider. Ce n’est pas le but de l’article, donc je ne citerai que le formidable Picard, du projet communautaire MusicBrainz, et son énorme base de données facilitant la pose de tag sur des albums entiers.

Même une fois le « taggage » terminé, on peut se retrouver avec de mauvaises surprises. Nombreux sont les lecteurs (qu’il s’agisse de logiciels ou de baladeurs) qui gèrent mal les encodages internationaux. L’éternel cauchemar UTF/ISO8859 du développeur, réactualisé pour l’amateur de musique. La solution la plus simple et que j’ai adopté : on dégage tout ce qui peut poser problème !

J’ai piqué sur un forum (merci à l’auteur) un script pour le logiciel MP3TAG qui remplit cet office. Plutôt que de me contenter du  lien, qui finira quasi certainement par ne plus marcher un jour, je me permets de recopier le script et de donner la procédure d’utilisation :

Copier le fichier dans le répertoire de données utilisateur de MP3Tag, par exemple pour Windows XP « X:\Documents and Settings\<nom d’utilisateur>\Application Data\Mp3tag\data\actions « ,   et « X:\Users\<nom d’utilisateur>\AppData\Roaming\Mp3tag\data\actions » pour Seven
Une fois que c’est fait, dans Mp3tag vous devriez pouvoir trouver le script dans la liste des actions.

Mon seul regret est de dépendre d’un logiciel qui n’est ni multi-plateforme, ni open-source. Si au hasard d’une recherche vous tombez sur cet article et connaissez des alternatives libres, je serai heureux de les voir dans les commentaires.

Jouer à Planescape Torment en 2010

Aucun commentaire sur Jouer à Planescape Torment en 2010

août 20, 2010 at 11:40 Categorie :Jeux

Planescape Torment est sans hésitation mon jeu préféré : un de ces jeux qui, malgré ses défauts, se teintent d’une magnifique aura de de magie et de nostalgie au fur et à mesure que le temps passe. Celui dont on se souvient de temps en temps, au détour d’une madeleine de Proust toute personnelle. Celui qui nous fait regarder dédaigneusement les productions récentes, toutes pleines de shaders, mais sans le supplément d’âme qui fait qu’un jeu comme Torment s’inscrit de façon indélébile dans les mémoires.

Pour ceux qui ne connaissent pas (mais que faites vous là alors?), voilà la fiche sur GrosPixel qui résume assez bien mon avis.

Pour les autres, voici quelques trucs pour le faire tourner sans subir l’effet « c’est-étrange-ça-me-semblait-pas-si-moche-à-l’époque ». Je précise que je n’invente rien, ayant pris toutes les infos au détour d’un message de forum. Je remercie l’auteur et ne fais donc que mettre à disposition les fichiers qui vont bien, ainsi que la procédure.

Voici l’archive contenant tout ce dont vous avez besoin, avec les répertoires numérotés correspondant aux étapes.

Et voilà la procédure :

  1. Installer le jeu
  2. Installer le patch officiel
  3. Copier le contenu des CDs 2 – 3 – 4 chacun dans un répertoire propre
  4. Editer le fichier Torment.ini, et remplacer les chemins des CDs 2, 3 et 4 sur ce modèle CD2:=X:\<CHEMIN>\Torment\NOM_REPERTOIRE_CD2\
  5. Installer les dialogues français : écrasez les anciens
  6. Installer le fixpack SANS les corrections de grammaires anglaises ! (décompressez dans le répertoire d’install et lancez le .exe)
  7. Installer le mod Unfinished Business comme le précédent mod
  8. installer le mod écran large comme le précédent mod. Choisissez votre résolution, attention les fontes plus grandes sont réservées à la version US.
  9. Installer le mod d’interface GhostDogs pour avoir des menus à votre résolution. Toujours de la même façon que les mods précédents

Un conseil : si vous avez la possibilité de faire tourner le jeu dans une machine virtuelle faisant tourner Windows XP ou 98, faites le. Dans le cas contraire, si vous rencontrez des problèmes , n’hésitez pas à baisser les options graphiques dans les menus de configuration du jeu. Voir peut être même dans les options de Windows (paramètres d’accélération matérielle de la carte graphique). Et si cette baisse de l’accélération introduit des problèmes de performances, alors installez le fixpack facultatif numéroté 10 dans le pack.

Bon jeu.

AJOUT 2013 : Aux détours du web, je suis tombé sur un autre excellent guide d’installation.