the centreon 18 is not working with remote polller and remote servers. why? - opennms

I have been trying to install distributed monitoring environment on my network for very long time using Centreon but whenever I install the remote poller or remote server, either it can't even show there or nothing happen. If someone had tried this, please let me know the step-by-step process.
Note: I had try every single document from he centreon but it's not working for me.

1 Network flows opening
From: Poller To: NTP server Protocol: NTP Port: UDP 123 Application: Synchronization of the system clock
From: Poller To: DNS server Protocol: DNS Port: UDP 53 Application: Domain name resolution
From: Poller To: SMTP server Protocol: SMTP Port: TCP 25 Application: Notification via email
From: Poller To: Repository Protocol: HTTP (FTP) Port: TCP 80 (FTP 20,21) Application: Repository for system and application packages
From: Central server To: Poller Protocol: SSH Port: TCP 22 Application: Export of Centreon configuration
2 Poller setup
Use the ISO Linux based on CentOS distribution or RPM packages available for CentOS distribution.
Online documentation on poller installation: https://documentation.centreon.com/docs/centreon/en/19.04/installation/from_iso.html
3 Exchanging SSH keys
The communication between the central server and a poller server is done via SSH. You must exchange the SSH keys between the two servers.
If you don’t have any private SSH keys on the central server for the centreon user:
# su - centreon
$ ssh-keygen -t rsa
Copy this key to the new server:
# su - centreon
$ ssh-copy-id -i .ssh/id_rsa.pub centreon#IP_POLLER
The password of the centreon user is centreon. It can be easily changed using the passwd command.
4 Configure the poller in Centreon web interface
Go to the Configuration > Pollers menu and click on Add server with the wizard to configure a new poller.
Select Add a Centreon Poller and click on Next. Type in the name, the IP address of the poller and IP address of the Central Server.
Then click on Apply to register this new poller in Centreon.
It takes a few seconds for the wizard to configure your new poller in the system.
5 Monitor your host from this new poller
In the Configuration > Host page, you now have this poller entry in the Monitored from list field. Select it for each host.
According to the kind of monitoring protocol you are using for each dedicated host, don't forget to open/configure the network flow between the poller and the host (ICMP, SNMP, HTTP, ..)

Related

DBVisualizer Hive SSH Tunnel Ignoring Server Information

I'm attempting to setup a connection to our Hadoop cluster via DBVisualizer.
In order to connect I need to SSH into a server on the domain and then I need to run the command to a remote server (I've not ssh'd onto the Hadoop cluster directly)
I have (figuratively)
Database Server: abcd.efg
Database Port: 12345
Database: Hello
configured for the Database section
SSH Host: hijk.efg
SSH Port: 678
When I attempt a connection, it returns
Could not open client transport with JDBC Uri:
jdbc:hive2://127.0.0.1:-----
Where 127.0.0.1 and ----- appear to be the defaults instead of what I entered.
Any idea how I get the SSH tunnel to use the server configuration I specify?
The SSH Tunnel is set up locally on the client, so connecting to the port on localhost tunnels you to the SSH Host/Port, which then sets up a connection to the database server/port you have specified. This page may help:
http://confluence.dbvis.com/display/UG100/Using+an+SSH+Tunnel
Best Regards,
Hans

How to properly configure a FTPconnection with Windows Azure Server.?

I'm new to Windows Azure Server configurations, and I'm trying to configure the FTP Connection. But when I access the Server with FileZilla it doesn't work. What am I doing wrong here?
I'm using IIS with FTP Server Roles installed.
Following is the error log from FileZilla
Status: Resolving address of AZR-SRV-map01.cloudapp.net
Status: Connecting to 52.187.64.207:990...
Status: Connection established, initializing TLS...
Status: Verifying certificate...
Status: TLS connection established, waiting for welcome message...
Status: Logged in
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is current directory.
Command: TYPE I
Response: 200 Type set to I.
Command: PASV
Response: 227 Entering Passive Mode (52,187,64,207,195,237).
Command: LIST
Response: 150 Opening BINARY mode data connection.
Error: Connection timed out after 20 seconds of inactivity
Error: Failed to retrieve directory listing
Status: Disconnected from server
I also tried the following steps in configuring the FTP Connection...
Here the endpoints have being configured from the Azure Portal.
This is how I published the FTP Site
Configured the FTP Firewall Support with the Azure Server Public IP
And enabled the firewall outbound and inbound rules..
After completing all the steps, I restarted the Microsoft FTP Service, but the problem still exists.
For now, we can't configure a active mode FTP on Azure VM. we should configure data channel port range in FTP Firewall Support, FTP work in passive mode. For example, we can use 10000-10010 ports as the data channel port range. Also, we should add ports to VM's endpoints and add then to VM's firewall inbound rules.
By the way, although the windows firewall seems to allow all traffic that’s required, we also need to enable stateful FTP filtering on the firewall:
netsh advfirewall set global StatefulFtp enable
Then restart the FTP windows service and we should be up and running:
net stop ftpsvc
net start ftpsvc
Here a case similar as you, please refer to it.

Can't connect to MongoDB instance running on remote azure windows machine

I'm having trouble connecting to a mongo instance running on a windows azure vm running Windows Server 2012 R2. I've verified the following things
The network security group has rule allowing port 27017 inbound (* -> 27017)
The VM has TCP port 27017 inbound open on all profiles (currently, my firewall is completely disabled)
Mongo is running as a windows service. I've verified it is up and running. I was able to connect, insert, and find records in the shell on the remote vm that's running Mongo
When I run netstat -a, I can see 0.0.0.0:27017 with the status "LISTENING"
If I try to ping the VM, it times out (I believe this is expected)
Port 22 is open in the firewall and in the network security group rules
I am not running any 3rd party anti-virus software on my local machine
I tried restarting the VM both from the OS and from azure portal
I tried removing the rules from network security group and readding them
I've tried connection via SSH in bash on my local machine running windows 10 using the most basic command mongo <ip-address>. It times out with the message ssh: connect to host x.x.x.x port 22: Resource temporarily unavailable
I've tried connection via Putty/SSH. Same result
I've tried connection via MongoDB Compass which gives a similar error Could not connect to MongoDB on the provided host and port
any ideas?
Here's the config I'm using
systemLog:
logAppend: true
verbosity: 0
traceAllExceptions: true
path: c:\MongoLogs\mongolog.log
destination: file
net:
port: 27017
bindIp: [127.0.0.1, <external-ip>]
http:
enabled: true
JSONPEnabled: false
RESTInterfaceEnabled: true
storage:
dbPath: c:\MongoData\
As it turns out, the VM had multiple network security group profiles attached to it. When I click "Effective security rules" it showed a second tab that had another profile that appears to have been inherited from the subnet -- sufficed to say, it did not have the permissions that are needed. By opening the correct ports on that profile as well, connections we then going through just fine. We're gonna clean that up, but in short, there was a conflict of permissions.

How to open incoming port 50070 in firewall (google compute engine)

I have my Single node Hadoop installed on Google Compute Engine instance and i want to open port 50070 on that machine to access the hadoop dashboard. i configured in the firewall rule as tcp:50070 in compute engine networks. but still i am unable to access my port outside the network (ie . via internet). I tried nmap for the public ip of my GCE instance and i got a result which has only ssh port got opened all other ports are filtered .
Note: i am using debian 7.5 image
Make sure your daemon is listening on port 50070. If you have more than one networks in you project make sure the port is opened on the right network. You can run the following commands to check the information about your instance and network.
lsof -i
gcutil --project= getinstance
gcutil --project= listnetworks
gcutil --project= listfirewalls
gcutil --project= getfirewall
Check if IP/Port is allowed in iptables or not.
iptables -L
would show you all the records.
To allow port in iptables you can do the following:
sudo iptables -A INPUT -p tcp -m tcp --dport 50070 -j ACCEPT
sudo iptables-save -c
Short answer
In addition to configure the firewall rule at GCE web console make sure that your server is listening at 0.0.0.0 instead of 127.0.0.1
Long answer
In the context of servers, 0.0.0.0 means all IPv4 addresses on the local machine. If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs - Source
In contrast 127.0.0.1 is the IP address used to stablish a connection to the same machine used by the user this address is usually referred as the localhost.
It's often used when you want a network-capable application to only serve clients on the same host. A process that is listening on 127.0.0.1 for connections will only receive local connections on that socket. - Source
Hence, if you try to stablish a connection to your server from internet and your server is listening at 127.0.0.1 at your GCE machine, then, from the server point of view a request has never been received and as a consequence Goocle Cloud Firewall will refuse the connection because there is no server listening at the opened port (in your case 50070).
I hope this answer helps to solve your problem. Best regards.

How to configure direct http access to EC2 instance?

This is a very basic Amazon EC2 question, but I'm stumped so here goes.
I want to launch an Amazon EC2 instance and allow access to HTTP on ports 80 and 8888
from anywhere. So far I can't even allow the instance to connect to on those ports using
its own IP address (but it will connect to localhost).
I configured the "default" security group for HTTP using the standard HTTP option on the management console (and also SSH).
I launched my instance in the default security group.
I connected to the instance on SSH port 22 twice and in one window launch an HTTP server
on port 80. In the other window I verify that I can connect to HTTP using the "localhost".
However when I try to access HTTP from the instance (or anywhere else) using either the public DNS or the Private IP address I het "connection refused".
What am I doing wrong, please?
Below is a console fragment showing the wget that succeeds and the two that fail run from the instance itself.
--2012-03-07 15:43:31-- http://localhost/
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: /__whiff_directory_listing__ [following]
--2012-03-07 15:43:31-- http://localhost/__whiff_directory_listing__
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: “__whiff_directory_listing__”
[ <=>
] 7,512 --.-K/s in 0.03s
2012-03-07 15:43:31 (263 KB/s) - “__whiff_directory_listing__” saved [7512]
[ec2-user#ip-10-195-205-30 tmp]$ wget http://ec2-50-17-2-174.compute-1.amazonaws.com/
--2012-03-07 15:44:17-- http://ec2-50-17-2-174.compute-1.amazonaws.com/
Resolving ec2-50-17-2-174.compute-1.amazonaws.com... 10.195.205.30
Connecting to ec2-50-17-2-174.compute-1.amazonaws.com|10.195.205.30|:80... failed:
Connection refused.
[ec2-user#ip-10-195-205-30 tmp]$ wget http://10.195.205.30/
--2012-03-07 15:46:08-- http://10.195.205.30/
Connecting to 10.195.205.30:80... failed: Connection refused.
[ec2-user#ip-10-195-205-30 tmp]$
The standard tcp sockets interface requires that you bind to a particular IP address when you send or listen. There are a couple of somewhat special addresses: localhost (which you're probably familiar with) which is 127.0.0.1. There's also a special address, 0.0.0.0 or INADDR_ANY (internet protocol, special shorthand for ANY ADDRESS). It's a way to listen on ANY or more commonly, ALL addresses on the host. This is a way to tell the kernel/stack that you're not interested in a particular IP address.
So, when you're setting up a server that listens to "localhost" you're telling the service that you want to use the special reserved address that can only be reached by users of this host, and while it exists on every host, making a connection to localhost will only ever reach the host you're making the request from.
When you want a service to be reachable everywhere (on a local host, on all interfaces, etc.) you can specify 0.0.0.0.
(0) It's silly but the first thing you need to do is to make sure that your web server is running.
(1) You need to edit your Security Group to let incoming HTTP packets access your website. If your website is listening on port 80, you need to edit the Security Group to open access to port 80 as mentioned above. If your website is listening on some other port, then you need to edit the Security Group to access that other port.
(2) If you are running a Linux instance, the iptables firewall may be running by default. You can check that this firewall is active by running
sudo service iptables status
on the command line. If you get output, then the iptables firewall is running. If you get a message "Firewall not running", that's pretty self-explanatory. In general, the iptables firewall is running by default.
You have two options: knock out the firewall or edit the firewall's configuration to let HTTP traffic through. I opted to knock out the firewall as the simpler option (for me).
sudo service iptables stop
There is no real security risk in shutting down iptables because iptables, if active, merely duplicates the functionality of Amazon's firewall, which is using the Security Group to generate its configuration file. We are assuming here that Amazon AWS doesn't misconfigure its firewalls - a very safe assumption.
(3) Now, you can access the URL from your browser.
(4) The Microsoft Windows Servers also run their personal firewalls by default and you'll need to fix the Windows Server's personal firewall, too.
Correction: by AWS default, AWS does not fire up server firewalls such iptables (Centos) or UAF (Ubuntu) when you are ordering the creation of new EC2 instances - That's why EC2 instances that are in the same VPC can ssh into each other and you can "see" the web server that you fired up from another EC2 instance in the same VPC.
Just make sure that your RESTful API is listening on all interfaces i.e. 0.0.0.0:portID
As you are getting connection refused (packets are being rejected) I bet it is iptables causing the problem. Try to run
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -p tcp --dport 8888 -j ACCEPT
and test the connection.
You will also need to add those rules permanently which you can do by adding the above lines into ie. /etc/sysconfig/iptables if you are running Red Hat.
Apparently I was "binding to localhost" whereas I needed to bind to 0.0.0.0 to respond to port 80 for the all incoming TCP interfaces (?). This is a subtlety of TCP/IP that I don't fully understand yet, but it fixed the problem.
Had to do the following:
1) Enable HTTP access on the instance config, it wasn't on by default only SSH
2) Tried to do nodejs server, so port was bound to 80 -> 3000 did the following commands to fix that
iptables -F
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
sudo service iptables-persistent flush
Amazon support answered it and it worked instantly:
I replicated the issue on my end on a test Ubuntu instance and was able to solve it. The issue was that in order to run Tomcat on a port below 1024 in Ubuntu/Unix, the service needs root privileges which is generally not recommended as running a process on port 80 with root privileges is an unnecessary security risk.
What we recommend is to use a port redirection via iptables :-
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
I hope the above information helps.

Resources