Неполадки DHCP (продолжение)
Или, если вы больше склоняетесь к утилитам с пользовательским интерфейсом, можете воспользоваться другой командой (см. рис. 8.1):
# /usr/sbin/ntsysv
Рис. 8.1. Установка автозапуска демона dhcpd
Если демон dhcpd работает, но Х-терминал так и не получил от него IP-адреса, следует еще раз проверить содержимое файла /etc/dhcpd.conf. Возможно, вы ошиблись в написании физического MAC-адреса сетевого адаптера. Например, если при загрузке Х-терминала на экране вы увидели такое сообщение:
Loading ROM image ......................
ROM segment 0x0000 length 0x0000 reloc 0x00020000
Etherboot 5.2.2. (GPL) http://etherboot.org Tagged ELF for [NE2000/PCI]
Relocation _text from [00013d70, 00022800) to [01ef1570, 01f00000)
Boot from (N)etwork or (Q)uit?
Probing pci nic ...
[rtl8029]
NE2000 base 0xfcc0, addr 03:42:60:FF:AC:0D
В файле /etc/dhcpd.conf ему должна соответствовать запись, похожая на:
host ws003 {
hardware ethernet 03:42:60:FF:AC:0D;
fixed-address 192.168.1.3;
filename "/lts/vmlinuz-2.4.24-ltsp-1";
}
Очень тщательно проверяйте соответствие MAC-адресов, так как ошибка даже в одном символе сделает невозможной загрузку Х-терминала. После внесения изменений в файл /etc/dhcpd.conf не забудьте перезапустить демон dhcpd:
# /sbin/service dhcpd restart
После двойной проверки конфигурационного файла DHCP-сервера (/etc/dhcpd.conf) и при все той же неработоспособности Х-терминала нужно удостовериться, что на Х-терминал сервере не выполняется программное обеспечение, блокирующее DHCP-запросы. Такая ситуация часто возникает при некорректной настройке брандмауэра (firewall). В операционной системе Linux программный брандмауэр может быть настроен при помощи утилит: iptables, реже ipchains и еще реже ipfwadm.
Первое, что необходимо сделать – это проверить работают ли данные программы. Так как принцип работы у программных брандмауэров одинаковый, то последующие примеры будут приводиться только для программы iptables. Итак, выполняем команду проверки запуска iptables:
# /sbin/service iptables status
Table: filter
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
В данном примере для всех цепочек применяется политика ACCEPT, что означает отсутствие правил фильтрации сетевых пакетов, а следовательно iptables не блокирует DHCP-запросы Х-терминалов.
Так как программный брандмауэр iptables работает с сетевыми пакетами на очень низком уровне, то из соображений производительности он реализован в виде модуля ядра, а как результат - его присутствие в оперативной памяти сервера нельзя определить анализируя список выполняющихся процессов. Поэтому методика ps aux | grep ip_tables нам не подойдет. Нужно проверить какие модули ядра загружены и выполняются:
$ /sbin/lsmod | grep ip
iptable_filter 2412 0 (autoclean) (unused)
ip_tables 15776 1 [iptable_filter]
Говоря откровенно, разобраться в большом списке правил для iptables без специальной подготовки и опыта довольно сложно, а поэтому, чтобы исключить из числа возможных причин некорректно настроенный брандмауэр, для проверки я предлагаю временно отключить его:
# /sbin/service iptables stop
Можно даже для повышенной надежности принудительно выгрузить из оперативной памяти модули ядра, принадлежащие пакету iptables:
# /sbin/rmmod iptable_filter
# /sbin/rmmod ip_tables
Если после отключения брандмауэра загрузка Х-терминала успешно прошла стадию получения IP-адреса от DHCP-сервера, то причина найдена – ваш брандмауэр iptables блокирует запросы DHCP и необходимо подкорректировать цепочки его правил.
При отрицательном результате от выключения брандмауэра у вас в арсенале есть еще один способ проверки работы протокола DHCP. Для этого при получении на экран Х-терминала строки “Searching for server (DHCP) ...” следует проследить, какие записи появляются в системном журнале. Чтобы видеть вновь поступающие в него записи, достаточно выполнить такую команду от имени суперпользователя:
# tail -f /var/log/messages
Например, если вы увидите там нечто подобное этому:
Feb 1 11:07:34 xtserver dhcpd: DHCPDISCOVER from 00:02:FD:72:FE:A0 via eth0
Feb 1 11:07:34 xtserver dhcpd: no free leases on subnet WORKSTATIONS
Feb 1 11:07:59 xtserver dhcpd: DHCPDISCOVER from 00:02:FD:72:FE:A0 via eth0
Feb 1 11:08:00 xtserver dhcpd: no free leases on subnet WORKSTATIONS
Это означает, что запросы от Х-терминала с MAC-адресом сетевого адаптера 00:02:FD:72:FE:A0 поступают на сетевой интерфейс сервера с символическим именем eth0, и сервер-демон DHCP успешно их принимает, но, к сожалению, не располагает никакой информацией по поводу возможности присвоения IP-адреса Х-терминалу с таким физическим MAC-адресом. Если вы столкнулись именно с такой ситуацией, то налицо ошибка в конфигурационном файле /etc/dhcpd.conf. Исправляете ошибку, перезапускаете демон dhcpd и проверяете загрузку Х-терминала. Если загрузка Х-терминала дошла до строки “Ме:” на экране, и дальше остановилась, то это означает успешное минование протокола DHCP. Проблему теперь нужно искать в настройках сервера TFTP.