Я надаю сценарій, який слухає сигнали dbus, що дозволить вам реагувати швидше, ніж якби ви опитувались на зміни вашої поточної конфігурації мережі. Це допомагає в системах, де сценарії / etc / не виконуються тоді, коли ви хотіли б їх (як у моїй системі 14.04).
мої вхідні / вихідні гачки.d не працюють
NetworkManager запускає dhclient з прапора, -sf /usr/lib/NetworkManager/nm-dhcp-client.action
який, здається, перекриває нормальну поведінку гачка введення / виходу. Типовою поведінкою для dhclient є виклик сценаріїв в /etc/dhcp/dhclient-{enter,exit}-hooks.d
. Тих, хто взагалі не дзвонить у мою систему.
мої сценарії NetworkManager discher.dd також не працюють
Однак НМ використовує інший набір сценаріїв /etc/NetworkManager/dispatcher.d
для інформування про різні події. Довідкова сторінка NetworkManager (8) визначає dhcp4-change
та dhcp6-change
дії, які, здавалося б, роблять саме те, що ви хочете. Незважаючи на те, що написано на сторінці, принаймні, у моїй системі, тільки up
і down
дії викликаються. Я не можу змусити цих сценаріїв запустити щось інше. Тому це не є великим способом моніторингу змін ІР.
таким чином, прослуховуйте безпосередньо на dbus-сигнали, що випромінюються NM
nm-dhcp-client.action
( джерело ) з командного рядка просто перетворює всі змінні середовища, встановлені dhclient, у сигнал dbus. Ці змінні середовища визначені в man dhclient-script
(8). Особливий інтерес викликає $new_ip_address
. Що ви можете зробити, як пропонує @Bernhard, - це контролювати сигнал та діяти відповідно до його вмісту.
Ось програма, яка буде переносити всі дані про події, передані цим бінарним файлом:
#!/bin/bash -e
#
# This script listens for the org.freedesktop.nm_dhcp_client signal.
# The signal is emitted every time dhclient-script would execute.
# It has the same contents as the environment passed to
# dhclient-script (8). Refer to manpage for variables of interest.
#
# "org.freedesktop.nm_dhcp_client" is an undocumented signal name,
# as far as I could tell. it is emitted by nm-dhcp-client.action,
# which is from the NetworkManager package source code.
#
# detail: todo cleanup subprocess on exit. if the parent exits,
# the subprocess will linger until it tries to print
# at which point it will get SIGPIPE and clean itself.
# trap on bash's EXIT signal to do proper cleanup.
mkfifo /tmp/monitor-nm-change
(
dbus-monitor --system "type='signal',interface='org.freedesktop.nm_dhcp_client'"
) > /tmp/monitor-nm-change &
exec </tmp/monitor-nm-change
rm /tmp/monitor-nm-change
while read EVENT; do
#change this condition to the event you're interested in
if echo "$EVENT" | grep -q BOUND6; then
# do something interesting
echo "current ipv6 addresses:"
ip addr show | grep inet6
fi
done
Вихід dbus-монітора не є простим для розбору в сценаріях. Можливо, це легше запустити на наявність певного ключового слова, наприклад new_ip_address
, і звідти використовувати різні інструменти для отримання інформації, яка змінилася (наприклад, ip або ifconfig).
# example output data from dbus-monitor for that signal
...
dict entry(
string "new_routers"
variant array of bytes "192.168.2.11"
)
dict entry(
string "new_subnet_mask"
variant array of bytes "255.255.255.0"
)
dict entry(
string "new_network_number"
variant array of bytes "192.168.2.0"
)
dict entry(
string "new_ip_address"
variant array of bytes "192.168.2.4"
)
dict entry(
string "pid"
variant array of bytes "12114"
)
dict entry(
string "reason"
variant array of bytes "REBOOT"
)
dict entry(
string "interface"
variant array of bytes "eth0"
)
...
Дай постріл!
dhclient-enter-hooks.d
скрипт ... але я ніколи не пробував! Існуючий/etc/dhcp/dhclient-enter-hooks.d/resolvconf
сценарій може бути корисним з точки зору синтаксису та на які сигнали звернути увагу ("$reason" == "BOUND"
можливо?)