Re: Error "Installation aborted by the user" during "D3_setup"

"Tony Gravagno" <address.is.in.posts@xxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:uta6k3hq98i0hfjg7ccabm5cvseb6ur9t4@xxxxxxx
Good to exchange notes with you again, my friend.

Appreciate the "friend" reference. Thank you.


I really do understand your position. Not for D3 but for other
products you'll find complex grep statements, regular expressions,
even Makefile's or shell scripts that need to be modified to install
some product (usually open source). It can be very confusing and it's
unfortunate that we now need to come to grips with detailed OS-level
nuances (aka voodoo) that we never needed with native MV
implementations. I freely admit that I glaze over when I start
looking at FLOSS that expects me tweak C code or rebuild a kernel.

However, in this case I'm afraid we are in disagreement. It's not the
job of the DBMS provider, nor the provider of any software, to educate
the user, especially the Value-Add-Reseller and support provider,
regarding the underlying OS. You will not find an explanation of
"init s", nor "cd" nor "mount" in any installation documentation for
any product. It's assumed that someone installing server software
will know these commands or do the research upon encountering
unfamiliar commands. And sure, we all forget commands that we don't
use that often. For this incident I'd say this is all just a case of
"use it or lose it", you've slapped your forehead with the "oh I get
it" as all of us do from time to time. It's OK to let this one drop
rather than petitioning the developers to make changes.

Two things. Firstly, I disagree with what is and isn't the job of the DBMS
provider. Not just for installation, but for everything, I feel their job
should be to make my job as simple as possible. The simpler they make
things for me, the more time I have for developing (and heaven forfend
marketing) solutions. The more solutions I sell, the more of their product
I sell. I win, they win, my clients win. Everybody wins. (Although, for
the avoidance of doubt, I'll point out right now that providing MV solutions
is not my core business.)

Before saying anything else, in a spirit of fairness to RD, I'll add that
(certainly here in the UK) they do training courses on installing D3 on both
NT and RedHat. (The courses have different titles, but I can't complete the
D3 Unix Administrator course (150) until I've completed the MV Fundamentals
(200) (which, with the greatest of respect to RD, I'm not going to pay to
complete), but the course is there. (For the sake of compleness, D3/NT
Installations is Course 100).

Your mission, should you choose to accept it, is to find details of these
courses on RD's web-site. They are there, but aren't as easy to find as
they could be. Furthermore, would it be too much to ask for RD to e-mail a
link, or even the PDF itself, every once in a while to their VARS,
particularly when they update the training schedule, but I suppose that
might count as marketing?)

Back to the instant case, I take complete responsibility for not remembering
the need to be at the console when running "init s".

I hadn't posted all the details, but I'll add some more now. The problem
occurred when one of the client's own people tried patching D3. Normally,
it wouldn't be a problem, he knows what he's doing but in this case it blew
up, spectacularly.

I've since repeated the patch and it has done the same on me - three times
(so that's four in total). I suspect there could be something wrong with
the patch process (patch number 247 seems problematic) and the system drops
into the debugger in the "delete-file" process prior to automatically
rebooting the machine after completion of patching, but that's a whole
different problem I'm chasing down with RD.

When the system blew, I therefore had in front of me, the instructions for
patching systems.

I can't post a binary here, but there's a screenshot of the process after
"/tmp/D3_setup" is run, and that doesn't look like the console to me. :-(

ftp://ftp.rainingdata.com/pub/Linux/7.4.0/Patches/linux730s3.html

Yes, I should have remembered about "init s" but a misleading screenshots
and plainly inaccurate error messages sure didn't help. (Nor did the
absence of anything in the install error log, but perhaps I'm just being
picky here, if you'll excuse the pun.)


About the specific error message you received - D3 expects to be in
single-user mode during the installation. No provision is made in the
installation scripts for a system that is not in single user mode
because the docs explictly state "Return to the root directory and set
single-user mode". Once the script is executed, if anything fails the
script will simply respond as best it can to the failure of whatever
the last command was that executed. It seems the engineer who wrote
the script assumed that if the system is in single user mode, the only
way for some specific step to fail would be if the user aborted it.
While all of us could easily question such assumptions and would
prefer an explict "Step X failed", we're never going to get "Step X
failed because the system is in single user mode".

This is open to contention but I would ask why any developer should
write specific code to investigate the cause of a problem down to the
point where it questions whether the user was following explicit
directions. Yes, you and I would probably take the time to do this
but we expect companies like RD have more important things to do than
to second-guess the users. We've always been comfortable with
messages like "[3] verb?" when what we really mean is "[3] command not
found in the master dictionary, please enter a valid command, checking
the reference manual if required, or consult with your support
provider for assistance." I'm all for being user-friendly but there's
only so far that developers should go.

In this particular case neither the installation procedure nor the
related documentation has changed in the area being discussed since I
worked on it with the TechPubs department and our QA team about 10
years ago. At that time we very carefully ensured that every required
step was covered, and even added many helpful warnings at points where
there might have been confusion. Some people could even question
those helpful tips as being condescending or just fluff that bloats a
10 minute process into over 100 pages of detail. Since then, VARs and
experienced end-users have been using those docs to install their
systems with virtually no problems related to the docs - had there
been confusion in all of these years it would have been changed since
a new doc is generated with details for every new release. In this
particular case I don't think any changes to the software or docs are
warranted.

I fear we'll have to agree to disagree Tony. If the error message said,
"Unable to continue with install" without giving details, I could have no
complaint. Similarly, if something (anything!) had been logged to
"/tmp/d3.install.errs", I'd be hard pressed to disagree with you.

But that isn't what happened. The system reported "Installation aborted by
the user". Aborting something implies an act of commission. That having
started the install, I then willfully took some action to stop the
installation from proceeding. That isn't the case.

Sure, I'd screwed up, and an error of "Installation aborted because the user
screwed up", whilst not the most helpful, would certainly have been
accurate.

RD are clearly checking "things" before proceeding. To my mind, it is best
practice to report the specifics of each error encountered rather than a
more general "unable to continue", or as in this case "you aborted it", even
though I don't think I did.

By way of comparison, assume you're writing some code that requires five
files to be opened before it can be run. This fact is well document in the
accompanying notes. Assume the files are called "one", "two", "three",
"four" and "five for the sake of ease. Also assume files "three" and "four"
don't exist. (Maybe somebody overwrote the q-pointer with something else
when they weren't thinking.)

You're writing the code Tony, so what error message are you going to report
to the user? "Unable to continue"? "Program aborted by the user"? Or
maybe, "File 'Three' is missing. File 'Four' is missing. Unable to
continue".

I would argue that option one, whilst not exactly helpful is at least
factually accurate. Option two is plainly non-sensical, yet you're happy
for RD to use similar in their install routines? Personally, I would use
option 3 and would argue that such an error message is best practice. (And
yes, I'd report both errors in the first pass, rather than the more annoying
version of reporting file "three" missing first time, then file "four"
missing second time round.)

As I said previously, we may have to agree to disagree on this one.

Regards

Mike Wooding


.

Relevant Pages

  • How to use scripting to secure your Win2K network--some examples
    ... Software Installation script: ... The purpose of this script is to ... Let's see how service packs and hotfixes are handled in the script: ... NT4 in the way the local system account accesses network resources. ...
    (NT-Bugtraq)
  • Re: [Info-Ingres] jdbc connection problem
    ... Initially you run a setup on a clean machine with the script recording ... I obtained mixed results where there was already an installation present ... @echo starting OpenROAD installation ... Subject: jdbc connection problem ...
    (comp.databases.ingres)
  • Installation of software, and security. . .
    ... installation in Windows and various package managers. ... A setup.exe program coded by some third party such as Real Networks ... A .msi Microsoft Installer package is unpacked, and a script coded by ...
    (Bugtraq)
  • pop-forum Ready for testing: new version of PC/Linux Poplog for testing (V15.6a)
    ... This change broke the install script included with Poplog v15.6, ... I have tried to make the new installation script equally happy with ... either of which which can be run to download and install everything ...
    (comp.lang.pop)
  • V880 boot problems
    ... Configuring /dev and /devices ... Starting Solaris installation program... ... Using finish script: scripts/Finish_script ... Executing JumpStart preinstall phase... ...
    (SunManagers)