J'aimerai avoir votre avis : d'un pull ou d'un push depuis les
clients ? Quel setup aurait votre préférence ?
J'aimerai avoir votre avis : d'un pull ou d'un push depuis les
clients ? Quel setup aurait votre préférence ?
J'aimerai avoir votre avis : d'un pull ou d'un push depuis les
clients ? Quel setup aurait votre préférence ?
En deux mots, c'est un serveur qui "pulle" les clients à partir d'un cron.
Avantage :
- setup minimal sur les clients;
- centralisation des logs;
Désavantage :
- demande un serveur ssh sur tous les client;
Une autre option est de faire des pushes à partir des clients. Ce qui me
semble plus logique.
En deux mots, c'est un serveur qui "pulle" les clients à partir d'un cron.
Avantage :
- setup minimal sur les clients;
- centralisation des logs;
Désavantage :
- demande un serveur ssh sur tous les client;
Une autre option est de faire des pushes à partir des clients. Ce qui me
semble plus logique.
En deux mots, c'est un serveur qui "pulle" les clients à partir d'un cron.
Avantage :
- setup minimal sur les clients;
- centralisation des logs;
Désavantage :
- demande un serveur ssh sur tous les client;
Une autre option est de faire des pushes à partir des clients. Ce qui me
semble plus logique.
salut la liste,
Je suis en train de réfléchir à la meilleure manière de mettre en route un système de bakup basé sur rdiff-backup [1] et un serveur qui tourne sous Jessie.
rdiff-backup fournit dans sa doc' un setup où le serveur initie les backups [2].
En deux mots, c'est un serveur qui "pulle" les clients à partir d'un cron.
Avantage :
- setup minimal sur les clients;
- centralisation des logs;
Désavantage :
- demande un serveur ssh sur tous les client;
Une autre option est de faire des pushes à partir des clients. Ce qu i me semble plus logique.
J'aimerai avoir votre avis : d'un pull ou d'un push depuis les clients ? Quel setup aurait votre préférence ?
Bonne soirée.
Jean-Marc
salut la liste,
Je suis en train de réfléchir à la meilleure manière de mettre en route un système de bakup basé sur rdiff-backup [1] et un serveur qui tourne sous Jessie.
rdiff-backup fournit dans sa doc' un setup où le serveur initie les backups [2].
En deux mots, c'est un serveur qui "pulle" les clients à partir d'un cron.
Avantage :
- setup minimal sur les clients;
- centralisation des logs;
Désavantage :
- demande un serveur ssh sur tous les client;
Une autre option est de faire des pushes à partir des clients. Ce qu i me semble plus logique.
J'aimerai avoir votre avis : d'un pull ou d'un push depuis les clients ? Quel setup aurait votre préférence ?
Bonne soirée.
Jean-Marc <jean-marc@6jf.be>
salut la liste,
Je suis en train de réfléchir à la meilleure manière de mettre en route un système de bakup basé sur rdiff-backup [1] et un serveur qui tourne sous Jessie.
rdiff-backup fournit dans sa doc' un setup où le serveur initie les backups [2].
En deux mots, c'est un serveur qui "pulle" les clients à partir d'un cron.
Avantage :
- setup minimal sur les clients;
- centralisation des logs;
Désavantage :
- demande un serveur ssh sur tous les client;
Une autre option est de faire des pushes à partir des clients. Ce qu i me semble plus logique.
J'aimerai avoir votre avis : d'un pull ou d'un push depuis les clients ? Quel setup aurait votre préférence ?
Bonne soirée.
Jean-Marc
Que nenni ! Le serveur de sauvegarde doit être le moins exposé possible
car il est précieux. Il est donc largement préférable que le serveur de
sauvegarde se connecte sur les serveurs à sauvegarder que le contraire.
Et pour durcir un peu la configuration sur les serveurs sauvegardés, il
faut faire en sorte que la clé utilisée ne soit acceptée que depuis l'IP
du serveur de sauvegarde, que les connexions interactives depuis
celui-ci soient interdites et que les commandes exécutables dans ce
contexte soient limitées via un petit script de filtrage.
Que nenni ! Le serveur de sauvegarde doit être le moins exposé possible
car il est précieux. Il est donc largement préférable que le serveur de
sauvegarde se connecte sur les serveurs à sauvegarder que le contraire.
Et pour durcir un peu la configuration sur les serveurs sauvegardés, il
faut faire en sorte que la clé utilisée ne soit acceptée que depuis l'IP
du serveur de sauvegarde, que les connexions interactives depuis
celui-ci soient interdites et que les commandes exécutables dans ce
contexte soient limitées via un petit script de filtrage.
Que nenni ! Le serveur de sauvegarde doit être le moins exposé possible
car il est précieux. Il est donc largement préférable que le serveur de
sauvegarde se connecte sur les serveurs à sauvegarder que le contraire.
Et pour durcir un peu la configuration sur les serveurs sauvegardés, il
faut faire en sorte que la clé utilisée ne soit acceptée que depuis l'IP
du serveur de sauvegarde, que les connexions interactives depuis
celui-ci soient interdites et que les commandes exécutables dans ce
contexte soient limitées via un petit script de filtrage.
Que nenni ! Le serveur de sauvegarde doit être le moins expos é possible
car il est précieux. Il est donc largement préférable que le serveur de
sauvegarde se connecte sur les serveurs à sauvegarder que le contrai re.
Et pour durcir un peu la configuration sur les serveurs sauvegardés, il
faut faire en sorte que la clé utilisée ne soit acceptée q ue depuis l'IP
du serveur de sauvegarde, que les connexions interactives depuis
celui-ci soient interdites et que les commandes exécutables dans ce
contexte soient limitées via un petit script de filtrage.
Personnellement, j'utilise rdiff-backup ainsi pour sauvegarder depuis
des années une grosse vingtaine de serveurs et j'en suis pleinement
satisfait.
Sébastien
Que nenni ! Le serveur de sauvegarde doit être le moins expos é possible
car il est précieux. Il est donc largement préférable que le serveur de
sauvegarde se connecte sur les serveurs à sauvegarder que le contrai re.
Et pour durcir un peu la configuration sur les serveurs sauvegardés, il
faut faire en sorte que la clé utilisée ne soit acceptée q ue depuis l'IP
du serveur de sauvegarde, que les connexions interactives depuis
celui-ci soient interdites et que les commandes exécutables dans ce
contexte soient limitées via un petit script de filtrage.
Personnellement, j'utilise rdiff-backup ainsi pour sauvegarder depuis
des années une grosse vingtaine de serveurs et j'en suis pleinement
satisfait.
Sébastien
Que nenni ! Le serveur de sauvegarde doit être le moins expos é possible
car il est précieux. Il est donc largement préférable que le serveur de
sauvegarde se connecte sur les serveurs à sauvegarder que le contrai re.
Et pour durcir un peu la configuration sur les serveurs sauvegardés, il
faut faire en sorte que la clé utilisée ne soit acceptée q ue depuis l'IP
du serveur de sauvegarde, que les connexions interactives depuis
celui-ci soient interdites et que les commandes exécutables dans ce
contexte soient limitées via un petit script de filtrage.
Personnellement, j'utilise rdiff-backup ainsi pour sauvegarder depuis
des années une grosse vingtaine de serveurs et j'en suis pleinement
satisfait.
Sébastien
Un peu de détail avec ma compréhension de ce passage.
. connexion SSH restreinte à une connexion par clés uniquement;
. pas de connexion interactive = shell du user = /usr/sbin/nologin,
voire /bin/false;
. pour restreindre les commandes, il y a l'option 'command="..."'
à insérer dans .ssh/authorized_keys;
. pour l'IP ou le nom du host, l'option from="..." de ce même fichier;
. et on peut utiliser les options no-agent-forwarding et
no-port-forwarding;
Dernier point, le paquet base-passwd [1] fournit un user backup (UID 34).
Est-ce un bon candidat ou dois-je créer mon propre user ?
Un peu de détail avec ma compréhension de ce passage.
. connexion SSH restreinte à une connexion par clés uniquement;
. pas de connexion interactive = shell du user = /usr/sbin/nologin,
voire /bin/false;
. pour restreindre les commandes, il y a l'option 'command="..."'
à insérer dans .ssh/authorized_keys;
. pour l'IP ou le nom du host, l'option from="..." de ce même fichier;
. et on peut utiliser les options no-agent-forwarding et
no-port-forwarding;
Dernier point, le paquet base-passwd [1] fournit un user backup (UID 34).
Est-ce un bon candidat ou dois-je créer mon propre user ?
Un peu de détail avec ma compréhension de ce passage.
. connexion SSH restreinte à une connexion par clés uniquement;
. pas de connexion interactive = shell du user = /usr/sbin/nologin,
voire /bin/false;
. pour restreindre les commandes, il y a l'option 'command="..."'
à insérer dans .ssh/authorized_keys;
. pour l'IP ou le nom du host, l'option from="..." de ce même fichier;
. et on peut utiliser les options no-agent-forwarding et
no-port-forwarding;
Dernier point, le paquet base-passwd [1] fournit un user backup (UID 34).
Est-ce un bon candidat ou dois-je créer mon propre user ?
Que nenni ! Le serveur de sauvegarde doit être le moins exposé possible
car il est précieux. Il est donc largement préférable que le serveur de
sauvegarde se connecte sur les serveurs à sauvegarder que le contraire.
Et pour durcir un peu la configuration sur les serveurs sauvegardés, il
faut faire en sorte que la clé utilisée ne soit acceptée que depuis l'IP
du serveur de sauvegarde, que les connexions interactives depuis
celui-ci soient interdites et que les commandes exécutables dans ce
contexte soient limitées via un petit script de filtrage.
100% d'accord. Je fonctionne ainsi.
Que nenni ! Le serveur de sauvegarde doit être le moins exposé possible
car il est précieux. Il est donc largement préférable que le serveur de
sauvegarde se connecte sur les serveurs à sauvegarder que le contraire.
Et pour durcir un peu la configuration sur les serveurs sauvegardés, il
faut faire en sorte que la clé utilisée ne soit acceptée que depuis l'IP
du serveur de sauvegarde, que les connexions interactives depuis
celui-ci soient interdites et que les commandes exécutables dans ce
contexte soient limitées via un petit script de filtrage.
100% d'accord. Je fonctionne ainsi.
Que nenni ! Le serveur de sauvegarde doit être le moins exposé possible
car il est précieux. Il est donc largement préférable que le serveur de
sauvegarde se connecte sur les serveurs à sauvegarder que le contraire.
Et pour durcir un peu la configuration sur les serveurs sauvegardés, il
faut faire en sorte que la clé utilisée ne soit acceptée que depuis l'IP
du serveur de sauvegarde, que les connexions interactives depuis
celui-ci soient interdites et que les commandes exécutables dans ce
contexte soient limitées via un petit script de filtrage.
100% d'accord. Je fonctionne ainsi.
