Enregistrement des commandes tappées

Rakotomandimby (R12y) Mihamina

24/05/2005 à 22:23

( Tue, 24 May 2005 21:57:55 +0200 ) Jerome Lambert :

C'est une question de contexte.
Je suis administrateur et je décide de qui doit faire quoi.
Mauvaise réponse: un administrateur est au service des administrés, et

c'est donc à lui de se débrouiller pour que le gusse puisse faire ce
qu'il veut avec la machine (!= faire n'importe quoi).

Pas sur celle en production.
Je suis entièrement à sa disposition pour réparer ce qu'il a cassé, et
même pour l'aider à interpréter les logs avec lui sur la machine de
developpement. On ne touche pas à "the" machine.

Bon alors on ne fait pas de developpement sur des machines de prod.
Et dans un environnement de développement, justement, on fait comment?

;-)

Là je lui laisse carte blanche. Mais on convient que c'est un
environnement de developpement.
Typiquement, installer les headers est necessaire sur une machine de dev.

Même si sur le fond je suis d'accord avec toi, je dois reconnaitre que
ton contradicteur est plus proche de ce qui se fait dans la vraie vie.

Ok.

OUI, on donne parfois le mot de passe root à certaines personnes en
sachant pertinement que le risque que cette personne casse tout est
assez élevé, et OUI, c'est *MAL*, mais il y a des situations où on
n'a pas le choix...

D'accord. Il y a des solutions, comme sudo, ou plein d'autres... le fait
de dire une partie des faits ça laisse les gens tergiverser... Et comme
les admins ça a beaucoup d'imagination :-)

--
Mirroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)

Jerome Lambert

25/05/2005 à 00:52

( Tue, 24 May 2005 21:57:55 +0200 ) Jerome Lambert :

C'est une question de contexte.
Je suis administrateur et je décide de qui doit faire quoi.

Mauvaise réponse: un administrateur est au service des administrés, et
c'est donc à lui de se débrouiller pour que le gusse puisse faire ce
qu'il veut avec la machine (!= faire n'importe quoi).

Pas sur celle en production.
Je suis entièrement à sa disposition pour réparer ce qu'il a cassé, et
même pour l'aider à interpréter les logs avec lui sur la machine de
developpement. On ne touche pas à "the" machine.

Tu ne comprends pas: je reste général. Si ton administré a *absolument*
besoin d'un programme en version x.y ou de l'une ou l'autre
fonctionnalité, c'est à l'administrateur de l'implémenter, même si lui
n'en voit pas l'intérêt.

"Le but recherché (de l'administration système) est de fournir un
environnement offrant aux utilisateurs le moyen d'effectuer leurs
travaux, de la manière la plus agréable et efficace possible, en tenant
compte des contraintes liées à la sécurité, aux droits des autres
utilisateurs, aux limites de la machine et aux réalités et aux exigences
de la communauté dans laquelle ils évoluent tous."
(A.Frisch, "Les bases de l'administration système", O'Reilly)

C'est un bouquin que tu ferais bien de lire, non pas pour son contenu
technique, mais plutot pour les conseils relatifs à la gestion humaine.
En gros, un administrateur s'occupe essentiellement des utilisateurs,
pas des machines...

(...)

OUI, on donne parfois le mot de passe root à certaines personnes en
sachant pertinement que le risque que cette personne casse tout est
assez élevé, et OUI, c'est *MAL*, mais il y a des situations où on
n'a pas le choix...

D'accord. Il y a des solutions, comme sudo, ou plein d'autres... le fait
de dire une partie des faits ça laisse les gens tergiverser... Et comme
les admins ça a beaucoup d'imagination :-)

Même pas besoin: p.ex. le serveur de mail qui déconne quand on est à
1000km de la machine et sans ordinateurs sous la main (pour faire du SSH
p.ex.), ou Mr Bidule qui doit *absolument* installer tel brol sur son
portable pour sa présentation du lendemain, et qui s'en rend compte chez
lui à 21H (et t'appelle sur le mobile de la société), bref des
situations où le plus efficace (à cours terme) est de dire "le mot de
passe root est ******** et débrouille-toi pour ne pas faire trop de dégats".
Et dans la vie réelle, cela arrive fréquemment...

( Tue, 24 May 2005 21:57:55 +0200 ) Jerome Lambert :

C'est une question de contexte.
Je suis administrateur et je décide de qui doit faire quoi.

Mauvaise réponse: un administrateur est au service des administrés, et
c'est donc à lui de se débrouiller pour que le gusse puisse faire ce
qu'il veut avec la machine (!= faire n'importe quoi).

Pas sur celle en production.
Je suis entièrement à sa disposition pour réparer ce qu'il a cassé, et
même pour l'aider à interpréter les logs avec lui sur la machine de
developpement. On ne touche pas à "the" machine.

Tu ne comprends pas: je reste général. Si ton administré a *absolument*
besoin d'un programme en version x.y ou de l'une ou l'autre
fonctionnalité, c'est à l'administrateur de l'implémenter, même si lui
n'en voit pas l'intérêt.

"Le but recherché (de l'administration système) est de fournir un
environnement offrant aux utilisateurs le moyen d'effectuer leurs
travaux, de la manière la plus agréable et efficace possible, en tenant
compte des contraintes liées à la sécurité, aux droits des autres
utilisateurs, aux limites de la machine et aux réalités et aux exigences
de la communauté dans laquelle ils évoluent tous."
(A.Frisch, "Les bases de l'administration système", O'Reilly)

C'est un bouquin que tu ferais bien de lire, non pas pour son contenu
technique, mais plutot pour les conseils relatifs à la gestion humaine.
En gros, un administrateur s'occupe essentiellement des utilisateurs,
pas des machines...

(...)

OUI, on donne parfois le mot de passe root à certaines personnes en
sachant pertinement que le risque que cette personne casse tout est
assez élevé, et OUI, c'est *MAL*, mais il y a des situations où on
n'a pas le choix...

D'accord. Il y a des solutions, comme sudo, ou plein d'autres... le fait
de dire une partie des faits ça laisse les gens tergiverser... Et comme
les admins ça a beaucoup d'imagination :-)

Même pas besoin: p.ex. le serveur de mail qui déconne quand on est à
1000km de la machine et sans ordinateurs sous la main (pour faire du SSH
p.ex.), ou Mr Bidule qui doit *absolument* installer tel brol sur son
portable pour sa présentation du lendemain, et qui s'en rend compte chez
lui à 21H (et t'appelle sur le mobile de la société), bref des
situations où le plus efficace (à cours terme) est de dire "le mot de
passe root est ******** et débrouille-toi pour ne pas faire trop de dégats".
Et dans la vie réelle, cela arrive fréquemment...

Vous avez filtré cet utilisateur ! Consultez son message

( Tue, 24 May 2005 21:57:55 +0200 ) Jerome Lambert :

C'est une question de contexte.
Je suis administrateur et je décide de qui doit faire quoi.

Mauvaise réponse: un administrateur est au service des administrés, et
c'est donc à lui de se débrouiller pour que le gusse puisse faire ce
qu'il veut avec la machine (!= faire n'importe quoi).

Pas sur celle en production.
Je suis entièrement à sa disposition pour réparer ce qu'il a cassé, et
même pour l'aider à interpréter les logs avec lui sur la machine de
developpement. On ne touche pas à "the" machine.

Tu ne comprends pas: je reste général. Si ton administré a *absolument*
besoin d'un programme en version x.y ou de l'une ou l'autre
fonctionnalité, c'est à l'administrateur de l'implémenter, même si lui
n'en voit pas l'intérêt.

"Le but recherché (de l'administration système) est de fournir un
environnement offrant aux utilisateurs le moyen d'effectuer leurs
travaux, de la manière la plus agréable et efficace possible, en tenant
compte des contraintes liées à la sécurité, aux droits des autres
utilisateurs, aux limites de la machine et aux réalités et aux exigences
de la communauté dans laquelle ils évoluent tous."
(A.Frisch, "Les bases de l'administration système", O'Reilly)

C'est un bouquin que tu ferais bien de lire, non pas pour son contenu
technique, mais plutot pour les conseils relatifs à la gestion humaine.
En gros, un administrateur s'occupe essentiellement des utilisateurs,
pas des machines...

(...)

OUI, on donne parfois le mot de passe root à certaines personnes en
sachant pertinement que le risque que cette personne casse tout est
assez élevé, et OUI, c'est *MAL*, mais il y a des situations où on
n'a pas le choix...

D'accord. Il y a des solutions, comme sudo, ou plein d'autres... le fait
de dire une partie des faits ça laisse les gens tergiverser... Et comme
les admins ça a beaucoup d'imagination :-)

Même pas besoin: p.ex. le serveur de mail qui déconne quand on est à
1000km de la machine et sans ordinateurs sous la main (pour faire du SSH
p.ex.), ou Mr Bidule qui doit *absolument* installer tel brol sur son
portable pour sa présentation du lendemain, et qui s'en rend compte chez
lui à 21H (et t'appelle sur le mobile de la société), bref des
situations où le plus efficace (à cours terme) est de dire "le mot de
passe root est ******** et débrouille-toi pour ne pas faire trop de dégats".
Et dans la vie réelle, cela arrive fréquemment...

Jérémy JUST

25/05/2005 à 01:38

On Tue, 24 May 2005 21:35:59 +0200
"Rakotomandimby (R12y) Mihamina"
wrote:

on ne fait pas de developpement sur des machines de prod.

Quand on passe une application du développement à la prod, il y a bien
un moment où on n'est pas sûr que ça va marcher, non?

(pareil quand on a une pré-prod entre le dév et la prod, même si ça
réduit les risques)

--
Jérémy JUST

DINH Viêt Hoà

25/05/2005 à 01:55

on ne fait pas de developpement sur des machines de prod.

Quand on passe une application du développement à la prod, il y a bien
un moment où on n'est pas sûr que ça va marcher, non?

c'est pour ça qu'il y a les machines de recette :)

que de vocabulaire 01 !

--
DINH V. Hoa,

"un joint tu vas pas avoir ton cerveau détruit à la longue" -- b.

Erwann ABALEA

25/05/2005 à 07:05

On Tue, 24 May 2005, Jerome Lambert wrote:

( Tue, 24 May 2005 21:08:10 +0200 ) SauronDeMordor :

je lueur repond que vous n avez aucune idees des contraintes d un admin sys
dans son taf de tous les jours.

C'est une question de contexte.
Je suis administrateur et je décide de qui doit faire quoi.

Mauvaise réponse: un administrateur est au service des administrés, et
c'est donc à lui de se débrouiller pour que le gusse puisse faire ce
qu'il veut avec la machine (!= faire n'importe quoi).

Pas tout à fait. On sépare bien les machines de développement des machines
de production. En général, on a des exigences de disponibilité sur les
machines de prod, des créneaux de maintenance, des procédures d'accès, de
backup/recovery, etc. Donner un accès root à quelqu'un qui n'a pas à
respecter ces contraintes est une très mauvaise idée. En cas de problème,
c'est le vrai admin qui aura à rendre des comptes à sa direction.

L'administrateur n'est pas au service des administrés, il doit leur
fournir un service (=uptime) de qualité, et c'est à l'équipe de dev
de fournir l'autre qualité de service (=fonctionnalités).

sys avec des vrais sontraintes de prod/d exploitation et de gestion d un
parc de serveur.

Bon alors on ne fait pas de developpement sur des machines de prod.

Et dans un environnement de développement, justement, on fait comment? ;-)

Dans un environnement de développement, c'est pareil. Pas besoin d'être
root pour lancer gcc, et les rares fois où on a besoin d'être root (lancer
un service qui écoute sur un port <1024 par exemple), sudo fait très bien
le boulot.

Quant à l'argument d'une mise en prod par l'équipe de dev, il ne faut pas
mélanger les responsabilités. C'est à l'équipe de prod de faire une mise
en prod, et à personne d'autre. Que ça se traduise par une ouverture du
tiroir de CD, un mount, et un ./install.sh, c'est pas grave, il s'agit
d'avoir quelque chose de reproductible par l'équipe de prod, dont ça va
être le boulot. Si une machine doit être installée en urgence en pleine
nuit, parce que le gars d'astreinte a reçu un SMS lui disant que la
qualité de service n'est plus acceptable, c'est pas le développeur qui
sera réveillé, et c'est pas lui qui aura signé un contrat d'astreintes
l'obligeant à se déplacer dans l'heure. Le gars doit pouvoir se
débrouiller seul.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
SP> Ah désolé, mais alors là Tristant il a bu le filtre
Non, le philtre. C'est pas pareil. Je te renvoie à fr.sci.filo
pour que tu conçoives la diphérence.
-+- TP in Guide du neuneu sur Usenet - C'est phou, non ? -+-

On Tue, 24 May 2005, Jerome Lambert wrote:

( Tue, 24 May 2005 21:08:10 +0200 ) SauronDeMordor :

je lueur repond que vous n avez aucune idees des contraintes d un admin sys
dans son taf de tous les jours.

C'est une question de contexte.
Je suis administrateur et je décide de qui doit faire quoi.

Mauvaise réponse: un administrateur est au service des administrés, et
c'est donc à lui de se débrouiller pour que le gusse puisse faire ce
qu'il veut avec la machine (!= faire n'importe quoi).

Pas tout à fait. On sépare bien les machines de développement des machines
de production. En général, on a des exigences de disponibilité sur les
machines de prod, des créneaux de maintenance, des procédures d'accès, de
backup/recovery, etc. Donner un accès root à quelqu'un qui n'a pas à
respecter ces contraintes est une très mauvaise idée. En cas de problème,
c'est le vrai admin qui aura à rendre des comptes à sa direction.

L'administrateur n'est pas au service des administrés, il doit leur
fournir un service (=uptime) de qualité, et c'est à l'équipe de dev
de fournir l'autre qualité de service (=fonctionnalités).

sys avec des vrais sontraintes de prod/d exploitation et de gestion d un
parc de serveur.

Bon alors on ne fait pas de developpement sur des machines de prod.

Et dans un environnement de développement, justement, on fait comment? ;-)

Dans un environnement de développement, c'est pareil. Pas besoin d'être
root pour lancer gcc, et les rares fois où on a besoin d'être root (lancer
un service qui écoute sur un port <1024 par exemple), sudo fait très bien
le boulot.

Quant à l'argument d'une mise en prod par l'équipe de dev, il ne faut pas
mélanger les responsabilités. C'est à l'équipe de prod de faire une mise
en prod, et à personne d'autre. Que ça se traduise par une ouverture du
tiroir de CD, un mount, et un ./install.sh, c'est pas grave, il s'agit
d'avoir quelque chose de reproductible par l'équipe de prod, dont ça va
être le boulot. Si une machine doit être installée en urgence en pleine
nuit, parce que le gars d'astreinte a reçu un SMS lui disant que la
qualité de service n'est plus acceptable, c'est pas le développeur qui
sera réveillé, et c'est pas lui qui aura signé un contrat d'astreintes
l'obligeant à se déplacer dans l'heure. Le gars doit pouvoir se
débrouiller seul.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
SP> Ah désolé, mais alors là Tristant il a bu le filtre
Non, le philtre. C'est pas pareil. Je te renvoie à fr.sci.filo
pour que tu conçoives la diphérence.
-+- TP in Guide du neuneu sur Usenet - C'est phou, non ? -+-

Vous avez filtré cet utilisateur ! Consultez son message

On Tue, 24 May 2005, Jerome Lambert wrote:

( Tue, 24 May 2005 21:08:10 +0200 ) SauronDeMordor :

je lueur repond que vous n avez aucune idees des contraintes d un admin sys
dans son taf de tous les jours.

C'est une question de contexte.
Je suis administrateur et je décide de qui doit faire quoi.

Mauvaise réponse: un administrateur est au service des administrés, et
c'est donc à lui de se débrouiller pour que le gusse puisse faire ce
qu'il veut avec la machine (!= faire n'importe quoi).

Pas tout à fait. On sépare bien les machines de développement des machines
de production. En général, on a des exigences de disponibilité sur les
machines de prod, des créneaux de maintenance, des procédures d'accès, de
backup/recovery, etc. Donner un accès root à quelqu'un qui n'a pas à
respecter ces contraintes est une très mauvaise idée. En cas de problème,
c'est le vrai admin qui aura à rendre des comptes à sa direction.

L'administrateur n'est pas au service des administrés, il doit leur
fournir un service (=uptime) de qualité, et c'est à l'équipe de dev
de fournir l'autre qualité de service (=fonctionnalités).

sys avec des vrais sontraintes de prod/d exploitation et de gestion d un
parc de serveur.

Bon alors on ne fait pas de developpement sur des machines de prod.

Et dans un environnement de développement, justement, on fait comment? ;-)

Dans un environnement de développement, c'est pareil. Pas besoin d'être
root pour lancer gcc, et les rares fois où on a besoin d'être root (lancer
un service qui écoute sur un port <1024 par exemple), sudo fait très bien
le boulot.

Quant à l'argument d'une mise en prod par l'équipe de dev, il ne faut pas
mélanger les responsabilités. C'est à l'équipe de prod de faire une mise
en prod, et à personne d'autre. Que ça se traduise par une ouverture du
tiroir de CD, un mount, et un ./install.sh, c'est pas grave, il s'agit
d'avoir quelque chose de reproductible par l'équipe de prod, dont ça va
être le boulot. Si une machine doit être installée en urgence en pleine
nuit, parce que le gars d'astreinte a reçu un SMS lui disant que la
qualité de service n'est plus acceptable, c'est pas le développeur qui
sera réveillé, et c'est pas lui qui aura signé un contrat d'astreintes
l'obligeant à se déplacer dans l'heure. Le gars doit pouvoir se
débrouiller seul.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
SP> Ah désolé, mais alors là Tristant il a bu le filtre
Non, le philtre. C'est pas pareil. Je te renvoie à fr.sci.filo
pour que tu conçoives la diphérence.
-+- TP in Guide du neuneu sur Usenet - C'est phou, non ? -+-

Erwann ABALEA

25/05/2005 à 07:10

On Wed, 25 May 2005, Jérémy JUST wrote:

On Tue, 24 May 2005 21:35:59 +0200
"Rakotomandimby (R12y) Mihamina"
wrote:

on ne fait pas de developpement sur des machines de prod.

Quand on passe une application du développement à la prod, il y a bien
un moment où on n'est pas sûr que ça va marcher, non?

Pour vérifier que ça marche (ou pas), on a un cahier de recette, des tests
applicatifs à mener, ...
Si on sait que ça marche pas, et il est tout à fait envisageable de
fournir les logs à l'équipe de dev pour diagnostic. Idem pour un éventuel
fichier core, ou tout autre objet permettant de faire du débuggage.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
Quand je passe par le bios et que je lui dit de booter sur C, il boot
sur le PM en C: et il met le SM en D:. Quand le lui dit de booter sur
D, il boot sur le SM en C: et il met le PM en D:. Ca c'est génial.
-+- FP in: Guide du Neuneu d'Usenet - Le bonheur, c'est simple -+-

Jérémy JUST

25/05/2005 à 09:11

On Wed, 25 May 2005 07:10:34 +0200
Erwann ABALEA wrote:

Quand on passe une application du développement à la prod, il y a
bien un moment où on n'est pas sûr que ça va marcher, non?
Pour vérifier que ça marche (ou pas), on a un cahier de recette, des

tests applicatifs à mener, ...

Ah, oui, mais ça, c'est pour déterminé si ça *a* marché.
Ça n'empêche pas qu'avant de migrer et de recetter, on ne sait pas,
et on se retrouve avec une application en test sur la machine de
production (comme le dit Dinh, 01 Informatique formulerait ça bien mieux
que moi, avec témoignages de consultants à l'appui).

--
Jérémy JUST

Hugues

25/05/2005 à 10:13

Ce cher Jerome Lambert a dit :

OUI, on donne parfois le mot de passe root à certaines personnes en sac hant
pertinement que le risque que cette personne casse tout est assez élev é, et
OUI, c'est *MAL*, mais il y a des situations où on n'a pas le choix...

Dans ce cas, pourquoi ne pas avoir recours a sudo, avec par exemple, seulem ent
l'autorisation de lancer "screen -x" dans un chroot, et dans ce meme chr oot
limiter l'utilisation des commandes necessaires ?

Ca me semble une solution assez sure et qui permettrait de surveiller s ans
aucun souci un tel utilisateur, avec en plus un degre bien plus eleve de
controle d'acces - merci sudo.

Non ?

--
Hugues- Linux Addict

Erwann ABALEA

25/05/2005 à 11:49

On Wed, 25 May 2005, Jérémy JUST wrote:

On Wed, 25 May 2005 07:10:34 +0200
Erwann ABALEA wrote:

Quand on passe une application du développement à la prod, il y a
bien un moment où on n'est pas sûr que ça va marcher, non?
Pour vérifier que ça marche (ou pas), on a un cahier de recette, des

tests applicatifs à mener, ...

Ah, oui, mais ça, c'est pour déterminé si ça *a* marché.
Ça n'empêche pas qu'avant de migrer et de recetter, on ne sait pas,
et on se retrouve avec une application en test sur la machine de
production (comme le dit Dinh, 01 Informatique formulerait ça bien mieux
que moi, avec témoignages de consultants à l'appui).

Ben? Et alors? L'équipe de dev fait ses tests, si on a une pré-prod, on
refait la même batterie de tests, et si ça passe, on installe en prod, et
on re-teste! On teste toute nouvelle installation, que cette installation
soit en dev, pré-prod, ou prod, c'est normal.
Après, selon les résultats du test sur la plate forme de prod, on ouvre le
service ou pas. Ne pas tester en prod, sous prétexte que les tests ont été
concluants sur le poste du développeur, c'est suicidaire.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
Nouveau possesseur d'une paire de Roces Amsterdam je désirerai me mettre
au roller...ben..j'sais pas en faire.. alors je voulais savoir si il
existait des cours sur Internet !
-+- Spawn in : Guide du Neuneu d'Usenet - Allez, rouillez jeunesse -+-

Jerome Lambert

25/05/2005 à 16:06

Ce cher Jerome Lambert a dit :

OUI, on donne parfois le mot de passe root à certaines personnes en sachant
pertinement que le risque que cette personne casse tout est assez élevé, et
OUI, c'est *MAL*, mais il y a des situations où on n'a pas le choix...

Dans ce cas, pourquoi ne pas avoir recours a sudo, avec par exemple, seulement
l'autorisation de lancer "screen -x" dans un chroot, et dans ce meme chroot
limiter l'utilisation des commandes necessaires ?

Ca me semble une solution assez sure et qui permettrait de surveiller sans
aucun souci un tel utilisateur, avec en plus un degre bien plus eleve de
controle d'acces - merci sudo.

Non ?

Exemple vécu: notre parc de portables ne se connecte qu'au réseau local.
Les utilisateurs n'ont donc aucun droit d'administration, et ne peuvent
changer la configuration du réseau.
Un jour, un commercial en emprunte un pour une présentation lors d'un
salon à San Francisco, veut se connecter au réseau disponible sur place,
et bien sûr ne peut pas, faute de pouvoir configurer correctement le
réseau...
Donc soit je prenais l'avion pour aller régler ça, soit je lui donnais
le mot de passe root par téléphone afin qu'il le règle lui-même (ou
qu'un type sur place le fasse pour lui). A part ça, je n'ai pas vu
d'autre solution...

Enregistrement des commandes tappées

10 réponses

Veuillez sélectionner un problème