Re: mkraid secret flag

2000-03-19 Thread m.allan noah

WARNING: i am going to type the secret command in the following mail. if you
cannot handle it, delete it now. if you want a rational explanation for why i
would do that, read on. i am not trying to be inflammatory, just make a point.

i have been using software raid under linux for quite a while now. both my
current and prior employers are using software raid boxes that i have setup
over the past two+ years. some of the older ones are running kernel 2.0.3x and
the more recent ones are 2.2.x of some sort. some older ones are using the
0.4x raid code, the newer, 0.90.

with these 20 or so machines, i have found the 0.90 tools and kernel level
driver to be much more robust and user friendly. i can remember when raid had
a single mdtab, then MULTIPLE conf files, and now a single raidtab. the newer
versions, with the inclusion of things like martin bene's failed-disk patches,
has been one of the most useful pieces of software i have applied in an x86
server environment. by comparison, the 0.40 raid code, replete with initrds
and weird startup scripts looks quite pathetic.

while there is some point to protecting a user from system damage, the message
that is printed, and the command name needed to actually get the work done,
make the 0.90 code appear unstable or untested.

there are at least hundreds if not thousands of people on this list who use
linux, and linux software raid every day. this is code is stable, and it is
tested. it is bulletproof in comparison to the 0.4x code, and if mr cox has
his way, it will finally be in the main kernel.

as such, i feel it is time to rename the --really-force command from mkraid to
--force. to leave as-is, is just great ammunition for those who would slight
the efforts of the developers as incomplete or amaturish.

people know they are taking their own system into their hands. this is WHY
they are using linux, rather than an os that hides the real innards of the
system from them. the extra logic required to make them type the longer
command, however simple, just adds kruft to the binary, to print a message
that is a GIVEN when you are root on your box.

think about it! rm by default does not -i! and rm is potentially MUCH more
dangerous than mkraid. hell, we tell people on this list ALL THE TIME to run
mkraid --really-force on their EXISTING partitions: "it only overwrites the
raid superblock"! we dont tell people to fix problems with rm -rf * ! should
we go back and change rm to always be in -i mode? fdisk does not print such
messages. mke2fs on a clean partition? no.

i feel that mingo/gadi et al have done a fine job, and these utils need to
take the same approach as other system level programs- no convoluted messages
asking for non-disclosure, just the normal warning, and the five second pause.
raid 0.90 is almost grown up. it should act that way.

wow- that was longer than i intended on such a simple subject- sorry :)

allan noah

James Manning [EMAIL PROTECTED] said: 

 [ Wednesday, March 15, 2000 ] root wrote:
   mkraid --**-force /dev/md0
 
 /me attempts to get the Stupid Idea Of The Month award
 
 Motivation: trying to keep the Sekret Flag a secret is a failed effort
 (the number of linux-raid archives, esp. those that are searchable, make
 this a given), and a different approach could help things tremendously.
 
 *** Idea #1:
 
 How about --force / -f look for $HOME/.md_force_warning_read and
 
 if not exists:
  - print huge warning (and beep thousands of times as desired)
  - creat()/close() the file
 
 if exists:
  - Do the Horrifically Dangerous stuff
 
 Benefit:  everyone has to read at least once (or at a minimum create a
   file that says they've read it)
 Downside: adds a $HOME/ entry, relies on getenv("HOME"), etc.
 
 *** Idea #2:
 
 --force / -f prints a warning, prompts for input (no fancy term
 tricks), and continues only on "yes" being entered (read(1,..) so
 we can "echo yes |mkraid --force" in cases we want it automated).
 
 Benefit:  warning always generated
 Downside: slightly more complicated to script
 
 Both are fairly trivial patches, so I'll be glad to generate the
 patch for whichever (if either :) people seem to like.
 
 James
 





[PATCHES] Re: mkraid secret flag

2000-03-19 Thread James Manning

Patches attached:

#1: allan noah's suggestion (small warning, 5 seconds, that's it)
#2: untested "it compiles" patch for warning file (with Seth's 2 week
recommendation on time-span)

[ Saturday, March 18, 2000 ] m. allan noah wrote:
 think about it! rm by default does not -i!

true, although most systems (just going by RH's volume) have alias rm="rm
-i" for root (as well as a couple of other possibly-destructive commands)

 i feel that mingo/gadi et al have done a fine job, and these utils need to
 take the same approach as other system level programs- no convoluted messages
 asking for non-disclosure, just the normal warning, and the five second pause.
 raid 0.90 is almost grown up. it should act that way.

raid 0.90 maturity is orthogonal to the issue of whether we want to warn
people on a potentially destructive command.  The motivation "It really
sucks to LOSE DATA!" applys equally well to Bug-Free (tm) kernel code
as to stuff in development (ie, you're willing to destroy what's on disk).

In any case, since the patches are small and easy to get almost any
warning behavior desired (or none at all), it'll boil down to distro
preference anyway.

James


--- raidtools-0.90/mkraid.c.origSun Mar 19 03:31:48 2000
+++ raidtools-0.90/mkraid.c Sun Mar 19 03:33:46 2000
@@ -68,7 +68,6 @@
 int version = 0, help = 0, debug = 0;
 char * configFile = RAID_CONFIG;
 int force_flag = 0;
-int old_force_flag = 0;
 int upgrade_flag = 0;
 int no_resync_flag = 0;
 int all_flag = 0;
@@ -79,8 +78,7 @@
 enum mkraidFunc func;
 struct poptOption optionsTable[] = {
{ "configfile", 'c', POPT_ARG_STRING, configFile, 0 },
-   { "force", 'f', 0, old_force_flag, 0 },
-   { "really-force", 'R', 0, force_flag, 0 },
+   { "force", 'f', 0, force_flag, 0 },
{ "upgrade", 'u', 0, upgrade_flag, 0 },
{ "dangerous-no-resync", 'r', 0, no_resync_flag, 0 },
{ "help", 'h', 0, help, 0 },
@@ -116,12 +114,8 @@
}
 } else if (!strcmp (namestart, "raid0run")) {
 func = raid0run;
-   if (old_force_flag) {
-   fprintf (stderr, "--force not possible for raid0run!\n");
-   return (EXIT_FAILURE);
-   }
if (force_flag) {
-   fprintf (stderr, "--really-force not possible for raid0run!\n");
+   fprintf (stderr, "--force not possible for raid0run!\n");
return (EXIT_FAILURE);
}
if (upgrade_flag) {
@@ -167,23 +161,6 @@
 
 if (getMdVersion(ver)) {
fprintf(stderr, "cannot determine md version: %s\n", strerror(errno));
-   return EXIT_FAILURE;
-}
-
-if (old_force_flag  (func == mkraid)) {
-   fprintf(stderr, 
-
-"--force and the new RAID 0.90 hot-add/hot-remove functionality should be\n"
-" used with extreme care! If /etc/raidtab is not in sync with the real array\n"
-" configuration, then a --force will DESTROY ALL YOUR DATA. It's especially\n"
-" dangerous to use -f if the array is in degraded mode. \n\n"
-" PLEASE dont mention the --really-force flag in any email, documentation or\n"
-" HOWTO, just suggest the --force flag instead. Thus everybody will read\n"
-" this warning at least once :) It really sucks to LOSE DATA. If you are\n"
-" confident that everything will go ok then you can use the --really-force\n"
-" flag. Also, if you are unsure what this is all about, dont hesitate to\n"
-" ask questions on [EMAIL PROTECTED]\n");
-
return EXIT_FAILURE;
 }
 


--- raidtools-0.90/mkraid.c.origSun Mar 19 03:31:48 2000
+++ raidtools-0.90/mkraid.c Sun Mar 19 03:55:19 2000
@@ -68,7 +68,6 @@
 int version = 0, help = 0, debug = 0;
 char * configFile = RAID_CONFIG;
 int force_flag = 0;
-int old_force_flag = 0;
 int upgrade_flag = 0;
 int no_resync_flag = 0;
 int all_flag = 0;
@@ -79,8 +78,7 @@
 enum mkraidFunc func;
 struct poptOption optionsTable[] = {
{ "configfile", 'c', POPT_ARG_STRING, configFile, 0 },
-   { "force", 'f', 0, old_force_flag, 0 },
-   { "really-force", 'R', 0, force_flag, 0 },
+   { "force", 'f', 0, force_flag, 0 },
{ "upgrade", 'u', 0, upgrade_flag, 0 },
{ "dangerous-no-resync", 'r', 0, no_resync_flag, 0 },
{ "help", 'h', 0, help, 0 },
@@ -116,12 +114,8 @@
}
 } else if (!strcmp (namestart, "raid0run")) {
 func = raid0run;
-   if (old_force_flag) {
-   fprintf (stderr, "--force not possible for raid0run!\n");
-   return (EXIT_FAILURE);
-   }
if (force_flag) {
-   fprintf (stderr, "--really-force not possible for raid0run!\n");
+   fprintf (stderr, "--force not possible for raid0run!\n");
return (EXIT_FAILURE);
}
if (upgrade_flag) {
@@ -170,8 +164,17 @@
return EXIT_FAILURE;
 }
 
-if (old_force_flag  (func == mkraid)) {
-   fprintf(stderr, 
+if (force_flag  (func == mkraid)) {

mkraid secret flag

2000-03-18 Thread James Manning

[ Wednesday, March 15, 2000 ] root wrote:
  mkraid --**-force /dev/md0

/me attempts to get the Stupid Idea Of The Month award

Motivation: trying to keep the Sekret Flag a secret is a failed effort
(the number of linux-raid archives, esp. those that are searchable, make
this a given), and a different approach could help things tremendously.

*** Idea #1:

How about --force / -f look for $HOME/.md_force_warning_read and

if not exists:
 - print huge warning (and beep thousands of times as desired)
 - creat()/close() the file

if exists:
 - Do the Horrifically Dangerous stuff

Benefit:  everyone has to read at least once (or at a minimum create a
  file that says they've read it)
Downside: adds a $HOME/ entry, relies on getenv("HOME"), etc.

*** Idea #2:

--force / -f prints a warning, prompts for input (no fancy term
tricks), and continues only on "yes" being entered (read(1,..) so
we can "echo yes |mkraid --force" in cases we want it automated).

Benefit:  warning always generated
Downside: slightly more complicated to script

Both are fairly trivial patches, so I'll be glad to generate the
patch for whichever (if either :) people seem to like.

James



Re: mkraid secret flag

2000-03-18 Thread Seth Vidal

 How about --force / -f look for $HOME/.md_force_warning_read and
 
 if not exists:
  - print huge warning (and beep thousands of times as desired)
  - creat()/close() the file
how about an expiration on the timestamp on this file
ie: if the time is longer than 2 weeks make them read it again.

I know I forget all sorts of warnings after a while :)

-sv