To content | To menu | To search

Tuesday 28 November 2006

Linux + gVim + Rox-filer = Mon IDE.

Une des questions cruciales qui se pose à tout développeur à au moins un moment de sa vie (souvent plusieurs en fait) est le choix d'un environnement de développement. J'en ai testé pas mal, plus ou moins longtemps, et bien que je ne sois jamais complètement satisfait, l'idée de perdre du temps à développer le mien m'indispose. J'ai donc opté pour l'environnement qui me va le mieux: Linux + gVim + Rox-filer.

Note: je ne couvre pas ici les fonctionnalités de débuging avancé, que je n'utilise pas encore, mais pour lesquelles j'ai déjà en tête des solutions qui me conviendront bien mieux que les outils intégrés à un quelconque IDE (je pense fortement à Xdebug).

Continue reading...

Thursday 9 November 2006

Migrer un dépot subversion

Imaginons que vous souhaitiez déplacer votre dépôt subversion myproject d'une machine old-server à une machine new-server. Vite fait, bien fait:

old-server# svnadmin dump /var/lib/subversion/myproject > ~/myproject.svndump
old-server# scp ~/myproject.svndump new-server:
new-server# svnadmin create /var/lib/subversion/myproject
new-server# svnadmin load /var/lib/subversion/myproject < ~/myproject.svndump

Attention, il vous faut par contre migrer vos éventuelles hooks à la main, ils ne sont effectivement pas gérés par svndump. Une autre méthode, incluant les hooks celle-ci, serait d'utiliser svnadmin hotcopy, mais je n'ai pas testé.

Plus d'infos:

Wednesday 1 November 2006

Incubated

Les liens interressants (ou pas) de la semaine:

Continue reading...

Friday 20 October 2006

Relayer un stream audio avec icecast2

Pour économiser la bande passante au boulot, j'ai décidé de relayer le stream Club ! de 1.fm sur le LAN. Après avoir vainement tenté d'utiliser streamripper (on verra plus tard pourquoi vainement), j'ai sorti l'artillerie lourde: icecast2:

sudo apt-get install icecast2

Si on sait un peu lire, le script de post-configuration nous incite à aller fourrer notre nez dans /etc/default/icecast2, où l'on apprend (vers la fin) que icecast est désactivé par défaut à cause de la directive ENABLED=false. C'est en fait une feinte pour nous pousser à configurer le bousin (de toute façon si on le configure pas, il marchera pas). Direction /etc/icecast2/icecast.xml donc, pour un brin de configuration (les explications qui suivent se basent sur le fichier par défaut d'une installation sur une ubuntu).

La première partie qui nous interresse s'intitule authentication (vers la ligne 23). Elle contient les informations d'authentification pour les clients qui se connectent en tant que source (source-password), les serveurs qui se connectent en tant que slave (relay-password, en fait je ne suis pas sur à 100%, c'est une déduction) et pour l'interface d'administration (admin-user et admin-password). Une fois ces informations modifiées, direction la directive hostname, qu'on remplira avec au choix, le nom de la machine, son ip, etc. J'ai personellement mis l'ip privée de ma machine (172.16.x.y), pour que ça correspondent à la prochaine directive qui nous interresse: listen-socket. Ici on définit le port et l'ip sur laquelle icecast va écouter. En gros, si vous spécifier 127.0.0.1, votre serveur de streaming ne sera accessible qu'en local. On y met donc en général la même chose que dans hostname (172.16.x.y par exemple), avec un port qui va bien, libre de préférence (8000 par défaut).

Maintenant on passe a la partie qui nous interresse vraiment, la section relay. Rien de bien compliqué ici. Le stream que je souhaite relayer se trouve là: http://64.62.253.223:8060/, or icecast nous demande un server, un port, un point de montage (mount) et un point de montage local (local-mount). Vous avez déjà compris qu'on arrive a cette configuration:

   <relay>
       <server>64.62.253.223</server>
       <port>8060</port>
       <mount>/</mount>
       <local-mount>/1.fm</local-mount>
       <on-demand>0</on-demand>
       <relay-shoutcast-metadata>1</relay-shoutcast-metadata>
   </relay>

Ainsi parés, il ne nous reste plus qu'a lancer modifier la directive ENABLED=false en ENABLED=true dans /etc/default/icecast2 et à lancer icecast:

sudo /etc/init.d/icecast2 start

Si vous avez bien tout fait, vous devriez pouvoir streamer depuis http://172.16.x.y:8000/1.fm, et vos collègues également ! Vous pouvez avoir une vue d'ensemble du serveur ainsi que quelques options d'administration en vous rendant sur l'interface d'admin: http://172.16.x.y:8000/ et en utilisant admin-user et admin-password pour vous authentifier.

A cela on peut ajouter un petit streamripper:

streamripper http://172.16.x.y:8000/1.fm -d ~/streamripped

Pour enregistrer. En parlant de streamripper, j'avais tenté au début de relayer avec streamripper -r, mais malgrès les apparences du netstat -pl (*:8000 LISTEN), il ne bind qu'en local, donc impossible d'en faire profiter les collègues :-)

Vous prendrez bien un peu de ssh avec votre tunnel ?

Il arrive des fois où on aimerait pouvoir relier directment deux machines appartenant a deux réseaux distincts. C'est par exemple mon cas quand j'ai besoin (envie on va dire) d'accéder à ma machine du boulot depuis une machine non connectée au VPN. Dans ce genre de cas, il existe en général une machine qui possède des interfaces susceptibles d'accéder à chacune des machines (le concentrateur VPN par exemple). Nous appellerons cette machine relay, car elle servira de relai au tunnel. Pour éviter les sempiternelles appellations A et B qui embrouillent plus qu'autre chose, les machines s'appelleront startpoint pour la machine sur laquelle on a la main et endpoint pour la machine à laquelle on souhaite accéder.

Postulats de base:

  • relay possède un serveur SSH qui tourne
  • startpoint possède un client SSH capable de créer un tunnel (ssh, par exemple)
  • relay est accessible depuis startpoint et peut se connecter à endpoint

Bien, allons y franchement, la commande, à executer depuis startpoint, permettant de créer un tunnel SSH entre startpoint et endpoint est la suivante:

ssh -L 2222:endpoint:22 relay

Qu'avons nous fait là ? L'option -L de SSH sert à binder un port de la machine locale (startpoint donc), à un autre port (ou le même) de la machine distante (endpoint). Ici, on associe le port local 2222 (22 étant déjà pris par mon serveur SSH, mais on pourrait utiliser le port 22 si aucun serveur ne tournait, à la différence près qu'il faudrait lancer la commande en root pour pouvoir binder un port inférieur à 1024 (c'est comme ça)) au port 22 de endpoint, c'est à dire le serveur SSH. Il nous est dès lors possible d'ouvrir une connection SSH sur endpoint en se connectant au port 2222 de notre machine locale:

ssh -p 2222 localhost

Magique non ? Bien sur, il est possible de forwarder n'importe quel port au travers du tunnel:

ssh -L 8080:endpoint:80 relay

Faire pointer votre navigateur sur http://localhost:8080/ vous ammenera sur le serveur web de endpoint.

Mais un tunnel ne se limite pas à joindre deux machines d'un réseau différents. On peut également imaginer un tunnel entre deux machines dans l'unique but de sécuriser une transmission, par exemple, des échanges de mails. Imaginons que votre serveur mail preferré, pop.example.com, ne propose pas de connection POP sécurisée. Vous pouvez remédier à ce manque flagrant de confidentialité en créant un tunnel SSH:

ssh -L 1100:localhost:110 pop.example.com

Bien sur, ce cas de figure nécessite d'avoir un compte permettant une connexion SSH sur pop.example.com, ce qui n'est pas forcément le cas. Pour remédier a ceci, deux solutions: utiliser un relay qui possède un serveur SSH, ou installer un serveur SSH sur startpoint pour s'en servir comme relai (sudo apt-get install openssh-server sur toute distribution debian-like qui se respecte):

ssh -L 1100:pop.example.com:110 localhost

And voila, il n'y a plus qu'a indiquer à notre client mail que le pop se situe sur localhost au port 1100, et le tour est joué :-)

Sunday 13 August 2006

Liste de fichiers avec grep

Quand on cherche à récupérer une liste de fichiers contenant un motif particulier sous UNIX, on peut, quand on est une grosse brute comme moi, utiliser un mix des commandes grep, cut et uniq:

grep -r motif /emplacement/des/fichiers/ | cut -d : -f 1 | uniq

Le truc, c'est qu'il existe une option de grep qui remplace avantageusement l'appel a cut:

grep -rl motif /emplacement/des/fichiers | uniq

Je ne sais pas si l'option -l traite les doublons, a vérifier.