Альтернативный вариант получения событий "/opt/etc/ndm/***"

[Ponywka]

Здравствуйте! В продолжение темы "Keenetic NDMS очищает IPTables во время запуска программы" хотел бы дополнить свои хотелки на счёт событий "/opt/etc/ndm/***".

Так получилось, что мой софт не является Bash скриптом, и чтобы ловить события "netfilter.d" - мне пришлось написать небольшой костыль, который тянет за собой пакет "socat" и с помощью него "пробрасывает" это событие в мою программу: https://github.com/MagiTrickle/MagiTrickle/blob/0cc26dd0762e69294476a173502068e3359cb2c3/opt/etc/ndm/netfilter.d/100-magitrickle

#!/bin/sh
SOCKET_PATH="/opt/var/run/magitrickle.sock"
[ -S "$SOCKET_PATH" ] || exit

BODY="{\"type\":\"$type\",\"table\":\"$table\"}"
LENGTH=$(printf "%s" "$BODY" | wc -c)

socat - UNIX-CONNECT:"$SOCKET_PATH" >/dev/null 2>&1 <<EOF
POST /api/v1/system/hooks/netfilterd HTTP/1.1
Host:
Content-Type: application/json
Content-Length: $LENGTH

$BODY
EOF

Очень хотелось бы обойтись без подобных костылей и вместо этого получать эти события по тем же UNIX-сокетам или же любым другим способом, удобным на команды разработки Keenetic NDMS.

Изменено 13 апреля пользователем Ponywka

[sergeyk]

1 час назад, Ponywka сказал:

Очень хотелось бы обойтись без подобных костылей и вместо этого получать эти события по тем же UNIX-сокетам или же любым другим способом, удобным на команды разработки Keenetic NDMS.

Вы сами можете это сделать, заменив bash-скрипты на собственные исполняемые файлы (или один исполняемый файл, на который указывают разные символические ссылки), которые будут в удобном для вас виде передавать нужным способом куда надо и аргументы запуска, и переменные окружения.

[Ponywka]

20 minutes ago, sergeyk said:

Вы сами можете это сделать, заменив bash-скрипты на собственные исполняемые файлы (или один исполняемый файл, на который указывают разные символические ссылки), которые будут в удобном для вас виде передавать нужным способом куда надо и аргументы запуска, и переменные окружения.

И чем это будет отличаться от socat который я описал выше?

Мне не нужно плодить новый процесс - мне нужно чтобы уже имеющийся мог знать о событиях!

[sergeyk]

4 минуты назад, Ponywka сказал:

И чем это будет отличаться от socat который я описал выше?

Технически ничем.

Какие тут могут быть ещё варианты?

[Ponywka]

1 minute ago, sergeyk said:

Какие тут могут быть ещё варианты?

 

1 hour ago, Ponywka said:

и вместо этого получать эти события по тем же UNIX-сокетам

 

[sergeyk]

1 минуту назад, Ponywka сказал:

и вместо этого получать эти события по тем же UNIX-сокетам

Что это принципиально изменит? Да, возможно передача одного сообщения станет чуть быстрее, но, поскольку поток событий от ndm невелик, заметного влияния на работу системы это не окажет.

[Ponywka]

2 minutes ago, sergeyk said:

Что это принципиально изменит? Да, возможно передача одного сообщения станет чуть быстрее, но, поскольку поток событий от ndm невелик, заметного влияния на работу системы это не окажет.

Ну как минимум не придется городить свои костыли для приёма таких сообщений

[sergeyk]

1 минуту назад, Ponywka сказал:

Ну как минимум не придется городить свои костыли для приёма таких сообщений

Со стороны ndm тоже не выглядит разумным держать несколько источников событий с разными форматами: кому-то нужен XML, кому-то JSON, кого-то устроит только собственный бинарный формат. Одним нужен UNIX domain, другим удаленное взаимодействие по TCP или UDP. Плюс всё это нужно документировать.

 

[Ponywka]

1 minute ago, sergeyk said:

кому-то нужен XML, кому-то JSON, кого-то устроит только собственный бинарный формат

Учитывая, что разработчики программы сами подцепляются к Keenetic NDMS - то они должны учитывать тот формат, который сам Keenetic и предоставляет. Главное документировать!

3 minutes ago, sergeyk said:

Одним нужен UNIX domain, другим удаленное взаимодействие по TCP или UDP

А зачем TCP/UDP в рамках одного устройства? Если нужно подцепляться удалённо, то пускай свой сервис пишут для этого, который будет оборачивать UNIX в TCP.

Но суть понял... Что-ж... Ладно

[sergeyk]

11 минут назад, Ponywka сказал:

Ну как минимум не придется городить свои костыли для приёма таких сообщений

Это не костыли, а следование официальному документированному API.

[Denis P]

4 минуты назад, sergeyk сказал:

Это не костыли, а следование официальному документированному API.

немного влезу, но попутно задам один вопрос, который тоже касается netfilter
каким-то образом можно инициализировать его перезапуск не трогая политики/интерфейсы/правила переадресации/мсэ и остальное что служит тригером для его перезапуска?
т.е грубо говоря вручную заставить перечитать скрипты которые лежат в netfilter.d не меняя параметры системы

[Александр Рыжов]

@Ponywka, почему способ с вызовом чего-либо в /opt/etc/ndm.d выглядит костыльным? Есть желание взаимодействовать с прошивкой без этой прослойки?

Вижу, что в самой прошивке аналогичным образом сделаны вызовы скриптов для ppp в /var/ppp.

[Le ecureuil]

В 13.04.2025 в 14:15, Denis P сказал:

немного влезу, но попутно задам один вопрос, который тоже касается netfilter
каким-то образом можно инициализировать его перезапуск не трогая политики/интерфейсы/правила переадресации/мсэ и остальное что служит тригером для его перезапуска?
т.е грубо говоря вручную заставить перечитать скрипты которые лежат в netfilter.d не меняя параметры системы

Разве что руками их дернуть. Или у вас есть ситуация, что после старта opkg netfilter.d не вызывается ни разу?

[Le ecureuil]

Вариант с socat вполне себе unix-way и работает как задумано. Не вижу тут никакого "костыля".

[Denis P]

52 минуты назад, Le ecureuil сказал:

Разве что руками их дернуть. Или у вас есть ситуация, что после старта opkg netfilter.d не вызывается ни разу?

В основном это ситуация при разворачивании "офлайн" инсталера с уже готовым набором пакетов и скриптами

Т.е приходится дергать интерфейс чтобы подхватилось из netfilter.d. не сказать что это прям создает сильный дискомфорт, но если есть какой-то вариант этого не делать, кроме ручного запуска скриптов, было бы удобнее)

[Le ecureuil]

16 минут назад, Denis P сказал:

В основном это ситуация при разворачивании "офлайн" инсталера с уже готовым набором пакетов и скриптами

Т.е приходится дергать интерфейс чтобы подхватилось из netfilter.d. не сказать что это прям создает сильный дискомфорт, но если есть какой-то вариант этого не делать, кроме ручного запуска скриптов, было бы удобнее)

Тогда комбинация из
> opkg no disk
> opkg disk XXX
будет самой правильной, как мне кажется.

[Denis P]

3 часа назад, Le ecureuil сказал:

Тогда комбинация из
> opkg no disk
> opkg disk XXX
будет самой правильной, как мне кажется.

к сожалению не работает 

проверил на 4.3.0

тут же сделал down/up случайному интерфейсу и скрипты из netfilter.d обработались

Изменено Пятница в 20:27 пользователем Denis P

[Le ecureuil]

16 часов назад, Denis P сказал:

к сожалению не работает 

проверил на 4.3.0

тут же сделал down/up случайному интерфейсу и скрипты из netfilter.d обработались

Это другое дело, спасибо за репорт, проверим. Так быть не должно - все скрипты должны вызваться хотя бы раз после первого запуска.

[Le ecureuil]

Поправлено, будет в следующей 4.3.