Posts tagged Linux

[Mémo] Chiffrer un disque dur externe sous Linux

1

Afin de ne plus chercher partout « comment je m’y étais pris la dernière fois » pour fabriquer mon disque dur externe chiffré, je me suis fait un petit mémo. L’objectif est donc d’utiliser LUKS, et quelques lignes de commande.

J’avais un disque dur SATA de 500 Go, récupéré dans une de mes anciennes machines, que je voulais transformer en disque de sauvegarde. J’ai donc utilisé un dock USB, puis branché sur une machine Linux.

Toutes les commandes se font en root ou bien préfixées par sudo. Moi je suis plutôt root sur mes machines, surtout quand j’enchaîne les commandes à privilèges (quitte à faire un sudo /bin/bash…) Mais c’est un vieux troll poilu une autre histoire…

Première étape : le repartitionnement

Fdisk est votre ami.

Fdisk vous affiche les partitions d’un disque donné :

# fdisk -l /dev/sdb

Mais fdisk est avant-tout interactif. Voici ce que ça donne :

# fdisk /dev/sdb

Avec o (lettre o minuscule) : je crée une table des partitions vide, donc je vide en une fois toutes les partitions existantes.

Avec n : je crée une partition. En laissant les valeurs par défaut, la partition occupera l’espace maximal disponible. (suite…)

[Découverte] Monter des images DMG sous Linux avec darling-dmg

0

Si vous êtes un ancien utilisateur de Macintosh, il y a de fortes chances que vous ayez quelques images au format DMG qui traînent quelque part, sur un vieux disque dur ou sur des CD.

Jusqu’ici, la seule méthode pour monter une image disque DMG consistait à convertir l’image DMG en ISO (avec dmg2iso), puis monter la partition HFS+ de l’image ISO (avec le module noyau hfsplus). C’est un processus fastidieux et qui nécessite les privilèges root, mais qui a le mérite d’exister ; si vous êtes curieux, je vous invite à lire cette question sur Ask Ubuntu.

J’ai découvert récemment l’utilitaire darling-dmg qui permet de monter des images DMG très simplement sous Linux. darling-dmg se présente sous la forme d’un pilote FUSE (Filesystem in UserSpacE, système de fichier en espace utilisateur) : plutôt que de créer un module noyau pour implémenter le système de fichier, un pilote FUSE est un programme qui est exécuté par l’utilisateur. Cela ouvre la porte à des systèmes de fichiers farfelus, comme par exemple GmailFS qui permettait d’utiliser sa boîte Gmail comme un espace de stockage, mais cela permet aussi de limiter les kernel panics quand le pilote plante, ce qui arrive parfois avec le module hfsplus…

darling-dmg est un sous-projet du projet Darling. Ce projet à pour vocation de permettre aux linuxiens de faire tourner des applications compilées pour Mac OS X, un peu à la manière de Wine. (suite…)

[Client léger] Exemple de mise en route de ThinStation

0

Introduction

En début d’année, nous nous étions posés la question de recycler un poste Asus EeeBox en un client léger qui soit à la fois capable de gérer du RDP et du 5250. Après quelques recherches, nous avons découvert que ThinStation pouvait répondre à ce besoin. Nous n’avons jamais exploité cette solution mais voici un aperçu rapide d’une mise en route basique.

Matériel utilisé

  • Clé USB
  • Un Asus EeeBox B202
  • Connexion Internet
  • Environ 1 heure

Création de l’environnement de préparation de l’ISO

On commence par télécharger la dernière version de ThinStation, ainsi que l’utilitaire Rufus, qui permettra de créer une clef USB bootable.

C’est à partir de cette clef USB que l’on va faire démarrer la machine à utiliser pour la préparation de l’ISO finale. (suite…)

[Astuces] Connexion automatique en SSH avec PuTTY

0

Lorsque vous gérez un parc important de serveurs, il peut devenir vite fastidieux de retenir tous les identifiants et mots de passe, voire même de les saisir plusieurs fois par jour, des fois même par heure. Dans mon cas, c’est principalement l’administration de machines Linux avec PuTTY qui nécessitait un coup de main.

Objectif : se connecter en quelques clics à un serveur Linux en SSH à l’aide de clés depuis une machine Windows.

Remarque : la configuration du serveur SSH n’est pas dans le périmètre de cet article. Une brève recherche sur n’importe quel moteur du Web vous retournera une surabondance de littérature à ce sujet. On partira donc du principe que votre serveur SSH est configuré et fonctionnel. De même, la gestion de l’authentification par clé publique et les manipulations à effectuer côté serveur ne sont pas détaillées.

Génération d’une paire de clés

La suite logicielle PuTTY propose l’outil PuTTY Key Generator, que vous trouverez en tant que PuTTYgen dans le menu Démarrer. Il est très simple à utiliser.

Génération d’une paire de clés avec PuTTY Key Generator

Au lancement, le logiciel ne contient aucune clé. Un clic sur Generate, comme son nom l’indique, vous permettra de générer une clé. L’aléa de génération est pris à l’aide des mouvements de votre souris dans une zone vide située sous la barre de progression. Vous la verrez avancer à chaque déplacement de votre pointeur.

Dès la génération terminée, des éléments supplémentaires apparaissent, dont les champs de mot de passe permettant de protéger la clé privée. Laissez ces champs vides pour la suite de l’article. (suite…)

[Ubuntu] Désactiver le tapé-glissé (TapAndDrag) d’un Dell XPS 13

0

Le Dell XPS 13 est une petite machine formidable pour y faire tourner une distribution GNU/Linux. Son clavier rétro-éclairé, sa faible bordure autour de l’écran et son autonomie très correcte en font une machine de choix pour tout amateur de machine compacte mais productive.

Lors de l’installation de Ubuntu (plus précisément Xubuntu) sur cette machine, nous avons été confrontés à un désagrément : il est possible de glisser une fenêtre sans cliquer sur le pavé tactile, mais tout simplement en tapant dessus. Malgré une exploration complète des paramètres du touchpad, nous n’avons pas trouvé la manière de désactiver cette fonctionnalité. Ou plutôt : tous les paramètres modifiés (y compris la désactivation du touchpad) n’avaient aucun effet. Mais nous avons fini par trouver une solution !

Le fonctionnement (complexe) du touchpad sur le XPS 13

Il y a une petite éternité, les ordinateurs ont commencé à adopter le protocole PS/2 comme interface pour brancher un clavier et une souris. C’est un protocole très simple à utiliser, qu’on soit concepteur de périphériques informatique ou développeur de systèmes d’exploitation. (suite…)

[Debian/Ubuntu] Installer Etherpad Lite

0

Etherpad Lite est un formidable outil collaboratif permettant de travailler à plusieurs sur un document texte, que vous connaissez peut-être déjà sous le nom de Framapad, qui est une installation d’Etherpad Lite gérée par l’association Framasoft. Dans la continuité de notre démarche d’auto-hébergement, nous avons voulu héberger une instance d’Etherpad Lite sur un de nos serveurs.

Il existe deux versions d’Etherpad : une « Lite » et une non-« Lite ». La version non-« Lite », plus ancienne, était écrite en Scala, et la version « Lite » est la réécriture d’Etherpad en JavaScript (avec Node.js), plus légère que la version originale. Nous allons donc dans ce tutoriel aborder l’installation de la version « Lite » d’Etherpad.

1. Installation de Node.js

Node.js est un environnement javascript plutôt bien adapté à des applications web. Etherpad Lite requiert une version particulière : la v0.11.16, que nous allons nous empresser (!) de compiler.

On va commencer à installer quelques dépendances qui nous serviront tout au long de ce tutoriel :

sudo apt-get install gzip git curl python libssl-dev pkg-config build-essential

Puis on va télécharger les sources :

cd /tmp
 wget http://nodejs.org/dist/v0.11.16/node-v0.11.16.tar.gz
 tar -xzvf node-v0.11.16.tar.gz
 cd node-v0.11.16

Et on va enfin compiler Node :

./configure
 make
 sudo make install

2. Installation de MySQL

On va aller plus loin dans la configuration de notre Etherpad Lite, et nous allons faire en sorte qu’il utilise une base de donnée MySQL pour stocker ses données.

On commence par installer leur serveur MySQL :

sudo apt-get install mysql-server

Lors de l’installation, vous allez devoir renseigner un mot de passe root pour votre base de donnée. Gardez-le précieusement de côté, on va en avoir besoin tout de suite pour se connecter à la base de donnée :

mysql -u root -p

Il faut taper son mot de passe pour arriver à un invite de commande MySQL. On va ensuite créer une base de donnée dédiée à Etherpad Lite, et attribuer les privilèges de cette base de donnée à notre utilisateur etherpad :

create database `etherpad-lite`;
 grant all privileges on `etherpad-lite`.* to 'etherpad'@'localhost' identified by '*MOT DE PASSE SQL ETHERPAD*';

Remplacez bien entendu *MOT DE PASSE SQL ETHERPAD* par un mot de passe de votre choix, si possible différent du mot de passe root pour des raisons de sécurité.

3. Installation d’Etherpad Lite

On va commencer par créer un utilisateur séparé pour Etherpad Lite. Vous noterez l’option « –disabled-login », qui permet de désactiver toute connexion directe à cette session pour des raisons de sécurités

sudo adduser --disabled-login --gecos 'Etherpad' etherpad

On va s’y connecter :

cd /home/etherpad
sudo su - etherpad -s /bin/bash

On télécharge les sources via Git :

git clone git://github.com/ether/etherpad-lite.git

On va ensuite changer quelques réglages :

cd etherpad-lite
cp settings.json.template settings.json
nano settings.json

Il faut changer l’IP de l’hôte :

"ip": "0.0.0.0",

par

"ip": "127.0.0.1",

Et aussi supprimer les paramètres de base de donnée actuels :

"dbType" : "dirty",
//the database specific settings
"dbSettings" : {
  "filename" : "var/dirty.db"
},

pour les remplacer par :

"dbType" : "mysql",
"dbSettings" : {
  "user" : "etherpad",
  "host" : "localhost",
  "password": "*VOTRE MOT DE PASSE MYSQL*",
  "database": "etherpad-lite"
},

4. Création des scripts de démarrage

Nous allons créer le script de démarrage qui vous permettera de lancer etherpad à l’allumage du serveur, mais aussi de l’arrêter et de le redémarrer facilement.

On fait un sudo nano /etc/init.d/etherpad, et on y insère le code suivant :

#!/bin/sh

### BEGIN INIT INFO
# Provides: etherpad-lite
# Required-Start: $local_fs $remote_fs $network $syslog
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: starts etherpad lite
# Description: starts etherpad lite using start-stop-daemon
### END INIT INFO

PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/node/bin"
LOGFILE="/var/log/etherpad.log"
EPLITE_DIR="/home/etherpad/etherpad-lite"
EPLITE_BIN="bin/run.sh"
USER="etherpad"
GROUP="etherpad"
DESC="Etherpad"
NAME="etherpad"

set -e

. /lib/lsb/init-functions

start() {
 echo "Starting $DESC... "

 start-stop-daemon --start --chuid "$USER:$GROUP" --background --make-pidfile --pidfile /var/run/$NAME.pid --exec $EPLITE_DIR/$EPLITE_BIN -- $LOGFILE || true
 echo "done"
}

#We need this function to ensure the whole process tree will be killed
killtree() {
 local _pid=$1
 local _sig=${2-TERM}
 for _child in $(ps -o pid --no-headers --ppid ${_pid}); do
 killtree ${_child} ${_sig}
 done
 kill -${_sig} ${_pid}
}

stop() {
 echo "Stopping $DESC... "
 while test -d /proc/$(cat /var/run/$NAME.pid); do
 killtree $(cat /var/run/$NAME.pid) 15
 sleep 0.5
 done
 rm /var/run/$NAME.pid
 echo "done"
}

status() {
 status_of_proc -p /var/run/$NAME.pid "" "etherpad" && exit 0 || exit $?
}

case "$1" in
 start)
 start
 ;;
 stop)
 stop
 ;;
 restart)
 stop
 start
 ;;
 status)
 status
 ;;
 *)
 echo "Usage: $NAME {start|stop|restart|status}" >&2
 exit 1
 ;;
esac

exit 0

On met les bonnes permissions et on met le script en démarrage automatique :

chmod +x /etc/init.d/etherpad
update-rc.d etherpad defaults

5. Installation de Nginx, et configuration en reverse proxy

J’utiliserai Nginx et non Apache dans ce tutoriel en raison de sa plus grande simplicité. Nginx va nous servir de reverse proxy, ce qui nous permettera d’associer plusieurs noms de domaines à notre adresse IP et d’avoir des logs d’accès.

On commence par installer le paquet de Nginx :

sudo apt-get install nginx

On crée un certificat SSL, pour permettre une utilisation de HTTPS :

sudo mkdir /etc/nginx/ssl
cd /etc/nginx/ssl
sudo openssl genrsa -des3 -out etherpad.key 2048
sudo openssl req -new -key etherpad.key -out etherpad.csr
sudo cp etherpad.key etherpad.key.org
sudo openssl rsa -in etherpad.key.org -out etherpad.key
sudo openssl x509 -req -days 365 -in etherpad.csr -signkey etherpad.key -out etherpad.crt

Et enfin on crée le fichier de description de l’hôte virtuelle pour Etherpad Lite, en faisant un sudo nano /etc/nginx/sites-enabled/etherpad, en y tapant les lignes de configurations suivantes :

server {
  listen 443 ssl;
  server_name *NOM DE DOMAINE*;

  access_log /var/log/nginx/etherpad.access.log;
  error_log /var/log/nginx/etherpad.error.log;

  ssl_certificate /etc/nginx/ssl/etherpad.crt;
  ssl_certificate_key /etc/nginx/ssl/etherpad.key;

  location / {
    proxy_pass http://localhost:9001/;
    proxy_set_header Host $host;
    proxy_buffering off;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
  }
}

server {
  listen 80;
  server_name *NOM DE DOMAINE*;

  access_log /var/log/nginx/etherpad.access.log;
  error_log /var/log/nginx/etherpad.error.log;

  location / {
    proxy_pass http://localhost:9001;
    proxy_set_header Host $host;
    proxy_buffering off;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
  }
}

map $http_upgrade $connection_upgrade {
  default upgrade;
  '' close;
}

N’oubliez pas d’inscrire au bon endroit le nom de domaine que vous souhaitez associer à votre installation d’Etherpad.

Et pour finir, nous pouvons recharger la configuration de Nginx :

sudo service nginx reload

Conclusion

L’installation d’Etherpad Lite est un processus long et un peu difficile pour un initié, mais permet une installation solide : notre installation est en route depuis plus de 2 mois, sans nécessiter beaucoup de maintenance.

En cas de soucis, le canal IRC #etherpad-lite-dev sur Freenode est disponible pour répondre à toutes vos questions.

[XiVO] Problème d’affichage de l’heure sur Cisco 7941 en cas de redémarrage d’Asterisk

11

Quel plaisir d’avoir votre système de téléphonie qui marche bien, les téléphones qui se configurent sans intervention physique, des groupes, des messageries, etc.

Le problème c’est que certains détails me chagrinent parfois à en perdre le sommeil. Si vous êtes aussi névrosé que moi, je vais peut-être pouvoir vous aider.

Nous avons trois types de postes. Les Cisco IP Phone 7960, les postes des bureaux du siège, les 7940 qui sont réservés à l’infrastructure, au local technique des agences, et éventuellement pour des lignes secondaires d’utilisateurs, et enfin, les 7941, les postes utilisateurs on-site.

Nous provisionnons nos téléphones directement dans XiVO, je reviendrai la dessus dans un futur billet, et tous les paramètres sont injectés automatiquement sans intervention dans chaque téléphone. Il me suffit de dire que le téléphone X ait telle ligne, et quelques secondes plus tard, le téléphone en question se voit affublé de la ligne demandée. Quelques clics, et quel plaisir de ne plus avoir à se déplacer et configurer manuellement, et surtout sans avoir à mettre les mains dans le cambouis.

Dans les différentes pages de configuration de XiVO, on paramètre la langue et le fuseau horaire, et si on fait bien les choses, les téléphones affichent bien la date et l’heure pour la France, dans le format suivant:

Cisco-7941-24h

Cisco IP Phone 7941 avec affichage en 24h, juste après une synchronisation de la ligne

Lorsque vous provisionnez les téléphones, tout va bien, mais j’ai remarqué que de temps en temps, certains téléphones perdaient le format d’affichage de l’heure et la date. En effet, on demandait à afficher la date en français, et au bout de quelques heures (après un changement d’adresse IP WAN de l’agence ou un redémarrage d’Asterisk) l’heure se remettait à s’afficher sous la forme:

Cisco-7941-12h

Cisco IP Phone 7941 en mode 12h, après avoir redémarré Asterisk

Cela semble venir non pas de XiVO mais des téléphones eux-mêmes qui vont chercher leur configuration dans le traditionnel fichier XML généré automatiquement pour chaque téléphone et non pas la configuration que l’utilisateur a choisi dans l’interface Web de XiVO.

Pour corriger le problème, il faut déjà comprendre comment est fait le greffon Cisco, en voici l’arborescence:

Arborescence d'un greffon XiVO

Vous pouvez visualiser cela directement en console. Connectez vous en SSH à votre serveur XiVO. Puis rendez vous dans le dossier qui contient les greffons:

ssh -l root <<votre serveur>>

Puis entrez votre mot de passe. On accède ensuite au dossier du greffon:

cd /var/lib/xivo-provd/plugins/xivo-cisco-sccp-9.0.3

Maintenant qu’on est là, je vous explique. Pour générer un fichier de configuration pour les téléphones, des fichiers de template sont utilisés. Dans notre cas, pour les 7941, ce sont les fichiers 7941G.tpl et base.tpl qui sont utilisés. Ce dernier contient en effet les réglages de base. C’est lui qu’on va modifier.

Pour cela, on va utiliser nano:

nano templates/base.tpl

Voici à quoi ressemble le fichier:

Fichier base.tpl avant édition

Fichier base.tpl avant édition

On va éditer la zone entourée en rouge. Après quelques tentatives, j’ai découvert qu’il suffit de modifier la syntaxe. Pour passer de 17-02-15 à 17/02/15, il suffit tout simplement de remplacer D-M-YA par D/M/YA. En ce qui concerne l’affichage de l’heure, il est conditionné par le A final. Dans le cas présent, le A provoque l’affichage en mode 12h. Il suffit donc de le retirer comme dans la capture suivante pour passer en mode 24h.

Fichier base.tpl modifié.

Fichier base.tpl modifié.

Une fois que c’est fait, vous pouvez enregistrer. Pour cela, pressez Control X, puis la lettre O et enfin Return pour valider.

Il reste maintenant une étape. Nous avons effectivement modifié le template mais les fichiers déjà générés contiennent toujours l’erreur et provoqueront le même dysfonctionnement. On va donc les régénérer.

On va donc envoyer maintenant cette commande:

provd_pycli -c 'devices.using_plugin("xivo-cisco-sccp-9.0.3").reconfigure()'

Vous allez voir apparaître autant de lignes absconses que vous avez de ces modèles de téléphones déjà enregistrés dans XiVO. Et ensuite… C’est terminé. Faites le test à froid pour être sûr. Redémarrez tout, serveur, téléphones et laissez le tout s’initialiser. Puis redémarrez Asterisk via l’interface de XiVO, et une fois les téléphones réenregistrés, la date et l’heure devraient s’afficher correctement là où ils affichaient l’heure au format 12h avant la modification.

Cela fait maintenant quelques semaines que cette solution fonctionne chez nous. Si vous avez mieux, plus simple, plus efficace à proposer, je serai ravi de modifier ce tutoriel.

Edition du 16 février 2015 :

Comme indiqué dans les commentaires par quelqu’un de chez XiVO, que je remercie chaleureusement au passage, il est préférable de ne pas éditer directement le fichier base.tpl car une mise à jour du greffon supprimera vos modifications. Copiez donc ce fichier dans le dossier var/templates (à l’intérieur du greffon) et éditez celui-là. Les indications nécessaires sont indiquées en commentaire.

[XiVO] Auto-hébergement, téléphonie, pfSense, OVH

3

Bonjour tout le monde !

1. Je vous explique le contexte

Comme vous le savez peut-être, voilà maintenant un peu plus d’un an que je me suis lancé, non sans difficultés, dans l’univers incroyable et merveilleux de la téléphonie IP. Nous avons commencé par un serveur dédié OVH Kimsufi 2G, cinq téléphones Cisco 7960 avec firmware SIP, et une ligne SIP Free (activable gratuitement dans l’interface client de tout abonné Freebox, alors autant s’amuser avec).

Quelques tests et bidouillages plus loin, ça marchait. On pouvait se téléphoner entre nous, appeler et recevoir des appels de l’extérieur et pendant plusieurs mois, tout fonctionnait à merveille. J’ai eu besoin d’un peu de temps pour mieux comprendre certains mécanismes de la VoIP avec Asterisk, essayer plusieurs autres distributions packagées comme Elastix. Mais au final, plus je connais XiVO, plus j’ai envie de l’utiliser.

Cisco 7941En effet, comme je n’y connais pas grand chose, je fais des recherches. Et à chaque fois je constate que le problème de la personne est un bug qui date des premières versions et qui depuis a été corrigé, je constate aussi que les demandes et retours des utilisateurs sont pris très au sérieux. De plus, j’ai eu pour les quelques soucis que je n’ai pu régler seul le plaisir de discuter en direct avec l’équipe, qu’il est très facile de contacter et qui sont la meilleure référence quand on a une question. Je précise qu’on ne me paye pas pour dire tout ça, mais je suis bien obligé de reconnaître que c’est très plaisant de discuter avec des gens compétents et sympas.

J’ai pas mal évolué, à tous les niveaux. Je comprends un peu mieux ce que je fais, même s’il m’arrive de me tromper et nous avons depuis changé un peu de matériel. En effet, nous avons cherché d’autres téléphones. Les Cisco IP Phones de la série 7900 sont très sympa et on les trouve très classe sur nos bureaux. Cependant, nous n’en avions que cinq mais rapidement nous nous sommes retrouvé avec un total de 32 de ces téléphones : Un mix de 7940, 7960 et 7941.

2. La solution de départ

  • Un serveur dédié OVH Kimsufi 2G
  • Connexion 100 Mb/s directement reliée (on retrouve l’IP externe sur l’interface Ethernet)
  • Debian Wheezy 32bit
  • XiVO installé via le script bash
  • Nos sites équipés de routeurs pfSense avec un proxy SIP (Siproxd)
  • Téléphones Cisco avec firmware SIP, pas de provisioning, configuration entièrement via les menus du téléphone

Ça fonctionnait, c’était assez stable, mais les firmwares SIP ne sont pas d’aussi bonne qualité que les firmwares SCCP pour ces téléphones. De plus, XiVO ne gère pas le provisioning de ces postes en SIP mais seulement en SCCP. On aurait pu croire qu’il aurait suffit de passer les téléphones en SCCP pour pouvoir gérer ça mais ce protocole passe mal à travers le NAT de nos routeurs.

3. Une minute de réflexion

Nous avons interconnecté trois de nos sites (et d’autres à venir) par OpenVPN en utilisant nos routeurs. Nous avions donc comme idée de relier également notre serveur dédié à XiVO chez OVH par VPN afin de se retrouver comme sur un réseau local et donc de profiter du provisioning et du SCCP. Le problème c’est qu’on a un peu merdé. Et puis on s’est dit : « Mais attends, de l’autre côté de ce mur — oui, il y avait un mur quand on s’est dit ça — il y a une baie avec des serveurs qui nous appartiennent ». Donc on a utilisé un de nos serveurs pour la téléphonie. Au moins il est chez nous, et c’était bien l’objectif de départ que d’héberger nous-même ce dont on a besoin. Ceci étant dit, on se retrouve donc avec un serveur de téléphonie, en local. On met un firmware SCCP dans nos téléphones, on crée quelques lignes et tout se met à marcher, du moins en interne.

4. Appels internes c’est bien, mais externes c’est quand même pratique

Nous souhaitons donc relier notre serveur XiVO local à une ligne SIP OVH. Nous avons choisi une ligne SIP Entreprise sans les appels vers les mobiles. Nous allons utiliser cette ligne en tant que trunk. Ce sera en quelque sorte le lien entre notre serveur de téléphonie, et ceux d’OVH, permettant ainsi de passer des appels vers et depuis l’extérieur.

Nous avons quelques contraintes :

  1. Notre serveur de téléphonie doit être fiable
  2. Il doit permettre le provisioning des postes et le SCCP
  3. La téléphonie doit fonctionner depuis n’importe quel site, provisioning compris
  4. Le serveur est situé sur un réseau local derrière un routeur pfSense
  5. Il doit permettre les appels vers et depuis l’extérieur

A ces contraintes, nous avons apporté les solutions suivantes :

  1. Nous allons utiliser un serveur HP ProLiant DL380 G4, avec du RAID, RAM, alimentations, ventilation redondante, bref, la totale
  2. Il faut pour cela installer les greffons correspondant aux téléphones dans l’interface de gestion de XiVO (dans notre cas il faut également trouver les bonnes versions des firmwares, merci Cisco)
  3. Nous utilisons des VPN entre nos différents sites
  4. Nous allons installer le package siproxd sur le routeur
  5. Il faut pour cela configurer un trunk dans XiVO.

C’est justement les points 4 et 5 qui nous intéressent car ça ne coule pas forcément de source pour un néophyte.

5. Configuration du routeur

On considère un routeur pfSense fonctionnel, avec une interface LAN et une WAN. Côté WAN on est raccordé a une Freebox en mode bridge, nous permettant de récupérer directement l’adresse IP externe sur l’interface réseau du routeur. Côté LAN on est en statique, dans notre cas 192.168.10.1. Le serveur DHCP du routeur est activé et on a attribué une adresse fixe à notre serveur de téléphonie. Notre VPN est configuré et vous pouvez vous aider de cette méthode. Dans les paramètres du serveur DHCP, on va ajouter une option 150 correspondant à notre serveur de téléphonie si on souhaite gérer le provisioning.

Ce que l’on va faire maintenant, c’est installer un paquet sur le routeur. On se connecte donc via un navigateur sur l’interface Web de gestion de pfSense, disponible sur son adresse LAN.

On va dans le menu System, puis Packages et s’affiche la liste des paquets disponibles. On clique alors sur le bouton en regard de siproxd. L’installation va se lancer. Il est important de laisser le routeur procéder à l’installation avant de cliquer ailleurs.

Une fois que c’est terminé, on peut se rendre dans le menu Services, puis siproxd pour procéder à la configuration.

Très peu de choses à régler. Cochez la case Enable siproxd, sélectionnez LAN dans le menu inbound interface, et WAN dans le menu outbound interface. Les deux champs suivants doivent rester vides.

On passe ensuite à RTP Settings, où tout doit être vide à l’exception de la case Enable RTP proxy. Dans la catégorie DSCP Settings, cocher les deux cases.

Tout le reste doit impérativement être décoché ou vide, puis sauvegardez.

6. Configuration de XiVO

On considère un serveur XiVO configuré et fonctionnel avec les appels internes. On ne peut pas encore passer d’appels externes, entrants comme sortants.

On va commencer, comme dans tous les guides que l’on peut trouver par se rendre dans l’onglet Services, puis IPBX.

XiVO Services IPBX

Dans la colonne de gauche, et plus précisément dans Gestion des interconnexions, on clique sur Protocole SIP. Un tableau vide devrait alors apparaître. On clique sur le bouton + en haut à droite, s’affiche alors une page de configuration avec quatre onglets.

Je ne vais préciser que les champs dans lesquels on entre quelque chose :

a. Onglet Général

On entre l’identifiant de la ligne (ex. 0033XXXXXXXXX)

On recopie le champ précédent

Le mot de passe correspondant à la ligne OVH

Varie selon l’offre choisie (dans notre cas c’est 2)

Friend

Statique (Cela fait apparaître un champ supplémentaire : sip.ovh.fr)

Appels entrants (from-extern)

fr_FR

b. Onglet Enregistrement

On coche la case

udp

L’identifiant de la ligne (ex. 0033XXXXXXXXX)

On recopie le champ précédent

Le mot de passe correspondant à la ligne OVH

Serveur distant : sip.ovh.fr

5060

c. Onglet Signalisation

DTMF : Inband

Personnaliser les codecs : On coche la case, faisant apparaitre deux tableaux

On clique sur le + en regard des codecs GSM (Audio) et G.711 A-law (Audio).

Ces deux codecs doivent apparaître dans la colonne de gauche.

d. Onglet Avancé

Insécurité : Tout

Port : 5060

Réécriture du champ From-User : L’identifiant de la ligne (ex. 0033XXXXXXXXX)

Réécriture du champ From-Domain : sip.ovh.fr

Protocoles réseau : udp

Enfin, on sauvegarde.

On vient donc de créer le lien d’interconnexion avec notre fournisseur SIP chez OVH. Celui-ci va nous servir à passer des appels vers l’extérieur. Comme nous avons placé notre serveur de téléphonie derrière un proxy SIP, nous devons créer un deuxième trunk avec la même méthode qui sera utilisé pour les appels entrants.

On va donc retourner dans la liste des interconnexions SIP si ce n’est pas déjà fait, et on va à nouveau cliquer sur le + en haut à droite.

On va plus ou moins reproduire ce qu’on a fait précédemment, à quelques différences près.

a. Onglet Général

trunk-incoming (par exemple, pour l’identifier aisément)

 On entre l’identifiant de la ligne (ex. 0033XXXXXXXXX)

Le mot de passe correspondant à la ligne OVH

Varie selon l’offre choisie (dans notre cas c’est 2)

Peer

Statique (Cela fait apparaître un champ supplémentaire dans lequel on entre l’IP du proxy SIP, dans notre cas 192.168.10.1)

Appels entrants (from-extern)

fr_FR

b. Onglet Enregistrement

On ne coche pas la case (on ne remplit rien)

c. Onglet Signalisation

DTMF : Inband

Personnaliser les codecs : On coche la case, faisant apparaitre deux tableaux

On clique sur le + en regard des codecs GSM (Audio) et G.711 A-law (Audio).

Ces deux codecs doivent apparaître dans la colonne de gauche.

d. Onglet Avancé

Insécurité : Tout

Port : 5060

Réécriture du champ From-User : L’identifiant de la ligne (ex. 0033XXXXXXXXX)

Réécriture du champ From-Domain : sip.ovh.fr

Protocoles réseau : udp

On sauvegarde, et on a terminé pour ce qui est des interconnexions SIP.

Maintenant que c’est fait on va expliquer au serveur ce qu’il faut faire en cas de réception ou d’émission d’un appel.

On va donc se rendre dans Appels sortants, sous la catégorie Gestion des appels, et on clique sur le traditionnel +.

a. Onglet Général

Nom : ovh (par exemple)

Contexte : to-extern

Temps de sonnerie avant de raccrocher : Illimité

Interconnexions : On clique sur le + en regard du trunk que nous avons créé pour les appels sortants, celui dont le nom est le numéro de ligne OVH.

b. Onglet Extensions

Un tableau vide s’affiche avec une case +, sur lequel on clique, faisant apparaître une ligne vide. Dans la case Extension, on entre « 0. » sans les guillemets pour définir la syntaxe d’un numéro externe. Le zéro sera à composer avant le numéro de votre correspondant à l’extérieur. Le point est important car il signifie que tout ce qui viendra après le zéro sera le numéro du correspondant.

Note : D’autres tutoriels indiquent qu’il faut saisir « 0XXXXXXXXXX ». Chaque X représentant un unique chiffre, cela signifie qu’on ne peut appeler que des numéros à 10 chiffres. Personnellement, je préfère le point, représentant une suite quelconque de chiffres, pour pouvoir appeler les numéros courts de certains services clientèle, etc.

Dans la liste déroulante Stripnum on choisit 1. Enfin on peut sauvegarder.

On peut maintenant faire un test d’appel. À l’aide d’un téléphone interne, on tente de composer un numéro externe précédé d’un zéro. Et normalement, l’appel s’effectue et on peut même discuter avec le correspondant.

C’est terminé pour les appels sortants.

On va maintenant dans la colonne de gauche choisir Appels entrants, et dans la page qui s’affiche on va encore choisir le + en haut à droite.

Cette partie est très simple.

SDA : Votre numéro d’appel OVH, mais sous la forme classique 0911223344

 

Contexte : Appels entrants (from-extern)

 

Destination : Utilisateur (par exemple)

 

Renvoyez vers : L’utilisateur désiré

On sauvegarde et enfin il ne reste plus qu’à se rendre dans Contextes, dans la colonne de gauche.

On clique ensuite sur l’icône en regard de la ligne from-extern, puis on se rend dans l’onglet Appels entrants.

Dans le tableau, on clique sur le +, on tape le numéro d’appel sous la forme 0911223344 dans le champ Début de l’intervalle de numéros, et on choisit 10 dans la case Nombre de chiffres reçus. On sauvegarde et c’est terminé pour la configuration.

A présent, on peut tenter un appel depuis l’extérieur en composant le numéro de ligne OVH, et si je n’ai rien oublié, le poste choisi dans le champ Renvoyez vers devrait sonner.

Vous pouvez vous connecter à votre pfSense, sur l’onglet Users du package siproxd. Vous devriez voir apparaître une ligne correspondant à votre trunk OVH.

Ceci est notre configuration et elle fonctionne. Si toutefois vous aviez une meilleure idée, une amélioration ou une correction à apporter, laissez donc un commentaire. J’ai réalisé ce tutoriel grâce à l’aide des développeurs de XiVO et j’en profite pour les remercier pour l’excellent travail qu’ils font.

[IPBX] Astuce pour les noms d’utilisateurs et mots de passe des extensions XiVO

0

Salut à tous !

Envie de bidouiller un peu de la téléphonie et j’ai un tout petit peu de temps libre, ça tombe bien, ça faisait longtemps que j’avais pas touché à XiVO.

Voici donc une petite astuce que j’ai trouvé un peu éparpillée sur le net que je n’invente pas, c’est juste pour la garder sous le coude. C’est pour faire un truc interdit par défaut, modifier le nom d’utilisateur et le mot de passe d’une extension. Habituellement lorsqu’on crée une nouvelle extension, le nom d’utilisateur et le mot de passe sont générés par le système et vous ne pouvez pas le modifier. Pour vous donner ce droit, il faut faire une petite manipulation simple.

Ouvrez un terminal et connectez vous à votre serveur et entrez votre mot de passe root :

$ ssh -l root serveur.domaine.tld

Une fois que c’est fait, on va éditer le fichier « ipbx.ini » :

$  nano /etc/xivo/web-interface/ipbx.ini

A la fin du fichier, modifiez le comme sur la capture :

Xivo Readonly ipwd

Enregistrez, puis connectez vous a l’interface d’administration de XiVo. Tentez d’éditer une de vos lignes et miracle, on peut mettre ce qu’on veut !

xivo config lines

Et voilà ! L’affaire est dans le sac !

Pour vous aider un peu avec XiVO, un petit blog intéressant pour les débutants. Ça contient deux trois trucs sympa pour vous aider à commencer avec ce logiciel.

 

[IPBX] Astuce post-installation de XIVO sur Kimsufi

7

Bonjour !

En rangeant un peu le bordel que j’ai sur ma machine, je suis tombé sur un fichier intéressant que je vais partager avec vous.

J’ai un serveur Kimsufi 2G chez OVH, et il y a quelques temps j’avais installé XIVO en suivant cette procédure. Cependant je m’étais heurté à un petit problème, DAHDI voulait se lancer et échouait. Au départ je ne comprenais pas vraiment pourquoi et surtout pourquoi cela posait problème, mais en cherchant un peu j’avais fini par trouver.

DAHDI c’est Digium/Asterisk Hardware Device Interface. C’est le logiciel qui permet de gérer les cartes de téléphonie. Sur un Kimsufi, il n’y en a pas, et cela crée une erreur lors du lancement des services. Pour régler ça, il faut dégager DAHDI.

Pour commencer, connectez-vous en SSH sur votre serveur XIVO.

On va ensuite éditer un fichier avec cette commande :

nano /usr/bin/xivo-service

On fait une recherche pour trouver le terme « dahdi » et on supprime l’occurrence. On enregistre et on va relancer les services :

xivo-service restart

On voit apparaître alors :

Closing port 5060.

Waiting for services to stop successfully...

Waiting for services to start successfully...

starting rabbitmq-server ... OK

starting xivo-sysconfd ... OK

xivo-confgend is disabled

xivo-dxtora is disabled

xivo-provd is disabled

xivo-agid is disabled

starting asterisk ... OK

xivo-agent is disabled

xivo-ctid is disabled

xivo-restapi is disabled

Opening port 5060.

XiVO fully booted

Ensuite, on enclenche les services avec :

xivo-service enable

Et on relance le tout :

xivo-service restart

On voit alors apparaître :

Closing port 5060.

Waiting for services to stop successfully...

Waiting for services to start successfully...

starting rabbitmq-server ... OK

starting xivo-sysconfd ... OK

starting xivo-confgend ... OK

starting xivo-dxtora ... OK

starting xivo-provd ... OK

starting xivo-agid ... OK

starting asterisk ... OK

starting xivo-agent ... OK

starting xivo-ctid ... OK

starting xivo-restapi ... OK

Opening port 5060.

XiVO fully booted

C’est fini, et maintenant les services démarrent correctement !

Go to Top