Bonjour.
Utilisateur (pas administrateur système) aujourd'hui avertis de système GNU/Linux, j'ai monté une petite machine uniquement en ligne de commande (pour l'exercice, mais aussi car c'est bien suffisant pour ce que je veux en faire). Mais si l'utilisation ne me pose pas de difficultés, un problème reste en suspend :
Comment fait un utilisateur pour demander l'arrêt de la machine en ligne de commande ?
Quelle est la «bonne» méthode ?
Ou en tout cas celle qui s'éloignera le moins d'une utilisation un peu puriste ?
Aujourd'hui j'en suis contraint à faire faire cette opération par l'administrateur.
NB : Cherchant la solution la plus standard, je ne précise volontairement pas ici (du moins dans la question initiale) la distribution spécifiquement utilisée.
# man shutdown man init (enfin, peut être plus avec systemd)
Posté par totof2000 . Évalué à 3. Dernière modification le 01 novembre 2016 à 20:09.
shutdown -h now (avec un sudo avant si tu n'es pas root ou si tu n'as pas les droits spécifiques pour arrêter la machine) te permet d'arrêter la machine. La page man de shutdown t'en dira plus (notamment les options équivalentes telles que -P, ou autres variantes).
[^] # Utilisateur et Administrateur
Posté par SlowBrain (site web personnel) . Évalué à 1.
C'est la méthode que j'utilise aujourd'hui : Passer en administrateur (root) ou demander à l'administrateur de faire (sudo), pour demander l'arrêt de la machine.
Mais je passe par cette méthode par l'élévation de privilège, et le mot de passe logiquement nécessaire.
C'est ce que je nomme l'«Arrêt par l'administrateur», or c'est plus un «Arrêt par l'utilisateur», sans être root et sans passer par sudo, que je chercherais.
La méthode que tu propose fonctionne car je suis en même temps l'utilisateur et l'administrateur de la machine. Mais qu'en serais il si je voulais mettre un second utilisateur, sans lui laisser le droit à l'administration, mais tout en lui laissant la possibilité d’arrêter la machine ?
(mais je comprend bien que l'action d'arrêter la machine soit, au moins historiquement, considérée comme une importante tâche d'administration)
[^] # Re: Utilisateur et Administrateur
Posté par gouttegd . Évalué à 2.
Si ConsoleKit est encore là (pas sûr vu qu’il est normalement remplacé par systemd-logind), un utilisateur (même non-root, du moment qu’il est connecté physiquement) peut appeler la méthode D-Bus
org.freedesktop.ConsoleKit.Manager.Stoppour arrêter le système.Depuis la ligne de commande, ça peut se faire avec dbus-send(1) :
Sur les systèmes où systemd-logind a remplacé ConsoleKit, la méthode équivalente est apparemment
org.freedesktop.login1.Manager.PowerOff. Je soupçonne que l’on doit pouvoir également utiliser simplementsystemctl halt(même en tant que simple utilisateur, encore une fois tant qu’il est physiquement connecté), mais n’utilisant pas systemd je ne peux être affirmatif.[^] # Re: Utilisateur et Administrateur
Posté par EauFroide . Évalué à 1. Dernière modification le 01 novembre 2016 à 21:12.
J'ai eu le même problème lorsque j'ai voulu coder une API de contrôle à distance de mes RPI.
Il y a moyen d'autoriser des commandes réservées à root en chipotant avec sudoers. Je saurais pas t'en dire plus, les tuto ne m'ont pas aidé quand j'ai voulu tenter cette solution ^ ^ (mais tout le monde m'a dit de passer par ce truc pour autoriser non pas la commande d’arrêt (par sécurité) mais un script dans lequel je lance la commande d’arrêt)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Utilisateur et Administrateur
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 0.
Les tutos, les tutos …. c'est de la merde les tutos, généralement fait par des mecs qui a la base ne comprennent pas comment les choses marchent et qui se retrouvent a publier leur "solution" trouvée le plus souvent par hasard ou en repompant un autre "tuto"…
Si tu veut savoir comment fonctionne sudo, et comment écrire un fichier sudoers:
*
man sudo*
man sudoersAlors oui c'est un peu long, mais au moins tout est expliqué, et au pire tu commence par regarder les exemples et adapter à tes besoins.
je vois pas bien l'avantage sécuritaire de faire un script qui lancerait la commande d'arrêt, au contraire, une couche de plus = un risque de plus, la possibilité de détourner ton script n'est pas a prendre à la légère
[^] # Re: Utilisateur et Administrateur
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Ha, le manuel de sudoers !
http://xkcd.com/1343/
# Un script
Posté par ComputingFroggy (site web personnel) . Évalué à 0.
Ah oui, ça c'est une bonne idée : un script qui donne les droits root avec seulement les droits d'exécution pour tous et qui effectuerait le shutdown
[^] # Re: Un script
Posté par SlowBrain (site web personnel) . Évalué à 1.
Heu.
Probable qu'il y ai un bout de script la dedans. Mais la question porte plus sur le contenu du script.
[^] # Re: Un script
Posté par totof2000 . Évalué à 6.
un groupe shudtdown, une conf dans /etc/sudoers.d/shutdown pour permettre d'exécuter la commande, et ajouter les utilisateurs pouvant arrêter la machine à ce groupe devrait amplement suffire (voir par exemple http://spencerstirling.com/computergeek/shutdown.html )
Pas besoin de script, ni d'autre délires à la dbus, systemd et compagnie.
# sudo shutdown
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Le plus simple, mettre ce qu'il faut dans ton
/etc/sudoerspour t'autoriser à faire ça :(ainsi que
shutdown, ouhaltetreboot: à ma connaissance, poweroff c'est pour tout arrêter puis éteindre l'ordinateur, reboot c'est pour tout arrêter puis redémarrer l'ordinateur, halt c'est pour tout arrêter, et, selon les implémentations, ne rien faire de plus ou éteindre l'ordinateur, et shutdown c'est un truc générique avec des options)Il y a eu, et il y a encore des moyens dits « propres » d'effectuer ce genre de tâche en tant qu'utilisateur, mais ça n'arrête pas de changer : c'était UPower qui marchait je ne sais comment, puis UPower2 qui s'utilisait avec un appel de machin D-Bus tout à fait imbitable, puis ConsoleKit (ou PoliciKit, je confonds toujours ces MachinKits), et maintenant peut-être un autre bidule à base de systemd qui est censé remplacer toutes ces merdes. Franchement, je préfère utiliser
sudo, parce que ça, je sais le régler, ça marche, ça répond à mon besoin et ça ne change pas tous les quatre matins.[^] # Re: sudo shutdown
Posté par gouttegd . Évalué à 3.
Ouais, on peut râler sur ces censurés de développeurs qui ont le culot de développer des trucs…
Ou alors on peut prendre un (tout petit) peu de temps pour essayer de comprendre à quoi ils servent.
UPower n’a jamais été en charge de l’extinction de la machine, et son fonctionnement n’a jamais été mystérieux pour quiconque lit la doc. C’est un service D-Bus qui donne accès aux informations sur l’état de l’alimentation du système (évitant ainsi d’aller fouiller directement dans
/sys/class/power_supply), informe les applications qui le souhaitent des changements de cet état (passage d’une alimentation sur secteur à une alimentation sur batterie par exemple), et fournit des méthodes pour commander la mise en veille et l’hibernation.Jamais entendu parler d’UPower2. Tu ne confonds pas avec UDisks et UDisks2 ?
ConsoleKit est un service de gestion des sessions utilisateur. PolicyKit est un service d’autorisation, par lequel un programme réalisant des tâches « privilégiées » peut mettre ses services à la disposition de programmes non-privilégiés.
En l’espèce, l’extinction de la machine nécessite des privilèges administrateurs. Au lieu d’acquérir de tels privilèges (via sudo ou assimilé), un utilisateur non-privilégié peut demander l’extinction au service ConsoleKit, qui vérifiera préalablement, via PolicyKit, que cet utilisateur est autorisé à le faire. Dans la configuration par défaut de PolicyKit et ConsoleKit, un utilisateur normal est autorisé à éteindre la machine s’il est physiquement connecté dessus (ça peut se changer pour ceux qui n’aimeraient pas cette idée).
systemd-logind remplace ConsoleKit pour gérer les sessions utilisateurs. Rien d’autre ne change.
[^] # Re: sudo shutdown
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Ouais, cool, donc si j'ai bien compris, pour mettre en veille, mettre en hibernation, éteindre ou redémarrer mon PC depuis un shell utilisateur, je dois faire appel à ConsoleKit qui va demander l'autorisation à PolicyKit, et l'un des deux, ou peut-être un troisième bidule, va effectivement faire le taf. Sauf que ConsoleKit est remplacé par un truc de systemd, donc je dois en fait faire appel à ce truc qui va demander l'autorisation à PolicyKit, et l'un des deux, ou peut-être un troisième bidule, va effectivement faire le taf.
Super, mais en pratique, pour faire ça, je tape quoi dans mon shell moi ?
[^] # Re: sudo shutdown
Posté par gouttegd . Évalué à 1.
J’ai donné la commande plus haut :
Alors, oui, ça fait peur, et je serais totalement incapable de sortir cette commande à brûle-pourpoint sans consulter la doc.
Mais
① C’est pour ça qu’on a inventé les scripts shell. Je ne tape jamais moi-même la commande ci-dessus, j’ai un script pour ça (ainsi que pour appeler les méthodes de mise en veille et d’hibernation).
② Il serait trivial d’écrire un programme (compilé, pas un script) dont la seule tâche serait d’appeler cette méthode D-Bus, c’est juste qu’apparemment personne n’en a jamais ressenti le besoin. Pourquoi ? Probablement parce que les principaux utilisateurs de ConsoleKit sont les environnements graphiques, et que fournir un outil en mode ligne de commande n’a semblé nécessaire à personne.
[^] # Re: sudo shutdown
Posté par totof2000 . Évalué à 4.
Ben c'est peut-être parce que ce n'est pas le but de ce genre d'outil, le mécanisme sudo + shutdown de base est ben plus simple à utiliser en CLI.
[^] # Re: sudo shutdown
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Ah, possible. C'est vrai que c'est super logique, un truc génial appelé UPower, qui ne s'occupe pas de l'arrêt, sauf quand l'arrêt en question est lié à une suspension sur disque. Désolé de m'y être trompé, suis-je bête !
Mais pas l'arrêt. Trop bien, ça sent le gros oubli en fait.
Ça doit être ça oui. Depuis, pour ce sujet de montage de périphériques amovibles, je suis passé à umount, ça marche bien, je suis content.
Bon, alors on va le laisser « gérer », quoi que ce terme puisse signifier.
Ça pour le coup c'est plutôt clair au moins.
[^] # Re: sudo shutdown
Posté par gouttegd . Évalué à 2.
Euh, umount, c’est l’outil classique de démontage. Tu veux parler de pmount ?
Sinon, moi j’utilise udisksctl (partie de UDisks2), ça marche bien, je suis content. Et je vois un certain intérêt à ce que l’outil que j’utilise en ligne de commande pour monter un périphérique amovible passe par le même mécanisme que les outils en mode graphique, plutôt que de passer par un mécanisme complètement différent.
Un coup de RTFM, peut-être ?
Avant que tu me dises qu’on n’a pas besoin de ConsoleKit pour ça : tout-à-fait, de la même façon qu’on n’a pas besoin de UPower pour gérer l’alimentation, de UDisks pour gérer les périphériques amovibles, de PolicyKit pour gérer les permissions, de systemd pour gérer les services, etc. Le but de tous ces outils n’a jamais été de permettre de faire des choses infaisables autrement, mais bien plutôt d’offrir des interfaces unifiées pour les faire, faisant abstraction des mécanismes sous-jacents.
[^] # Re: sudo shutdown
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Oulà, oui, pardon, je m'embrouille.
J'utilisais à une époque udisk. Puis c'est passé à UDisk2, la syntaxe a changée, et de façon assez chiante, il me semble que le périphérique à monter doit être précisé dans une option, ce qui me semble assez idiot. Entre le changement et cette syntaxe qui ne me plaisait pas, j'ai préféré passer à autre chose, de plus stable et plus simple.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.