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 retrouvez aussi ce bouton dans le menu contextuel (clique-droit) sur un projet Constellation:

Par défaut, Visual Studio ouvrira le fichier de configuration du serveur Constellation enregistré si il n’y en a qu’un. Autrement un fenêtre vous invitera à sélectionner le serveur Constellation à utiliser :

Pour gérer les serveurs Constellation dans Visual Studio, consultez cet article.

Une fois la configuration de votre serveur Constellation ouverte dans Visual Studio, vous pouvez l’éditer comme bon vous semble :

Vous disposerez de l’auto-complétion et de la validation du schéma de votre configuration :

Lorsque vous enregistrez ce fichier, Visual Studio vous proposera d’uploader le fichier modifié sur votre Constellation :

Vous pourrez également ordonner le rechargement de votre nouvelle configuration sur votre serveur :

Ici, si vous ouvrez la Console Constellation vous pourrez observer vos modifications :

The post Editer la configuration Constellation depuis Visual Studio appeared first on Constellation.

Pour chaque package (réel) vous avez en temps réel :

• Le statut :
  • Starting : package en cours de démarrage
  • Started : package démarré et en cours de fonctionnement
  • Stopping : package en cours d’arrêt
  • Stopped : package arrêté
• L’état de connexion qui indique si le package est bien connecté au serveur
• La date de la dernière activité (il s’agit de la date de la dernière modification du statut)
• La consommation en CPU et RAM sur la sentinelle sur lequel le package est démarré
• Des informations quant à la version du package et de la librairie Constellation utilisée par le package

En fonction de l’état du package le bouton d’action permettra de démarrer le package (Start) et de l’arrêter (Stop).

Comme sur les autres pages de la Console, vous avez un menu contextuel pour chaque package vous permettant de contrôler le package, d’éditer sa configuration ou ses settings, etc.

La fenêtre d’information permet de retrouver toutes les informations sur le statut du package :

Notez également que vous avez la possibilité de filtrer dans la liste des packages soit avec la zone de texte ou soit en cliquant sur le bouton “Show filters” afin de filtrer le type de package (réel ou virtuel), l’état de connexion (connecté ou non) et l’état activé/désactivé. Par défaut tous les packages sont affichés à l’exception des packages marqués “Désactivé” (Enable=false).

Contrôler un package

Pour pouvez pour chaque package le démarrer ou l’arrêter avec le bouton d’action sur la droite ou depuis le menu contextuel.

Vous pouvez également redémarrer le package (restart) c’est à dire demander à la sentinelle de stopper le package (si il est “Started”)  puis de le démarrer.

Vous pouvez aussi faire un rechargement du package : “reload”. Cette action fonctionne comme un “restart” mais force la sentinelle à (re)télécharger le package du “Package Repository” du serveur. Cela permet de déployer les mises à jours de vos packages : vous envoyez la nouvelle version de votre package sur votre serveur Constellation puis vous faites un “reload” afin de reforcer les sentinelles à redémarrer le package avec sa nouvelle version.

Pour finir vous pouvez également “pousser” les settings vers un package en cas de modification (sans avoir à redémarrer le package).

Editer la configuration d’un package

Pour chaque package (réel ou virtuel) vous pouvez saisir le nom de l’instance (seulement lors de la création) et le credential utilisé pour la connexion du package. Vous pouvez également définir si le package est activé ou non.

S’il s’agit d’un package réel, vous pouvez définir si le package doit démarré automatiquement lorsque la sentinelle se démarre et vous pouvez également redéfinir les options de récupération :

Editer les settings d’un package

Il s’agit des paramètres propre au package (voir ici).

Pour chaque package vous définir autant de variable de configuration (= une clé et une valeur) que vous désirez en cliquant sur le bouton “Add new setting” :

Dans le cas d’un package dit “réel” il est grandement recommandé de déclarer les settings utilisés par le package dans son manifeste : voir ici.

Cette déclaration permet à la Console Constellation de connaitre les settings obligatoires ou non, le type de chaque setting, la description et valeur par défaut.

Editer les groupes d’un package

Pour rappel, un message peut être envoyé à un (ou plusieurs) groupe qui regroupe des packages ou des consommateurs. Chaque package ou consommateur peut joindre un groupe depuis les API mais vous pouvez également définir ces liens d’appartenance au niveau de la configuration du serveur.

Pour cela, cliquez sur “Group membership” dans le menu contextuel d’un page et définissez les groupes dont fait partie votre package :

Déployer un package

Pour déployer un package, vous avez plusieurs solutions :

• Cliquez sur le bouton “Deploy new package” depuis la page “Packages”
• Cliquez sur le bouton “Deploy new package” dans le menu contextuel d’une sentinelle sur la page « Sentinels »
• Utiliser la page “Package Repository”

Depuis la page des Packages, cliquez sur le bouton “Deploy new package” en haut à gauche  :

Vous obtiendrez alors une pop-in vous permettant de sélectionner la sentinelle sur laquelle déployer et le package à déployer :

S’il s’agit d’un page virtuel, sélectionnez “Virtual package” (voir ci-dessous) sinon sélectionner un package présent dans votre “Package repository”.

Vous serez alors guidé dans les étapes de configuration du package.

Note : par défaut le champ “Package file” est nul, c’est à dire que le fichier à utiliser pour votre instance sera déterminé dynamiquement (lire ici).

Dans le cas où une instance est déjà présente sur la sentinelle vous serez obligé de définir un autre nom et donc de spécifier le “Package file”.

Par exemple, ici je pourrais nommer cette nouvelle instance “HWMonitor2” en utilisant le fichier “HWMonitor”.

Veuillez lire ceci pour bien comprendre le mécanisme de résolution.

Les packages virtuels

Comme expliqué ici, un package virtuel n’est pas réel dans le sens où ce n’est pas un processus lancé et supervisé par une sentinelle.

De ce fait, dans la Console, vous n’aurez aucun information remontée à son sujet.

Vous pouvez seulement les déclarer ou supprimer, les associer à des credenitals, gérer l’appartenance aux groupes ou bien sûr gérer les settings.

The post Gérer les packages avec la Console Constellation appeared first on Constellation.

Pour plus d’information sur le fichier de configuration, n’hésitez pas à lire ou relire cet article.

Vous pouvez mettre l’éditeur en plein écran avec le bouton F11.

L’éditeur dispose d’un système d’auto-complétion assez simple sur base du schéma du fichier de configuration :

Vous trouverez sur l’éditeur trois boutons :

• Get Config : permettant d’ouvrir la dernière version du serveur
• Save Config : permettant d’enregistrer la configuration en cours d’édition sur le serveur (raccourci : Ctrl+S)
• Save & Deploy : permettant d’enregistrer la configuration en cours d’édition sur le serveur puis d’appliquer (déployer) la configuration dans la Constellation

Le fait de déployer la configuration informe tous les packages et les sentinelles de votre Constellation de la nouvelle configuration. C’est en déployant la configuration que les sentinelles vont déployer les nouveaux packages ajoutés ou au contraire fermer les packages supprimés, etc.

The post Le Configuration Editor appeared first on Constellation.

Il héberge des hubs et des interfaces HTTP/REST. De plus il peut également héberger des fichiers statiques en configurant le “fileServer” ce qui permet par exemple l’auto-hébergement de la console Constellation (plus d’info ici).

Les hubs Constellation sont basés sur la technologie SignalR permettant d’exposer des canaux de communication bi-directionnels et temps réel en HTTP long-polling, server-event ou WebSocket en fonction des capacités du client.

Les interfaces HTTP/REST sont en fait des contrôleurs WebAPI exposant des méthodes en HTTP/REST. Les interfaces HTTP/REST permettent d’exposer des fonctionnalités de Constellation de manière très simple pour les devices ou frameworks ne pouvant supporter SignalR.

Il existe 4 hubs :

• Constellation
• Consumer
• Controller
• Sentinel

Ainsi que 3 interfaces HTTP/REST :

• Constellation
• Consumer
• Management

Le hub et l’interface HTTP “Constellation” sont utilisés par les packages Constellation (réels ou virtuels). Ils exposent des méthodes pour écrire des logs, pour récupérer les settings, pour publier ou interroger des StateObjects, envoyer ou recevoir des messages, etc…

Le hub et l’interface HTTP “Consumer” sont utilisés par les “consommateurs”. Par exemple une page Web est un consommateur, c’est à dire qu’elle se connecte à Constellation pour interroger des StateObjects ou envoyer/recevoir des messages mais elle n’est pas un package (son cycle de vie est lié au navigateur du client). Un “consommateur” ne peut pas produire des logs, avoir de settings ou encore publier des StateObjects.

Le hub “Controller” expose des méthodes pour contrôler la Constellation comme arrêter/démarrer des packages, s’abonner et récupérer en temps réel les logs des packages de la Constellation, propager les changements de configuration dans la Constellation, suivre les états et consommation des ressources des packages, etc… Ce hub est notamment utilisé par la Console Constellation pour vous fournir une interface de pilotage de votre Constellation. Pour pouvez également vous connecter et exploiter les fonctionnalités de contrôle de vos pages Web ou packages .NET.

Le hub “Sentinel” est un hub privé réservé aux sentinelles de la Constellation. C’est sur ce hub que les sentinelles s’enregistrent, remontent les états des packages qu’elles supervisent, etc…

Enfin l’interface HTTP “Management” aussi nommée “Management API” est une API HTTP/REST de management du serveur permettant la gestion des sentinelles, des packages, des settings, des credentials, etc… Cette API est notamment utilisée par la Console Constellation pour vous fournir une interface d’administration de votre Constellation.

The post Les différents hubs et interfaces REST du serveur Constellation appeared first on Constellation.

Concrètement un package est un fichier ZIP qui contient un exécutable (exe) qui sera exécuté et supervisé par une sentinelle.

Sentinel + Package = Instance de package

Par défaut, Constellation va utiliser le package dont le nom est celui de l’instance que vous déclarez dans la configuration.

Par exemple, pour déployer le package “HWMonitor” sur la sentinelle nommée “SENTINEL-DEMO”, on écrira dans le fichier de configuration :

<sentinel name="SENTINEL-DEMO" credential="Standard">
    <packages>    
      <package name="HWMonitor"></package>
    </packages>
</sentinel>

L’attribut “name” du package est le nom de l’instance du package. On parlera alors de l’instance “SENTINEL-DEMO/HWMonitor” pour identifier de manière unique l’instance de ce package dans une Constellation.

Lors du déploiement, Constellation va analyser chaque package dans son repository pour récupérer celui dont le nom déclaré son manifeste correspond au nom de notre instance.

Dans le cas où il ne trouve aucun package dont le manifeste déclare le nom de package recherché, il va tenter de sélectionner le package à partir du fichier “<nom d’instance>.zip”. Si ce fichier n’existe pas alors une erreur sera levée dans les logs de la Constellation.

Dans notre cas, Constellation va analyser chaque package de son repository (c’est à dire chaque fichier .ZIP) pour récupérer celui qui a dans son manifeste (PackageInfo.xml) déclaré la propriété “Name” à “HWMonitor”. Si il ne le trouve pas, il va tenter de récupérer le package par le nom de fichier “HWMonitor.zip”.

Versioning des packages

En plus du nom du package, le manifeste (PackageInfo.xml) déclare également d’autre information comme la version du package.

Le “Package Repository” d’un serveur Constellation peut donc contenir plusieurs versions d’un même package.

Par exemple, imaginez les packages suivants stockés dans le “Package Repository” de votre serveur Constellation :

• HWMonitor.zip (avec dans le manifeste: Name=”HWMonitor” et Version=”1.0”)
• HWMonitor-1.1.zip (avec dans le manifeste: Name=”HWMonitor” et Version=”1.1”)
• HWMonitor-1.2.zip (avec dans le manifeste: Name=”HWMonitor” et Version=”1.2”)

Note : la nomenclature des noms des fichiers dans le repository n’a aucune importance.

Si dans votre fichier de configuration vous déclarez simplement la ligne suivante :

<package name="HWMonitor"></package>

Constellation trouvera donc 3 packages qui correspondent (car l’attribut name=”HWMonitor” dans les trois packages). Dans ce cas, le serveur Constellation va sélectionner le package dont la version est la plus haute.

Ainsi dans cet exemple, c’est le package “HWMonitor-1.2.zip” qui sera déployé sur la sentinelle pour l’instance “HWMonitor”.

Résolution explicite du fichier d’un package

Jusqu’à présent la règle est donc d’utiliser le fichier dont le nom du package (d’après son manifeste) correspond au nom de l’instance déclarée (package “HWMonitor <> instance “HWMonitor”) et si plusieurs fichiers correspondent on sélectionne la version la plus haute. A contrario, si aucun fichier n’est trouvé, on tente d’utiliser le fichier “<nom d’instance>.zip”.

C’est donc une résolution “implicite” du fichier du package qui est réalisée par le serveur Constellation.

Toutefois il est possible de contourner ce comportement et de définir explicitement le fichier d’un package à utiliser grâce à l’attribut “filename”.

Si dans votre fichier de configuration vous déclarez la ligne suivante :

<package name="HWMonitor" filename="HWMonitor-1.1.zip"></package>

Vous définissez explicitement que cette instance nommée “HWMonitor” utilisera le package contenu dans le fichier “HWMonitor-1.1.zip”. On peut donc forcer l’utilisation d’une version spécifique en déclarant explicitement le fichier à utiliser pour une instance d’un package.

On aurait aussi pu écrire :

<package name="HWMonitor" filename="DemoPackage.zip"></package>

C’est à dire qu’on déclare une instance d’un package nommée “HWMonitor” utilisant le package contenu dans le fichier “DemoPackage.zip”, ce qui n’a pas de sens mais est tout à fait possible !

Ainsi pour résumer, Constellation utilise donc en priorité le fichier défini par l’attribut “filename”. Dans le cas contraire on applique la règle implicite définie précédement.

Instances multiples d’un même package

Avec cet attribut “filename” il devient possible de déployer plusieurs instances d’un même package sur une même sentinelle tant que le nom d’instance est différent.

Prenez la configuration suivante :

<sentinel name="SENTINEL-DEMO" credential="Standard">
    <packages>    
      <package name="HWMonitor1" filename="HWMonitor.zip"></package>
      <package name="HWMonitor2" filename="HWMonitor.zip"></package>
   </packages>
</sentinel>

Dans cet exemple, on a deux instances du package “HWMonitor.zip” qui seront déployées sur “SENTINEL-DEMO”.

Ces instances “SENTINEL-DEMO/HWMonitor1” et “SENTINEL-DEMO/HWMonitor2” sont deux instances différentes dans votre Constellation et peuvent avoir des configuration (settings) différentes mais elles sont basées sur le même code, car elles partagent la même source (le package “HWMonitor.zip”).

Vous pouvez donc déployer le même package plusieurs fois sur une même sentinelle en déclarant plusieurs instances (name) du même package (filename).

Résolution semi-implicite / semi-explicite d’un package

Le problème des instances multiples est que vous déclarez explicitement le fichier (filename) à utiliser.

Dans l’exemple précèdent “SENTINEL-DEMO/HWMonitor1” et “SENTINEL-DEMO/HWMonitor2” sont des instances du même package “HWMonitor.zip” qui d’après les exemples précédents correspond à la version “1.0” du package “HWMonitor”.

Toujours d’après les exemples précédents, on dispose également de la version 1.1 et 1.2 de ce package dans le « Package Repository »  (fichiers HWMonitor-1.1.zip et HWMonitor-1.2.zip).

Pour mettre à jour ces deux instances (“SENTINEL-DEMO/HWMonitor1” et “SENTINEL-DEMO/HWMonitor2”) vers une version plus récente, disons la version 1.2, il faudra modifier à la fois l’attribut “filename” de l’instance “HWMonitor1” mais également celui de l’instance de “HWMonitor2”.

Ce qui revient à écrire :

<sentinel name="SENTINEL-DEMO" credential="Standard">
    <packages>    
      <package name="HWMonitor1" filename="HWMonitor-1.2.zip"></package>
      <package name="HWMonitor2" filename="HWMonitor-1.2.zip"></package>
   </packages>
</sentinel>

Pour éviter cela, il y a un “mode intermédiaire” qu’on pourrait nommer résolution “semi-implicite” ou “semi-explicite” car il s’agit d’un mixte de ces deux modes !

Pour l’utiliser, il suffit d’omettre l’extension “.zip” dans l’attribut “filename”.

Dans notre exemple, déclarez simplement :

<sentinel name="SENTINEL-DEMO" credential="Standard">
    <packages>    
      <package name="HWMonitor1" filename="HWMonitor"></package>
      <package name="HWMonitor2" filename="HWMonitor"></package>
   </packages>
</sentinel>

On a toujours deux instances “HWMonitor1” et “HWMonitor2” et ces deux instances déclarent le “filename” à “HWMonitor”.

Sans l’extension “.zip”, “HWMonitor” ne correspond à aucun fichier de notre repository et c’est donc là que Constellation réalise une résolution partielle : semi-explicite / semi-implicite.

Cette résolution partielle sélectionne la dernière version du package qui porte le nom déclaré dans attribut “filename” (ici nommé “HWMonitor”).

Ainsi en ajoutant la version 1.3 du package “HWMonitor” dans notre repository, les deux instances seront mises à jour avec la version 1.3 de ce package sans avoir besoin de modifier la configuration de notre Constellation.

Pour résumer

• Un package déployé sur une sentinelle est une instance de package (couple Sentinelle/Package)
• Chaque instance a son propre cycle de vie, sa propre configuration et sa propre identité dans la Constellation
• Il n’y a pas de lien entre le nom du package et le nom de l’instance du package, vous pouvez nommer vos instances sans restriction à partir du moment où elles sont uniques pour une même sentinelle
• Vous pouvez avoir plusieurs instances d’un même package sur une même sentinelle
• Vous pouvez également avoir plusieurs instances de versions différentes d’un même package sur une même sentinelle
• Les packages (fichiers ZIP) sont tous stockés dans le “Package Repository” du serveur
• Pour résoudre le package à utiliser pour une instance :
  1. Si l’attribut “filename” est défini :
     1. Et qu’il correspond à un fichier du “Package Repository”, c’est ce package qui sera utilisé pour l’instance du package
     2. Sinon, sans extension .ZIP, on utilise la version la plus haute du package dont le nom (déclaré dans le manifeste) est celui déclaré dans l’attribut “filename”
  2. Sinon, sans l’attribut “filename” :
     1. On utilise la version la plus haute du package dont le nom (déclaré dans le manifeste) est celui déclaré dans l’attribut “name” (c’est à dire le nom de l’instance du package)
     2. Sinon on utilise le package qui se nomme <name>.zip si ce fichier existe dans le “Package Repository”
     3. Sinon une erreur est levée

The post Instance de package, package, versioning, multi-instances et résolution des packages appeared first on 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

Généralités

Construction de l’URL

L’URL est :  <Root URI>/rest/management/<action>?<paramètres>

Partons du principe que votre Constellation est exposée en HTTP sur le port 8088 (sans path). On retrouvera dans le fichier de configuration la section suivante :

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

La “Root URI “ est donc “http://<ip ou dns>:8088/”.

Par exemple si nous sommes en local, nous pourrions écrire :

http://localhost:8088/rest/management/xxxxx

Authentification

Comme pour toutes les requêtes vers Constellation vous devez impérativement spécifier dans les headers HTTP ou dans les paramètres de l’URL (querystring), les paramètres “SentinelName”, “PackageName” et “AccessKey” pour l’authentification.

Dans le cas de l’API “Management”, la “SentinelName” est “Management” et le “PackageName” est le nom de votre choix que l’on considère comme un “FriendlyName”. Typiquement le “FriendlyName” est par exemple le nom de l’application/page qui se connecte.

L’AccessKey doit bien sûr être déclaré et activé sur le serveur. De plus elle doit avoir le droit  d’utiliser l’API de Management, soit depuis la Console Constellation ou soit directement dans le fichier de configuration en ajoutant l’attribut “enableManagementAPI”.

Ainsi chaque appel aura le format suivant :

http://localhost:8088/rest/management/<action>?SentinelName=Management&PackageName=<Friendly name>&AccessKey=<access key>&<paramètres>

Check Access

Toutes les API REST de Constellation exposent une méthode en GET “CheckAccess” qui retourne un code HTTP 200 (OK). Cela permet de tester la connexion et l’authentification au serveur Constellation.

• Action : “CheckAccess” (GET)
• Paramètres : aucun

Exemple :

http://localhost:8088/rest/management/CheckAccess?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Récupérer la version du serveur

Pour connaitre la version du serveur Constellation, vous pouvez invoquer l’action “/server/version”.

• Action : “/server/version” (GET)
• Paramètres : aucun

Exemple :

http://localhost:8088/rest/management/server/version?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Edition du fichier de configuration

Lire le fichier de configuration

Vous pouvez récupérer le contenu entier du fichier de configuration de votre Constellation en invoquant l’action ”/configuration”

• Action : “/configuration” (GET)
• Paramètres : aucun

Exemple :

http://localhost:8088/rest/management/configuration?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Ecrire le fichier de configuration

Vous pouvez également réécrire le fichier de configuration en postant le nouveau contenu sur la même URL.

• Action : “/configuration” (POST)
• Paramètres : aucun
• Corps de la requête : le fichier de configuration XML

Le serveur vérifiera le bon format du fichier XML avant d’écraser le fichier de configuration existant par votre nouvelle version. Vous devrez ensuite recharger la configuration pour appliquer les modifications.

Recharger et déployer la configuration

Pour recharger le fichier de configuration vous devez invoquer l’action “/configuration/reload” :

• Action : “/configuration/reload ” (GET)
• Paramètres :
  • deployConfiguration (optionnel – par défaut “false”) : indique si l’ordre de mise à jour doit être envoyé aux sentinelles et packages de la Constellation

Exemple :

http://localhost:8088/rest/management/configuration/reload?deployConfiguration=true&SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

La License Constellation

Vous pouvez récupérer les caractéristiques de la licence affectée à votre serveur en invoquant l’action  “/license”.

• Action : “/license” (GET)
• Paramètres : aucun

Exemple :

http://localhost:8088/rest/management/license?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Vous pouvez également charger une nouvelle licence en utilisant le verbe “POST” sur cette action et en plaçant le contenu de la nouvelle licence dans le corps de la requête.

Gestion du Package Repository

Lister le Package Repository

Pour récupérer la liste des packages de le Package Repository :

• Action : “/packages” (GET)
• Paramètres : aucun

Exemple :

http://localhost:8088/rest/management/packages?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Récupérer un package

Pour récupérer un package en particulier de votre Package Repository :

• Action : “/packages/{packageName}” (GET)
• Paramètres : aucun

Exemple :

http://localhost:8088/rest/management/packages/{packageName}?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Renommer un package

Pour renommer un package de votre Package Repository vous devez poster un objet JSON contenant son nouveau nom :

• Action : “/packages/{packageName}” (POST)
• Paramètres : aucun
• Corps de la requête (application/json) : { « newName »: newName }

Supprimer un package

Pour supprimer package de votre Package Repository :

• Action : “/packages/{packageName}” (DELETE)
• Paramètres : aucun

Récupérer l’icone d’un package

Pour récupérer l’icone d’un package de votre Package Repository :

• Action : “/packages/{packageName}/icon” (GET)
• Paramètres : aucun

Vous obtiendrez l’icone au format “PNG”.

Exemple :

http://localhost:8088/rest/management/packages/{packageName}/icon?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Récupérer le schéma XSD d’un paramètre de configuration d’un package

Chaque package peut avoir des settings. Ces settings peuvent être de plusieurs types (types simples, objet JSON ou XML). Chaque package doit (ou devrait) déclarer la liste des settings qu’il utilise dans son “Package Manifest”.

Si le setting est de type XML (“ConfigurationSection” ou “XmlDocument”) il peut être lié à un schéma XSD pour décrire le format XML du setting en question.

L’action ci-dessous permet de récupérer ce schema XSD pour un setting d’un package de votre Package Repository.

• Action : ”/packages/{package}/settings/{settingName}/xsd ” (GET)
• Paramètres : aucun

Exemple :

http://localhost:8088/rest/management/packages/{packageName}}/settings/{settingName}/xsd?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Télécharger un package vers votre Package Repository

Vous pouvez ordonner à votre serveur Constellation de télécharger un fichier vers le Package Repository.

Pour cela vous utiliserez l’action “/download-package” en spécifiant l’URL du fichier à télécharger.

• • Action : ”/download-package” (POST)
  • Paramètres : aucun
  • Corps de la requête (application/json) : { « url »: url}

Téléverser un package vers votre Package Repository

Vous pouvez également envoyer un fichier vers votre Package Repository en utilisant l’action “/upload-package”.

• Action : ”/upload-package” (POST)
• Paramètres : aucun
• Corps de la requête (multipart/form-data) : les fichiers à enregistrer dans votre Package Repository.

Les RecoveryOptions

Les Recovery Options spécifient les options de récupération en cas de crash d’un package sur vos sentinelles.

Chaque package peut avoir ses propres options mais par défaut il hérite des options “globales”.

Pour récupérer ces options “globales” :

• Action : ”/configuration/recoveryoptions” (GET)
• Paramètres : aucun

Exemple :

http://localhost:8088/rest/management/configuration/recoveryoptions?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Vous pouvez également redéfinir ces options en postant sur cette même URI votre nouvel objet JSON :

• Action : ”/configuration/recoveryoptions” (POST)
• Paramètres : aucun
• Corps de la requête (application/json) : l’objet “RecoveryOptions” avec les nouvelles valeurs

Gestion des sentinelles

Lister les sentinelles

Pour récupérer la liste des sentinelles de votre Constellation :

• Action : “/sentinels” (GET)
• Paramètres : aucun

Exemple :

http://localhost:8088/rest/management/sentinels?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Ajouter ou modifier une sentinelle

Pour ajouter ou modifier une sentinelle de votre Constellation :

• Action : “/sentinels” (POST)
• Paramètres : aucun
• Corps de la requête (application/json) : un objet JSON contenant deux propriétés :
  • “Name”  : le nom de la sentinelle
  • “Credential” : le nom du credential associé à cette sentinelle

Supprimer une sentinelle

Pour supprimer une sentinelle de votre Constellation :

• Action : “/sentinels/{sentinelName}” (DELETE)
• Paramètres : aucun

Gestion des packages et des settings

Lister les packages d’une sentinelles

Pour récupérer la liste des packages (virtuels ou non) d’une sentinelle (virtuelle ou non) de votre Constellation :

• Action : “/sentinels/{sentinelName}/packages” (GET)
• Paramètres : aucun

Exemple :

http://localhost:8088/rest/management/sentinels/{sentinelName}/packages?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Récupérer une instance d’un package

Pour récupérer le détail d’une instance de package sur une sentinelle donnée :

• Action : “/sentinels/{sentinelName}/packages/{packageName}” (GET)
• Paramètres : aucun

Exemple :

http://localhost:8088/rest/management/sentinels/{sentinelName}/packages/{packageName}?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Ajouter ou modifier une instance d’un package

Pour ajouter ou modifier un package sur une sentinelle de votre Constellation :

• Action : “/sentinels/{sentinel}/packages” (POST)
• Paramètres : aucun
• Corps de la requête (application/json) : un objet JSON contenant cinq propriétés :
  • “Name”: le nom de l’instance du package (obligatoire et unique)
  • “PackageFile” (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 lorsque sa sentinelle démarre

Supprimer une instance d’un package

Pour supprimer un package sur une sentinelle de votre Constellation :

• Action : “/sentinels/{sentinel}/packages/{packageName}” (DELETE)
• Paramètres : aucun

Options de récupération d’une instance d’un package

Pour récupérer les options de récupération d’une instance d’un package :

• Action : “/sentinels/{sentinelName}/packages/{packageName}/recoveryoptions” (GET)
• Paramètres : aucun

Exemple :

http://localhost:8088/rest/management/sentinels/{sentinelName}/packages/{packageName}/recoveryoptions?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Pour les redéfinir vous devez poster la nouvelle valeur de votre objet “RecoveryOptions” sur cette même URI.

• Action : “/sentinels/{sentinelName}/packages/{packageName}/recoveryoptions” (POST)
• Paramètres : aucun
• Corps de la requête (application/json) : l’objet “RecoveryOptions” avec les nouvelles valeurs

Groupes d’une instance d’un package

Pour récupérer les groupes d’une instance d’un package :

• Action : “/sentinels/{sentinelName}/packages/{packageName}/groups” (GET)
• Paramètres : aucun

Exemple :

http://localhost:8088/rest/management/sentinels/{sentinelName}/packages/{packageName}/groups?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Utilisez cette même URI pour poster la nouvelle liste des groupes de votre instance :

• Action : “/sentinels/{sentinelName}/packages/{packageName}/groups” (POST)
• Paramètres : aucun
• Corps de la requête (application/json) : la liste des groupes de votre instance

Settings d’une instance d’un package

Pour récupérer les settings d’une instance d’un package :

• Action : “/sentinels/{sentinelName}/packages/{packageName}/settings” (GET)
• Paramètres : aucun

Exemple :

http://localhost:8088/rest/management/sentinels/{sentinelName}/packages/{packageName}/settings?SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Utilisez cette même URI pour poster le nouveau dictionnaire (clé/valeur) des settings :

• Action : “/sentinels/{sentinelName}/packages/{packageName}/settings” (POST)
• Paramètres : aucun
• Corps de la requête (application/json) : le dictionnaire (clé/valeur) des settings de votre instance

Gestion des credentials et autorisations

Lister les credentials

Pour récupérer la liste des credentials de votre Constellation :

• Action : “/credentials” (GET)
• Paramètres :
  • includeAccessKeys (optionnel – par défaut “false”) : indique si vous souhaitez inclure les AccessKeys de chaque credentials

Exemple :

http://localhost:8088/rest/management/credentials?includeAccessKeys=true&SentinelName=Management&PackageName=Demo&AccessKey=MaCleDeTest123

Ajouter ou modifier un credential

Pour ajouter ou modifier un credential de votre Constellation :

• Action : “/credentials” (POST)
• Paramètres : aucun
• Corps de la requête (application/json) : un objet JSON contenant six propriétés :
  • “Name” : le nom du credential
  • “AccessKey” : la clé d’accès du credential
  • “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)

Supprimer un credential

Pour supprimer un credential de votre Constellation :

• Action : “/credentials/{credentialName}” (DELETE)
• Paramètres : aucun

Récupérer les autorisations d’un credential

• Action : “/credentials/{credentialName}/authorizations” (GET)
• Paramètres : aucun

Vous récupérerez un objet de type “CredentialAuthorizations“ sérialisé en JSON

Définir les autorisations d’un credential

• Action : “/credentials/{credentialName}/authorizations” (POST)
• Paramètres : aucun
• Corps de la requête (application/json) : l’objet CredentialAuthorizations sérialisé en JSON

The post L’interface REST « Management » appeared first on Constellation.