Содержание

Ключевые слова: Х-терминал, linux, LTSP, Linux Terminal Server Project, терминальный linux-сервер, бездисковая станция, ПК без жесткого диска, использование старых компьютеров, diskless workstation, thin client, asplinux, использование Linux в офисе, X-terminal

Неполадки 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.

Пока интересно, читаем дальше!

Авторское право © Сеник Николай, 2004-2006