I am a beginner with Linux TC. I cannot figure out why a certain qdisc which I added to the root of an interface cannot be deleted by specifying its handle.
Yes, I know I can delete it using the root specifier if it's attached to the root of the interface, but I should also be able to delete it by handle.
root#pc:/home/pc# tc qdisc add dev enp0s3 root netem
root#pc:/home/pc# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2
qdisc netem 8005: dev enp0s3 root refcnt 2 limit 1000
root#pc:/home/pc# tc qdisc delete dev enp0s3 handle 8005
RTNETLINK answers: Invalid argument
root#pc:/home/pc# tc qdisc delete dev enp0s3 root
root#pc:/home/pc#
In the above sample, a netem qdisc was added, and it's handle is shown as 8005. I try to delete it by specifying that handle. This doesn't work. But obviously, specifying root as the handle works.
Why?
Related
I've been connecting to a Google Cloud VM instance via gcloud ssh from my macOS:
$ gcloud compute ssh [username]#[instance]
Starting from a week ago, the connection will just drop after ~60 seconds of idle connection and returns:
Connection to [my_external_ip] closed by remote host.
Connection to [my_external_ip] closed.
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
I configured the TCP keepalive time to 30 seconds on both my macbook and the VM. But that did not solve the problem.
Any idea how do I extend the connection duration?
This is unlikely an issue with your timeout setting, but more likely an issue with your firewall rules or routes.
Firstly I would suggest checking your firewall rules and ensure you have an ingress firewall rule opening port 22. If you have, check the configuration of this rule, in particular:
Check the IP range in 'Source filters'. Does the range include the IP address of your home computer? For testing purposes, to ensure it does, you could temporarily set this to 0.0.0.0/0 to include all IP addresses.
Check the 'Targets' drop-down. Is this set to apply to 'All instances in the network' or is it set to 'Specified target tags'? If you have set it to 'Specified target tags', make sure that the same tag is added to the 'Network tags' section of the instance, otherwise the firewall rule will not apply to the instance and allow SSH traffic.
Ensure this rule has a higher priority than any other rules that could counteract it (when I say higher priority I mean lower number, for example, a a rule with a priority of 1000 is a higher priority than a rule with a priority of 20000).
If the above doesn't resolve the issue, run the following command to check the routes:
gcloud compute routes list
Ensure there is an entry which contains the following:
default 0.0.0.0/0 default-internet-gateway
EDIT
If you are able to sometimes SSH into the instance but then the connection drops, there may be some useful information in the logs, or the serial console.
You can access the serial console by clicking on the instance name in the GCP Console, then clicking on "Serial port 1 ".
When you SSH into the instance, information about the SSH session populates the serial console output (this can be refreshed by hitting the 'Refresh' at the top of the page.) Information about the session ending also populates the serial console. There may be some useful information/clues about why the session ends in this output.
It might also be worth checking the status of SSH daemon on the instance and giving it a restart to see if that makes a difference:
Check status of sshd:
systemctl status sshd
Restart sshd:
sudo systemctl restart sshd
I have an issue with kvm/libvirt virtualization and network namespaces on my Ubuntu 16.04 LTS. What I want to do is the following fenced setup:
One network namespace (the fence)
Two Linux bridges in the namespace.
Each bridge has it's own ip network.
Allow ip forwarding between these two bridges.
Two VMs. VM1 is connected to bridge1 and VM2 is conncted to bridge2.
Ping VM1 to VM2.
The intention is to get a little lab on my laptop which is fully independent from the host's remaining network setup that has communication to the outside world and it seems to me that network namespaces are the way to attain this but I hit some snags.
Until now I've set up the following:
ip netns add internalSpielwiese
ip netns exec internalSpielwiese bash
ip addr add 127.0.0.1/8 dev lo
ip link set lo up
ip link add name iBr0 type bridge
ip addr add 172.0.0.1/24 dev iBr0
ip link set iBr0 up
ip link add name iBr1 type bridge
ip addr add 172.0.1.1/24 dev iBr1
ip link set iBr1 up
Pinging the ips inside the namespace is successful. IP forwarding is enabled. Outside the namespace the bridges are not visible/existent. Now it would be time to make the bridges in libvirt known. But it doesn't work. I tried it with this xml
<network>
<name>internalBr0</name>
<uuid>3f4647d9-0c19-509f-b512-9cac91c7149b</uuid>
<forward mode='bridge'/>
<bridge name='iBr0'/>
</network>
and appropriate virsh net-define and net-start commands. I edited a VM's xml file and started the VM but the result was this:
virsh # start kirke2
error: Failed to start domain kirke2
error: Cannot get interface MTU on 'iBr0': No such device
Obviously, libvirt didn't find the iBr0 in the namespace internalSpielwiese and after some googling I've got the impression that libvirt is not able to deal with network namespaces. Or is there a way? How?
Libvirt can only see resources that are located in the same namespaces that libvirtd is running in. So the devices in your private namespace are invisible to libvirtd. There's no good way around this at this time, aside from making libvirtd run in this custom network namespace too. Then the host NICs are invisible to libvirtd - whether this is a problem or not depends on what you try todo.
at the first day when i created the instance, i was able to SSH no problem, but after yesterday, i just couldnt connect to my instance. when i checked the console i get something like this
Nov 5 15:30:49 my-app kernel: [79738.555434] [UFW BLOCK] IN=ens4 OUT= MAC=42:01:0a:94:00:02:42:01:0a:94:00:01:08:00 SRC=71.15.27.115 DST=10.121.0.7 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=38049 PROTO=TCP SPT=37344 DPT=22 WINDOW=60720 RES=0x00 SYN URGP=0
i figured its a firewall issue, but my firewall rule seems okay (assuming i did not change anything since first i created the instance). i wonder what else could be the problem? here's my fw config
default-allow-http
http-server
IP ranges: 0.0.0.0/0
tcp:80
Allow
1000
default
default-allow-https
https-server
IP ranges: 0.0.0.0/0
tcp:443
Allow
1000
default
default-beego-http
http-server
IP ranges: 0.0.0.0/0
tcp:8080
Allow
1000
default
default-jenkins-app
http-server
IP ranges: 0.0.0.0/0
tcp:8989
Allow
1000
default
default-allow-icmp
Apply to all
IP ranges: 0.0.0.0/0
icmp
Allow
65534
default
default-allow-internal
Apply to all
IP ranges: 10.128.0.0/9
tcp:0-65535, udp:0-65535, 1 more
Allow
65534
default
default-allow-rdp
Apply to all
IP ranges: 0.0.0.0/0
tcp:3389
Allow
65534
default
default-allow-ssh
Apply to all
IP ranges: 0.0.0.0/0
tcp:22
Allow
65534
default
Looking at the output you’ve provided following your attempt to SSH into your instance, it looks like you’re being blocked by UFW (Uncomplicated Firewall) which is installed/enabled on the actual instance, rather than the GCP project wide firewall rules you have set (these look okay).
In order to SSH into your VM you will need to open port 22 in UFW on the instance. There are a couple of possible methods that will allow you to do this.
Firstly, see Google Compute Engine - alternative log in to VM instance if ssh port is disabled , specifically the answer by Adrián which explains how to open port 22 using a startup script. This method requires you to reboot your instance before the firewall rule is applied.
Another method which doesn’t require a reboot of the machine makes use of the Serial Console. However, in order to use this method a password for the VM is required. This method is therefore only possible if you previously set a password on the VM (before losing access).
To connect via the Serial Console the following metadata must be added, either to the instance you are trying to connect to, or to the entire project:
serial-port-enable=1
You can apply the metadata to a specific instance like so:
gcloud compute instances add-metadata [INSTANCE_NAME] \
--metadata=serial-port-enable=1
Or alternatively, to the entire project by running:
gcloud compute project-info add-metadata --metadata=serial-port-enable=1
After setting this metadata you can attempt to connect to the instance via the Serial Console by running the following command from the Cloud Shell:
gcloud compute connect-to-serial-port [INSTANCE_NAME]
When you have accessed the instance you will be able to manage the UFW rules. To open port 22 you can run:
sudo /usr/sbin/ufw allow 22/tcp
Once UFW port 22 is open, you should then be able to SSH into your instance from Cloud Shell or from the Console.
There is some additional info about connecting to instances via the Serial Console here:
https://cloud.google.com/compute/docs/instances/interacting-with-serial-console
I'm trying to setup a three-node Aerospike cluster on Ubuntu 14.04. Apart from the IP address/name, each machine is identical. I installed Aerospike and the management console, per the documentation, on each machine.
I then edited the network/service and network/heartbeat sections in /etc/aerospike/aerospike.conf:
network {
service {
address any
port 3000
access-address 10.0.1.11 # 10.0.1.12 and 10.0.1.13 on the other two nodes
}
heartbeat {
mode mesh
port 3002
mesh-seed-address-port 10.0.1.11 3002
mesh-seed-address-port 10.0.1.12 3002
mesh-seed-address-port 10.0.1.13 3002
interval 150
timeout 10
}
[...]
}
When I sudo service aerospike start on each of the nodes, the service runs but it's not clustered. If I try to add another node in the management console, it informs me: "Node 10.0.1.12:3000 cannot be monitored here as it belongs to a different cluster."
Can you see what I'm doing wrong? What changes should I make to aerospike.conf, on each of the nodes, in order to setup an Aerospike cluster instead of three isolated instances?
Your configuration appears correct.
Check if you are able to open a TCP connection over ports 3001 and 3002 from each host to the rest.
nc -z -w5 <host> 3001; echo $?
nc -z -w5 <host> 3002; echo $?
If not I would first suspect firewall configuration.
Update 1:
The netcat commands returned 0 so let's try to get more info.
Run and provide the output of the following on each node:
asinfo -v service
asinfo -v services
asadm -e info
Update 2:
After inspecting the output in the gists, the asadm -e "info net" indicated that all nodes had the same Node IDs.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Network Information~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node Node Fqdn Ip Client Current HB HB
. Id . . Conns Time Self Foreign
h *BB9000000000094 hadoop01.woolford.io:3000 10.0.1.11:3000 15 174464730 37129 0
Number of rows: 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Network Information~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node Node Fqdn Ip Client Current HB HB
. Id . . Conns Time Self Foreign
h *BB9000000000094 hadoop03.woolford.io:3000 10.0.1.13:3000 5 174464730 37218 0
Number of rows: 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Network Information~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node Node Fqdn Ip Client Current HB HB
. Id . . Conns Time Self Foreign
h *BB9000000000094 hadoop02.woolford.io:3000 10.0.1.12:3000 5 174464731 37203 0
Number of rows: 1
The Node ID is constructed with the fabric port (port 3001 in hex) followed by the MAC address in reverse byte order. Another flag was that the "HB Self" was non-zero and is expected to be zero in a mesh configuration (in a multicast configuration this will also be non-zero since the nodes will receive their own heartbeat messages).
Because all of the Node IDs are the same, this would indicate that all of the MAC address are the same (though it is possible to change the node IDs using rack aware). Heartbeats that appear to have originated from the local node (determined by hb having the same node id) are ignored.
Update 3:
The MAC addresses are all unique, which contradicts previous conclusions. A reply provided the interface name being used, em1, which is not an interface name Aerospike looks for. Aerospike looks for interfaces named either eth#, bond#, or wlan#. I assume since the name wasn't one of the expected three this caused the issue with the MAC addresses; if so I would suspect the following warning exists in the logs?
Tried eth,bond,wlan and list of all available interfaces on device.Failed to retrieve physical address with errno %d %s
For such scenarios the network-interface-name parameter may be used to instruct Aerospike which interface to use for node id generation. This parameter also determines which interface's IP address should be advertised to the client applications.
network {
service {
address any
port 3000
access-address 10.0.1.11 # 10.0.1.12 and 10.0.1.13 on the other two nodes
network-interface-name em1 # Needed for Node ID
}
Update 4:
With the 3.6.0 release, these device names will be automatically discovered. See AER-4026 in release notes.
Last week I was using RPC and could run my RPC server program just fine. However, today I tried to start it again and I am getting this error:
Cannot register service: RPC: Authentication error; why = Client
credential too weak unable to register (X_PROG, X_VERS, udp)
Can anybody tell me what the cause of this error can be?
rpcinfo gives me this:
program version netid address service owner
100000 4 tcp6 ::.0.111 portmapper superuser
100000 3 tcp6 ::.0.111 portmapper superuser
100000 4 udp6 ::.0.111 portmapper superuser
100000 3 udp6 ::.0.111 portmapper superuser
100000 4 tcp 0.0.0.0.0.111 portmapper superuser
100000 3 tcp 0.0.0.0.0.111 portmapper superuser
100000 2 tcp 0.0.0.0.0.111 portmapper superuser
100000 4 udp 0.0.0.0.0.111 portmapper superuser
100000 3 udp 0.0.0.0.0.111 portmapper superuser
100000 2 udp 0.0.0.0.0.111 portmapper superuser
100000 4 local /run/rpcbind.sock portmapper superuser
100000 3 local /run/rpcbind.sock portmapper superuser
The weird thing is that I haven't even been using this pc the past week.
Are there any services that should be running?
Hope you can help me out.
Grtz Stefan
this error is linked to rpcbind,so you should stop service portmap like this:
sudo -i service portmap stop
then
sudo -i rpcbind -i -w
at end start service portmap:
sudo -i service portmap start
I realize this is an older thread, but Google finds it among the top 3 results and people are still discovering the nfs service error. Even Red Hat's RHN's fix didn't work.
As of December 2013 on a RHEL 6.4 (x64), and patched as of November 2013, the only solution was changing the permissions on the tcp_wrapper config files. Because we had secured the box pretty heavily, we had permissions of 640 on /etc/hosts.allow and /etc/hosts.deny, both owned by root:root. We did try given these files different group ownership nothing corrected the issue when nfs started.
Once we put the perms back to "out-of-the-box" (644) the nfs (rquotad) service started up as expected. Or if we moved the hosts.allow/deny out of the way entirely.
What a pain that was to figure out. The selinux logs may have helped if I had looked sooner.
Now if we had left selinux in enforcing mode this MAY have not been an issue. I still have to test that theory.
Good luck.
Making the change persistent on Ubuntu12.04
(assuming security implications of running rpcbind with -i are irrelevant):
echo 'OPTIONS="-w -i"' | sudo tee /etc/default/rpcbind
sudo service portmap restart
Yet Another Solution: CentOS 7.3 edition
In addition to rpcbind, I also had to allow mountd in /etc/hosts.allow:
rpcbind : ALL : allow
mountd : ALL : allow
This finally allowed me to not only execute rpcinfo, but showmount and mount as well.
None of the solutions presented here so far worked for me on the Debian Squeeze to Wheezy upgrade.
In my case the sole thing I had to do was to replace all occurrences of "portmapper" (or "portmap", no more sure) in /etc/hosts.allow with "rpcbind". That was all. (Otherwise ypbind couldn't connect to rpcbind via localhost.)
This also happens if iptables is used and it is blocking UDP connections for localhost. Ran into this today. Stopped iptables, connections started working.
You will need to figure out the rules that broke it.
I think that it is worth mentioning that if you see errors like:
0-rpc-service: Could not register with portmap
it can be related to hosts.allow and hosts.deny files set and lacking permissions for localhost in the hosts.allow file.
I had this kind of problem with setting NFS with GlusterFS.
In my /etc/hosts.allow file I have added:
ALL: 127.0.0.1 : ALLOW
and problem with registering service with portmap went away and everything is working.
Note: with GlusterFS remember to restart the glusterd service
/etc/init.d/glusterd restart
I was receiving an error like so on rhel7:
ypserv: Cannot register service: RPC: Authentication error; why = Client credential too weak
when starting ypbind. I tried everything including the '-i' to rpcbind above. In the end as XTaran mentioned modifying /etc/hosts. allow adding this line:
rpcbind: 127.0.0.1
worked for me.
FWIW, here's an 'alternative' solution.
Check the /etc/hosts.deny file. It should say something like:
rpcbind mountd nfsd statd lockd rquotad : ALL
Ensure that there is a blank last line in this file.
Check the /etc/hosts.allow file. It should say something like:
rpcbind mountd nfsd statd lockd rquotad: 127.0.0.1 192.168.1.100
Ensure that there is a blank last line in this file.
The "trick" (for me) was the blank final line in the file(s).