Has this server been backed up by any other backup server before this. Also I see that the client is on 8.1.1, can you uninstall NetWorker off the client machine, rename the "EMC NetWorker" folder under the installation path then install the 8..2 client version on it and try again.
1.) You're using a new NIC and I guess that you're using new host names and IPs. Ensure that those new host names (client, server, storage node) and IPs are correct specified and can be resolved (e. g. /etc/hosts)
2.) The client was integrated before and the client has a valid configuration, try to delete the old peer configuration:
At NetWorker server command line, go to the location /nsr/res
Type the command:
nsradmin -p nsrexec
print type:nsr peer information; name:client_name
delete
y
At the client/storage node command line, go to the location /nsr/res
Type the command:
nsradmin -p nsrexec
print type:nsr peer information
delete
3.) Check that the servers file on the client contains the correct information of the NetWorker server (or delete the content of the file for test purposes). Not that the servers file blocks the NetWorker server from controlling the client.
4.) In the NetWorker client configuration (as far as I remeber the "global 2/2" tab) contains an interface field. Type the FQDN of the NW server interface of the related NIC to the field.
5.) Try to first configure the client without the wizzard and afterwards you can try the wizzard.
Yes. added the servers second NIC IP and the client second NIC IP in both of the hosts files. They can ping each other. Even the first step of adding a client works. Add creation Legato server sees there is a networker install on those clients...
Hasn't this to do with GSS authentication ? If so, where to i have to disable nsrauth ?
That is correct if servers file does not exist or is not populated then any Networker server should be able to contact and proceed. This is allowed but against best practice.
You should be able to use any IP address as long as name resolution and networking allow. Which one NetWorker uses for initial communication is dependent on the networking side as we sit above this as a application. Once we have “authenticated” we can specify specific interfaces for communication with Storage nodes via names/aliases or with the NetWorker server via Server interface variable on client definition.
Check simple tests like ping, traceroute/tracert etc between NetWorker server and client to make sure your routing etc is good. You have already said you use local hosts file for name resolution so I assume all relevant entries here are correct.
As for using nsrauth v oldauth – you can try this as a test but we should not have to change this to cope with multiple NICs on a host and increasingly some functionality depends on nsrauth being in place.
maybe I'm wrong. but I guess, that deleting the peer configuration might be needed (SSL key matches between the NMC Server and the NetWorker client). You also might think about deleting the /nsr folder on the client.
In your case you will have an additional NIC bound to the client. now you have two NICs and you should have two IPs and at least two hostnames (one per IP) and maybe also a short name (which should point on the NetWorker site to the new NIC IP). In the Client configuration tab "Globals (1 of 2)" you list all host names and aliases. So it might be, that e. g. the client was integrated before using the short name. Now you integrate the client again and this might lead to problems. It might also be, that NW server will now use the NICs IP of the client, but the Client will use the old NICs IP.
To be on the save site:
- Check on the client site the NSRLA configuration (to know which hostname is used by the client, e. g. short name or old NIC FQDN).
- Try whether deleting the per information will help. Afterwards a new SSL key is exchanged.
- You can also try to check the NSRLA section of the NW server, NW storage node and console server. Not that NW is using a different hostname than you expect (e. g. a short name, which points in your /etc/hosts file to the old NIC interface).
Hope that my suggestions will not guide you to the wrong direction :-)
masonb
445 Posts
0
February 3rd, 2016 00:00
JohanRM,
Have you added new aliases to the Client and Networker server client definitions?
Have you added new alias to servers file on client for the NetWorker server?
Do both local hosts files have the same entries for the IP/names for the respective servers?
Regards,
Bill Mason
crazyrov
4 Operator
•
1.3K Posts
0
February 3rd, 2016 00:00
Hi JohanRM,
Has this server been backed up by any other backup server before this. Also I see that the client is on 8.1.1, can you uninstall NetWorker off the client machine, rename the "EMC NetWorker" folder under the installation path then install the 8..2 client version on it and try again.
JohanRM
1 Rookie
•
79 Posts
0
February 3rd, 2016 01:00
Those clients have been abced up by another server in another domain.
Rgds
Johan
Kleinenbroich
86 Posts
0
February 3rd, 2016 01:00
Hi JohanRM,
your issue can have several issues.
1.) You're using a new NIC and I guess that you're using new host names and IPs. Ensure that those new host names (client, server, storage node) and IPs are correct specified and can be resolved (e. g. /etc/hosts)
2.) The client was integrated before and the client has a valid configuration, try to delete the old peer configuration:
At NetWorker server command line, go to the location /nsr/res
Type the command:
nsradmin -p nsrexec
print type:nsr peer information; name:client_name
delete
y
At the client/storage node command line, go to the location /nsr/res
Type the command:
nsradmin -p nsrexec
print type:nsr peer information
delete
3.) Check that the servers file on the client contains the correct information of the NetWorker server (or delete the content of the file for test purposes). Not that the servers file blocks the NetWorker server from controlling the client.
4.) In the NetWorker client configuration (as far as I remeber the "global 2/2" tab) contains an interface field. Type the FQDN of the NW server interface of the related NIC to the field.
5.) Try to first configure the client without the wizzard and afterwards you can try the wizzard.
Regards
Michael
JohanRM
1 Rookie
•
79 Posts
0
February 3rd, 2016 01:00
Yes. added the servers second NIC IP and the client second NIC IP in both of the hosts files. They can ping each other. Even the first step of adding a client works. Add creation Legato server sees there is a networker install on those clients...
Hasn't this to do with GSS authentication ? If so, where to i have to disable nsrauth ?
Rgds,
Johan
bingo.1
2.4K Posts
0
February 3rd, 2016 02:00
Do not forget that you must
- correct the ..\nsr\res\servers file on the client so that the new server will be added/exchanged
- restart the NW client daemon/service to re-read the new configuration
JohanRM
1 Rookie
•
79 Posts
0
February 4th, 2016 01:00
Hi,
I am still in test phase. So, i have to be able to backup the client that got a second IP using his first old IP as well after the test.
Why should i delete te peer configuration of a client with another name ?
I have the impression that the issue has to do with GSS authentication.....
I saw someone saying: to disable the strong authentication using the nsadmin interface
What do you think of that piste ?
Johan
masonb
445 Posts
0
February 4th, 2016 01:00
JohanRM,
That is correct if servers file does not exist or is not populated then any Networker server should be able to contact and proceed. This is allowed but against best practice.
Regards,
Bill Mason
JohanRM
1 Rookie
•
79 Posts
0
February 4th, 2016 01:00
No entries in servers file so no need to add the new one as well. No ?
masonb
445 Posts
0
February 4th, 2016 02:00
JohanRM,
You should be able to use any IP address as long as name resolution and networking allow. Which one NetWorker uses for initial communication is dependent on the networking side as we sit above this as a application. Once we have “authenticated” we can specify specific interfaces for communication with Storage nodes via names/aliases or with the NetWorker server via Server interface variable on client definition.
Check simple tests like ping, traceroute/tracert etc between NetWorker server and client to make sure your routing etc is good. You have already said you use local hosts file for name resolution so I assume all relevant entries here are correct.
As for using nsrauth v oldauth – you can try this as a test but we should not have to change this to cope with multiple NICs on a host and increasingly some functionality depends on nsrauth being in place.
Regards,
Bill Mason
Kleinenbroich
86 Posts
0
February 4th, 2016 06:00
Hi JohanRM,
maybe I'm wrong. but I guess, that deleting the peer configuration might be needed (SSL key matches between the NMC Server and the NetWorker client). You also might think about deleting the /nsr folder on the client.
In your case you will have an additional NIC bound to the client. now you have two NICs and you should have two IPs and at least two hostnames (one per IP) and maybe also a short name (which should point on the NetWorker site to the new NIC IP). In the Client configuration tab "Globals (1 of 2)" you list all host names and aliases. So it might be, that e. g. the client was integrated before using the short name. Now you integrate the client again and this might lead to problems. It might also be, that NW server will now use the NICs IP of the client, but the Client will use the old NICs IP.
To be on the save site:
- Check on the client site the NSRLA configuration (to know which hostname is used by the client, e. g. short name or old NIC FQDN).
- Try whether deleting the per information will help. Afterwards a new SSL key is exchanged.
- You can also try to check the NSRLA section of the NW server, NW storage node and console server. Not that NW is using a different hostname than you expect (e. g. a short name, which points in your /etc/hosts file to the old NIC interface).
Hope that my suggestions will not guide you to the wrong direction :-)
Regards
Michael