04-17-2014 12:41 AM
I've bee struggling with a problem for days and nights: in short, I need to back up Centos FS with a Windows Server 2008 Cell Manager.
The problem is when I install the Linux DA client . The process gives me the following result:
[root@centos02 LOCAL_INSTALL]# ./omnisetup.sh -server dpcell3 -install da
Data Protector version A.07.00 found
Client detected, installed packets: da
Packets going to be (re)installed: omnicf da
Installing Core (omnicf)...
Data Protector software package successfully installed
Installing Disk Agent (da)...
Data Protector software package successfully installed
Importing client to dpcell3...
[12:1602] Cannot access the Cell Manager system. (inet is not responding)
The Cell Manager host is not reachable or is not up and running
or has no Data Protector software installed and configured on it.
Installation/Upgrade session finished.
I can ping hosts in both directions.
I can telnet 5555 in both directions. (Return me the DP version: 7.0 in both CM and Centos)
Windows Firewall is disabled.
Centos iptables and SELinux are disabled.
/etc/opt/omni/client/cell_server is set to dpcell3
Apparently, the service xinetd (or the omni service) cannot connect with my Windows Cell Manager.
I don't know what else to do.... Please help! I'm out of ideas :(
Solved! Go to Solution.
04-17-2014 06:48 AM
in addition to the "always use FQDNs" mantra, I'd like to add that if DNS isn't under your control or isn't fixable due to other issues on layers above 7, you can always help yourself out with the hosts file (/etc/hosts on Unix, windows\system32\drivers\etc\hosts on Windows). On the client, add IPs and FQDNs for cell manager and any potential other server side host (MA host, IS host, GUI host etc). On these server hosts, add the client FQDN. Works wonders.
BTW, I like to install Unix clients locally and then use import from the GUI to get them registered with the CM. Seems to work most reliably. For that matter, I've also extracted the relevant RPMs (CORE, CC, DA are what mostly suffices), put them somewhere wget(1)able, and pull and install them manually. After that, importing the client and an initial Upgrade brings it up to speed. For upgrading, you need a Unix IS though. Ideally you put it on the first Linux box you happen to add (and which is x86_64). Without a Unix IS, patching is really getting nightmarish unless you really have just a single Linux box to deal with.
04-17-2014 10:12 AM
Thanks for your fast response.
I'm not working in a domain environment. It's just a plain network. Then I don't have FQDN for the nodes.
Also, I've added host names in the etc hosts files in both nodes, so I can ping each other by the name.
From Win CM: Ping centos02 --> responds OK
From Centos node: Ping dpcell3 --> responds OK
It is really mandatory to use FQDN?
Thanks for your help.
04-17-2014 10:48 AM
I've mannually installed DA in centos machine. From Windows CM, I did imported mannually the Centos client, and i can set up a backup for the linux fs, I can browse the linux FS. I'm not using Unix IS .
But when I run the backup, gives me a simmilar error:
[Normal] From: VBDA@centos-02 "/" Time: 16/04/2014 20:13:52
STARTING Disk Agent for centos-02:/ "/".
[Critical] From: BDA-NET@centos-02 "/" Time: 16/04/2014 20:13:52
Cannot connect to Media Agent on system dpcell3, port 49234 (IPC Invalid Hostname or IP Address) => aborting.
[Critical] From: VBDA@centos-02 "/" Time: 16/04/2014 20:13:52
Unexpected close reading NET message => aborting.
Always the same problem: the DA cannot connect to Cell Manager.
Many thanks for your help.
04-17-2014 11:51 AM
I generally would expect short naming to work correctly if it is entirely consistent between all the nodes. In theory, short naming is nothing but all FQDNs being TLDs, and that used to work since 1986 (cf. localhost). The problem is that, in practice, ignorant developers have sprinkled code bases with implicit assumptions about host names necessarily containing a domain part (they probably work next door to those who always forget that '-' is an allowed character in domain names). That brought us nonsense like localhost.localdomain (and RedHat, being essentially the blueprint for CentOS, are quite in the front row of this questionable development). But I disgress. What I want to say is that in practice, short names have quirks. Windows for instance does some weird magic when you try to resolve short names that it doesn't do when resolving FQDNs that have a domain part. It's even a difference how many parts there are, name.tld is dealt with differently then name.sld.tld. Don't know what they smoke, but when they embraced DNS with the beginnings of AD, we all hoped it could only get better than before (NetBIOS naming and WINS). But all sorts of quirks remain. BTW, DNS and "a domain environment" are two completely orthogonal things. IP networks (including LANs) of some size used DNS long before MS finally based their second generation domain concept (AD) on top of its naming hierarchy entirely. As soon as networks grow beyond SOHO size, naming usually turns into a mess and DNS is absolutely necessary to keep it consistent.
But back to your problem: What baffles me is the repeating theme here ain't only the DA claiming it couldn't connect to the MA (runing on dpcell3), it's that IPC Invalid Hostname or IP Address that it presents as the actual reason for the problem to connect. And that would mean the issue is in fact ultimately in the resolving of dpcell3 to a proper address. But ping and telnet 5555 working with that same name would exclude this explanation.
This somehow calls for some strace(8) examination of what really happens, I think, ideally accompanied by sniffing the conversations with tcpdump(8). There's some dead rat here in name resolution, and it needs to be found and disposed of. Have you checked all the usual suspects, like /etc/resolv.conf, /etc/host.conf, /etc/nsswitch.conf, /etc/gai.onf (and IPv6 interference in general)? Is mDNS/ZeroConf/avahi part of the picture? It somehow looks like the issue is client-->server, but not the other way around (as you could import the client when connecting to it from the server).
BTW, if you ask yourself of what FQDN to use in order to test this, I have a backup DMZ that simply uses the TLD backup (so with your hostnames, they would turn into dpcell3.backup and centos-02.backup). That's working flawlessly so far with a lot of different Linux (including one CentOS 4, mind you) and Windows versions, some of them using DNS (the zone is on a Linux running BIND) and some of them using hosts entries. The problem is probably that you cannot move your CM to another name (even when only changing its FQDN) now, as that is burned deeply into the IDB. But maybe I'm wrong here.
04-18-2014 05:19 PM
FIXED!!!!!!!!!!!!!!! :)) :)) :))
Thanks to your suggestion of using strace, I studied the vomited log file that omnicc yielded, and I realized that the name resolution problem it was not against the cell manager... but in the centos itself! The centos couldn't ping to itself!
So I simply added in /etc/hosts an entry for the centos itself... and voilá!
Many many thanks for your help! I'm very happy!
i hope this will help others too.