OBII3.1: install hosts error (97 Views)
Reply
Occasional Advisor
Gengwd
Posts: 17
Registered: ‎03-30-2000
Message 1 of 4 (97 Views)

OBII3.1: install hosts error

Hi,
I encountered a problem when install a host.

A cell manager & IS is in a N-class system, I intend to distribute disk agent to a R-class system remotely. When use "Edit->Install Hosts->Unix Hosts", it prompted a Critical Message. Below is the message :
"importing host 10.xx.xx.xx...
[Critical]: from INET@XX XX Time:XX
security violation: Host not in local cell"

the R-system use DNS, the N-system use /etc/hosts.

Why does this? Thanks for your help!
Ping-Jian Xiao
Honored Contributor
Alex Glennie
Posts: 4,068
Registered: ‎05-07-2000
Message 2 of 4 (97 Views)

Re: OBII3.1: install hosts error

this is a networking problem of sorts I suspect, try an nslookup from the N class to the R class if it fails there's your problem !

I'd try and include the N class into DNS and revert back to /etc/hosts if problems : see /etc/nsswitch.conf

If it's not that, what type of networking are we talking ? .... token ring etc ?

Make sure you have the latest omniback patches and be aware there's a variable : OMNI_HOSTS which may still be around at OB 3.1 and added to an .omnirc file to help. Try the above first though !
Email : alex_glennie@hotmail.com
Trusted Contributor
alberto vasquez
Posts: 119
Registered: ‎05-08-2000
Message 3 of 4 (97 Views)

Re: OBII3.1: install hosts error

First of all - identify how many network cards you have on each system, what are the names and IP addresses associated with each of them, and which card is primary.

As mentioned above, this error is probably name resolution related, although there are all sorts of variations on this theme.

If you have more then one network card - we must use the name of the PRIMARY network card to start with (even though that card is NOT on your backup network...) After that "server" was imported into Omniback, we could then IMPORT 'additional hostnames' or 'virtual hostnames' for each additional network card.

If you have only one network card, then focus on name resolution and NSLOOKUP.

Do the following steps at the prompt for the machine you wish to bring into Omniback...

Test resolution of the machines own name

1. What is the output of the HOSTNAME
1b. use this in the nslookup below
2a. How about uname -a?
2b. if this differs from hostname, why?
3a. nslookup servername.domain.com
3b. what was the ip, write this down
3c. what was the FIRST name returned
3d. what was the first ALIAS returned
3e. what were any additional aliases
3f. note resolved via files/hosts, DNS, NIS?
4a. nslookup servername
4b. what was the ip, did it match 3b?
4c. does the FIRST name match 3c?
4d. does first ALIAS match 4d
4e. what were any additional aliases
4f. resolve from files/hosts, DNS, NIS?
5a. nslookup ip.ip.ip.ip
5b. what was resolved ip, did it match 3b?
5c. does the FIRST name match 3c?
5d. does first ALIAS match 4d
5e. what were any additional aliases
5f. resolve from files/hosts, DNS, NIS?

You will do similar steps for aliases...

You will do similar steps to test resolution from this client machine of the cell server name.

At the cell server do all of these tests AGAIN...looking for the cell server name, the name of the remote client, aliases, etc...

Here is the basic idea...

if you are resolving from files, and DNS (both in your environment) the files format needs to look like this...

ip.ip.ip.ip servername.domain.com servername

This searches with this format returns in the same way as DNS.

The key is consistency. If DNS is used, host should be formatted to match DNS output.

If DNS is not used, hosts files should be consistent everywhere.

It is a lot of work - but Omniback is critically dependent on name resolution being consistent.

-Joseph Wyckoff
Trusted Contributor
alberto vasquez
Posts: 119
Registered: ‎05-08-2000
Message 4 of 4 (97 Views)

Re: OBII3.1: install hosts error

By the way, if there is any kind of advanced security in place, you will have to look at that.

Since the error is on import, that doesn't seem a likely issue - but Omniback does not work well with firewalls or proxies.

At installation time we need access to certain services that the security concious like to disable - we need more than just telnet...

-Joseph Wyckoff
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.