Avertissement : Article encore en cours d'écriture

Intro

L'idée est soit de réutiliser un vieux PC qui ne fait plus grand chose, soit de délibérément constituer un second PC pour s'en servir dans son studio. Typiquement les synthés virtuels polyphoniques sont très demandeurs en CPU, et il est bon de les "externaliser". Le fait d'avoir une machine dédiée permettra d'avoir une latence très basse, et d'avoir le même comportement qu'un vrai synthé. Pour obtenir les mêmes conditions pratiques qu'un expandeur nous allons voir comment se passer de l'écran et du clavier supplémentaires en le pilotant en réseau.

Par convention dans l'article:PC1 sera l'hôte et PC2 le second PC dédié.

Matos

Je pense qu'il est préférable d'éviter les trop vieilles machines, car les soft-synthés sont gourmands, et compte tenu des efforts demandés il est bon que le retour soit à la hauteur.

• Un combo CM+CPU, Pour le CPU, 600 à 800 mhz est un minimum à moins d'avoir vraiment une idée d'application peu gourmande. On trouve sans problème en occasion des combos d'Athlon à 1.5 gigaHz avec carte mère pour pas cher du tout (il y a sinon des cartes meres neuves à 40 euros !!).
• Pas besoin de bcp de RAM 128 meg peuvent être suffisants.
• Il faudra également un HD minimum 4 giga (et peut-être moins).
• une carte réseau: On peut envisager différentes choses, une carte Ethernet 100mbit/s ou mieux 1gigabit/s. Il serait possible également d'utiliser une connection firewire ou USB2 pour le réseau (à confirmer). Pour le débit tout dépend si l'on compte faire véhiculer des données audio sur le réseau. Pour l'affichage qui sera exporté il vaut mieux à priori éviter l'USB1 et l'Ethernet 10 mbit/s. A l'usage 100mbit/s se révèle acceptable pour des petites applications ne nécessitant pas trop d'interactions (ex: PureData, ZynaddSubFX). Par contre l'usage de gros logiciels comme Ardour exportés sur un affichage distant impose une connexion gigabit.
• Une carte son, celle-ci peut-être très basique (SBLive)

Netbooting ?

Il y a certes des possibilités pour booter en réseau mais c'est assez complexe. On peut par exemple flasher la mémoire de certaines cartes réseau pour contenir le bootloader ou utiliser le protocole PXE. Pour notre part nous préférons ré-utiliser un petit disque dur qui ne sert plus et booter normalement.

Installer une distrib sur le PC2

Une distribution dédiée comme Musix, CCRMA (ou APODIO ?) fera parfaitement l'affaire. Il est pratique à ce titre d'utiliser la même que celle que l'on utilise sur le PC principal ce qui rend la gestion des 2 machines plus aisée. On peut même s'éviter l'installation depuis le CD en copiant directement son répertoire racine sur le HD de la future machine. Avant de réinstaller le HD dans le PC2, il faut penser à éditer /etc/fstab pour qu'il reflète sa configuration. Ensuite avec une disquette de boot, une fois le prompt atteint, il faut au besoin éditer le bootloader et réinscrire le MBR. A présent la machine devrait être bootable depuis le disque. (note: tout compte fait il y a sans doute d'autres choses à faire, l'installation depuis le CD est plus facile pour un newbie et à considérer en priorité).

Voici un (début de) tutoriel pour cloner une installation.

Installer le réseau

Configurer les interfaces

Les adresses IP pour un réseau privé sont de la forme 192.168.x.x Nous choisirons 192.168.1.1 pour le PC1 et 192.168.1.2 pour PC2. La configuration des interfaces Ethernet n'est pas tellement difficile, il faut déjà que le bon module soit chargé, ce qui est simplifié si vous avez un service d'autodétection des périphériques au boot. Sinon il faudra sans doute, trouver un moyen d'inscrire le module dans les fichiers de configuration des modules, généralement /etc/modules.conf. Il faut regarder avec dmesg si un module pout la carte réseau à bien détecté celle-ci, ensuite les distributions proposent des outils de configuration qui permettent d'aller vite. On peut utiliser ifconfig pour vérifier que l'interface eth0 est UP et route pour voir l'état du réseau.
Sous Debian: dpkg-reconfigure etherconf, sous d'autres OS on trouve parfois netconf ou netcfg.
Léa propose un article complet sur l'installation des cartes réseaux.

Autoriser les services, inetd, xinetd, portmap

Au niveau global, il peut exister ou non un mécanisme de défense.
Sur Debian il existe un fichier /etc/hosts.allow qui permet d'autoriser (le comportement par défaut étant restrictif) une IP:
ex pour une machine distante sans restriction :

ALL=192.168.1.3

Cependant je pense que cette ligne est facultative à moins que votre distribution Debian soit configurée dans un mode ultra-restrictif, il existe un fichier /etc/hosts.deny qui est le pendant négatif du premier. Vérifier que ALL: PARANOID est bien commenté.

# The PARANOID wildcard matches any host whose name does not match its
# address. You may wish to enable this to ensure any programs that don't
# validate looked up hostnames still leave understandable logs. In past
# versions of Debian this has been the default.
# ALL: PARANOID

Sous Gentoo, nous n'avons pas eu d'autorisation globale de ce type à effectuer.

Désactiver les services et le serveur X sur PC2

Dans notre utilisation le PC2 (une sorte de rack) n'a pas d'écran et transfert son affichage sur le serveur X du premier.

Un bon nombre de services sont complètement inutiles sur un PC dédié, c'est donc le cas du serveur X.

On ne peut pas le désinstaller car de nombreux programmes en dépendent, mais il ne sera pas lancé par défaut au boot. Il faut donc désactiver le display manager (gdm,kdm ou xdm) car c'est lui qui lance le serveur X au démarrage. De ce fait au boot le PC1 s'arrêtera au login en mode console. Cela permet d'économiser des cycles de CPU (environ 10% sur une machine type Athlon XP 2400).

Xserveur

Comme l'affichage est distant, il faut exporter la variable DISPLAY sur le PC2 pour que ses applications aillent s'ouvrir sur le PC principal.
Dans un des fichiers de configuration "bashrc" du système :

Cette déclaration peut se faire dans /etc/profile pour un effet global ou dans le fichier .bashrc de l'utilisateur.

Il faut aussi penser à ajouter l'IP du PC2 dans le fichier /etc/X0.hosts du serveurX:

local:
inet:192.168.1.2

NFS

Cette étape est facultative car on peut utiliser certaines commandes pour transférer des fichiers d'un PC à l'autre. Néanmoins il est intéressant de rendre accessible le disque contenant les travaux audio au deuxième PC afin de centraliser les presets par exemple.
Pour cela il faut d'abord installer et configurer un serveur NFS sur le PC principal.

Installer

Il existe probablement un paquet logiciel NFS sur votre distribution qui correspond au serveur, installez-le

Configurer le serveur

Il faut juste éditer /etc/export

/               192.168.1.2(rw,no_root_squash,nohide,sync)

rw:donne l'accès en lecture et en écrite
no_root_squash:
nohide:
sync: sync et préférable à async si on ne recherche pas les performances mais plutôt la fiabilité. 'sync' s'assure que les opérations sur le système de fichiers exporté sont toujours confirmées.

Lancer le service

Il y a plusieurs façons suivant les distributions

Sous Debian rcconf permet d'éditer le lancement des services au boot (ou utiliser update-rc.d en console).
Sous les autres systèmes, il existe surement une interface graphique.

Monter le système depuis le client.

Le PC2 doit pouvoir maintenant monter le système du serveur. On peut donc l'ajouter définitivement dans son fichier /etc/fstab

192.168.1.1:/Musique  /Musique    nfs          rw,soft            0    0

Le répertoire /Musique de l'hôte contenant par exemple les projets audio est monté sur le client.

rcp et scp

Ce sont des commandes permettant de copier directement un fichier d'un PC à l'autre. rcp est l'ancienne version, scp son remplacement sécurisé quand on utilise SSH (prenons de bonnes habitudes).

Ca marche dans l'autre sens aussi:

Vous noterez que l'on doit taper le mot de passe de la machine distante et que celle-ci doit avoir un serveur SSH actif (plus de détails plus bas sur SSH). On peut utiliser directement l'adresse IP et si on précise un nom de fichier différent à l'arrivée cela permet de renommer automatiquement la copie.

Telnet, rlogin, rsh ou ssh

Ce sont 2 méthodes parmi d'autres pour se connecter à distance sur un sytème UNIX. Telnet, rlogin et rsh sont passés en désuétude et sont considérés moins sûrs. Cela ne nous poserait pas de réel problème vu l'utilisation de la machine en réseau local. Mais ssh est préférable pour d'autres raisons, comme le fait de se passer de login grâce au système de clés d'authentification. Ainsi il sera facile de lancer une application à distance sur le PC2. La configuration de SSH est par contre un peu complexe et ennuyeuse au début. Une étape obligée

Pour la suite nous nous sommes aidé de l'article du site Léa http://lea-linux.org/cached/index/Reseau-secu-ssh.html# que nous avons un peu édulcoré.

Un client peut se connecter sur une machine distante avec ssh si cette dernière fait tourner un serveur sshd.

Installer

Il doit exister des paquets sshd (serveur) et ssh (client) à installer, ensuite il faut lancer le service sshd :

Pour que le service soit permanent utiliser rcconf (debian) ou un autre moyen suivant la distribution.

Côté serveur, il existe un fichier /etc/ssh/sshd_config qui permet d'ajouter des restrictions mais ce qui nous intéresse est de mettre un système de clés pour rendre le login automatique sans mots de passe et en toute sécurité.

Attention, il faut que PubkeyAuthentication soit positionné à yes dans ce fichier (serveur) pour la suite des évènements.

Par ailleurs il faut que l'utilisateur client ait un compte d'utilisateur sur la machine serveur (dans l'exemple : jop)

Génération des clés

La commande ssh-keygen permet la génération de clés dsa et rsa correspondant à deux versions de protocoles SSH. En pratique DSA correspond à la version la plus évoluée. On peut générer les 2 clés ou une seule si est sûr du protocole qui sera utilisé par les deux machines. Ces commandes sont à taper sur la machine client.

Pour SSH v2:


Facultatif, pour SSH v1:

Mettre en place les clés

A présent nous devons copier à l'aide de scp la clé (ou les clés) vers la machine serveur sur laquelle nous désirons nous loguer.

La commande copie le fichier id_dsa.pub (qui a été généré plus haut) vers le répertoire ~/.ssh de l'utilisateur job du serveur sshd. Cette clé est renommée en "dsa2connex" lors du transfert.

A présent il faut se connecter sur le serveur et aller dans le répertoire ~/.ssh de l'utilisateur où le fichier dsa2connex à été transféré et taper:


Ce qui a pour but d'ajouter la clé à la liste, attention à bien mettre les ">>".

Et voilou ! Vous pouvez à présent vous connecter en utilsant ssh sans avoir à taper un pass' !

Si vous avez généré une clé RSA, vous pouvez faire la même procédure de transfert et d'ajout, mais c'est dans le cas où la machine ne supporterait pas le protocle SSH v2.

Créer une passerelle avec Iptables

Encore une étape facultative mais qui est bien pratique pour mettre à jour le 2ème PC ou le faire bénéficier d'un accès au net pour certains usages.

Installer

A priori les noyaux sont généralement déjà compilés avec les bons modules, mais si vous compilez vous même le votre n'oubliez pas d'ajouter le support pour iptables. Sur le PC1 il faut en plus installer un paquet logiciel "Iptables" qui contient la commande du même nom.

configurer iptables sur l'hôte

Il suffit de placer ceci dans un script au démarrage:

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -F FORWARD
iptables -A FORWARD -j ACCEPT 
iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE^

ajouter la gateway sur le 2èmePC

Plusieurs façons:
-manuellement : route add default gw 192.168.1.1
-en éditant le fichier /etc/network/interfaces

auto lo eth0

iface lo inet loopback

iface eth0 inet static
        address 192.168.1.2
        netmask 255.255.255.0
        broadcast 192.168.1.255
        gateway 192.168.1.1

DNS et /etc/resolv.conf

Ce fichier sur le PC2 doit contenir les adresses DNS de votre prestataire internet.
Note: il y a un problème lorsque le PC1 n'est pas sur le net, il devient long de se connecter avec ssh.. Les DNS inaccessibles en sont-ils la cause ? Le fait de retirer le gateway résoud le problème.
On peut aussi rajouter a la fin du fichier /etc/ssh/sshd_config l'option

UseDNS no

(plus d'info la : http://mediakey.dk/~cc/openssh-disabled-reverse-dns-lookup/ )

Créer un service au démarrage

Il est parfois utile que des commandes soient exécutées au démarrage. Cela varie un peu en fonction des distributions mais l'idée est la même il faut ajouter un script dans /etc/init.d (ne pas oublier de le rendre exécutable avec chmod+x) contenant les commandes en question. Puis (ex sous Debian):

Le "99" assure que le script sera exécuté en dernier. Disclaimer: le sujet est plutôt complexe si on veut bien faire. On peut par exemple faire en sorte que le script réagisse à des commandes START et STOP, et aussi choisir le niveau d'init. Se reporter à Lea qui contient un article beaucoup plus complet.
Sous Gentoo, bien entendu la procédure sera différente (argh), il faut copier manuellement le script dans /etc/init.d puis:

Une page en français concernant Gentoo pour personnaliser ses scripts de démarrage, ici

ALSA connection midi réseau avec aseqnet

Alsa propose des commandes pour envoyer des données midi via un résau et donc cela nous évite de devoir utiliser un câble
Sur le PC1, tapez:

Sur le PC2, tapez:

Vous devrez à présent pouvoir constater avec aconnect -lio en ligne de commandes ou via la fenêtre Connection/MIDI de Qjackctl que des ports MIDI "Net Client" ont fait leur apparition. Il suffit de connecter les applications MIDI sur ces ports et les informations circuleront en réseau d'un PC à l'autre.

OSC

OSC est un protocole non lié à une interface particulière pour autant qu'il s'agisse d'une connexion réseau. Il y a peu de logiciels Linux qui utilisent OSC mais c'est néanmoins utilisable. Par exemple PureData peut tout à fait envoyer des données de cette façon à un autre programme OSC.

Communication audio entre PC

Puredata

cf. les objets streamin~/streamout~ de l'external "ggee". Notez que Puredata permet le transfert d'information non-audio via les objets netsend/netreceive en standard et via OSC en utilisant l'external OSCx avec les objets "oscdump" et "oscsend".

Nas (?)

netjack