Je vous soumets un problème que je n'arrive pas à résoudre.
Je sauvegarde régulièrement des données d'un poste distant
(serveurintra) par rsync sur ssh. Il n'est pas possible de se
connecter en ssh à serveurintra sous root : seuls quelques
utilisateurs peuvent le faire (ici, par exemple, truc). Je sais que
la pertinence d'une telle pratique est discutable mais, pour
l'instant, je ne veux pas toucher à cette limitation (ne serait-ce
que pour trouver comment contourner mon problème).
Or, parmi les données que je veux sauvegarder, certaines, sous /etc,
ne sont lisibles que par root...
Voici la commande que j'utilise :
rsync -avze ssh
truc@serveurintra:/etc/ /home/truc/sauvegardes/serveurintra/etc/
Évidemment, rsync renvoie des messages d'erreur comme :
rsync: send_files failed to open "/etc/sudoers": Permission denied
(13)
Bref, comment contourner le problème, à part en créant un groupe admin
auquel appartiendrait truc et qui aurait les droits en lecture pour
tous les fichiers de serveurintra:/etc/ ? Une telle solution me gêne
car certains fichiers ne devraient être accessibles qu'à root:root.
De plus, je ne sache pas qu'on puisse donner un même fichier à
plusieurs groupes (peut-être avec les ACL, auxquels je ne connais pas
grand-chose).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
SauronDeMordor
en configurant un serveur rsyncd et en lui donnat les permission dessus.
Bonjour,
Je vous soumets un problème que je n'arrive pas à résoudre.
Je sauvegarde régulièrement des données d'un poste distant (serveurintra) par rsync sur ssh. Il n'est pas possible de se connecter en ssh à serveurintra sous root : seuls quelques utilisateurs peuvent le faire (ici, par exemple, truc). Je sais que la pertinence d'une telle pratique est discutable mais, pour l'instant, je ne veux pas toucher à cette limitation (ne serait-ce que pour trouver comment contourner mon problème).
Or, parmi les données que je veux sauvegarder, certaines, sous /etc, ne sont lisibles que par root...
Voici la commande que j'utilise : rsync -avze ssh :/etc/ /home/truc/sauvegardes/serveurintra/etc/
Évidemment, rsync renvoie des messages d'erreur comme : rsync: send_files failed to open "/etc/sudoers": Permission denied (13)
Bref, comment contourner le problème, à part en créant un groupe admin auquel appartiendrait truc et qui aurait les droits en lecture pour tous les fichiers de serveurintra:/etc/ ? Une telle solution me gêne car certains fichiers ne devraient être accessibles qu'à root:root. De plus, je ne sache pas qu'on puisse donner un même fichier à plusieurs groupes (peut-être avec les ACL, auxquels je ne connais pas grand-chose).
Ou alors, avec sudo ?
Merci de vos idées.
en configurant un serveur rsyncd et en lui donnat les permission dessus.
Bonjour,
Je vous soumets un problème que je n'arrive pas à résoudre.
Je sauvegarde régulièrement des données d'un poste distant
(serveurintra) par rsync sur ssh. Il n'est pas possible de se
connecter en ssh à serveurintra sous root : seuls quelques
utilisateurs peuvent le faire (ici, par exemple, truc). Je sais que
la pertinence d'une telle pratique est discutable mais, pour
l'instant, je ne veux pas toucher à cette limitation (ne serait-ce
que pour trouver comment contourner mon problème).
Or, parmi les données que je veux sauvegarder, certaines, sous /etc,
ne sont lisibles que par root...
Voici la commande que j'utilise :
rsync -avze ssh
truc@serveurintra:/etc/ /home/truc/sauvegardes/serveurintra/etc/
Évidemment, rsync renvoie des messages d'erreur comme :
rsync: send_files failed to open "/etc/sudoers": Permission denied
(13)
Bref, comment contourner le problème, à part en créant un groupe admin
auquel appartiendrait truc et qui aurait les droits en lecture pour
tous les fichiers de serveurintra:/etc/ ? Une telle solution me gêne
car certains fichiers ne devraient être accessibles qu'à root:root.
De plus, je ne sache pas qu'on puisse donner un même fichier à
plusieurs groupes (peut-être avec les ACL, auxquels je ne connais pas
grand-chose).
en configurant un serveur rsyncd et en lui donnat les permission dessus.
Bonjour,
Je vous soumets un problème que je n'arrive pas à résoudre.
Je sauvegarde régulièrement des données d'un poste distant (serveurintra) par rsync sur ssh. Il n'est pas possible de se connecter en ssh à serveurintra sous root : seuls quelques utilisateurs peuvent le faire (ici, par exemple, truc). Je sais que la pertinence d'une telle pratique est discutable mais, pour l'instant, je ne veux pas toucher à cette limitation (ne serait-ce que pour trouver comment contourner mon problème).
Or, parmi les données que je veux sauvegarder, certaines, sous /etc, ne sont lisibles que par root...
Voici la commande que j'utilise : rsync -avze ssh :/etc/ /home/truc/sauvegardes/serveurintra/etc/
Évidemment, rsync renvoie des messages d'erreur comme : rsync: send_files failed to open "/etc/sudoers": Permission denied (13)
Bref, comment contourner le problème, à part en créant un groupe admin auquel appartiendrait truc et qui aurait les droits en lecture pour tous les fichiers de serveurintra:/etc/ ? Une telle solution me gêne car certains fichiers ne devraient être accessibles qu'à root:root. De plus, je ne sache pas qu'on puisse donner un même fichier à plusieurs groupes (peut-être avec les ACL, auxquels je ne connais pas grand-chose).
Ou alors, avec sudo ?
Merci de vos idées.
Vincent Ramos
SauronDeMordor a écrit dans <d6fob9$slt$ :
en configurant un serveur rsyncd et en lui donnat les permission dessus.
Merci, mais ce n'est pas possible : je n'ai pas la possibilité d'ouvrir d'autres ports du routeur que ceux qui le sont déjà...
SauronDeMordor a écrit dans <d6fob9$slt$1@s1.news.oleane.net> :
en configurant un serveur rsyncd et en lui donnat les permission
dessus.
Merci, mais ce n'est pas possible : je n'ai pas la possibilité
d'ouvrir d'autres ports du routeur que ceux qui le sont déjà...
en configurant un serveur rsyncd et en lui donnat les permission dessus.
Merci, mais ce n'est pas possible : je n'ai pas la possibilité d'ouvrir d'autres ports du routeur que ceux qui le sont déjà...
Bob qui Trolle
Vincent Ramos wrote:
je ne sache pas qu'on puisse donner un même fichier à plusieurs groupes
On peut (peut-être) utiliser les groupes secondaires pour ça ?
Sinon, pour la question que tu évoques, en ce qui me concerne, j'utilise amanda (.org), lequel passe par un groupe qui peut lire la device qui porte les fichiers sensibles par l'intermédiaie des droits du groupe sur du device. La question de fond (sauvegarder des fichiers sensibles) serait certainement une bonne question pour fr.comp.storage ?
Sinon, classiquement, l'UID propriétaire d'un processus réalisant des sauvegardes est souvent une UID différent de celles employées par les utilisateurs interactifs, ne serait-ce que parce que, précisement, il faut bien sauvegarder des fichiers dont on veut interidre la lecture aux utilisateurs interactifs.
Vincent Ramos wrote:
je ne sache pas qu'on puisse donner un même fichier à
plusieurs groupes
On peut (peut-être) utiliser les groupes secondaires pour ça ?
Sinon, pour la question que tu évoques, en ce qui me concerne, j'utilise
amanda (.org), lequel passe par un groupe qui peut lire la device qui
porte les fichiers sensibles par l'intermédiaie des droits du groupe sur
du device. La question de fond (sauvegarder des fichiers sensibles)
serait certainement une bonne question pour fr.comp.storage ?
Sinon, classiquement, l'UID propriétaire d'un processus réalisant des
sauvegardes est souvent une UID différent de celles employées par les
utilisateurs interactifs, ne serait-ce que parce que, précisement, il
faut bien sauvegarder des fichiers dont on veut interidre la lecture aux
utilisateurs interactifs.
je ne sache pas qu'on puisse donner un même fichier à plusieurs groupes
On peut (peut-être) utiliser les groupes secondaires pour ça ?
Sinon, pour la question que tu évoques, en ce qui me concerne, j'utilise amanda (.org), lequel passe par un groupe qui peut lire la device qui porte les fichiers sensibles par l'intermédiaie des droits du groupe sur du device. La question de fond (sauvegarder des fichiers sensibles) serait certainement une bonne question pour fr.comp.storage ?
Sinon, classiquement, l'UID propriétaire d'un processus réalisant des sauvegardes est souvent une UID différent de celles employées par les utilisateurs interactifs, ne serait-ce que parce que, précisement, il faut bien sauvegarder des fichiers dont on veut interidre la lecture aux utilisateurs interactifs.
Vincent Ramos
Bob qui Trolle a écrit dans <428c2424$0$22978$ :
On peut (peut-être) utiliser les groupes secondaires pour ça ?
Je ne connais pas. Google s'impose...
Bob qui Trolle a écrit dans <428c2424$0$22978$636a15ce@news.free.fr> :
On peut (peut-être) utiliser les groupes secondaires pour ça ?
On peut (peut-être) utiliser les groupes secondaires pour ça ?
Je ne connais pas. Google s'impose...
Vincent Ramos
Vincent Ramos a écrit dans <428e6a6f$0$6502$ :
On peut (peut-être) utiliser les groupes secondaires pour ça ?
Je ne connais pas.
Ah ben si, en fait.
Mais cela ne résout pas bien mon problème (je laisse amanda de côté pour l'instant, mais ça a l'air intéressant) : je ne voudrais pas changer l'appartenance des fichiers ni faire en sorte que l'identité sous laquelle je me connecte appartienne aux groupes root, shadow, etc. Or, si /etc/shadow est -rw-r----- 1 root shadow, je ne vois pas ce que je peux faire de mieux.
Vincent Ramos a écrit dans <428e6a6f$0$6502$636a15ce@news.free.fr> :
On peut (peut-être) utiliser les groupes secondaires pour ça ?
Je ne connais pas.
Ah ben si, en fait.
Mais cela ne résout pas bien mon problème (je laisse amanda de côté
pour l'instant, mais ça a l'air intéressant) : je ne voudrais pas
changer l'appartenance des fichiers ni faire en sorte que l'identité
sous laquelle je me connecte appartienne aux groupes root, shadow,
etc. Or, si /etc/shadow est -rw-r----- 1 root shadow, je ne vois pas
ce que je peux faire de mieux.
On peut (peut-être) utiliser les groupes secondaires pour ça ?
Je ne connais pas.
Ah ben si, en fait.
Mais cela ne résout pas bien mon problème (je laisse amanda de côté pour l'instant, mais ça a l'air intéressant) : je ne voudrais pas changer l'appartenance des fichiers ni faire en sorte que l'identité sous laquelle je me connecte appartienne aux groupes root, shadow, etc. Or, si /etc/shadow est -rw-r----- 1 root shadow, je ne vois pas ce que je peux faire de mieux.
