Network manager does not edit settings - cloud-init

I am trying to move my organisation from Centos7 to Centos8 and Rocky linux which have network manager. Due to the multi-homed system I am trying to setup scriping to autoconnect since out of the box NM loses connectivity but I am a bit stuck.
If I try to run For example
nmcli c modify ens3 "IP4.DNS[0]" "8.8.8.8"
I get the Error: invalid or not allowed setting 'IP4': 'IP4' not among [connection, 802-3-ethernet (ethernet), 802-1x, dcb, sriov, ethtool, match, ipv4, ipv6, hostname, tc, proxy]. From what I understand NM is unable to modify these settings but I not understand why, or who set them up. I suspect it is somewhere in cloud init or in the dhcp-reply ??
nmcli connection show ens3 | grep IP4
IP4.ADDRESS[1]:136.ZZ.XX.XXX/23
IP4.GATEWAY:136.ZZ.YY.YY
...
IP4.DOMAIN[1]:openstacklocal
[root#chkorocky syck]# nmcli c show ens3 | grep ipv4
ipv4.method: auto
ipv4.dns: --
ipv4.dns-search: --
ipv4.addresses: --
ipv4.gateway: --
Is there anyway to understand where these extra attributes come from? Somehow ipv4.XX do not get set up at all but instead other variables with similar names allow NM to work ?

Related

LuaSocket How to bind to interface?

Is there a SO_BINDTODEVICE equivalent or workaround for LuaSocket?
I've tried:
ifconfig to fetch the inet addr of my interface (e.g. ethA 1.1.1.1) + setpeername("1.1.1.1", 0). When I tcpdump on "ethA", I don't see my packet. Not too sure what the difference between bind versus bindtodevice is - I thought bindtodevice was just a shortcut to fetch the ip address from the interface name but that doesn't seem to be the case.
local udp = socket.udp()
udp:settimeout(1)
udp:setsockname("1.1.1.1", 0)
udp:setpeername("2.2.2.2", 12345)
udp:send(query)
The ip-multicast-if from https://tst2005.github.io/lua-socket/udp.html which was the only thing that mentioned interface in the documentation didn't seem to work.
local udp = socket.udp()
udp:setoption("ip-multicast-if", "1.1.1.1")
udp:settimeout(1)
udp:setsockname("*", 0) -- I've also tried "1.1.1.1" here and it didn't work.
udp:setpeername("2.2.2.2", 12345)
udp:send(query)
I see that it may be an option for luaposix, but I don't have that package and I don't want to bring in an additional dependency just for this.

Failed to infer CIDR network for mon ip

I follow the instructions to bootstrap a new Ceph (I'm new to Ceph) cluster.
I got the following error:
sudo cephadm bootstrap --mon-ip <mon-ip>
INFO:cephadm:Verifying podman|docker is present...
INFO:cephadm:Verifying lvm2 is present...
INFO:cephadm:Verifying time synchronization is in place...
INFO:cephadm:Unit systemd-timesyncd.service is enabled and running
INFO:cephadm:Repeating the final host check...
INFO:cephadm:podman|docker (/usr/bin/podman) is present
INFO:cephadm:systemctl is present
INFO:cephadm:lvcreate is present
INFO:cephadm:Unit systemd-timesyncd.service is enabled and running
INFO:cephadm:Host looks OK
INFO:root:Cluster fsid: e08484be-72c1-11ea-a13e-0050563f093a
INFO:cephadm:Verifying IP *<mon-ip>* port 3300 ...
INFO:cephadm:Verifying IP *<mon-ip>* port 6789 ...
ERROR: Failed to infer CIDR network for mon ip *<mon-ip>*; pass --skip-mon-network to configure it later
What does it mean ? How to fix it ?
cephadm is still fairly new. I've tracked a few days ago in:
https://tracker.ceph.com/issues/44828
Please run
ceph config set mon public_network <mon_network>
after bootstrap finished.
Is this the exact command you ran?
sudo cephadm bootstrap --mon-ip *<mon-ip>*
If so you actually need to replace *<mon-ip>* with the actual IP address that you want the monitor daemon to listen on.
For future reference, on that page, any command you see that has a variable surrounded by asterisks is something you would need to replace with an address/host/hostname etc. that applies to your environment.

how can I make large number of connections without error at client side

I have written a program in golang to make request about 2000qps to different remote ip with local port randomly selected by linux, and close request immediately after connection established, but still encounter bind: address already in use error periodically
what I have done:
net.ipv4.ip_local_port_range is 15000-65535
net.ipv4.tcp_tw_recycle=1 net.ipv4.tcp_tw_reuse=1 net.ipv4.tcp_fin_timeout=30
above is sockstat:
sockets: used 1200 TCP: inuse 2302 orphan 1603 tw 40940 alloc 2325 mem 201
I don't figure it out why this error still there with kernel selecting available local port,will kernel return a port in use ?
This is a good answer from 2012:
https://serverfault.com/questions/342741/what-are-the-ramifications-of-setting-tcp-tw-recycle-reuse-to-1#434669
As of 2018, tcp_tw_recycle exists only in the sysctl binary, is otherwise gone from the kernel:
https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=tcp_tw_recycle&type=
tcp_tw_reuse is still in use as described in the above answer:
https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_ipv4.c#L128
However, while a TCP_TIMEWAIT_LEN is in use:
https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=TCP_TIMEWAIT_LEN&type=
the value is hardcoded:
https://github.com/torvalds/linux/blob/master/include/net/tcp.h#L120
and tcp_fin_timeout refers to a different state:
https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.txt#L294
One can relatively safely change the local port range to 1025-65535.
For kicks, if there were a situation where this client was talking to servers and network under my control, I would build a new kernel with a not-to-spec TCP_TIMEWAIT_LEN, and perhaps also fiddle with tcp_max_tw_buckets:
https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.txt#L379
But doing so in other circumstances- if this client is behind a NAT and talking to common public servers- will likely be disruptive.

honeyd: ip-open: operation not permitted

I want to Use honeyd to setup a virtual host with the following specification:
• Operating System: Linux
• Ethernet MAC Address: 00:00:24:22:8c:14
• IP Address: 10.10.10.2
• Open Ports: 22
so I instlled honeyd on ubuntu 1204 vm; then changed etc/honeypot/honeyd.conf as below:
create default
set default default tcp action block
set default default udp action block
set default default icmp action block
create linux
set linux personality "Linux 2.4.20"
set linux default tcp action reset
add linux tcp port 22 open
set linux ethernet "00:00:24:22:8c:14"
bind 10.10.10.2 linux
and the file honeyd.conf in etc/default/ like below:
RUN="yes"
INTERFACE= "eth0"
NETWORK= 10.10.10.2
OPTIONS="--disable-webserver"
when i run the honeyd using command : 'honeyd start'
sometimes it shows this error:
honeyd: ip-open: operation not permitted
and other times it shows this one:
honeyd: interface_expandips: Invalid network range: start
what should i do?
Thanks
If you run honeyd without sudo you will receive the first error message. The second one occurs when running it with sudo.
Looks like you didn't specify a network range in the config file at /etc/default. 10.10.10.2 is an IP address. Not a range. You probably want something like:
NETWORK= 10.10.10.0/24
in your config file,
my error removed after i changed my vmware nat dhcp setting. it is in tab edit>virtual network editor.. > nat> dhcp setting.
the range must include the ip address i want to use.
:)

Link aggregation and status of network interfaces in "ipadm" command

I am again rephrasing the issue that we are facing:
We are creating link aggregations [dlmp groups] with two interfaces named net0 & net5:
# dladm create-aggr -m dlmp -l net0 -l net5 -l net2 aggr1
Setting prob targets for aggr1:
# dladm set-linkprop -p probe-ip=+ aggr1
Setting failure detection time:
# dladm set-linkprop -p probe-fdt=15 aggr1
After this we are adding IP to this aggregation as follows:
# ipadm create-ip aggr1
Assigns an IP to this:
# ipadm create-addr -T static -a x.x.x.x/y aggr1/addr
Then we check the status using dladm and ipadm everything seems up and running.
Then we tested a scenario where we are dettached cables from above n/w interfaces, but what we got is as follows:
# dladm show-aggr -x
LINK PORT SPEED DUPLEX STATE ADDRESS PORTSTATE
traf0 -- 100Mb unknown up 0:10:e0:5b:69:1 --
net0 100Mb unknown down 0:10:e0:5b:69:1 attached
net5 100Mb unknown down a0:36:9f:45:de:9d attached
First issues is that we are getting the state of link "traf0" as up in above command output, secondly in the output of "ipadm":
traf0 ip ok -- --
traf0/addr static ok -- 7.8.0.199/16
We are getting the status of traf0 as ok.
So here I have a query, can't we have any configuration where we could get right status of traf0 both in dladm and ipadm output?
[One more thing to add here is, when we don't assign any IP to this traf0 aggregation then in that case on dettaching the cables we get right output in dladm command.]
Apart from this configuration, we are using these aggregations as vnics in zones. There also we are getting the status of these links up in ipadm command output [after dettaching the cables].
A small update::
We have set the value of "TRACK_INTERFACES_ONLY_WITH_GROUPS" parameter in /etc/default/mpathd as no and getting the state of "traf0" in ipadm command as failed, but still we get traf0/addr as ok.
traf0 ip failed -- --
traf0/addr static ok -- 7.8.0.199/16