хост использует его как gateway, хотя имеется более короткий маршрут.
Например, после загрузки таблицы маршрутизации на sophus может быть
неполной: она содержит маршруты к сети математиков, к FDDI магистрали,
а по умолчанию указан gateway Groucho Вычислительного центра (gcc1).

Поэтому, любые пакеты для quark посылаются через gcc1, хотя
быстрее было бы через niels (gateway в отделе физики). При получении
таких дэйтаграм, gcc1 будет извещать что это -- плохой маршрут, и
будет отправлять пакет к niels, в то же самое время возвращая ICMP
сообщение к sophus, показывая ему лучший маршрут.

Это кажется очень разумным, потому что пропадает необходимость
дописывать новые маршруты вручную. Однако будте осторожны, полагаясь
на динамические схемы маршрутизации, будь то RIP или ICMP
перенаправляющие сообщения, это не всегда хорошая идея. ICMP
перенаправления и RIP предлагают Вам маленький или никакой выбор при
проверке, подлинности маршрутной информации Это позволяет
злоумышлинику полностью разрушить движение по сети, или сделать что-то
еще.

3.6. Система имен областей (Domain Name System)

3.6.1 Поиск по имени (Hostname Resolution)

< > Как описано выше, адресация в TCP/IP сети крутится вокруг 32
разрядных номеров. Однако, Вам будет трудно запомнить даже некоторые из

- 44 -

них. Поэтому, хосты чаще известны под "обычными", имена типа gauss или
strange. Поэтому требуются программы для получения IP адреса по имени
машины Этот процесс назван Hostname resolution.

Приложение, которое хочет найти IP адрес по данному имени хоста,
не должен пытаться сделать это собственными силами Вместо этого, оно
обращается к библиотечным функциям, которые для этого и написаны, они
называются gethostbyname (3) и gethostbyaddr (3). Традиционно, эти и
ряд других процедур были сгруппированы в отдельной библиотеке
названной resolver; в Linux, это часть стандартной libc.

На маленькой сети, подобной Ethernet, или даже на нескольких, не
очень трудно поддерживать таблицу, сопоставляющую имена хоста к IP
адресам. Эта информация обычно хранится в файле /etc/hosts. При
добавлении или перемещении хоста, или при переназначении адресов, все
что Вы должны сделать -- это изменить файл hosts на всех хостах.
Очевидно, что это будет достаточно трудно в сетях с большим
количеством машин.

Одно из решений этой проблемы -- NIS, Сетевая Информационная
Система разработанная Sun Microsystems, названное YP, или Желтыми
Страницами. NIS хранит hosts файл (и другую информацию) в базе данных
на главном хосте, от которого клиенты могут восстановить свои файлы
если это необходимо. Все еще, Этот способ подходит только для сетей
среднего размера, потому что он требует поддерживать полную базу
данных как на центральной машине, так и на всех остальных.

В Internet, первоначально информация об адресах хранилась в
единственном файле HOSTS.TXT. Этот файл поддерживался в NIC, и должен
был загружаться всеми участвующими участками. Когда сеть выросла,
возникло несколько проблем. Постоянное обновление и постоянная
перекачка файла HOSTS.TXT регулярно требовали все больше ресурсов,
нагрузка на сервер, который этим занимался стала слишком высока. Но
еще большей проблемой стало придумывание новых (не совпадающих с
преждними) имен.

Вот почему, в 1984 г, введена новая схема -- DNS, разработанная
Paul Mockapetris и решившая обе проблемы одновременно.

- 45 -


3.6.2. О DNS

DNS организовывает имена хостов по областям(domain). Область --
набор как-то связанных участков, это могут быть машины одной сети (на
пример все машины в университетском городке, или всех хосты в BITNET),
все они могут принадлежать определенной организации (типа
американского правительства), или они просто географически близки.
Например, университеты сгруппированы в edu области, с каждым
Университетом или Коледжом, использующим отдельную подобласть, в
которой и находятся все его хосты. Groucho Marx Университету можно
давать groucho.edu область, Отделу математики -- maths.groucho.edu.
Хост на данной сети к имени области добавляет свое имя и таким образом
получает свое полное имя в Internet erdos был бы известен как
erdos.maths.groucho.edu.

Картинка 3.6.2 изображает пространство имен. Запись в корне этого
дерева, которая обозначена единственной точкой, весьма точно названа
областью корня, и она связана со всеми другими областями. Чтобы
показать что в данном месте пишется полное имя хоста, а не имя
относительно локальной области, иногда после имени ставят точку. Это
значит, что последний компонент имени принадлежит области корня.

В зависимости от местоположения в иерархии имени, область может
быть названа top-level, second-level, или third-level
(верхнеуровневой, второго уровня, или третьего уровня). Больше
количество уровней встречается редко. Вот несколько верхних областей,
которые Вы можете часто увидеть:

edu ( Главным образом США ) образовательные учреждения подобно
университетам, и т.д..

com Коммерческие организации, компании.

org некоммерческие организации. Часто частные UUCP сети находятся в этой
области.

net Gateways и другие административные хосты в сети.

- 46 -


mil американские военные учреждения.

gov американские правительственные учреждения.

uucp Официально, все имена участков прежде используемые как UUCP имена
без областей, были перемещены в эту область.

Технически, первый четыре из них принадлежат американской части
Internet, но там встречаются и не американские участки. Это особенно
верно для net области. Однако, mil и gov используются исключительно в
США.

Вне США, каждая страна вообще использует собственную область,
названую по имени страны и состоящая из двух букв определенных в
ISO-3166. Финляндия, например, использует fi область, fr используется
Францией, de Германией, au Австралией и т.д.. Ниже этой
высокопоставленной области, NIC каждой страны может свободно раздавать
имена хостам. Австралия, например, имеет области второго уровня
подобные международным высшим областям, названным com.au, edu.au, и
так далее. Другие, подобно Германии, не используйте этот
дополнительный уровень, но используют слегка длинные имена, которые
непосредственно относятся к организациям управляющих специфической
областью. Например, на пример ftp.informatik.uni-erlangen.de.

чонечно, эти национальные области не подразумевают что хост
расположенный ниже фактически расположен в той же стране; это только
сигнализирует что хост регистрировался в NIC этой страны . Шведский
изготовитель мог бы иметь отделение в Австралии, и все же
регистрировать все хосты в se области.

Теперь, организация пространства имен в иерархии имен областей
приятно решает проблему уникальности имен; с DNS, имя хоста должно
быть уникально только в пределах одной области Кроме того, полностью
квалифицированные имена весьма легко запомнить. Но DNS делает не
только это: он позволяет Вам передать работу с подобластями местным
администраторам. Например, администратор в Groucho Вычислительном
Центре мог бы создать подобласть для каждого отдела; мы уже

- 47 -

столкнулись с подобластями физиков и математиков. Когда он решит, что
сеть в Отделе Физики слишком большая и хаотичная, чтобы справиться с
ней из вне , он может просто передать контроль над physics.groucho.edu
областью администраторам этой сети. Тогда они свободны использовать,
любые имена хостов и назначать их IP адреса в пределах подсети без
вмешательства сверху.

Так, пространство имени раздроблено на зоны, которая управляется
своей областью. Обратите Внимание На различие между зоной и областью:
область groucho.edu затрагивает все машины в Groucho Marx
Университете, в то время как зона groucho.edu включает только хостов
которые работают в компьютерном центре непосредственно, например в
отделе математики. Хост в отделе физики принадлежат другой зоне, а
именно physics.groucho.edu. На картинке 3.6.2, начало зоны отмечено
маленьким кружочком справа от имени области.

3.6.3 Поиск имени с помощью DNS

На первый взгляд, все эти суета с областями и зонами кажется
делает поиск адреса ужасно сложным делом. В конце концов, если нет
центрального органа контролируещего какие имена связаны с каким
адресом, тогда как - скромное приложение должно его узнавать?!

Теперь начинается действительно техническая часть описания DNS.
Если Вы хотите выяснять IP адрес erdos, тогда, DNS говорит, иди и
спроси людей, которые управляют им, и они ответят Вам.

Фактически, DNS - гигантская распределенная база данных. Это
осуществлено посредством так называемых серверов имен(name server),
которые снабжают всех информацией о данной области или нескольких
областях сразу. Для каждой зоны имеются по крайней мере два сервера
имен, которые содержат всю информацию относительно хостов в этой зоне.
Чтобы получить IP адрес erdos, все что Вы должны сделать -- обратится
к серверу имен зоны groucho.edu, который и передаст Вам требуемые
данные.

Легко сказать, а как это сделать, подумали вы. Так как найти
сервер имен в Groucho Marx Университет? В случае если ваш компьютер не

- 48 -

оборудован address-resolving oracle, DNS также обеспечивает это. Когда
ваше приложение хочет найти информацию относительно erdos, оно входит
в контакт с местным сервером имен, который проводит так называемый
итерационный опрос. Сначала он посылает запрос серверу имен об области
корня, спрашивая о адресе erdos.maths.groucho.edu. Сервер имен корня
сообщает, что это имя не принадлежит зоне его полномочий, но вместо
этого отсылает к edu области. Таким образом, он предлагает Вам войти в
контакт с сервером имен зоны edu для получения большего количества
информации, и прилагает список всех серверов имен edu вместе с их
адресами. Ваш местный сервер имен пошлет запрос одному из них,
например a.isi.edu. Также как серверу имен корня, a.isi.edu знает что
люди groucho.edu управляют свей зоной сами, и направит Вас на их
сервера. Местный сервер имен запросит одного из них, который наконец
распознает имя, как принадлежащее к его зоне, и вернет IP адрес.

Кажется, что для поиска одного IP адреса тратится слишком много
ресурсов. но это не сравнимо меньше, чем при преждней схеме с
HOSTS.TXT. Но все еще имеются места для усовершенствования этой
схемой.

Чтобы уменьшить время ответа для будущих запросов, сервер имени
хранит полученную раньше информацию в кэше. Так что в следующий раз,
когда любой другой из вашей локальной сети захочет найти адрес хоста в
groucho.edu области, ваш сервер имен не проведет все снова, а будет
сразу обращаться к серверу имен groucho.edu.

Конечно, сервер имен не будет хранить эту информацию всегда, а
отбросит ее через некоторое время. Этот интервал времени назван time
to live(временем жизни), или TTL. TTL задается администратором данной
зоны.

3.6.4 Областные сервера имен (Domain Name Servers)

Сервера имен, которые содержат всю информацию относительно хостов
в пределах данной зоны названы авторитарными для этой зоны и иногда
упоминаются как master name servers. Любой запрос относительно хоста в
пределах этой зоны будет в конце концов передан одному из этих
серверов.

- 49 -


Чтобы обеспечить адекватную картину зоны, эти сервера должны быть
хорошо синхронизированы. Это достигается с помощью создания одного
главного сервера, который загружает зональную информацию из файлов
данных, а другие вторичные сервера через равные интервалы времени
качают эти данные с главного сервера.

Одна из причин иметь несколько серверов имен состoит в том, чтобы
распределять груз работы, другая -- надежность. Когда одна машина с
сервером имен ломается, все запросы будут посылаться другим серверам.
Конечно, эта схема не защищает Вас от сбоев сервера, при которых он
отсылает неправильные ответы на все запросы DNS, например от ошибок в
программе сервера.

Конечно, Вы можете также создать сервер имени, который не будет
авторитарным для любой области. Этот тип серверов используется чтобы
проверять запросы от местных приложений и кэшировать ответы. Поэтому
его называют caching-only сервером.

3.6.5 База данных DNS

Мы видели, что DNS имеет дело не только с IP адресами хостов, но
также обменивается информацией относительно серверов имен. В DNS базе
данных фактически имеется целая куча различных типов записей.

Единица информации в DNS базе данных названа resource record
(записью ресурса), или RR. Каждая запись имеет определенный тип,
описывающий тип данных, которые в ней записаны, и определяющий тип
сети, к которой она применяется. Последний используется при
определении схемы адресования, типа IP адресов (IN класс), или адресов
в Hesiod сетях (используемые в MIT), и др. Основной записью ресурсов
является запись, которая связывает полное имя области с IP адресом.

Конечно, хост может иметь больше чем одно имя. Однако, одно из
этих имен должно быть определенно как официальное, или каноническое
имя хоста, в то время как остальные просто псевдонимы. Различие между
ними в том, что каноническое имя хоста связано с А записью, в то время
как другие только с записью типа CNAME, которая указывает на

- 50 -

каноническое имя хоста.

Мы не будем приводить здесь все типы записей, а сделаем это
позже, в другой главе, здесь же ограничимся кратким примером. Картинка
3.6.5 показывает часть базы данных области которая загружена на
сервере имен для зоны physics.groucho.edu.

Кроме A и CNAME записи, Вы можете видеть специальную, занимающую
несколько строк, запись сверху файла. Это - SOA запись ресурса,
расшифровывается Start of Authority (Начало Власти), которая содержит
общую информацию относительно зоны, для которой этот сервер является
авторитарным. Она включает, например, время жизни для всех записей.

Обратите Внимание что все имена в файле с примером, которые не
заканчиваются точкой интерпретируются относительно groucho.edu
области. Специальное имя "@", используемое в SOA записи при обращении
к имени данной области.

Мы видели, что сервера имен для groucho.edu области так или иначе
должен знать хоть что-то относительно зоны физиков так, чтобы
направлять запросы серверам имен. Это обычно достигается парой
записей: NS запись дается FQDN, и А запись, ассоциирующая его имя с IP
адресом. Так как эти записи появляются вместе, они часто называются
склеенными записями. Это -- фактически единственный случаи записи, в
которой родительская зона держит информацию относительно хостов в
зоне подчиненного. Склеенные записи указывающие на сервера имен для
physics.groucho.edu показаны на рисунке 3.6.5.

;
; Authoritative Information on physics.groucho.edu
@ IN SOA {
niels.physics.groucho.edu.
hostmaster.niels.physics.groucho.edu.
1034 ; serial no
360000 ; refresh
3600 ; retry
3600000 ; expire
3600 ; default ttl

- 51 -

}
;
; Name servers
IN NS niels
IN NS gauss.maths.groucho.edu.
gauss.maths.groucho.edu. IN A 149.76.4.23
;
; Theoretical Physics (subnet 12)
niels IN A 149.76.12.1
IN A 149.76.1.12
nameserver IN CNAME niels
otto IN A 149.76.12.2
quark IN A 149.76.12.4
down IN A 149.76.12.5
strange IN A 149.76.12.6
...
; Collider Lab. (subnet 14)
boson IN A 149.76.14.1

muon IN A 149.76.14.7
bogon IN A 149.76.14.12
...

Картинка 5. фрагмент файла amed.hosts для Отдела Физики.

3.6.6. Обратный поиск.

После обнаружения IP адреса, принадлежащего хосту, иногда
желательно выяснять каноническое имя хоста, соответствующее данному
адресу. Это называется reverse mapping(обратное отображение) и
используется несколькими сервесами, чтобы проверить идентичность
клиента. При использовании единственного hosts файла, обратный поиск
заключается просто в проверке этого файла. В DNS, конечно не
проводится просмотр всего адресного пространсва. Вместо этого, создана
специальная область, inaddr.arpa, она содержит IP адреса всех хостов.
в перевернутой dotted-quad записи Например, IP адрес 149.76.12.4
соответствует имени 4.12.76.149.in-addr.arpa. Тип записи ресурса,
связывающий это имя с именем, называется PTR.

- 52 -


;
; Zone data for the groucho.edu zone.
@ IN SOA {
vax12.gcc.groucho.edu.
hostmaster.vax12.gcc.groucho.edu.
233 ; serial no
360000 ; refresh
3600 ; retry
3600000 ; expire
3600 ; default ttl
}
....
;
; Glue records for the physics.groucho.edu zone
physics IN NS niels.physics.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physics IN A 149.76.12.1
gauss.maths IN A 149.76.4.23
...

Картинка 6. фрагмент файла named.hosts для GMU.

Создание зоны полномочий обычно означает что ее администраторам
дают полный контроль над тем как назначать адреса и имена хостов. Так
как они обычно управляют одной или более IP сетями или подсетями, одна
DNS зона может охватывать несколько IP сетей. Отдел Физики, например,
включает подсети 149.76.8.0, 149.76.12.0, и 149.76.14.0.

Как следствие, новые зоны должны быть записаны в in-addr.arpa
области: 8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa, и
14.76.149.in-addr.arpa. Иначе, установка нового хоста в Collider
лаборатории требовала бы обращения к родительской области чтобы
отметится в ее in-addr.arpa файле. Зональная база данных для подсети
12 показана на картинке 3.6.6. Соответствующие склеенные записи в базе
данных зоны родителя показывается на картинке 3.6.6.

;

- 53 -

; the 12.76.149.in-addr.arpa domain.
@ IN SOA {
niels.physics.groucho.edu.
hostmaster.niels.physics.groucho.edu.
233 360000 3600 3600000 3600
}
2 IN PTR otto.physics.groucho.edu.
4 IN PTR quark.physics.groucho.edu.
5 IN PTR down.physics.groucho.edu.
6 IN PTR strange.physics.groucho.edu.

Картинка 7. фрагмент файла named.rev для подсети 12.

;
; the 76.149.in-addr.arpa domain.
@ IN SOA {
vax12.gcc.groucho.edu.
hostmaster.vax12.gcc.groucho.edu.
233 360000 3600 3600000 3600
}
...
; subnet 4: Mathematics Dept.
1.4 IN PTR sophus.maths.groucho.edu.
17.4 IN PTR erdos.maths.groucho.edu.
23.4 IN PTR gauss.maths.groucho.edu.
...
; subnet 12: Physics Dept, separate zone
12 IN NS niels.physics.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physics.groucho.edu. IN A 149.76.12.1
gauss.maths.groucho.edu. IN A 149.76.4.23
...

Картинка 8. фрагмент файла named.rev для сети

Одно важное следствие этого то, что зоны могут создаваться только
как наборы IP сетей, и, даже круче, количество нулевых битов в
netmasks должно выть кратно 8. Все подсети в Groucho Marx Университете

- 54 -

имеют netmask 255.255.255.0, так что in-addr.arpa зона может быть
создана для каждой подсети. Однако, если netmask 255.255.255.128,
создание зон для подсети 149.76.12.128 будет невозможно, потому что
нет никакой возможности сообщить DNS, что 12.76.149.in-addr.arpa
область была раздроблена на две зоны, с именами хостов
располагающимися от 1 до 127, и 128 до 255, соответственно.
.
- 55 -



4. Конфигурирование сетевых аппаратных средств.

4.1. Устройства, драйвера, и все это

До сих пор, мы весьма немного говорили относительно сетевых
интерфейсов и общих проблем TCP/IP, но не говорили о том, что
происходит, когда "сетевой код" в ядре обращается к аппаратным
средствам. Для этого, мы должны немного поговорить о концепциях
интерфейсов и драйверов.

Во-первых, конечно, имеются непосредственно аппаратные средства,
например Ethernet карта: пластина из эпоксидной смолы, утыканная
большим количеством крошечных чипов с глупыми номерами на них, и
воткнутая в слот вашего PC. Это - то что мы обычно называем
устройством.

Для того чтобы использовать Ethernet карту, необходимы
специальные функции, расположенные в ядре вашего Linux, которые знают
как работать с этим устройством. Это так называемые драйвера
устройств. Например, Linux имеет драйвера устройства для нескольких
марок Ethernet плат которые очень похожи по выполняемым функциям. Они
известны как "Becker Series Drivers" ,и называются так по имени их
автора, Donald Becker. Другой пример - D-link драйвер, который
работает с адаптером D-link пакетов, присоединяемым к параллельному
порту.

Но, что мы подразумиваем, когда говорим что драйвер "управляет"
устройством? Давайте вернемся к Ethernet плата, которую мы уже
упоминали. Драйвер должен быть способен работать с переферией этой
платы: он должен посылать команды и данные плате, в то время как плата
должна передать полученные данные драйверу.

В PC, эта связь устанавливается через область памяти ввода-вывода
которая является отображением регистров платы и т.п. Все команды и
данные которые ядро посылает плате проходят через эти регистраторы.
Память ввода-вывода описывается указанием начального(или основного)

- 56 -

адреса Типичные основные адреса для Ethernet плат 0x300, или 0x360.

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

Также, во время загрузки, ядро будет пытаться обнаружить только
одно Ethernet устройство. Если вы используете больше чем одну плату,
Вы должны явно сообщить ядру об этой плате.

Другой параметр, который Вы могли бы сообщить ядру -- interrupt
request channel (канал прерывания запроса). Компоненты аппаратных
средств обычно прерывают ядро когда они нуждаются во внимании,
например когда прибыли данные, или произошли другие события. В PC,
прерывание может происходить на одном из 15 каналов (0, 1, 3 и до 15).
Номер прерывания назначенный компоненту аппаратных средств называется
interrupt request channel или IRQ.

Как описано в главе 3., ядро обращается к устройствам через так
называемый интерфейс. Интерфейсы предлагают абстрактный набор функций,
которые являются стандартными для всех типов аппаратных средств, типа
посылки или получения дэйтаграм.

Интерфейсы идентифицируются посредством имен. Эти имена
определенны внутри ядра, это не файлы устройств в директории /dev.
Типичные имена для интерфейсов Ethernet. - eth0, eth1, и т.д.
Назначение интерфейсов для определенных устройств обычно зависит от
способа, которым устройства конфигурированы; например первая
установленная Ethernet плата станет eth0, следующая -- eth1, и так
далее. Исключение из этого правила - SLIP интерфейсы, которые
назначаются динамически; То есть всякий раз, когда устанавливается
SLIP связь, последовательному порту назначается интерфейс


- 57 -

Картинка пробует показать связь между аппаратными средствами,
драйверами устройств и интерфейсами.

Во время загрузки, ядро показывает какие устройства обнаружены, и
какому какой интерфейс будет установлен. Фрагмент типичного экрана
загрузки:

This processor honours the WP bit even when in supervisor mode. Good.
Floppy drive(s): fd0 is 1.44M
Swansea University Computer Society NET3.010
IP Protocols: ICMP, UDP, TCP
PPP: version 0.2.1 (4 channels) OPTIMIZE FLAGS
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.
SLIP: version 0.7.5 (4 channels)
CSLIP: code copyright 1989 Regents of the University of California
dl0: D-Link DE-600 pocket adapter, Ethernet Address: 00:80:C8:71:76:95
Checking 386/387 coupling... Ok, fpu using exception 16 error reporting.
Linux version 1.1.11 (okir@monad) #3 Sat May 7 14:57:18 MET DST 1994

Здесь показано что ядро компилировалось с TCP/IP, и с драйверами
для SLIP, CSLIP, и PPP. Третья строка c низу сообщает, что был
обнаружен адаптер d-link, и он установился как интерфейс dl0. Если Вы
имеете Ethernet карту, ядро обычно печатает строку, начинающуюся с
eth0, и сопровождаемую типом обнаруженной карты. Если Вы имеете
Ethernet карту, но не увидели это сообщение, это означает что ядро
неспособно обнаружить вашу плату. Об этом мы поговорим позже.

4.2. Конфигурирование ядра

Большинство Linux распространяются вместе с загрузочными
дискетами, работующими со всеми основными типами аппаратных средств
PC. Это означает что ядро на этих дискетах имеет все виды драйверов,
многие из которых Вам никогда не пригодятся, но занимают драгоценную
память системы потому что части ядра не свопируются. Поэтому, Вы
должны собрать ваше собственное ядро, включая только необходимые Вам
драйвера.


- 58 -

При управлении Linux системой, Вы должны быть знакомы со
строением ядра. Основы этого объясняются в "Installation and Getting
Started" написанной Matt Welsh, который является также частью проекта
Linux документации. Потому, в этой секции мы будем обсуждать только те
стороны конфигурации Linux, которые относятся к сети.

При запуске make config, сначала Вас спрашивают общие вопросы
конфигурации, например хотите ли Вы в ядре иметь математический
эмулятор или нет, и т.д.. Один из этих вопросов -- хотите ли Вы
поддержку TCP/IP сети. Вы должны ответить y, чтобы получить ядро
способное работать с сетью.

4.2.1. Опции ядра в Linux 1.0 и выше

После того, как основная часть вопросов задана, конфигуратор
продолжит спрашивать Вас относительно различных особенностей типа SCSI
драйверов, и т.д..

Последующий список вопросов относится к проблемам поддержки сети.
Точный набор опций конфигурации постоянно меняется, из-за
продолжающейся разработки. Типичный список опций предлагаемых
большинством версий ядра (в основном в 1.0 1.1) напоминает этот (
комментарии даются italics шрифтом):
*
* Network device support
*
Network device support? (CONFIG ETHERCARDS) [y]

Несмотря на макро название указанное в скобках, Вы должны
ответить на этот вопрос y, если Вы хотите использовать любой тип