AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20071120135210.00024b1f@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<jonathan.goldick@onstor.com>,<joshua.goldenhar@onstor.com>,<maxim.kozlovsky@onstor.com>,<sudheesh.nair@onstor.com>,<dl-software@onstor.com>,<dl-qa@onstor.com>,<csgroup@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	24509	BB375AF679D4A34E9CA8DFA650E2B04E06A7BD5D@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 20 Nov 2007 13:56:00 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Jonathan Goldick" <jonathan.goldick@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>
Subject: Re: SystemX management shell documents to review
Message-ID: <20071120135600.72d425be@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E06A7BD5D@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E05963FB7@onstor-exch02.onstor.net>
 <BB375AF679D4A34E9CA8DFA650E2B04E06A7BD5D@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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.
> 
> This document describes the interactive administrator login
> environment and is a major area where ease of use needs to be worked
> into the product.
> 
> 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) 
> 

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.

Section 2.1

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

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

Section 4.1

Bash absolutely does have a restricted mode.  man rbash for details.

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.

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?

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.

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.

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.

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.

