Il m'arrive assez souvent d'avoir à faire des trucs bénins sur un
système, et j'aimerais pouvoir le faire sans passer root (avec tous
les risques que ça comporte en cas d'erreur).
Par exemple, je voudrais faire un "passwd -S machin". C'est pas
méchant, ça ne modifie rien dans le système.
Mais si je passe root (su, sudo), et que je fais une erreur dans la
commande, les conséquences peuvent être fâcheuses.
De même, j'aimerais pouvoir faire un fdisk /dev/hda, et avoir accès à
tout sauf la commande "w" -- en d'autres termes, pouvoir regarder et
expérimenter tout mon saoûl, mais ne rien pouvoir écrire réellement
sur le disque.
Une solution serait d'avoir une machine "miroir", exactement identique
en tout point, sur laquelle je pourrais faire tout ce que je veux sans
risquer de casser la machine principale, mais bon... c'est un peu
lourd quand il s'agit juste de vérifier qu'un compte n'a pas de mot de
passe.
Une solution serait d'avoir une machine "miroir", exactement identique en tout point, sur laquelle je pourrais faire tout ce que je veux sans risquer de casser la machine principale, mais bon... c'est un peu lourd quand il s'agit juste de vérifier qu'un compte n'a pas de mot de passe.
Merci d'avance pour vos idées et suggestions...
pour ca j'utilise qemu. Une installation rapide, et la on peut tester tout et n'importe quoi. qemu offre l'option snapshot qui permet meme de ne rien casser. La sauvegarde de ton systeme qemu se fait en copiant un fichier (celui qui represente le disque).
Bon, ensuite, c'est effectivement un peu mou du genou a l'utilisation (surtout avec -snapshot) mais ca reste un outil de test et de validation incroyable, genre est ce que je suis capable de supprimer une glibc de mon systeme? (et ensuite: comment est ce que je peux reparer mon systeme maintenant qu'il est tout casse :) ).
On 19 mar, 09:39, Fabien LE LEZ <grams...@gramster.com> wrote:
Une solution serait d'avoir une machine "miroir", exactement identique
en tout point, sur laquelle je pourrais faire tout ce que je veux sans
risquer de casser la machine principale, mais bon... c'est un peu
lourd quand il s'agit juste de vérifier qu'un compte n'a pas de mot de
passe.
Merci d'avance pour vos idées et suggestions...
pour ca j'utilise qemu.
Une installation rapide, et la on peut tester tout et n'importe quoi.
qemu offre l'option snapshot qui permet meme de ne rien casser.
La sauvegarde de ton systeme qemu se fait en copiant un fichier
(celui
qui represente le disque).
Bon, ensuite, c'est effectivement un peu mou du genou a l'utilisation
(surtout avec -snapshot) mais ca reste un outil de test et de
validation incroyable, genre est ce que je suis capable de
supprimer une glibc de mon systeme? (et ensuite: comment est ce que
je peux reparer mon systeme maintenant qu'il est tout casse :) ).
Une solution serait d'avoir une machine "miroir", exactement identique en tout point, sur laquelle je pourrais faire tout ce que je veux sans risquer de casser la machine principale, mais bon... c'est un peu lourd quand il s'agit juste de vérifier qu'un compte n'a pas de mot de passe.
Merci d'avance pour vos idées et suggestions...
pour ca j'utilise qemu. Une installation rapide, et la on peut tester tout et n'importe quoi. qemu offre l'option snapshot qui permet meme de ne rien casser. La sauvegarde de ton systeme qemu se fait en copiant un fichier (celui qui represente le disque).
Bon, ensuite, c'est effectivement un peu mou du genou a l'utilisation (surtout avec -snapshot) mais ca reste un outil de test et de validation incroyable, genre est ce que je suis capable de supprimer une glibc de mon systeme? (et ensuite: comment est ce que je peux reparer mon systeme maintenant qu'il est tout casse :) ).
Nicolas.MICHEL
Fabien LE LEZ wrote:
Mais si je passe root (su, sudo), et que je fais une erreur dans la commande, les conséquences peuvent être fâcheuses.
Salut
A mon humble avis, tu prends le problème dans le mauvais sens.
Tu peux effectivement faire une fausse manip, mais ce n'est qu'une possibilité parmis tant d'autre ... - crash disque - update buggy - vol de la machine - foudre - ...
Contre tous ces maux, il n'y a qu'un seul bon remède, le backup.
Alors commence tes tests par ça, vérifies que ton backup est restaurable et après, éclates toi sans craintes. -- Nicolas
Fabien LE LEZ <gramster@gramster.com> wrote:
Mais si je passe root (su, sudo), et que je fais une erreur dans la
commande, les conséquences peuvent être fâcheuses.
Salut
A mon humble avis, tu prends le problème dans le mauvais sens.
Tu peux effectivement faire une fausse manip, mais ce n'est qu'une
possibilité parmis tant d'autre ...
- crash disque
- update buggy
- vol de la machine
- foudre
- ...
Contre tous ces maux, il n'y a qu'un seul bon remède, le backup.
Alors commence tes tests par ça, vérifies que ton backup est restaurable
et après, éclates toi sans craintes.
--
Nicolas
Mais si je passe root (su, sudo), et que je fais une erreur dans la commande, les conséquences peuvent être fâcheuses.
Salut
A mon humble avis, tu prends le problème dans le mauvais sens.
Tu peux effectivement faire une fausse manip, mais ce n'est qu'une possibilité parmis tant d'autre ... - crash disque - update buggy - vol de la machine - foudre - ...
Contre tous ces maux, il n'y a qu'un seul bon remède, le backup.
Alors commence tes tests par ça, vérifies que ton backup est restaurable et après, éclates toi sans craintes. -- Nicolas
Yves Lambert
Nicolas MICHEL wrote:
Fabien LE LEZ wrote:
Mais si je passe root (su, sudo), et que je fais une erreur dans la commande, les conséquences peuvent être fâcheuses.
Salut
A mon humble avis, tu prends le problème dans le mauvais sens.
Tu peux effectivement faire une fausse manip, mais ce n'est qu'une possibilité parmis tant d'autre ... - crash disque - update buggy - vol de la machine - foudre - ... rootkit et alors le backup (sauf /home) ne sert à pas grand chose....
Alors commence tes tests par ça, vérifies que ton backup est restaurable et après, éclates toi sans craintes.
backup /home et ne pas craindre de faire et refaire des installations...
Nicolas MICHEL wrote:
Fabien LE LEZ <gramster@gramster.com> wrote:
Mais si je passe root (su, sudo), et que je fais une erreur dans la
commande, les conséquences peuvent être fâcheuses.
Salut
A mon humble avis, tu prends le problème dans le mauvais sens.
Tu peux effectivement faire une fausse manip, mais ce n'est qu'une
possibilité parmis tant d'autre ...
- crash disque
- update buggy
- vol de la machine
- foudre
- ...
rootkit et alors le backup (sauf /home) ne sert à pas grand chose....
Alors commence tes tests par ça, vérifies que ton backup est restaurable
et après, éclates toi sans craintes.
backup /home et ne pas craindre de faire et refaire des installations...
Mais si je passe root (su, sudo), et que je fais une erreur dans la commande, les conséquences peuvent être fâcheuses.
Salut
A mon humble avis, tu prends le problème dans le mauvais sens.
Tu peux effectivement faire une fausse manip, mais ce n'est qu'une possibilité parmis tant d'autre ... - crash disque - update buggy - vol de la machine - foudre - ... rootkit et alors le backup (sauf /home) ne sert à pas grand chose....
Alors commence tes tests par ça, vérifies que ton backup est restaurable et après, éclates toi sans craintes.
backup /home et ne pas craindre de faire et refaire des installations...
Fabien LE LEZ
On Mon, 19 Mar 2007 13:51:12 +0100, (Nicolas MICHEL):
Contre tous ces maux, il n'y a qu'un seul bon remède, le backup.
Même ça n'est pas suffisant. Si jamais je veux vérifier un détail sur la configuration du serveur de l'entreprise pendant la journée, je n'ai pas le droit à l'erreur, car un downtime prolongé serait inacceptable.
On Mon, 19 Mar 2007 13:51:12 +0100, Nicolas.MICHEL@BonBon.net (Nicolas
MICHEL):
Contre tous ces maux, il n'y a qu'un seul bon remède, le backup.
Même ça n'est pas suffisant.
Si jamais je veux vérifier un détail sur la configuration du serveur
de l'entreprise pendant la journée, je n'ai pas le droit à l'erreur,
car un downtime prolongé serait inacceptable.
On Mon, 19 Mar 2007 13:51:12 +0100, (Nicolas MICHEL):
Contre tous ces maux, il n'y a qu'un seul bon remède, le backup.
Même ça n'est pas suffisant. Si jamais je veux vérifier un détail sur la configuration du serveur de l'entreprise pendant la journée, je n'ai pas le droit à l'erreur, car un downtime prolongé serait inacceptable.
Fabien LE LEZ
On 19 Mar 2007 04:13:41 -0700, :
pour ca j'utilise qemu.
Moi aussi j'utilise un émulateur pour créer des machines de test. Mais je parle ici d'une machine de production, sur laquelle je dois pouvoir vérifier certains détails n'importe quand, avec le moins de risque d'erreur possible.
On 19 Mar 2007 04:13:41 -0700, octane@alinto.com:
pour ca j'utilise qemu.
Moi aussi j'utilise un émulateur pour créer des machines de test.
Mais je parle ici d'une machine de production, sur laquelle je dois
pouvoir vérifier certains détails n'importe quand, avec le moins de
risque d'erreur possible.
Moi aussi j'utilise un émulateur pour créer des machines de test. Mais je parle ici d'une machine de production, sur laquelle je dois pouvoir vérifier certains détails n'importe quand, avec le moins de risque d'erreur possible.
Fabien LE LEZ
On 19 Mar 2007 04:13:41 -0700, :
Bon, ensuite, c'est effectivement un peu mou du genou a l'utilisation (surtout avec -snapshot)
T'as essayé VMware ?
mais ca reste un outil de test et de validation incroyable, genre est ce que je suis capable de supprimer une glibc de mon systeme?
Il faut reconnaître un truc avec cette manip : une fois effectuée, on ne risque pas de rebooter par erreur ;-)
(et ensuite: comment est ce que je peux reparer mon systeme maintenant qu'il est tout casse :) ).
Sur ce point, je suis d'accord avec Nicolas : rien ne vaut un bon backup (avec le live CD qui va avec).
On 19 Mar 2007 04:13:41 -0700, octane@alinto.com:
Bon, ensuite, c'est effectivement un peu mou du genou a l'utilisation
(surtout avec -snapshot)
T'as essayé VMware ?
mais ca reste un outil de test et de
validation incroyable, genre est ce que je suis capable de
supprimer une glibc de mon systeme?
Il faut reconnaître un truc avec cette manip : une fois effectuée, on
ne risque pas de rebooter par erreur ;-)
(et ensuite: comment est ce que
je peux reparer mon systeme maintenant qu'il est tout casse :) ).
Sur ce point, je suis d'accord avec Nicolas : rien ne vaut un bon
backup (avec le live CD qui va avec).
Bon, ensuite, c'est effectivement un peu mou du genou a l'utilisation (surtout avec -snapshot)
T'as essayé VMware ?
mais ca reste un outil de test et de validation incroyable, genre est ce que je suis capable de supprimer une glibc de mon systeme?
Il faut reconnaître un truc avec cette manip : une fois effectuée, on ne risque pas de rebooter par erreur ;-)
(et ensuite: comment est ce que je peux reparer mon systeme maintenant qu'il est tout casse :) ).
Sur ce point, je suis d'accord avec Nicolas : rien ne vaut un bon backup (avec le live CD qui va avec).
Arol
"Fabien LE LEZ" a écrit dans le message de news:
Mais je parle ici d'une machine de production, sur laquelle je dois pouvoir vérifier certains détails n'importe quand, avec le moins de risque d'erreur possible.
Ouh lala lala. Tu as une machine de prod sans un clone (au moins logiciel) chez toi ? Tu prends beaucoup de risques mon bon.
"Fabien LE LEZ" a écrit dans le message de news:
Mais je parle ici d'une machine de production, sur laquelle je dois
pouvoir vérifier certains détails n'importe quand, avec le moins de
risque d'erreur possible.
Ouh lala lala.
Tu as une machine de prod sans un clone (au moins logiciel) chez toi ?
Tu prends beaucoup de risques mon bon.
Mais je parle ici d'une machine de production, sur laquelle je dois pouvoir vérifier certains détails n'importe quand, avec le moins de risque d'erreur possible.
Ouh lala lala. Tu as une machine de prod sans un clone (au moins logiciel) chez toi ? Tu prends beaucoup de risques mon bon.
Arol
"Fabien LE LEZ" a écrit dans le message de news:
Contre tous ces maux, il n'y a qu'un seul bon remède, le backup.
Même ça n'est pas suffisant. Si jamais je veux vérifier un détail sur la configuration du serveur de l'entreprise pendant la journée, je n'ai pas le droit à l'erreur, car un downtime prolongé serait inacceptable.
Non mais tu as pas 36 solutions la. Tu as une machine clone (au minimum logiciel) sur laquelle tu fais des modifs, tu vérifies que ça marche et seulement ensuite tu fais la même chose sur la machine de prod.
Bien évidemment ça implique d'avoir 2 machines et faire les manips 2 fois, mais au moins ça apporte 2 fois plus de sécurité.
Perso, j'ai un p225, 128Mo de ram qui clone un bi xeon avec 4Go de ram. Jusqu'à présent, le clonage logiciel a suffit pour bien vérifier que tout marche, mais le jour ou j'aurai des modifs qui impliquent le coté matériel de la machine de prod, par exemple activer un module du noyau qui tire mieux profit du bi xeon, ou la mise à jour du bios, je serai un peu coincé et faudra que je fasse la modif la nuit et être sur que la modif sera effective avant la levée du soleil.
Pour être complet, le p255 est le clone de 5 machines de prod, le disque dur contient plusieurs partitions qui correspondent aux machines "maîtres" et en fonction des besoins, je boote sur la bonne partition. Donc faut faire attention de booter sur la bonne partition, sinon risque de s'emmêler les pinceaux en testant sur un clone qui correspond pas au maître.
C'est très old school, je vais réfléchir à une solution vmware sur une machine plus puissante. Faut savoir évoluer dans la vie.
"Fabien LE LEZ" a écrit dans le message de news:
Contre tous ces maux, il n'y a qu'un seul bon remède, le backup.
Même ça n'est pas suffisant.
Si jamais je veux vérifier un détail sur la configuration du serveur
de l'entreprise pendant la journée, je n'ai pas le droit à l'erreur,
car un downtime prolongé serait inacceptable.
Non mais tu as pas 36 solutions la.
Tu as une machine clone (au minimum logiciel) sur laquelle tu fais des
modifs, tu vérifies que ça marche et seulement ensuite tu fais la même chose
sur la machine de prod.
Bien évidemment ça implique d'avoir 2 machines et faire les manips 2 fois,
mais au moins ça apporte 2 fois plus de sécurité.
Perso, j'ai un p225, 128Mo de ram qui clone un bi xeon avec 4Go de ram.
Jusqu'à présent, le clonage logiciel a suffit pour bien vérifier que tout
marche, mais le jour ou j'aurai des modifs qui impliquent le coté matériel
de la machine de prod, par exemple activer un module du noyau qui tire mieux
profit du bi xeon, ou la mise à jour du bios, je serai un peu coincé et
faudra que je fasse la modif la nuit et être sur que la modif sera effective
avant la levée du soleil.
Pour être complet, le p255 est le clone de 5 machines de prod, le disque dur
contient plusieurs partitions qui correspondent aux machines "maîtres" et en
fonction des besoins, je boote sur la bonne partition.
Donc faut faire attention de booter sur la bonne partition, sinon risque de
s'emmêler les pinceaux en testant sur un clone qui correspond pas au maître.
C'est très old school, je vais réfléchir à une solution vmware sur une
machine plus puissante.
Faut savoir évoluer dans la vie.
Contre tous ces maux, il n'y a qu'un seul bon remède, le backup.
Même ça n'est pas suffisant. Si jamais je veux vérifier un détail sur la configuration du serveur de l'entreprise pendant la journée, je n'ai pas le droit à l'erreur, car un downtime prolongé serait inacceptable.
Non mais tu as pas 36 solutions la. Tu as une machine clone (au minimum logiciel) sur laquelle tu fais des modifs, tu vérifies que ça marche et seulement ensuite tu fais la même chose sur la machine de prod.
Bien évidemment ça implique d'avoir 2 machines et faire les manips 2 fois, mais au moins ça apporte 2 fois plus de sécurité.
Perso, j'ai un p225, 128Mo de ram qui clone un bi xeon avec 4Go de ram. Jusqu'à présent, le clonage logiciel a suffit pour bien vérifier que tout marche, mais le jour ou j'aurai des modifs qui impliquent le coté matériel de la machine de prod, par exemple activer un module du noyau qui tire mieux profit du bi xeon, ou la mise à jour du bios, je serai un peu coincé et faudra que je fasse la modif la nuit et être sur que la modif sera effective avant la levée du soleil.
Pour être complet, le p255 est le clone de 5 machines de prod, le disque dur contient plusieurs partitions qui correspondent aux machines "maîtres" et en fonction des besoins, je boote sur la bonne partition. Donc faut faire attention de booter sur la bonne partition, sinon risque de s'emmêler les pinceaux en testant sur un clone qui correspond pas au maître.
C'est très old school, je vais réfléchir à une solution vmware sur une machine plus puissante. Faut savoir évoluer dans la vie.
Fabien LE LEZ
On Tue, 20 Mar 2007 00:35:10 +0100, "Arol" :
Tu as une machine clone (au minimum logiciel) sur laquelle tu fais des modifs,
Mais justement, il ne s'agit pas de faire une modification, mais d'accéder à une information en lecture seule.
Je voudrais un compte sous lequel je pourrais faire passwd -S machin mais pas passwd -d machin
Ou bien, sur lequel je pourrais faire "fdisk /dev/sda", mais pas utiliser la commande "w" (write). Ou encore, lancer mdadm pour vérifier l'état de mes RAID, mais ne pas pouvoir y modifier quoi que ce soit (i.e. uniqument mdadm -D).
On Tue, 20 Mar 2007 00:35:10 +0100, "Arol" <annie.nomat@free.fr>:
Tu as une machine clone (au minimum logiciel) sur laquelle tu fais des
modifs,
Mais justement, il ne s'agit pas de faire une modification, mais
d'accéder à une information en lecture seule.
Je voudrais un compte sous lequel je pourrais faire
passwd -S machin
mais pas
passwd -d machin
Ou bien, sur lequel je pourrais faire "fdisk /dev/sda", mais pas
utiliser la commande "w" (write).
Ou encore, lancer mdadm pour vérifier l'état de mes RAID, mais ne pas
pouvoir y modifier quoi que ce soit (i.e. uniqument mdadm -D).
Tu as une machine clone (au minimum logiciel) sur laquelle tu fais des modifs,
Mais justement, il ne s'agit pas de faire une modification, mais d'accéder à une information en lecture seule.
Je voudrais un compte sous lequel je pourrais faire passwd -S machin mais pas passwd -d machin
Ou bien, sur lequel je pourrais faire "fdisk /dev/sda", mais pas utiliser la commande "w" (write). Ou encore, lancer mdadm pour vérifier l'état de mes RAID, mais ne pas pouvoir y modifier quoi que ce soit (i.e. uniqument mdadm -D).
octane
On 19 mar, 23:07, Fabien LE LEZ wrote:
On 19 Mar 2007 04:13:41 -0700, :
Bon, ensuite, c'est effectivement un peu mou du genou a l'utilisation (surtout avec -snapshot)
T'as essayé VMware ?
capucepalibre. De plus, il faut lancer des modules noyaux.
Et recompiler a chaque changement de noyau linux. Donc bof. A part ca, le gros plus de vmware c'est la facilite du bridging reseau. Je n'ai jamais pu trouver une solution satisfaisante avec qemu.
Par ailleurs qemu permet d'emuler du SMP (pratique pour faire des images systemes SMP sur du mono CPU) et quelques petit trucs sympa comme le vnc inclus.
La lenteur est relative (atroce a l'installation de windows, tres rapide en fonctionnement avec linux) et kqemu a ete libere.
Sinon pour les tests 'in situ' je pourrais te conseiller quelque chose:
le noyau boote, il demarre sur un initrd special. L'initrd monte tout en lecture seule et ajoute un coup d'unionfs, puis chroote. Toutes les modifs sont faites en RAM, pas de soucis, tu peux tout casser :) au reboot, tout est nickel. En fait je suis en train de me dire que c'est interessant comme concept, je vais regarder si c'est du domaine du faisable.
On 19 mar, 23:07, Fabien LE LEZ <grams...@gramster.com> wrote:
On 19 Mar 2007 04:13:41 -0700, oct...@alinto.com:
Bon, ensuite, c'est effectivement un peu mou du genou a l'utilisation
(surtout avec -snapshot)
T'as essayé VMware ?
capucepalibre. De plus, il faut lancer des modules noyaux.
Et recompiler a chaque changement de noyau linux.
Donc bof.
A part ca, le gros plus de vmware c'est la facilite du
bridging reseau.
Je n'ai jamais pu trouver une solution satisfaisante avec
qemu.
Par ailleurs qemu permet d'emuler du SMP (pratique pour
faire des images systemes SMP sur du mono CPU) et quelques
petit trucs sympa comme le vnc inclus.
La lenteur est relative (atroce a l'installation de windows,
tres rapide en fonctionnement avec linux) et kqemu a ete
libere.
Sinon pour les tests 'in situ' je pourrais te conseiller quelque
chose:
le noyau boote, il demarre sur un initrd special. L'initrd monte
tout en lecture seule et ajoute un coup d'unionfs, puis chroote.
Toutes les modifs sont faites en RAM, pas de soucis, tu peux tout
casser :) au reboot, tout est nickel.
En fait je suis en train de me dire que c'est interessant comme
concept, je vais regarder si c'est du domaine du faisable.
Bon, ensuite, c'est effectivement un peu mou du genou a l'utilisation (surtout avec -snapshot)
T'as essayé VMware ?
capucepalibre. De plus, il faut lancer des modules noyaux.
Et recompiler a chaque changement de noyau linux. Donc bof. A part ca, le gros plus de vmware c'est la facilite du bridging reseau. Je n'ai jamais pu trouver une solution satisfaisante avec qemu.
Par ailleurs qemu permet d'emuler du SMP (pratique pour faire des images systemes SMP sur du mono CPU) et quelques petit trucs sympa comme le vnc inclus.
La lenteur est relative (atroce a l'installation de windows, tres rapide en fonctionnement avec linux) et kqemu a ete libere.
Sinon pour les tests 'in situ' je pourrais te conseiller quelque chose:
le noyau boote, il demarre sur un initrd special. L'initrd monte tout en lecture seule et ajoute un coup d'unionfs, puis chroote. Toutes les modifs sont faites en RAM, pas de soucis, tu peux tout casser :) au reboot, tout est nickel. En fait je suis en train de me dire que c'est interessant comme concept, je vais regarder si c'est du domaine du faisable.
