Thomas

Thomas

This user hasn't shared any profile information

Home page: http://www.labcellar.net

Posts by Thomas

[Asterisk] Protéger un sous-menu de serveur vocal par un mot de passe

3

Bonjour à tous,

Depuis plusieurs mois années (la vache, le temps passe super vite), nous utilisons un serveur de téléphonie basé sur Asterisk. Il s’agissait à l’origine de XiVO, qui depuis a forké pour devenir Wazo. Ce dernier est toujours géré par sa super équipe de développeurs habituelle basée au Québec. XiVO existe toujours mais ne correspond pas à nos attentes sur différents plans, mais ce n’est pas le sujet.

Au départ nous n’avions qu’un seul numéro provenant d’une ligne SIP Free, qu’il suffit d’activer depuis son espace abonné Freebox. Pour joindre différents postes, nous avons très vite été obligés de mettre en place un IVR, ou SVI. Plus clairement, il s’agit de ce qu’on appelle un Serveur Vocal Interactif, Interactive Voice Response.

L’objectif est d’expliquer à Asterisk, le moteur de téléphonie, ce qu’il va devoir faire dans tel ou tel cas. Pour cela, on lui expliquera tout cela avec une syntaxe bien spécifique. Je mets un peu les briques dans le désordre. Je ne vais pas expliquer spécialement les principes de base mais plutôt vous montrer comment j’ai réalisé ce que je souhaitais obtenir afin que vous puissiez vous en inspirer, voire améliorer ce que j’ai fait (qui contient probablement des erreurs dues à mon manque de pratique dans le domaine).

Pour l’occasion, je vous partage mon serveur vocal, un peu modifié pour le rendre plus digeste et surtout retirer les lignes inutiles. La logique de ce serveur vocal est simple, nous souhaitons que les appelants puissent nous contacter mais aussi, qu’en cas de besoin, nous puissions accéder à des fonctions avancées qui doivent nous être réservées, il faut donc les protéger, et quoi de mieux qu’un code à taper sur le téléphone. (suite…)

[Astuce] Économie de bande passante lors des mises à jour de téléphones Cisco IP Phone

0

Bonjour à tous,

Aujourd’hui un tout petit article pour une toute petite astuce.

Lorsque je déploie des téléphones Cisco IP Phone, dans mon cas des 7975, il arrive que le serveur ne soit pas sur le même site que les postes. L’approvisionnement des téléphones se faisant par FTP, le temps de chargement des fichiers composant le firmware peut être assez long. Si en plus je dois déployer plusieurs téléphones en simultané, je me retrouve vite obligé de patienter de longues minutes inutilement.

Pour contrer ce problème, il suffit de temporiser le déploiement de chaque téléphone. Seulement, si pour chaque poste la mise à jour se fait plus vite, au global on perd encore plus de temps.

Cisco y a pensé et a doté les téléphones d’une fonctionnalité très intéressante. On peut activer le partage de firmware.

Concrètement, on va pouvoir déployer tous les postes simultanément. Les téléphones vont communiquer entre eux et un seul va télécharger les firmwares pendant que les autres attendent. Une fois les firmwares téléchargés ils vont être transmis aux autres postes via le réseau local.

Pour activer cette fonctionnalité, il suffit simplement d’ajouter une balise XML dans vos fichiers ou vos templates de configuration, dans la zone vendorConfig :

<peerFirmwareSharing>1</peerFirmwareSharing>

Et le tour est joué !

[LabCellar] Notre nouveau venu dans l’infra

0

Bonjour à tous,

Le titre est inexact. Il ne s’agit pas d’un nouveau venu, seulement que nous n’avons jamais pu prendre le temps de publier ce billet.

Depuis la mi-avril, nous sommes équipés d’une nouvelle machine. En effet, un magnifique IBM System i5 en excellent état a fait son apparition chez nous. Il s’agit d’un modèle 520 de type 9406 (comme notre précédent iSeries). Cette machine est équipée d’un processeur Power 5 et a donné un gros coup de fouet aux performances de nos programmes.

Voici ce nouveau venu…

Il trône fièrement sur notre baie HP et fait tourner notre programme de gestion des des équipements, ainsi que deux ou trois autres bidouilles, comme l’envoi de mails et de SMS. C’est également le serveur de temps de toute l’infrastructure LabCellar. Il sait compiler du COBOL, du RPG, mais aussi du C et du Java, entre autres. Il dispose aussi d’un environnement d’exécution UNIX, ce qui le rend très polyvalent. Il peut depuis peu communiquer avec nos imprimantes laser et thermiques, et bientôt sera accessible à nos terminaux mobiles Windows CE.

Par ailleurs, nous avons upgradé sa mémoire centrale, remplacé son lecteur de bandes VXA-320 par un SLR60, et lui avons ajouté un second bloc d’alimentation afin de le fiabiliser. Ces ajouts ont été possibles par le prélèvement de ces composants sur une autre machine identique qui nous a été offerte en échange de conseils informatiques. Je ne dévoilerai pas l’identité de notre donateur mais je le remercie très chaleureusement.

[LabCellar] Réorganisation de notre baie et IBM iSeries

1

Bonjour tout le monde,

Suite au remplacement de notre AS/400 (un magnifique 9401-400 sous V4R3) par un iSeries bien plus gros (un 9406-820), nous avons été dans l’obligation de réagencer notre baie. En effet, il a fallu repenser la façon dont sont répartis les équipements sur les différentes phases, dont le câblage réseau est organisé et à mieux mutualiser les ressources de nos serveurs sur les différents sites afin d’en décommissionner un sur les deux présents ici.

Outre l’aspect purement « manutention » de tels changements, nous avons eu la joie intense d’inventorier tout le câblage réseau présent. Nous avons également intégralement refait un panneau de brassage pour le rendre plus modulaire et faciliter les interventions et les évolutions.

Les équipements présents dans la baie ont été un peu déplacés et compte tenu de la place gagnée, nous en avons profité pour y inclure nos deux robots de sauvegarde afin de pouvoir enfermer tout ce qui habituellement se trouve à l’extérieur. Nous avons également investi dans des adaptateurs Twinnax/Ethernet afin de de plus être dépendant de la longueur de nos vieux câbles Twinnax pour le choix de l’emplacement de la console IBM. En ce qui concerne le serveur HP (un ProLiant DL380 G7) il n’est désormais plus administrable que via iLO en console à distance.

Voici deux jolies photos réalisés par Jean

[XiVO] SCCP et provisioning sur téléphones non supportés et DHCP désactivé (MàJ des greffons)

3

Va falloir penser à contacter WordPress pour mettre des titres de 1000 caractères tant je traite de cas particuliers…

Bonjour tout le monde !

Encore un cas ultra particulier avec XiVO. Comme d’habitude, je vous explique.

Préambule

Cisco 7941Nous avons l’immense joie d’utiliser au quotidien XiVO, une solution de téléphonie IP open source de qualité, performante et complète. Ses développeurs sont très sympa et répondent à toutes nos questions. Heureusement, car nous avons l’indélicatesse et le mauvais goût d’infliger à notre valeureux serveur la gestion de téléphones Cisco IP Phones 7900 Series, dont le fonctionnement est presque aussi obscur à comprendre que la physique quantique, l’intérêt en moins.

Cependant nous aimons beaucoup XiVO, et nous aimons beaucoup nos téléphones et je me sentirai comme une âme en peine si je devais me passer d’un de ces bidules (dont nous avons possédé plus d’un quarantaine).

Dans la suite de cet article, lorsque je parle de téléphone Cisco IP Phone 794x (prévus pour gérer jusqu’à deux lignes), comprenez que c’est valable également pour les modèles 796x (qui eux sont prévus pour gérer jusqu’à six lignes). Il est important de bien comprendre également la différence entre l’enregistrement (le fait qu’un téléphone sache se connecter au serveur pour passer des appels) et l’approvisionnement (ou provisioning, soit le fait qu’un téléphone reçoive ses paramètres depuis le serveur). De plus, il serait de bon ton pour parvenir à effectuer les manipulations que vous sachiez utiliser un peu la ligne de commande Linux, même si je vais tenter d’être le plus didactique possible. De plus les manipulation ont été effectuées avec la version 15.02 et 15.03 de XiVO. Elles devraient fonctionner avec des versions plus anciennes ou plus récentes.

Entrons donc dans le vif du sujet.

1. L’existant

  • Nous avons des téléphones Cisco IP Phone 7940 et 7960, ainsi que des 7941 tous supportés mais nous commençons la mise à jour du parc avec des 7945, plus modernes, et également des 7970. Ces modèles ne sont pas supportés par XiVO. Les Cisco ne peuvent être provisionnés qu’en SCCP donc nous les utiliserons tous sur ce protocole, sur nos différents sites à travers nos VPN.

Explication: Pour qu’un modèle puisse s’enregistrer, il faut recompiler le module xivo-libsccp en précisant les modèles à supporter en éditant trois fichiers. C’est rapide à faire et c’est très simple en se connectant au serveur en SSH. Si on ne le fait pas, les modèles non supportés ne pourront qu’afficher « Enregistrement » indéfiniment et seront rejetés par le serveur, les laissant inopérants.

  • Nous avons fait le choix de complètement nous passer d’un VLAN dédié à la téléphonie ainsi que du serveur DHCP intégré de XiVO. Nous préférons en effet gérer l’attribution des adresses de manière globale sur le routeur de chaque site. Dans la mesure où nous utilisons des VPN nous ne souhaitons pas compliquer davantage la configuration de chaque routeur afin de limiter les erreurs et simplifier les diagnostics.

Explication: Cela n’empêche pas le fonctionnement du provisioning mais il y a un problème. XiVO, dans cette configuration, se trouve incapable de déterminer automatiquement le modèle de téléphone, impliquant de devoir sélectionner manuellement le greffon pour chaque téléphone (c’est une archive contenant ce qu’il faut pour générer un fichier de configuration pour chaque terminaison, c’est également là que l’on place les fichiers de firmware Cisco, plus d’informations ici).

Un autre problème, c’est que dans un greffon se trouve la gestion de plusieurs téléphones. Sauf que si XiVO ne sait pas précisément quel modèle on veut provisionner, alors il créera seulement un fichier générique qui ne contient pas les spécificités de chaque modèle. Ça fonctionnera quand même pratiquement à tous les coups mais ce n’est pas idéal.

  • Comme le 7945 et le 7970 ne sont pas du tout supportés, si on modifie le module xivo-libsccp, ils seront capables de s’enregistrer, mais encore faut il un greffon pour les provisionner!

Explication: Au départ, j’avais modifié le greffon qui gère entre autres les Cisco 7941 et 7942 pour lui faire accepter les 7945 et 7970, ces dernier étant simplement des nouvelles versions du 7941. Et cela fonctionnait correctement. Rapidement j’ai découvert que les fichiers de configuration permettaient bien de faire fonctionner indifféremment un 7941 ou un 7945, mais les options spécifiques à chaque modèle n’étaient pas renseignées dans les fichiers générés. Une option dans XiVO permettant d’effectuer ce choix était vraisemblablement présente mais elle a été retirée, selon les dires d’un développeur.

J’ai alors décidé de rétablir ce choix manuel grâce à une petite astuce. Puisque l’on peut toujours choisir manuellement un greffon, j’ai créé des greffons dédiés modèle par modèle à partir des greffons officiels fournis par XiVO. Ainsi, lorsque l’on se trouve dans la même configuration, il suffit d’ajouter un de nos greffons modifiés et l’attribuer à une terminaison, un téléphone.

J’ai souhaité rendre cela facile d’accès pour tout le monde, il suffit de savoir manipuler un peu la ligne de commande sous Linux et comprendre un peu le fonctionnement des greffons et de XiVO. Attention tout de même, les greffons Cisco sont fournis sans les fichiers firmware à l’intérieur, il faut donc se les procurer séparément, comme pour les greffons officiels.

2. Modification et recompilation du module xivo-libsccp pour supporter le Cisco 7945 et le 7970

C’est presque l’étape la moins risquée, mais tout de même assez sensible. De mauvaises manipulations pourraient entraîner un fonctionnement erratique. J’ai choisi d’ajouter deux modèles pour vous montrer la marche à suivre mais il est tout à fait possible d’en ajouter d’autres.

On va donc commencer par accéder au serveur, dans mon cas en SSH.

ssh -l root IP.DE.VOTRE.XIVO

Puis, une fois le mot de passe saisi et validé, on entre la commande suivante:

apt-get update && apt-get install build-essential asterisk-dev git-core

Acceptez ce qui est proposé. Puis nous allons entrer successivement :

git clone https://github.com/xivo-pbx/xivo-libsccp.git
cd xivo-libsccp/xivo-libsccp/

C’est là que le plus risqué doit être fait. La documentation officielle indique qu’il faut compiler. Dans notre cas, nous allons préalablement éditer trois fichiers à l’aide de nano: sccp_device.csccp_msg.c ainsi que sccp_msg.h.

On va s’en occuper dans l’ordre:

nano sccp_device.c

On va d’abord rechercher l’emplacement où se trouvent les modèles supportés. On utilise la commande Control-W pour cela, puis on tape le texte à chercher et on valide en appuyant sur la touche Entrée. Ici on va rechercher par exemple case SCCP_DEVICE_7942, car on sait qu’il est déjà dedans. Note : Il est possible que l’on trouve déjà dans le fichier les informations pour le 7970.

Cela renvoie vers une liste qui ressemble à ceci (en gras, ce que l’on ajoute):

 case SCCP_DEVICE_7941:
 case SCCP_DEVICE_7941GE:
 case SCCP_DEVICE_7942:
 case SCCP_DEVICE_7945:
 case SCCP_DEVICE_7960:
 case SCCP_DEVICE_7961:
 case SCCP_DEVICE_7962:
 case SCCP_DEVICE_7970:

On va maintenant enregistrer les modifications en utilisant la commande Control-X, et on valide lorsqu’il nous est demandé si on veut enregistrer les changements.

On vient de s’occuper du premier fichier, il en reste deux autres. Ce ne sera pas plus compliqué. Je vais abréger un peu, il suffit de reproduire ces étapes pour chaque fichier.

Dans le cas de sccp_msg.c on va donc rechercher quelque chose qui n’est pas en gras et ajouter ce qui l’est:

 case SCCP_DEVICE_7942:
          return "7942";
 case SCCP_DEVICE_7945:
          return "7945";
 case SCCP_DEVICE_7960:
          return "7960";
 case SCCP_DEVICE_7961:
          return "7961";
 case SCCP_DEVICE_7970:
          return "7970";

Et enfin, même opération pour le fichier sccp_msg.h:

 SCCP_DEVICE_7962 = 404,
 SCCP_DEVICE_7937 = 431,
 SCCP_DEVICE_7942 = 434,
 SCCP_DEVICE_7945 = 435,
 SCCP_DEVICE_7905 = 20000,
 SCCP_DEVICE_7920 = 30002,
 SCCP_DEVICE_7970 = 30006,

Je ne sais pas à quoi correspond précisément la valeur à droite du numéro de modèle mais c’est nécessaire. Pour ajouter le support d’un modèle supplémentaire, il suffit de reprendre ces étapes, et pour la valeur en question, vous pouvez vous aider de ceci. Attention, un modèle non supporté pourra ainsi s’enregistrer, mais il faudra encore avoir un greffon d’approvisionnement qui le gère.

À partir de là, une fois que tous les fichiers sont modifiés et enregistrés (il est préférable de se relire), on va pouvoir compiler conformément à ce qui est expliqué dans la documentation. Pour cela, on entre l’une après l’autre les commandes suivantes:

make
make install

Quand tout est terminé, on redémarre le serveur avec la commande reboot. On entre ensuite le nom d’hôte du serveur si on est connecté en SSH.

3. Installation des greffons modifiés

On se connecte à l’interface d’administration web de XiVO, puis on choisit l’onglet Configuration, et enfin, dans la colonne de gauche, sous Approvisionnement, on clique sur Configuration.

Dans le champ URL, entrez l’adresse du dépôt de greffons que nous avons spécialement créé:

http://xivo-provd.labcellar.com

 

On sauvegarde la configuration, puis on se rend dans Greffons (dans la colonne de gauche), et on clique sur l’icône en haut à droite qui permet de charger les greffons. Au bout d’un instant, on peut voir apparaitre un liste de greffons nommés sous la forme xivo-cisco-sccpXX-9.0.3.

Au moment où j’écris ces lignes, j’ai préparé sept greffons (d’autres sont à venir si besoin):

  • xivo-cisco-sccp05-8.0.3 : Pour Cisco IP Phone 7905
  • xivo-cisco-sccp06-9.0.3 : Pour Cisco IP Phone 7906 et 7911
  • xivo-cisco-sccp12-8.0.4 : Pour Cisco IP Phone 7912
  • xivo-cisco-sccp20-3.0.2 : Pour Cisco IP Phone 7920
  • xivo-cisco-sccp21-1.4.5 : Pour Cisco IP Phone 7921
  • xivo-cisco-sccp31-9.0.3 : Pour Cisco IP Phone 7931
  • xivo-cisco-sccp40-8.1.2 : Pour Cisco IP Phone 7940 et 7960
  • xivo-cisco-sccp41-9.0.3 : Pour Cisco IP Phone 7941 et 7961
  • xivo-cisco-sccp42-9.0.3 : Pour Cisco IP Phone 7942 et 7962
  • xivo-cisco-sccp45-9.0.3 : Pour Cisco IP Phone 7945 et 7965
  • xivo-cisco-sccp70-9.0.3 : Pour Cisco IP Phone 7970 et 7971
  • xivo-cisco-sccp75-9.0.3 : Pour Cisco IP Phone 7975

Il n’est utile d’installer, via l’icône en regard de la ligne du tableau, que les greffons dont vous avez besoin. Quelques secondes après avoir cliqué sur l’icône, un autre tableau devrait apparaître, correspondant au contenu du greffon. Si on essaye d’installer un fichier cela ne fonctionne pas.

4. Installation des firmwares Cisco dans les greffons

En effet, nous allons devoir procéder manuellement. Je ne peux pas vous fournir les fichiers de firmware, mais ils sont téléchargeables depuis le site de Cisco. Il suffit de créer un compte pour accéder aux firmwares. Les fichiers de langues quant à eux nécessitent un contrat de racket service SMARTnet payant.

Mes greffons, ont été élaborés à partir des greffons officiels de XiVO, nécessitent les mêmes versions des firmwares et leur installation se fait de la même façon. En l’occurrence pour les modèles cités plus haut, il faut la version 9.0.3. Pour les fichiers networklocale et les fichiers de langage, il faudra les versions 9.0.2.

Une fois que vous avez obtenu les fichiers dont vous avez besoin, au minimum le firmware, alors mettez le en ligne quelque part, un hébergement en ligne quelconque, c’est le plus simple.

Pour la suite, je vais prendre comme exemple l’installation des fichiers pour le 7945. Il conviendra de remplacer les noms des fichiers par ce que vous avez si vous installez un autre greffon.

On se connecte en SSH au serveur:

ssh -l root IP.DE.VOTRE.XIVO

On entre le mot de passe et on valide. Puis:

cd /var/lib/xivo-provd/plugins/xivo-cisco-sccp45-9.0.3/var/cache

Puis on va télécharger ici les fichiers dont on a besoin depuis l’emplacement en ligne où on les a placé.

On a donc:

  • firmware (obligatoire) : cmterm-7945_7965-sccp.9-0-3.zip
  • langage (optionnel) : po-locale-fr_FR-9.0.2.1000-1.cop.sgn
  • network locale (optionnel) : po-locale-combined_network-9.0.2.1000-1.cop.sgn

On va donc entrer la commande wget suivie de l’URL du fichier:

wget http://mon-hebergement-web.com/fichiers/cmterm-7945_7965-sccp.9-0-3.zip

On répète ensuite l’opération pour les deux autres fichiers, si besoin.

Une fois que c’est fait, on reprend l’interface web de XiVO que l’on a laissé de côté. On retourne dans le greffon que l’on avait installé, dans notre cas celui du 7945, et on peut cliquer sur le bouton d’installation en regard de la ligne qui correspond au firmware, et on répète cette opération si besoin pour les autres fichiers.

5. Configuration du serveur DHCP du routeur

Une fois les fichiers installés, il faut s’assurer que votre serveur DHCP, sans doute votre routeur, indique aux téléphones que vous branchez où ils doivent aller chercher les infos. Je ne peux pas expliquer comment on fait avec tous les modèles de routeurs, il vous faut un modèle un peu plus évolué qu’une box. Avec pfSense, il faut se rendre dans l’interface de configuration. Une fois connecté, on se rend dans Services puis DHCP Server.

On clique ensuite sur le bouton Advanced en regard de Additional BOOTP/DHCP Options. Dans la case Number on entre 150. Dans la liste déroulante on sélectionne IP address or host et enfin on tape l’adresse IP de notre serveur dans la case Value.

On va à tout hasard cliquer sur TFTP, et entrer l’adresse IP de notre serveur.

Ensuite on clique sur Save.

6. Installation des téléphones

Maintenant on peut brancher notre téléphone. Je continue mon exemple avec le Cisco 7945. Il suffit de le relier à la prise Ethernet appelée généralement 10/100 SW. Si le switch n’est pas en mesure de fournir l’alimentation PoE, alors il faut également relier un bloc d’alimentation compatible. Le téléphone va démarrer. Note : Pour que le firmware puisse être provisionné, il faut que votre téléphone soit chargé avec la version 8.3.3 du firmware au minimum.

Pendant ce temps, on retourne dans l’interface de gestion de XiVO et dans la page des terminaisons, accessible dans la colonne de gauche de la page IPBX, on devrait pas tarder à voir apparaitre dans le tableau une nouvelle ligne, il faut parfois un peu de patience.

À gauche, l’adresse MAC indiquée correspond à celle du téléphone. À droite on peut voir quel greffon est utilisé. L’un des boutons à droite de cette ligne permet de modifier la terminaison et ainsi choisir quel greffon on lui applique. Il est important que le bon greffon soit sélectionné sans quoi le téléphone ou le système d’approvisionnement pourrait avoir un comportement erratique.

XiVO choix greffon

Si besoin, on peut remettre le téléphone en configuration d’usine en le déconnectant de son alimentation. Il suffit alors de le reconnecter et immédiatement appuyer sur la touche # et maintenir la touche enfoncée jusqu’à ce que les touches de lignes clignotent alternativement en orange. Lorsque c’est le cas, on peut relâcher la touche # et on dispose alors d’une minute pour entrer la séquence de touches 123456789*0#, et le téléphone redémarre et réclame au serveur son firmware.

Pendant ce temps, il est vital de ne pas déconnecter le téléphone sans quoi le firmware risque d’être corrompu et le téléphone inutilisable.

En attendant que le firmware se charge, dans l’interface, section IPBX, on va dans Utilisateurs, dans la colonne de gauche. On entre toutes les informations nécessaires comme indiqué dans la documentation officielle, puis dans l’onglet ligne, on clique sur l’icône +.

XiVO Utilisateur ligne SCCP

On choisit le protocole SCCP, on entre un numéro de ligne désiré. Dans le champ Terminaison on clique sur l’adresse MAC du téléphone à provisionner, et le pop-up devrait disparaître et le champ se remplir. Il ne reste maintenant plus qu’à sauvegarder.

Au bout de quelques instants, une fois le firmware chargé sur le téléphone et lors que ce dernier indique Enregistrement ou Registering, il devrait alors finir par afficher le num de l’utilisateur en haut à droite, et la première touche de ligne devrait afficher le numéro de ligne demandée.

 

Il ne reste qu’a répéter l’opération pour tous les téléphones concernés et vous aurez un serveur XiVO qui sait enregistrer et provisionner des téléphones Cisco SCCP non supportés.

Conclusion

Ce tutoriel nous est très utile car il permet de faire fonctionner nos téléphones préférés avec XiVO et il a été rédigé pour répondre à notre besoin. Certains greffons ont été réalisés à la demande d’autres utilisateurs de XiVO et toute remontée de bug ou d’information m’intéresse. Une fois toutes les manipulations effectuées il n’y a plus grand chose à faire à part en profiter. Ce tutoriel a été réalisé grâce à l’aide des développeurs de XiVO et à ce titre, je les remercie très chaleureusement.

[MISE A JOUR]

Depuis, XiVO a forké vers Wazo qui est développé par l’équipe originale, et aussi le système de répertoires a changé, ce qui implique que les greffons que l’on trouve ici ne fonctionnent plus depuis plusieurs éditions de XiVO. Si quelqu’un a le courage de les modifier nous pouvons aussi les héberger avec plaisir.

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

[Internet] La neutralité du net expliquée en moins de 5 minutes

0

Alors que je buvais tranquillement un café en attendant un rendez-vous hier, je suis tombé (sans me faire mal) sur une vidéo YouTube sur le blog de Korben, expliquant la neutralité du net. C’est plutôt clair et simple à comprendre alors autant partager si toutefois ces notions n’étaient pas très claires pour vous.

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

[pfSense] Astuce pour les DynHosts OVH, mais mieux !

0

Dans un billet où je parlais de pfSense, je vous expliquais comment mettre à jour les DynHosts OVH depuis pfSense mais c’était crade et ça tombait à chaque mise à jour. C’est sans compter sur l’aide de Chris dans les commentaires du billet.

Hello,

je vous file une configuration que j’ai trouvé pour éviter d’avoir à éditer des fichiers à la main.

Supposons que vous veuillez mettre à jour le domaine ‘mydom.com’

utiliser un dyndns de type « Custom »
– interface WAN
– username: l’identifiant du dynhost OVH
– password: le password du dynhost OVH
– update URL: « http://www.ovh.com/nic/update?system=dyndns&hostname=mydom.com&myip=%IP% »
– result match: « good %IP% »

URL et Result match à rentrer sans les guillemets bien entendu.

J’ai trouvé ces options en faisant un petit tcpdump sur le traffic TCP généré lors d’une mise à jour ddclient qui marchait :

tcpdump -vv -XX -n host http://www.ovh.com

et hop, un ddclient lancé depuis une autre console.

A++
Chris

Testé et approuvé !

Il suffit de se connecter à l’interface de gestion, d’aller dans Services puis Dynamic DNS, et suivre les instructions de Chris.

pfSense DynHost OVH

 

Merci à notre lecteur adoré car ceci va en aider plus d’un !

[Déballage] Réception du ProLiant MicroServer Gen8

2

Tant de choses se sont passées depuis notre dernier billet ! Indignes que nous sommes de vous laisser dans l’attente haletante d’un excellent article sur un sujet de fond… Ou pas.

Résumé de l’épisode précédent

Depuis la dernière fois, des tas de décisions ont été prises, du matériel a été trouvé, des aménagements on été faits…

Nous avons effectivement défini les postes de travail que nous utilisons dans nos locaux. Un poste complet sera donc composé d’un Dell Optiplex 745 au format USFF équipé en bi écran 24″ et 17″, une webcam Logitech C525, un clavier Logitech K200, une souris optique HP ainsi qu’un téléphone Cisco 7940. Nous sommes très attentifs à ce que tous les postes soient harmonisés.

Il a été décidé que les Macs (en très faible nombre) ne seront pas intégrés au réseau outre mesure, excepté la solution on ne peut plus basique fournie par Apple dans Mac OS X.

Les asset tags que nous posons sur le matériel sont actuellement imprimés avec une Dymo LabelManager PNP et seront prochainement remplacés par une autre solution plus efficace, plus propre et moins chère.

Des progrès ont été faits dans la gestion de la téléphonie avec XiVO, les Cisco 7940 et PfSense.

Nous avons créé une page de vente pour le matériel dont nous ne nous servons pas ou plus et de la logistique nécéssaire pour pouvoir le retirer sur CAR94 à Charenton-le-Pont, VLG89 à Villeneuve-la-Guyard, ou C1389 à Chéroy. Nous mettrons régulièrement à jour la page pour plus de facilité. Nos ventes s’effectuent de particulier à particulier. Nous ne sommes pas une entreprise, et l’argent obtenu sert à financer nos futurs achats uniquement. Lorsque vous nous achetez quelque chose, vous nous aidez.

Nos différents sites sont équipés de manière très aléatoire, cela va changer. En effet, CAR94 est équipé HP, C1389 est équipé Dell. Les serveurs n’ont rien à voir entre eux en termes de performances, de capacité, de qualité de fonctionnement, etc.

C’est justement l’objet de ce billet. Toujours dans un soucis d’harmonisation, afin de faciliter la formation, l’installation, l’utilisation et la maintenance, tout semble en bonne voie pour que nous puissions équiper ces deux sites du même modèle de serveur, permettant de baisser significativement la consommation énergétique, le bruit, tout en conservant les avantages d’un serveur local, de la rapidité d’accès, etc.

MicroServer G7

MicroServer G7

C’est dans cette optique que mon choix s’est porté pour le HP ProLiant MicroServer Gen8. Si vous suivez le blog, vous savez sans doute que j’ai eu par le passé un MicroServer G7. Cette machine était intéressante pour tous les avantages cités plus haut, mais elle souffrait de quelques défauts pénibles.

En effet, outre le processeur soudé, cette machine se présentait dans la gamme ProLiant comme un ovni. On n’y trouvait pas les composants habituels de la gamme, pas vraiment la même logique dans le fonctionnement, pas de vraie gestion à distance malgré l’ajout d’une carte spécifique… Ça se rapprochait plus d’un PC « Embedded » appelé « ProLiant » avec quatre emplacements de disques.

Premières impressions

Moi ce que j’aime, c’est le côté serveur, et de ce point de vue là, j’étais moyennement satisfait. Avec la Gen 8 du MicroServer, HP a conçu un excellent produit. Il exploite de la RAM DDR3 ECC Unbuffered. J’ai chargé la mule avec 16 Go. Le processeur (dans mon cas un Celeron G1610T par défaut) est remplaçable, donc plein de possibilité d’évolutions, notamment jusqu’à des Xeon E3 (le socket utilisé est un LGA1155) tant que le TDP est inférieur à 45W. Il n’est pas nécessaire d’extraire la carte mère pour ajouter de la RAM. Toutefois il est toujours possible de le faire mais cela se fait par l’arrière (à condition d’avoir préalablement déconnecté toutes ses prises).

HP iLO logoOn trouve un contrôleur RAID HP Dynamic Smart Array B120i qui se gère dans le traditionnel Array Configuration Utility comme tout ProLiant qui se respecte, une vraie gestion à distance avec iLO 4 en Gigabit Ethernet ou depuis l’appli mobile. A ce sujet, une puce Broadcom nous offre deux Gigabit Ethernet sur la carte mère. Cette dernière donne également accès à 6 ports USB dont certains en USB 3. Il y a également un port USB interne, ainsi qu’un lecteur de carte Micro SD.

La machine est certes relativement compacte mais c’est un concentré de serveur et c’est un vrai régal. On a tout de même un slot PCI Express pour peu qu’on ait une carte Low profile. Je verrai ça quand j’y installerai mon contrôleur RAID HP Smart Array P410 avec cache et batterie de back-up.

Lorsque l’on ouvre la porte frontale, dont l’esthétique n’est pas sans rappeler ses grands frères ML notamment, on a accès à une clé HP pour le serrage des vis et aux quatre emplacements pour les disques durs. La machine est fournie avec des tiroirs de disques vides.

Le lecteur optique (non fourni dans mon cas) est de type slim 9 mm. Personnellement j’en ai pas besoin car j’ai mon disque dur Zalman, vachement plus pratique et plus rapide qu’un CD.

Un truc très sympa, le serveur est équipé de l’Intelligent Provisioning, qui permet d’accéder à tout un tas d’utilitaire de configuration et de diagnostics très utiles qu’il était possible d’avoir avec le CD SmartStart mais aussi d’autres.

J’ai été impressionné lorsque j’ai démarré le serveur après avoir remplacé la RAM car il a automatiquement lancé un test de la mémoire, ce qui est plutôt appréciable.

Niveau bruit, la machine souffle fort au démarrage. Comme tout ProLiant qui se respecte, quand vous l’allumez il ventile assez fort puis diminue son régime pour redevenir silencieux. N’ayant pas encore pu installer mes disques à l’intérieur, je ne peux pas vraiment juger du silence mais disons que ça semble être assez proche de l’ancienne génération.

Quelques défauts

A première vue, n’ayant pas encore vraiment testé la machine, j’ai noté quelques défauts. Tout d’abord le contrôleur RAID. De ce que j’ai pu trouver sur le net, il n’est pas possible de lui adjoindre de la mémoire cache et une batterie de back-up. C’est dommage car cela ne permet par d’activer le support du RAID5 si toutefois il en était capable. Je vais utiliser un autre contrôleur HP mais c’est tout de même dommage de ne pas permettre cela sur le contrôleur intégré.

Les tiroirs de disques sont marqués comme non hot-plug ce qui est dommage. On regrettera aussi que ce ne soit pas les mêmes tiroirs que dans les autres serveurs, ceux avec les LEDs indiquant l’état du disque car c’est classe et sympa. Même s’il serait peut-être possible d’en insérer un, le fond de panier n’a pas les connecteurs des LEDs donc elles seraient de toutes façons inopérantes.

Autre chose, la bande lumineuse bleue en bas de la façade indique l’état du serveur (c’est bleu, orange ou rouge, à ce que j’ai lu) mais il aurait été super qu’on puisse s’en servir de LED UID. Une LED UID virtuelle est cependant présente dans l’interface web d’iLO mais j’aurais bien aimé que la LED physique sur le boîtier clignote quand on prend la main via la gestion a distance.

La porte de la façade est plutôt sympa mais contrairement à la génération précédente, elle ne dispose pas de serrure. Elle est aimantée pour rester bien fermée mais un système à clefs aurait été bienvenu. Il est toutefois possible d’en verrouiller l’ouverture via un loquet mais celui-ci se trouve à l’intérieur du serveur, impliquant de démonter la coque. Pas super pratique.

Conclusion

Il me semble que cette machine soit une réussite malgré ses quelques défauts. Je l’ai obtenu pour 240 euros sur Amazon mais il est fréquent de la trouver à des tarifs bien plus élevés. Dans tous les cas, indépendamment du fait qu’elle est plus récente, les améliorations apportées par HP par rapport à la génération précédente me laissent penser que le prix n’est pas disproportionné.

J’ai personnellement beaucoup d’affection pour les petits serveurs de ce type par rapport aux NAS. Le prix d’un NAS Synology ou QNAP est assez élevé et il n’est pas dit que ce serveur revienne moins cher, mais il faut reconnaître que son évolutivité et sa capacité à lancer de nombreux systèmes d’exploitation en font un adversaire redoutable (à condition de savoir configurer soi-même un OS serveur).

Il sera très certainement encore possible de mettre à jour le système même si HP n’apporte plus vraiment de support comme c’est possible sur les autres serveurs (la preuve, nous utilisons des serveurs de cinquième génération avec le dernier Windows Server sans problèmes). Et là où les NAS disposent de RAM et de processeurs soudés, il sera ici possible d’apporter des modifications à la configuration.

J’ai hâte de recevoir le reste du matériel pour pouvoir mettre en place quelques bricoles…

Thomas's RSS Feed
Go to Top