🎦 Présentation de ShinobiCCTV Community Edition 👁️

ShinobiCCTV Community Edition est un serveur de vidéo‐surveillance multi‐plate‐forme, dont les finitions se situent quelque part entre ZoneMinder et Kerberos.io. Voyons ensemble ses particularités, ses avantages et inconvénients. lien n°1 : Site officiel ShinobiCCTV lien n°2 : Discord ShinobiCCTV Room Sommaire Version communautaire de Shinobi (Community Edition) 📰 Introduction 🛠️ Fonctionnalités et capacités ⚖️ Quelques différences avec les autres 🔎 Composition de Shinobi 📡 Au niveau logiciel 📡 Au niveau des dépendances 📱 Au niveau de la WEBUI (interface Web) Mise en place 🌱 Installation (de base) 🗑️ Désinstallation Bonus 🍔 Anecdotes 📊 Sondages 🗨️ Avis personnels ☄️ Avis de Voxdemonix (2018) ♾️ Remerciements 🎞️ Captures d’écran 🔗 Liens Version communautaire de Shinobi (Community Edition) 📰 Introduction ShinobiCCTV, Shinobi pour les intimes, serveur de vidéo‐surveillance à ses heures, naquit dans une région froide du Canada sous les martèlements de clavier de Moe Alam. Ce projet serait l’alternative de référence à ZoneMinder (source). Ce qu’il pourrait devenir, en effet, compte tenu du peu de choix dans cet écosystème libre. « Shishi » est basé sur FFmpeg et Node.js, utilisant massivement du JavaScript, un peu de Python, ainsi qu’un chouia de Shell (source). Le serveur est multi‐plate‐forme (BSD, GNU/Linux, macOS, Windows) et compatible avec l’architecture ARM. Une image Docker est aussi disponible. En termes de fonctionnalités, ShinobiCCTV se situe quelque part entre ZoneMinder (utilisable en milieu pro mais vieillissant) et Kerberos.io. Il n’y a pas de limite en nombre de caméras (autre que la puissance de calcul de vos machines et la bande passante de votre réseau). Shinobi se divise en deux branches distinctes : Shinobi Community Edition → licence libre (gratuit) ; Shinobi Pro → Open Source non libre (payant, sauf exceptions). Nous allons ici, bien entendu, nous intéresser uniquement à la version libre. D’après cet article, la version libre de Shinobi ne reçoit pas de mises à jour régulières (historique) et n’accepte aucun demande d’intégration (pull request). S’il existe donc bien une version libre de Shinobi, elle n’est, à l’heure de la rédaction de cet article, hélas point communautaire. Il faut néanmoins souligner que Moe, pour le moment l’unique développeur, est très réactif, à l’écoute et surtout qu’il utilise le logiciel qu’il code (cf. les tarifs du support). 🛠️ Fonctionnalités et capacités capacité de récupérer des flux audio‐vidéo des caméras via HTTP, RTP/RTSP et ONVIF ; HTTPS est pris en charge, mais uniquement avec des certificats X.509 valides ; enregistrement aux formats vidéo compatible avec l’accélération matérielle, avec trois modes d’enregistrement différents (enregistrement continu, enregistrement lors d’événements avec ou sans tampon, enregistrement puis suppression si pas d’événement détecté) ; enregistrement possible de l’audio ; détection de mouvements et analyse de formes ; diversité de formats d’enregistrement (liste) ; diversité dans les méthodes de diffusion ; en revanche, le délai entre la réalité et ce que l’on voit sur l’écran peut être important (jusqu’à 8 s avec HLS) suivant la méthode de diffusion choisie ; gestion des stockages distants (Amazon S3, WebDAV, Backblaze B2) ; possibilité de définir le stockage pour chaque caméra ; gestion d’une petite partie des commandes pour caméras (PTZ, IR) ; possibilité de permuter entre le mode de diffusion « normal » et le mode JPEG, moins gourmand en bande passante et avec une plus faible latence (très utile pour déplacer les PTZ ou couper les flux audio) ; utilisation de robots pour les alertes (courriel, discord) ; compatibilité LDAP ; ligne du temps, accéléré (time‐lapse) ; lancement de scripts (par défaut en super‐utilisateur) lors d’événements ; calendrier par caméra où sont indiqué les évènements ; ce calendrier n’est pas encore synchronisable ; le mode grappe de serveurs (cluster) de Shinobi est basé sur le système maître‐esclave, permettant de répartir la charge, mais pas d’avoir de la haute disponibilité ; seul le serveur maître s’occupe de la communication avec la base de données, si ce serveur plante, tout plante ; sur la WEBUI vous pouvez adapter votre tableau de bord grâce au glisser‐déposer (drag & drop) sur les différents moniteurs de caméra. ⚖️ Quelques différences avec les autres ZM et Shinobi permettent tous deux de visualiser plusieurs moniteurs simultanément (pas Kerberos.io) ; en revanche, avec Shinobi vous ne pouvez choisir la taille de l’affichage ; la ligne du temps de Shinobi se base sur des points fixes sans image de prévisualisation ; pour voir ce qu’il s’est déroulé entre deux points, il faut visualiser la vidéo liée ; sur ZM, il suffit de survoler la ligne du temps pour charger une image de l’instant T ; vous ne pourrez donc pas visualiser une journée entière en quelques secondes comme avec ZM ; impossible aussi de trouver un évènement si vous ne savez pas le dater ; Sur Shinobi il faudra paramétrer les commandes PTZ de chaque caméra, sauf pour celles compatibles ONVIF ; vous pouvez éventuellement recopier la configuration d’une caméra, mais, pour le moment, pas choisir dans une liste de pré‐configuration, comme avec ZM ; Shinobi n’est pas capable de contrôler autant de commandes pour les PTZ, infrarouge, etc., que ZoneMinder ; la session utilisateur n’est pas liée au navigateur mais à l’onglet, sauf bogue ; la consommation d’espace d’échange mémoire (swap) est assez imposante, et l’on ne peut définir son chemin d’accès ; Shinobi utilise massivement le super‐utilisateur root (pm2, ffmpeg, etc.) ; ZoneMinder et Kerberos.io utilisent tous deux un serveur Web, Shinobi intègre le sien ; vous devrez donc allouer un port différent (par défaut 8080) et ne pourrez journaliser les infos ni les exploiter avec Piwik/Matamo, sauf à passer par un serveur mandataire (exemple avec HaProxy) ; Node.js oblige, ShinobiCCTV nécessite de l’expérience en Node.js/expressjs afin de pouvoir ajouter des pages Web sur le serveur (par exemple un fichier healthcheck) ; Avec ZoneMinder le mode grappe de serveurs (cluster) nécessite de répartir manuellement les caméras sur plusieurs nœuds et, si vous pouvez visionner les enregistrements depuis n’importe quel nœud, le direct quant à lui est limité aux caméras gérées par le serveur ; Shinobi semble lui répartir la charge entre ses nœuds fils automatiquement, en se basant sur l’utilisation du processeur ; le visionnage du direct ou des enregistrements se fait donc uniquement sur le serveur maître (source) ; le système de ZoneMinder permet de créer une grappe de serveurs répartie sur plusieurs réseaux, Shinobi semble capable d’accomplir aussi cette tâche ; le détecteur de mouvement est plus difficile à configurer sur Shinobi (sur ZoneMinder, il se résume à l’activer et optionnellement adapter le niveau de « bruit ») ; Kerberos utilise un mécanisme de mise à jour via la WEBUI [source], ZoneMinder est directement intégré au système ; Shinobi, quant à lui, passe par Git [source]. 🔎 Composition de Shinobi 📡 Au niveau logiciel Node.js, moteur JavaScript basé sur Chromium — nom des processus : node (tourne en super‐utilisateur) ; pm2, gestionnaire de processus pour Node.js — nom des processus : PM2 v3.2.2: God Daemon (tourne en super‐utilisateur) ; ffmpeg, acquisition et traitement des flux vidéo et audio — nom des processus : ffmpeg (tourne en super‐utilisateur) 📡 Au niveau des dépendances Ces logiciels peuvent être installés sur la même machine ou répartis sur plusieurs : MariaDB, le serveur de base de données, nom des processus : mysqld (tourne sous l’utilisateur « mysql ») ; si accessible via WAN, un frontal au choix (HAProxy, Apache 2, etc.) ; si sur plusieurs machines, un logiciel pour chiffrer les communications entre le ou les frontaux et le serveur maître ShinobiCCTV, voire entre ShinobiCCTV et le(s) serveur(s) de base de données. 📱 Au niveau de la WEBUI (interface Web) http://your_shinobi:8080 ⇒ Tableau de bord : http://your_shinobi:8080/admin ⇒ Ici les utilisateurs créés par l’administrateur pourront créer eux‐mêmes des « sous‐utilisateurs » (équivalent des modérateurs), permettant de partager l’accès à des caméras : http://your_shinobi:8080/super ⇒ Gestion de l’administrateur, des comptes utilisateurs et de quelques paramètres de base : Mise en place 🌱 Installation (de base) Est expliqué comment faire une installation minimale de Shinobi Community Edition. Pour une installation complète, avec notamment HTTPS, voyez le tutoriel « Ubuntu/Debian Installation complète de Shinobi Community Edition ». Lancez l’installation du logiciel : mv /tmp/ wget https://gitlab.com/Shinobi-Systems/Shinobi-Installer/raw/master/shinobi-install.sh sudo bash shinobi-install.sh Créez la base de données et son utilisateur avec multiple accès. Adaptez, bien entendu, le mot de passe ainsi que « 10.8.%.% » qui, dans cet exemple, autorise l’accès à n’importe quel client ayant une adresse IP comprise entre 10.8.0.0 et 10.8.255.255. Attention, localhost est différent de 127.0.0.1 et autoriser l’un n’autorise pas automatiquement l’autre : GRANT ALL PRIVILEGES ON ccio . * TO 'shinobi' @ 'localhost' IDENTIFIED BY 'my_super_password' ; GRANT ALL PRIVILEGES ON ccio . * TO 'shinobi' @ '10.8.%.%' IDENTIFIED BY 'my_super_password' ; FLUSH PRIVILEGES ; Éditez /home/Shinobi/conf.json afin d’y ajouter les informations concernant la base de données : nano /home/Shinobi/conf.json Initialisez la base de données : mysql -u shinobi -p shinobi < /home/Shinobi/sql/framework.sql mysql -u shinobi -p shinobi < /home/Shinobi/sql/tables.sql mysql -u shinobi -p shinobi < /home/Shinobi/sql/database.sql Redémarrez le cœur de Shinobi : pm2 --update-env restart all 🗑️ Désinstallation Suppression de la base de données et de son utilisateur : mysql -uroot -p -e "DROP DATABASE ccio;" mysql -uroot -p -e "DROP USER ‘shinobi’@’localhost’;" mysql -uroot -p -e "DROP USER ‘shinobi’@’10.8.%.%’;" Suppression et purge des logiciels : pm2 kill sudo npm uninstall pm2 -g sudo apt remove ffmpeg mariadb-server nodejs -y && sudo apt autoremove -y && sudo apt-get autoclean sudo rm -rf /usr/local/bin/npm /usr/local/share/man/man1/node* /usr/local/lib/dtrace/node.d ~/.npm ~/.node-gyp /opt/local/bin/node /opt/local/include/node /opt/local/lib/node_modules /usr/local/lib/node* /usr/local/include/node* /usr/local/bin/node* /home/Shinobi Bonus 🍔 Anecdotes 📊 Sondages Un petit sondage, non représentatif, indique qu’Ubuntu semble être le serveur le plus utilisé. Un autre sondage, pas plus représentatif, semble indiquer que la version la plus utilisée est Shinobi Pro. 🗨️ Avis personnels Les avis du ou des auteurs sont subjectifs et ne doivent pas être pris comme règles. ☄️ Avis de Voxdemonix (2018) Les technologies utilisées autant pour le cœur (Node.js), la l’interface Web (HTML 5), le support (Discord, la messagerie instantanée avec Moe intégrée dans la documentation) que les fonctionnalités (Discord bot, WebDAV, reconnaissance d’objets) sont rafraîchissantes. Aucun autre projet que j’ai testé ne discute de l’utilisation de réseaux neuronaux. En revanche, voir tourner Node.js et FFmpeg en super‐utilisateur amène une certaine appréhension sur la sécurité. Pour info, FFmpeg est suffisamment soumis à risque pour que le projet Nextcloud déconseille complètement son utilisation (afin d’éviter qu’un fichier corrompu ne passe dans le générateur de prévisualisation). FFmpeg qui récupère un flux réseau non sécurisé en super‐utilisateur, c’est assez dangereux. À tester si la version Docker corrige ce problème important. Il manque quelques fonctionnalités (pré‐sélections de caméras, voire balayage à la ZoneMinder, ainsi que des boutons importants, notamment au niveau des PTZ (ex : IR auto on/off), il n’y a pas de date sur les flux) et certaines fonctionnalités ne sont pas terribles (ligne du temps qui nécessite de pouvoir dater un évènement pour le retrouver). Le fait que ShinobiCCTV n’applique les mises à jour et les demandes d’intégration que sur le projet proprio fait aussi peur, peut‐être à tort, que le développeur ne ferme le projet dès qu’il aura des clients (époque #OpenWashing oblige). Sans compter que cela casse un peu l’envie de participer, surtout au niveau code et rapport de bogue. Quand aucun utilisateur n’est sur la WEBUI, la charge système machine reste sous 0,5. En revanche, dès qu’un utilisateur se connecte sur la WEBUI et affiche des flux, la charge monte rapidement entre 1,5 et 2,5. Plusieurs utilisateurs m’ont indiqué utiliser ou tester ShinobiCCTV sur Raspberry Pi 3 sans réel problème, il n’y a eu aucun retour quant aux ARM non 32/64 bits en revanche. Bref, il y a encore du boulot pour que ShinobiCCTV devienne utilisable en milieu professionnel, mais les fonctionnalités vitales sont déjà disponibles pour une utilisation familiale ou PME (si l’on rajoute une surcouche de sécurité). ♾️ Remerciements Gros remerciement à la communauté et à Moe pour leur participation ! 💋 🎞️ Captures d’écran 🔗 Liens Linux Surveillance Camera Software Evaluation 2018 ; Nextcloud : les créateurs d’ownCloud rebootent leur projet ; Genetec Security Center. Télécharger ce contenu au format Epub Commentaires : voir le flux atom ouvrir dans le navigateur

group_work LinuxFRNews 2 January, 2019