I am using confd version 6.3. I'm trying to set it up to be able to ssh with netconf over ipv4 and ipv6. My related configuration looks as follows:
<netconf>
<enabled>true</enabled>
<transport>
<ssh>
<enabled>true</enabled>
<ip>::</ip>
<port>2022</port>
</ssh>
<!-- NETCONF over TCP is not standardized, but it can be useful
during development in order to use e.g. netcat for scripting.
-->
<tcp>
<enabled>true</enabled>
<ip>127.0.0.1</ip>
<port>2023</port>
</tcp>
</transport>
....
</netconf>
Which result in
root#0eeefd5ae80c:/shared# netstat -ln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
...
tcp6 0 0 :::2022 :::* LISTEN
When I change ip to 0.0.0.0 then it listens over ipv4. But I am not able to set both ipv4 and ipv6. Is it even possible>
It turned out that it is possible to use a parameter that is not described in manifest. So in order to do that can be used:
...
<netconf>
<enabled>true</enabled>
<transport>
<ssh>
<enabled>true</enabled>
<ip>0.0.0.0</ip>
<port>2022</port>
<extraIpPorts>:::830</extraIpPorts>
</ssh>
</netconf>
...
Related
After following the installation instructions referenced at https://superset.apache.org/docs/installation/installing-superset-from-scratch, I'm not able to see the app at the ip number/server port in my win 10 web browser. How do I make it work at the right ip address?
I've installed it under venv running on a CentOS 8 VM on my win 10 laptop. I'm using the NAT network adapter and I can can use putty and the CentOS 8 cockpit app is available on port 9090.
Currently it says it's running at 127.0.0.1:8089:
(venv) /root>superset run -p 8089 --with-threads --reload --debugger
logging was configured successfully
2021-08-04 15:35:48,492:INFO:superset.utils.logging_configurator:logging was configured successfully
2021-08-04 15:35:48,505:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
/root/venv/lib64/python3.8/site-packages/flask_caching/__init__.py:201: UserWarning: Flask-Caching: CACHE_TYPE is set to null, caching is effectively disabled.
warnings.warn(
No PIL installation found
2021-08-04 15:35:48,722:INFO:superset.utils.screenshots:No PIL installation found
* Serving Flask app "superset" (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: off
2021-08-04 15:35:50,007:INFO:werkzeug: * Running on http://127.0.0.1:8089/ (Press CTRL+C to quit)
netstat shows port 8089 open for 127.0.0.1, but not the VM's ip number. nmap shows the port closed.
/root>netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 944/sshd
tcp 0 0 127.0.0.1:8089 0.0.0.0:* LISTEN 4247/python3
tcp6 0 0 :::9090 :::* LISTEN 1/systemd
tcp6 0 0 :::22 :::* LISTEN 944/sshd
/root>nmap 192.168.42.130
Starting Nmap 7.70 ( https://nmap.org ) at 2021-08-04 15:45 PDT
Nmap scan report for kevinsAppServer (192.168.42.130)
Host is up (0.000015s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
9090/tcp open zeus-admin
Nmap done: 1 IP address (1 host up) scanned in 1.73 seconds
/root>nmap -p 8089 192.168.42.130
Starting Nmap 7.70 ( https://nmap.org ) at 2021-08-04 15:45 PDT
Nmap scan report for kevinsAppServer (192.168.42.130)
Host is up (0.000067s latency).
PORT STATE SERVICE
8089/tcp closed unknown
I think it should work if i can get the port opened on my server's IP number, unless there's something I did wrong..
I got it to work by adding the -h option for the superset run command, which I found when running the superset run --help at the server command line. So now this command works:
superset run -h my.i.p.adddress -p 8089 --with-threads --reload --debugger
In my case I also had to open port 8089 on the CentOS firewall.
I am trying to create a SSH tunnel between a database running server port and another server as the following.
MySQL:3306 <=====> Server-A:3306
And I want to use the Server-A:3306 as the database URI to connect to the database.
I am running the following on ServerA
ssh -f -N -i ~/keys/test.pem foo#foo.storesandbox.com -L5001:127.0.0.1:2001
I can see that the tunnel is up and running. But when I use the public IP of Server-A and try to connect to the database, It does not work.
If I create another tunnel between between Server-A and where I run the MySQL client. then it works. But I don't want to do that.
What can be the reason for this issue. I am fairly new to scripting
by default local side (ssh client) creates listening port at loopback interface with address 127.0.0.1 when you use command like this
ssh me#server -L3306:localhost:3306
if you check netstat on your host you will see something like this
sudo netstat -ntlp | grep 3306
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 12354/ssh
So applications at your local node can connect to such mapped service because loopback interface is visible to host itself but external nodes have no access to this virtual interface so can't make any connections to any service(port) which is listening on this single interface.
To instruct local ssh client to share such mapped port to the world you need to instruct it to bind to either all interfaces (including loopback) or to specific interface only
# here you explicitly tell ssh client to accept connection to your tunnel
# from any client(i.e. bind listenning port to all interfaces)
ssh me#server -L0.0.0.0:3306:localhost:3306
sudo netstat -ntlp | grep 3306
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 12354/ssh
#here you do the same thing by using -g option
ssh me#server -g -L3306:localhost:3306
sudo netstat -ntlp | grep 3306
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 12354/ssh
#and here is an example of how to bind to specific interfaces only
# 10.0.0.12 is an IP of one of interfaces on your node
# 10.1.0.156 is also IP address of one interfaces of your node
ssh me#server -L10.0.0.12:3306:localhost:3306 -L10.1.0.156:3306:localhost:3306
sudo netstat -ntlp | grep 3306
tcp 0 0 10.0.0.12:3306 0.0.0.0:* LISTEN 12354/ssh
tcp 0 0 10.1.0.156:3306 0.0.0.0:* LISTEN 12354/ssh
I have a running apache webserver in centos docker container which is hosted by AWS redhat instance.
I am able to curl my container webserver in AWS instance local host but unable to access publicly in my laptop web browser.
details of the Webserver:
docker run -d --name httpd -p 8080:8080 -v /home/ec2-user/apache/web1/www:/var/www:Z docker.io/centos/httpd-24-centos7
The output of docker ps:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
abd790b28b51 docker.io/centos/httpd-24-centos7 "container-entrypo..." 2 hours ago Up 20 minutes 0.0.0.0:8080->8080/tcp, 8443/tcp httpd
In AWS instance :
curl http://localhost:8080
Hello World!!!
But unable to get this in public internet using AWS host public ip from my laptop.
The output of netstat -tulpn:
(No info could be read for "-p": geteuid()=1000 but you should be root.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN -
tcp6 0 0 :::8080 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 ::1:25 :::* LISTEN -
udp 0 0 0.0.0.0:68 0.0.0.0:* -
udp 0 0 127.0.0.1:323 0.0.0.0:* -
udp6 0 0 ::1:323 :::* -
My AWS Security inbound rules:
HTTP TCP 80 157.51.138.196/32
All traffic All All 157.51.138.196/32
SSH TCP 22 157.51.138.196/32
DNS (TCP) TCP 53 157.51.138.196/32
HTTPS TCP 443 157.51.138.196/32
you are missing inbound rule 8080 on instance security group add it and check and inform further if not work.
Hurray it Worked!!!
But not sure how it worked actually ;-) Will try to find out that...
I just stopped all apache containers and removed them entirely. Then executed the below command and everything worked perfect.
While using the below make sure you are mapping the volume (-v) correctly to the index.html file in your host.
docker run -d --name httpd -p 9080:8080 -v /home/ec2-user/apache/web1/www/html:/var/www/html:Z docker.io/centos/httpd-24-centos7
I am trying to run AMQP with bunny and event machine. Whenever I try to use a worker, bunny complains about the following: Could not establish TCP connection to any of the configured hosts
I don't see port 5672 anywhere when I run netstat. Further, the output of nmap -p 5672 0.0.0.0 gives the following:
Nmap scan report for 0.0.0.0
Host is up (0.000092s latency).
PORT STATE SERVICE
5672/tcp closed amqp
My configuration file ($HOME/etc/rabbitmq/rabbitmq.config is as follows:
[{mnesia, [{dump_log_write_threshold, 1000}]},
{rabbit, [{tcp_listeners, [5672]},
{cluster_nodes, {['rabbit#jordan-dev'], disc}}
]}].
Could anybody explain to me why rabbitmq can not connect to the tcp port specified in the configuration file?
Is your firewall configured properly?
Try telnet ip port from some machine is see if it's reachable. If it's not reachable then add the firewall rule.
iptables -A INPUT -p tcp --dport 5672 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 5672 -j ACCEPT
What ports does RabbitMQ Server use or need to have open on the firewall for a cluster of nodes?
My /usr/lib/rabbitmq/bin/rabbitmq-env is set below which I'm assuming are needed (35197).
SERVER_ERL_ARGS="+K true +A30 +P 1048576 \
-kernel inet_default_connect_options [{nodelay,true}] \
-kernel inet_dist_listen_min 35197 \
-kernel inet_dist_listen_max 35197"
I haven't touched the rabbitmq.config to set a custom tcp_listener so it should be listening on the default 5672.
Here are the relevant netstat lines:
tcp 0 0 0.0.0.0:4369 0.0.0.0:* LISTEN 728/epmd
tcp 0 0 0.0.0.0:35197 0.0.0.0:* LISTEN 5126/beam
tcp6 0 0 :::5672 :::* LISTEN 5126/beam
My questions are:
for other nodes to be able to connect to the cluster, do all 3 ports 4369, 5672 and 35197 need to be open?
Why isn't 5672 running on tcp and not just tcp6?
PORT 4369: Erlang makes use of a Port Mapper Daemon (epmd) for resolution of node names in a cluster. Nodes must be able to reach each other and the port mapper daemon for clustering to work.
PORT 35197
set by inet_dist_listen_min/max Firewalls must permit traffic in this range to pass between clustered nodes
RabbitMQ Management console:
PORT 15672 for RabbitMQ version 3.x
PORT 55672 for RabbitMQ pre 3.x
Make sure that the rabbitmq_management plugin is enabled, otherwise you won't be able to access management console on those ports.
PORT 5672 RabbitMQ main port (AMQP)
PORT 5671 TLS-encrypted AMQP (if enabled)
For a cluster of nodes, they must be open to each other on 35197, 4369 and 5672.
For any servers that want to use the message queue, only 5672 (or possibly 5671) is required.
What ports is RabbitMQ using?
Default: 5672, the manual has the answer. It's defined in the RABBITMQ_NODE_PORT variable.
https://www.rabbitmq.com/configure.html#define-environment-variables
The number might be differently if changed by someone in the rabbitmq configuration file:
vi /etc/rabbitmq/rabbitmq-env.conf
Ask the nmap if it can see it:
sudo nmap -p 1-65535 localhost
Starting Nmap 5.51 ( http://nmap.org ) at 2014-09-19 13:50 EDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00041s latency).
PORT STATE SERVICE
443/tcp open https
5672/tcp open amqp
15672/tcp open unknown
35102/tcp open unknown
59440/tcp open unknown
Oh look, 5672, and 15672
Ask netstat if it can see it:
netstat -lntu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:15672 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:55672 0.0.0.0:* LISTEN
tcp 0 0 :::5672 :::* LISTEN
Oh look 5672.
lsof to see ports:
eric#dev ~$ sudo lsof -i | grep beam
beam.smp 21216 rabbitmq 17u IPv4 33148214 0t0 TCP *:55672 (LISTEN)
beam.smp 21216 rabbitmq 18u IPv4 33148219 0t0 TCP *:15672 (LISTEN)
use nmap from a different machine, find out if 5672 is open:
sudo nmap -p 5672 10.0.1.71
Starting Nmap 5.51 ( http://nmap.org ) at 2014-09-19 13:19 EDT
Nmap scan report for 10.0.1.71
Host is up (0.00011s latency).
PORT STATE SERVICE
5672/tcp open amqp
MAC Address: 0A:40:0E:8C:75:6C (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds
Try to connect to a port manually with telnet, 5671 is CLOSED:
telnet localhost 5671
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
Try to connect to a port manually with telnet, 5672 is OPEN:
telnet localhost 5672
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Check your firewall:
sudo cat /etc/sysconfig/iptables
It should tell you what ports are made open:
-A INPUT -p tcp -m tcp --dport 5672 -j ACCEPT
Reapply your firewall:
sudo service iptables restart
iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Flushing firewall rules: [ OK ]
iptables: Unloading modules: [ OK ]
iptables: Applying firewall rules: [ OK ]
To find out what ports rabbitmq uses:
$ epmd -names
Outputs:
epmd: up and running on port 4369 with data:
name rabbit at port 25672
Run these as root:
lsof -i :4369
lsof -i :25672
More about epmd options.
Port Access
Firewalls and other security tools may prevent RabbitMQ from binding to a port. When that happens, RabbitMQ will fail to start. Make sure the following ports can be opened:
4369: epmd, a peer discovery service used by RabbitMQ nodes and CLI tools
5672, 5671: used by AMQP 0-9-1 and 1.0 clients without and with TLS
25672: used by Erlang distribution for inter-node and CLI tools communication and is allocated from a dynamic range (limited to a single port by default, computed as AMQP port + 20000). See networking guide for details.
15672: HTTP API clients and rabbitmqadmin (only if the management plugin is enabled)
61613, 61614: STOMP clients without and with TLS (only if the STOMP plugin is enabled)
1883, 8883: (MQTT clients without and with TLS, if the MQTT plugin is enabled
15674: STOMP-over-WebSockets clients (only if the Web STOMP plugin is enabled)
15675: MQTT-over-WebSockets clients (only if the Web MQTT plugin is enabled)
Reference doc:
https://www.rabbitmq.com/install-windows-manual.html
Check \AppData\Roaming\RabbitMQ\log. If you have a log file there search for started TCP listener on [::].
It should tell you on which port rabbitMq is running. Look for the last entry.
Disclaimer: not the best way to find port, as there might be a chance the port has been changed in the mean time.