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