Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

cloudera manager 7180 firewall issues

avatar
Contributor

Hi,

 

I'm having some issues with connecting to the CM admin page in addition to other daemon web UI's. Originally I had requested firewall changes to allow the ports for each of the daemons and CM admin page, this worked but does not work as a valid solution for dynamic IPs. Other computers are unable to access the CM admin page from different IPs. This also means that the current computer I am accessing the CM admin page from will require the port to be allowed for each dynamic IP that I am assigned.

 

I'm curious if there is a work around for this that does not involve shutting down a network firewall. Other clusters that are setup in my environment do not have these firewall issues. I confirmed that SElinux was disabled and the iptables match the settings in the other clusters (those that are not having firewall issues). I added all the ips/domain names to the /etc/hosts on all nodes.

 

The cluster that is having the firewall issues are all physical machines and not VMs, I'm not sure if this makes any difference in how the dns is resolved.

 

Thanks

 

CM 5.2

1 ACCEPTED SOLUTION

avatar
Master Collaborator

What part of the environment is using DHCP?  The desktops that are attempting to access the cluster?  The firewall rules need to allow the target subnets the users will be connecting from... if source rules are in place for the firewall.  Auditing / comparing the firewall rules from a working cluster and this cluster would be a good idea.

 

For CM and cluster services, we reccomend static IP's for all cluster nodes. Forward and reverse lookup is critical as well.


What is happening when you attempt to access things, is the page never connecting or not completing, what happens when you telnet from your desktop to the port 7180 for the HTTP process?

View solution in original post

3 REPLIES 3

avatar
Master Collaborator

What part of the environment is using DHCP?  The desktops that are attempting to access the cluster?  The firewall rules need to allow the target subnets the users will be connecting from... if source rules are in place for the firewall.  Auditing / comparing the firewall rules from a working cluster and this cluster would be a good idea.

 

For CM and cluster services, we reccomend static IP's for all cluster nodes. Forward and reverse lookup is critical as well.


What is happening when you attempt to access things, is the page never connecting or not completing, what happens when you telnet from your desktop to the port 7180 for the HTTP process?

avatar
Contributor

Thanks for the quick response Tgrayson.

 

For the firewall rule, the source subnets would be for example 192.168.x.x (IP of client machine connecting). As for when I try to connect I recieve a "connection failed" with telnet (client to cluster). With a web browser I receive a "connection refused" in google chrome. Currently, I have resolved the issue temporarly with a firewall rule to accept my full IP but from the sounds of it I need the subnet of the user clients who would be accessing.

 

What is happening when you attempt to access things, is the page never connecting or not completing, what happens when you telnet from your desktop to the port 7180 for the HTTP process? I receive a "connect failed" on port 23. However, I receive the same message when I enter in the full IP with port previously before the firewall rule had been created.

 

Will try out your suggestion and post back.

avatar
Master Collaborator

The telnet context is to tell telnet (or nc, which is more common "yum install nc") to connect to the actual port you are attmpeting to access to verify TCP connectivity (telnet host.fqdn.name port)

 

As telnet has lost favor and is no longer installed by default, netcat (nc) might be the better tool to use to verify port connectivity in the future.


The telnet to its default port (23) would be expected to fail.


Todd