Access hpux remotely

[Matti_Kurkela]

> Ssh client u mean cygwin or something right ? or any specific client which will meet my requirement

Are you waiting for an answer to this? Yes, *any* SSH client should work, if your lan console (MP or iLO MP) supports the SSH protocol.

Bill Hassell suggested PuTTY, which is free, simple to install, supports both SSH and telnet, and has plenty of features too.

The newest versions of PuTTY even support direct serial connections, so if you ever need to access a HP-UX system console locally, you only need a serial cable (+ maybe a USB->serial converter, if your computer does not have a serial port) and you can access the system with the same tool you're already familiar with.

[coollllllllllll]

Hi Matti ,

I think my reqmnt is still not clear with you.

As per Bill 

" Would not recommend using a Windows box and remote desktop access. The terminal licensing error is from the Windows environment and remote desktap/terminal services is 100x more complicated (network traffic) than ssh or telnet access"

But the problem in our environment is we have to take 40 servers sessions.

Each server minimm session is of 30.

Is lan console capable of handling so many remote sessions ?

We cannot take puty directly because all our main jobs run in foreground , and if any 1 of main job fails we have to restore database and carry out main jobs again . Likewise we have 150 clients.

What we do is take remote desktop "win 2003" server and from there we get in that netowrk [lan] and and then wetake putty to avoid any link drop issue from location that we handle main jobs.

Sevrers are kept in B location and we access from location A with 10mbps link.

[Matti_Kurkela]

OK, now I understand... the problem is not that you must use Windows per se.

The actual problem is that your "main jobs" need a babysitter. :-)

There are several ways to solve this problem.

For example, you might install a freeware utility called "screen".

You can get it from here:

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/screen-4.0.3/

Before installing it, you must first install its run-time dependency, the termcap library:

http://hpux.connect.org.uk/hppd/hpux/Development/Libraries/termcap-1.3.1/

Once you have installed the screen utility, your clients can run the "screen" command before starting the main jobs. At that point, the screen utility will display its copyright message, and then the shell prompt will come back. But now, the shell session is "wrapped" by the screen utility: if the connection is lost, the commands run within the screen session will keep running, and the user can login to the HP-UX system again and run "screen -r" to reconnect to his session that is still running the main jobs.

You can even have multiple detached screen sessions running at the same time; in that case, you may have to use "screen -ls" to list your sessions and then use "screen -r <session name>" to select a session you want to reconnect to.

The screen utility has many more features, but I think these are the ones you need the most.

If you google with keywords "using screen", you will find many tutorials about the screen utility.

If your main jobs don't need any input once they have been started, it might be possible to start them in a special way that protects them from disconnections. The standard HP-UX command "nohup" does that.

For example, if a job is started with a command like:

$ start_main_job some_parameters

 ...then you could start it in this way instead:

$ nohup start_main_job some_parameters &

 In this way, the job is started in the background, and any output it may produce will be stored in a file named "nohup.out" in the user's current working directory.

If you want to give a different name to the output file (this might be a good idea, as you have many jobs running simultaneously), you could do this:

$ nohup start_main_job some_parameters >/some/where/main_job_output.txt 2>&1 &

 This will direct both the standard output and the standard error output of the job to a file named /some/where/main_job_output.txt.

If you want to keep monitoring the job as it runs, you can use "tail -f /some/where/main_job_output.txt" (or "tail -f nohup.out").

[coollllllllllll]

Hi Matti ,

Screen utility is awesome.

Can we also take screenshot of entire activity carried out in that screen ?

Also can we get the following script running called test.sh ;

script /dev/null

screen

screen -S mign_${date}

while true

do

date

sleep 1

done

What happens is am not able to get the desired o/p  i.e. date getting displayed in loop after 1 sec each 

Is it becuase of shell that it internally invokes , am not able to get desired o/p .

My reqmnt is i have a user called mign which when logged in , say by su - mign ,

i must be able to name that screeen session as mign_date .

Also would like to record entire activity carried out in that screen

[Matti_Kurkela]

If you start the "script" command *after* the "screen" command, it will record whatever is happening within the screen session, and it will also stay with the screen session if it gets detached for any reason.

Also "script /dev/null" does not make sense: it is like setting up a printer so that its output goes directly into a paper shredder.

Both screen and script are special commands, in the sense that they "encapsulate" the session in order to do something special with it: screen does it to allow detaching/reattaching, and script does it to record everything that happens within the session. (Actually, both will start a sub-shell to continue the session: when the sub-shell exits, the respective special function also ends.) When you need to script one of these "encapsulating" commands, you'll usually need to pass the command(s) you want to run within the encapsulation as options on the command line that starts the respective encapsulating command.

So... I would do your example like this:

screen -S $(whoami)_${date} script /some/where/activity_${date}.log /some/where/activity.sh

 ... and the /some/where/activity.sh would contain this part:

#!/bin/sh
while true
do
    date
    sleep 1
done

(It's also possible to pile it all up into a one-liner, but it would be a very long and confusing line.)

Explanation: First, the outermost encapsulation is screen, with a custom name for the new screen session, and a command to execute.

That command is script, with a specified file to log into, and a custom command (the activity.sh script) to execute.

If the "activity.sh" script terminates for any reason, then the "script" command will also terminate immediately after that... and that will cause the screen to terminate too.

Is this what you wanted?

[chindi]

Hi Matti ,

Screen is not working when i do su - user1  , and run screen from there ( Cannot open your terminal '/dev/pts/1' - please check. )

hence m using script /dev/null

I would like to set this screen logging for " user1  "

[chindi]

Hi Matti ,

Also commands like clear , top not working

Also my application scripts commands not working in screen utility .

[Matti_Kurkela]

The message "Cannot open your terminal '/dev/pts/1'" suggests this is caused indirectly by the su command.

When you log in, your terminal device is given ownership and permissions according to your login username (for example, user A). When you su to a different user (for example, user B), the terminal device permissions are not updated to match the new identity as user B. This is intentional: if the permissions were changed, it would allow other processes running as user B to open a file handle to the terminal device, and use it later to inject commands (with some terminal control code tricks) to the session of user A, after user A has exited the su but before s/he has logged out.

The strange permissions for the terminal device are not a problem for programs that are simply using the already-opened standard input/output/error streams, but any programs that want to manipulate the terminal device in advanced ways (using ioctls etc.) may have problems.

Your "script /dev/null" is an useful workaround for that. (I haven't thought about that before, thanks for the tip!)

It allocates a new terminal device for the encapsulated session, so that it can catch all the data passing between the encapsulated session and the real login session, and copy it to a file. As a side effect, the new terminal device will be owned by the current user - so the terminal device ownership problem after su will be avoided.

If you want to start the whole procedure as root, you may have to use your "script /dev/null" workaround as the first step after su.

The chain of commands to start the job must then be even longer: (one long command line, split to multiple lines with the \ characters for clarity)

su - mign script /dev/null \
    screen -S mign_${date} \
    script /some/where/activity_${date}.log \
    /some/where/activity.sh

Another possible problem is that you should have your TERM environment variable set to TERM="screen" when running within the screen utility. Normally, the screen utility does that automatically, but if you have login scripts that override the TERM value, they may cause problems for you.

You may also want to check that the terminal type definition for "screen" is installed: in HP-UX, the /usr/lib/terminfo/s/screen file should exist, and the "untic screen" command should display the terminal control codes defined for screen.

If the file does not exist, and/or the untic command reports: "untic: no such terminal: screen", then the terminal type information needs to be added.

[chindi]

Hi ,

We wont be using this through root.

this utility is to be used by non-admin logins i.e application users

We are not able to run our commands , which we use daily in our application.

Is there any way by which we can run this commands for ex clear ,  in screen session ???

[chindi]

Hi ,

We have microfocus cobol also here.

We are not able to run 1 job which uses terminfo from its default location.

I need to add this screen utility source in terminfo databse.

Do u have any idea about adding terminal screen options in terminfo databse ?