Vous pouvez mettre à jour votre installation en lançant le « Web Platform Installer » sur Windows :

Constellation Web Platform Installer » Article
Constellation-Web-Platform-Installer-1.9.735.exe
Version: 1.9.735

1.2 MiB
2137 Downloads
Détails

Constellation Web Platform Installer pour Windows

Auteur:	MyConstellation.io
Plateformes:	Windows
Catégorie:	Web Platform Installers
Licence:	Constellation License Agreement
Date:	juin 15, 2020

Ou, sur Linux, en lançant la commande :

wget -O install.sh https://developer.myconstellation.io/download/installers/install-linux.sh && chmod +x install.sh && ./install.sh

Constellation Server 1.8.3

Tout d’abord les dépendances du serveur Constellation ont été mises à jour : Json.NET 9.0.1, NLog 4.4.11, SignalR 2.2.2 et enfin la stack OWIN en version 3.1. Chacune d’entre elles apportant des correctifs et améliorations de performance.

La modification la plus importante de cette version 1.8.3 est la refonte complète de la gestion des packages au niveau du serveur. En effet, jusqu’à présent seuls les packages réels (et non virtuels) étaient gérés par le hub de contrôle. Pour les packages virtuels, il fallait exploiter l’API de Management (ou lire la configuration XML) car ils n’existaient pas sur le hub de contrôle (d’où le terme “virtuel”).

Désormais, chaque package déclaré dans la configuration d’une Constellation, qu’il soit réel ou virtuel, est chargé sur le hub de contrôle. Il n’y a donc plus de Statut en “N/A” sur la Console Constellation : tous les packages ont par défaut un état à “Unknown”. Une simple connexion sur le hub de contrôle permet donc de récupérer l’intégralité des packages d’une Constellation sans devoir combiner des informations venant de la configuration XML pour y ajouter la partie « virtuelle ».

De plus les packages virtuels initialisant des abonnements aux messages ou StateObjects sont maintenant marqués comme “connecté” sur le hub de contrôle permettant de suivre leurs états. Par exemple, un Arduino/ESP est maintenant vu comme connecté sur le hub de contrôle :

Aussi chaque package envoie désormais, en plus de son n° de version et de la libraire Constellation utilisée, le type de la libraire utilisée : il s’agit de la propriété “ConstellationClientType”.

Aussi, il est possible définir le répertoire de base de la Constellation dans lequel trouver le fichier de configuration en spécifiant la clé « Constellation.BaseDirectory ». Cela permet de séparer les binaires Constellation de sa configuration, très utile dans un environnement Docker. Un article sur le sujet sera prochainement publié.

Outre différentes optimisations du code et correction de défauts mineurs on peut aussi noter :

• Server / ControlHub : le ReloadServerConfiguration envoi la liste des packages aux sentinelles seulement connectées et « Update settings » sur les packages connectés seulement et non à tous les groupes
• Server / ControlHub : prise en charge des mises à jour de configuration des packages à volée
• Server / Management API : ajout d’un objet de synchronisation pour les I/O vers le fichier de configuration pour éviter les écritures concurrentes
• Server / Licensing : LeaseLicensing dans le domaine serveur si multi-tenant sinon dans le domaine de la constellation si mono-instance (permettant ainsi de récupérer les erreurs de licence dans la Console Log)
• Server / API REST : le timeout des sessions HTTP est maintenant de 150 secondes par défaut configurable dans le fichier de configuration

Enfin notez que le serveur 1.8.3 est rétrocompatible avec les différents composants Constellation 1.8.x, que ce soit pour la Console, les packages ou les sentinelles. Autrement dit vous pouvez mettre à jour votre serveur en 1.8.3 tout en gardant vos packages et sentinelles 1.8.x fonctionnelles.

Constellation Sentinel 1.8.3

L’autre grande nouveauté de cette nouvelle version 1.8.3 est la refonte complète du gestionnaire de processus sur les sentinelles.

Jusqu’à présent lorsqu’une sentinelle recevait sa liste des packages, elle se chargeait de télécharger et démarrer chaque package de sa liste. Si le package était déjà en fonctionnement elle levait un Warning ce qui avait tendance à “polluer” les logs notamment lorsqu’on déployé la configuration au niveau d’une Constellation. Enfin lorsqu’un package en fonctionnement était supprimé de la liste, elle fermait le processus associé.

Le problème dans ce mécanisme est que si vous arrêtez un package et que vous redéployer la configuration, par exemple en ajoutant, supprimant ou modifiant les settings d’un autre package, la liste était renvoyée à votre sentinelle qui relançait “bêtement” le package vous avez arrêté !

C’est pour cela que le fonctionnement interne de la sentinelle a été profondément revu et a conduit à la réécriture complète du mécanisme de gestion des processus. Ainsi la description de chaque package, démarré ou non, est maintenue en mémoire. Lorsqu’une sentinelle reçoit sa nouvelle liste, elle est toujours capable de charger/démarrer les nouveaux packages et supprimer/arrêter les packages retirés mais les packages existants ne sont pas redémarrés automatiquement, ils conservent leurs états.

Cette refonte a amélioré beaucoup de chose en apportant plus de fiabilité et stabilité dans le suivi du processus et elle apporte une meilleure cohérence des états de chaque package.

Aussi, comme le serveur, les dépendances ont été mises à jour : Json.NET 9.0.1, SignalR 2.2.2, NLog 4.4.11 et NLog.Windows.Form 4.2.3 pour la Sentinelle UI.

Notez enfin qu’une sentinelle 1.8.3 peut fonctionner sans aucun problème dans une Constellation 1.8.x de version antérieure tout comme une sentinelle antérieure à la version 1.8.3 pour fonctionner sur une Constellation 1.8.3.

Constellation Console 1.8.3

La Console Constellation a aussi reçu sont lot de nouveautés à l’occasion de cette nouvelle release 1.8.3.

Etant donné la refonte dans la gestion des packages sur le hub de contrôle, la Console Constellation a été impacté à ce niveau. Elle se base exclusivement sur le hub de contrôle sans devoir interroger la Management API en parallèle pour intégrer les packages virtuels ou non connectés.

Suite à la publication des nouvelles librairies Javascript et AngularJS 1.8.2 du mois dernier, les codes snippets du MessageCallbacks Explorer ont été mis à jour pour intégrer les nouveautés de ces librairies.

On notera aussi l’ajout d’un bouton pour vider la Console Log, l’ajout ConstellationClientType sur les packages ou encore du credential utilisé par une sentinelle sur la fenêtre de détail. Aussi la Console supporte pleinement les utilisateurs connectés sans droits de Management.

Mais aussi :

• Console / Package : Gestion des packages virtuels avec un statut Unknown, menu contextuel synchronisé et mise à jour de l’activité pour les packages virtuels
• Console / Packages : « Update Settings » affiché dans le menu contextuel si le package est connecté et démarré (package virtuel compris)
• Console / Packages : bugfix sur le déploiement de package avec un setting de type DateTime (module $filter non injecté dans le contrôleur principal)
• Console / Packages : bugfix sur le déploiement de la configuration une fois que le SetRecoveryOption est terminé et non en parallèle
• Console : déconnexion des deux hubs (consumer et controller) si l’un des deux est déconnecté (cas très rare où l’un des deux hubs parvient à se reconnecter et pas l’autre)
• Console : Mise à jour de l’API Constellation Javascript & AngularJS en version 1.8.2 et de la librairie SignalR 2.2.2

Autres nouveautés

La librairie .NET pour les packages a été mise à jour en version 1.8.3.17190, et est disponible sur le repository Nuget. Cette nouvelle version envoie le “ConstellationClientType” ( net40 » ou « net45 ») lors de la connexion de votre package à Constellation. De plus les dépendances ont été mises à jour vers JSON.NET 9.0.1 et SignalR 2.2.2.

Notez enfin qu’un package exploitant l’API 1.8.3 peut fonctionner sans aucun problème sur une Constellation 1.8.x de version antérieure tout comme un package antérieure à la version 1.8.3 peut fonctionner sur une Constellation 1.8.3.

Une nouvelle version SDK est également disponible. Il intègre une mise à jour des templates de projet Constellation pour prendre en compte les dernières versions des API 1.8.3.

Pour finir le Web Platform Installer pour Linux a lui aussi été mis à jour. Il garde en mémoire le jeton d’authentification entre les différents installeurs Server, Sentinel et Console de façon à éviter de devoir se ré authentifier à chaque composant mais surtout le pilotage des services Server et Sentinel dans Supervisor est désormais basé sur “supervisorctl” pour une gestion plus fine des services.

Pour consulter le changelog complet de cette nouvelle version cliquez ici. N’hésitez pas non plus à remonter vos feedbacks sur le forum.

The post Constellation 1.8.3 est disponible appeared first on Constellation.

The post WakeOnLan : réveillez vos équipements réseau depuis Constellation appeared first on Constellation.

Vous pouvez mettre à jour votre installation en lançant le « Web Platform Installer » :

Constellation Web Platform Installer » Article
Constellation-Web-Platform-Installer-1.9.735.exe
Version: 1.9.735

1.2 MiB
2137 Downloads
Détails

Constellation Web Platform Installer pour Windows

Auteur:	MyConstellation.io
Plateformes:	Windows
Catégorie:	Web Platform Installers
Licence:	Constellation License Agreement
Date:	juin 15, 2020

Ou sur Linux en lançant la commande suivante :

wget -O install.sh https://developer.myconstellation.io/download/installers/install-linux.sh && chmod +x install.sh && ./install.sh

Constellation SDK 1.8.2 : support de Visual Studio 2017

La nouvelle version du SDK Constellation est désormais compatible avec toutes les éditions de Visual Studio 2012, 2013, 2015 et maintenant 2017.

Cette version embarque également une mise à jour du générateur de code pour supporter des booléens optionnels dans la signature des MC ou encore l’ajout de méthode d’extension pour les StateObjects de type générique.

Aussi, les fenêtres s’ouvrent maintenant au centre de l’instance Visual Studio et non sur l’écran principal ce qui était peu conviviale sur les environnements multi-écrans. Les templates de projet ont également été mis à jour.

Enfin avec l’arrivée de Visual Studio 2017, le programme d’installation du SDK a été révisé pour supporter cette nouvelle version ainsi que le concept de “multi-instance” de Visual Studio 2017. Vous aurez maintenant le programme “VSIX Installer” qui sera lancé automatiquement lors de l’installation pour sélectionner les instances de VS où installer le SDK Constellation.

Constellation Console 1.8.2 : plus de productivité

Cette mise à jour apporte beaucoup d’améliorations de la Console Constellation.

Déploiement des mises à jour des packages

Depuis Constellation 1.8.1, lorsqu’une mise à jour est disponible dans le catalogue en ligne, vous avez une notification avec la possibilité de télécharger la nouvelle version du package :

La nouvelle version du package est déployée dans votre repository local et c’est à vous, ensuite, de déployer manuellement cette nouvelle version sur les instances en cours de fonctionnement via le bouton “Reload”.

Désormais avec la version de 1.8.2 de la Console, une fenêtre s’ouvre automatiquement à la suite du déploiement d’une mise à jour d’un package pour vous proposer de recharger directement le ou les packages sur les sentinelles de votre Constellation où ils sont déployés :

Détachement des fenêtres

Sur toutes les pages de la Console 1.8.2, vous avez deux nouvelles icones en haut à droite :

La première icone permet de détacher la page en cours dans une pop-up et la deuxième icone permet de détacher la page en cours dans un nouvel onglet de votre navigateur.

Cela permet d’ouvrir plusieurs pages de la Console sur un même écran, pour suivre par exemple les logs, contrôler les packages, visualiser les StateObjects, etc. sans devoir changer constamment de page :

Contrôle de la compatibilité du déploiement des packages sur les sentinelles

Sur la fenêtre de déploiement d’un package, un contrôle de compatibilité est réalisé pour vous indiquer si le package est compatible avec la sentinelle sélectionnée.

Par exemple un package comme HWMonitor ou WindowsControl n’est pas compatible avec une sentinelle Linux, vous aurez donc directement l’information lors du déploiement d’un nouveau package.

Ce contrôle est basé sur les informations définies dans le manifeste du package. A charge au package de spécifier les informations de compatibilité dans leur manifeste.

Les filtres persistants

Les filtres de chaque page sont maintenant conservés lorsque l’on change puis revient sur une page (au sein d’une même session). Cela apporte plus de productivité en nous évitant de devoir constamment réappliquer les filtres lorsque l’on passe d’une page à l’autre.

Plus de réactivité

Outre les nouvelles fonctionnalités, la Console 1.8.2 apporte aussi plus de réactivité. Anciennement il y a certaines opérations comme la suppression de sentinelles ou de packages, la création d’un package virtuel, qui nécessitaient de recharger la Console (via un F5 par exemple). Désormais, les vues se mettent bien à jour en temps réel quelque soit les actions réalisées.

Il est également possible de déployer plusieurs instances d’un même package sur une même sentinelle.

Autre

En vrac :

• Extinction automatique des packages lors de la suppression d’une sentinelle
• Affichage du nombre d’élément filtré et total sur chaque page
• Limite de 500 lignes dans la Console Log et de 20 erreurs max dans la sidebar de notification pour éviter les dérives de performances
• Rafraichissement automatique du cookie d’authentification lorsque l’on est connecté (pour éviter les déconnexions au changement de page)
• Mise en forme des types génériques sur le StateObjects Explorer & MessageCallbacks Explorer
• Bugfix graphique sur le rédimensionnement de la Console log & editeur de configuration
• Mise à jour des codes snippets pour les appels HTTP (exemples pour l’API Constellation et l’API Consumer) dans le MessageCallbacks Explorer
• Appel des ressources JS/CSS et templates HTML avec le numéro de version pour éviter les problèmes de cache lors des mises à jour de la Console

Constellation Server 1.8.2 : section de configuration et compteurs de performance

Premièrement, le nom de la section de configuration “constellationSection” a été renommé en “constellation”.

Le programme d’installation du serveur 1.8.2 renommera automatiquement la section en cas de mise à jour de votre Constellation. Soyez simplement vigilant sur le fait que, désormais, la section est “<constellation>” et non “<constellationSection>”. Les schémas XSD fournis avec le SDK ainsi que l’IntelliSense du “Configuration Editor” de la Console ont été mis à jour dans ce sens.

Ensuite autre modification importante, les compteurs de performance sont activés si et seulement si la clé de configuration  “EnablePerformanceCounters” est définie à “true”.

Si la valeur est “false” ou encore si la clé n’est pas présente, les compteurs ne seront pas activés.

<appSettings>
  <add key="EnablePerformanceCounters" value="true" />
</appSettings>

Par défaut, lors d’une nouvelle installation la clé est définie à “false”. Dans le cas d’une mise à jour, la clé n’est pas ajoutée, autrement dit cette clé sera absente de votre configuration. De ce fait, les compteurs de performance sont désactivés par défaut.

C’est pourquoi, si vous souhaitez suivre les indicateurs de performance du serveur Constellation, vous devez explicitement ajouter ou modifier cette clé dans votre fichier de configuration et redémarrer le service Windows “Constellation Server”. Pour rappel, cette fonctionnalité n’est disponible que sur un environnement Windows.

N’hésitez pas à consulter le changelog complet et remonter vos feedbacks sur le forum.

The post Constellation 1.8.2 est disponible appeared first on Constellation.

Vous pouvez donc mettre à jour votre installation en lançant le « Web Platform Installer » :

Constellation Web Platform Installer » Article
Constellation-Web-Platform-Installer-1.9.735.exe
Version: 1.9.735

1.2 MiB
2137 Downloads
Détails

Constellation Web Platform Installer pour Windows

Auteur:	MyConstellation.io
Plateformes:	Windows
Catégorie:	Web Platform Installers
Licence:	Constellation License Agreement
Date:	juin 15, 2020

Ou sur Linux en lançant la commande suivante :

wget -O install.sh https://developer.myconstellation.io/download/installers/install-linux.sh && chmod +x install.sh && ./install.sh

A ce sujet, le « Web Platform Installer » pour Linux a été revu pour corriger les différents bugs remontés par la communauté.

Constellation Server 1.8.1 : ajout des compteurs de performance et nouvelle API de Management

Outre la refonte du manageur de StateObject et diverses optimisations et corrections de bugs mineurs, la nouvelle version du serveur Constellation supporte les compteurs de performance sous Windows pour pouvoir suivre l’activité du serveur.

Vous trouverez dans l’analyseur de performance Windows une nouvelle catégorie Constellation avec l’ensemble des compteurs du serveur :

L’autre grande nouveauté concerne l’API de Management. Elle met à disposition une API HTTP/REST d’édition de la configuration de votre Constellation :

• Gestion des sentinelles
• Gestion des packages
• Gestion des groupes
• Gestion des settings
• Gestion des RecoveryOptions
• Gestion des credentials et autorisations
• Gestion du Package Repository et upload de package
• Gestion de la licence
• Lire / Ecriture du fichier de configuration
• Récupération du numéro de version du serveur
• Rechargement et déploiement de la configuration

Vous trouverez sur cette page la documentation complète relative à cette API.

Constellation Sentinel 1.8.1

Les sentinelles remontent désormais au serveur des informations quant au moteur .NET utilisé et prennent en compte les changements de configuration des RecoveryOptions même si le package est déjà démarré. Aussi diverses optimisations et correctifs de bugs mineurs sont embarqués dans cette mise à jour.

Constellation Console 1.8.1 : une console vraiment complète !

C’est certainement la principale nouveauté de cette release 1.8.1 : l’évolution majeure de la Console !

Couplée à l’API de Management du serveur Constellation 1.8.1, il est désormais possible de configurer / piloter la quasi-totalité de Constellation depuis l’interface graphique de la Console sans devoir éditer le fichier de configuration XML manuellement.

De plus, cette version ajoute le catalogue en ligne de package Constellation directement dans la Console.

Gestion des sentinelles et packages

Il est maintenant possible d’ajouter, éditer ou supprimer les sentinelles depuis l’interface graphique.

De la même façon, il est possible de déployer des packages sans devoir éditer le fichier de configuration XML grâce à un assistant de déploiement :

De plus il est maintenant possible d’éditer la configuration ou les paramètres (settings) d’un package, de gérer les groupes de messages ou encore de supprimer les packages depuis l’interface de la Console :

Gestion des settings

La Console 1.8.1 rend possible l’édition des settings des packages sur base du manifeste. La Console tient compte des différentes informations contenues dans le manifeste comme les valeurs par défaut, le type du setting, son caractère obligatoire ou non, etc..

De plus l’éditeur s’adaptera en fonction du type du setting (types simples, section XML ou JSON) :

Le catalogue de package en ligne

Le catalogue de package officiel est directement intégré dans la console ce qui vous permettra de déployer des nouveaux packages ou les mises à jour sans quitter votre Console Constellation.

Gestion des crédentials et des autorisations

Il est désormais possible de gérer les crédentials depuis l’interface de la Console sans devoir éditer la configuration XML :

De plus, les autorisations sont également éditables depuis la Console :

Editeur de configuration

L’éditeur de configuration a évolué afin d’ajouter l’IntelliSense sur du base du schéma de configuration de Constellation pour simplifier l’édition bien qu’avec cette nouvelle version 1.8.1 il n’est plus tellement nécessaire de devoir éditeur ce fichier manuellement, l’interface de la Console permet la quasi-totalité des opérations.

Pour consulter le changelog complet de la version 1.8.1 :

• Release 1.8.1 (1.8.1.16259)
• Release 1.8.1 RC3 (1.8.1.16258)
• Release 1.8.1 RC2 (1.8.1.16203)
• Release 1.8.1 RC1 (1.8.1.16202)

N’hésitez pas à remonter vos feedbacks sur le forum.

The post Constellation 1.8.1 est disponible appeared first on Constellation.

Prérequis

La plateforme Constellation se compose :

• d’un serveur qui héberge et expose la Constellation en HTTP/s (un serveur = une Constellation)
• de sentinelles (UI ou Service) à installer sur vos différentes machines (tout système Windows ou Linux)
• d’une Console d’administration : application Web de pilotage de votre Constellation

Vous pouvez installer le serveur Constellation sur une machine Windows ou Linux, que ce soit un laptop, un desktop, un NUC, un SoC, un serveur local ou dans le Cloud.

Dans la rubrique Constellation Server vous retrouverez plusieurs articles sur les différentes installations possibles (système Linux,  Raspberry, cloud Azure ou Amazon, etc…).

Pour démarrer, nous allons déployer dans ce guide une Constellation complète (serveur, sentinelle, console et le SDK) sur une machine Windows.

Vous avez donc besoin pour suivre ce guide :

• d’un ordinateur ou serveur sous Windows (Windows 7/8/10 ou Windows Server)
• Pour installer le SDK : Visual Studio 2015, 2017 ou 2019

Si vous ne disposez pas de licence de Visual Studio, vous pouvez installer la version  “Community”, une version gratuite de Visual Studio compatible avec le SDK Constellation : https://www.visualstudio.com/fr-fr/products/visual-studio-community-vs.aspx

Télécharger la plateforme Constellation

Sur la page de téléchargement vous trouverez plusieurs programmes d’installation pour chaque composant Constellation  :

• Le serveur
• Les sentinelles (UI ou Service)
• La console
• Le SDK Visual Studio

Mais pour gagner en productivité, vous avez à votre disposition le “Web Platform Installer” (WPI), un programme d’installation tout-en-un qui télécharge automatiquement et configure les composants que vous souhaitez installer.

Commencez donc par télécharger le programme  “Constellation Web Platform Installer” pour Windows :

Constellation Web Platform Installer
Constellation-Web-Platform-Installer-1.9.735.exe
Version: 1.9.735

1.2 MiB
2137 Downloads
Détails

Constellation Web Platform Installer pour Windows

Auteur:	MyConstellation.io
Plateformes:	Windows
Catégorie:	Web Platform Installers
Licence:	Constellation License Agreement
Date:	juin 15, 2020

Installer la plateforme

Etape 1 : lancement de l’installation

Lancez le programme “Constellation Web Platform Installer.exe”

Etape 2 : identification

Vous devez dans cette étape renseigner votre compte myConstellation.io afin de pouvoir télécharger les composants Constellation et accéder à vos licences :

Etape 3 : acceptez la licence d’utilisation

Vous retrouverez le détail des licences Constellation sur cette page. Pour résumer, Constellation est gratuit pour un usage personnel ou éducatif sans aucun but lucratif et soumis à l’acquisition d’une licence pour un usage professionnel ou entreprise.

Etape 4 : choix du canal de distribution

Vous devez sélectionner le canal de distribution à utiliser : Stable ou Pre-release (versions Beta) :

Etape 5 : répertoire d’installation

Vous devez choisir le répertoire d’installation racine de la plateforme Constellation :

Etape 6 : sélectionnez les composants Constellation à installer

Vous pouvez sélectionner ici les composants à installer ou utiliser les profils prédéfinis :

• Full server installation : installation typique pour un serveur (le serveur, la sentinelle en version service et la console Constellation)
• Full developer installation : installation typique pour un poste de développement (le serveur, la sentinelle UI, la console et le SDK Visual Studio)
• Custom installation : sélectionnez à la carte les composants que vous souhaitez installer

Notez que le WPI vous indiquera la dernière version de chaque composant à installer et est capable de déployer les mises à jour pour chacun de ces composants si une nouvelle version plus récente est disponible.

Notez également que si Visual Studio n’est pas installé, le composant SDK sera grisé avec la mention “Not applicable”.

Dans ce guide, sélectionnons le profil “Développeur” :

Etape 7 : configuration du serveur Constellation

Entrons désormais dans les étapes de configuration de chacun des composants à installer en commençant par le serveur Constellation.

Etape 7.1 : sélection de la licence

Premièrement, vous devez sélectionner une licence pour l’utilisation du serveur. Vous pouvez utiliser une licence que vous aurez préalablement téléchargée depuis le portail Constellation ou  vous connecter directement sur le service de licence de Constellation depuis le WPI :

Vous obtiendrez l’ensemble des licences associées à votre compte avec la possibilité de créer des licences gratuites pour un usage personnel (plus d’information ici).

Dans notre cas créons une licence personnelle :

Etape 7.2 : choix du répertoire des packages

Dans cette étape vous devez définir le répertoire pour votre catalogue de packages de votre Constellation.

Par défaut, il s’agit du sous-dossier “Packages” de votre répertoire d’installation :

Etape 7.3 : choix du port d’écoute du serveur

Le serveur Constellation utilise le protocole HTTP pour exposer ses différents hubs et API. Pour cela vous avez besoin de choisir le port d’écoute et de l’ouvrir au niveau de votre firewall.

L’assistant peut déclarer le port que vous avez choisi dans le pare-feu de Windows. Si vous souhaitez ouvrir Constellation à l’extérieur de votre réseau local, à vous d’ouvrir le port sur votre routeur.

A noter que vous pouvez déclarer dans la configuration du serveur Constellation sur plusieurs ports HTTP et/ou HTTPS ou même définir un chemin HTTP personnalisé. Il est d’ailleurs conseillé d’activer le protocole HTTPS si vous souhaitez exposer votre serveur Constellation sur Internet. Vous retrouverez plusieurs articles sur la configuration avancée du serveur dans la rubrique Constellation Server.

Etape 7.4 : choix des clés d’accès

Pour se connecter à Constellation vous avez besoin de créer des clés d’accès (les “Access Keys”). Dans le cas d’une nouvelle installation, l’assistant vous proposera de créer deux clés :

• Une clé “Standard” (accès de base) que vous utiliserez pour connecter vos sentinelles et packages
• Une clé “Administrator” qui dispose des droits d’accès au hub de contrôle (pour le pilotage de la Constellation) et à l’API de Management (pour la configuration du serveur) :

Une clé d’accès est une chaîne de caractère. Il est conseillé de choisir des clés d’accès assez longues (> 16 caractères) et compliquées.

Pour simplifier leurs mémorisations et générations, Constellation propose d’utiliser un couple login/password pour créer des clés d’accès. Pour cela, on utilise le hash SHA1.

Exemple : pour le login “Admin” et le mot de passe “Password”, la clé d’accès sera “d882b8721a224d38ebb54559e6b54e5df3a1bc6d » (soit SHA1(“AdminPassword”)). Notez bien que la casse est importante !

Dans l’assistant d’installation, cliquez sur le bouton “Use Password” pour renseigner un couple login/password afin de générer les Access Keys :

Pour finir, vous pouvez ajouter le droit de débogage sur la clé “Administrator” en cochant la case correspondante. Cela nous permettra de tester des packages connectés à votre Constellation depuis Visual Studio.

Etape 8 : configuration de la Console Constellation

Comme la Console Constellation est déployée sur la même machine que le serveur Constellation, l’assistant vous propose héberger la console par le serveur Constellation lui-même.

Si vous désirez utiliser votre propre serveur Web pour exposer la Console (Apache, IIS ou autre) sélectionnez la deuxième option mais dans notre guide laissons le serveur Constellation héberger la console :

Vous pouvez ensuite fixer une clé d’accès en dur ou utiliser une page de login. De plus vous pouvez également restreindre l’accès à la console en local seulement.

Laissons les options par défaut (c’est à dire Console ouverte à tous avec une page de login) :

Etape 9 : configuration de la Sentinelle Constellation

Dans la sélection des composants nous avons indiqué vouloir installer la sentinelle UI. Vous arrivez donc à cette étape de configuration.

Comme la sentinelle est installée sur la même machine sur le serveur, vous pouvez l’inclure automatiquement dans votre Constellation ou bien l’inclure dans une autre Constellation en sélectionnant la deuxième option.

Dans notre cas, laissons la première option sélectionnée pour ajouter notre sentinelle UI à notre Constellation en cours d”installation :

Etape 10 : Installation

La configuration des composants est désormais terminée. Vous retrouverez tout le détail sur l’écran de confirmation :

En cliquant sur le bouton “Install”, le Web Platform Installer va télécharger les dernières versions de composants Constellation à installer :

Puis il déroulera l’installation et la configuration de chacun de ces composants :

A la fin de l’installation, l’assistant vous proposera de lancer la Console et la Sentinelle UI (car ces deux composants ont été installés) :

Etape 11 : Validation de l’installation

En fermant le programme d’installation, la sentinelle UI va être lancée :

En double-cliquant sur l’icone vous pourrez visualiser les logs de cette sentinelle qui doit être correctement connectée au serveur :

Vous aurez également la Console Constellation qui se lancera dans votre navigateur Internet par défaut :

Utilisez le Login/Password de la clé d’accès “Administrator” pour vous connecter. Sur la page “Sentinels” vous devriez voir votre sentinelle UI locale connectée :

Bravo vous avez déployé votre première Constellation avec succès !

Optionnellement : ajouter ou mettre à jour un composant

Vous pouvez à tout moment relancer le “Web Platform Installer” (WPI) pour ajouter ou mettre à jour des composants Constellation.

Ainsi quand des mises à jour Constellation sont disponibles, vous avez juste à relancer le WPI et vous laissez guider par l’assistant.

Dans notre exemple, relançons le WPI. Comme nous le montre l’écran ci-dessous, tous les composants sont bien à jour mais vous pouvez encore ajouter la “Sentinel Service” sur cette machine :

Vous entrez alors dans la configuration de la sentinelle avec la possibilité d’ajouter cette nouvelle sentinelle à votre Constellation locale (car précédemment installée) ou de l’ajouter à une autre Constellation.

Next steps

• Ajoutez des sentinelles dans votre Constellation
• Téléchargez et déployez des packages sur vos sentinelles
• Exposer votre serveur Constellation derrière avec reverse proxy IIS ou Nginx et ajouter le support du HTTPS/SSL

Vous souhaitez installer le serveur et sa console sur un système Linux ?

• Installer Constellation sur Linux

Prêt pour développer avec Constellation ?

• Créez votre premier package Constellation en C#
• Créez des packages UI en Winform ou WPF
• Connectez vos pages Web à Constellation
• Créez votre premier package Constellation en Python
• Connectez un Arduino ou un ESP8266 à Constellation

The post Installer la plateforme Constellation 1.8 appeared first on Constellation.

Ce fichier se nomme “Constellation.Server.exe.config” et se trouve dans le répertoire d’installation du serveur (par défaut dans “Program Files\Constellation Plateform\Server« ).

Vous pouvez le modifier de différente manière :

• En éditant ce fichier directement sur le serveur (avec un éditeur de texte type Notepad)
• Via la Console Constellation (sur la page Configuration Editor)
• Via Visual Studio
• Via l’API de Management Constellation

Le fichier contient une balise globale “configuration” dans laquelle vous trouverez 4 sections :

• configSections : réservé au moteur .NET
• constellation : la section de configuration Constellation (anciennement nommée ‘constellationSection’)
• startup : réservé au moteur .NET
• runtime : réservé au moteur .NET

Vous ne devez en aucun cas modifier les sections réservées au moteur .NET sans savoir exactement ce que vous faites.

La section de “constellation” se décompose de la façon suivante :

• listenUris : définit la configuration des URI d’écoute du serveur Constellation
• fileServer : définit la configuration du serveur Web statique utilisé pour l’hébergement de la Console Constellation
• recoveryOptions : définit les options de récupération des packages
• sentinels : définit la configuration des sentinelles (et des packages) de votre Constellation
• settingsGroups : définit la configuration des groupes de “settings”
• credentials : définit la configuration des credentials pour l’accès à votre Constellation

A chaque modification vous devez recharger la configuration soit via le hub de contrôle ou la Console Constellation (bouton “Reload Configuration”) ou soit en redémarrant le service Constellation Server.

Section “listenUris”

Cette section permet de définir les URI sur lesquels le serveur Constellation doit écouter.

<listenUris>
  <uri listenUri="http://+:8088/" />
</listenUris>

Ici le serveur répondra sur le port HTTP 8088 quelque soit le host (nom DNS ou adresse IP) car nous utilisons le wildcard “+” (pour plus d’information, lisez ceci).

Vous pouvez configurer autant de “listenUri” que vous souhaitez. Par exemple :

<listenUris>
  <uri listenUri="http://+:8088/" />
  <uri listenUri="http://constellation.mydomain.net:8888/" />
  <uri listenUri="http://+:8080/constellation/" />
  <uri listenUri="https://+:8089/" />
</listenUris>

Ici, le serveur Constellation répondra :

• Aux requêtes sur le port HTTP 8088
• Aux requêtes sur le port HTTP 8888 où le host est “constellation.mydomain.net” (en clair une requête http://<ip>:8888  ne fonctionnera pas)
• Aux requêtes sur le port HTTP 8080 quelque soit le host mais dont le path doit forcement démarrer par “/constellation/”
• Aux requêtes sur le port HTTPS 8089 en utilisant un cryptage SSL (plus d’information)

Pour prendre en compte les modifications de cette section vous devez redémarrer le service Constellation.

Section “fileServer”

Cette section permet d’activer et configurer le “fileServer” de Constellation pour héberger des fichiers statiques (pages HTML, fichiers CSS, JS, images, etc..).

Cela sert principalement pour “auto-héberger”  la Console Constellation par le serveur Constellation lui-même.

En effet, la Console Constellation n’est ni plus ni moins qu’une application Web client-side, c’est à dire une série de pages HTML avec scripts JS et fichiers CSS/Image. Libre à vous de l’héberger sur vos serveurs Web mais afin de limiter les prérequis, le serveur Constellation peut lui-même héberger la console grâce au “fileServer” intégré.

La section “fileServer” ne contient que quatre attributs :

<fileServer enable="true" path="/WebConsole" localhostOnly="true" physicalPath="D:\App\Constellation\Console" />

• “enable” : indique si le serveur de fichier statique sur le serveur Constellation doit être activé (true ou false).
• “path” : le répertoire d’écoute (préfixé par la listenUri).
• “localhostOnly” : indique si le fileServer répond seulement aux requêtes “locales” ou à toutes les requêtes (true ou false).
• “physicalPath” : le répertoire physique

Dans l’exemple ci-dessus, le serveur de fichier est activé mais ne répondra qu’aux requêtes locales. Le serveur délivra les fichiers dans “D:\App\Constellation\Console” sur l’URL “<listen_URI_du_serveur_Constellation>/WebConsole” par exemple http://localhost:8088/WebConsole ou http://127.0.0.1:8088/WebConsole en partant du principe qu’il existe une listenUri “http://+:8088”.

Comme pour la section précédente (listenUris), il faut obligatoirement redémarrer le service Constellation Server pour prendre en compte ces modifications.

Section “recoveryOptions”

Les options de récupération (recoveryOptions) permettent de définir le comportement de la sentinelle en cas d’arrêt brutale de l’exécution d’un package (crash du package).

Chaque package peut avoir ses propres options de récupération mais cette section permet de définir les options “globales”, c’est à dire appliqué par défaut pour chaque package de la Constellation.

Les options de récupérations se résume en quatre propriétés :

• “restartAfterFailure” (true par défaut) : définit si la sentinelle doit redémarrer un package en cas de crash de ce dernier
• “numberOfRetry” (3 par défaut) : définit le nombre maximal de tentative de redémarrage d’un package
• “restCounterAfterMinutes” (15 par défaut) : définit la période (en minute) au delà de laquelle le compteur d’erreur est réinitialisé
• “restartPackageAfterSeconds” (30 par défaut) : définit le délai d’attente avant de redémarrer un package suite à un crash

Dans la configuration par défaut, si un package “crash” il est automatiquement redémarré 30 secondes après son crash dans la limite de 3 tentatives sachant qu’au bout de 15 minutes, le compteur de tentative est réinitialisé à 0.

Section “sentinels”

Dans cette section vous allez déclarer vos sentinelles (virtuelles ou non) dans lesquelles vous déclarerez les packages (virtuels ou non) qui eux même déclarons leurs settings et leurs groupes.

En clair, c’est cette section qui décrit votre “Constellation”.

Prenez l’exemple de la Constellation suivante :

<sentinels>
  <sentinel name="SENTINEL-NAME-DEMO" credential="Standard">
    <packages>    
      <package name="HWMonitor" enable="true"></package>          
      <package name="DemoPackage" credential="ControlHubAccess" enable="true">
        <settings>
        <import>
          <settingGroup groupName="GroupSettingsDemo" />
        </import>
        <setting key="IntSetting" value="42" />
        <setting key="StringSetting" value="sample config value 2" />
        <setting key="SettingXml">
          <content>
            <demo type="test">
              <list count="42">
              <a>123</a>
              <b>test</b>
              </list>
            </demo>
          </content>
        </setting>
        <setting key="SettingJson">
          <content>
          <![CDATA[
          {
            ListenPorts: [ 80, 443 ],
            EnableCaching : true,
            ServerProgramName: "Hypothetical WebServer 1.0",
            Websites: [
              {
                Path: "/srv/www/example/",
                Domain: "example.com",
                Contact: "admin@example.com"    
              },
              {
                Path: "/srv/www/somedomain/",
                Domain: "somedomain.com",
                Contact: "admin@somedomain.com"
              }
            ]
          }
          ]]>
          </content>
        </setting>
        </settings>
      </package>
    </packages>
  </sentinel>
  <sentinel name="ANOTHER-SENTINEL" credential="Standard">
    <!-- ..... -->
  </sentinel>
</sentinels>

Voici ce qu’elle décrit :

• Nous avons deux sentinelles “SENTINEL-NAME-DEMO” et “ANOTHER-SENTINEL »
• Les deux sentinelles utilisent le même credential “Standard” (déclaré dans la section credentials).
• Sur la première sentinelle est déployée deux packages :
  • “HWMonitor” : le package utilise le même credential que sa sentinelle (car non défini explicitement donc hérite du credential de sa sentinelle)
  • “DemoPackage” : ce package utilise le credential nommé “ControlHubAccess” et déclare les settings suivants :
    • IntSetting et StringSetting associés à des valeurs (numérique et string)
    • SettingXml et SettingJson associés à des contenus (XML et JSON)
    • Importe le groupes de settings nommé “GroupSettingsDemo” défini dans la section “settingsGroups”

Les sentinelles

Pour entrer dans le détail, vous allez déclarer dans la section “sentinels”, les sentinelles de votre Constellation que ce soit des sentinelles réelles ou virtuelles.

Pour cela, vous utiliser la balise “<sentinel>” qui comporte les attributs suivants :

• “name” : le nom de la sentinelle (obligatoire et unique)
• “credential” : le nom du credential (déclaré dans la section credentials) à utiliser pour l’authentification (obligatoire)

La section “<sentinel>” contient une collection de “<package>” rangée dans la balise “<packages>”. Chaque package peut-être réel ou virtuel.

Les packages

L’élément “<package>” contient les attributs suivants :

• “name”: le nom de l’instance du package (obligatoire et unique)
• “filename” (facultatif) : le nom du fichier du package à utiliser dans le repository (plus d’info)
• “enable” (facultatif, par defaut true) : indique si le package est activé ou désactivé
• “credential” (facultatif, utilise par défaut du credential de sa sentinelle) : spécifie le credential que le package va utiliser pour s’authentifier sur le serveur Constellation
• “autostart” (facultatif, par defaut true) : indique si le package doit automatiquement démarrer sur sa sentinelle ou juste être déployé (et donc démarré manuellement)

Un package peut contenir ensuite trois sous sections :

• “recoveryOptions” : définit les options de récupération du package (par défaut, la sentinelle utilise les options globales)
• “settings” : définit les paramètres/variables de configuration d’un package
• “groups” : définit les groupes dans lesquels le package sera abonné

Les options de récupérations

La balise est la même que la section globale.

Par exemple si on ne souhaite pas que le package redémarre en cas de crash, on peut écrire :

<package name="MonPackage" enable="true">
  <recoveryOptions restartAfterFailure="false" />
</package>

Les paramètres de configuration

Chaque package peut définir des paramètres de configuration au niveau du serveur Constellation. Cela vous permet de changer ces paramètres directement depuis la Constellation qui se chargera de redescendre ces paramètres sur vos packages.

Il y a deux types de settings :

• Les “Setting Value” : il s’agit d’un couple clé/value
• Les “Setting Content”  : il s’agit d’un setting dont la valeur peut être un XML ou JSON

Dans l’exemple plus haut, le package “DemoPackage” contient à la fois des settings de type “value” et de type “content”.

Vous pouvez également regrouper des settings dans les groupes afin de les partager entre plusieurs package grâce aux settingsGroups. Toujours dans l’exemple précédent, le package “DemoPackage” inclut le groupe “GroupSettingsDemo”, un groupe de settings décrit dans la section ”settingsGroups”.

Pour plus d’information sur les settings, consultez l’article sur l’exploitation des settings avec l’API .NET.

Les groupes

Comme vous le savez, un message peut être envoyé à un groupe dans lequel des packages réels ou virtuels peuvent s’abonner.

Il y a deux manières d’abonner un package à un groupe :

• Soit par le package lui même en invoquant la méthode “SubscribeToMessage” via les différentes API Constellation misent à disposition
• Soit dans la configuration du package au niveau du serveur Constellation

Cela vous permet d’avoir la main sur l’appartenance des packages aux groupes que vous pouvez administrer sans devoir modifier vos packages (virtuels ou non).

La section “groups” sur un package permet de définir ces liens. Par exemple :

<package name="MonPackage" enable="true">
  <groups>
    <group name="MonGroupeA" />
    <group name="MonGroupeB" />
  </groups>
</package>

Ici le package “MonPackage” est abonné aux groupes “MonGroupeA” et “MonGroupeB”. En cas de modification des affectations aux groupes, il faudra redémarrer le package soit via vos applications en utilisant les API du hub de contrôle soit depuis la Console Constellation.

Section “settingsGroups”

Vous pouvez grouper des settings (Content ou Value) dans des groupes au niveau du serveur et importer ces groupes dans les settings de vos packages ou dans d’autres groupes.

Par exemple, créons un groupe pour “HWMonitorSettings” qui contient le setting “Interval” :

<settingsGroups>
  <group name="HWMonitorSettings">
    <settings>
      <setting key="Interval" value="500" />
    </settings>
  </group>
</settingsGroups>

Ainsi pour chaque instance du package “HWMonitor”, vous pouvez importer le groupe “HWMonitorSettings” afin de centraliser la configuration de ce package :

<package name="HWMonitor">
  <settings>
    <import>
      <settingGroup groupName="HWMonitorSettings" />
    </import>
  </settings>
</package>

Vous pouvez importer des groupes dans des groupes sans limite.

C’est toujours la valeur du setting la plus proche du package qui gagne (surcharge).

Bien entendu, vous pouvez créer autant de groupe que vous voulez et chaque groupe peut contenir des SettingValue ou des SettingContent :

<settingsGroups>
  <group name="test">
    <settings>
      <setting key="Demo1" value="Seb" />
      <setting key="Demo2" value="123" />
    </settings>
  </group>
  <group name="test2">
    <settings>
      <import>
        <settingGroup groupName="common" />
      </import>
      <setting key="Demo1" value="Sebastien" />
      <setting key="Demo2" value="2015" />
    </settings>
  </group>
  <group name="common">
    <settings>
      <setting key="MyStringSetting" value="This is a string" />
      <setting key="MyBoolSetting" value="true" />
      <setting key="MyXmlDocument">
        <content>
          <note date="09-02-2016">
            <to>Tove</to>
            <from>Jani</from>
            <heading>Reminder</heading>
            <body>Don't forget me this weekend!</body>
          </note>
        </content>
      </setting>
      <setting key="MyJsonObject">
        <content>
          <![CDATA[
        {
          "Number": 123,
          "String" : "This is a test (local)",
          "Boolean": true
        }
        ]]>
        </content>
      </setting>
    </settings>
  </group>
</settingsGroups>

Pour bien comprendre, imaginez le package suivant :

<package name="DemoPackage">
  <settings>
    <import>
      <settingGroup groupName="test" />
      <settingGroup groupName="test2" />
    </import>
    <setting key="numberTest" value="42" />
    <setting key="Demo1" value="It’me" />
  </settings>
</package>

Ici cette instance du package “DemoPackage” définie au niveau du serveur (= sans prendre en compte les settings déclarés dans le fichier local et le manifeste) 7 settings :

• numberTest = 42 (définit dans les settings du package)
• Demo1 = “It’s me” (définit dans les settings du package, cette valeur écrase celle des groupes importés)
• Demo2 = 2015 (définit par le groupe “test2”. Cette valeur écrase la valeur du groupe “test”, car le groupe “test2” est importé APRES le groupe “test”)
• MyStringSetting, MyBoolSetting, MyXmlDocument et MyJsonObject définies par le groupe “common” (groupe importé dans le groupe “test2” lui même importé sur le package “DemoPackage”).

Section “credentials”

Comme évoqué dans l’article lié à la sécurité, tous les appels (http) au serveur Constellation doivent être authentifiés en utilisant une clé d’accès que l’on nomme “AccessKey”.

Ces clé d’accès sont liés à des credentials.

Dans la section “credentials” nous allons donc définir les différents credentials ainsi que les différentes autorisations et droits sur ces credentials.

Chaque credential comporte obligatoirement deux propriétés :

• Le nom (unique) du credential
• L’AccessKey

Ainsi que les propriétés suivantes :

• “enable” (true par défaut) : indique si le credential est activé ou désactivé
• “enableControlHub” (false par défaut) : indique si le credential peut se connecter sur le hub de contrôle (pour l’administration de la Constellation)
• “enableManagementAPI” (false par défaut) : indique si le credential peut se connecter à l’API de Management (pour l’édition de la configuration)
• “enableDeveloperAccess” (false par défaut) : indique si le credential peut utiliser la sentinelle virtuelle “Developer” pour debugger des packages (utilisé par le SDK Visual Studio)

Par exemple :

<credentials>
  <credential name="Standard" accessKey="fb1af70a46057dbf4f2ff3f43b6ec0c544b22749" />
  <credential name="Administrator" accessKey="b363d6ccb86ef1418a72f9fea4b96975d8a1f2c7" enableControlHub="true" enableDeveloperAccess="true" enableManagementAPI="true" />
</credentials>

Vous pouvez ensuite définir des autorisations particulières sur un credential pour l’envoi de message, l’abonnement aux groupes de message ou encore l’interrogation de StateObject.

Pour cela il existe trois sous-sections :

• “stateObjects” : autorisations spécifiques pour l’interrogation (Request ou Subscribe) des StateObjects
• “messages” : autorisations spécifiques pour l’envoi de messages
• “groups” : autorisations spécifiques pour l’abonnement aux groupes

Les autorisations sur l’interrogation des StateObjects

Par défaut un credential actif (enable=true) peut interroger (Request ou Subscribe) tous les StateObjects de votre Constellation sans restriction.

Pour modifier ce comportement vous pouvez utiliser les autorisation sur les StateObjects.

Par exemple :

<credential name="Standard" accessKey="fb1af70a46057dbf4f2ff3f43b6ec0c544b22749">
  <authorizations>
    <stateObjects defaultAuthorization="Deny">
      <authorization id="Paradox" authorization="Allow" packageName="Paradox" />
      <authorization id="MonPC" authorization="Allow" sentinelName="PC-SEB" />
      <authorization id="LesCPU" authorization="Allow" packageName="HWMonitor" name="/intelcpu/load/0" />
      <authorization id="ServerRAM" authorization="Allow" sentinelName="SERVER" packageName="HWMonitor" name="/ram/load" />
    </stateObjects>
  </authorizations>
</credential>

Ici le credential “Standard” ne pourra pas interroger les StateObjects de la Constellation (defaultAuthorization = Deny) sauf pour les exceptions suivantes :

• Les StateObjects produits par le(s) instance(s) du package “Paradox”
• Les StateObjects produits par les packages (quel qu’il soit) de la sentinelle “PC-SEB”
• Les StateObjects nommés “/intelcpu/load/0” et produits par le package “HWMonitor” peu importe la sentinelle
• Le StateObject nommé “/ram/load” produit par le package “HWMonitor” sur la sentinelle “SERVER”

Vous devez donc définir l’autorisation par défaut (defaultAuthorization) et optionnellement ajouter une ou plusieurs exceptions avec l’élément <authorization> dont les attributs sont les suivants :

• “id” (obligatoire) : identifiant unique de l’autorisation
• “authorization” (facultatif – Allow par défaut) : type de l’exception (Allow ou Deny)
• “sentinelName” (facultatif – * par défaut) : sentinelle producteur du StateObject
• “packageName” (facultatif – * par défaut) : package producteur du StateObject
• “name” (facultatif – * par défaut) :  nom du StateObject

Les autorisations sur l’envoi de messages

Par défaut un credential actif (enable=true) peut envoyer un message à n’importe quel scope dans votre Constellation sans restriction.

Par exemple :

<credential name="Standard" accessKey="fb1af70a46057dbf4f2ff3f43b6ec0c544b22749">
  <authorizations>
    <messages defaultAuthorization="Deny">
      <authorization id="GroupA" authorization="Allow" scope="Group" args="A" />
      <authorization id="DemoSeb" authorization="Allow" scope="Package" args="DemoPackage" />
      <authorization id="TemperatureNest" authorization="Allow" scope="Package" args="Nest" messageKey="SetTargetTemperature"  />
    </messages>
  </authorizations>
</credential>

Ici le credential “Standard” ne pourra pas envoyer de message dans la Constellation (defaultAuthorization = Deny) sauf pour les exceptions suivantes :

• Messages envoyés au groupe “A”
• Messages envoyés au package “DemoPackage”
• Message “SetTargetTemperature” envoyé au package “Nest”

Vous devez donc définir l’autorisation par défaut (defaultAuthorization) et optionnellement ajouter une ou plusieurs exceptions avec l’élément <authorization> dont les attributs sont les suivants :

• “id” (obligatoire) : identifiant unique de l’autorisation
• “scope” (obligatoire) : type de scope pour le message (All, Group, Package ou Sentinel)
• “authorization” (facultatif – Allow par défaut) : type de l’exception (Allow ou Deny)
• “args” (facultatif) : les arguments du scope
• “messageKey” (facultatif) :  la clé du message

Les autorisation sur l’abonnement aux groupes

Par défaut un credential actif (enable=true) peut s’abonner à n’importe quel groupe sans restriction.

Par exemple :

<credential name="Standard" accessKey="fb1af70a46057dbf4f2ff3f43b6ec0c544b22749">
  <authorizations>
    <groups defaultAuthorization="Deny">
      <authorization groupName="A" />
    </groups>
  </authorizations>
</credential>

Ici le credential “Standard” ne pourra pas s’abonner à des groupes (defaultAuthorization = Deny) à l’exception du groupe “A”. Les attributs sont les suivants :

• “groupName” (obligatoire) : le nom du groupe
• “authorization” (facultatif – Allow par défaut) : type de l’exception (Allow ou Deny)

The post Le fichier de configuration appeared first on Constellation.

Vous pouvez soit exposer votre serveur Constellation derrière un reverse-proxy IIS, ngnix, Apache ou autre sur lequel vous activerez le cryptage SSL ou soit exposer Constellation directement en SSL.

Pour cette dernière option voici la procédure compatible seulement sur un serveur Windows. Si votre serveur Constellation est sous Linux, vous devez mettre en place un reverse proxy (avec IIS sur Windows ou ngnix sur Linux) devant votre serveur Constellation.

Etape 1 : créer un certificat SSL

La première étape consiste à créer un certificat SSL portant le nom de l’URI de votre Constellation (par exemple constellation.mondomaine.com).

Plusieurs options :

• Créer un certificat auto-signé
• Créer un certificat privé avec votre propre autorité de certification
• Créer/acheter un certificat à une autorité de certification reconnue

Dans le premier cas, il faudra installer ce certificat sur chaque poste client sous peine d’avoir des avertissements de sécurité.

Vous pouvez créer des certificats auto-signés depuis la console IIS, Powershell ou en ligne de commande avec l’utilitaire “makecert” sur Windows par exemple. Il existe également des générateurs de certificats auto-signés en ligne.

Si vous avez un domaine Active Directory avec une autorité de certification (ADCS) vous pouvez générer des certificats SSL depuis la console IIS (voir ici). Il faudra que chaque client de votre Constellation ait le certificat publique de votre autorité de certification (AC) pour fonctionner.

Autrement pour éviter ce type de prérequis, vous devez générer un certificat SSL signé par une véritable autorité de certification tel que GlobalSign, GeoTrust, Gandi, etc. Chez StartCom ou WoSign, les certificats SSL sont gratuits. Chez Gandi, vous avez la première année offerte pour chaque domaine que vous commandez chez eux.

Pour finir il est aussi possible d’utiliser Let’s Encrypt pour générer gratuitement et à la demande des certificats SSL. Il est recommandé d’utiliser ce type de certificat avec un reverse proxy pour simplifier le déploiement et le renouvellement. Consultez avec article exposer Constellation en SSL avec des certificats Let’s Encrypt et Nginx.

Etape 2 : installer le certificat

Sous Windows, vous devez ouvrir la MMC de gestion des certificats pour installer le certificat créé à l’étape 1.

Vous pouvez par exemple suivre ces guides :

• https://fr.godaddy.com/help/iis-8-install-a-certificate-4951
• https://www.startssl.com/Support?v=31 (étape 9 à 12).

Etape 3 : lier le certificat à un port TCP

Lorsque vous installer votre certificat dans la MMC lors de l’étape précédente, copiez l’empreinte (thumbprint) visible dans les propriétés de votre certificat.

Puis dans une invite de commande, entrez la commande suivante :

netsh http add sslcert ipport=0.0.0.0:XXX appid={12345678-db90-4b66-8b01-88f7af2e36bf} certhash=yyy

Vous devez remplacer “XXX” par le port TCP que vous souhaitez utiliser pour exposer Constellation en SSL et “YYY” par le thumbprint de votre certificat SSL.

Etape 4 : configurer Constellation

Pour finir éditez le fichier de configuration Constellation (Constellation.Server.exe.config) et ajoutez une “listenUri” sur le port défini dans l’étape précédente.

Par exemple, configurons Constellation pour écouter en HTTP sur le port par défaut 8088 et en HTTPS (SSL) sur le port 8089 :

<listenUris>
  <uri listenUri="http://+:8088/" />
  <uri listenUri="https://+:8089/" />
</listenUris>

The post Configuration du serveur Constellation en SSL appeared first on Constellation.

Si vous avez un serveur Windows, vous pouvez également utiliser IIS pour configurer un reverse proxy vers Constellation.

Dans cet article nous allons découvrir comment exposer le serveur Constellation derrière un serveur Nginx protégé avec un certificat SSL Let’s Encrypt.

Prérequis : avoir une Constellation exposée publiquement avec un nom DNS

Avant de démarrer vous devez avoir un serveur Constellation opérationel.

Si vous installez Constellation sur un Linux, cela se résume à lancer la commande ci-dessous et à suivre l’assistant :

wget -O install.sh https://developer.myconstellation.io/download/installers/install-linux.sh && chmod +x install.sh && ./install.sh

Pour plus d’information, veuillez suivre le guide : Installer Constellation sur Linux.

On considéra à ce stade que votre serveur Constellation est démarré et opérationnel. Vous pouvez lancer la commande suivante pour vérifier le statut des services Constellation :

sudo supervisorctl status

Vous devriez voir le “constellation-server” avec le statut “RUNNING” (et la sentinelle si déployée) :

sebastien@ubuntu:~$ sudo supervisorctl status
constellation-sentinel           RUNNING   pid 1194, uptime 1 day, 17:36:48
constellation-server             RUNNING   pid 2888, uptime 1 day, 15:06:41

Vous pouvez également installer Constellation sur un système Windows (voir le guide).

En effet, le reverse proxy (ici Ngnix) qui sera installé sur un système Linux peut exposer un service tel que Constellation quelque soit le serveur sur lequel il est déployé. Le reverse proxy n’est pas nécessairement sur la même machine sur le ou les services à exposer.

Il est donc possible d’installer un serveur Linux avec Nginx pour exposer en SSL un serveur Constellation sur un système Windows de la même manière que nous pouvons installer un serveur Windows avec IIS pour exposer en SSL un serveur Constellation sur un système Linux !

Dans ce guide nous avons installer le serveur Constellation et le reverse proxy Nginx sur le même serveur, sous Linux Ubuntu 16.

Si vous souhaitez activer le HTTPS et donc ajouter un certificat SSL, vous devez nécessairement avoir un nom DNS qui pointe vers l’adresse IP (public) de votre serveur de reverse proxy.

Plusieurs options s’offre à vous :

• Si vous avez un nom de domaine, modifiez votre zone DNS pour ajouter un “host” (enregistrement A ou AAAA) vers l’adresse IP (public) de votre Constellation.
• SI vous n’avez pas de nom de domaine :
  • Achetez-en un ! Comptez environ 15€/an pour les extensions standards (.fr, .net, .com), 2,99€ HT par an pour  un .ovh
  • Utilisez un service de “Dynamic DNS” comme dyndns.fr, dyn.com ou autre
  • Certains FAI comme Free proposent d’attacher un nom DNS type xxxx.hd.free.fr à votre IP de connexion
  • Certains NAS comme Synology permettent aussi de créer un DDNS type xxx.synology.me vers votre IP de connexion

Dans le cas présent, j’ai crée l’entrée DNS “demo.internal.myconstellation.io” qui pointe vers l’adresse IP public du serveur Constellation installé sur un Ubuntu (le DNS doit pointer votre le serveur où sera installé le reverse proxy dans la mesure où tout passera par lui. Etant donné que le reverse proxy sera sur le même serveur que le service Constellation on peut dire que le DNS pointe vers le serveur Constellation).

Bien évidement, si votre serveur est installé dernière un routeur avec du NAT (typiquement sur un réseau local derrière une box Internet) vous devez configurer la redirection de port sur votre routeur/box internet.

Encore une fois, on part du principe que le serveur de R.P et Constellation sont sur le même serveur, donc la même IP interne.

Dans un premier temps redirigez seulement le port 8088 en tcp sur l’IP interne de votre serveur Constellation. A noter que nous supprimerons cette redirection une fois le reverse proxy installé.

Donc pour résumer et avant de démarrer, vous devez avoir votre serveur Constellation démarré répondant sur l’URL : http://<mon_nom_dns>:8088

Dans mon cas : http://demo.internal.myconstellation.io:8088 :

Voilà vous êtes prêt, votre Constellation est démarrée et elle répond bien sur un nom DNS public depuis l’internet.

Exposer Constellation derrière Nginx

Avant de démarrer il est recommandé de mettre à jour le référentiel du gestionnaire de package par la commande suivante :

sudo apt-get update

Ensuite installez le serveur Web Nginx avec la commande :

sudo apt-get install nginx

Les fichiers de configuration sont situés dans le répertoire “/etc/nginx/sites-available/” et pour les activer on crée un lien symbolique vers ces fichiers dans le répertoire “/etc/nginx/sites-enabled”.

Pour commencer désactivez la configuration par défaut par la commande ci-dessous :

sudo rm /etc/nginx/sites-enabled/default

Comme vous l’aurez compris le contenu de cette configuration par défaut est toujours présente dans le répertoire “/etc/nginx/sites-available/” mais non activée car on a supprimé le lien symbolique vers ce fichier dans le répertoire “site-enabled”.

Maintenant nous allons créer une configuration pour notre reverse proxy avec la commande :

sudo nano /etc/nginx/sites-available/constellation

Dans ce fichier, copiez le contenu suivant :

server {
    listen 80; listen [::]:80;
    server_name demo.internal.myconstellation.io;

    location / {
        proxy_pass http://localhost:8088;

        set $content_length_safe $http_content_length;
        if ($content_length_safe = "") {
            set $content_length_safe 0;
        }
        proxy_set_header Content-Length $content_length_safe;

        proxy_set_header Host $host;
        proxy_set_header Connection "";
        proxy_http_version 1.1;

        proxy_buffering off;
        proxy_cache off;
        proxy_connect_timeout 30;
        proxy_send_timeout 30;
        proxy_read_timeout 150;
    }
}

Vous devez modifier le paramètre “server_name” avec le nom DNS de votre serveur Constellation, dans le cas présent “demo.internal.myconstellation.io”.

Il est important de bien reprendre les mêmes options, notamment le “proxy_buffering” pour permettre les “server-Sent events” vers le serveur Constellation.

Dans le cas présent Nginx va « proxifer » les requêtes vers http://localhost:8088, c’est à dire au service Constellation (port 8088) installé sur le même serveur (localhost).

Tapez ensuite sur la combinaison de touches “Ctrl+X” pour quitter en prenant suivant d’enregistrer le fichier. Puis, pour activer cette configuration, créez le lien symbolique suivant :

sudo ln -s /etc/nginx/sites-available/constellation  /etc/nginx/sites-enabled/constellation

Avant de redémarrer Nginx, éditez le fichier de configuration global pour augmenter la taille maximale des requêtes entrantes afin de pouvoir uploader des packages Constellation sur le serveur (par défaut cette taille est fixée à 1Mo, autrement dit vous obtiendrez une erreur 413 « Request Entity Too Large » si vous tentez d’uploader un package de plus de 1Mo).

sudo nano /etc/nginx/nginx.conf

Sous la section « http », ajoutez l’option « client_max_body_size » (ou si l’option existe déjà, modifiez sa valeur) que nous fixerons à 100 Méga :

client_max_body_size 100M;

Pour finir, rechargez Nginx afin prendre en compte notre nouvelle configuration :

sudo systemctl reload nginx

Votre Constellation est maintenant accessible derrière Nginx sur le port 80.

Rendez-vous donc sur l’adresse http://<votre_nom_dns> (sans spécifier le port, car 80 par défaut) pour vérifier que le reverse proxy est opérationnel. Dans le cas présent http://demo.internal.myconstellation.io

Ce n’est donc plus Constellation qui répond mais notre serveur Nginx qui lui même communique avec le serveur Constellation local.

Donc pour résumer, sur le port 80 c’est le serveur Nginx qui répond en transférant au serveur Constellation sur le port 8088.

Note : si vous êtes dernière un routeur avec du NAT, n’oubliez pas d’ajouter la redirection du port 80 vers votre serveur Constellation interne. Par la même occasion vous pouvez supprimer la redirection du port 8088, ainsi tout passera nécessairement par Nginx.

Activer le HTTPS avec des certificats SSL Let’s Encrypt

Maintenant que votre service Constellation est exposé dernière le serveur Nginx vous allez pouvoir configurer différentes choses sur Nginx comme par exemple des restrictions d’accès , l’authentification, des limites (throttling) et bien d’autre chose. Dans le cas présent on va s’intéresser au support du SSL.

Pour activer le HTTPS, il vous faut un certificat SSL. Pour simplifier la démarche, Let’s Encrypt est une autorité de certification lancée en 2015 qui permet d’automatiser la génération de certificat. De plus le service est gratuit ! Les certificats sont valides trois mois, il faudra donc régulièrement les renouveler mais vous allez voir que cette action est entièrement automatisable.

Ici nous allons utiliser Certbot, un agent installé sur le serveur qui permet de générer et renouveler automatiquement les certificats SSL Let’s Encrypt.

Commencez par ajouter le repository suivant :

sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update

Ensuite installez Certbot pour Nginx :

sudo apt-get install python-certbot-nginx

Une fois installé, lancez la commande “certbot –nginx” en spécifiant le nom DNS vers votre serveur. Dans le cas présent :

sudo certbot --nginx -d demo.internal.myconstellation.io

L’assistant vous demandera tout d’abord votre adresse mail :

Après avoir accepté les conditions du service, l’assistant va automatiquement valider un challenge en interrogeant votre site Web (d’où la nécessité d’avoir exposé correctement votre serveur sur Internet avec le nom DNS spécifié), créer le certificat SSL et l’ajouter dans votre configuration Nginx.

Pour finir l’assistant vous proposera de modifier automatiquement la configuration de votre Nginx pour rediriger tous les appels HTTP (port 80) vers HTTPS (port 443).

Choisissiez l’option 2 pour activer cette redirection.

Et voilà, votre serveur Nginx est configuré avec le certificat SSL généré par Let’s Encrypt et toutes les requêtes seront redirigés en HTTPS et donc chiffrés !

Votre Constellation est maintenant protégée !

Rechargez la page dans votre navigateur (F5) sur l’URL http://<mon_nom_dns> vous constaterez la redirection automatique en https:// et le cadenas vert vous informant du chiffrement SSL :

(Note : pour les personnes derrières un NAT, n’oubliez pas non plus d’ajouter la redirection du port 443 vers votre serveur Nginx interne)

Pour vérifier le bon renouvellement du certificat vous pouvez utiliser la commande suivante :

sudo certbot renew --dry-run

Certbot a automatiquement installé un trigger dans systemd (ou crontab selon le système) pour réaliser le renouvellement et déploiement automatique de vos certificats avant leurs expirations.

Pour les plus curieux, vous pouvez jeter un œil dans le fichier “/etc/nginx/sites-available/constellation” pour voir les modifications apportées par Certbot.

Pour aller plus loin

Sécuriser le serveur avec un firewall UFW et fail2ban

Installer fail2ban

Fail2ban est un script tournant en tâche de fond qui va vérifier si les tentatives d’authentification SSH et Nginx; et en cas d’attaque, bannir l’IP grâce à iptables.

sudo apt-get install fail2ban

Pour plus d’info:  https://www.digitalocean.com/community/tutorials/how-to-protect-an-nginx-server-with-fail2ban-on-ubuntu-14-04

Installer UFW

UFW est un firewall applicatif. Pour l’installer :

sudo apt-get install ufw

Autorisez ensuite les services HTTP (nécessaire pour le challenge Let’s Encrypt), HTTPS (notre reverse proxy Nginx vers Constellation) et SSH :

sudo ufw allow http
sudo ufw allow https
sudo ufw allow ssh

Pour l’activer :

sudo ufw enable

Votre serveur Linux ne répondra plus que sur les ports 22 (ssh), 80 (http), 443 (https) en IPv4 et IPv6.

sebastien@ubuntu:~$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere
22                         ALLOW       Anywhere
80 (v6)                    ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)
22 (v6)                    ALLOW       Anywhere (v6)

Vous noterez que le port 8088 n’est maintenant plus accessible car bloqué par le firewall UFW. Il faudra forcement se connecter à Constellation via Nginx en HTTPS. N’oubliez pas alors de modifier l’URI de votre Constellation sur vos sentinelles existantes pour prendre en compte ce changement.

Ajouter d’autre application Web dernière votre reverse proxy SSL

Jusqu’au présent vous avez configuré un nom DNS type “demo.internal.myconstellation.io” qui pointe vers votre serveur Linux sur lequel le service Nginx répond en HTTP (80) et HTTPS (443) avec un certificat Let’s Encrypt pour “proxifier” les requêtes vers le service Constellation accessible localement sur le port 8088.

Vos utilisateurs se connectent donc forcement en HTTPS sur le reverse proxy pour accéder à Constellation !

La règle configurée dans Ngnix “proxifie” toutes les requêtes à partir de la racine « / » vers Constellation :

location / {
        proxy_pass http://localhost:8088;
....
}

Mais il est également possible d’adapter cette règle pour que votre reverse proxy ne soit plus exclusivement un passe-plat pour Constellation mais aussi pour vos autres services internes (une box domotique, un serveur Web, un objet connecté, une camera IP, etc…).

Vous aurez ainsi la possibilité d’exposer différents services Web internes dernière votre reverse proxy profitant d’un même port TCP (le 443) et donc d’un même canal de communication sécurisé (par le cryptage SSL).

Parmi les différentes options pour ce type de configuration :

1. Reverse proxy en fonction du “server_name”
2. Reverse proxy en fonction de la “location”

Reverse Proxy en fonction du server_name

Le principe est de rejouer ce tutoriel depuis le début pour chacune de vos applications à exposer.

Vous devrez ainsi créer une adresse DNS vers votre IP public pour chaque site, créer une configuration Nginx en changeant le « server_name » et « proxy_pass » vers la ressource interne à exposer et créer un certificat SSL avec Certbot pour tous vos sites créés.

Vous aurez ainsi une multitude de nom DNS qui pointerons tous vers votre serveur Nginx qui lui redirigera vers les ressources internes en fonction du « server_name ». Par exemple “constellation.mondomaine.fr”, “macamera.mondomaine.fr”, “jeedom.mondomaine.fr”, etc.. etc..

La configuration est simple car il s’agit de répéter ce tutoriel pour chaque service, par contre l’administration est un peu lourde et vous aurez autant de sous domaine et donc de certificat que de service à exposer.

Reverse Proxy en fonction de la “location”

Dans ce mode, nous gardons un seul site Nginx (celui configuré dans le fichier /etc/nginx/sites-available/constellation) et donc un seul nom de domaine (ici demo.internal.myconstellation.io) avec son certificat associé.

Cependant au lieu de “rediriger” les requêtes depuis la racine « / » vers Constellation nous allons créer plusieurs “location”.

Prenons un exemple pour bien comprendre. Ici le serveur Ngnix est installé sur la même que le serveur Constellation, donc localhost. Imaginons que dans ce même réseau LAN, j’ai par exemple un serveur ZoneMinder qui répond sur 192.168.0.10 et une box Jeedom sur 192.168.0.11.

Je pourrais éditer la configuration Nginx de cette façon :

location /constellation/ {
        proxy_pass http://localhost:8088/constellation/;

        proxy_set_header Host $host;
        proxy_set_header Connection "";
        proxy_http_version 1.1;

        proxy_buffering off;
        proxy_cache off;
        proxy_connect_timeout 30;
        proxy_send_timeout 30;
    }
    
    
location /zm/ {
        proxy_pass http://192.168.0.10/zm/;

        proxy_set_header Host $host;
        proxy_set_header Connection "";
        proxy_http_version 1.1;
    }
    
location /jeedom/ {
        proxy_pass http://192.168.0.11;

        proxy_set_header Host $host;
        proxy_set_header Connection "";
        proxy_http_version 1.1;
    }

Ainsi, en fonction du “path” demandé, un service différent me répondra :

• https://<mon_nom_DNS>/constellation : réponse du serveur Constellation
• https://<mon_nom_DNS>/zm  : réponse du serveur ZoneMinder
• https://<mon_nom_DNS>/jeedom : réponse du serveur Jeedom

Attention : si le serveur Constellation répond sur un “sous path”, comme ici “/constellation” il faut également modifier la configuration du serveur Constellation pour l’informer.

Pour cela modifiez le ficher “/opt/constellation-server/Constellation.Server.exe.config” :

sudo nano /opt/constellation-server/Constellation.Server.exe.config

Et modifier le listenUri pour reprendre la même structure d’URI, ici en ajoutant “/constellation” :

<listenUris>
    <uri listenUri="http://+:8088/constellation" />
</listenUris>

Pour finir, il faudra relancer le service Constellation pour prendre en compte ce changement :

sudo supervisorctl restart constellation-server

Voilà votre Constellation répond maintenant sur le /constellation, dans notre cas https://demo.internal.myconstellation.io/constellation :

Si maintenant on change le path pour “/zm” soit ici https://demo.internal.myconstellation.io/zm, c’est notre serveur ZoneMinder qui répondra :

On a donc un seul serveur en frontal, Ngnix qui écoute en HTTPS avec le certificat Let’s Encrypt pour sécuriser TOUS les échanges et qui, selon le “path” demandé, transféra les requêtes vers les différents services internes de votre réseau.

A noter que vous pouvez également utiliser des expressions régulières (regex) pour définir vos “locations”. Pour plus d’information : https://www.scalescale.com/tips/nginx/nginx-location-directive/

The post Exposer Constellation en HTTPS derrière un reverse proxy avec Nginx et Let’s Encrypt appeared first on Constellation.

Nous allons voir ici comment configurer un serveur Microsoft IIS en tant que reverse proxy pour Constellation. Vous pouvez également réaliser le reverse proxy avec nginx notamment si vous êtes sur un système Linux.

Etape 1 : installer ARR et URL Rewrite

Pour commencer, en utilisant le “Web Platform Installer”, installez :

• Application Request Routing 3.0
• URL Rewrite 2.0

Etape 2 : créer un site Web IIS

Toujours depuis la Console IIS, créez un site web IIS. Configurez le binding et les autres options de votre choix (port d’écoute, SSL ou non, authentification, restriction d’IP, filtrage, etc..).

C’est ce site Web IIS qui devra être exposé sur Internet et qui sera le point d’entrée vers votre Constellation.

Etape 3 : configurer la règle de reverse proxy

Créez le fichier “web.config” dans le répertoire de votre site Web créé à l’étape précédente avec le contenu suivant :

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <clear />
                <rule name="Constellation on my private server" stopProcessing="true">
                    <match url="^constellation/(.*)" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
                    <action type="Rewrite" url="http://myprivateserver.mynetwork.lan:8088/{R:1}" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Dans cet exemple toutes requêtes qui commence par “constellation/” seront “rewritées” vers le serveur local “myprivateserver.mynetwork.lan:8888”.

Etape 4 : activer le HTTPS

Vous pouvez depuis le gestionnaire IIS ajouter des certificat SSL pour activer le HTTPS sur votre site IIS et donc exposer votre Constellation dans un canal sécurisé.

Pour utiliser des certificats SSL Let’s Encrypt, téléchargez et installez Certify SSL Manager. Vous pourrez alors ajouter un certificat SSL en quelques clics à votre site IIS avec gestion automatique du renouvellement.

The post Exposer Constellation en HTTPS derrière un reverse proxy avec IIS et Let’s Encrypt appeared first on Constellation.

Vous pourrez alors exploiter ces indicateurs de performance avec des outils de supervision tel quel New Relic, Nagios, Cacti, dotcom-monitor, Applications Manager, ou plus simplement en utilisant la MMC “Analyseur de Performances” de Windows.

Vous pouvez également développer vos propres applications pour suivre les indicateurs de performance de votre serveur Constellation étant donné que ces compteurs Windows sont exposés en WMI (voir la documentation). Pour les développeurs .NET, la classe PerformanceCounter vous permettra d’interroger ces compteurs très facilement.

Pour finir, vous trouverez dans le catalogue de package gratuit, le package PerfCounter qui permet de publier en temps réel des compteurs de performance Windows en tant que StateObject. Autrement dit vous pouvez suivre l’activité et les performances de votre Constellation via des StateObjects de votre Constellation.

Activer les compteurs de performance

Pour activer les compteurs de performance, vous devez manuellement éditer le serveur de configuration pour ajouter la section et la clé de configuration suivante :

<appSettings>
  <add key="EnablePerformanceCounters" value="true" />
</appSettings>

Vous pouvez éditer ce fichier depuis la Console Constellation, depuis le SDK ou directement sur votre serveur avec votre éditeur favori.

Comme il s’agit d’une modification de bas niveau, vous devez nécessairement redémarrer le service Constellation :

• Soit via la MMC “Services” :

• Soit en ligne de commande :

net stop ConstellationServer && net start ConstellationServer

Vous pourrez ensuite suivre les indicateurs de performance de votre Constellation avec un outil de supervision, l’analyseur de performances de Windows ou même développer vos propres outils en exploitant l’API PerformanceCounter sous .NET ou WMI.

Utiliser l’analyseur de performances Windows

Dans les outils d’administration Windows, lancez la MMC “Analyseur de Performances” et cliquer sur le bouton “Ajouter” dans la toolbar.

Tous les compteurs Constellation sont disponibles dans la catégories “Constellation Server” puis sélectionnez le ou les compteurs à suivre :

A noter que cette fonctionnalité n’est disponible que sur un environnement Windows, la plateforme Linux n’ayant pas d’équivalent.

Utiliser le package PerfCounter

Le package PerfCounter permet de suivre des compteurs de performance Windows et de les injecter en tant que StateObject dans Constellation. Il est donc possible suivre l’activité et les performances de votre Constellation via des StateObjects de votre Constellation.

Pour plus d’information sur ce package et son utilisation : https://developer.myconstellation.io/package-library/perfcounter/ 

Ci-dessous la définition des compteurs de performance publiés Constellation pour le package PerfCounter :

<!-- Constellation Server / StateObjects provider -->
<perfCounter id="ConstellationPushStateObject" categoryName="Constellation Server" counterName="# PushStateObject / sec" instanceName="default" />
<perfCounter id="ConstellationPushStateObjectCount" categoryName="Constellation Server" counterName="Total PushStateObject" instanceName="default" />
<perfCounter id="ConstellationUpdateStateObject" categoryName="Constellation Server" counterName="# UpdateStateObject / sec" instanceName="default" />
<perfCounter id="ConstellationUpdateStateObjectCount" categoryName="Constellation Server" counterName="Total UpdateStateObject" instanceName="default" />
<perfCounter id="ConstellationRequestStateObjects" categoryName="Constellation Server" counterName="# RequestStateObjects /sec" instanceName="default" />
<perfCounter id="ConstellationRequestStateObjectsCount" categoryName="Constellation Server" counterName="Total RequestStateObjects" instanceName="default" />
<perfCounter id="ConstellationSubscribeStateObjects" categoryName="Constellation Server" counterName="# SubscribeStateObjects / sec" instanceName="default" />
<perfCounter id="ConstellationSubscribeStateObjectsCount" categoryName="Constellation Server" counterName="Total SubscribeStateObjects" instanceName="default" />
<perfCounter id="ConstellationStateObjectsCount" categoryName="Constellation Server" counterName="Current StateObjects Count" instanceName="default" />
<perfCounter id="ConstellationStateObjectSubscriptionCount" categoryName="Constellation Server" counterName="Current StateObject Subscriptions" instanceName="default" />
<!-- Constellation Server / Messaging -->
<perfCounter id="ConstellationSendMessage" categoryName="Constellation Server" counterName="# SendMessage / sec" instanceName="default" />
<perfCounter id="ConstellationSendMessageCount" categoryName="Constellation Server" counterName="Total SendMessage" instanceName="default" />
<perfCounter id="ConstellationReceiveMessage" categoryName="Constellation Server" counterName="# ReceiveMessage / sec" instanceName="default" />
<perfCounter id="ConstellationReceiveMessageCount" categoryName="Constellation Server" counterName="Total ReceiveMessage" instanceName="default" />
<!-- Constellation Server / Logging -->
<perfCounter id="ConstellationWriteLog" categoryName="Constellation Server" counterName="# WriteLog / sec" instanceName="default" />
<perfCounter id="ConstellationWriteLogCount" categoryName="Constellation Server" counterName="Total WriteLog" instanceName="default" />
<!-- Constellation Server / Packages -->
<perfCounter id="ConstellationPackageConnections" categoryName="Constellation Server" counterName="Total Package connections" instanceName="default" />
<perfCounter id="ConstellationPackageDisconnections" categoryName="Constellation Server" counterName="Total Package disconnections" instanceName="default" />
<perfCounter id="ConstellationPackagesConnected" categoryName="Constellation Server" counterName="Current Packages connected" instanceName="default" />
<!-- Constellation Server / Sentinels -->
<perfCounter id="ConstellationSentinelConnections" categoryName="Constellation Server" counterName="Total Sentinel connections" instanceName="default" />
<perfCounter id="ConstellationSentinelDisconnections" categoryName="Constellation Server" counterName="Total Sentinel disconnections" instanceName="default" />
<perfCounter id="ConstellationSentinelsConnected" categoryName="Constellation Server" counterName="Current Sentinels connected" instanceName="default" />
<!-- Constellation Server / Consumers -->
<perfCounter id="ConstellationConsumerConnections" categoryName="Constellation Server" counterName="Total Consumers connections" instanceName="default" />
<perfCounter id="ConstellationConsumerDisconnections" categoryName="Constellation Server" counterName="Total Consumers disconnections" instanceName="default" />
<perfCounter id="ConstellationConsumerConnected" categoryName="Constellation Server" counterName="Current Consumers connected" instanceName="default" />
<!-- Constellation Server / API REST -->
<perfCounter id="ConstellationWebApiSubscriptionCount" categoryName="Constellation Server" counterName="Current subscriptions (HTTP REST API)" instanceName="default" />
<perfCounter id="ConstellationWebApiRequestInProcess" categoryName="Constellation Server" counterName="Current long-polling requests (HTTP REST API)" instanceName="default" />

The post Surveiller et monitorer les indicateurs de performance du serveur Constellation appeared first on Constellation.