Re: Running Commands on multiple systems

The one thing I did really wish I could easily do that did not work well

oevr ssh was the running of SQL on each LPAR.


Try something like this: system -i "call QSYS/QZDFMDB2 parm('select * from
table')"

Also, a new open source project was started a few days ago that could help
(result sets in JSON/XML): http://bit.ly/db2util (special thanks to Tony
Cairns of IBM for this)


Aaron Bartell
litmis.com - Services for open source on IBM i


On Wed, Jul 27, 2016 at 4:46 PM, Evan Harris <auctionitis@xxxxxxxxx> wrote:

I meant to get back to this earlier but real world events intervened..

After a bit of experimentation I think in most cases the need to run a
command on remote systems might be manageable by using ssh from come
central point, for instance for running a CRTUSRPRF, a WRKSYSSTS etc. It
might be more problematic for more complex operations, particularly in
terms of capturing output.

For the purposes of the scenario I am looking at, writing and deploying a
command processing web service might be viewed as re-inventing the wheel as
there are a number of tools that have some coverage for parts of the job. I
would readily concede that such a web service would work better than
something cobbled from various almost OK services.

Setting up some remote dataqueues might be a small enough change or
addition to what we have, and I have gone this route in the past, so this
might well be part the eventual solution.

The one thing I did really wish I could easily do that did not work well
oevr ssh was the running of SQL on each LPAR. For instance, if I wanted to
collect PTF information on each system it's just a matter of running a SQL
statement on each machine and collating the output. I could not find (and I
am still looking for) a simple way of doing this.

I spent some time trying to use the Access Client SQL interface to try and
engineer something that would allow me to connect to system 1, run a
statement, connect to system 2, run a statement, etc etc but could not find
a way to do it. I could use the download plugin or the cldownload function
but the inclusion of the SQL statement was pretty ugly. if I could include
a script or file to run this might well work for me (or if I could run it
from ssh even better...) so I may end up wrapping this SQL stuff in a
wrapper and running it via a front end command over ssh then picking up the
output in a similar way.

Given the amount of services being exposed by SQL it would be great if we
could more easily run the SQL over ssh or even via the Access client for
multiple systems to easily collect this stuff. I am thinking i might even
fall back on perl or python and script this stuff using an odbc connection.
Not my first preference but probably workable and over the long haul it
might be more configurable.


On Wed, Jul 27, 2016 at 6:12 AM, Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx> wrote:

My thought would be along the same line however I'd use remote data

queues

instead.

Send the command you want to the remote data queue(s)

Data queue program picks it off the queue and runs it.

Now you can specify the user profile to run the command if you either set
up a switch user API or just run the data queue receiver with that
profile. It does not necessarily limit what command you want to run.
Depending on how you code it you could selectively send the command to
different partitions, etc.. You can make the receiving program as smart

or

dumb as you would like it to be. Start out simple and add function as

you

go. It could give return codes, or CPF messages. It could be done
entirely in CL, or RPG, or COBOL, or anything really, you pick.

it also avoids the need to have the web servers running which can be
problematic if one of the things you want to do is restart the HTTP/WAS
servers..

Jim Oberholtzer
CEO/Chief Technical Architect
Agile Technology Architects

On Tue, Jul 26, 2016 at 11:11 AM, Nathan Andelin <nandelin@xxxxxxxxx>
wrote:

My first inclination would be to write and deploy a command-processing

web

service on each system and pair it with a command entry client. Enable
users to broadcast requests to all systems, or selected systems. As an
alternative to web services, I'd look into setting up remote DB server
entries and using an SQL interface for running commands on selected

remote

hosts.

Just some thoughts to stir discussion.


On Sun, Jul 24, 2016 at 8:56 PM, Evan Harris <auctionitis@xxxxxxxxx>
wrote:

Hi All

I have a situation where I have a number of systems (10+) that I need

to

be

running commands on every now and then and I was curious as to the
approaches others took when running commands across multiple systems.

The servers are a mix of i and p LPARs (but let's primarily stick to

the

i

LPARs for the purposes of this exercise) running on top of VIOS and

with

a

HMC managing them.

It seems that something like the AIX dsh command would be really

handy,

but

I wondered what other options were out there and why they were

preferred. I

would really like to capture the output instead of having it roll out

in

a

spool file that I have to somehow also get back to check successor

failure.

Options I have available to me:
(1) Sign on to every system and manually do stuff system by system
(2) SSH is running on all systems, so connect via SSH from some

central

place (NIM Server ?) and run a command
(3) Ops Navigator via the Mgmt Central Task stuff
(4) Navigator for i (does that have anything comparable)
(5) Nominate a central i server and use one of SSH, RunRmtCmd
(6) Write a script somewhere central and use ODBC or SSH to run on

multiple

systems (Python ? Perl ?)
(7) Run a command or script via SSH from central HMC
(8) Some kind of SCOM tooling (looking at SCOM for monitoring)
(9) SNADS solution of some kind....
(10) something else I have not thought of

I am kind of interested in commercial solutions but most unlikely to

buy

anything. I don't really want to add another sever into the mix, I'd

rather

run it centrally on one of the existing platforms.

I am interested in how others have "cracked this nut" so feel free to

share

how you are doing this now or have done it in the past


--

Regards
Evan Harris
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)

mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--

Regards
Evan Harris
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.