I have a problem about Nifi Web UI. When I set nifi.web.http.host=luan-ht01, I could not access Nifi Web UI on browsers by public IP, example: http://localhost:8080/nifi/, http://107.113.193.160:8080/nifi. I only could access Nifi Web by host name.
Do you have any solutions?
Thank you very much.
Your experience is the expected behavior -- when you set the hostname explicitly, that is the address on which NiFi will respond. You can leave that property value blank to have NiFi respond on all available hosts, (i.e. localhost, 127.0.0.1, etc.). During startup, the $NIFI_HOME/logs/nifi-app.log file will show a listing like below, enumerating all listening hosts.
2378 │ 2019-06-18 14:25:20,738 INFO [main] org.apache.nifi.web.server.JettyServer NiFi has started. The UI is available at the following URLs:
2379 │ 2019-06-18 14:25:20,738 INFO [main] org.apache.nifi.web.server.JettyServer https://node1.nifi:9441/nifi
2381 │ 2019-06-18 14:25:20,740 INFO [main] org.apache.nifi.BootstrapListener Successfully initiated communication with Bootstrap
2382 │ 2019-06-18 14:25:20,740 INFO [main] org.apache.nifi.NiFi Controller initialization took 93674324706 nanoseconds (93 seconds).
One quick work-around for you could be to create an "alias" for your localhost IP address to be named as your domain (just for testing purposes on your local environment, of course):
On GNU/Linux based systems, just edit (with sudo privileges) your /etc/hosts file, and add another line like that one for localhost:
/etc/hosts
127.0.0.1 localhost
127.0.0.1 luan-ht01
In Windows systems, the hosts file would (usually) be found at:
c:\Windows\System32\Drivers\etc\hosts
By doing so, you'll now be able to direct your browser to http://luan-ht01:8080/nifi and hopefully will be getting your web UI back.
Enjoy ;)
Related
I'am trying to use Hue as a file browser for HDFS. So for that I have clone the hue repository and build the app with the following commands given in README.md of the hue repository.
git clone https://github.com/cloudera/hue.git
cd hue
make apps
build/env/bin/hue runserver
Hue UI is accessible in local machine using default port using the url http://localhost:8000 and everything works fine. But when I use my machine ip address http://x.x.x.x:8000 and try to access the Hue UI it keeps on processing and waiting.
Other observations -:
I can ping from remote machine to the host machine.
There is no firewall blocking the ports. (checked with nmap port scanner)
Machines are in same network.
I can access other ports for Hadoop NameNodes UI and DataNodes.
Changing the http_host in hue.ini doesn't affect the result
The ideal setup for Hue is configuring a reverse proxy (Nginx or Apache HTTP, for example)
However, you should refer to the Configuration documentation to externally run the server outside of 127.0.0.1
[desktop]
# Webserver listens on this address and port
http_host=0.0.0.0
http_port=8888
I was able to find a solution to the issue.. First hue run on a CherryPy web server so starting server by command build/env/bin/hue runserver will start the development server where hue.ini configuration is neglected.
So the correct command to start the production server after setting up correct configuration in hue.ini file is build/env/bin/hue runcpserver. Then I was able to access it using remote host without any problem. You also can use supervisor to start the production server. More information about that can be found here
To remove a node from 2 node cluster in AWS I ran
nodetool removenode <Host ID>
After this I was supposed to get my cluster back if I put all the cassandra.yaml and cassandra-rackdc.properties correctly.
I did it but still, I am not able to get back my cluster.
nodetool status is displaying only one node.
significant system.log on cassandra is :
INFO [main] 2017-08-14 13:03:46,409 StorageService.java:553 - Cassandra version: 3.9
INFO [main] 2017-08-14 13:03:46,409 StorageService.java:554 - Thrift API version: 20.1.0
INFO [main] 2017-08-14 13:03:46,409 StorageService.java:555 - CQL supported versions: 3.4.2 (default: 3.4.2)
INFO [main] 2017-08-14 13:03:46,445 IndexSummaryManager.java:85 - Initializing index summary manager with a memory pool size of 198 MB and a resize interval of 60 minutes
INFO [main] 2017-08-14 13:03:46,459 MessagingService.java:570 - Starting Messaging Service on /172.15.81.249:7000 (eth0)
INFO [ScheduledTasks:1] 2017-08-14 13:03:48,424 TokenMetadata.java:448 - Updating topology for all endpoints that have changed
WARN [main] 2017-08-14 13:04:17,497 Gossiper.java:1388 - Unable to gossip with any seeds but continuing since node is in its own seed list
INFO [main] 2017-08-14 13:04:17,499 StorageService.java:687 - Loading persisted ring state
INFO [main] 2017-08-14 13:04:17,500 StorageService.java:796 - Starting up server gossip
Content of files:
cassandra.yaml : https://pastebin.com/A3BVUUUr
cassandra-rackdc.properties: https://pastebin.com/xmmvwksZ
system.log : https://pastebin.com/2KA60Sve
netstat -atun https://pastebin.com/Dsd17i0G
Both the nodes have same error log.
All required ports are open.
Any suggestion ?
It's usually a best practice to have one seed node per DC if you have just two nodes available in your datacenter. You shouldn't make every node a seed node in this case.
I noticed that node1 has - seeds: "node1,node2" and node2 has - seeds: "node2,node1" in your configuration. A node will start by default without contacting any other seeds if it can find it's IP address as first element in - seeds: ... section in the cassandra.yml configuration file. That's what you can also find in your logs:
... Unable to gossip with any seeds but continuing since node is in its own seed list ...
I suspect, that in your case node1 and node2 are starting without contacting each other, since they identify themselves as seed nodes.
Try to use just node1 for seed node in both instance's configuration and reboot your cluster.
In case of node1 being down and node2 is up, you have to change - seeds: ... section in node1 configuration to point just to node2's IP address and just boot node1.
If your nodes can't find each other because of firewall misconfiguration, it's usually a good approach to verify if a specific port is accessible from another location. E.g. you can use nc for checking if a certain port is open:
nc -vz node1 7000
References and Links
See the list of ports Cassandra is using under the following link
http://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureFireWall.html
See also a detailed documentation on running multiple nodes with plenty of sample commands:
http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html
This is for future reference. My problem has been solved just by opening 7000 port for same security group in AWS. Although it was open but security group was something different.
When I ran:
ec2-user#ip-Node1 ~]$ telnet Node2 7000
Trying Node2...
telnet: connect to address Node2: Connection timed out
I came to know the problem could be of the security group.
And that is how it has been solved.
About seeds I am using IP of both the nodes, like this:
-seeds: "node1,node2"
It is same on both the nodes.
I'm using a yo generator (generator-moda), running on an ec2 instance, and want to navigate from my browser to the external url provided but my browser just hangs on connecting...
Are there special config adjustments that need to be done in ec2 security groups or otherwise allow the ip or host below?
[BS] Access URLs:
-------------------------------------
Local: http://localhost:3000
External: http://172.31.60.85:3000
-------------------------------------
UI: http://localhost:3001
UI External: http://172.31.60.85:3001
-------------------------------------
[BS] Serving files from: ./app
[17:52:19] gulp-inject 12 files into main.scss.
[17:52:19] gulp-inject 12 files into main.scss.
[17:52:19] Starting 'html'...
[17:52:19] Finished 'html' after 3.89 ms
[BS] 1 file changed (index.html)
INFO [karma]: Karma v0.12.31 server started at http://localhost:9876/
INFO [launcher]: Starting browser PhantomJS
WARN [watcher]: Pattern "/home/ubuntu/dev/clients/alugha/main/app/scripts/**/*.html" does not match any file.
INFO [PhantomJS 1.9.8 (Linux)]: Connected on socket f08K4dCRmBorILmZgofR with id 91726259
The problem is that 172.31.0.0/16 is an Amazon's private range of IPs, so you cannot access to them outside the VPC (Amazon Virtual Private Cloud) source.
If you want to connect to your EC2 instance where your code is running you need to do two things:
Connect to the public DNS hostname / IP that you can get from your EC2 console. You have the instructions here: Determining Your Public, Private, and Elastic IP Addresses - AWS docs
Open the port in the security group to allow you to connect to your instance. In this answer is explained how to open a port for your security group, but instead of port 80, open 3000 and 3001.
Then in your browser copy the public DNS hostname you got on the first step with the correct port and you should be able to load your page.
I am trying to get openNMS (v1.12) to fetch the list of nodes from DNS server.
First, I tried to add requisition-def in my provisiond-configuration.xml with dns://mydnsServerIP/myZone and following, I executed:
/opt/opennms/bin/send-event.pl uei.opennms.org/internal/reloadDaemonConfig --parm 'daemonName Provisiond'
to avoid restarting. Nothing happened.
Following, I tried to add the dns URL in configure discovery URL in the admin page. After saving, discovery.log started having entries like this:
2014-02-24 20:54:53,919 WARN [OpenNMS.Discovery-Thread] DiscoveryConfigFactory:
Unknown host '<node building="MYZONE_HERE" foreign-id="520105224"
node-label="CORRECTNODELABEL_HERE">' inside discovery include file:
address ignored
2014-02-24 20:54:53,920 WARN [OpenNMS.Discovery-Thread] DiscoveryConfigFactory:
Unknown host '<interface descr="DNS-AAAA" ip-addr="IPV6_HERE" managed="true" status="1"
snmp-primary="P">' inside discovery include file: address ignored
2014-02-24 20:54:53,922 WARN [OpenNMS.Discovery-Thread] DiscoveryConfigFactory:
Unknown host '<monitored-service service-name="SNMP"/>' inside discovery include
file: address ignored
2014-02-24 20:54:53,925 WARN [OpenNMS.Discovery-Thread] DiscoveryConfigFactory:
Unknown host '<monitored-service service-name="ICMP"/>' inside discovery include
file: address ignored
2014-02-24 20:54:53,927 WARN [OpenNMS.Discovery-Thread] DiscoveryConfigFactory:
Unknown host '</interface>' inside discovery include file: address ignored
2014-02-24 20:54:53,929 WARN [OpenNMS.Discovery-Thread] DiscoveryConfigFactory:
Unknown host '</node>' inside discovery include file: address ignored
It there anything else I have to do to get it to auto discover nodes from DNS server?
Thanks in advance!
Your OpenNMS server that is initiating the provisioning via a DNS import must be allowed to perform a zone transfer. You can test it with the following from your OpenNMS server console.
dig -t AXFR #<dnsServer> <zone>
If that fails the provisioning will fail.
Also you need to create a provisioning group first.
See more here: http://www.opennms.org/wiki/DNS_Importing
I'm getting this when starting up a TeamCity agent. To expose TC Server on EC2 I'm using Application request routing, Created a Server Farm and route 80 to 8080 internally. I can see mention of Port 9090 in below logs - I'm wondering if I would need to create a second application request route for 9090 - I haven't seen mention of this in any docs - anyone have XP with this?
[2014-02-09 07:31:35,994] INFO - buildServer.AGENT.registration - Registering on
server http://team.xxxx.com.au, AgentDetails{Name='WIN-IXXX',
AgentId=null, BuildId=null, AgentOwnAddress='null', AlternativeAddresses=
[10.xxx.xxx.xxx, 54.xxx.xxx.xxx], Port=9090, Version='27767', PluginsVersion='NA',
AvailableRunners=[], AvailableVcs=[], AuthorizationToken=''}
[2014-02-09 07:32:08,567] WARN - buildServer.AGENT.registration - Call
http://team.xxxx.com.au/RPC2 buildServer.registerAgent3:
org.apache.xmlrpc.XmlRpcClientException: Server returned incorrect status code: 502 Bad
Gateway
The TeamCity server needs to be able to open HTTP connections to the agent via the ownPort property of the buildAgent.properties file. That port is, by default, 9090.
You can read more here:
TeamCity - Setting Up Additional Build Agents