PEBKAC pour l'école qui laisse des accès root aux étudiants !

Clairement, le pauvre prof n'y est pas pour grand chose, c'est les admins qui sont à blamer ...

Il y a une légère différence entre laisser les étudiants pouvoir éteindre les machines et leur donner des accès root complets.

De plus, expliquez-moi comment vous comptez installer des choses sur les PC sans être root ? Il y a des cours qui nécessitent pas mal d'installation.

Non, pour moi le gros PEBKAC est qu'une prof d'informatique ne cherche pas à diagnostiquer quoi que ce soit et hurle au virus au moindre probléme comme le ferait un gros noob

Parfois, on a besoin d'un accès root, comme précisé.
Le problème vient surtout du fait que toutes les machines ont le même mot de passe root.
Et puis... c'est pas difficile d'éteindre le serveur ssh.

Je ne vois pas pourquoi un cours de programmation nécessiterait de donner des droits aux étudiants. C'est le travail de l'admin d'installer ce qui est nécessaire, duh. C'est vrai qu'une toolchain C++ c'est tellement exotique.. clairement pebkac.

Un cours de réseaux ou d'administration système, à la limite... auquel cas on a des VMs, ou au moins une manière de réinstaller les postes a distance...

@b0fh : ça dépend, en prog système, on peut avoir besoin de droits d'admins...


@neeko : donner des droits root à des étudiants, c'est une des plus belles conneries qu'on puisse faire.
Si vraiment ils ont besoin d'être admins pour certaines tâches, ils font comme moi : ils apprennent dans une machine virtuelle sur laquelle ils ont tous les droits. Au moins, ils ne bousillent pas la machine physique, et la VM on s'en cogne, c'est l'affaire d'un fichier à re-déployer.

PEBKAC au prof pour demander la ré-install sans réfléchir, PEBKAC aux admins pour laisser des droits root à tout le monde.

@Quelqu'un : trop facile de critiquer quand on ne connait pas la situation. On a eu les droits d'admin toute l'année, on n'a flingué aucun poste.

Et à mon avis, ça prend moins de temps de redéployer un Linux que de se faire chier à configurer des VM, surtout quand on a besoin de bosser sur du réseau.

@b0fh : sauf que l'admin ne sait pas forcément ce qui sera nécessaire. Je rappelle qu'il arrive souvent que des professionnels fassent cours. Or, ces professionnels ont souvent le champ libre pour apprendre de la façon qu'ils souhaitent. Ce qui fait qu'ils vont faire utiliser des outils qu'ils veulent utiliser. En cours de réseau, on a du installer postfix, asterisk, zimbra, et j'en passe, et apprendre à le configurer. Tu peux m'expliquer comment tu fais pour les préinstaller et apprendre des choses aux étudiants ?

@neeko
Dans ton cas : machines virtuelles.


@Quelqu'un
"Si vraiment ils ont besoin d'être admins pour certaines tâches, ils font comme moi : ils apprennent dans une machine virtuelle sur laquelle ils ont tous les droits."
Sauf si tu développes en bas niveau (avoir accès à des infos hardware d'une carte Wi-Fi sur une VM, c'est pas possible, par exemple).

@neeko: possible sous linux en tout cas

Je ne vois vraiment pas pourquoi il est question d'accès root. shutdown peut tout à fait être accessible à n'importe quel utilisateur local, c'est même à mon sens logique : à partir du moment où un utilisateur a physiquement accès à la machine, parce qu'il est connecté directement dessus, il pourra l'éteindre si il veut alors autant lui donner le moyen de le faire proprement via shutdown plutôt que d'attendre qu'il débranche l'alim !

Après, la réaction de la prof, hem... J'espère que les admins n'ont pas aveuglement fait ce qu'elle demandait !

@Muf : j'ai déjà eu accès à un poste avec un compte tellement limité que je ne pouvais même pas l'éteindre (je ne sais plus où mais je me souviens bien du "vous ne disposez pas des autorisations nécessaires pour effectuer cette action").


@Fred : Comme l'a dit neeko, des vm ça peut être chiant à configurer. Pour nos cours de sécurité dont le but des tp était de pourir un système (on avait une Fedora d'installée) le prof ne s'était pas fait chier et réinstallait toutes les machines de la salle à distance avec un ghost en même pas 1/2 heures (à ce qu'il nous a dit).

Je ne vois vraiment pas pourquoi il est question d'accès root. shutdown peut tout à fait être accessible à n'importe quel utilisateur local, c'est même à mon sens logique : à partir du moment où un utilisateur a physiquement accès à la machine, parce qu'il est connecté directement dessus, il pourra l'éteindre si il veut alors autant lui donner le moyen de le faire proprement via shutdown plutôt que d'attendre qu'il débranche l'alim !

Après, la réaction de la prof, hem... J'espère que les admins n'ont pas aveuglement fait ce qu'elle demandait !

euh... y'a que moi qui ai percuté sur "tandis que camarades" ?

Ceux qui parle d'avoir les droits root devrait relir la commance et voir que c'est sous windows (Sous Linux, c'est pas shutdown, mais halt)
Donc evidemment qu'ils sont admin, c'est des PC windows, le genre de pc ou tout le monde est admin de base)

@Bhaal42 : "c'est des PC windows, le genre de pc ou tout le monde est admin de base)"
Ca dépend de la version de Windows, qui n'est pas précisée ici.

@Bhaal42 : http://www.linux-france.org/article/debutant/debutant-linux.html#shutdown ?
Je m'interroge sur ce site Linux-France.org, parlent ils de commandes Windows ?

Et moi, je connais la situation où le mec qui a des droits (même hyper-restreints) ne se prive pas pour faire le con. Alors, pour moi, compte limité par défaut et attribution de droits selon les personnes et besoins.
VM contre ghost, la question peut se poser. Accès root, non.

@Muf : Permettre à un utilisateur d'éteindre la machine n'est pas si logique. Celui qui coupe une machine sur laquelle je suis en train de travailler en SSH est passible de chaise électrique USB.

@Bhaal42 :
[root@Toto ~]# whereis shutdown
shutdown: /sbin/shutdown /etc/shutdown.allow
[root@Toto ~]# uname
Linux

C'est bel et bien de l'unix(-like) : sous windows les options utilisent (traditionnellement) "/" et non "-".

@Quelqu'un : Bloquer 'shutdown' n'évitera pas que quelqu'un éteigne ta machine et en plus tu risques de te retrouver avec une machine éteinte à la bourrin (oui, j'ai déjà vu des gens laisser systématiquement le bouton de l'UC enfoncé jusqu'à l'extinction brutale...). Si la machine est destinée à être utilisée à la fois en local et en distant, il vaut mieux informer (ou menacer :-) ) plutôt que d'essayer de mettre en place une interdiction impossible à faire respecter.


@Bhaal42: tu as à moitié raison, même si shutdown existe sous Linux, shutdown -s, c'est du Windows.

Effectivement, au temps pour moi.

@Muf : je ne me contente pas de refuser de donner des droits, je prend aussi la peine de menacer mes condamnés.
Mais donner le pouvoir à un utilisateur de faire quelque chose qu'il ne doit pas faire me parait un peu stupide.
Permettre de rebooter une machine windoze, alors qu'il est le seul dessus et qu'elle peut planter à tout moment, OK. Permettre d'éteindre une machine GNU/Linux ou FreeBSD sur laquelle il y z potentiellement 10 utilisateurs connectés, bof...
Celui qui veut vraiment m'emmerder, il lui suffit de débrancher la prise, mais personne n'éteindra par accident.

(suite)
Concernant la commande shutdown et le troll windoze/Linux, j'avais pas percuté sur le "-s" qui n'existe que sous windoze (ou alors n'est pas documentée dans "man shutdown"). Au temps pour moi.

@Quelqu'un : Bloquer 'shutdown' n'évitera pas que quelqu'un éteigne ta machine et en plus tu risques de te retrouver avec une machine éteinte à la bourrin (oui, j'ai déjà vu des gens laisser systématiquement le bouton de l'UC enfoncé jusqu'à l'extinction brutale...). Si la machine est destinée à être utilisée à la fois en local et en distant, il vaut mieux informer (ou menacer :-) ) plutôt que d'essayer de mettre en place une interdiction impossible à faire respecter.


@Bhaal42: tu as à moitié raison, même si shutdown existe sous Linux, shutdown -s, c'est du Windows.

Oups, il semblerait que j'ai fait une fausse manip (ou que recharger la page re-soumette aussi le commentaire?). Désolé pour le doublon...


@Quelqu'un : moui, je comprends. N'empêche, avoir une machine prévue pour être utilisée à la fois en local et en distant me semble être 1) un cas quand même très particulier et 2) pas une très bonne idée à priori. Il me semble plus logique que la politique par défaut soit d'autoriser shutdown à un utilisateur local et qu'ensuite, dans les rares cas qui le justifient, l'administrateur retire cette permission.