Причина - у пакета поменялись зависимости, поэтому его обновление хоть и возможно, но повлечет установку новых пакетов-зависимостей. По-умолчанию такой пакет не обновляется, а выводится в списке после сообщения "The following packages have been kept back...". Чтобы все равно обновить такой пакет, apt-get upgrade нужно запускать с флагом --with-new-pkgs.
вторник, 30 ноября 2021 г.
понедельник, 8 ноября 2021 г.
Запуск tcpdump на заданное количество секунд
Задача
Нужно в bash-скрипте запустить tcpdump, чтобы он отработал N секунд и завершился.
Решение
Как вариант - запуск с помощью команды timout:
timeout --preserve-status {N} tcpdump ...
Здесь {N} нужно заменить на необходимое количество секунд. Если не установить опцию --preserve-status, комадна будет всегда завершаться с ненулевым статусом (сигнализируя о наступлении таймаута). Если это не критично - опцию можно убрать.
Есть более элегантный вариант:
tcpdump -G {N} -W 1 -w myfile ...
, предложенный тут https://stackoverflow.com/questions/25731643/how-to-schedule-tcpdump-to-run-for-a-specific-period-of-time. Идея в том, чтобы задать ротацию по времени выходных файлов-дампов, и установить максимум в 1 файл. Однако, работоспособность такого варианта зависит от наличия трафика на интерфейсе и установленных в tcpdump фильтрах. Если вдруг окажется, что никакой трафик не удовлетворяет условиям установленного фильтра, то tcpdump зависнет навечно, вместо того, чтобы быть завершенным через {N} секунд. Tcpdump будет считать, что раз выходной файл пустой, то и ротировать его по истечении {N} секунд не нужно.
Kubernetes: как снять дамп трафика с Enthernet-интерфейсов узла, не подключаясь к узлу
Задача
Нужно снять дамп трафика с Enternet-интерфейсов одного из узлов Kubernetes-кластера. При этом ssh-доступа к самому узлу нет.
Решение
Деплоим на узел pod с hostNetwork = true. Pod оказывается подключенным к root network namespace, ему оказываются непосредственно видны физические ethernet-интерфейсы. Далее дело за малым - запустить tcpdump (например, можно взять для этого образ corfr/tcpdump).
Windows 10 игнорирует DHCP и использует DNS-сервер непонятно откуда
Проблема
При работе в своей домашней WiFi-сети у меня в один период была необходимость отключить на своем Windows-ноутбуке DHCP и прописать настройки сети вручную (включая DNS-сервер 192.168.1.1). Однако, когда я после этого попробовал воспользоваться интернетом, раздаваемым с телефона, то столкнулся с тем, что он не работает. Проверил настройки - DHCP для этой сети включен. Все настройки приходят корректно, кроме DNS - он почему-то установился в 192.168.1.1, хотя должен был быть а-ля 192.168.202.200.
ipconfig /flushdns и ipconfig /renew, перезагрузки, выкл/вкл WiFi, удаление сети и подключение к ней по новой - ничего не помогло. 192.168.1.1 снова и снова появляся каким-то магическим образом. Причем я даже зашел в настройки подключения к домашней сети, и вернул там DHCP. После этого 192.168.1.1 больше нигде не фигурировал в настройках, но все равно упорно появлялся при подключении к раздаваемому с телефона WiFi.
Решение
Спасибо https://superuser.com/questions/1323938/windows-10-wifi-sets-wrong-dns-server-when-connecting-to-wifi-networks. Нужно зайти в реестр Windows и очистить значение ключа:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\{*interface-UUID*}\ProfileNameServer
Когда установлено, оно перезатирает адрес DNS-сервера, получемый по DHCP. Ох.
Подписаться на:
Сообщения (Atom)