Posts tagged tutoriel

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

Tutoriel : Geek Sushi seul chez soi

0

Si vous êtes seul chez vous, comme moi ce soir, vous pouvez réaliser simplement ce tutoriel chez vous pour passer le temps. Dans mon exemple, j’ai utilisé :

  • mon NAS Synology et mon téléviseur afin de diffuser la série Mon Oncle Charlie
  • un Palm V
  • le boitier contenant les supports d’installation de mon serveur
  • deux spares disques durs 146 Go SAS 10K
  • la télécommande des lampes LivingColors afin de choisir une ambiance agréable
  • un VMU

Vous aurez aussi besoin de votre ordinateur ou votre téléphone pour commander des sushis et autres plats japonais. J’ai commandé des brochettes, des sushis au saumon, et du riz cantonais au poulet.

Avant que votre commande soit livrée, disposez vos appareils technologiques près de vous, notamment sur la table ou le support que vous utiliserez pour manger, puis placez les plats dès leur réception.

Table pour votre soirée Geek Sushi

Table pour votre soirée Geek Sushi

Vous êtes maintenant prêt pour votre soirée Geek Sushi !

Comment assouvir ses besoins de Big Brother chez soi

0

Bonjour bonjour !

Non, nous n’avons aucune hécatombe à déplorer, bien que nous ne sommes actuellement pas très actifs ces temps-ci. Pourtant j’ai aujourd’hui retrouvé un tuto d’il y a deux ans et que je pensais perdu (en fait il était bien présent en /files/racine/bordel8/sauv/bordel/bordelcopie/poil/merdier_bizarre/ de mon dossier personnel sur le NAS, c’est dire si c’était rangé !).

L’idée à l’époque était, avec un PC sous Ubuntu et une simple webcam USB d’avoir chez soi un petit serveur sur lequel on peut mettre un site, des fichiers, ce que l’on veut, mais aussi et surtout, une page web qui affiche l’image de la webcam sans avoir besoin de grand chose. Mon but était d’avoir une interface graphique sur la machine pour éventuellement être utilisée pour surfer de temps à autres.

J’utilisais Ubuntu Server 10.10

Vous avez besoin pour cela de :

  1. un quelconque PC capable de faire fonctionner Ubuntu 10.10
  2. Ubuntu Server 10.10
  3. une webcam (je ne sais pas quel type particulier mais on avait utilisé une version Logitech de l’EyeToy
  4. une connexion Internet pas trop dégueulasse (ce tuto était prévu pour une connexion avec IP dynamique mais les chanceux qui ont une IP fixe verront de quelle partie ils peuvent se passer)
  5. un domaine OVH avec un DynHost
  6. un modem-routeur-box qui permet la redirection de ports
  7. un peu de patience et des gencives de porc

Commençons par le truc le plus simple, installer Ubuntu Server 10.10 et choisissez à l’installation les options LAMP, OpenSSH et Samba. Et laissez-vous guider, il n’y a rien de particulier à faire. Vous pouvez en attendant rediriger le port 80 de votre routeur vers votre serveur (voire faire une DMZ mais c’est pas super pour la sécurité). Vous pouvez vous connecter en SSH depuis votre machine ou entrer les commandes physiquement sur le serveur indifféremment.

Une fois tout installé, connectez-vous avec votre couple login/password et faites une mise à jour :

admin@server:~$ sudo apt-get upgrade

Une fois que c’est terminé :

admin@server:~$ sudo apt-get install xorg gnome-core gdm gnome-applets gnome-system-tools gnome-utils compiz-gnome firefox sysv-rc-conf gedit webcam network-manager software-center libapache2-mod-auth-mysql phpmyadmin ddclient

Puis on va modifier les autorisations du dossier racine de site Web par :

admin@server:~$ sudo chmod -R 777 /var/www

Maintenant, pour rendre l’accès plus commode depuis votre réseau local, vous pouvez éditer le fichier de configuration de Samba comme suit :

admin@server:~$ sudo nano /etc/samba/smb.conf

Ajoutez dans la section [Share definitions] le bloc suivant :

[www]

   comment = Partage Web

   read only = no

   available = yes

   public = yes

   writable = yes

   path = /var/www

   guest ok = no

   browsable = yes

Enregistrez et quittez, puis on s’occupe du domaine OVH. Vous avez créé un identifiant DynHost qui autorise la mise à jour de l’adresse IP comme le fait No-IP ou DynDNS, ainsi qu’un champ DynHost correspondant. Ensuite il faut créer le fichier de configuration de DDclient. Il suffit de copier ce qui suit en remplaçant les XXXX par les bonnes informations :

admin@server:~$ sudo nano /etc/ddclient.conf

Si quelque chose est présent, il suffit de tout remplacer par cela :

# Configuration file for ddclient

#

# /etc/ddclient.conf

daemon=600 # check every 600 seconds

syslog=yes # log update msgs to syslog

mail=root # mail all msgs to root

mail-failure=root # mail failed update msgs to root

pid=/var/run/ddclient.pid # record PID in file.

cache=/tmp/ddclient.cache # Cache file

## Check IP via DynDNS CheckIP server

use=web, web=checkip.dyndns.com/, web-skip='IP Address'

## Enter your Ovh DynHost username and password here

login=XXXXXX # your Ovh DynHost username

password=XXXXXX # your Ovh DynHost password

protocol=dyndns2 # default protocol

server=www.ovh.com # default server

## Dynamic DNS hosts go here

XXXXXXXXX

Enregistrez et quittez. Puis modifiez, sinon créez le fichier de configuration de la webcam :

admin@server:~$ sudo nano /home/ladmin/.webcamrc

Remplissez avec ceci (vous pouvez laisser tel quel, ou bien modifier les noms des fichiers) :

[ftp]

host = localhost

user = nobody

pass = xxxxxx

dir = /var/www/webcam

file = webcam.jpg

tmp = imageup.jpg

local = 1

[grab]

device = /dev/video0

width = 640

height = 480

delay = 1

quality = 100

Enregistrez et quittez. On s’approche violemment du but. Il ne reste plus qu’à éditer le fichier rc.local pour lancer le programme de capture automatiquement :

sudo nano /etc/rc.local

Faites le ressembler à ceci :

#!/bin/sh -e

#

# rc.local

#

# This script is executed at the end of each multiuser runlevel.

# Make sure that the script will "exit 0" on success or any other

# value on error.

#

# In order to enable or disable this script just change the execution

# bits.

#

# By default this script does nothing.

webcam /home/ladmin/.webcamrc&

exit 0

Redémarrez !

Il ne vous reste plus qu’à placer un fichier index.html (Exemple de fichier index).

C’est vraiment terminé ! Gardez cependant bien à l’esprit que tout ce que filme votre webcam est diffusé sur la page Web.

Go to Top