I should have suspected trouble was brewing when I realized how proud I was of my own cleverness: Set up a Unix IS for a customer using a Linux VM. That would eliminate the need to use one of their three HP-UX clients as an IS. The one we had anticipated using turned out to be back at 11i v1 (11.11), so it was not a viable IS platform. The remaining two 11i v3 (11.31) clients were production cluster nodes, and the powers-that-be were not receptive to the idea of tinkering with either one regardless of how benign the DP IS function might be.
No problem. One Linux VM later, we had an IS installed and patched. Now it was time to import it into the cell.
[root@neelix ~]# omnicc -import_is neelix.localdomain [12:1660] Import Installation Server failed.
When the Installation Server (IS) import failed, I said, "Aha! I know what it is. Most of the time, failed client imports are the product of inconsistent name resolution." So I quickly set about verifying that the Cell Manager (CM) could resolve the new IS by FQDN and IP address. Okay, that looks good. The problem must be with the new IS. I pop over there and verified that the new IS could resolve the CM both forwards and backwards. Well well well, now what?
Time to drop back to some basic DP troubleshooting. From the CM, can I telnet to port 5555 on the new IS? Survey says . . . . . . . . . . no, I cannot. Good. No, really -- good. This means we have something concrete to track down. Why am I unable to telnet to port 5555 on the new IS? There are no hardware firewalls in the network path between CM and IS. BUT, my default install of Linux may have included iptables. Did it? Was the service running?
[root@neelix ~]# service iptables status Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 5 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) num target prot opt source destination 1 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) num target prot opt source destination
Well, there's our problem! I stopped iptables momentarily and repeated my my telnet test. Now it works. So I tried my IS import again.
[root@neelix ~]# omnicc -import_is neelix.localdomain Import host successful.
There we go! I restarted the iptables service while I mulled over my options.
Does my IS really need firewall protection? Should I go to the trouble to port-limit DP and create firewall rules for the IS? In a word: NO. I'm not hosting nuclear launch codes on the IS -- it's just an install depot for Unix-flavored DP components.
The steps required to save the current iptables config, stop the service, and disable it from starting at system boot are fairly straightforward.
[root@neelix ~]# service iptables save iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ] [root@neelix ~]# service iptables stop iptables: Flushing firewall rules: [ OK ] iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Unloading modules: [ OK ] [root@neelix ~]# chkconfig iptables off [root@neelix ~]# chkconfig --list iptables iptables 0: off 1: off 2: off 3: off 4: off 5: off 6: off
That last command simple allowed me to verify that iptables was not set to start automatically at any runlevel.
So there you have it. Your list of likely culprits for jamming a good client import should include both faulty name resolution and firewalls. Have you overcome other roadblocks that prevented a successful client import? If so, please share your experience in the comments below!