Tag: GNU/Linux

Brève : copier coller indenté dans vi

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

24 mai 2011 at 21 h 13 minCategorie :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 !

Gestion multi-serveur de Mumble par dbus

Aucun commentaire sur Gestion multi-serveur de Mumble par dbus

18 septembre 2010 at 19 h 14 minCategorie :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

Apache, SSL et hôtes virtuels

Aucun commentaire sur Apache, SSL et hôtes virtuels

8 septembre 2010 at 23 h 18 minCategorie :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.