X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C83052.8DEBB89B@onstor-exch02.onstor.net>; Mon, 26 Nov 2007 09:34:10 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: SystemX management shell documents to review
Date: Mon, 26 Nov 2007 09:34:10 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E03B1BF7C@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E06B7AC16@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SystemX management shell documents to review
Thread-Index: AcgrwCNpd99OWTV5SpCGf2HJH51qqQECREYwACD32IA=
From: "Rendell Fong" <rendell.fong@onstor.com>
To: "Jonathan Goldick" <jonathan.goldick@onstor.com>,
	"Andy Sharp" <andy.sharp@onstor.com>
Cc: "Joshua Goldenhar" <joshua.goldenhar@onstor.com>,
	"Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>,
	"Sudheesh Nair" <sudheesh.nair@onstor.com>,
	"dl-Software" <dl-software@onstor.com>,
	"dl-QA" <dl-qa@onstor.com>,
	"dl-Customer Service Group" <csgroup@onstor.com>

See RF> below.

JG> The problem is that bash doesn't transfer control to an external
executable/script/whatever when you hit tab-tab.  If you want command
completion when that is typed, which we have today, the shell must be
modified in some way.  I think others would agree that completion after
typing 'volume tab-tab' and getting a list of add,show,delete,modify is
an important requirement.


RF> For each CLI command, a completion specification (compspec) can be
defined during bash shell initialization.  Compspec does support
parameter completion (with single tab) or displaying a list of
completion possibilities (with tab-tab).  So there shouldn't be any need
to modify bash source code to provide this functionality unless
parameters contain certain non-alphanumeric characters.  Also, not only
can there be completion on static parameters but dynamic ones as well
(such as volume names generated via execution of another command).  The
compspec can run other executables (grep, awk, scripts) but is subject
to the restricted bash shell mode if used.  The linux man page for bash
describes this feature in the section called "Programmable Completion"
although not very easy to follow.  I recall that it was somewhat hard to
figure out until I found some examples.



-----Original Message-----
From: Jonathan Goldick=20
Sent: Sunday, November 25, 2007 5:36 PM
To: Andy Sharp
Cc: Joshua Goldenhar; Maxim Kozlovsky; Sudheesh Nair; dl-Software;
dl-QA; dl-Customer Service Group
Subject: RE: SystemX management shell documents to review

See JG>

-----Original Message-----
From: Andy Sharp=20
Sent: Tuesday, November 20, 2007 1:56 PM
To: Jonathan Goldick
Cc: Joshua Goldenhar; Maxim Kozlovsky; Sudheesh Nair; dl-Software;
dl-QA; dl-Customer Service Group
Subject: Re: SystemX management shell documents to review

On Fri, 16 Nov 2007 15:39:40 -0800 "Jonathan Goldick"
<jonathan.goldick@onstor.com> wrote:

> If you are on the TO line you are a required reviewer but I would
> really appreciate any feedback I can get.
>=20
> This document describes the interactive administrator login
> environment and is a major area where ease of use needs to be worked
> into the product.
>=20
> Management Shell [10]
>
<http://intranet.onstor.net/md/software/systemx/Component_Docs/SystemX_S
> hell.doc>
>
(http://intranet.onstor.net/md/software/systemx/Component_Docs/SystemX_S
> hell.doc)=20
>=20

The document header says "SystemX Software Upgrade"

Section 1

Reference document #6 is in a platform/application specific format that
is basically unreadable w/o purchasing multiple expensive software
licenses.  Please submit in PDF or something.

JG> No, learn to enjoy the Windows world via Citrix.  Visio is our only
tool to write UML diagrams.  I'm not signing up to export dozens,
eventually hundreds, of visio pages to some other format and re-export
them on every update.  I'm also not soliciting suggestions for alternate
tools so that the reader can avoid ever touching Windoze.

Section 2.1

The nomenclature for user support levels is not consistent.  Root level
is called diagnostic-level and so forth.

JG> I'll clean this up.  We have historically used them as synonymous
within our internal documentation.

Admin level paragraph contains unneeded/unwanted implementation
details/constraints, namely restricted shell and chroot.  Just list the
requirements here, not the implementation details.

JG> This was included here because the question was asked time and again
in early conversations, basically it is a requirement that they operate
in a restricted environment with no ability to see files we don't want
them to.  When I put it in the abstract, the questions would immediately
follow.  That said, I'll see what I can move around.  Note that Max has
pointed out in different email that restricted bash will not allow shell
scripts to be run so it may not be an option for us.

Section 4.1

Bash absolutely does have a restricted mode.  man rbash for details.
JG> That is exactly what I said.  What is the point you are making here?
Are you just objecting to the heading about limitations?

Bash does indeed understand interactive v. non-interactive which makes
it appropriate for running "captured."  At least, interactivity can be
detected/checked and acted upon by any script.

JG> See above comment.

Since bash is a fully functional [battle star] programming environment;
it is likely not necessary to modify the actual source to add something
which has as dubious a necessity as hierarchical commands.  Such a
thing could be implemented with included scripts or just careful
program naming, no?

JG> The problem is that bash doesn't transfer control to an external
executable/script/whatever when you hit tab-tab.  If you want command
completion when that is typed, which we have today, the shell must be
modified in some way.  I think others would agree that completion after
typing 'volume tab-tab' and getting a list of add,show,delete,modify is
an important requirement.  Why do you see this as dubious?

Section 4.3

First paragraph: say what and the what-what?  ext3??  The M$ kid learns
a few Linux acronyms and he becomes really dangerous.  But seriously,
this part begs for a different design.  Perhaps management volumes
should have a general storage area that is NFS/CIFS/Samba exportable
and block-replication underpinned (for HA) for storing such things.
Having a quota would suffice to replace any notion of detecting
persistent v. non-persistent and all that.

JG> Let's discuss this.  The reason this is the way it is, is because
you cannot rely upon the existence and availability of the singular
management volume whereas the file system I described will be
redundantly available.  In the event of a failure of the management
volume, you should not lose access to your home directory and login
environment.  I see no reason to add multiple management volumes for
this single use case when it can be solved as described, but perhaps you
have another use case that was missed in the clustering document.

P2: I don't like the clusterDB overloading here.  People expect home
directories to persist.  It's probably best to just set some disk space
aside for this and be done with it.  Normal quota mechanisms applied.

JG> High availability must be provided in some fashion.  Why reinvent
the wheel when the cluster DB provides it.  Having two mechanisms to
provide cluster-wide, consistent, and highly available management
information seems like something to avoid.

Persisted Scripts - above comments applied to this.

Home directory quotas - ditto.

Section 4.5

Hmm.  This presents an undue burden on executing cron jobs, first
having to extract the scripts from the clusDB.  See my comments above
for an alternative approach that is less awkward to integrate with cron.

JG> What do you suggest that meets the availability requirement?

Section 4.8

Not in a chrooted environment, a restricted environment which consists
mainly of an unchangeable PATH setting.  Utilities can be added to the
appropriate paths as their need is discovered in testing and debugging.

JG> Pretty much what I said, or is there something I'm missing here?
