[xcat-user] Design of dsh/dcp for xCAT 2.0

Thu Nov 8 12:36:58 MST 2007

I don't mean to argue with you over this, I just don't agree that xCAT
should have two commands in that do the same thing.

- What customers use dsh in their scripts?  xCAT 2.0 is new for people
who have already written many scripts that depend on xCAT 1.3.  They
will need to migrate as well.

- Why can't CFM run under psh?  If you're going to support rdist in a
future dsh, why not just put that functionality into psh?

- xCAT psh already has a dshbak like command called xcoll

- with xCAT 1.3 I always run psh on client.

I must be missing something...

Vallard

On Nov 8, 2007 6:02 AM, Lissa Valletta <lissav at us.ibm.com> wrote:
>
>
> There are several reasons, we are bring dsh/dcp over to xCAT. First is we
> are going to migrate customers to xCAT who have been using dsh/dcp for many
> years and have developed their own scripts using these commands. dsh/dcp has
> a rich set of configurable options that are widely used. It is also needed
> for the CFM ( Configuration File Management Function) which will also be
> incorporated into xCAT. dcp not only support a scp, rcp but an rsynch and in
> the future rdist interface. The dshbak command which formats the output, is
> critical when we are returning data from large distributions.
>  As you suggest, one option could be to just not have dsh/dcp run in the
> client server mode, but only on the Management Server (MS) with an xCAT
> Context. It needs the xCAT Context, because dsh/dcp still needs to know how
> to convert nodegroups and noderanges to lists of nodes from the xCAT DB. It
> was under our impression though, that there would be a desire to run dsh/dcp
> from a client, not have to be on the MS.
>
>  psh is not going away. We will support both.
>
>
>  Lissa K. Valletta
>  414/3-8
>  Poughkeepsie, NY 12601
>  (tie 293) 433-3102
>
>
>  "Vallard Benincosa" <vallard at gmail.com>
>
>
>
>
>
>
>
> "Vallard Benincosa" <vallard at gmail.com>
>
>  Sent by: xcat-user-bounces at lists.xcat.org
>
> 11/07/2007 05:09 PM
> Please respond to
>  xCAT Users Mailing list <xcat-user at lists.xcat.org>
>
>
> To
>  "xCAT Users Mailing list" <xcat-user at lists.xcat.org>
>
>
> cc
>
>
>
> Subject
>  Re: [xcat-user] Design of dsh/dcp for xCAT 2.0
>
>
>
>  Why do you need dsh/dcp when xCAT has psh and pscp?  If it doesn't
>  need xCAT for some of its functionality, why not just break it out
>  entirely?  I just need to be educated...
>
>  On Nov 7, 2007 1:20 PM, Jarrod B Johnson <jbjohnso at us.ibm.com> wrote:
>  >
>  >
>  > I see three modes of operation:
>  >  -The way the xCAT 2.0 psh works today. It simply asks the server to
> resolve
>  > the noderange for it, then spawns the ssh processes normally from the
> same
>  > point the client is run. This means xCAT doesn't worry about privilege
>  > escalation nor about trying to get in the way of pscp. It also means
>  > communications within the cluster are more straightford (i.e. a psh node2
>  > from node1 results in ssh being run on node2 instead of pulling in the
>  > management server. The behavior is easiest to 'get right' (i.e. files
>  > created during psh are owned by the user executing psh, performance would
> be
>  > probably better if psh is used from non-management nodes frequently. The
>  > downside being that your management station executing psh would either
> have
>  > to have all the nodes routable, or ssh to a part of the cluster, but I
> don't
>  > think this is too much to ask personally, but administrators seeking
>  > client/server should speak up. Having written the basic xCAT 2.0 psh, I
> may
>  > be a little biased...
>  >
>  >  -The way dsh appears to be implemented in the alpha today, which gets
> the
>  > management server having to execute the ssh processes and running them as
>  > root. The possible feature or concern here is that it winds up being
>  > essentially sudo. I'm jbj and I psh rack1 touch /tmp/file and /tmp/file
> gets
>  > owned by root, instead of jbj, hypothetically. I'm not positive the
> security
>  > measures in place are appropriate for this activity, not to mention the
>  > behavior may not appear correct. Also, an scp becomes more complicated,
> file
>  > must transfer to the management server then to the clients, without a
> good
>  > clue as to where it should transiently sit, and putting a bizarre
>  > non-obvious filesystem restriction that can fail the transaction. This
> does,
>  > however, mean an outside management station can execute a parallel shell
> to
>  > nodes without having direct routes to them.
>  >
>  >  -Attempt to manage identities and execute ssh from the management
> server.
>  > In this model, it's like above, but xcatd sets the uid before execing ssh
>  > based on the client identity. The added limitation here is that now every
>  > xCAT identity must have an /etc/passwd account for a parallel shell to
> work.
>  > This still has all the load probably inappropriately on a smaller set of
>  > servers, and still leaves parallel scp complicated. Additionally, again
> I'm
>  > not confident in the ability of the security mechanism to do this
>  > reasonably.
>  >
>  >  Lissa Valletta---11/07/2007 03:01:03 PM---I am currently working on
> taking
>  > the IBM dsh/dcp shipped with several IBM products and incorporating them
>  > into xCAT 2.0. A coup
>  >
>  >
>  >
>  >  From:
>  >  Lissa Valletta/Poughkeepsie/IBM at IBMUS
>  >
>  >  To:
>  >  <xcat-user at lists.xcat.org>
>  >
>  >  Date:
>  >  11/07/2007 03:01 PM
>  >
>  >  Subject:
>  >  [xcat-user] Design of dsh/dcp for xCAT 2.0
> ________________________________
>  >
>  >
>  >
>  >
>  >
>  > I am currently working on taking the IBM dsh/dcp shipped with several IBM
>  > products and incorporating them into xCAT 2.0. A couple of design
> questions
>  > have come up.
>  >  Current IBM dsh/dcp supports multiple contexts. These contexts are
> really
>  > just perl *.pm library routines ( plugins) that tell dsh/dcp how to get
>  > nodegroups and list of nodes in those nodegroups, in whatever context
>  > (environment) they are running.
>  >
>  >  In the alpha of 2.0 we have xCAT- xdsh client that invokes, through the
>  > daemon, the xdsh/xdcp plugin which calls IBM dsh/dcp with an XCAT
> context.
>  > The XCAT.pm context reads the xCAT database for the list of node groups
> and
>  > nodes.
>  >
>  >  In the future, we want to not have xdsh/xdcp plugin call IBM dsh/dcp but
>  > our own xdsh/xdcp using an api interface. dsh/dcp would become part of
> the
>  > xCAT product. The interesting thing here is when we go through the
> daemon,
>  > the nodegroups, noderanges, and nodelists are automatically resolved to a
>  > node list before it gets to the xdsh/xdcp plugin. So in reality there is
> no
>  > need for an xCAT Context in this scenario at all, since that is all the
> xCAT
>  > Context does. We could for efficiency come up with some No Context for
>  > xdsh/xdcp, to avoid loading the xCAT Context and just run off the
> nodelist
>  > supplied by the daemon for the case where we are running in the
>  > client-server mode. The other option is to not support contexts in
> dsh/dcp
>  > at all, but just code to the xCAT requirements.
>  >
>  >  One question is do we see further need for contexts. Would there be
> other
>  > areas that would want to use dsh/dcp and read their node lists from some
>  > other source to supply to a dsh/dcp.
>  >
>  >  A second question is do we also need to support an xdsh/xdcp in a
>  > non-client server mode . This would be a scenario, where a user would run
>  > xdsh/xdcp and not go through the daemon. If this is needed then xdsh/xdcp
>  > would still need the xCAT context to resolve the nodegroups to nodelists
> and
>  > also expand the supported noderanges that xCAT has today. The obvious
> reason
>  > for this mode is for a non-root user to use dsh/dcp.
>  >
>  >  Any ideas on the design and future use of dsh/dcp in xCAT, or any other
>  > mode, are appreciated.
>  >
>  >
>  >  Lissa K. Valletta
>  >  414/3-8
>  >  Poughkeepsie, NY 12601
>  >  (tie 293) 433-3102
>  >  _______________________________________________
>  >  xcat-user mailing list
>  >  xcat-user at lists.xcat.org
>  >  http://www.xcat.org/mailman/listinfo/xcat-user
>  >
>  >
>  > _______________________________________________
>  > xcat-user mailing list
>  > xcat-user at lists.xcat.org
>  > http://www.xcat.org/mailman/listinfo/xcat-user
>  >
>  >
>  _______________________________________________
>  xcat-user mailing list
>  xcat-user at lists.xcat.org
>  http://www.xcat.org/mailman/listinfo/xcat-user
>
>
> _______________________________________________
> xcat-user mailing list
> xcat-user at lists.xcat.org
> http://www.xcat.org/mailman/listinfo/xcat-user
>
>