Libvirt dnsmasq is running on all interfaces, this is undesired - virtualization

So currently I'm running libvirt on my debian box, and it's DHCP server is listening on all interfaces, I would like to restrict that down to the bridge interface where the VMs would live. I can kill off the dhcp server temporarily to accomplish what I need but would like something more permanent.
I'm sure there is some option I can put in the dhcp server portion of the network config to make this happen.
<network>
<name>default</name>
<uuid>2fb34907-96bc-4af1-89a2-4f1f872a2600</uuid>
<forward mode='nat'/>
<bridge name='virbr0' stp='on' delay='0'/>
<mac address='52:54:00:c3:d2:ea'/>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.122.2' end='192.168.122.254'/>
<host mac='52:54:00:21:df:dc' ip='192.168.122.2'/>
</dhcp>
</ip>
<route address='192.168.122.2' prefix='32' gateway='192.168.122.110'/>
</network>
root#calypso-deb:~# lsof -i -n | grep dnsmasq
dnsmasq 1656 nobody 3u IPv4 29150 0t0 UDP *:bootps
dnsmasq 1656 nobody 5u IPv4 29153 0t0 UDP 192.168.122.1:domain
dnsmasq 1656 nobody 6u IPv4 29154 0t0 TCP 192.168.122.1:domain (LISTEN)
root#calypso-deb:~#

Here’s a suggestion (which is meant to be a comment rather than an answer, but I cannot comment).
User Jonathon Reinhart posted an answer that describes how to pass options to dnsmasq (since libvirt v.5.6.0). See also “Network XML format” in the libvirt documentation. This got me wondering whether passing something like --interface=virbr0 --bind-interfaces would do what you need in this case.

It should already be listening on virbr0 interface only, as the config shows that too.
You can check that with lsof -i -n | grep dnsmasq or similar tools.

Related

Postgres database port 5432. Is it connecting to the internet?

I am a newbie to connections. I ran the following command on my ubuntu server:
lsof -nP -iTCP -sTCP:LISTEN
and this came up, among other connections:
postgres 29826 postgres 7u IPv6 192275 0t0 TCP [::1]:5432 (LISTEN)
postgres 29826 postgres 8u IPv4 192276 0t0 TCP 127.0.0.1:5432 (LISTEN)
I am configuring my "ufw" firewall and trying to understand what is connecting to my server. Question is the following:
Is this connecting in some way to the internet? I am assuming it is not, since the IP address is local. Another question, is there a command to check only incoming and outcoming connections to the internet? Somewhat simplified so I can understand it better?
Thank you very much
You are right, that server is only listening on the loopback interface.
You'll have to change the listen_addresses parameter and restart PostgreSQL.

Is there a way to determine to which etcd host the kubernetes apiserver is talking to?

Only apiserver talks directly to etcd. In the etcd cluster there are many hosts. I would like to see to which etcd host the apiserver is talking to. This may be different for each api resource like Pod or Node. I prefer to see etcd host information for each request.
Specifically, kubernetes 1.6.13 and etcd 3.1.14 using v3 store.
I have tried:
Enable etcd client and grpc logging on the kubernetnes api server.
I think grpc only logs in unexpected events. Similarly for etcd
clientv3. I was not able to get information about the etcd side of the
connection.
Enable http2 debug logging with GODEBUG=http2debug=2 on api server
To my surprise http2 debug logs print a lot of information about each request but I could not find the remote endpoint information. I am still skeptical about this I may be missing a mention in the log files. Not completely sure.
Debug logs on the etcd side.
Enabling debug logs with Enabling Debug Logging prints only about v2 store accesses. For v3 store one could use the http://<host>2379/debug/requests endpoint but that is not available in my version of etcd 3.1.14.
I have not tried yet to use GODEBUG=http2debug=2 on the etcd side. Maybe the http2 logs on the etcd have the info I need.
tcpdump or tcpflow
The apiserver <-> etcd connection is encrypted. Would these show me the request url ? I think I did not see that information in the dumps.
Man in the middle attack the apiserver <-> etcd connection with mitmproxy. I do not think this should be that complicated.
I hope, I have missed a super obvious and simple way to accomplish this.
Update:
About using lsof based approaches:
Using lsof, we can list the connections with endpoints information at one time. I do not think there is enough information in lsof output to arrive at endpoint information per request. Apiserver opens a lot of connections to etcd. Looking at the code that observation looks reasonable to me. See NewStorage in here
$ sudo lsof -p 20816 | grep :2379 | wc -l
130
The connections looks like this
$ sudo lsof -
p 20816 | grep :2379 | head -n 5
hyperkube 20816 root 3u IPv4 58093240 0t0 TCP compute-master7001.dsv31.boxdc.net:36360->compute-etcd7001.dsv31.boxdc.net:2379 (ESTABLISHED)
hyperkube 20816 root 5u IPv4 58085987 0t0 TCP compute-master7001.dsv31.boxdc.net:26005->compute-etcd7002.dsv31.boxdc.net:2379 (ESTABLISHED)
hyperkube 20816 root 6u IPv4 58085988 0t0 TCP compute-master7001.dsv31.boxdc.net:55650->compute-etcd7003.dsv31.boxdc.net:2379 (ESTABLISHED)
hyperkube 20816 root 7u IPv4 58102030 0t0 TCP compute-master7001.dsv31.boxdc.net:36366->compute-etcd7001.dsv31.boxdc.net:2379 (ESTABLISHED)
hyperkube 20816 root 8u IPv4 58085990 0t0 TCP compute-master7001.dsv31.boxdc.net:55654->compute-etcd7003.dsv31.boxdc.net:2379 (ESTABLISHED)
........
Looking at this, I cannot know which etcd is used for each request between the apiserver and etcd.
Update:
I think at the etcdv3 client code that ships with kubernetes 1.6.13, the grpc.Balancer.Get function returns the endpoint address used for each grpc request. I think one could add a log print here and make apiserver log the etcd address per request.
Find the pid of apiserver
ps aux | grep apiserver
Then use lsof to see the open socket connections
lsof -p $PID | grep :2379

how to change ipv6 to ipv4?

i've problem with change ipv6 to ipv4 when i used this command
lsof -i :6702
got this
java 3143 st 71u IPv6 12097 0t0 TCP *:6702 (LISTEN)
as you can see it using ipv6 and i want to change it to ipv4
i used the
supervisor.childopts: "-Djava.net.preferIPv4Stack=true"
in storm.yaml
summary in storm ui read the change but when i used
lsof -i :6702 didn't read it ! still using ipv6 !
If 6702 is a worker, perhaps try to add -Djava.net.preferIPv4Stack=true to worker.childopts as well?
It looks like you are on a dual stack node. The v6 socket should accept incoming v4 connections transparently. What problem are you trying to solve?
Error disappered by adding this property
-Djava.net.preferIPv4Stack=true
to nimbus and supervisor and worker in storm.yaml

Open Port in Ubuntu

So I'm using AWS using EC2 and I'm trying to open up a port for Postgresql. In AWS I already have it open:
TCP
Port (Service) Source Action
0 - 65535 sg-92aadda2 (default) Delete
22 (SSH) 0.0.0.0/0 Delete
80 (HTTP) 0.0.0.0/0 Delete
5432 0.0.0.0/0 Delete
When I do netstat it looks as though the port is listening:
# netstat -an | grep 5432
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN
When I do a localhost nmap I get the following:
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000010s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
5432/tcp open postgresql
And here's where the fun begins. When I do an nmap from an alternative host I get the following:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
5432/tcp closed postgresql
I also looked at my iptables to see if I was missing something, but the iptables look empty (which should mean they aren't really doing much)
$ iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere 127.0.0.0/8 reject-with icmp-port-unreachable
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:postgresql
ACCEPT icmp -- anywhere anywhere
LOG all -- anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "iptables denied: "
DROP all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Am I missing something cause I can't seem to figure out how to access the ip. Whenever I try I get the following error:
Is the server running on host "xx.xx.xx.xx" and accepting TCP/IP connections on port 5432?
How do I make it so that I can open up the port so that external servers have access to it? Thanks in advance =) Lemme know if you need any additional data.
EDIT: As asked below, I tested telnetting, and I was able to telnet into the localhost, but when attempting from the outside I get:
$ telnet xx.xx.xx.xx 5432
Trying xx.xx.xx.xx...
telnet: Unable to connect to remote host: Connection refused
Also, I double checked and I was properly able to telnet into ssh:
$ telnet xx.xx.xx.xx 22
Trying xx.xx.xx.xx...
Connected to xx.xx.xx.xx.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
Edit /etc/postgresql/<version>/main/postgresql.conf and set the listen_addresses to your outgoing interface or all. Restart postgresql: sudo service postgresql restart.
It works for me the last method (thks Julio):
Edit: postgresql.conf
sudo nano /etc/postgresql/9.3/main/postgresql.conf
Enable or add:
listen_addresses = '*'
Restart the database engine:
sudo service postgresql restart
Besides, you can check the file: pg_hba.conf
sudo nano /etc/postgresql/9.3/main/pg_hba.conf
And add your network or host address:
host all all 192.168.1.0/24 md5
If you have edited postgresql.conf and main/pg_hba.conf and still having a problem, please try
sudo ufw allow 5432/tcp
to unblock psql port
In case you are using docker to connect to the host's postgresql you have to use the host's ip which you can obtain by running ip addr show docker0 hope it helps someone.

Can't connect to memcached server on localhost, how to debug?

I'm running memcached, but can't connect. How should I start to debug this? Something appears to be stopping me connecting.
ps -elf | grep memcached
0 S lee 10744 529 0 80 0 - 30529 ep_pol 03:36 pts/22 00:00:00 /usr/bin/memcached -m 512 -p 11211 -u nobody -l 127.0.0.1
(Memcached is definitely running)
But when I try to telnet in, I get a timeout.
telnet 127.0.0.1 11211
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection timed out
Any advice would be appreciated.
Ensure that the local loopback network interface is running. It sounds like you're using a Unix system, so I would recommend running /sbin/ifconfig to see if a section labeled lo with the IP address (labeled as the inet addr) 127.0.0.1 is up and running. If not, run ifdown lo then ifup lo, this should get it going. Read your /etc/hosts file to make sure that localhost or you machine's name is bound to 127.0.0.1. And if your machine is using ipchains or iptables, ensure that those are configured to let traffic pass to 127.0.0.1 from 127.0.0.1.
These things are all fine 99% of the time, but being unable to connect to localhost is indeed odd, so a sanity check is in order.
Make sure you don't have any firewall enabled. In my case I found following entries for iptables:
target prot opt source destination
ACCEPT tcp -- example.com.internal anywhere tcp dpt:11211
ACCEPT udp -- example.com.internal anywhere udp dpt:11211
DROP tcp -- anywhere anywhere tcp dpt:11211
DROP udp -- anywhere anywhere udp dpt:11211
They allow connection only from the example.com.internal and deny from anywhere else, including localhost. To fix that I added specific rule for localhost:
ACCEPT tcp -- localhost anywhere tcp dpt:11211
ACCEPT udp -- localhost anywhere udp dpt:11211