c2devel / c2-ec2-netutils Goto Github PK

Behavior change in grep 3.8 causes netutils scripts to malfunction

In version 3.8 grep was migrated to PCRE2 according to this commit:
e0d39a9133e1507345d73ac5aff85f037f39aa54 https://git.savannah.gnu.org/cgit/grep.git/

In pcre2 any alpha-numeric character preceded by a backslash is treated as a character or sequence with a special meaning. In the case where the sequence has not been defined to be special, an error occurs. This seems to be different from pcre, where the error does not occur and the backslash is ignored.

This behavior change affects some grep -P commands in netutils scripts and even in dpkg scripts.
Examples are:

• c2-ec2-netutils/DEBIAN/postinst

  Line 3 in 219a9f7

  release=$(grep -P '^\ID=' /etc/os-release | tr -d 'ID=')

• c2-ec2-netutils/ec2ifscan

  Line 13 in 219a9f7

  release=$(grep -P '^\ID=' /etc/os-release | tr -d 'ID=')

grep returns the following error:

# grep -P '^\ID=' /etc/os-release
grep: unrecognized character follows \

It looks like the backslash in this case were not needed and now it even causes an error.

grep version: grep (GNU grep) 3.8 on Ubuntu 23.04 (Lunar Lobster)

Route policy rules are not added on boot in debian-like distros.

Having route policy rules configured is vital for instances with multiple network interfaces, because rules specify which routing table will be used for sending response traffic based on dst ip of incoming traffic. If route policy rules are not configured, traffic coming to all interfaces is being sent through the primary interface according to default route in main table, and this leads to a lack of connectivity.

Expected behavior:
Route policy rules for non-primary interfaces are being added on boot.

Actual behavior:
Route policy rules are not added.

This behavior is caused by udev rule running script for adding route policy rules before the primary interface is configured. Primary interface should be configured before the script runs, because script relies on EC2 metadata, which is not available unless primary interface is up.

On systems with the initscripts package controlling the network, such as RHEL 7, it was normal to use proto kernel in routes in the configurations /etc/sysconfig/network-scripts/route-*, because they were used literally by network initscript. On systems with NetworkManager, these configurations are interpreted by the ifcfg-rh plugin, and it seems to not allow specificproto and instead prefers nothing (which means the static proto will be used).

c2-ec2-netutils for rhel generate route configs with routes with proto kernel in them.

This causes a warning on RHEL8-9:

NetworkManager[756]: <warn>  [1685325176.7685] ifcfg-rh:     ignoring invalid route at "        10.222.16.0/20 dev eth1 proto kernel scope link src 10.222.16.4 table 10001" (/etc/sysconfig/network-scripts/route-eth1:2): Unrecognized argument ("to" is duplicate or "proto" is garbage)

And routes are applied with proto static:

~# ip r s t 10001
default via 10.222.16.1 dev eth1 proto static metric 104 
10.222.16.1 dev eth1 proto static scope link metric 104 
~#

On Fedora 38 (aka RHEL 10) this causes the same warning:

NetworkManager[541]: <warn>  [1685325497.1294] ifcfg-rh:     ignoring invalid route at "        10.222.16.0/20 dev eth1 proto kernel scope link src 10.222.16.4 table 10001" (/etc/sysconfig/network-scripts/route-eth1:2): Unrecognized argument ("to" is duplicate or "proto" is garbage)

But the routes are not applied at all:

~# ip r s t 10001
default via 10.222.16.1 dev eth1 proto static metric 104 
~#

Route tables for non-primary interfaces are not added on Debian 11

In PR #1 support for Debian 11 were introduced.
Everything works like on previous Debian versions, except for one thing -- script fails to add different route table numbers in different interface configs for network scripts.

Expected behavior:
Scripts generate configs for interfaces and use different route table numbers for interface specific routes.

Actual behaviour:
Scripts generate configs for interfaces and use the same route table with number 10000

This behavior is caused by a bug in the following if

It ensures that a unique route table number is used based on the interface name.
Since Debian 11 uses the ens* interface naming, this code does not generate a routing table number.