sorrodje.alter-it.org

Ca faisait un moment que je m'intéressais au moyen de mettre en ligne ma musique afin de l'écouter depuis un peu partout sans avoir à trimbaler la totalité de ma bibliothèque, puis il m'a paru sympathique de permettre cet échange au sein de mon petit cercle amical ou familial. C'est toujours sympa d'échanger ses curiosités musicales.

Du coup, au vu de la bande passante potentiellement mobilisable, il a semblé pertinent de me monter un serveur de streaming personnel sur un serveur dédié. Un des outils les plus adapté pour cet usage est subsonic  qui permet d'uploader de la musique , de l'écouter en ligne , de gérer les playlists et autres joyeusetés... Le tout pour plusieurs utilisateurs. L'interface présente bien et dispose de plusieurs solutions de personnalisation, la navigation y est claire. Enfin, des clients Subsonic sont disponibles pour les smartphones ou autres terminaux sous iOS ou Android.  Bref, on a là l'outil idéal.



Il ne reste plus qu'à le déployer sur un serveur Dédié. Dans la phase de test , j'ai choisi un VPS GANDI et une Ubuntu 12.04 flambant neuve. Voici un mémo d'installation du tout "from scratch" .

   

Achat et mise en place du VPS Chez Gandi

Cela se fait via l'interface d'administration par laquelle on achète d'abord des ressources ( CPU , RAM , disque , interface ) soit "à la carte" soit en achetant une "part" de serveur correspondant à 1 coeur , 256 Mo de RAM et 8 Go d'espace disque. Ca parait peu mais ça suffit largement ( pour Subsonic , ça fait juste en RAM à l'utilisation quand même ;) ) pour tester et mettre en place tout un tas d'expérimentations dont celle qu'on suit ici.  Une ou deux captures d'écran de l'interface Gandi :

Achat , gestion des ressources et création de serveur:

    


L'interface de gestion des serveurs:





A la création du serveur, choisir la connexion par mot de passe , la connexion par clé se mettra en place plus tard.

Mise en place de base du serveur:

On se connecte à la machine fraîchement créée en ssh (via le terminal quand on est comme moi sur une machine linux ou via putty sur une machine windows )

$ssh 

et donner le mot de passe choisi à la création du serveur.

On est alors connecté et on peut travailler. L'utilisateur de base n'est pas sudoer et le compte root est actif: on passe donc par un "su root" classique. Le mot de passe par défaut est celui qu'on a choisi à la création du serveur. On le modifie donc immédiatement.

Premières configurations

$su root

puis

#passwd root

et on modifie le mot de passe root. On entame ensuite les quelques tâches de préparation du serveur:

#apt-get update && apt-get upgrade

Un éventuel problème de locales peut se poser avec ça qui apparaît:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
    LANGUAGE = (unset),
    LC_ALL = (unset),
    LANG = "fr_FR.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

La solution :

# locale-gen fr_FR.UTF-8
Generating locales...
  fr_FR.UTF-8... done
Generation complete.

Et c'est parti pour la suite: D'abord l'installation d'outils de base non livrés d'origine dans l'image GANDI:

#apt-get install nano htop

A savoir mon éditeur de texte et mon moniteur système préférés! Et on est dès lors outillé pour la préparation de notre serveur de son!

Installation et paramétrage du pare-feu UFW.

Précaution indispensable pour une machine connectée en direct à Internet , l'installation d'un pare-feu me parait être du domaine du réflexe de l'admin' ;-)

On peut passer par un script et des règles iptables. On peut aussi passer par des outils puissants genre Shorewall. Ici, je choisis d'utiliser l'outil "naturel" sur une Ubuntu : ufw. C'est à mes yeux un outil typique de ce qu'apporte Ubuntu: convivial et très simple à manipuler pour les usages standards. Pour la maîtrise fine , des besoins complexes et pour la connaissance approfondie du filtrage noyau, mieux vaut travailler avec iptables. Ici, on veut juste que ça marche sans se prendre le citron ;)

#apt-get install ufw

puis

#ufw default deny incoming
#ufw default deny outgoing

pour fermer complètement le pare-feu au trafic entrant et sortant.

# ufw allow in 22  ou ufw allow in ssh

Pour permettre l'autorisation des requêtes depuis l'extérieur pour le ssh.

# ufw allow out 53
# ufw allow out 21
# ufw allow out 80

Pour permettre au serveur d'accéder ( dans l'ordre ) aux serveurs DNS, FTP ou http. Dans la mesure où on laisse le trafic entrant fermé (pas de directive allow in)  un éventuel serveur web ou ftp sur le serveur ne serait pas accessible depuis l'extérieur. Il faudrait ouvrir le trafic entrant sur ces ports pour cela. On va le voir en exemple pour Subsonic ci-dessous

On active ensuite le pare-feu.

# ufw enable 

Evidemment on se déconnecte et on vérifie bien qu'on peut se reconnecter en ssh sinon... On réinstalle la snapshot du disque qu'on a soigneusement fait au préalable ( un des grands avantages de ces Serveurs dédiés virtuels !) sinon on demande la suppression du serveur via l'interface gandi et on en recrée un neuf ;-))) .

Voilà , c'est tout pour le moment. Rien de compliqué non ? On peut aussi passer par un script iptables hein ;)

Configuration accès SSH serveur:

Assez classiquement on monte une authentification ssh par clé pour remplacer l'authentification par défaut par mot de passe. Si on a pas déjà une clé valide, il faut la générer sur notre poste de travail (ubuntu 12.04 ici) via la commande

:~$ssh-keygen -t dsa

dans un terminal en tant qu'utilisateur du poste de travail pour lequel on souhaite créer la clé. On exporte ensuite la clé nouvellement créée ou préexistante sur le serveur qu'on est en train d'installer :

$ssh-copy-id -i ~/.ssh/id_dsa.pub  ssh 

On teste cette connexion par clé en vérifiant que la connexion n'exige plus de mot de passe. On repasse alors en root sur le serveur ( "su root" toujours ) puis on modifie la config de ssh pour ne permettre que les authentifications par clés afin d'en sécuriser l'accès. :

#nano /etc/ssh/sshd_config

et on modifie la ligne correspondante de ce fichier comme suit:

...

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
...

Dans ce cas et contrairement au choix fait ici , je laisse ssh écouter sur le port 22 et je laisse l'accès root ouvert. Ainsi les accès du support gandi restent possibles ainsi que la console de secours disponible dans l'interface de gestion. A chacun de choisir ce qu'il veut laisser comme accès selon l'usage de la machine.

Compléments de sécurisation de notre serveur.

Un dédié, virtuel ou pas, n'a pas de protection. Il est connecté directement sur le net et on sait que le net est peuplé de grands méchants qui veulent du mal à nos machines et en particulier prendre le contrôle via ssh. C'est d'ailleurs le seul port qu'on a laissé ouvert dans notre configuration de pare-feu. Une installation de fail2ban permet de se parer contre ce type d'attaque:

#apt-get install fail2ban

Dès l'installation fail2ban est paramétré pour bannir 10 mn les IPs de machines faisant 6 tests erronés de connexion ssh. On peut laisser comme ça ou aller modifier ces paramètres dans le fichiers /etc/fail2ban/jail.conf au paragraphe "default" et dans celui dédié à ssh ;)

On peut aussi ajouter portsentry pour bannir à jamais les scanneurs de port. C'est ce que j'ai pris l'habitude de faire en tous cas.

Un chouïa de monitoring et de suivi des logs: Munin et logwatch.

Ma problématique sur un serveur Dédié pour Subsonic c'est tout de même de suivre la conso des ressources de base ( bande passante , RAM , Disque en particulier et de surveiller que la machine fonctionne toujours correctement.  Un outil de monitoring comme Munin et un suivi de log comme logwatch contribuent à avoir un oeil attentif sur notre bébé.

#apt-get install logwatch. 

Si aucun dispositif d'envoi de mail n'est installé, logwatch installe postfix en tant que dépendance. Il faut donc répondre aux questions d'installation de ce dernier. Il faut choisir la configuration "site internet" . Ensuite il demande de choisir un nom de domaine valable à utiliser. Ces éléments peuvent être modifiés par la suite dans la configuration de postfix ( /etc/postfix/main.cf ) en cas de besoin.

Une fois l'installation terminée, tester le fonctionnement de logwatch via la commande :

#logwatch

Là, sans aucune configuration après installation, il donne le résultat directement dans le terminal. Allons jeter un oeil à la conf de logwatch en lui-même afin de paramétrer un envoi de mail à une adresse qui nous convient.

#nano /usr/share/logwatch/default.conf/logwatch.conf

Pour modifier les données suivantes comme ceci:

...
Output = mail 
...
Format = html
...
MailTo = 
...
MailFrom = Logwatch
...

et on refait le test...En scrutant son mail, on s'aperçoit que de mail on ne reçoit point! Encore eut-il fallu ouvrir le port 25 sur notre firewall précédemment mis en place! ;)

# ufw allow out 25 
# ufw reload 

et un dernier test permet de recevoir son beau mail avec les infos de suivi de nos logs.

Pour Munin voir ici: Installation Munin. Si on installe uniquement munin-node en vue de le faire communiquer avec un grapheur ailleurs , il faut bien à nouveau penser à adapter le firewall en conséquence et ouvrir ainsi le port 4949 qu'utilise munin par une instruction "ufw allow in 4949" et "ufw reload"

Installation Subsonic4.6 en mode "Standalone"

On prend ici le parti de choisir les solutions les plus simples donc on va utiliser le .deb fourni par subsonic . Ce paquet installe tout le nécessaire ( et en particulier le serveur d'applications jetty ) pour avoir un subsonic fonctionnel en deux coups de cuillère à pot ;). Donc en mode root sur le serveur, ça donne  ceci:

Il faut installer au préalable quelques outils : java et des outils de décodage audio/vidéo :

# apt-get install openjdk-6-jre lame ffmpeg flac faad vorbis-tools

Puis télécharger le .deb avec l'adresse qui va bien (à actualiser selon les versions de subsonic bien sur)

# wget http://downloads.sourceforge.net/project/subsonic/subsonic/4.6/subsonic-4.6.deb 

Puis après un petit "ls" pour vérifier le nom du deb est bien subsonic-4.6.deb , on lance l'installation avec l'outil Debian qui va bien:

# dpkg -i subsonic-4.6.deb

et voilà !

Subsonic est alors installé avec un serveur d'application permettant de faire fonctionner l'application proprement dite qui est en java. Par défaut , subsonic écoute sur le port 4040. Il faut donc modifier notre parefeu pour autoriser le serveur à répondre sur ce port:

#ufw allow in 4040
#ufw reload

et ainsi notre serveur subsonic est disponible en appelant depuis un navigateur l'adresse : http://IP_DU_SERVEUR:4040 :




Il faut alors se connecter et découvrir les fonctionnalité sympathique de ce Serveur de streaming Musical . A la première connexion , Subsonic porte notre attention sur 3 configurations :

- La modifications du mot de passe admin . On met donc à jour ce mot de passe tout de suite.
- L'absence de dossier de musique.

Par défaut Subsonic va chercher un /var/music. Dans la mesure où on est sur un serveur /var semble une bonne destination générale pour des données. Autant conserver donc /var/music comme dossier où pourra mettre notre musique.

en root :

# mkdir /var/music

Et Subsonic va retrouver ses petits ;) . Par défaut , subsonic agit en tant qu'utilisateur root sur le serveur donc pas de problème ici à créer le répertoire en tant que root et laisser les droits tels quels.

- Dernier paramétrage qui concerne le réseau : Subsonic étant à la base destiné à une installation sur un PC de bureau chez soi , c'est une configuration présentée pour ce type d'utilisation et aiguiller vers l'ouverture du bon port ( 4040 ) sur le routeur ou la box de la maison et adopter une adresse qui sait "suivre" une IP dynamique. 

Dans notre cas , on peut à priori utiliser une adresse subsonic et donc bénéficier des modalités de partage de liens d'écoute (et de téléchargement éventuel) . Dans la mesure ou un dédié comme un VPS Gandi a une IP fixe , j'ai plutot opté pour un nom de domaine qui m'appartient et je me passe pour le moment du partage dont la gestion sur nom de domaine personnel arrive à priori dans la prochaine version de subsonic ;)

Attention tout de même ici , on monte ce serveur avec 256 Mo mais ça fait trop juste , l'utilisation de la mémoire est vite à 100% ;) . 512 Mo semble une meilleure base . L'allocation de ressources est à adapter ensuite selon le nombre de personnes susceptibles d'utiliser Subsonic ;)

Voilà , il ne reste plus qu'à découvir ce très joli outil de streaming musical !

Changer de port d'écoute...

Il se peut que vous souhaitiez écouter la musique de votre serveur depuis un endroit où un proxy bloque le port 4040. Par exemple depuis votre travail.

Le plus simple pour parer à un éventuel bloquage de ce point de vue est de changer le port d'écoute de Subsonic pour choisir un port que les proxy ne bloquent pas en général : le port 80.

Pour cela, il faut simplement modifier un fichier de conf de Subsonic :

# nano /etc/default/subsonic 

#
# This is the configuration file for the Subsonic service
# (/etc/init.d/subsonic)
#
# To change the startup parameters of Subsonic, modify
# the SUBSONIC_ARGS variable below.
#
# Type "subsonic --help" on the command line to read an
# explanation of the different options.
#
# For example, to specify that Subsonic should use port 80 (for http)
# and 443 (for https), and use a Java memory heap size of 120 MB, use
# the following:
#
# SUBSONIC_ARGS="--port=80 --https-port=443 --max-memory=120"

SUBSONIC_ARGS="--max-memory=100"


# The user which should run the Subsonic process. Default "root".
# Note that non-root users are by default not allowed to use ports
# below 1024. Also make sure to grant the user write permissions in
# the music directories, otherwise changing album art and tags will fail.

SUBSONIC_USER=root

Et modifier la ligne

SUBSONIC_ARGS="--max-memory=100"

à

SUBSONIC_ARGS="--port=80 --max-memory=100"

Et le tour est joué.

Changer le port d'écoute ET l'utilisateur par défaut.

Ici c'est plus compliqué. On souhaite avoir accès à Subsonic via le port 80 mais aussi que Subsonic n'utilise plus l'utilisateur root mais un utilisateur spécifique dédié pour des raisons de sécurité.

Si on modifie le ficher /etc/default/subsonic pour changer l'utilisateur par défaut , ce dernier ne peut plus utiliser le port 80. On est donc à priori  coincés! . J'ai donc adopté la solution de passer par la mise en place d'un reverse proxy via apache2 . Si on considère qu'on part de la situation par défaut où subsonic écoute sur le port 4040 et que l'utilisateur par défaut est "root", les manips à mettre en place sont les suivantes:


Mise en place d'apache2 et du Reverse proxy.

Installation d'apache2  (en mode admin donc via su root ou sudo -i selon la configuration choisie):

 #apt-get install apache2

Et on enchaîne directement sur l'activation du module proxy_http

#a2enmod proxy_http

On crée ensuite un Virtualhost dédié à subsonic pour le nom de domaine dédié ( par exemple subsonic.mondomaine.org )

#nano /etc/apache2/sites-available/subsonic 

Avec le contenu suivant:

<VirtualHost *:80>

        ServerName subsonic.mondomaine.org
        ServerAdmin 
        ErrorLog /var/log/apache2/test.alter-it.org.log
        CustomLog /var/log/apache2/test.alter-it.org.log combined

        <Proxy *:80>
                Order allow,deny
                allow from all
        </Proxy>

ProxyPass / http://127.0.0.1:4040/
ProxyPassReverse / http://127.0.0.1:4040/

</VirtualHost>

Le contenu permet ainsi de "transférer" les requêtes arrivant via http://subsonic.mondomaine.org vers http://127.0.0.1:4040 c'est à dire la même machine ( notre serveur ) mais sur le port 4040 où écoutent Jetty et donc Subsonic! Ca permet aussi accessoirement de générer des logs spécifique dédié à Subsonic et susceptible d'être analysés par un analyseur de logs comme awstats .

On active le Vhost:

#a2ensite subsonic

Puis on recharge la configuration apache2 pour faire prendre en compte notre Vhost tout neuf;)

#service apache2 reload

A partir de là , on a un subsonic derrière un apache2 et Subsonic répond donc à http://subsonic.mondomaine.org via le classique port 80 .  Rien n'empêche donc de mettre en place un utilisateur dédié à subsonic en lieu et place de root.


Changer l'utilisateur par défaut de Subsonic

Il faut d'abord créer notre utilisateur ( ici je choisis subsonic )

# adduser --system --group subsonic

Pour créer un utilisateur systeme sans home et sans mot de passe ainsi que son groupe associé ( subsonic aussi) puis on modifie  les droits des répertoires de données de l'application Subsonic:

# chown -R subsonic:subsonic /tmp/subsonic
# chown -R subsonic:subsonic /var/subsonic
# chown -R root:root /var/subsonic/transcode
# chown -R root:root /var/subsonic/jetty/*/webapp

Cela donne les droits d'accès à l'utilisateur subsonic mais ça laisse les répertoires "sensibles" inaccessibles. 

On modifie alors notre fichier /etc/default/subsonic

#
# This is the configuration file for the Subsonic service
# (/etc/init.d/subsonic)
#
# To change the startup parameters of Subsonic, modify
# the SUBSONIC_ARGS variable below.
#
# Type "subsonic --help" on the command line to read an
# explanation of the different options.
#
# For example, to specify that Subsonic should use port 80 (for http)
# and 443 (for https), and use a Java memory heap size of 120 MB, use
# the following:
#
# SUBSONIC_ARGS="--port=80 --https-port=443 --max-memory=120"

SUBSONIC_ARGS="--max-memory=100"


# The user which should run the Subsonic process. Default "root".
# Note that non-root users are by default not allowed to use ports
# below 1024. Also make sure to grant the user write permissions in
# the music directories, otherwise changing album art and tags will fail.

SUBSONIC_USER=subsonic

On enregistre puis on redémarre subsonic:

# /etc/init.d/subsonic restart

Et on a fini  :)



Enfin, Outre les différentes attaques qu'on a essayé de parer via un pare-feu et des outils dédiés comme fail2ban et logwatch, on aurait pu se poser la question de la fragilité de subsonic vis à vis d'éventuelles attaques DDOS. Or il semblerait que le fonctionnement même du serveur d'application utilisé par subsonic (Jetty ) soit intrinsèquement résistant à ce type d'attaque. Voir ici : QoSfilter .  Si j'ai à vérifier ça par moi même, je vous en donnerai des nouvelles! 

Bien sur , on est ici sur une configuration de subsonic "au plus simple" en considérant que c'est la seule application disponible sur le serveur en question . Si tel n'était pas le cas , on peut envisager des montages un peu plus complexes comme par exemple dans cet intéressant tuto sur le même sujet !


Bonne musique !!


Le site officiel et le forum Subsonic : subsonic.org
Une source claire et sympa pour ufw : Tuto UFW