2. Je voudrais savoir, si le cas pr=E9c=E9dent fonctionne, si =E7a
fonctionne toujours dans l'hypoth=E8se o=F9 toto est un user ayant pour
shell /bin/false de m=EAme uid sur le client et le serveur, et que le
client et lanc=E9 par root avec un --owner --group. Dans ce cas, que
faudrait-il mettre dans les champs 'uid' et 'gid' du fichier de conf
du serveur ? toto ou root ?
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
Nicolas George
slespess wrote in message :
1. Je voudrais savoir si les users que l'on déclare dans le fichier secrets de rsync doivent forcément être des users système.
Non, aucune restriction. C'est une table complètement arbitraire de paires login/mot de passe.
2. Je voudrais savoir, si le cas précédent fonctionne, si ça fonctionne toujours dans l'hypothèse où toto est un user ayant pour shell /bin/false de même uid sur le client et le serveur, et que le client et lancé par root avec un --owner --group.
La configuration du serveur et l'UID du client n'ont vraiment aucune influence l'un sur l'autre.
slespess wrote in message
<d677f03b-4a0a-4f22-bcec-7b4f853267e5@d10g2000yqh.googlegroups.com>:
1. Je voudrais savoir si les users que l'on déclare dans le fichier
secrets de rsync doivent forcément être des users système.
Non, aucune restriction. C'est une table complètement arbitraire de paires
login/mot de passe.
2. Je voudrais savoir, si le cas précédent fonctionne, si ça
fonctionne toujours dans l'hypothèse où toto est un user ayant pour
shell /bin/false de même uid sur le client et le serveur, et que le
client et lancé par root avec un --owner --group.
La configuration du serveur et l'UID du client n'ont vraiment aucune
influence l'un sur l'autre.
1. Je voudrais savoir si les users que l'on déclare dans le fichier secrets de rsync doivent forcément être des users système.
Non, aucune restriction. C'est une table complètement arbitraire de paires login/mot de passe.
2. Je voudrais savoir, si le cas précédent fonctionne, si ça fonctionne toujours dans l'hypothèse où toto est un user ayant pour shell /bin/false de même uid sur le client et le serveur, et que le client et lancé par root avec un --owner --group.
La configuration du serveur et l'UID du client n'ont vraiment aucune influence l'un sur l'autre.
slespess
On 12 oct, 19:16, Nicolas George <nicolas$ wrote:
Ça fait des années que j'avais pas mis les pieds ici, et je constate qu'il y a toujours les mêmes têtes pour apporter leur aide :o)
> 1. Je voudrais savoir si les users que l'on déclare dans le fichier > secrets de rsync doivent forcément être des users système.
Non, aucune restriction. C'est une table complètement arbitraire de pai res login/mot de passe.
OK parfait o/
> 2. Je voudrais savoir, si le cas précédent fonctionne, si ça > fonctionne toujours dans l'hypothèse où toto est un user ayant pour > shell /bin/false de même uid sur le client et le serveur, et que le > client et lancé par root avec un --owner --group.
La configuration du serveur et l'UID du client n'ont vraiment aucune influence l'un sur l'autre.
En fait mon souci vient pas vraiment de l'UID, il vient du shell par défaut. Je pars de la supposition (peut-être fausse d'ailleurs) qu'un user avec un shell par défaut valant /bin/false ne peut pas lancer de scripts (ni rien du tout) depuis sa crontab. Avec une config comme ça, côté client, je serai donc obligé de pass er par root avec un --owner --group --perms. La crainte que j'ai c'est que si dans ma config serveur je spécifie un UID dont le shell par défaut est /bin/false, ça marche pas non plus. A priori j'aurai pas de problème vu que normalement les UID/GID indiqués dans la conf ne sont la que pour des questions de permissions pour l'accès au fichiers, mais bon, on sait jamais, je préférais demander au cas où.
Merci pour ta contribution en tout cas.
Cordialement,
Simon
On 12 oct, 19:16, Nicolas George <nicolas$geo...@salle-s.org> wrote:
Ça fait des années que j'avais pas mis les pieds ici, et je constate
qu'il y a toujours les mêmes têtes pour apporter leur aide :o)
> 1. Je voudrais savoir si les users que l'on déclare dans le fichier
> secrets de rsync doivent forcément être des users système.
Non, aucune restriction. C'est une table complètement arbitraire de pai res
login/mot de passe.
OK parfait o/
> 2. Je voudrais savoir, si le cas précédent fonctionne, si ça
> fonctionne toujours dans l'hypothèse où toto est un user ayant pour
> shell /bin/false de même uid sur le client et le serveur, et que le
> client et lancé par root avec un --owner --group.
La configuration du serveur et l'UID du client n'ont vraiment aucune
influence l'un sur l'autre.
En fait mon souci vient pas vraiment de l'UID, il vient du shell par
défaut. Je pars de la supposition (peut-être fausse d'ailleurs) qu'un
user avec un shell par défaut valant /bin/false ne peut pas lancer de
scripts (ni rien du tout) depuis sa crontab.
Avec une config comme ça, côté client, je serai donc obligé de pass er
par root avec un --owner --group --perms.
La crainte que j'ai c'est que si dans ma config serveur je spécifie un
UID dont le shell par défaut est /bin/false, ça marche pas non plus. A
priori j'aurai pas de problème vu que normalement les UID/GID indiqués
dans la conf ne sont la que pour des questions de permissions pour
l'accès au fichiers, mais bon, on sait jamais, je préférais demander
au cas où.
Ça fait des années que j'avais pas mis les pieds ici, et je constate qu'il y a toujours les mêmes têtes pour apporter leur aide :o)
> 1. Je voudrais savoir si les users que l'on déclare dans le fichier > secrets de rsync doivent forcément être des users système.
Non, aucune restriction. C'est une table complètement arbitraire de pai res login/mot de passe.
OK parfait o/
> 2. Je voudrais savoir, si le cas précédent fonctionne, si ça > fonctionne toujours dans l'hypothèse où toto est un user ayant pour > shell /bin/false de même uid sur le client et le serveur, et que le > client et lancé par root avec un --owner --group.
La configuration du serveur et l'UID du client n'ont vraiment aucune influence l'un sur l'autre.
En fait mon souci vient pas vraiment de l'UID, il vient du shell par défaut. Je pars de la supposition (peut-être fausse d'ailleurs) qu'un user avec un shell par défaut valant /bin/false ne peut pas lancer de scripts (ni rien du tout) depuis sa crontab. Avec une config comme ça, côté client, je serai donc obligé de pass er par root avec un --owner --group --perms. La crainte que j'ai c'est que si dans ma config serveur je spécifie un UID dont le shell par défaut est /bin/false, ça marche pas non plus. A priori j'aurai pas de problème vu que normalement les UID/GID indiqués dans la conf ne sont la que pour des questions de permissions pour l'accès au fichiers, mais bon, on sait jamais, je préférais demander au cas où.
Merci pour ta contribution en tout cas.
Cordialement,
Simon
Nicolas George
slespess wrote in message :
En fait mon souci vient pas vraiment de l'UID, il vient du shell par défaut. Je pars de la supposition (peut-être fausse d'ailleurs) qu'un user avec un shell par défaut valant /bin/false ne peut pas lancer de scripts (ni rien du tout) depuis sa crontab. Avec une config comme ça, côté client, je serai donc obligé de passer par root avec un --owner --group --perms.
Il me semblerait plus solide de faire le changement d'UID avant de lancer le client rsync, avec su ou équivalent.
La crainte que j'ai c'est que si dans ma config serveur je spécifie un UID dont le shell par défaut est /bin/false, ça marche pas non plus.
Essaie, ça prend trente secondes.
slespess wrote in message
<4955e4b8-ad2b-44ef-b19f-853ecc03a059@k19g2000yqc.googlegroups.com>:
En fait mon souci vient pas vraiment de l'UID, il vient du shell par
défaut. Je pars de la supposition (peut-être fausse d'ailleurs) qu'un
user avec un shell par défaut valant /bin/false ne peut pas lancer de
scripts (ni rien du tout) depuis sa crontab.
Avec une config comme ça, côté client, je serai donc obligé de passer
par root avec un --owner --group --perms.
Il me semblerait plus solide de faire le changement d'UID avant de lancer le
client rsync, avec su ou équivalent.
La crainte que j'ai c'est que si dans ma config serveur je spécifie un
UID dont le shell par défaut est /bin/false, ça marche pas non plus.
En fait mon souci vient pas vraiment de l'UID, il vient du shell par défaut. Je pars de la supposition (peut-être fausse d'ailleurs) qu'un user avec un shell par défaut valant /bin/false ne peut pas lancer de scripts (ni rien du tout) depuis sa crontab. Avec une config comme ça, côté client, je serai donc obligé de passer par root avec un --owner --group --perms.
Il me semblerait plus solide de faire le changement d'UID avant de lancer le client rsync, avec su ou équivalent.
La crainte que j'ai c'est que si dans ma config serveur je spécifie un UID dont le shell par défaut est /bin/false, ça marche pas non plus.
Essaie, ça prend trente secondes.
slespess
On 13 oct, 10:51, Nicolas George <nicolas$ wrote:
Il me semblerait plus solide de faire le changement d'UID avant de lancer le client rsync, avec su ou équivalent.
J'y ai pensé, mais... Toujours avec mon utilisateur toto avec un shell /bin/false, si je fais un $ su toto /ma/commande /ma/commande n'a pas l'air de s'exécuter correctement (j'ai changé les username/group/host, tutu est un user normal, j'ai mis . en 777), c'est pour ça que j'avais pris l'idée du --owner :
Tue Oct 13 - 12:56:30 :~/test $ ll total 2 -rwxr-xr-x 1 user group 36 Oct 13 12:54 script.sh
Tue Oct 13 - 12:56:37 :~/test $ su toto ./script.sh Password:
Tue Oct 13 - 12:56:48 :~/test $ ll total 2 -rwxr-xr-x 1 user group 36 Oct 13 12:54 script.sh
Tue Oct 13 - 13:02:05 :~/test $ su tutu ./script.sh Password:
Tue Oct 13 - 13:02:15 :~/test $ ll total 4 -rwxr-xr-x 1 user group 58 Oct 13 12:57 script.sh -rw-r----- 1 tutu grouptutu 5 Oct 13 13:02 toto.txt
Tue Oct 13 - 13:02:16 :~/test $
> La crainte que j'ai c'est que si dans ma config serveur je spécifie u n > UID dont le shell par défaut est /bin/false, ça marche pas non plus .
Essaie, ça prend trente secondes.
J'aimerais bien, mais non, c'est pour un problème au boulot, donc je dois ouvrir un ticket auprès de l'infogérant blablabla tout ça, y'en a au moins pour 1 heure :'(
Pour précision, je suis sur du Solaris 10 (sur fco.unix, c'est tout mou, alors je suis venu ici).
On 13 oct, 10:51, Nicolas George <nicolas$geo...@salle-s.org> wrote:
Il me semblerait plus solide de faire le changement d'UID avant de lancer le
client rsync, avec su ou équivalent.
J'y ai pensé, mais...
Toujours avec mon utilisateur toto avec un shell /bin/false, si je
fais un
$ su toto /ma/commande
/ma/commande n'a pas l'air de s'exécuter correctement (j'ai changé les
username/group/host, tutu est un user normal, j'ai mis . en 777),
c'est pour ça que j'avais pris l'idée du --owner :
Tue Oct 13 - 12:56:30
user@host:~/test $ ll
total 2
-rwxr-xr-x 1 user group 36 Oct 13 12:54 script.sh
Tue Oct 13 - 12:56:37
user@host:~/test $ su toto ./script.sh
Password:
Tue Oct 13 - 12:56:48
user@host:~/test $ ll
total 2
-rwxr-xr-x 1 user group 36 Oct 13 12:54 script.sh
Tue Oct 13 - 13:02:05
user@host:~/test $ su tutu ./script.sh
Password:
Tue Oct 13 - 13:02:15
user@host:~/test $ ll
total 4
-rwxr-xr-x 1 user group 58 Oct 13 12:57 script.sh
-rw-r----- 1 tutu grouptutu 5 Oct 13 13:02 toto.txt
Tue Oct 13 - 13:02:16
user@host:~/test $
> La crainte que j'ai c'est que si dans ma config serveur je spécifie u n
> UID dont le shell par défaut est /bin/false, ça marche pas non plus .
Essaie, ça prend trente secondes.
J'aimerais bien, mais non, c'est pour un problème au boulot, donc je
dois ouvrir un ticket auprès de l'infogérant blablabla tout ça, y'en a
au moins pour 1 heure :'(
Pour précision, je suis sur du Solaris 10 (sur fco.unix, c'est tout
mou, alors je suis venu ici).
Il me semblerait plus solide de faire le changement d'UID avant de lancer le client rsync, avec su ou équivalent.
J'y ai pensé, mais... Toujours avec mon utilisateur toto avec un shell /bin/false, si je fais un $ su toto /ma/commande /ma/commande n'a pas l'air de s'exécuter correctement (j'ai changé les username/group/host, tutu est un user normal, j'ai mis . en 777), c'est pour ça que j'avais pris l'idée du --owner :
Tue Oct 13 - 12:56:30 :~/test $ ll total 2 -rwxr-xr-x 1 user group 36 Oct 13 12:54 script.sh
Tue Oct 13 - 12:56:37 :~/test $ su toto ./script.sh Password:
Tue Oct 13 - 12:56:48 :~/test $ ll total 2 -rwxr-xr-x 1 user group 36 Oct 13 12:54 script.sh
Tue Oct 13 - 13:02:05 :~/test $ su tutu ./script.sh Password:
Tue Oct 13 - 13:02:15 :~/test $ ll total 4 -rwxr-xr-x 1 user group 58 Oct 13 12:57 script.sh -rw-r----- 1 tutu grouptutu 5 Oct 13 13:02 toto.txt
Tue Oct 13 - 13:02:16 :~/test $
> La crainte que j'ai c'est que si dans ma config serveur je spécifie u n > UID dont le shell par défaut est /bin/false, ça marche pas non plus .
Essaie, ça prend trente secondes.
J'aimerais bien, mais non, c'est pour un problème au boulot, donc je dois ouvrir un ticket auprès de l'infogérant blablabla tout ça, y'en a au moins pour 1 heure :'(
Pour précision, je suis sur du Solaris 10 (sur fco.unix, c'est tout mou, alors je suis venu ici).
