AppWatcher - Gestion d'applications Delphi à distance pour développeurs

Version imprimable

Voir 40 message(s) de cette discussion en une page

02/03/2025, 07h37
mbaum

AppWatcher - Gestion d'applications Delphi à distance pour développeurs
Bonjour à la communauté,

Je suis ravi de partager mon nouveau projet open-source, AppWatcher : https://github.com/mbaumsti/Delphi-App-Watcher

Avez-vous déjà rencontré la difficulté de gérer des dizaines d'applications Delphi fonctionnant sur plusieurs machines du réseau ? Trouver un créneau horaire convenable pour remplacer les exécutables peut être un véritable casse-tête. C'est pourquoi j'ai développé AppWatcher.
AppWatcher est un composant Delphi et 2 applications qui vous permettent de contrôler à distance l'arrêt et le redémarrage de vos applications Delphi sur votre réseau.
Voici comment cela fonctionne :
1. Intégrez le composant TAppWatcherClient dans vos applications Delphi.
2. Déployez l'Agent AppWatcher sur vos machines clientes.
3. Utilisez l'application AppWatcher Master pour contrôler à distance toutes vos applications.
Fonctionnalités clés :
- Arrêtez à distance les applications avec des notifications utilisateur.
- Redémarrez automatiquement les applications après les mises à jour.
- Évitez d'utiliser RDP ou d'accéder physiquement à chaque machine.
- Minimisez les temps d'arrêt et rationalisez le processus de déploiement.
Si vous recherchez une solution pour simplifier la gestion d'applications à distance dans votre environnement Delphi, je vous encourage à découvrir AppWatcher. Les contributions et les commentaires sont les bienvenus !
02/03/2025, 14h21
ShaiLeTroll
Sinon, il existe des solutions de déploiement comme LANDesk software deployment portal ... normalement, cela devrait l'équipe Cloud Ops et Dev Ops de ta société qui devrait fournir ce genre d'outil avec toutes les sécurités possibles.
Je pense aussi à Ansible ou Jenkinsn idéal pour automatiser compilation, packaging et déploiement vers le Cloud après pour l'agent local, ça tu as un tas de prestataire qui en fournisse pour les sociétés qui investisse dans un gestionnaire d'asset avec outil de RMM Deployment.

Cela fait penser à PAServer sur le fonctionnement Master-Slave et sur l'inversion qui est Client Server lors de la négociation initiale de connexion, tu n'as pas de problème avec les FireWall, proxy voire les réseaux secondaires (plusieurs cartes réseau sur serveur), je déploie pas mal d'application non visible sur le réseau de l'entreprise, mais uniquement visible par des frontaux PHP/NodeJS/Python via un revert proxy NGINX, sinon derrière des fermes CITRIX idem, on déploie sur le master, pas du la prod active (du moins, je l'ai fait mais comme toi, j'ai développé mon outil, plus simpliste puisque LAN accessible)

Comment gères tu la sécurité, il y a des clés validées par des certficats à échanger lors de la communication pour éviter que n'importe qui puisse se connecter au Port et injecter n'importe quelle commande ou forcer un deny de service en saturant le port de données, prévoit éventuellement un throttling.

Comme tu échanges un record, je te recommande

Code:

TAppWatcherMessage = packed record

et veiller MINENUMSIZE au TAppWatcherCommand
Faudrait empêcher le code de se compiler en 32Bits aussi, car l'échange de HWnd change de taille entre 32 et 64 bits, sinon il te faut gérer un champ size supplémentaire dans le code pour déterminer quelle version du protocole utiliser.

Petite astuce syntaxique TAppWatcherStrCommand: array[0..10] of string = ... -> APP_WATCHER_COMMAND_STR: array[TAppWatcherCommand] of string = ... cela évite le Ord et en plus cela respecte le nommage conventionnel pour une constante
Code:

1 2 3 4 Function TAppWatcherMessage.CmdName : string; begin Result := APP_WATCHER_COMMAND_STR[Command]; // à la place de // Result:= TAppWatcherStrCommand[ord(Command)]; end;
On pourrait aussi faire cela sans constante
Code:

1 2 3 4 Function TAppWatcherMessage.CmdName : string; begin Result := Copy(GetEnumName(TypeInfo(TAppWatcherCommand), Ord(Command)), Length('cmd') + 1); end;
03/03/2025, 07h37
mbaum

Réponse aux remarques de ShaileTroll
Bonjour ShaiLeTroll,

Merci pour ton retour détaillé et tes remarques pertinentes !
Effectivement, AppWatcher est une solution très simple, pensée pour un besoin bien précis : gérer proprement le déploiement d'un exécutable sur un réseau local sans avoir à me soucier de sessions ouvertes ou de processus bloquants.

Dans ma boîte (30 personnes, petite structure), je n'ai pas de Cloud Ops / DevOps, ni d’outils comme Ansible ou Jenkins en place. Le but n'est pas de concurrencer des solutions industrielles, mais juste d’avoir un moyen efficace de remplacer une appli sur un partage réseau sans prise de tête.

Cela dit, tes remarques sur la sécurité sont intéressantes ! Même si je suis dans un réseau local derrière un pare-feu, je vais quand même renforcer certains points pour éviter tout risque d’abus. En tout cas certains me paraissent assez facile à mettre en place. Je me les note pour une prochaine mise à jour :
- Clé d’authentification
- Vérification des IP autorisées
- Gestion plus propre du format des messages (packed record, compatibilité 32/64 bits).
- Throttling
Je vais évidemment utiliser ton idée d’utiliser GetEnumName pour simplifier CmdName !
Bon j'ai du travail devant moi...

Encore merci pour ton retour ! :D
03/03/2025, 09h32
SergioMaster

Ça me rappelait quelque chose !
J'ai testé, mais jamais "déployé" TWebUpdate de TMSSoftware, ce srait plus ou moins le même esprit ?

P.S. Le dépôt manque peut-être un peu d'images écrans pour appâter le client.
P.P.S je n'ai jamais compris PPrem (Patrick Prémartin) faisait pour mettre ses fichiers Readme en anglais et en français, ce serait un autre plus (ce n'est qu'une suggestion)
03/03/2025, 11h02
mbaum

Bonjour SergioMaster

TWebUpdate me semble plutôt conçu pour proposer une mise à jour à l'utilisateur lorsqu'une nouvelle version est disponible, ce qui implique une installation locale sur chaque machine. Ce n'est pas le cas dans mon approche.

De mon côté, je remplace directement l'exécutable sur un disque réseau auquel les utilisateurs accèdent via un lien.

Avantage : Je suis sûr que tout le monde utilise toujours la dernière version, ce qui est crucial dans mon cas, car mes applications sont liées à des bases de données. La moindre différence de version peut entraîner des problèmes graves pour les données.

Inconvénient : Ce type de déploiement impose que personne ne soit en train d'utiliser l'application au moment de la mise à jour, ce qui complique un peu la gestion.

Je note pour les images à ajouter et pour la traduction du readme en Français
03/03/2025, 12h00
SergioMaster

TWebUpdate est un composant à inclure directement dans le programme, mais oui ta solution m'aurait intéressé quand j'étais encore en activité, surtout que moi, j'étais en télétravail (et ce depuis 1998)
Longtemps, je demandais aux utilisateurs d'appliquer, via un .bat, les mises à jour en fonction de "l'image" des programmes sur le serveur, puis logmein à changer la donne et j'envoyais directment sur les divers postes les programmes modifiés mais c'était assez fastidieux (surtout avec 2 necessités : poste allumé et programme inutilisé)
03/03/2025, 13h46
mbaum
LogMeIn semble une solution puissante, mais clairement surdimensionnée pour notre besoin. Il semble d'ailleurs que la mise à jour d'applications ne soit disponible qu'avec la version Premium...

Mon petit outil, lui, me convient parfaitement :
- Pas de gestion compliquée des mises à jour : Les machines de l'atelier étant parfois éteintes, je n’ai pas à me soucier de savoir si elles sont à jour ou non. Dès qu’elles redémarrent, elles utilisent automatiquement la dernière version.
- Pas besoin de connexion distante, je n’ai pas à me connecter à chaque machine.
- Gestion des applications en cours d'utilisation : Si une appli est en cours, l’utilisateur est averti. Je n’ai plus besoin d’appeler tout le monde pour vérifier qui utilise quoi.
J’ai aussi inclus la possibilité pour une application de refuser l’arrêt, ce qui est bien utile pour certaines applis critiques. En mode modification, ça permet d’éviter que l’utilisateur perde son travail ou que la base de données ne se retrouve dans un état incohérent.
Du coups, si l’utilisateur n’a pas enregistré son travail avant la fin du décompte, l’application ne se fermera pas. Dans ce cas je dois évidemment intervenir pour faire enregistrer le travail et libérer l'application. Mais si au final, il ne reste qu’un seul poste à gérer sur la trentaine, j’ai déjà gagné un temps précieux !

A noter que mon application redémarre les applications qui ont été arrêtées ce qui permet ici aussi d'éviter les messages à tous le monde ...

Cerise sur le gâteau, le composant permet de gérer les paramètres de lancement grâce à la méthode OnGetAppParams qui permet à l'application de transmettre à l'agent la liste de paramètres à utiliser pour redémarrer. De cette manière on est sûr que l'application redémarre dans le mode ou elle était lors de l'arrêt.
03/03/2025, 15h07
ShaiLeTroll

Personnellement, je fais ce genre de mise à jour automatiquement via un .BAT généré : TSLTModuleAutoUpdate

Pas besoin de faire manuellement, ni même d'avertir l'utilisateur, la nouvelle version se télécharge automatiquement depuis un Repo, la plus simpliste étant TSLTModuleAutoUpdateByDOSBatchEngine avec une simple copie de fichier LAN mais j'avais aussi une version FTP et une version LAN avec mot de passe WNetAddConnection2 / CopyFileEx et Asynchrone.

Dès que le l'utilisateur lance programme qui commence par un SplashScreen, cela lance la mise à jour, si accessible, téléchargement, abandon du démarrage de la version en cours, démarrage de la version téléchargée, l'utilisateur n'y voyait que du feu.

C'était justement pour remplacer un AutoUpdate d'une lib tiers qui posaient bcp de problème de verrou de fichier avec CITRIX (sans parler de faux positifs de virus) et pire que l'utilisateur pouvait annuler !
Dans certains cas, la modification de la DB ou d'une logique métier imposait d'utiliser une version d'exe compatible avec la version de DB, fallait surtout pas que l'utilisateur puisse annuler la mise à jour

La différence, c'était plutôt 200 postes en france sur 5 sites, plus italie, inde, chine ... mais tous les externes étaient en CITRIX donc ritualisé le Lundi soir pour les modifs DB et au fil de la journée pour les modifs ergonomie.
Et les modifs DB, on ne faisait pas de ALTER TABLE en plein journée, on le faisait entre 22h et 2h, quand l'europe a fini mais l'asie n'a pas encore commencé, non parce qu'une base contenant 2000 tables et 200 milliards d'enregistrement, tu fais pas ça en journée et sans backup (journaux / delta)
On mettait donc les scripts de mise à jour DB dans une file d'attente pour les produits en PROD, contrairement à ceux encore en cours de DEV non déployée qui était auto-distribué

En parallèle, chaque Exe utilisait une base de données centralisées, chaque programme, presque 200, au démarrage, créé un log avec des infos dont la version, l'utilisateur, le nom de la machine ... idem à l'arrêt du programme
Ainsi, je savais aussi ceux qui n'avait pas redémarré ou alors les CITRIX qui avaient gardé une version d'exe en cache (de toute façon purgé tous les lundis soirs)

Sinon

Vcl.Forms.GetParentForm pour aussi simplifier FindParentForm

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
function FindParentForm(AComponent: TComponent): TForm;
var
    Current: TComponent;
begin
    Result := nil;
    Current := AComponent;
 
    //🔄 Remonte dans la hiérarchie des "Owner" (gestion mémoire)
    while Assigned(Current) do
    begin
        if Current is TForm then
            Exit(TForm(Current)); //✅ Trouvé !
 
        Current := Current.Owner;
    end;
 
    //🔄 Remonte aussi la hiérarchie des "Parent" (visuel)
    if AComponent is TControl then
    begin
       Exit(TForm(GetParentForm(TControl(AComponent))));          
    end;
end;

03/03/2025, 16h04
Andnotor
Je procède un peu comme Shai : un service contrôle périodiquement la disponibilité d'une mise à jour (par VPN dans mon cas) et le cas échéant active un event global. Un thread est démarré servant uniquement à attendre la libération du PID de l'app cible. Dès qu'elle quitte la nouvelle version téléchargée est simplement renommée. L'event est contrôlé au niveau de la cible lorsque l'utilisateur se délogue, elle lance simplement un bat temporisé de 5 s pour son redémarrage avant de quitter (mais j'aurais aussi pu faire un restart par le service). Le service en profite également à ce moment-là (plus d'utilisateur actif) pour contrôler si une mise à jour Windows nécessite un reboot et le lance si nécessaire, ça évite les attentes interminables si la station doit être redémarrée en cours de journée (sinon veille prolongée, jamais d'arrêt).

Les petites choses qui me dérangent dans ton approche sont :
- ce fichier ini sur un partage réseau que tous les agents doivent consulter toutes les 5 s (!). Un broadcast depuis le master ("Hey! je suis votre nouveau master") ou depuis les agents ("Hey! je viens de démarrer, à qui dois-je m'adresser ?") m'aurais plus plu ;
- dans quel état se trouve le premier master lorsqu'un deuxième démarre ?
- "AppWatcher Agent – A lightweight service" mais dans les faits une application desktop ;
- deux apps desktop dialoguant par socket, je trouve ça un peu lourd et limitatif (voir ci-dessous) ;
- si l'agent était véritablement un service dialoguant par pipe avec les clients, ton app serait facilement utilisable sur un serveur pour piloter toutes les instances également en RDP.
Mais ce ne sont que des considérations si tu voulais faire évoluer ce projet par la suite ;)
03/03/2025, 16h29
ShaiLeTroll

Dans deux anciennes boites et partiellement celle où c'était en CITRIX, il y a avait un Portail applicatif

Le Portail applicatif était le point d'accès principal voire même unique

Dans le cas Portail applicatif unique
En fait, tous les modules étaient des DLL, tout était sous forme de Plugin, c'est le Portail qui gère les mises à jour, en fonction de la DB, il savait quelle était version de DLL mini/maxi à récupérer depuis le serveur (souvent des patch mineurs)
Ainsi l'équipe déploiement ne mettait à jour que le Serveur c'est le Portail qui gérait la notification, un système comme le tient mélangeant TCP/IP + DB, cela en D3, D5 et D7 (oui les clients ne voulaient pas forcément acheté les grosses mise à jour donc maintenance de version plus ancienne, j'étais un des seuls à maintenir le D3 en reproduisant ce que les autres faisaient en TMS sur D7, je faisais tout à la mano)

Dans le cas Portail applicatif en point d'accès principal
Les modules étaient des Exe, certains autonomes, surtout ceux qui ne servaient qu'à la consultation, d'autres nécessitaient d'être loggué mais pour se logguer
soit passer par le Portail (échange de données entre Portail et Exe via Pipe/Message)
soit avoir une version "premium" pour qu'elle autorise l'accès directe et propose l'écran de login, uniquement les responsables
Selon le mode de lancement, la mise à jour étant piloté par l'appelant ou par l'appelé.

Le Portail pouvant aussi servir pour faire des annonces ... c'était devenu nécessaire lorsque les utilisateurs france commençait à 6h et finissait à 20h avec rotation d'équipe aux "ateliers" pour une mise à jour gravissime, ce n'est arrivé qu'une fois.

Et les programmes serveur, là c'était des taches planifiées pour arrêter un service windows, mettre à jour la base, démarrer le service, en nocturne, sans personne pour s'en occuper.

C'est aussi la difficulté de la gestion de mise à jour, la nature du programme, son environnement, sa disponibilité (les mises à jour Asie n'étaient pas faites au même moment que l'Europe).
04/03/2025, 07h31
mbaum
Citation:
Envoyé par Andnotor

Les petites choses qui me dérangent dans ton approche sont :

ce fichier ini sur un partage réseau que tous les agents doivent consulter toutes les 5 s (!). Un broadcast depuis le master ("Hey! je suis votre nouveau master") ou depuis les agents ("Hey! je viens de démarrer, à qui dois-je m'adresser ?") m'aurais plus plu ;
dans quel état se trouve le premier master lorsqu'un deuxième démarre ?
"AppWatcher Agent – A lightweight service" mais dans les faits une application desktop ;
deux apps desktop dialoguant par socket, je trouve ça un peu lourd et limitatif (voir ci-dessous) ;
si l'agent était véritablement un service dialoguant par pipe avec les clients, ton app serait facilement utilisable sur un serveur pour piloter toutes les instances également en RDP.
Bonjour Andnotor et merci pour tes remarques :

1) Pour le fichier ini consulté toutes les 5s oui, c'est vrai ce n'est pas forcément super élégant, mais qu'est-ce que c'est simple ... :lol:
Le broadcast complique les choses (écoute réseau, ports ouverts, gestion des destinataires...), et je ne suis pas sûr que ce soit nécessaire pour mon usage. Peut-être si quelqu'un a besoin de plusieurs Masters sur le même réseau, à voir. D’ailleurs, une optimisation possible serait de ne lire le fichier ini que s’il a été modifié, ça éviterait les lectures inutiles.

2) A l'heure actuelle le dernier master qui démarre sur le réseau prend la main. Mon optique n'était pas d'en avoir plusieurs mais pour être plus propre j'ai pensé ajouter une vérification régulière par le Master de l'adresse IP se trouvant dans le fichier ini pour qu'il puisse signaler qu'il a perdu la main ...

3) Oui c'est vrai l'agent est une solution Desktop. Pour le moment c'est intentionnel car finalement je n'ai absolument pas besoin de lui si la machine est arrêtée ou l'utilisateur déconnecté puisque ce que je cherche c'est que les .exe soient libres

4) La connexion via socket me paraît par contre être un bon plan pour la partie communication Agent<-> client, ce sera en effet moins lourd que les sockets TCP. Je me la note donc pour une mise à jour.

Merci encore pour le temps que tu as consacré à me répondre

Citation:

Envoyé par ShaiLeTroll

Sinon

Vcl.Forms.GetParentForm pour aussi simplifier FindParentForm

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
function FindParentForm(AComponent: TComponent): TForm;
var
    Current: TComponent;
begin
    Result := nil;
    Current := AComponent;
 
    //🔄 Remonte dans la hiérarchie des "Owner" (gestion mémoire)
    while Assigned(Current) do
    begin
        if Current is TForm then
            Exit(TForm(Current)); //✅ Trouvé !
 
        Current := Current.Owner;
    end;
 
    //🔄 Remonte aussi la hiérarchie des "Parent" (visuel)
    if AComponent is TControl then
    begin
       Exit(TForm(GetParentForm(TControl(AComponent))));          
    end;
end;

Merci pour ce source ShaiLeTroll
Je suis impressionné par vos réponses, je vois que vous épluchez littéralement le source ... je ne m'attendais pas à un tel niveau d'intervention

Merci encore

04/03/2025, 09h21
ShaiLeTroll

Cela reste des observations triviales sur la syntaxe et fonctions méconnues.

Ayant fait ce genre d'outil, la curiosité de voir comment chacun s'y prend est intéressante, pour ma part, à chaque mouture de ce type de composant, il fut en lien avec les spécificités de mon entreprise du moment, je n'ai jamais finalement une seule version commune dans le temps, que ce soit le stockage que le transport ou les modalités (interaction, notification, planification ...)
04/03/2025, 09h58
mbaum

Oui finalement chacun fait à sa sauce en fonction de ses besoins, de ses idées et de ses capacités ...
Mais c'est intéressant d'échanger avec d'autres personnes car cela ouvre de nouveaux horizons.

J'ai créé une série de "Issues" dans mon repo pour noter toutes vos remarques à toi et Andnotor
https://github.com/mbaumsti/Delphi-App-Watcher/issues
07/03/2025, 07h40
mbaum

Bonjour Messieurs,

J'ai un peu travaillé sur le sujet de la sécurité et je vous avoue ne pas trop savoir que faire car je trouve les solutions très lourdes pour mon application.

Que me conseilleriez vous ?
Un certificat TLS ?
07/03/2025, 09h22
ShaiLeTroll

Concernant le Certificat TLS, c'est un abus de langage pour le HTTPS via Certificat X509 qui est lié à une URL via un tiers de confiance, faudrait étudier plus le mécanisme du HTTPS et la vérification d'identité.
Tu peux utiliser Certificat X509 dans d'autres situations

A ton niveau, tu peux gérer un autre Certificat X509, plutôt pour "vérifier" l'authenticité des données, un peu comme pour un JWT, ajout d'une signature
Master Clé Privée -> génère la signature
Client Clé Publique -> vérifie la signature

Evidemment la clé privée c'est ultra confidentielle,
La clé publique, tu peux l'intégrer à l'exe en ressources, tu peux la télécharger depuis le Master ... (*)

Tu peux mettre l'IP du Master dans la donnée ainsi le client peut vérifier l'IP du Socket remote, il aura une confirmation de l'identité

D'ailleurs, tu pourrais très bien envoyé un JWT comme donnée, après tout c'est juste un JSON, tu as quelques champs standards à respecter mais tu peux ajouter plein d'autres à toi.
En Delphi, je ne connais pas de composant standard pour le JWT, moi je l'ai codé avec les DLL OpenSSL et j'ai étendu les Headers Indy de ma version qui sont incomplets (normal c'est 3500 fonctions dans une DLL)

(*) ça c'est une solution niveau donnée, mais tu peux avoir la même chose au niveau transport :
TIdTCPServer + TIdServerIOHandlerSSLOpenSSL <-> TIdTCPClient + TIdSSLIOHandlerSocketOpenSSL

Sur le server : SSLOptions.RootCertFile / CertFile / KeyFile
Faudrait voir exactement, tu as aussi un moyen d'avoir une clé asymétrique générée à la volée à chaque session.

tu as aussi le compo de Paul Toth SChannel à la place de OpenSSL

C'est en fait, la première chose à mettre en place, la partie Transport de ta couche Indy, c'est la base, si je te retrouve un code à ce sujet, cependant, je n'ai jamais géré les certificats, les admins systèmes/réseaux me fournissaient ça.
07/03/2025, 10h08
mbaum

Bonjour

Oui je connais cette technique bien que jamais mis en œuvre.
Il faut utiliser openssl pour générer le fichier certificat et la clé secrète.
Quelque chose du genre :

Code:

openssl req -x509 -newkey rsa:2048 -keyout server.key -out server.crt -days 365 -nodes

et ensuite il faut utiliser ces certificats avec Indy sans doute avec TIdServerIOHandlerSSLOpenSSL et TIdSSLIOHandlerSocketOpenSSL

C'est bien à ça que tu pensais ?
07/03/2025, 10h36
ShaiLeTroll

C'est exactement cela mais uniquement TIdServerIOHandlerSSLOpenSSL

server.crt -> SSLOptions.CertFile
server.key -> SSLOptions.KeyFile

Il te faut le .pem pour RootCertFile

le TIdSSLIOHandlerSocketOpenSSL lui fera un handshake avec le server, il ne connaît pas ce fichier.

Comme toi, on m'a toujours fourni les fichiers, je n'ai fait que les intégrer.

Et pense à être à jour niveau Indy : https://github.com/IndySockets/Indy/ et https://github.com/IndySockets/IndyTLS-OpenSSL

Pense aussi au TIdSSLIOHandlerSocketSChannel de Paul Toth, il pourrait aussi t'intéresser.
07/03/2025, 10h46
SergioMaster

TMSSoftware fourni un outil gratuit pour générer des certificats https://www.tmssoftware.com/site/freetools.asp#certgen sans trop se fatiguer.
Je ne suis pourtant plus tellement fan de TMS :roll: mais je m'apperçois que je l'ai déjà notifier deux fois :oops:

Voir 40 message(s) de cette discussion en une page