AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20071127095009.1dffdfd0@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	25079	BB375AF679D4A34E9CA8DFA650E2B04E06B7AC16@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 27 Nov 2007 09:53:14 -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: <20071127095314.1d7264a6@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E06B7AC16@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E05963FB7@onstor-exch02.onstor.net>
 <BB375AF679D4A34E9CA8DFA650E2B04E06A7BD5D@onstor-exch02.onstor.net>
 <20071120135600.72d425be@ripper.onstor.net>
 <BB375AF679D4A34E9CA8DFA650E2B04E06B7AC16@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 Sun, 25 Nov 2007 17:35:49 -0800 "Jonathan Goldick"
<jonathan.goldick@onstor.com> wrote:

> See JG>
> 
> -----Original Message-----
> From: Andy Sharp 
> 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.
> > 
> > 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.
> 
> JG> No, learn to enjoy the Windows world via Citrix.  Visio is our
> JG> 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.

While I'm sure there are many wonders in Windows that await me, and
many, many I've already experienced, this is at best a
rationalization.  By not utilizing a standards based format, you
are merely dooming yourself to fail to reach your full intended
audience. Or put another way, there's a reason no one puts Visio
documents on the web.  BTW, there are plenty of pdfs on mightydog that
were authored using visio, so it can't be that hard to export one doc.

> 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
> JG> 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.

Yes I see that.

> 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
> JG> here?
> Are you just objecting to the heading about limitations?

Not following you here.  This was a self contained comment that you
already mentioned was replied to by Max.  Unfortunately Max's comment
would seem to indicate that rbash may not be of use to us, but some
experimentation is indicated.

> 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?

This requirement isn't dubious, but it is an important rewording of
what I originally read. I believe that we can satisfy this requirement
with built in capabilities of bash, as Rendell expounded on, so it's
all good.

> 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?

Sorry to say but I only have vague ideas here.  What I was thinking was
adding to the uses of the management volume by adding a filesystem to
it. We could also make the management volume mirror-able like any
other volume.  Currently I don't know if the management volume is per
filer or per cluster, but obviously I'm talking about a per cluster
paradigm. It could be made available to all the filers in a cluster
with NFS.

> 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?

You lost me here, but my comment would seem to be negated by the
information in Max's reply anyway.
