MT#57371 drop dependency on iptables

As we now natively support nftables, we no longer need to rely on the
iptables helper script. We can completely remove it.

Change-Id: I214bfee6ada534754141cb86bb50e87556de977d
pull/1747/head
Richard Fuchs 2 years ago
parent b2ff4cc03f
commit 979a3c09ad

1
debian/control vendored

@ -68,7 +68,6 @@ Pre-Depends:
adduser,
${misc:Pre-Depends},
Depends:
iptables,
sysvinit-utils (>= 3.05-4~) | lsb-base (>= 3.0-6),
${misc:Depends},
${shlibs:Depends},

@ -75,14 +75,6 @@ case "$1" in
esac
fi
RC=0
ngcp-rtpengine-iptables-setup start || RC=$?
if [ "$RC" -ne 0 ]; then
log_action_msg "Failed to start ngcp-rtpengine-iptables-setup"
log_end_msg "$RC"
exit 1
fi
log_daemon_msg "Starting $DESC" "$NAME"
# shellcheck disable=SC2086
start-stop-daemon --start --quiet --pidfile "$PIDFILE" \
@ -94,9 +86,6 @@ case "$1" in
RC=0
start-stop-daemon --oknodo --stop --quiet --pidfile "$PIDFILE" \
--retry 5 --exec "$DAEMON" || RC=$?
if [ "$RC" -eq 0 ]; then
ngcp-rtpengine-iptables-setup stop || true
fi
rm -f "$PIDFILE"
log_end_msg "$RC"
exit "$RC"

@ -1,3 +1,2 @@
debian/ngcp-rtpengine-iptables-setup /usr/sbin
etc/rtpengine.conf /etc/rtpengine/
usr/bin/rtpengine

@ -1,2 +1 @@
debian/ngcp-rtpengine-iptables-setup.1
usr/share/man/man8/rtpengine.8

@ -1,142 +0,0 @@
#!/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MODNAME=xt_RTPENGINE
MANAGE_IPTABLES=yes
DEFAULTS=/etc/default/ngcp-rtpengine-daemon
# Load startup options if available
if [ -f "$DEFAULTS" ]; then
. "$DEFAULTS" || true
fi
MODPROBE_OPTIONS=""
TABLE=$(/usr/libexec/rtpengine/rtpengine-get-table --config-file="${CONFIG_FILE-/etc/rtpengine/rtpengine.conf}")
# Handle requested setuid/setgid.
if ! test -z "$SET_USER"; then
PUID=$(id -u "$SET_USER" 2> /dev/null)
test -z "$PUID" || MODPROBE_OPTIONS="$MODPROBE_OPTIONS proc_uid=$PUID"
if test -z "$SET_GROUP"; then
PGID=$(id -g "$SET_USER" 2> /dev/null)
test -z "$PGID" || MODPROBE_OPTIONS="$MODPROBE_OPTIONS proc_gid=$PGID"
fi
fi
if ! test -z "$SET_GROUP"; then
PGID=$(grep "^$SET_GROUP:" /etc/group | cut -d: -f3 2> /dev/null)
test -z "$PGID" || MODPROBE_OPTIONS="$MODPROBE_OPTIONS proc_gid=$PGID"
fi
if ! test -z "$SET_MASK"; then
MODPROBE_OPTIONS="$MODPROBE_OPTIONS proc_mask=$SET_MASK"
fi
###
if [ -x "$(which ngcp-virt-identify 2>/dev/null)" ]; then
if ngcp-virt-identify --type container; then
VIRT="yes"
fi
fi
firewall_setup()
{
if [ -z "$TABLE" ] || [ "$TABLE" -lt 0 ] || [ "$VIRT" = "yes" ]; then
return
fi
if [ "$MANAGE_IPTABLES" != "yes" ]; then
return
fi
# shellcheck disable=SC2086
modprobe $MODNAME $MODPROBE_OPTIONS
iptables -N rtpengine 2>/dev/null
iptables -D INPUT -j rtpengine 2>/dev/null
iptables -D INPUT -p udp -j rtpengine 2>/dev/null
iptables -I INPUT -p udp -j rtpengine
iptables -D rtpengine -p udp -j RTPENGINE --id "$TABLE" 2>/dev/null
iptables -I rtpengine -p udp -j RTPENGINE --id "$TABLE"
ip6tables -N rtpengine 2>/dev/null
ip6tables -D INPUT -j rtpengine 2>/dev/null
ip6tables -D INPUT -p udp -j rtpengine 2>/dev/null
ip6tables -I INPUT -p udp -j rtpengine
ip6tables -D rtpengine -p udp -j RTPENGINE --id "$TABLE" 2>/dev/null
ip6tables -I rtpengine -p udp -j RTPENGINE --id "$TABLE"
}
firewall_teardown()
{
if [ -z "$TABLE" ] || [ "$TABLE" -lt 0 ] || [ "$VIRT" = "yes" ]; then
return
fi
# The daemon might take a little while to stop: keep trying to remove the
# table until we can.
for _ in $(seq 1 10); do
TABLE_REMOVE_SUCCESS=true
if [ ! -e /proc/rtpengine/control ]; then
break
fi
if [ ! -d /proc/rtpengine/"$TABLE" ]; then
break
fi
if echo "del $TABLE" >/proc/rtpengine/control 2>/dev/null; then
break
fi
TABLE_REMOVE_SUCCESS=false
sleep 0.1
done
if ! $TABLE_REMOVE_SUCCESS; then
echo "Failed to remove the iptables kernel table after shutdown of rtpengine." >&2
return
fi
if [ "$MANAGE_IPTABLES" != "yes" ]; then
return
fi
iptables -D rtpengine -p udp -j RTPENGINE --id "$TABLE" 2>/dev/null
ip6tables -D rtpengine -p udp -j RTPENGINE --id "$TABLE" 2>/dev/null
# The module refcount might also be delayed going to zero.
for _ in $(seq 1 10); do
MODULE_UNLOAD_SUCCESS=true
if ! lsmod | grep -q "$MODNAME"; then
break
fi
if rmmod "$MODNAME"; then
break
fi
MODULE_UNLOAD_SUCCESS=false
sleep 0.1
done
if ! $MODULE_UNLOAD_SUCCESS; then
echo "Failed to unload the kernel module $MODNAME." >&2
fi
}
case "$1" in
start)
firewall_setup
;;
stop)
firewall_teardown
;;
*)
echo "Usage: $0 {start|stop}" >&2
exit 1
;;
esac
exit 0

@ -1,16 +0,0 @@
.TH man 1 "17 May 2022" "1.0" "ngcp-rtpengine-iptables-setup man page"
.SH NAME
ngcp\-rtpengine\-iptables\-setup \- manages iptables rules for ngcp\-rtpengine\-daemon service
.SH SYNOPSIS
ngcp\-rtpengine\-iptables\-setup [start|stop]
.SH DESCRIPTION
ngcp\-rtpengine\-iptables\-setup will enable or disable the iptables rules needed by rtpengine to properly work.
This program will be called by ngcp\-rtpengine\-daemon service.
.SH OPTIONS
ngcp\-rtpengine\-iptables\-setup has no options.
.SH SEE ALSO
rtpengine(8)
.SH BUGS
No known bugs.
.SH AUTHOR
Victor Seva (vseva@sipwise.com)

@ -24,21 +24,22 @@ For these reasons, *rtpengine* provides a kernel module to offload the bulk of t
duties from user space to kernel space. Using this technique, a large percentage of the overhead can be
eliminated, CPU usage greatly reduced and the number of concurrent calls possible to be handled increased.
In-kernel packet forwarding is implemented as an *iptables* module
(or more precisely, an *x\_tables* module). As such, it comes in two parts, both of
which are required for proper operation. One part is the actual kernel module called `xt_RTPENGINE`. The
second part is a plugin to the `iptables` and `ip6tables` command-line utilities to make it possible to
actually add the required rule to the tables.
In-kernel packet forwarding is implemented as an *nftables* module
(or more precisely, an *x\_tables* module). As such, it requires two parts
for proper operation. One part is the actual kernel module called
`xt_RTPENGINE`. The second part is a rule in the local *nftables* chains that
gets hit by UDP packets so that they can be processed by the kernel module.
### Overview ###
In short, the prerequisites for in-kernel packet forwarding are:
1. The `xt_RTPENGINE` kernel module must be loaded.
2. An `iptables` and/or `ip6tables` rule must be present in the `INPUT` chain (or in a custom user-defined
chain which is then called by the `INPUT` chain) to send packets
1. The `xt_RTPENGINE` kernel module must be loaded. The module supports
auto-loading when correctly installed.
2. A rule added to an *nftables* chain that gets called by an *input* hook in
the *filter* table, which sends packets
to the `RTPENGINE` target. This rule should be limited to UDP packets, but otherwise there
are no restrictions.
are no restrictions. The *rtpengine* daemon manages creation and deletion of this rule.
3. The `rtpengine` daemon must be running.
4. All of the above must be set up with the same forwarding table ID (see below).
@ -49,7 +50,7 @@ The sequence of events for a newly established media stream is then:
based on the info received
from the SIP proxy. Only userspace forwarding is set up, nothing is pushed to the kernel module yet.
3. An RTP packet is received on the local port.
4. It traverses the *iptables* chains and gets passed to the *xt\_RTPENGINE* module.
4. It traverses the *nftables* chains and gets passed to the *xt\_RTPENGINE* module.
5. The module doesn't recognize it as belonging to an established stream and thus ignores it.
6. The packet continues normal processing and eventually ends up in the daemon's receive queue.
7. The daemon reads it, processes it and forwards it. It also updates some internal data.
@ -61,13 +62,13 @@ The sequence of events for a newly established media stream is then:
and will forward them on its own. It will stop those packets from traversing the network stacks any
further, so the daemon will not see them any more on its receive queues.
11. In-kernel forwarding is allowed to cease to work at any given time, either accidentally (e.g. by
removal of the *iptables* rule) or deliberately (the daemon will do so in case of a re-invite), in which
removal of the *nftables* rule) or deliberately (the daemon will do so in case of a re-invite), in which
case forwarding falls back to userspace-only operation.
### The Kernel Module ###
The kernel module supports multiple forwarding tables (not to be confused with the tables managed
by *iptables*), which are identified through their ID number. By default, up to 64 forwarding tables
by *nftables*), which are identified through their ID number. By default, up to 64 forwarding tables
can be created and used, giving them the ID numbers 0 through 63.
Each forwarding table can be thought of a separate proxy instance. Each running instance of the
@ -75,7 +76,16 @@ Each forwarding table can be thought of a separate proxy instance. Each running
running instance of the daemon at any given time. In the most common setup, there will be only a single
instance of the daemon running and there will be only a single forwarding table in use, with ID zero.
The kernel module can be loaded with the command `modprobe xt_RTPENGINE`. With the module loaded, a new
The kernel module can be loaded with the command `modprobe xt_RTPENGINE`. It
isn't normally necessary to do this explicitly or manually as the module is
automatically loaded when the appropriate *nftables* rule is created (see
below). The module supports a few options (see `modinfo -p xt_RTPENGINE`) which
can either be set at the `modprobe` command line, and/or through an entry in
`/etc/modprobe.d/` (by default `/etc/modprobe.d/rtpengine.conf`) for options to
be set when auto-loading the module. Options can be inspected during runtime
via `/sys/module/xt_RTPENGINE/parameters/`.
With the module loaded, a new
directory will appear in `/proc/`, namely `/proc/rtpengine/`. After loading, the directory will contain
only two pseudo-files, `control` and `list`. The `control` file is write-only and is used to create and
delete forwarding tables, while the `list` file is read-only and will produce a list of currently
@ -84,7 +94,7 @@ active forwarding tables. With no tables active, it will produce an empty output
The `control` pseudo-file supports two commands, `add` and `del`, each followed by the forwarding table
ID number. To manually create a forwarding table with ID 42, the following command can be used:
echo 'add 42' > /proc/rtpengine/control
echo 'add 42' > /proc/rtpengine/control
After this, the `list` pseudo-file will produce the single line `42` as output. This will also create a
directory called `42` in `/proc/rtpengine/`, which contains additional pseudo-files to control this
@ -107,72 +117,106 @@ deletion of tables may be required after shutdown of the daemon or before a rest
daemon can create the table it wants to use.
The kernel module can be unloaded through `rmmod xt_RTPENGINE`, however this only works if no forwarding
table currently exists and no *iptables* rule currently exists.
### The *iptables* module ###
In order for the kernel module to be able to actually forward packets, an *iptables* rule must be set up
to send packets into the module. Each such rule is associated with one forwarding table. In the simplest case,
for forwarding table 42, this can be done through:
table currently exists and no *nftables* rule currently exists.
### The *nftables* Rule ###
In order for the kernel module to be able to actually forward packets, an
*nftables* rule must be set up to send packets into the module. Previously
these rules were managed via the `iptables` and `ip6tables` CLI tools (in
combination with a plugin module, e.g. via a command such as `iptables -I INPUT
-p udp -j RTPENGINE --id 42`), but with *iptables* being phased out and
replaced by *nftables* this is no longer necessary.
The *rtpengine* daemon manages creation and deletion of the required *nftables*
rules directly, creating them during startup and deleting them during
shutdown. The location of the rules and the names of the chains can be
configured via the options `nftables-chain` and `nftables-base-chain` (see
manual page).
_NOTE: As the `nft` command-line tool isn't able to understand the non-standard
`RTPENGINE` target rules, it may emit a warning when displaying the rules via
`nft list ruleset` or similar._
The rules can also be managed explicitly and directly from the command line via
the `\-\-nftables-start` and `\-\-nftables-stop` options (see manual page).
This is useful to manage these rules from a script if so desired, or to
re-create them during runtime if they had gotten lost.
A typical output from `nft list ruleset` with a rule loaded may look like this
(including the aforementioned warning message):
# Warning: table ip filter is managed by iptables-nft, do not touch!
table ip filter {
chain INPUT {
type filter hook input priority filter; policy accept;
ip protocol udp counter packets 1 bytes 201 jump rtpengine
}
chain rtpengine {
XT target RTPENGINE not found
counter packets 1 bytes 201
}
}
iptables -I INPUT -p udp -j RTPENGINE --id 42
## Summary
If IPv6 traffic is expected, the same should be done using `ip6tables`.
In a typical setup no extra steps need to be taken to facilitate in-kernel forwarding, provided the kernel module is compiled and installed for the currently running kernel (which should be handled by `dkms` on compatible systems).
It is possible but not strictly
necessary to restrict the rules to the UDP port range used by *rtpengine*, e.g. by supplying a parameter
like `--dport 30000:40000`. If the kernel module receives a packet that it doesn't recognize as belonging
to an active media stream, it will simply ignore it and hand it back to the network stack for normal
processing.
A cheat sheet with various related commands is below:
The `RTPENGINE` rule need not necessarily be present directly in the `INPUT` chain. It can also be in a
user-defined chain which is then referenced by the `INPUT` chain, like so:
# Load module: this only needs to be done once after system
# (re-) boot, but can be omitted if auto-load is working correctly
modprobe xt_RTPENGINE
iptables -N rtpengine
iptables -I INPUT -p udp -j rtpengine
iptables -I rtpengine -j RTPENGINE --id 42
# Load module with some options set
# (usually handled via /etc/modprobe.d/rtpengine.conf)
modprobe xt_RTPENGINE proc_uid=1234 proc_gid=5678
This can be a useful setup if certain firewall scripts are being used.
# Create nftables rules: This normally happens automatically during
# startup. Kernel table ID and nftables chain names are taken from
# the config file
rtpengine --nftables-start
## Summary
# Create nftables rules overriding the default chain names, or the
# names from the config file
rtpengine --nftables-start --table=42 --nftables-chain=foobar --nftables-base-chain=
A typical start-up sequence including in-kernel forwarding might look like this:
# Delete a leftover table. Might be needed if the kernel module
# can't be unloaded (see /proc/rtpengine/list)
echo 'del 0' > /proc/rtpengine/control
# this only needs to be done once after system (re-) boot
modprobe xt_RTPENGINE
iptables -I INPUT -p udp -j RTPENGINE --id 0
ip6tables -I INPUT -p udp -j RTPENGINE --id 0
# Start daemon: this creates the nftables rules for table 0
/usr/bin/rtpengine --table=0 --interface=10.64.73.31 --interface=2001:db8::4f3:3d \
--listen-ng=127.0.0.1:2223 --tos=184 --pidfile=/run/rtpengine.pid --no-fallback
# ensure that the table we want to use doesn't exist - usually needed after a daemon
# restart, otherwise will error
echo 'del 0' > /proc/rtpengine/control
# start daemon
/usr/bin/rtpengine --table=0 --interface=10.64.73.31 --interface=2001:db8::4f3:3d \
--listen-ng=127.0.0.1:2223 --tos=184 --pidfile=/run/rtpengine.pid --no-fallback
# Start daemon without implicitly creating any nftables rules (empty chain name)
/usr/bin/rtpengine --table=0 --interface=10.64.73.31 --interface=2001:db8::4f3:3d \
--listen-ng=127.0.0.1:2223 --tos=184 --pidfile=/run/rtpengine.pid --no-fallback \
--nftables-chain=
## Running Multiple Instances
In some cases it may be desired to run multiple instances of *rtpengine* on the same machine, for example
if the host is multi-homed and has multiple usable network interfaces with different addresses. This is
supported by running multiple instances of the daemon using different command-line options (different
local addresses and different listening ports), together with
multiple different kernel forwarding tables.
In some cases it may be desired to run multiple instances of *rtpengine* on the
same machine, for example if the host is multi-homed and has multiple usable
network interfaces with different addresses and different port ranges. This is
supported by running multiple instances of the daemon using different
command-line options (different local addresses and different listening ports)
or different config files, together with multiple different kernel forwarding
tables.
For example, if one local network interface has address 10.64.73.31 and another has address 192.168.65.73,
then the start-up sequence might look like this:
modprobe xt_RTPENGINE
iptables -I INPUT -p udp -d 10.64.73.31 -j RTPENGINE --id 0
iptables -I INPUT -p udp -d 192.168.65.73 -j RTPENGINE --id 1
echo 'del 0' > /proc/rtpengine/control
echo 'del 1' > /proc/rtpengine/control
/usr/bin/rtpengine --table=0 --interface=10.64.73.31 \
--listen-ng=127.0.0.1:2223 --tos=184 --pidfile=/run/rtpengine-10.pid --no-fallback
/usr/bin/rtpengine --table=1 --interface=192.168.65.73 \
--listen-ng=127.0.0.1:2224 --tos=184 --pidfile=/run/rtpengine-192.pid --no-fallback
/usr/bin/rtpengine --config-file=none --table=0 --interface=10.64.73.31 \
--listen-ng=127.0.0.1:2223 --tos=184 --pidfile=/run/rtpengine-10.pid --no-fallback
/usr/bin/rtpengine --config-file=none --table=1 --interface=192.168.65.73 \
--listen-ng=127.0.0.1:2224 --tos=184 --pidfile=/run/rtpengine-192.pid --no-fallback
With this setup, the SIP proxy can choose which instance of *rtpengine* to talk to and thus which local
interface to use by sending its control messages to either port 2223 or port 2224.
For ease of use it's recommended to use multiple config files
(`\-\-config-file=...`) or config file sections (`\-\-config-section=...`)
instead. When running under *systemd* a new service unit can be created via
`systemctl edit ...`.

@ -1,101 +0,0 @@
#!/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MODNAME=xt_RTPENGINE
MANAGE_IPTABLES=yes
DEFAULTS=/etc/sysconfig/rtpengine
# Load startup options if available
if [ -f "$DEFAULTS" ]; then
. "$DEFAULTS" || true
fi
TABLE=$(/usr/sbin/rtpengine-get-table --config-file="${CONFIG_FILE-/etc/rtpengine/rtpengine.conf}")
MODPROBE_OPTIONS=""
# Handle requested setuid/setgid.
if ! test -z "$SET_USER"; then
PUID=$(id -u "$SET_USER" 2> /dev/null)
test -z "$PUID" || MODPROBE_OPTIONS="$MODPROBE_OPTIONS proc_uid=$PUID"
if test -z "$SET_GROUP"; then
PGID=$(id -g "$SET_USER" 2> /dev/null)
test -z "$PGID" || MODPROBE_OPTIONS="$MODPROBE_OPTIONS proc_gid=$PGID"
fi
fi
if ! test -z "$SET_GROUP"; then
PGID=$(grep "^$SET_GROUP:" /etc/group | cut -d: -f3 2> /dev/null)
test -z "$PGID" || MODPROBE_OPTIONS="$MODPROBE_OPTIONS proc_gid=$PGID"
fi
###
if [ -x "$(which ngcp-virt-identify 2>/dev/null)" ]; then
if ngcp-virt-identify --type container; then
VIRT="yes"
fi
fi
firewall_setup()
{
if [ "$TABLE" -lt 0 ] || [ "$VIRT" = "yes" ]; then
return
fi
if [ "$MANAGE_IPTABLES" != "yes" ]; then
return
fi
# shellcheck disable=SC2086
modprobe $MODNAME $MODPROBE_OPTIONS
iptables -N rtpengine 2>/dev/null
iptables -D INPUT -j rtpengine 2>/dev/null
iptables -D INPUT -p udp -j rtpengine 2>/dev/null
iptables -I INPUT -p udp -j rtpengine
iptables -D rtpengine -p udp -j RTPENGINE --id "$TABLE" 2>/dev/null
iptables -I rtpengine -p udp -j RTPENGINE --id "$TABLE"
ip6tables -N rtpengine 2>/dev/null
ip6tables -D INPUT -j rtpengine 2>/dev/null
ip6tables -D INPUT -p udp -j rtpengine 2>/dev/null
ip6tables -I INPUT -p udp -j rtpengine
ip6tables -D rtpengine -p udp -j RTPENGINE --id "$TABLE" 2>/dev/null
ip6tables -I rtpengine -p udp -j RTPENGINE --id "$TABLE"
}
firewall_teardown()
{
if [ "$TABLE" -lt 0 ] || [ "$VIRT" = "yes" ]; then
return
fi
# XXX: Wait a bit to make sure the daemon has been stopped.
sleep 1
if [ -e /proc/rtpengine/control ]; then
echo "del $TABLE" >/proc/rtpengine/control 2>/dev/null
fi
if [ "$MANAGE_IPTABLES" != "yes" ]; then
return
fi
iptables -D rtpengine -p udp -j RTPENGINE --id "$TABLE" 2>/dev/null
ip6tables -D rtpengine -p udp -j RTPENGINE --id "$TABLE" 2>/dev/null
}
case "$1" in
start)
firewall_setup
;;
stop)
firewall_teardown
;;
*)
echo "Usage: $0 {start|stop}" >&2
exit 1
;;
esac
exit 0

@ -13,9 +13,7 @@ CapabilityBoundingSet=CAP_NET_ADMIN CAP_SYS_NICE
LimitNOFILE=150000
RuntimeDirectory=rtpengine
PIDFile=/run/rtpengine/rtpengine.pid
ExecStartPre=+/usr/sbin/ngcp-rtpengine-iptables-setup start
ExecStart=/usr/bin/rtpengine --config-file=${CFG_FILE} --pidfile=${PID_FILE}
ExecStopPost=+/usr/sbin/ngcp-rtpengine-iptables-setup stop
RestartSec=3s
TimeoutSec=15s
Restart=on-failure

@ -38,14 +38,10 @@ The Sipwise NGCP rtpengine is a proxy for RTP traffic and other UDP based
media traffic. It's meant to be used with the Kamailio SIP proxy and forms a
drop-in replacement for any of the other available RTP and media proxies.
%if 0%{?rhel} < 7
%define iptables_ipv6 1
%endif
%package kernel
Summary: NGCP rtpengine in-kernel packet forwarding
Group: System Environment/Daemons
BuildRequires: gcc make redhat-rpm-config iptables-devel
Requires: iptables %{?iptables_ipv6:iptables-ipv6}
Requires: %{name}%{?_isa} = %{version}-%{release}
Requires: %{name}-dkms = %{version}-%{release}
@ -128,8 +124,6 @@ install -D -p -m755 recording-daemon/%{binname}-recording %{buildroot}%{_bindir}
%if 0%{?has_systemd_dirs}
install -D -p -m644 el/%{binname}.service \
%{buildroot}%{_unitdir}/%{binname}.service
install -D -p -m755 el/ngcp-rtpengine-iptables-setup \
%{buildroot}%{_sbindir}/ngcp-rtpengine-iptables-setup
%else
install -D -p -m755 el/%{binname}.init \
%{buildroot}%{_initrddir}/%{name}
@ -240,8 +234,6 @@ true
# init.d script and configuration file
%if 0%{?has_systemd_dirs}
%{_unitdir}/%{binname}.service
# Systemd iptables setup
%{_sbindir}/ngcp-rtpengine-iptables-setup
%else
%{_initrddir}/%{name}
%endif

Loading…
Cancel
Save