Note : N.D.T. : nous garderons les commentaires en anglais pour coller le plus possible au fichier de configuration. Des explications en français suivent chaque paramètre. |
Exemple de code 1.3 : Choisir la limite d'utilisateurs |
MaxUser=10
|
C'est ici que nous indiquons le nombre maximum d'utilisateurs. Comme l'indique le commentaire, il est stupide de mettre 100 utilisateurs lorsqu'on ne dispose que de 256 Kb/s d'upload (c'est pourquoi nous avons choisi de mettre 10, dans la mesure où la connexion utilisée pour l'exemple est effectivement de 256 Kb/s en upload). Si vous utilisez le serveur SHOUTcast pour une radio sur un réseau local, vous pouvez mettre un nombre bien plus important (facilement 100). Souvenez-vous qu'il ne faut pas abuser non plus de la bande passante dont vous disposez. La bande passante coûte cher aux fournisseurs d'accès Internet et certains d'entre eux pourraient couper votre compte par exemple, car vous abuseriez d'eux, dans un sens.
Exemple de code 1.4 : Configurer le mot de passe |
Password=un_mot_de_passe_solide
|
C'est ici que vous indiquerez votre mot de passe pour le serveur. Le mot de passe apparaît en clair dans le texte. Pour des raisons de sécurité, nous vous recommandons FORTEMENT de ne pas utiliser des mots de passe que vous utilisez pour d'autres composants importants de votre système ou qui puisse protéger l'accès à des données sensibles. Choisissez-en un le plus aléatoire possible, avec une combinaison de lettres, chiffres et caractères spéciaux. Ce mot de passe sera utilisé par SHOUTcast Trans (ou tout autre fournisseur de contenu) pour se connecter et diffuser du contenu.
Exemple de code 1.5 : Choisir le port d'écoute |
PortBase=8000
|
Nous configurons ici le port sur lequel les utilisateurs se connecteront au serveur SHOUTcast. La valeur par défaut, 8000, est celle utilisée par défaut par la plupart des programmes permettant de se connecter à des serveurs de ce type (xmms, winamp, etc.). Comme indiqué en commentaire, si vous voulez utiliser un port inférieur à 1024, vous devrez être root. Cependant, nous vous recommandons très fortement de ne pas utiliser de port inférieur à 1024 pour votre serveur SHOUTcast.
Exemple de code 1.6 : Mettre en place le système de journalisation |
LogFile=/var/log/SHOUTcast.log
|
Nous indiquons ici la destination du fichier de journalisation du serveur SHOUTcast. Par défaut, l'ebuild l'initialise à /dev/null. Vous devrez donc probablement le changer pour avoir une journalisation correcte. Ici, nous avons choisi comme répertoire de destination l'habituel /var/log. Cela dit, vous pouvez mettre votre fichier de journalisation où bon vous semble.
Exemple de code 1.7 : Activer les informations en temps réel |
RealTime=0
|
Cela affiche des informations sur le fichier diffusé en cours dans la sortie standard toutes les secondes. L'ebuild désactive cela pour que le démon SHOUTcast puisse fonctionner le plus silencieusement possible. Mettez la valeur de la variable à 1 si vous souhaitez obtenir ces informations toutes les secondes. Cependant, nous vous recommandons d'utiliser la page de statut à la place.
Exemple de code 1.8 : Activer la journalisation en temps réel |
ScreenLog=0
|
Par défaut, l'ebuild désactive encore cette variable pour avoir un démon qui s'exécute le plus silencieusement possible. L'activer aurait pour effet de journaliser tous les événements (connexions, déconnexions, etc.) sur la sortie standard, en temps réel. Cependant, comme le fichier de journalisation fait la même chose, nous vous recommandons d'utiliser ce fichier à la place de l'affichage sur la sortie standard.
Exemple de code 1.9 : Choisir le nombre de dernières chansons affichées |
ShowLastSongs=10
|
Comme son nom l'indique, cette valeur correspond au nombre de chansons qui ont été récemment jouées et ces chansons seront indiquées dans /played.html. Si vous mettez une valeur de plus de 20, vous rencontrerez probablement des problèmes.
Exemple de code 1.10 : Activation de la journalisation des modifications dans le système de fichiers |
|
Cet élément permet d'activer ou non la journalisation pour les événements concernant les modifications de répertoire par le DNAS (le serveur audio distribué). Il est recommandé pour ceux qui souhaitent avoir une journalisation la plus sûre possible. Ceux qui font usage de ce serveur pour une utilisation en Intranet ou occasionnelle n'auront probablement pas besoin de cet élément.
Exemple de code 1.11 : Activation de la journalisation des requêtes HTTP |
|
Cette option permet d'indiquer si vous voulez ou non journaliser les requêtes faites sur le serveur HTTP fourni par SHOUTcast. Encore une fois, elle est recommandée pour ceux qui souhaitent une journalisation complète, mais pas pour la plupart des utilisateurs.
Exemple de code 1.12 : Activer la journalisation W3C |
W3CEnable=Yes
W3CLog=/dev/null
|
La première option active la journalisation W3C. Il est plus simple d'extraire des informations de la journalisation si on l'active, notamment si on utilise l'un des programmes cités dans les commentaires (Analog, WebTrends...). Nous le recommandons grandement pour ceux qui souhaitent avoir des statistiques les plus complètes possible.
La seconde option indique l'endroit où doit être gardé le fichier de journalisation W3C. Par défaut, l'ebuild met cette option à /dev/null.
Configuration réseau
Exemple de code 1.13 : Configurer l'adresse IP source |
SrcIP=ANY
|
La variable SrcIP indique de quelle adresse IP le contenu de diffusion provient. Cela peut venir d'autres serveurs (relais), de localhost (cas général) ou de toute autre adresse IP que votre interface peut supporter. L'initialiser à localhost empêche les autres serveurs d'utiliser votre serveur SHOUTcast comme une source de diffusion. Par défaut, la variable est mise à ANY, ce qui fait que votre serveur SHOUTcast pourra diffuser le contenu depuis d'autres serveurs. Pour des raisons de sécurité, il est préférable de choisir une valeur plus précise.
Exemple de code 1.14 : Configurer l'adresse IP de destination |
DestIP=ANY
|
Cette variable détermine sur quelle adresse IP de votre interface réseau vous autoriserez les utilisateurs à se connecter. Cela peut être localhost (si vous êtes antisocial et ne voulez diffuser du contenu que pour vous-même), une adresse IP privée (de type 192.168.0.101, si vous hébergez un serveur SHOUTcast pour un réseau local) ou une adresse IP publique (de type 209.204.249.201, pour faire de la diffusion sur WAN et non sur LAN). Dans la plupart des cas, vous pourrez accéder au contenu diffusé en utilisant 127.0.0.1. ANY permet à votre serveur SHOUTcast de recevoir les requêtes clientes sur toutes les adresses IP venant de toutes les interfaces disponibles.
Exemple de code 1.15 : Configurer le port proxy/yp.SHOUTcast.com |
Yport=80
|
Cette variable permet deux choses. Tout d'abord, elle spécifie le port avec lequel le serveur peut se connecter à yp.SHOUTcast.com. yp.SHOUTcast.com est une page de Nullsoft pour les serveurs publics qui permet aux utilisateurs d'avoir accès à une liste de serveurs sur lesquels ils peuvent écouter du contenu. Les utilisateurs peuvent accéder à votre serveur depuis cette page. L'autre utilisation est pour les proxy Web. Il faut alors mettre cette valeur au numéro du port utilisé pour les connexions proxy et mettre à DestIP le nom du proxy pour la diffusion.
Exemple de code 1.16 : Configurer le DNS inversé |
NameLookups=0
|
Cette option permet d'indiquer si oui ou non vous voulez activer l'utilisation du DNS inversé pour les clients. Cela permet de récupérer leur nom à partir de leur IP. À utiliser essentiellement pour créer des rapports de journalisation plus détaillés.
Exemple de code 1.17 : Activer le relais |
|
Permet d'indiquer que vous agissez comme serveur relais. Les serveurs relais sont souvent utilisés pour récupérer le contenu d'une connexion à faible débit et le diffuser à un plus grand nombre d'utilisateurs, avec une connexion supérieure. RelayPort et RelayServer indiquent le port et l'adresse IP du serveur SHOUTcast pour lequel vous voulez agir comme relais. Laissez ces lignes commentées si vous ne souhaitez pas servir de relais.
Configuration du serveur
Exemple de code 1.18 : Indiquer le mot de passe administrateur |
|
L'initialisation de cette variable va créer un administrateur et un diffuseur (broadcaster et administrator). Le diffuseur peut se connecter avec un mot de passe et voir les connexions actuelles. Cependant, pour pouvoir déconnecter, bannir des clients ou administrer le serveur, vous devez avoir le mot de passe administrateur. Cette option crée des rôles précis pour votre serveur. Son usage est recommandé quand l'administrateur système n'est pas la même personne que le diffuseur.
Exemple de code 1.19 : Configurer la déconnexion automatique des clients |
AutoDumpUsers=0
|
Cette variable permet de décider si oui ou non les utilisateurs seront déconnectés si la diffusion se déconnecte pour une raison quelconque. On la met à 0 pour que les clients se mettent eux-même en dépassement de temps de connexion ou pour qu'ils puissent continuer d'essayer de mettre en tampon un contenu diffusé. À utiliser si vous pensez avoir de courtes interruptions de temps à autre.
Exemple de code 1.20 : Configurer le temps de connexion limite pour la source |
AutoDumpSourceTime=30
|
Cette variable indique quand le serveur SHOUTcast abandonnera la tentative de connexion à une source (en général un serveur relais) pour diffuser son contenu. Une valeur entre 30 et 60 secondes devrait être raisonnable ici.
Exemple de code 1.21 : Configurer le répertoire de contenu |
ContentDir=/opt/SHOUTcast/content/
|
La variable ContentDir indique où doit être mis le contenu à la demande. Par exemple, si vous souhaitez diffuser une annonce à vos employés, vous pouvez utiliser cette fonctionnalité. L'ebuild du serveur SHOUTcast l'initialise à /opt/SHOUTcast/content pour vous. Pour l'utiliser, mettez un MP3 dans le répertoire de contenu, puis mettez un lien vers http://exemple.com:[port]/content/nomDump3.pls. Le serveur SHOUTcast créera automatiquement une liste de diffusion pour le MP3 et le diffusera à la demande. À utiliser comme alternative à SHOUTcast Trans pour diffuser une source audio.
Exemple de code 1.22 : Configurer un fichier d'introduction |
|
Cela permet d'ajouter un fichier d'introduction. À chaque fois qu'un utilisateur se connecte, il entendra ce fichier. Comme indiqué, le débit de diffusion et celui du morceau d'introduction doivent coïncider, sinon cela peut créer des problèmes. Vous pouvez cependant mettre des fichiers comme intro128.mp3 et intro64.mp3 et il jouera alors intro128.mp3 pour les utilisateurs qui utilisent une diffusion 128 Kb/s et intro64.mp3 pour ceux qui utilisent une connexion 64 Kb/s.
Top
Exemple de code 1.23 : Configurer un fichier son d'attente |
|
Cette variable a le même effet que la précédente, mais le fichier sera joué quand la source de diffusion est finie, au lieu de déconnecter les utilisateurs. Ne fonctionne que si AutoDumpUsers est mis à 0.
Exemple de code 1.24 : Configurer le format de titre |
TitleFormat=Chris Gentoo Beats: %s
|
Cette variable permet de spécifier un titre fixe pour votre serveur SHOUTcast. Utilisez-la si votre source de diffusion diffère du nom de votre serveur. Cela ne fonctionnera pas pour les serveurs relais.
Exemple de code 1.25 : Configurer le format d'URL |
|
Cette variable permet de faire la même chose que TitleFormat, mais pour les URL : l'URL précisée ici est utilisée à la place de l'URL de la source de diffusion.
Top
Exemple de code 1.26 : Configurer le statut public d'une source de diffusion |
PublicServer=default
|
On peut préciser si oui ou non on veut être listé comme un serveur public, même si votre source/serveur relais est listé comme tel ou non.
Exemple de code 1.27 : Permettre les relais |
AllowRelay=Yes
|
AllowRelay permet de choisir si d'autres serveurs peuvent relayer votre contenu. Si vous ne pensez pas que vous serez relayé, mettez « No ».
Exemple de code 1.28 : Permettre aux relais d'afficher publiquement la source |
AllowPublicRelay=Yes
|
On peut préciser grâce à AllowPublicRelay si l'on veut permettre aux serveurs qui vous relaient de vous lister dans le répertoire SHOUTcastpublic. Remarquez que PublicServer a priorité sur cette fonctionnalité.
Exemple de code 1.29 : Configurer la variable MetaInterval |
MetaInterval=32768
|
Laissez-le tel quel, tout simplement.
Configuration des accès
Top
Exemple de code 1.30 : Configurer le temps maximum d'écoute |
|
Je ne suis pas sûr de voir l'utilité que cette fonctionnalité pourrait avoir pour vous. Tout ce qu'elle fait, c'est de déconnecter les utilisateurs qui sont sur le serveur depuis trop longtemps. La seule utilité que je lui vois est de permettre de déconnecter les personnes qui se connectent pour rien ou si vous estimez que les utilisateurs devraient avoir autre chose à faire qu'écouter votre diffusion. La valeur est à mettre en minutes.
Exemple de code 1.31 : Indiquer le fichier de bannissement |
|
C'est le fichier contenant la liste des clients qui sont bannis de votre serveur. Par défaut, c'est le fichier sc_serv.ban, mais vous pouvez utiliser le fichier que vous voulez.
Exemple de code 1.32 : Indiquer le fichier de liste blanche |
|
Autrement nommé RipFile, pour « Reserved IP », ce fichier est utilisé pour préciser la liste des utilisateurs amis ou des personnes que vous considérez comme plus importantes que les utilisateurs lambda. Si vous êtes actuellement en train de diffuser du contenu à un nombre d'utilisateurs égal à votre maximum et qu'un membre de la liste blanche essaye de se connecter, le serveur déconnectera la personne qui aura le temps d'écoute maximum pour laisser place à l'utilisateur privilégié.
Top
Exemple de code 1.33 : Configurer si seuls les utilisateurs Rip peuvent accéder au serveur |
|
Avec cette option, vous ne pouvez permettre l'accès à votre serveur SHOUTcast qu'aux membres Rip (de la liste blanche). Vous pouvez au choix l'utiliser pour faire de la diffusion radio privée ou faire en sorte que seuls certains relais puissent accéder à votre contenu.
Configuration de masse
Exemple de code 1.34 : Configurer la variable Unique |
|
Pour faire simple, si vous disposez de nombreux serveurs SHOUTcast, cela serait une vraie plaie de devoir modifier tous les fichiers de journalisation, bannissement, etc. pour chaque serveur, alors que leur contenu est identique pour tous les serveurs. À la place, vous pouvez mettre une valeur pour Unique et $ sera remplacé par le contenu de Unique. Par exemple, si un fichier contient Unique=Jazz et qu'un autre contient Unique=Rock, alors Log=/var/log/$.log produira un fichier /var/log/Jazz.log pour l'un des fichiers de configuration et /var/log/Rock.log pour l'autre. Cela permet de simplifier le fonctionnement de plusieurs serveurs SHOUTcast disposant de configurations similaires.
Exemple de code 1.35 : Configurer des variables de configuration communes |
|
Si vous disposez de plusieurs serveurs SHOUTcast et si vous souhaitez utiliser des variables de configuration similaires, sans les configurer dans chaque fichier de configuration, vous pouvez utiliser cette variable pour pointer vers un fichier contenant des configurations qui seront communes pour vos différents serveurs.
Configuration d'optimisation
Exemple de code 1.36 : Configurer le nombre de processeurs utilisés |
|
Sur les systèmes qui disposent de plusieurs processeurs, vous pouvez utiliser cette variable pour forcer le serveur SHOUTcast à utiliser un certain nombre CpuCount de processeurs. Par défaut, il assignera un fil d'exécution pour chaque processeur et les clients seront distribués entre les fils d'exécution. Si vous utilisez une valeur inférieure au nombre de vos processeurs, cela vous laissera des processeurs libres pour d'autres tâches.
Exemple de code 1.37 : Configuration de l'intervalle de soumission de données |
|
Le serveur SHOUTcast utilisera la valeur de « Sleep » pour déterminer l'intervalle entre chaque envoi de données. Plus la valeur est grande, plus l'intervalle est grand. Plus la valeur est petite, plus l'intervalle sera petit et le serveur SHOUTcast utilisera plus de capacité de calcul du processeur pour arriver à ses fins. Sur des systèmes limités, vous devrez probablement diminuer la valeur pour que les serveurs SHOUTcast puissent envoyer des données de plus en plus fréquemment aux utilisateurs. Le mieux est de laisser la valeur par défaut.
Top
Exemple de code 1.38 : Configurer la sortie XML |
|
Nous n'avez probablement pas à vous préoccuper de cette variable, sauf si vous utilisez un parseur XML personnalisé pour créer des statistiques adaptées à vos besoins pour votre serveur. Si le parseur XML ne peut pas gérer les espaces et les sauts de lignes des flux XML, mettez cette valeur à « Yes » et tout devrait fonctionner correctement.
Conclusion à propos de la configuration
Votre serveur SHOUTcast devrait être maintenant bien configuré. Je recommande l'utilisation de la journalisation W3C, car on en extrait plus facilement les données et elle est recommandée pour créer des statistiques personnalisées. Vous pouvez également activer la variable AdministratorPassword. Vous aurez peut-être également besoin de quelques options de configuration de masse si vous configurez plusieurs serveurs SHOUTcast.
Maintenant que la configuration a été mise en place, nous allons mettre le serveur SHOUTcast en production. Nous le lancerons avec une diffusion simple à la demande, pour commencer, puis nous utiliserons SHOUTcast Trans (qui est plus complet et complexe à mettre en œuvre).
Source http://www.gentoo.org/doc/fr/shoutcast-config.xml
Top
|