Planet GCU

Dernière étape de la migration des services de l’ancien iMil.net vers son nouveau foyer: icecast.

Alors que je me préparais à l’enfermer dans un chroot comme quelques-uns de ses petits camarades, je me suis souvenu que icecast supportait déjà cette fonction. Sa configuration est une promenade de santé.

Après l’avoir installé via un bête pkgin in icecast-2, l’édition de son fichier de configuration, si l’on fait abstraction de cette saloperie de format XML, est assez rapide, voici les sections qu’il vous faudra renseigner dans le fichier /usr/pkg/etc/icecast/icecast.xml afin de rapidement diffuser du son sur l’intarwebz :

[...]
    <authentication>
        <!-- Sources log in with username 'source' -->
        <source -password>motdepassecomplique</source>
        <!-- Relays log in username 'relay' -->
        <relay -password>motdepassecomplique</relay>

        <!-- Admin logs in with the username given below -->
        <admin -user>admin</admin>
        <admin -password>motdepasseencorepluscomplique</admin>
    </authentication>
[...]
    <hostname>ta.radio.quidemonte.net</hostname>
[...]
    <paths>
                <!-- basedir is only used if chroot is enabled -->
        <basedir>/var/chroot/icecast</basedir>
        <!-- Note that if <chroot> is turned on below, these paths must both
             be relative to the new root, not the original root -->
        <logdir>log/</logdir>
        <webroot>web/</webroot>
        <adminroot>admin/</adminroot>
        <pidfile>/var/chroot/icecast/icecast.pid</pidfile>
[...]
    <security>
        <chroot>1</chroot>
        <changeowner>
            <user>icecast</user>
            <group>icecast</group>
        </changeowner>
    </security>

</paths>

On notera que la directive chroot est à 1 et que les path sont relatifs au chroot, ce qui nous donne /var/chroot/icecast/{web,log,admin}. Il sera enfin nécessaire de copier le contenu des repertoires /usr/pkg/share/icecast/{web,admin} dans leurs équivalents chrootés, puis de configurer le démarrage automatique d’icecast :

# cp /usr/pkg/share/examples/rc.d/icecast /etc/rc.d/
# echo "icecast=YES" >> /etc/rc.conf
# /etc/rc.d/icecast start

À toutes fins utiles, je colle ici la configuration du client ices2, qui permet le streaming effectif d’une source audio :

$ cat etc/ices2.xml
< ?xml version="1.0"?>
<ices>

    <!-- run in background  -->
    <background>0</background>
    <!-- where logs go. -->
    <logpath>/var/log/ices</logpath>
    <logfile>ices.log</logfile>
    <!-- size in kilobytes -->
    <logsize>2048</logsize>
    <!-- 1=error, 2=warn, 3=infoa ,4=debug -->
    <loglevel>4</loglevel>
    <!-- logfile is ignored if this is set to 1 -->
    <consolelog>0</consolelog>

    <!-- optional filename to write process id to -->
    <!-- <pidfile>/home/ices/ices.pid -->

    <stream>
        <!-- metadata used for stream listing -->
        <metadata>
            <name>Du bon SON</name>
            <genre>Du qui tape</genre>
            <description>Du qui fait que tu put tes hands in the air</description>
            <url>http://ta.radio.quidemonte.net:8000</url>
        </metadata>

        <!--    Input module.

            This example uses the 'oss' module. It takes input from the
            OSS audio device (e.g. line-in), and processes it for live
            encoding.  -->
        <input />
            <module>alsa</module>
            <param name="rate">48000</param>
            <param name="channels">2</param>
            <param name="device">hw:0,0</param>
            <!-- Read metadata (from stdin by default, or -->
            <!-- filename defined below (if the latter, only on SIGUSR1) -->
            <param name="metadata">1</param>
            <param name="metadatafilename">test</param>

        <!--    Stream instance.

            You may have one or more instances here.  This allows you to
            send the same input data to one or more servers (or to different
            mountpoints on the same server). Each of them can have different
            parameters. This is primarily useful for a) relaying to multiple
            independent servers, and b) encoding/reencoding to multiple
            bitrates.

            If one instance fails (for example, the associated server goes
            down, etc), the others will continue to function correctly.
            This example defines a single instance doing live encoding at
            low bitrate.  -->

        <instance>
            <!--    Server details.

                You define hostname and port for the server here, along
                with the source password and mountpoint.  -->

            <hostname>ta.radio.quidemonte.net</hostname>
            <port>8000</port>
            <password>motdepassecomplique</password>
            <mount>/jumpjump.ogg</mount>
            <yp>0</yp>   <!-- allow stream to be advertised on YP, default 0 -->

            <!--    Live encoding/reencoding:

                channels and samplerate currently MUST match the channels
                and samplerate given in the parameters to the oss input
                module above or the remsaple/downmix section below.  -->

            <encode>
                <quality>0</quality>
                <samplerate>48000</samplerate>
                <channels>2</channels>
            </encode>

            <!-- stereo->mono downmixing, enabled by setting this to 1 -->
            <downmix>0</downmix>

            <!-- resampling.

                Set to the frequency (in Hz) you wish to resample to, -->

            <!--resample>
                <in -rate>44100</in>
                <out -rate>44100</out>
            </resample -->
        </instance>

    </stream>
</ices>

Et voila ! Ton petit monde peut désormais écouter tes exploits sur http://ta.radio.quidemonte.net:8000/jumpjump.ogg

Je rappelle également que dans 2 semaines, c’est la Miami Winter Conference 2010, que c’est le 25ème anniversaire de cette grand messe, et qu’ILS y seront.

Ça y est. Enfin. Ça va recommencer.

Contre toute attente, la migration de mon IPBX perso a été parfaitement sans douleur. Après l’installation de la toute dernière version d’Asterisk sur mon domU NetBSD à l’aide de pkgin (puisqu’aucune option particulière ne m’était nécessaire), je me suis souvenu d’un article que j’avais initialement écrit sur le site Freephonie.org, dans lequel j’expliquais les diverses manipulations pour monter un Asterisk fonctionnel derrière du NAT.
Comme souvent, l’article a été peaufiné par quelques contributeurs, et son contenu est tout à fait valide pour la configuration d’un Asterisk 1.6.

Ainsi, mon dom0 GNU/Linux possède les règles suivantes :

# on accepte le traffic SIP et une plage destinée au RTP
-A INPUT -p udp -m udp --dport 5060 -j ACCEPT
-A INPUT -p udp -m udp --dport 10000:10100 -j ACCEPT
# On accepte le forward pour ces memes ports vers le domU qui accueille le PBX
-A FORWARD -d 10.20.30.1/32 -i eth0 -p udp -m udp --dport 5060 -j ACCEPT
-A FORWARD -d 10.20.30.1/32 -i eth0 -p udp -m udp --dport 10000:10100 -j ACCEPT
# On reroute le traffic vers ces ports sur le domU adéquat
-A PREROUTING -i eth0 -p udp -m udp --dport 5060 -j DNAT --to-destination 10.20.30.1
-A PREROUTING -i eth0 -p udp -m udp --dport 10000:10100 -j DNAT --to-destination 10.20.30.1

Sur le domU en question, ma configuration n’a guère changé, si ce n’est que j’ai réduit le pool de ports RTP dans le fichier rtp.conf :

; ces ports correspondent aux ports reroutés par iptables sur le dom0
rtpstart=10000
rtpend=10100

Le reste de la configuration est strictement identique à la documentation visible sur Freephonie.org.
Notez qu’afin de pouvoir débugger tranquillement avec votre utilisateur, grace à la commande asterisk -r, et pour pouvoir éditer les fichiers de configuration d’Asterisk sans peine, pensez à vous ajouter au groupe “asterisk”, autoriser l’ecriture pour le groupe dans /usr/pkg/etc/asterisk, et modifier les champs suivants dans le fichier asterisk.conf :

runuser = asterisk ; The user to run as
rungroup = asterisk ; The group to run as

[files]
astctlpermissions = 0660
astctlowner = asterisk
astctlgroup = asterisk
astctl = asterisk.ctl

Et enfin: “Allo Bob ? c’est Paul !”

Sur le “SuperPlan Mini” qui héberge désormais iMil.net, les services sont portés par des DomUs paravirtualisés Xen. Ces machines virtuelles fonctionnent avec les mêmes versions de noyau, d’espace utilisateur et surtout, de packages. Je ne partage pas via NFS l’espace utilisateur car je ne garantis pas la sécurité des applications hébergées sur l’une et l’autre des VMs (du php, beaucoup trop de php…).

Afin de simplifier la mise à jour des packages, j’utilise, devinez quoi: pkgin. Seulement voila, comme je l’expliquais quelques posts plus bas, j’ai besoin de spécifier certaines options à quelques packages, et de fait, je ne peux pas uniquement fonder mes mises à jour sur les paquets binaires fournis par le Projet NetBSD.
Dans l’exemple qui suit, on considèrera une machine “maître”, à qui revient la bonne gestion des packages et qui exporte son repertoire /usr/pkgsrc en NFS :

$ cat /etc/exports
/usr/pkgsrc  -alldirs -maproot=root -network 10.20.30.0 -mask 255.255.255.0
$ tail -3 /etc/rc.conf
rpcbind=yes
mountd=yes
nfs_server=yes

Voici la méthodologie que j’utilise pour le moment, pas trop fastidieuse mais tout de même pas d’une convivialité extrème :

• Sur la machine maitre
• Mise à jour des binaires sur la machine “maître” :

  # pkgin up && pkgin fug
  

• Remplacement des packages “custom” (je pourrais le faire avec pkg_chk, ce serait probablement plus propre)

  # cd /usr/pkgsrc/chat/irssi && make replace clean
  

• Regénération de tous les packages :

  # pkg_tarup -a -d /usr/pkgsrc/packages/All/ '*'
  

• Préparation du pkg_summary :

  # cd /usr/pkgsrc/packages/All/
  # pkg_info -X * |bzip2 -c > pkg_summary.bz2
  

• Sur les machines “slave”
• Renseignement du repository local :

  $ cat /usr/pkg/etc/pkgin/repositories.conf
  file:///usr/pkgsrc/packages/All
  

• Mise à jour de la base et des packages

  # pkgin up && pkgin fug
  

Et le tour est joué.