pour créer une base postgres, j'ai fait un script bash
qui passe en user "root" par su puis en "postgres" mais il
s'arrête apres le "su - root"...
normal ?
Utiliser "su -c " avec expect ou sudo avec la bonne conf /etc/sudoers pour éxécuter les commandes à passer en root.
Voire carrément écrire le script, le placer dans un endroit accessible des utilisateurs et autoriser les utilisateurs à éxécuter le dit-script avec sudo.
C'est peut être plus "propre" que de laisser des mots de passe ou des appels à sudo complètement opaques dans le script.
C'est vraiment pas clair, mais si comme je le pense tu as collé ton su au milieu des autres commandes dans un même script, c'est normal que « ça n'aille pas plus loin ». su ("Substitute User") est fait pour ouvrir un shell sous une identité donnée, par défaut root. Fais un logout dans ce shell et tu verras que ton script exécutera le reste de tes commandes (mais pas en root, cela va de soi).
Tu peux utiliser su -c pour lancer ledit shell en mode non-interactif et lui spécifier la commande à exécuter.
l'utilisateur "a", depuis son shell bash, lance su.
le shell fork et execute su.
tu as deux processus : le shell est toujours là, et le su.
l'utilisateur associé au processus su passe à root (ou à un autre utilisateur), puis su invoque un shell.
tu as trois processus : le shell d'origine qui appartient toujours à "a", qui attend la fin de su, le su qui appartient à root qui attend la fin du shell invoqué, et le shell invoqué (qui appartient à root aussi donc) qui attend que tu tappes des commandes.
ce n'est pas la manière que tu avais imaginée, mais ça fait du sens du point de vue unix :
- si le shell d'origine passait à root, il faudrait une notion de pile de changement d'utilisateur, ou au moins une notion de "sortie" de changement d'utilisateur, qui n'existe pas
- tout est basé sur la notion de processus, la seule entorse à ma connaissance est fork, tout le reste agit sur le processus en cours, en particulier ici on invoque "su" avec l'appel système exec après fork, puis on change l'identité du processus avec les appels système setgid et setuid
# pas de su en bash ?
Posté par Jllc . Évalué à 2.
s'arrête apres le "su - root"...
normal ?
Peut-être qu'il attend tout simplement que l'utilisateur rentre le mot de passe root ?
Ce que je e pourra pas faire un script.
[^] # Re: pas de su en bash ?
Posté par zx81 . Évalué à 1.
je saisi bien le mdp, pour revenir au prompt ensuite... mais dans un
bash supplémentaire (un de plus que celui du login en faisant un "ps")
[^] # Re: pas de su en bash ?
Posté par Cereal Killer . Évalué à 1.
su --shell=/bin/bash dans cas.
# alternative
Posté par jerome (site web personnel) . Évalué à 3.
Voire carrément écrire le script, le placer dans un endroit accessible des utilisateurs et autoriser les utilisateurs à éxécuter le dit-script avec sudo.
C'est peut être plus "propre" que de laisser des mots de passe ou des appels à sudo complètement opaques dans le script.
# Sois plus clair.
Posté par Obsidian . Évalué à 4.
Tu peux utiliser su -c pour lancer ledit shell en mode non-interactif et lui spécifier la commande à exécuter.
Mieux, tu peux utiliser sudo.
[^] # Re: Sois plus clair.
Posté par Cereal Killer . Évalué à 1.
[^] # Re: Sois plus clair.
Posté par gc (site web personnel) . Évalué à 1.
l'utilisateur "a", depuis son shell bash, lance su.
le shell fork et execute su.
tu as deux processus : le shell est toujours là, et le su.
l'utilisateur associé au processus su passe à root (ou à un autre utilisateur), puis su invoque un shell.
tu as trois processus : le shell d'origine qui appartient toujours à "a", qui attend la fin de su, le su qui appartient à root qui attend la fin du shell invoqué, et le shell invoqué (qui appartient à root aussi donc) qui attend que tu tappes des commandes.
ce n'est pas la manière que tu avais imaginée, mais ça fait du sens du point de vue unix :
- si le shell d'origine passait à root, il faudrait une notion de pile de changement d'utilisateur, ou au moins une notion de "sortie" de changement d'utilisateur, qui n'existe pas
- tout est basé sur la notion de processus, la seule entorse à ma connaissance est fork, tout le reste agit sur le processus en cours, en particulier ici on invoque "su" avec l'appel système exec après fork, puis on change l'identité du processus avec les appels système setgid et setuid
[^] # Re: Sois plus clair.
Posté par Obsidian . Évalué à 3.
man su
et
http://www.google.fr/search?hl=fr&q=Substitute+User&btnG=Re(...)
[^] # Re: Sois plus clair.
Posté par zx81 . Évalué à 2.
Je crois que je vais être obligé de "compliquer" mon script :-((
Merci à tous ceux qui ont répondu.
[^] # Re: Sois plus clair.
Posté par Cyrille Hombecq . Évalué à 2.
ou avec un sudo script
plus d'info : man su, man sudo, man visudo, man sudoers
# autre solution :
Posté par Cyrille Hombecq . Évalué à 1.
createdb -U postgres <nom_de_la_base>
selon le contenu de ton fichier pg_hba.conf
plus d'info man createdb
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.