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.
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.
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
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é.
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.
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
|