Всем привет.

Столкнулся с забавным эффектом, при создании зеркала репозитория встроенными в восьмерку средствами, aka reposync: репозиторий вытягивается, метадата присутствует, однако количество файлов меньшее, чем в оригинальной репе.

Например:

dnf reposync --delete --remote-time --download-metadata -p ${dest_path} --repo=BaseOS

Зеркалируется, но не выкачивает 509 файлов, если сравнить с оригиналом.

Если указать архитектуру, к примеру --arch=x86_64, то вдобавок будут пропущены пакеты без указания архитектуры а-ля ****.el8.noarch.rpm.

Есть подозрения, что фиговничают новомодно-молодежные модули, которые теперь вместе с dnf идут, однако найти информацию по настройке их совместно с reposync у меня не получилось.

Сталкивался кто?

Требуется завернуть маркированный через Netfilter трафик на клиенте завернуть в туннель к серверу, а остальной пустить по default маршруту.

Имеется:

• Клиент - gateway маленькой сети на Centos
• Сервер - Облачный шлюз - на Centos

1. Сервер, с поднятым туннелем:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:2d:70:4a brd ff:ff:ff:ff:ff:ff
    inet 16.124.9.234/32 brd 51.38.50.121 scope global dynamic eth0
       valid_lft 60677sec preferred_lft 60677sec
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.8.0.1/24 scope global wg0
       valid_lft forever preferred_lft forever

wg0 - порт wireguard туннеля

2. Клиент с поднятым подключением:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 38:d5:47:28:4d:e2 brd ff:ff:ff:ff:ff:ff
    inet 10.204.163.19/30 brd 10.204.163.19 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether ca:b2:ad:cd:81:5f brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.8.0.100/32 scope global wg0
       valid_lft forever preferred_lft forever

eth0 - внешняя сеть eth1 - внутренняя сеть wg0 - порт wireguard туннеля

3. Модуль ядра для маркировки пакетов на клиенте - загружен:

# lsmod | grep -i "mark"
xt_mark                16384  1

4. Параметры ядра на клиенте:

• влючен форвардинг
• отключен rpfilter - что бы ядро, не отбрасывало пакеты, вернувшиеся с другого интерфейса

# sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.tcp_fwmark_accept = 1
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0

5. Пакеты в ядре клиента маркируются простым правилом:

iptables -A PREROUTING -t mangle -s 192.168.1.222 -j MARK --set-mark 1

6. Добавлено правило на клиенте - создана таблица wire для маркированного трафика:

ip rule add fwmark 1 table wire

7. Требуется прописать маршрут для пакетов из таблицы wire в интерфейс wg0

• Внутрення сеть: 192.168.0.0/24
• Адреса в туннеле: 1.8.0.0/24

Самоизоляционный тупняк на меня напал - спасайте.

Привет всем.

{drama mode is on} Все начиналось как обычно: «Давайте развернем тестовый стенд на докере - ну шо нам мешает??!»

По итогу внезапно оказалось (ну кто бы мог подумать), что тестируемые приложения запускаются в нескольких количествах на каждой ноде и для изоляции используют cgroups + функционал systemd. {drama mode is off}

Запустить кастрированный вариант системд в контейнере - получилось, благо есть гайды, да и тут тема поднималась не раз (спойлер: systemd в docker ). Юниты монитарятся, логи пишутся, однако дальше все стало печально - никакой изоляции внутри контейнера не получить ввиду монтирования с хоста /sys/fs/cgroup в режиме только чтения.

{holywar mode is on} Да, знаю, один контейнер на один сервис, но все таки. Да, используем не по назначению. Нет, KVM не подойдет. Нет, разделить на несколько контейнеров нельзя - не подходит для деплоя тестового окружения. {holywar mode is off}

Может кто уже получал этими же граблями по лбу и знает что выход {есть|нет} ? (нужное подчеркнуть)