Log dhcp сервера linux

Установка и настройка DHCP сервера на Linux CentOS 7

Базовая настройка

yum install dhcp

Теперь откроем на редактирование конфигурационный файл:

И внесем в него, примерно, следующее:

subnet 192.168.0.0 netmask 255.255.255.0 <
range 192.168.0.100 192.168.0.200;
option domain-name-servers 192.168.0.10, 192.168.0.11;
option domain-name «dmosk.local»;
option routers 192.168.0.1;
option broadcast-address 192.168.0.255;
default-lease-time 600;
max-lease-time 7200;
>

• subnet обозначает сеть, в области которой будет работать данная группа настроек;
• range — диапазон, из которого будут браться IP-адреса;
• option domain-name-servers — через запятую перечисленные DNS-сервера;
• option domain-name — суффикс доменного имени;
• option routers — шлюз по умолчанию;
• option broadcast-address — адрес сети для широковещательных запросов;
• default-lease-time, max-lease-time — время и максимальное время в секундах, на которое клиент получит адрес, по его истечению будет выполнено продление срока.

** все примеры настроек можно увидеть в файле /usr/share/doc/dhcp*/dhcpd.conf.example (вместо * будет версия установленного dhcp).

Проверить корректность конфигурационного файла можно командой:

Источник

ISC-DHCPd + Syslog ( Простейшая настройка журналирования DHCP-сервера в Linux. )

20 сентября 2017 (обновлено 8 декабря 2017)

OS: Linux Debian 6/7/8/9.
Application: ISC-DHCPd, Syslog и Logrotate.

Задача: наладить сбор сообщений о событиях обслуживания сервером клиентских DHCP-запросов в отдельном журнальном файле.

Используемый в Linux и BSD сервер автоматизации выдачи сетевых настроек «ISC DHCPd» (далее DHCPd) старенький и местами странно отсталый. Американский «Internet Systems Consortium» выпустил его первую стабильную версию в конце 1997 года, прошли десятилетия, в 2017 году мы уже пользуемся четвёртой версий, а средств управления без перезапуска этим сервисом нет, как отсутствует и поддержка возможности направить сообщения о событиях в произвольный файл. За двадцать лет важнейший и привычный всем функционал так и не добавили — но альтернативы нет, и мы продолжаем жить с тем, что неудобно, но работает.

По умолчанию весь поток сообщений о взаимодействии с клиентами DHCPd отправляет в подсистему журналирования «syslog» несущей операционной системы. Казалось бы, пусть себе шлёт их, куда захочет. В общем, пусть бы оно и так, но для сети в пару десятков тысяч пользователей поток сообщений льётся так обильно, что полностью забивает собой всё остальное — можно считать, что об остальных системных событиях вы уже не узнаете.

Определение параметров журналирования в DHCPd.

Единственное, что можно сделать в конфигурационном файле, так это указать «метку», по которой в дальнейшем можно будет вылавливать интересующие нас сообщения в общей массе:

Не обязательно использовать метку «local7», но она фигурирует в примере от разработчиков, и не конфликтует с метками других распространённых сервисов — так что проще оставить «по умолчанию».

Как я упоминал выше, применение параметров без полного перезапуска DHCPd не поддерживается, так что особо важно предварительно проверить, не допущено ли ошибок в конфигурации такового:

На данный момент три приложения системы журналирования в Linux актуальны и используются: «Syslog», «RSyslog» и «Syslog-NG» — рассмотрим способы обработки сообщений DHCPd в каждой из них.

Сбор событий DHCPd в отдельном файле посредством «Syslog».

Старая и простая подсистема, в которой всё с интересующей нас меткой просто отправляется в файл, после чего обработка пакета данных завершается:

Сбор событий DHCPd в отдельном файле посредством «RSyslog».

В этой, пришедшем на замену «Syslog»-у, подсистеме журналирования, по умолчанию обработка пакета данных продолжается даже после совпадения с критерием фильтрации — явно останавливаем процесс операндом «&

Сбор событий DHCPd в отдельном файле посредством «Syslog-NG».

В наиболее современном «Syslog-NG» управление потоками гибче, но существенно сложнее — приходится не только вылавливать нужное, но и отсекать это же там, где оно помешает:

.
# Указываем целевой файл журнала
destination d_dhcpd < file("/var/log/dhcpd.log"); >;

# Описываем критерии фильтрации (можно по «метке», но эффективнее по наименованию испускающего событие приложению)
// filter f_dhcpd < facility(local7); >;
filter f_dhcpd < program('^dhcpd$'); >;

# Добавляем в некоторые имеющиеся фильтры указания исключать из них уже захваченное фильтром «f_dhcpd»:
filter f_debug < . and not filter(f_dhcpd); >;
filter f_error < . and not filter(f_dhcpd); >;
filter f_messages < . and not filter(f_dhcpd); >;
filter f_syslog < . and not filter(f_dhcpd); >;

# Формируем цепочку обработчиков, которая обслуживает поток сообщений DHCPd
log < source(s_src); filter(f_dhcpd); destination(d_dhcpd); >;
.

Настройка ротации файлов журнала.

Конечно же, если поддержка вывода журнала событий в DHCPd отсутствует, то усечения и ротация такового тоже не предусмотрена. Исправим это:

Проверяем корректность настройки ротации:

[ уже посетило: 3400 ] [ интересно! / нет ]

Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )

Источник

Разница между dhcpd.leases и dhcp.log

dhcpd.leases — база данный (database), хранящая в текстовом файле данные об арендах (leases).
Пример:
lease 192.168.100.211 <
starts 0 2008/04/01 03:12:51;
ends 0 2008/04/01 04:12:51;
cltt 0 2008/04/01 03:12:51;
binding state active;
next binding state free;
hardware ethernet 00:76:00:aa:3d:23;
uid «»;
client-hostname «aphina»;
>

dhcp.log — сюда сбрасываются c помощью syslog мессаги о взаимодействии клиента-сервера.
Пример:
Jan 19 00:00:03 ns dhcpd: DHCPINFORM from 172.20.100.01 via vlan802
Jan 19 00:00:03 ns dhcpd: DHCPACK to 172.20.100.01
Jan 19 00:00:03 ns dhcpd: DHCPREQUEST for 172.20.100.02 from 00:31:dd:ff:01:34 (Hostname Unsuitable for Printing) via vlan802
Jan 19 00:00:03 ns dhcpd: DHCPACK on 172.20.206.129 to 00:31:dd:ff:01:34 (Hostname Unsuitable for Printing) via vlan802

Какая идея хранения примерно одного и того же в двух видах? И где можно достать документацию по syslog-овским сообщениям (кроме как из кода)?

Re: Разница между dhcpd.leases и dhcp.log

Ты логи можешь не вести, но лизы ты вести обязан.

Re: Разница между dhcpd.leases и dhcp.log

> Какая идея хранения примерно одного и того же в двух видах?

Это совсем не одно и то же.

В суслоге dhcpd просто извещает всех о том, что уже произошло. Для истории, так сказать. Журнал произведённых действий.

Ну а файл dhcpd.leases dhcpd-демон периодически просматривает (при очередном широковешательном крике на получение адреса). В этос файле хранится информация о том, как долго закреплять один и тот же адрес за одним и тем же компом, запрашивающим IP-адрес. То есть, если бы не было вообще этого файла, то каждый раз клиенты получали бы разные адреса. Но файл есть, в файле прописаны таймауты хранения адреса (или закрепления адреса) и в этом же файле прописаны MAC-адреса; поэтому при повторном запросе от клиента (завтра. послезавтра) будет выдан такой же IP-адрес, какой был выдан сегодня.

Объяснил как мог. 🙂 Если непонятно — переспроси.

Re: Разница между dhcpd.leases и dhcp.log

Идею dhcpd.leases понял (На самом деле это порушило все мое мировоззрение). Когда игрался с dhcp, он исправно вел dhcpd.leases, но в некоторый момент, скидывал все в dhcpd.leases

, затирая таким образом всю старую базу. В опциях сервера не мог найти той опции, которая бы вела базу бесконечно. Можно ли сказать, что если комп подтвердил свои претензии на определенный ip, то предыдущие записи об этом компе и его ip хранить незачем для сервера? И если все претензии понятны для сервера, то он затирает старую бд (т.е. файл dhcpd.leases

Re: Разница между dhcpd.leases и dhcp.log

> Когда игрался с dhcp, он исправно вел dhcpd.leases, но в некоторый момент, скидывал все в dhcpd.leases

, затирая таким образом всю старую базу.

— это просто резервная копия перед началом изменений основного файла dhcpd.leases. То есть, предыдущее состояние файла dhcpd.leases. Поэтому этот файл (dhcpd.leases

) будет всегда меняться при изменении основного файла. И этот файл нужен только для непредвиденных случаев, когда dhcpd.leases по какой-то причине разрушен (мало ли). Тогда его можно воостановить из dhcpd.leases

— это не старая база, это предыдущее состояние файла dhcpd.leases

> В опциях сервера не мог найти той опции, которая бы вела базу бесконечно.

Эм. не понял. Оно и так ведётся бесконечно 🙂 dhcpd.leases меняется всегда (и dhcpd.leases

как логически связанный с ним)

> Можно ли сказать, что если комп подтвердил свои претензии на определенный ip, то предыдущие записи об этом компе и его ip хранить незачем для сервера?

Ну да. В dhcpd.leases хранится всегда актуальное состояние. Зачем хранить историю выданных адресов? История в суслоге 🙂

Re: Разница между dhcpd.leases и dhcp.log

>> В опциях сервера не мог найти той опции, которая бы вела базу бесконечно.

>Эм. не понял. Оно и так ведётся бесконечно 🙂 dhcpd.leases меняется всегда (и dhcpd.leases

как логически связанный с ним)

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

Re: Разница между dhcpd.leases и dhcp.log

Кстати, а есть какие-нибудь тулзы для мониторинга того, что сбрасывается с помощью syslog-а? Гугл упорно посылает в маны. Или в принципе ничего стоящего выудить не удается по этим логам, а события из ряда вон выходящие видны и без всяких тулзов?

Источник

Как посмотреть, что делает DHCP-клиент?

В случае, если есть существенные различия между Linux: я заинтересован в Debian 8.1 (минимальная установка по умолчанию amd64).

DHCP-клиент ISC обычно вызывается dhclient в большинстве дистрибутивов Linux. От man dhclient :

Клиент обычно не выводит выходные данные во время своей последовательности запуска. Это может быть сделано для генерации подробных сообщений, отображающих события последовательности запуска, пока он не получит адрес, предоставив аргумент командной строки -v. В любом случае клиент регистрирует сообщения с использованием средства syslog (3).

Есть два возможных способа прочитать системный журнал. В большинстве систем, которые используют systemd, вы должны использовать journalctl , тогда как cat /var/log/syslog это действительно для систем, которые все еще используют традиционную систему инициализации.

Поэтому, если ваша система использует средства ведения журнала systemd, вы можете использовать journalctl | grep -Ei ‘dhcp’ для получения журналов клиента DHCP. В противном случае введите cat /var/log/syslog | grep -Ei ‘dhcp’ .

Вот как обычно выглядит мой журнал DHCP-клиента:

Хакерский (но эффективный) способ отладки dhclient на многих платформах Linux — включить трассировку bash в / sbin / dhclient-script .

dhclient запускает этот скрипт на большинстве вариантов ОС, которые я проверял (RedHat, Debian и т. д.).

Простое добавление -x к шебангу (первая строка) в этом скрипте должно включить трассировку каждой строки в консоли, например:

Тогда вы можете запустить, например,

И вы должны увидеть много выходных данных, не только из dhclient-script, но и из всех включенных .d скриптов в / etc / dhcp *.

Вывод трассировки должен позволить вам выяснить, что происходит и какие решения принимает код (обращайтесь к самому сценарию, просматривая вывод).

Обычно вы можете вывести входные данные (например, параметры, включая IP, GATEWAY и т. Д.) Сценария, полученного из этих выходных данных, но если нет, вы можете временно добавить что-то подобное в сценарий непосредственно перед выходом:

Затем проверьте ваш журнал после запуска dhclient (/ var / log / messages или / var / log / syslog)

Пожалуйста, найдите ответ в строке.

Клиент dhcp в Linux записывает какие-либо логи?

Если нет, можно ли включить логи и как?

Если он пишет логи, где их можно найти?

• Как выглядит типичный журнал клиента dhcp при получении IP-адресов и серверов имен с DHCP-сервера?

galaxy dhcpd: DHCPDISCOVER от 00: 0d: 62: d7: a0: 12 через eth0
galaxy dhcpd: DHCPOFFER с 192.168.1.5 до 00: 0d: 62: d7: a0: 12 через eth0
galaxy dhcpd: DHCPREQUEST для 192.168.1.5 (192.168 .1.1) с 00: 0d: 62: d7: a0: 12 через eth0
galaxy dhcpd: DHCPACK с 192.168.1.5 до 00: 0d: 62: d7: a0: 12 через eth0

Где я могу найти исходный код клиента DHCP?

Источник

How to see what DHCP client does?

In case there are relevant differences between Linuxes: I am interested in Debian 8.1 (default minimal installation amd64).

3 Answers 3

ISC’s DHCP client is usually called dhclient in most Linux distributions. From man dhclient :

The client normally prints no output during its startup sequence. It can be made to emit verbose messages displaying the startup sequence events until it has acquired an address by supplying the -v command line argument. In either case, the client logs messages using the syslog(3) facility.

There are two possible ways to read your system log. On most systems that use systemd, you have to use journalctl , whereas cat /var/log/syslog is valid for systems that still employ a traditional init system.

Therefore, if your system is using systemd’s logging facility, you can use journalctl | grep -Ei ‘dhcp’ to get DHCP client logs. Otherwise, enter cat /var/log/syslog | grep -Ei ‘dhcp’ .

Here is what my DHCP client log typically looks like:

A hacky (but effective) way to debug dhclient on many Linux platforms is to enable bash tracing in /sbin/dhclient-script.

dhclient runs that script on most OS variants I’ve checked (RedHat, Debian, etc).

Simply adding -x to the shebang (first line) in that script should enable tracing each line to console, eg:

Then you can run, for example

And you should see lots of output, not only from dhclient-script, but from all the included .d scripts in /etc/dhcp*.

The trace output should allow you to figure out what’s happening and what decisions the code is making (reference the script itself when looking at the output).

You can usually deduce the inputs (eg parameters including IP, GATEWAY, etc) the script received from this output, but if not, you can temporarily add something like this to the script just before the exit:

Then check your log after running dhclient (/var/log/messages or /var/log/syslog)

Источник