Re: Getting remote variables more efficiently (138 Views)
Reply
Super Advisor
Patrick Ware_1
Posts: 216
Registered: ‎12-14-2004
Message 1 of 6 (138 Views)
Accepted Solution

Getting remote variables more efficiently

Hello all,

I have a script that has to get variables remotely. Rather than having the script login to the remote server 3 separate times, is there a faster way to get each variable?

CODE
--------------------------------------------------------------------
##Server comes from input or list##


CHKINSTALL=`ssh server "swlist | grep -i program" | grep -v Running | awk '{print $1}'`
CHKVERSION=`ssh server "swlist | grep -i program" | grep -v Running | awk '{print $2}'`
CFEPROCESS=`ssh server "ps -ef | grep -i program > /dev/null ; echo $?" | grep -v -e grep -e Running`
Acclaimed Contributor
James R. Ferguson
Posts: 21,184
Registered: ‎07-06-2000
Message 2 of 6 (138 Views)

Re: Getting remote variables more efficiently

Hi:

Perhaps (by example):

# ssh myserver -n 'MODEL=$(model);HOST=$(echo $(hostname));UNAME=$(uname -a);echo "${MODEL}:${HOST}:${UNAME}"'

Regards!

...JRF...
Honored Contributor
Bill Hassell
Posts: 14,218
Registered: ‎05-29-2000
Message 3 of 6 (138 Views)

Re: Getting remote variables more efficiently

Variables (shells such as ksh and HP's POSIX sh) can hold megabytes of data. Put everything in one variable and then parse locally at memory speeds:

SWLISTOUT=$(ssh server /usr/sbin/swlist)
CHKINSTALL=$(echo "$SWLISTOUT" | grep -i program | grep -v Running | awk '{print $1}')
CHKVERSION=$(echo "$SWLISTOUT" | grep -i program | grep -v Running | awk '{print $2}')

Grave accents `` are obsolete and deprecated in the man pages. Use $(command...) instead.

ps|grep is full of mistakes. Use ps to locate programs by name using the UNIX95 variable to activate -C and -o features:

CFEPROCESS=$(ssh server UNIX95=1 ps -C program -o pid= -oargs=)
Super Advisor
Patrick Ware_1
Posts: 216
Registered: ‎12-14-2004
Message 4 of 6 (138 Views)

Re: Getting remote variables more efficiently

Thanks for the replies.

-------------------------------------------
CFEPROCESS=$(ssh server UNIX95=1 ps -C program -o pid= -oargs=

-------------------------------------------

Bill, I've never used the UNIX95 command. I noticed the flags you used for the pid and other arguments. Is the "-o pid=" required?


Exalted Contributor
Steven E. Protter
Posts: 33,806
Registered: ‎08-15-2002
Message 5 of 6 (138 Views)

Re: Getting remote variables more efficiently

Shalom,

Bill's UNIX95 argument is required for values on his recommended ps command.

Without setting the variable, you won't get the data.

First time I saw this, I got all excited and set UNIX95 in my /etc/profile . That was a bad idea, as it broke several things on the system.

You need UNIX95 for the command Bill recommends.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Honored Contributor
Bill Hassell
Posts: 14,218
Registered: ‎05-29-2000
Message 6 of 6 (138 Views)

Re: Getting remote variables more efficiently

> Bill, I've never used the UNIX95 command. I noticed the flags you used for the pid and other arguments. Is the "-o pid=" required?

UNIX95 is a variable, not a command. It is an underutilized feature of the shell that you can temporarily assign a variable for the duration of the command by making the assignment in front of a command. UNIX95 (when defined) enables 3 VERY useful options:

-C exact-process-name
-H show hierarchy of parents and children
-o make your own customized ps command

-C is the only way to stop grep failures -- let ps find the process in the kernel's process table. So ps -C sh and ps -C ksh will get exact matches.

-o allows you to choose the columns you want in the output. The optional = sign says use this label instead of the default, and with nothing following the two option= arguments, ps removes the title line completely, perfect for scripting.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.