C'est étrange au premier abord en effet. Nous proposons aux clients
une surveillance quotidienne ; ça les rassure c'est comme ça, c 'est
pas toujours facile d'éduquer un client ... Sur le principe je suis
donc d'accord avec toi, une alerte devrait nous suffire. Mais nous
garantissons que nous nous inquiétons de l'état du parc tous les
jours. Du fait de notre manque d'expérience dans le domaine cela nous
permet aussi de constater un problème que nous n'avons pas anticip é,
pour lequel nous n'avons pas configuré de règle. Un dernier poi nt,
l'information "je vais bien" est claire, alors que l'absence
d'information laisse toujours peser un doute, ma seule crainte étant
la volumétrie du bousin, crainte qui pourrait aider à convaincr e les
décideurs sur la modification de la clause du contrat, qui sait ...
C'est étrange au premier abord en effet. Nous proposons aux clients
une surveillance quotidienne ; ça les rassure c'est comme ça, c 'est
pas toujours facile d'éduquer un client ... Sur le principe je suis
donc d'accord avec toi, une alerte devrait nous suffire. Mais nous
garantissons que nous nous inquiétons de l'état du parc tous les
jours. Du fait de notre manque d'expérience dans le domaine cela nous
permet aussi de constater un problème que nous n'avons pas anticip é,
pour lequel nous n'avons pas configuré de règle. Un dernier poi nt,
l'information "je vais bien" est claire, alors que l'absence
d'information laisse toujours peser un doute, ma seule crainte étant
la volumétrie du bousin, crainte qui pourrait aider à convaincr e les
décideurs sur la modification de la clause du contrat, qui sait ...
C'est étrange au premier abord en effet. Nous proposons aux clients
une surveillance quotidienne ; ça les rassure c'est comme ça, c 'est
pas toujours facile d'éduquer un client ... Sur le principe je suis
donc d'accord avec toi, une alerte devrait nous suffire. Mais nous
garantissons que nous nous inquiétons de l'état du parc tous les
jours. Du fait de notre manque d'expérience dans le domaine cela nous
permet aussi de constater un problème que nous n'avons pas anticip é,
pour lequel nous n'avons pas configuré de règle. Un dernier poi nt,
l'information "je vais bien" est claire, alors que l'absence
d'information laisse toujours peser un doute, ma seule crainte étant
la volumétrie du bousin, crainte qui pourrait aider à convaincr e les
décideurs sur la modification de la clause du contrat, qui sait ...
On Tue, 26 Mar 2013 16:35:41 +0100
Gabriel Euzet wrote:
> C'est étrange au premier abord en effet. Nous proposons aux client s
> une surveillance quotidienne ; ça les rassure c'est comme ça, c'est
> pas toujours facile d'éduquer un client ... Sur le principe je sui s
> donc d'accord avec toi, une alerte devrait nous suffire. Mais nous
> garantissons que nous nous inquiétons de l'état du parc tous les
> jours. Du fait de notre manque d'expérience dans le domaine cela n ous
> permet aussi de constater un problème que nous n'avons pas anticip é,
> pour lequel nous n'avons pas configuré de règle. Un dernier p oint,
> l'information "je vais bien" est claire, alors que l'absence
> d'information laisse toujours peser un doute, ma seule crainte éta nt
> la volumétrie du bousin, crainte qui pourrait aider à convain cre les
> décideurs sur la modification de la clause du contrat, qui sait .. .
Dans ce cas, passe juste par des agents zabbix et centralise la
base de données chez toi. Ãa fera l'inverse et le client ne rec evra
plus que les alertes (en plus de toi).
Comme ça tu pourras faire de l'extraction sur la DB jusqu'à plu s soif.
Et c'est de toute façon plus logique (juste une liaison TCP chiffr ée).
à noter qu'un agent est tout à fait capable de rebalancer la
sauce à plusieurs serveurs si besoin est (et qu'il peut fonctionner
en push ou en pull).
Ãa n'est pas la peine de laisser un visuel au client s'il n'est pas
en mesure de l'exploiter correctement (ou alors, fais-lui tourner une
vidéo avec de beaux graphiques en boucle;-)
Un (petit) aperçu de ce qu'il sait faire.
http://wiki.contribs.org/Zabbix
On Tue, 26 Mar 2013 16:35:41 +0100
Gabriel Euzet <geuzet@sqli.com> wrote:
> C'est étrange au premier abord en effet. Nous proposons aux client s
> une surveillance quotidienne ; ça les rassure c'est comme ça, c'est
> pas toujours facile d'éduquer un client ... Sur le principe je sui s
> donc d'accord avec toi, une alerte devrait nous suffire. Mais nous
> garantissons que nous nous inquiétons de l'état du parc tous les
> jours. Du fait de notre manque d'expérience dans le domaine cela n ous
> permet aussi de constater un problème que nous n'avons pas anticip é,
> pour lequel nous n'avons pas configuré de règle. Un dernier p oint,
> l'information "je vais bien" est claire, alors que l'absence
> d'information laisse toujours peser un doute, ma seule crainte éta nt
> la volumétrie du bousin, crainte qui pourrait aider à convain cre les
> décideurs sur la modification de la clause du contrat, qui sait .. .
Dans ce cas, passe juste par des agents zabbix et centralise la
base de données chez toi. Ãa fera l'inverse et le client ne rec evra
plus que les alertes (en plus de toi).
Comme ça tu pourras faire de l'extraction sur la DB jusqu'à plu s soif.
Et c'est de toute façon plus logique (juste une liaison TCP chiffr ée).
à noter qu'un agent est tout à fait capable de rebalancer la
sauce à plusieurs serveurs si besoin est (et qu'il peut fonctionner
en push ou en pull).
Ãa n'est pas la peine de laisser un visuel au client s'il n'est pas
en mesure de l'exploiter correctement (ou alors, fais-lui tourner une
vidéo avec de beaux graphiques en boucle;-)
Un (petit) aperçu de ce qu'il sait faire.
http://wiki.contribs.org/Zabbix
On Tue, 26 Mar 2013 16:35:41 +0100
Gabriel Euzet wrote:
> C'est étrange au premier abord en effet. Nous proposons aux client s
> une surveillance quotidienne ; ça les rassure c'est comme ça, c'est
> pas toujours facile d'éduquer un client ... Sur le principe je sui s
> donc d'accord avec toi, une alerte devrait nous suffire. Mais nous
> garantissons que nous nous inquiétons de l'état du parc tous les
> jours. Du fait de notre manque d'expérience dans le domaine cela n ous
> permet aussi de constater un problème que nous n'avons pas anticip é,
> pour lequel nous n'avons pas configuré de règle. Un dernier p oint,
> l'information "je vais bien" est claire, alors que l'absence
> d'information laisse toujours peser un doute, ma seule crainte éta nt
> la volumétrie du bousin, crainte qui pourrait aider à convain cre les
> décideurs sur la modification de la clause du contrat, qui sait .. .
Dans ce cas, passe juste par des agents zabbix et centralise la
base de données chez toi. Ãa fera l'inverse et le client ne rec evra
plus que les alertes (en plus de toi).
Comme ça tu pourras faire de l'extraction sur la DB jusqu'à plu s soif.
Et c'est de toute façon plus logique (juste une liaison TCP chiffr ée).
à noter qu'un agent est tout à fait capable de rebalancer la
sauce à plusieurs serveurs si besoin est (et qu'il peut fonctionner
en push ou en pull).
Ãa n'est pas la peine de laisser un visuel au client s'il n'est pas
en mesure de l'exploiter correctement (ou alors, fais-lui tourner une
vidéo avec de beaux graphiques en boucle;-)
Un (petit) aperçu de ce qu'il sait faire.
http://wiki.contribs.org/Zabbix
Par contre, comme je l'ai dit plus tôt : pas de connexion permanente
avec le site client.
certains de nos clients ont un service
informatique et l'exigeront. Tout ça me donne l'impression que la
solution va relever de la bricole :-/
Par contre, comme je l'ai dit plus tôt : pas de connexion permanente
avec le site client.
certains de nos clients ont un service
informatique et l'exigeront. Tout ça me donne l'impression que la
solution va relever de la bricole :-/
Par contre, comme je l'ai dit plus tôt : pas de connexion permanente
avec le site client.
certains de nos clients ont un service
informatique et l'exigeront. Tout ça me donne l'impression que la
solution va relever de la bricole :-/
On Tue, 26 Mar 2013 17:09:15 +0100
Gabriel Euzet wrote:
> Par contre, comme je l'ai dit plus tôt : pas de connexion permanen te
> avec le site client.
Pourquoi? Ãa n'est pa le volume de données qui va boucher
le tuyauâ¦
> certains de nos clients ont un service
> informatique et l'exigeront. Tout ça me donne l'impression que la
> solution va relever de la bricole :-/
Pas spécialement, tu peux tout à fait lancer un script avec
un cron qui effectuera une requête sur la DB du client
(peut-être en effectuant une sélection des données pour
obtenir une fréquence de mesure inférieure à la sienne),
qui exportera les résultats en CSV et qui t'expédiera le
paquet une fois compressé.
Sauf que ta BAL devra être capable de recevoir "une certaine
taille" d'e-mails pour que ça passe (dépendante de la Qté de
données à transmettre).
Et de ton côté, tu peux tout à fait exécuter le scrip t inverse,
qui viendra récupérer l'attachment, le décompressera et
l'insérera dans ta propre DB.
Mais, encore une fois, c'est une moins bonne solution que de
recevoir les données au fil des mesures.
On Tue, 26 Mar 2013 17:09:15 +0100
Gabriel Euzet <geuzet@sqli.com> wrote:
> Par contre, comme je l'ai dit plus tôt : pas de connexion permanen te
> avec le site client.
Pourquoi? Ãa n'est pa le volume de données qui va boucher
le tuyauâ¦
> certains de nos clients ont un service
> informatique et l'exigeront. Tout ça me donne l'impression que la
> solution va relever de la bricole :-/
Pas spécialement, tu peux tout à fait lancer un script avec
un cron qui effectuera une requête sur la DB du client
(peut-être en effectuant une sélection des données pour
obtenir une fréquence de mesure inférieure à la sienne),
qui exportera les résultats en CSV et qui t'expédiera le
paquet une fois compressé.
Sauf que ta BAL devra être capable de recevoir "une certaine
taille" d'e-mails pour que ça passe (dépendante de la Qté de
données à transmettre).
Et de ton côté, tu peux tout à fait exécuter le scrip t inverse,
qui viendra récupérer l'attachment, le décompressera et
l'insérera dans ta propre DB.
Mais, encore une fois, c'est une moins bonne solution que de
recevoir les données au fil des mesures.
On Tue, 26 Mar 2013 17:09:15 +0100
Gabriel Euzet wrote:
> Par contre, comme je l'ai dit plus tôt : pas de connexion permanen te
> avec le site client.
Pourquoi? Ãa n'est pa le volume de données qui va boucher
le tuyauâ¦
> certains de nos clients ont un service
> informatique et l'exigeront. Tout ça me donne l'impression que la
> solution va relever de la bricole :-/
Pas spécialement, tu peux tout à fait lancer un script avec
un cron qui effectuera une requête sur la DB du client
(peut-être en effectuant une sélection des données pour
obtenir une fréquence de mesure inférieure à la sienne),
qui exportera les résultats en CSV et qui t'expédiera le
paquet une fois compressé.
Sauf que ta BAL devra être capable de recevoir "une certaine
taille" d'e-mails pour que ça passe (dépendante de la Qté de
données à transmettre).
Et de ton côté, tu peux tout à fait exécuter le scrip t inverse,
qui viendra récupérer l'attachment, le décompressera et
l'insérera dans ta propre DB.
Mais, encore une fois, c'est une moins bonne solution que de
recevoir les données au fil des mesures.
Le client héberge des données médicales. Il recherche le m aximum de
sécurité. Une porte d'entrée ouverte en moins !
mail ou FTP, le second serait mon préféré car plus facile Ã
automatiser à la réception. Mais l'idée est là et c'e st cela que je
sous-entendais par bricole. Je voulais dire qqch qui n'existe pas en
natif. Ta solution a le mérite de rester simple.
Restera à trouver
comment restaurer les données sur un système qui hébergera N (jusqu'Ã
50) sites équivalents. Zabbix propose la notion de groupe. Peut-à ªtre
pourra-t-on affecter un groupe lors de la restauration.
Le client héberge des données médicales. Il recherche le m aximum de
sécurité. Une porte d'entrée ouverte en moins !
mail ou FTP, le second serait mon préféré car plus facile Ã
automatiser à la réception. Mais l'idée est là et c'e st cela que je
sous-entendais par bricole. Je voulais dire qqch qui n'existe pas en
natif. Ta solution a le mérite de rester simple.
Restera à trouver
comment restaurer les données sur un système qui hébergera N (jusqu'Ã
50) sites équivalents. Zabbix propose la notion de groupe. Peut-à ªtre
pourra-t-on affecter un groupe lors de la restauration.
Le client héberge des données médicales. Il recherche le m aximum de
sécurité. Une porte d'entrée ouverte en moins !
mail ou FTP, le second serait mon préféré car plus facile Ã
automatiser à la réception. Mais l'idée est là et c'e st cela que je
sous-entendais par bricole. Je voulais dire qqch qui n'existe pas en
natif. Ta solution a le mérite de rester simple.
Restera à trouver
comment restaurer les données sur un système qui hébergera N (jusqu'Ã
50) sites équivalents. Zabbix propose la notion de groupe. Peut-à ªtre
pourra-t-on affecter un groupe lors de la restauration.
Le 26 mars 2013 17:21, Bzzz a écrit :
> On Tue, 26 Mar 2013 17:09:15 +0100
> Gabriel Euzet wrote:
>
> > Par contre, comme je l'ai dit plus tôt : pas de connexion
> > permanente avec le site client.
>
> Pourquoi? Ça n'est pa le volume de données qui va boucher
> le tuyau…
>
Le client héberge des données médicales. Il recherche le maximum de
sécurité. Une porte d'entrée ouverte en moins !
>
> > certains de nos clients ont un service
> > informatique et l'exigeront. Tout ça me donne l'impression que la
> > solution va relever de la bricole :-/
>
> Pas spécialement, tu peux tout à fait lancer un script avec
> un cron qui effectuera une requête sur la DB du client
> (peut-être en effectuant une sélection des données pour
> obtenir une fréquence de mesure inférieure à la sienne),
> qui exportera les résultats en CSV et qui t'expédiera le
> paquet une fois compressé.
>
> Sauf que ta BAL devra être capable de recevoir "une certaine
> taille" d'e-mails pour que ça passe (dépendante de la Qté de
> données à transmettre).
>
> Et de ton côté, tu peux tout à fait exécuter le script inverse,
> qui viendra récupérer l'attachment, le décompressera et
> l'insérera dans ta propre DB.
>
> Mais, encore une fois, c'est une moins bonne solution que de
> recevoir les données au fil des mesures.
>
mail ou FTP, le second serait mon préféré car plus facile à
automatiser à la réception. Mais l'idée est là et c'est cela que je
sous-entendais par bricole. Je voulais dire qqch qui n'existe pas en
natif. Ta solution a le mérite de rester simple. Restera à trouver
comment restaurer les données sur un système qui hébergera N (jusqu'à
50) sites équivalents. Zabbix propose la notion de groupe. Peut-être
pourra-t-on affecter un groupe lors de la restauration.
Merci pour tes éclaircissements :-)
Le 26 mars 2013 17:21, Bzzz <lazyvirus@gmx.com> a écrit :
> On Tue, 26 Mar 2013 17:09:15 +0100
> Gabriel Euzet <geuzet@sqli.com> wrote:
>
> > Par contre, comme je l'ai dit plus tôt : pas de connexion
> > permanente avec le site client.
>
> Pourquoi? Ça n'est pa le volume de données qui va boucher
> le tuyau…
>
Le client héberge des données médicales. Il recherche le maximum de
sécurité. Une porte d'entrée ouverte en moins !
>
> > certains de nos clients ont un service
> > informatique et l'exigeront. Tout ça me donne l'impression que la
> > solution va relever de la bricole :-/
>
> Pas spécialement, tu peux tout à fait lancer un script avec
> un cron qui effectuera une requête sur la DB du client
> (peut-être en effectuant une sélection des données pour
> obtenir une fréquence de mesure inférieure à la sienne),
> qui exportera les résultats en CSV et qui t'expédiera le
> paquet une fois compressé.
>
> Sauf que ta BAL devra être capable de recevoir "une certaine
> taille" d'e-mails pour que ça passe (dépendante de la Qté de
> données à transmettre).
>
> Et de ton côté, tu peux tout à fait exécuter le script inverse,
> qui viendra récupérer l'attachment, le décompressera et
> l'insérera dans ta propre DB.
>
> Mais, encore une fois, c'est une moins bonne solution que de
> recevoir les données au fil des mesures.
>
mail ou FTP, le second serait mon préféré car plus facile à
automatiser à la réception. Mais l'idée est là et c'est cela que je
sous-entendais par bricole. Je voulais dire qqch qui n'existe pas en
natif. Ta solution a le mérite de rester simple. Restera à trouver
comment restaurer les données sur un système qui hébergera N (jusqu'à
50) sites équivalents. Zabbix propose la notion de groupe. Peut-être
pourra-t-on affecter un groupe lors de la restauration.
Merci pour tes éclaircissements :-)
Le 26 mars 2013 17:21, Bzzz a écrit :
> On Tue, 26 Mar 2013 17:09:15 +0100
> Gabriel Euzet wrote:
>
> > Par contre, comme je l'ai dit plus tôt : pas de connexion
> > permanente avec le site client.
>
> Pourquoi? Ça n'est pa le volume de données qui va boucher
> le tuyau…
>
Le client héberge des données médicales. Il recherche le maximum de
sécurité. Une porte d'entrée ouverte en moins !
>
> > certains de nos clients ont un service
> > informatique et l'exigeront. Tout ça me donne l'impression que la
> > solution va relever de la bricole :-/
>
> Pas spécialement, tu peux tout à fait lancer un script avec
> un cron qui effectuera une requête sur la DB du client
> (peut-être en effectuant une sélection des données pour
> obtenir une fréquence de mesure inférieure à la sienne),
> qui exportera les résultats en CSV et qui t'expédiera le
> paquet une fois compressé.
>
> Sauf que ta BAL devra être capable de recevoir "une certaine
> taille" d'e-mails pour que ça passe (dépendante de la Qté de
> données à transmettre).
>
> Et de ton côté, tu peux tout à fait exécuter le script inverse,
> qui viendra récupérer l'attachment, le décompressera et
> l'insérera dans ta propre DB.
>
> Mais, encore une fois, c'est une moins bonne solution que de
> recevoir les données au fil des mesures.
>
mail ou FTP, le second serait mon préféré car plus facile à
automatiser à la réception. Mais l'idée est là et c'est cela que je
sous-entendais par bricole. Je voulais dire qqch qui n'existe pas en
natif. Ta solution a le mérite de rester simple. Restera à trouver
comment restaurer les données sur un système qui hébergera N (jusqu'à
50) sites équivalents. Zabbix propose la notion de groupe. Peut-être
pourra-t-on affecter un groupe lors de la restauration.
Merci pour tes éclaircissements :-)
On Tue, 26 Mar 2013 17:31:58 +0100
Gabriel Euzet wrote:
> Le client héberge des données médicales. Il recherche le maximum de
> sécurité. Une porte d'entrée ouverte en moins !
Et alors? Si tu marches en push, l'agent poussera ses données
vers ton svr sans possibilité de l'atteindre. Au pire une
règle du FW client pour laisser sortir le flux.
On Tue, 26 Mar 2013 17:31:58 +0100
Gabriel Euzet <geuzet@sqli.com> wrote:
> Le client héberge des données médicales. Il recherche le maximum de
> sécurité. Une porte d'entrée ouverte en moins !
Et alors? Si tu marches en push, l'agent poussera ses données
vers ton svr sans possibilité de l'atteindre. Au pire une
règle du FW client pour laisser sortir le flux.
On Tue, 26 Mar 2013 17:31:58 +0100
Gabriel Euzet wrote:
> Le client héberge des données médicales. Il recherche le maximum de
> sécurité. Une porte d'entrée ouverte en moins !
Et alors? Si tu marches en push, l'agent poussera ses données
vers ton svr sans possibilité de l'atteindre. Au pire une
règle du FW client pour laisser sortir le flux.
bonjour,
pourquoi vous ne regardez point du côté de glpi ou de p uppet ?
http://projects.puppetlabs.com/projects/1/wiki/Puppet_Windows
http://www.glpi-project.org/wiki/doku.php?id=fr:manuel:bonnespratiques
permet le déploiement de la solution ad'hoc choisie et
d'administrer
50 serveurs et ses clients
slt
bernard
bonjour,
pourquoi vous ne regardez point du côté de glpi ou de p uppet ?
http://projects.puppetlabs.com/projects/1/wiki/Puppet_Windows
http://www.glpi-project.org/wiki/doku.php?id=fr:manuel:bonnespratiques
permet le déploiement de la solution ad'hoc choisie et
d'administrer
50 serveurs et ses clients
slt
bernard
bonjour,
pourquoi vous ne regardez point du côté de glpi ou de p uppet ?
http://projects.puppetlabs.com/projects/1/wiki/Puppet_Windows
http://www.glpi-project.org/wiki/doku.php?id=fr:manuel:bonnespratiques
permet le déploiement de la solution ad'hoc choisie et
d'administrer
50 serveurs et ses clients
slt
bernard
Le 26 mars 2013 17:42, Bzzz
<mailto: a écrit :
On Tue, 26 Mar 2013 17:31:58 +0100
Gabriel Euzet <mailto: wrote:
> Le client héberge des données médicales. Il recherche le maximum de
> sécurité. Une porte d'entrée ouverte en moins !
Et alors? Si tu marches en push, l'agent poussera ses données
vers ton svr sans possibilité de l'atteindre. Au pire une
règle du FW client pour laisser sortir le flux.
Ok. J'avais donc mal compris. c'est la bonne solution. Dans le cas du
choix Zabbix, et si j'ai bien compris le produit, chaque serveur chez
un client sera un noeud et aura pour martre notre serveur. Tu confirmes ?
Le 26 mars 2013 17:42, Bzzz <lazyvirus@gmx.com
<mailto:lazyvirus@gmx.com>> a écrit :
On Tue, 26 Mar 2013 17:31:58 +0100
Gabriel Euzet <geuzet@sqli.com <mailto:geuzet@sqli.com>> wrote:
> Le client héberge des données médicales. Il recherche le maximum de
> sécurité. Une porte d'entrée ouverte en moins !
Et alors? Si tu marches en push, l'agent poussera ses données
vers ton svr sans possibilité de l'atteindre. Au pire une
règle du FW client pour laisser sortir le flux.
Ok. J'avais donc mal compris. c'est la bonne solution. Dans le cas du
choix Zabbix, et si j'ai bien compris le produit, chaque serveur chez
un client sera un noeud et aura pour martre notre serveur. Tu confirmes ?
Le 26 mars 2013 17:42, Bzzz
<mailto: a écrit :
On Tue, 26 Mar 2013 17:31:58 +0100
Gabriel Euzet <mailto: wrote:
> Le client héberge des données médicales. Il recherche le maximum de
> sécurité. Une porte d'entrée ouverte en moins !
Et alors? Si tu marches en push, l'agent poussera ses données
vers ton svr sans possibilité de l'atteindre. Au pire une
règle du FW client pour laisser sortir le flux.
Ok. J'avais donc mal compris. c'est la bonne solution. Dans le cas du
choix Zabbix, et si j'ai bien compris le produit, chaque serveur chez
un client sera un noeud et aura pour martre notre serveur. Tu confirmes ?
Le 27/03/2013 09:22, Gabriel Euzet a écrit :Le 26 mars 2013 17:42, Bzzz <mailto: >>
a écrit :
On Tue, 26 Mar 2013 17:31:58 +0100
Gabriel Euzet <mailto: wrote:
> Le client héberge des données médicales. Il recherc he le maximum de
> sécurité. Une porte d'entrée ouverte en moins !
Et alors? Si tu marches en push, l'agent poussera ses données
vers ton svr sans possibilité de l'atteindre. Au pire une
règle du FW client pour laisser sortir le flux.
Ok. J'avais donc mal compris. c'est la bonne solution. Dans le cas du
choix Zabbix, et si j'ai bien compris le produit, chaque serveur chez un
client sera un noeud et aura pour martre notre serveur. Tu confirmes ?
Oui. Chez les clients c'est un zabbix-proxy qui tourne, il récupà ¨re les
infos des machines du réseau du client, puis les envoient sur le zab bix
maitre qui est votre serveur.
Le 27/03/2013 09:22, Gabriel Euzet a écrit :
Le 26 mars 2013 17:42, Bzzz <lazyvirus@gmx.com <mailto:lazyvirus@gmx.com >>
a écrit :
On Tue, 26 Mar 2013 17:31:58 +0100
Gabriel Euzet <geuzet@sqli.com <mailto:geuzet@sqli.com>> wrote:
> Le client héberge des données médicales. Il recherc he le maximum de
> sécurité. Une porte d'entrée ouverte en moins !
Et alors? Si tu marches en push, l'agent poussera ses données
vers ton svr sans possibilité de l'atteindre. Au pire une
règle du FW client pour laisser sortir le flux.
Ok. J'avais donc mal compris. c'est la bonne solution. Dans le cas du
choix Zabbix, et si j'ai bien compris le produit, chaque serveur chez un
client sera un noeud et aura pour martre notre serveur. Tu confirmes ?
Oui. Chez les clients c'est un zabbix-proxy qui tourne, il récupà ¨re les
infos des machines du réseau du client, puis les envoient sur le zab bix
maitre qui est votre serveur.
Le 27/03/2013 09:22, Gabriel Euzet a écrit :Le 26 mars 2013 17:42, Bzzz <mailto: >>
a écrit :
On Tue, 26 Mar 2013 17:31:58 +0100
Gabriel Euzet <mailto: wrote:
> Le client héberge des données médicales. Il recherc he le maximum de
> sécurité. Une porte d'entrée ouverte en moins !
Et alors? Si tu marches en push, l'agent poussera ses données
vers ton svr sans possibilité de l'atteindre. Au pire une
règle du FW client pour laisser sortir le flux.
Ok. J'avais donc mal compris. c'est la bonne solution. Dans le cas du
choix Zabbix, et si j'ai bien compris le produit, chaque serveur chez un
client sera un noeud et aura pour martre notre serveur. Tu confirmes ?
Oui. Chez les clients c'est un zabbix-proxy qui tourne, il récupà ¨re les
infos des machines du réseau du client, puis les envoient sur le zab bix
maitre qui est votre serveur.
