Access hpux remotely

[coollllllllllll]

Hi ,

I need to access hpux servers kept at Y location.

What we do is take a remotedesktop of windows kept in Y location , and from there we take putty sessions .

Recently smethg went wrong and all our putty sessions got disconnected , some terminla license error.

Whats alternate way of accessing ?????

We do this to avoid link disruptions in case our windows get disconnected .

[Matti_Kurkela]

In ancient times, before the rise of the Internet, HP-UX licensing used to be based on the number of serial terminals connected to it. As time passed on, serial terminals become obsolete for regular users, and HP decided that all the remote access connections through the network, by whatever means, would be counted as a single "user" for licensing purposes.

From that point on, a "two-user license" was the standard for HP-UX: one user for the system console, and another for all the users logging in through the network. For those rare situations where serial ports were still used, HP offered an "unlimited-user license". Eventually, HP provided the unlimited-user licenses for HP-UX 10.20 and 11.00 as a free download; all the HP-UX versions after that allowed "unlimited users" by default.

So, if your HP-UX system really shows you error messages about terminal licensing, it might mean that something ancient and forgotten has awakened in your server, making demands of things long thought abolished. Now, the system administrator needs to find the legendary System Console, and use it to find out what exactly caused this nameless monster to awaken. If the cause can be found, the brave sysadmin just might be able to send the beast back to its timeless sleep, to dream about the era of the rule of modem lines and serial ports.

[Bill Hassell]

So is there a reason that you can't use PuTTY directly to the remote systems?

Using a remote desktop seems a bit clumsy.

...some terminal license error...

This is missing some very important details:

-- What version of HP-UX are you running?

    Did this error come from HP-UX?

    Or from the PuTTY window?

    Or from the remote console session?

    Or from your own PC?

-- What PuTTY connection are you using:

     telnet?

     ssh?

     port tunneling and you are really running Xwindows?

What does syslog.log show on the remote HP-UX system?

Finally, since these are remote (I assume with no local operator to walk into the computer room), do you have the console connection setup as well as one or more HP-UX ports?

[Robert_Jewell]

MK - very nice!

-Bob

[coollllllllllll]

Hi ,

We are accessing hpux servers remotely , becoz we cannot aceess them directly .

REason is we have vvimp eod processes which run at night and all are front end jobs , if our link goes down then we will have to restore everything and hence to avoid the same we are using windows remote desktop to server in same LAN and from there we take ssh of our hpux server.

Even if we loose our link , we still have these sesions connected and programs running on windows session , whenevr the link is restored.

Terminal license eror was seen on windows box , whose remote session we take .  

We need a different method of accessing hpux servers kept in "Y location "  , which must also take this link into picture.

We take remote from win xp client machines to win 2003 server remote desktop sessions.

and from which we take ssh if hpux servrs 11iv2.

[Torsten.]

Do you have more details about this

>> some terminla license error. ???



I understand you first connect to a local windows host, just in case the line from your location to the server location gets disconnected, right? So in this case the ssh session between hp-ux and windows is still alive, even if your remote desktop to windows got disconnected.

Any ssh client is still the way to go.

[Matti_Kurkela]

My earlier answer seemed to suffer from an overdose of H.P. Lovecraft literature. Sorry about that.

If you are maintaining HP-UX servers in a distant location, you will really want to have some way to access the system console. Otherwise you will be helpless if there is a major issue that causes the system boot to stop in single-user mode, or just prevents the sshd daemon from starting. In those situations, if you don't have console access, you must send someone with appropriate skills to visit the system physically.

Pretty much all currently-supported HP-UX hardware now have a management processor: a GSP, MP, or iLO MP.
These are all separate network interfaces that have their own tiny processor, which can allow console connections even if the main server has completely crashed - or even turned off, as long as the PSUs are still receiving power. Essentially, the console will have its own IP address, completely separate from the IP address(es) of the rest of the server.

Through the management processor, you can remotely control the server's power switch and TOC button, so you will be able to remotely force the system to make a crash dump and reboot, even if the server OS is totally hung.

GSP is the oldest type of management processor. Depending on exact version, it may allow only telnet connections, or telnet + web-console connections with poor encryption. These must be connected to a network segment that is protected from outsider traffic.

MP and iLO MP are newer management processors. They can support real SSL-secured web console connections and even SSH (an optional license code may be required to activate all features). Even so, exposing these management processors to Internet unprotected is still not recommended, as there have been firmware bugs that can cause the MP to lock up when port-scanned or otherwise probed, possibly denying the console access when you really need it.

GSPs must always be initially configured and enabled using a serial connection to the local system console port; MPs may use DHCP by default, so you may able to have someone plug a network cable in and then connect using a default password. (The default passwords are well-known, so you should always change them if you connect the GSP/MP to network.)

Either the Installation Guide or the User Guide for your server model(s) should include the GSP/MP cabling instructions and set-up steps.

For older HP-UX hardware, you may need an external device for making the system console port network-accessible: some advanced network KVMs may offer this functionality, or you can buy dedicated "serial device servers" specifically for this purpose. I've sometimes used Moxa NPort serial device servers: they work well, but are somewhat expensive. You may be able to find cheaper equivalents (recommendations, anyone?).

[Bill Hassell]

Serial console server products are available from:

Avocent

Cyclades

Digi International

Lantronix

Logical Solutions

MRV Communications

Raritan Computer

I've used Cyclades and Raritan. But these boxes are only for systems such as the T, K, or D-series where no LAN console exists. Otherwise use LAN-based console connections.

I strongly support Matti's recommendation about an isolated subnet. These maintenance ports are not HP-UX, they are fixed code in small memory-based environments, seldom updated (even when there are fixes available) in production systems. I would expand the isolated network to every appliance (routers, switches, tape changers, etc) console. Don't connect them to a general network. Put a bridge system in the middle with lots of security to provide access. Linux or HP-UX are ideal in this role.

I 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. I would revisit the issues that prevent you from using a simple text access method. The console is the last step in getting a problem server running -- it should be the simplest and most reliable.

[coollllllllllll]

Hi ,

Only Mr. Torsten has understood my requirement :-)

We do have lan console enabled for all of our servers.

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

[Bill Hassell]

The most common ssh and telnet client is PuTTY:    PuTTY download

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

[Matti_Kurkela]

Yes. Download the screen source code package here:

http://hpux.connect.org.uk/ftp/hpux/Sysadmin/screen-4.0.3/screen-4.0.3-src-11.11.tar.gz

The filename seems to indicate that the package is for HP-UX 11.11. Don't worry about that, you'll need just one file from that package, and that file can work in all HP-UX 11.* versions.

Find the "screeninfo.src" file inside it (located in screen-4.0.3/terminfo/screeninfo.src)

and add the information inside it to your system:

gunzip screen-4.0.3-src-11.11.tar.gz
tar xvf screen-4.0.3-src-11.11.tar
cd screen-4.0.3/terminfo
tic screeninfo.src

After that, your system should be able to recognize the "screen" terminal type, and commands like "clear", "top" etc. should work within the screen sessions.

Apparently the creator of the screen-4.0.3 .depots has forgotten to include a post-install script to the depot that would add the terminal type information automatically.

[Dennis Handly]

>forgotten to include a post-install script to the depot

More accurately a configure control script since it would have to be done on each NFS diskless system (if those still existed :-).

[chindi]

Hi Matti ,

You were spot on again.

Thanks again.

One small nagging thing alias set .profile is not working , any reason why ?

For ex alias c ='clear'  not working for a user 

[Matti_Kurkela]

If the user is configured with a different shell, e.g. tcsh or the (scummy) csh, it might run another login script instead of .profile.

If the HP-UX default /usr/bin/sh shell is used, the actual login shell will execute .profile, but the encapsulated sub-shells started by script or screen might not. Environment variables can be inherited from the (grand)parent process by the subshell, but shell aliases cannot be inherited that way.

If it is not harmful to run the user's .profile twice, the easiest workaround would be to add

export ENV=$HOME/.profile

 in the user's .profile. This tells the sub-shells to execute .profile too, so they would also get the alias definitions.

But if the user's .profile contains something that must run only once per login, a slightly more complicated solution is needed.

For example, if the user's .profile contains settings that add something to existing environment variable values, like "export PATH=$HOME/bin:$PATH", making sub-shells execute .profile would cause the user's PATH to contain those elements two or more times (e.g. the PATH value in the sub-shell would be something like /home/username/bin:/home/username/bin/:..). At best this is unnecessary repetition, and it might actually be harmful with some application-specific environment variables.

In that case, the alias definitions must first be moved into another file, for example ~/.sh_aliases.

Then, the .profile should be set to read the .sh_aliases file, and set the ENV variable so that the sub-shells will read the .sh_aliases file only:

# read the aliases from a separate file
. $HOME/.sh_aliases
# make the sub-shells read the aliases file too
export ENV=$HOME/.sh_aliases

After this modification, any commands that must run at login only should go to .profile, and commands that must run at each time a sub-shell is started should go to .sh_aliases.

[chindi]

Thanks Matti .