Very Computer

Hallo,

I'm using Legato Networker 5.0.1/Turbo on SPARC/Solaris 2.6.
Im trying to back up a HP-UX 10.X machine, using Client Pak for Unix
V4.2.3.

Backing up several Solaris-Machines works without problem, but when I
try to back up the HP-Box, the following error appears in
/opt/networker/logs/daemon.log:

10/05/98 16:45:46 nsrexecd: Authentication failed: Access violation -
unknown host: 130.205.140.87

Ping from server to client and reverse works - using hostname, full
qualified hostname and IP-address.

The .rhosts for root on HP-UX contains lines for the Networker-Server,
rsh from Networker to HP-UX works also.

All tests in the Networker Administration Guide (ping, rpcinfo) passed
without problem.

Any ideas ?

Thanks,
  Juergen Maihoefner

: Hallo,

: I'm using Legato Networker 5.0.1/Turbo on SPARC/Solaris 2.6.
: Im trying to back up a HP-UX 10.X machine, using Client Pak for Unix
: V4.2.3.

: Backing up several Solaris-Machines works without problem, but when I
: try to back up the HP-Box, the following error appears in
: /opt/networker/logs/daemon.log:

: 10/05/98 16:45:46 nsrexecd: Authentication failed: Access violation -
: unknown host: 130.205.140.87

Smells like a problem with confusion between the /etc/hosts file, the
DNS/NIS/NIS+ setups and which goes first.  

Check your config on each machine.

        --Dale

--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Dale Farmer Dale at accessdotdigex.net Personal opinion. Sudbury, Mass.
"Free the ISO 9000!"  --Nomi Burstein
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I've checked the name service configuration several times, but I dont't
know how to solve the problem.

My nsswitch.conf on the HP looks like this:

hosts: files[NOTFOUND=continue UNAVAIL=continue] dns [NOTFOUND=return
UNAVAIL=continue TRYAGAIN=return]
# hosts: dns [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=return]
files[NOTFOUND=return UNAVAIL=continue TRYAGAIN=return]
protocols: files[NOTFOUND=return UNAVAIL=continue]
services: files[NOTFOUND=return UNAVAIL=continue]
networks: files[NOTFOUND=return UNAVAIL=continue]
netgroup: files[NOTFOUND=return UNAVAIL=continue]
rpc: files[NOTFOUND=return UNAVAIL=continue]

the domainname:

fthw.siemens.de

/etc/hosts:

130.205.140.154 fthw011x fthw011x.fthw.siemens.de
130.205.140.87  fthw010x fthw010x.fthw.siemens.de nsrhost
130.205.140.33  nexus01 fthw006x
130.205.5.31    fthw317a
130.205.200.113  Q2451
[some more lines]

on the SUN-Servermachine:

nsswitch.conf:

# the following two lines obviate the "+" entry in /etc/passwd and
/etc/group.
passwd:     files nis
group:      files nis
# consult /etc "files" only if nis is down.
hosts:      xfn nis dns [NOTFOUND=return] files
networks:   nis [NOTFOUND=return] files
protocols:  nis [NOTFOUND=return] files
rpc:        nis [NOTFOUND=return] files
ethers:     nis [NOTFOUND=return] files
netmasks:   nis [NOTFOUND=return] files
bootparams: nis [NOTFOUND=return] files
publickey:  nis [NOTFOUND=return] files
netgroup:   nis
automount:  files nis
aliases:    files nis
# for efficient getservbyname() avoid nis
services:   files nis
sendmailvars:   files

domainname:

fthw.siemens.de

/etc/hosts:

127.0.0.1       localhost
130.205.140.87  fthw010x        loghost
130.205.140.33  fthw006x
130.205.49.11   fthw007x
130.205.204.243 FU16909D
130.205.140.154 fthw011x        fthw011x.fthw.siemens.de
130.205.55.130  fthw330x

ypcat -k hosts:

fthw011x 130.205.140.154        fthw011x
fthw010x 130.205.140.87 fthw010x
[several more lines]

Thanks,
  Juergen Maihoefner

Hi,

[SNIP]

As you pointed out in your first message the HP complains:

Quote:> 10/05/98 16:45:46 nsrexecd: Authentication failed: Access violation -
> unknown host: 130.205.140.87

I'd recommend to use the following line in nsswitch.conf on the HP:

hosts: dns [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=continue]
files[NOTFOUND=continue UNAVAIL=continue TRYAGAIN=return]
files

Then check your /etc/resolv.conf carefully.

The problem is - as far as I can see - that the HP can NOT reverse
lookup the name of the IP address 130.205.140.87

In order to test this try

nslookup 130.205.140.87 fthw011x (the HP is fthw011x, correct?)

This has to work, otherwise all remote jobs will fail.

I also recommend to use FQHN in your .rhosts file.

Hope this helps

Dieter
--
___________________________________________________________________________

Unix Systems Administrator     http://www.eur.sas.com/~eurdrk (int.)    
Systems and Operations         http://members.xoom.com/eurdrk (ext.)

SAS Institute                  Tel:  (49) 6221/416-117
European Headquarters          Fax:  (49) 6221/474850
Neuenheimer Landstrasse 28-30
P.O.-BOX 105340
D-69120 Heidelberg, Germany
___________________________________________________________________________

I've tried this, but it don't help.

Quote:

> Then check your /etc/resolv.conf carefully.

That's my resolv.conf on the HP:

domain fthw.siemens.de
nameserver 130.205.7.53     # fthw341a
nameserver 130.205.7.54     # fthw342a

Quote:

> The problem is - as far as I can see - that the HP can NOT reverse
> lookup the name of the IP address 130.205.140.87

> nslookup 130.205.140.87 fthw011x (the HP is fthw011x, correct?)

This works, as all it's aliases. (Yes, the HP is fthw011x.)

Quote:

> This has to work, otherwise all remote jobs will fail.

> I also recommend to use FQHN in your .rhosts file.

That's my .rhosts in the root-directory on the HP:

fthw010x mj4726
fthw010x.fthw.siemens.de mj4726
fthw010x root
fthw010x.fthw.siemens.de root
fthw010x
fthw010x.fthw.siemens.de
130.205.140.87

Someone told me to check whether savefs on the client works - it does !
Therefore, it's possible to back up the HP using a crontab - it's a
first
solution.

It seems that only nsrexecd has the problem - maybe, it's still a
name-service
problem.
I believe the SUN's work because they're using their own name service -
NIS - first,
the HP uses only DNS and /etc/hosts.
The man-page for nsrexecd tells about the -i switch, which should
turn-off the
reverse lookup - but it still don't work (a bug in nsrexecd ?).
I will ask our DNS-admin to check the PTR-records in-addr-arpa domain.

Thanks for the help so far,
  Juergen Maihoefner