``Бездисковая загрузка'' означает, что машина с FreeBSD загружается по сети и читает необходимые файлы с сервера, а не со своего диска. Подробное описание есть в соответствующей главе Руководства.
Да. Пожалуйста, обратитесь к разделу Руководства, посвящённому сложным вопросам работы в сети, особенно в той части, что касается маршрутизации и маршрутизаторов.
Как правило, те, кто задают такие вопросы, имеют дома два компьютера, один с FreeBSD, а другой с какой-то версией Windows; идея состоит в использовании FreeBSD для подключения к Internet, а затем осуществлять выход в Internet из Windows через FreeBSD. На самом деле это просто частный случай предыдущего вопроса, который хорошо отработан.
Если для подключения к Internet вы используете коммутируемое соединение, то ppp(8) режима пользователя имеет параметр -nat. Если вы запустите ppp(8) с параметром -nat, установив в файле /etc/rc.conf переменную gateway_enable в значение YES и правильно настроите машину с Windows, то всё должно прекрасно заработать. Для получения дополнительной информации, пожалуйста, обратитесь к страницам справочной системы по команде ppp(8) или разделу Руководства о PPP режима пользователя.
Если вы используете PPP режима ядра, или у вас Ethernet-подключение к Internet, то нужно использовать natd(8). Пожалуйста, обратитесь к разделу о natd Руководства для получения вводной информации.
Да. Обратитесь к страницам справочника по командам slattach(8), sliplogin(8), ppp(8), и pppd(8). ppp(8) и pppd(8) могут обслуживать как входящие, так и исходящие соединения, когда как sliplogin(8) имеет дело исключительно со входящими соединениям, а slattach(8) только с исходящими.
Более подробная информация об их использовании находится в разделе Руководства о протоколах PPP и SLIP.
Если вы имеете доступ в Internet только через командную строку оболочки, вам может подойти пакадж net/slirp. С его помощью можно получить (ограниченный) доступ к таким службам, как FTP и http прямо с вашей машины.
Да. Если вы собираетесь использовать NAT с пользовательским соединением PPP, пожалуйста, обратитесь к разделу Руководства о пользовательском PPP. Если же вы хотите использовать NAT вместе с другим типом сетевого подключения, пожалуйста, взгляните на раздел о natd Руководства.
Пожалуйста, обратитесь к разделу Руководства о PLIP.
Дело в том, что такие устройства не нужны. В стандарте сетевого взаимодействия Беркли сетевые интерфейсы напрямую доступны только ядру. За дополнительной информацией обратитесь к файлу /etc/rc.network и страницам справочника, описывающим различные сетевые программы, упоминаемые здесь. Если всё это оставит вас в недоумении, почитайте книгу, описывающую администрирование сети в другой BSD-подобной операционной системе; с некоторыми незначительными исключениями, администрирование сети во FreeBSD в основном совпадает с SunOS 4.0 и Ultrix.
Если алиас находится в той же самой сети, что и уже настроенный на интерфейсе адрес, то добавьте в командной строке для ifconfig(8) добавьте netmask 0xffffffff примерно следующим образом:
# ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff
В противном случае просто задайте сетевой адрес и маску обычным образом:
# ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00
Если вы хотите задействовать другой разъём, то должны указать дополнительный параметр при вызове команды ifconfig(8). Разъёмом по умолчанию является link0. Чтобы задействовать разъём AUI, а не BNC, используйте link2. Эти флаги должны быть указаны с помощью переменных ifconfig_* в файле /etc/rc.conf (посмотрите справку по rc.conf(5)).
Некоторые сетевые адаптеры работают (мягко говоря) хуже, чем другие, что может иногда вызывать проблемы при работе приложений типа NFS, интенсивно использующих сеть.
Подробности описаны в соответствующей главе Руководства, посвящённой NFS.
Некоторые версии NFS для Linux поддерживают запросы на монтирование только с привилегированного порта; попробуйте
# mount -o -P linuxbox:/blah /mnt
Рабочие станции Sun под управлением SunOS 4.X поддерживают запросы на монтирование только с привилегированного порта; попробуйте
# mount -o -P sunbox:/blah /mnt
12.13. Почему mountd продолжает выдавать сообщения ``can't change attributes'' и ``bad exports list'' на моём сервере NFS, работающем под управлением FreeBSD?
В большинстве случаев проблема заключается в недостаточном понимании корректного формата файла /etc/exports. Пожалуйста, просмотрите ещё раз справочную информацию по exports(5) и раздел об NFS в Руководстве, особенно в части настройки NFS.
Попробуйте отменить все расширения TCP в файле /etc/rc.conf (посмотрите справку по rc.conf(5)), изменив значение следующей переменной в NO:
tcp_extensions=NO
Маршрутизаторы Annex фирмы Xylogic не работают по этой же причине, поэтому при подключении к ним вам нужно проделать то же самое.
По умолчанию FreeBSD поддерживает работу с многоадресного сетевого вещания. Если вы хотите использовать ваш компьютер как маршрутизатор многоадресного трафика, вам нужно перекомпилировать ядро с включенной опцией MROUTING и запустить mrouted(8). Во FreeBSD во время загрузки будет запускаться mrouted(8), если переменная mrouted_enable в файле /etc/rc.conf установлена в значение YES.
Приложения MBONE находятся в собственной категории портов, mbone. Если вы ищете приложения для организации конференций vic и vat, посмотрите там!
Вот список, составленный Гленом Фостером (Glen Foster) <gfoster@driver.nsta.org>, с некоторыми незначительными добавлениями:
Table 12-1. Сетевые карты созданные на основе наборе микросхем DEC PCI
Производитель | Модель |
---|---|
ASUS | PCI-L101-TB |
Accton | ENI1203 |
Cogent | EM960PCI |
Compex | ENET32-PCI |
D-Link | DE-530 |
Dayna | DP1203, DP2100 |
DEC | DE435, DE450 |
Danpex | EN-9400P3 |
JCIS | Condor JC1260 |
Linksys | EtherPCI |
Mylex | LNP101 |
SMC | EtherPower 10/100 (Модель 9332) |
SMC | EtherPower (Модель 8432) |
TopWare | TE-3500P |
Znyx (2.2.x) | ZX312, ZX314, ZX342, ZX345, ZX346, ZX348 |
Znyx (3.x) | ZX345Q, ZX346Q, ZX348Q, ZX412Q, ZX414, ZX442, ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd) |
Вы, наверное, обнаружили, что хост, к которому вы обратились, оказался на самом деле в другом домене; например, если вы находитесь в домене foo.example.org и хотите обратиться к хосту mumble в домене example.org, то должны указать его полное доменное имя, mumble.example.org, а не просто mumble.
Традиционно, это позволял делать ресолвер BSD BIND. Однако текущая версия bind (посмотрите справку по named(8)), поставляемая с FreeBSD, больше не добавляет имена доменов, отличающихся от того, в котором вы находитесь, для не полностью указанных имён хостов. Так что неполно указанный хост mumble будет найден либо как mumble.foo.example.org, либо будет искаться в корневом домене.
Это отличается от предыдущего поведения, при котором поиск продолжался в mumble.example.org и mumble.edu. Посмотрите RFC 1535 о причинах объявления такого поведения плохой практикой и даже ошибкой в безопасности.
Как хорошее решение, вы можете поместить строку
search foo.example.org example.org
вместо ранее используемой
domain foo.example.org
в файл /etc/resolv.conf (посмотрите справку по resolv.conf(5)). Однако удостоверьтесь, что порядок поиска не нарушает ``границ полномочий между местным и внешним администрированием'', как это названо в RFC 1535.
Если вы компилировали ядро с опцией IPFIREWALL, имейте в виду, что политикой по умолчанию является запрет прохождения всех пакетов, которые явно не разрешены.
Если вы случайно неверно отконфигурировали межсетевой экран, то для восстановления работоспособность сети дайте такую команду, войдя суперпользователем:
# ipfw add 65534 allow all from any to any
Также вы можете задать firewall_type='open' в файле /etc/rc.conf.
Более подробная информация о конфигурировании межсетевого экрана в FreeBSD находится в соответствующем разделе Руководства.
Пожалуйста, обратитесь к разделу Руководства о межсетевых экранах, особенно в части, касающейся дополнительной нагрузки от IPFW и оптимизации.
Возможно, потому что вы хотите выполнять трансляцию сетевых адресов (NAT), а не просто перенаправлять пакеты. Правило ``fwd'' делает точно то, что означает; оно перенаправляет пакеты. Данные внутри пакета оно не меняет. Пусть, скажем, у нас имеется правило такого вида:
01000 fwd 10.0.0.1 from any to foo 21
Когда пакет с адресом назначения foo достигает машины с этим правилом, то он перенаправляется на 10.0.0.1, но в нём остаётся адрес назначения foo! Адрес назначения пакета не меняется на 10.0.0.1. Большинство машин, скорее всего, отбросят полученный пакет, имеющий адрес назначения, им не соответствующий. Таким образом, правило ``fwd'' не часто работает так, как ожидает пользователь. Такое поведение является особенностью, а не ошибкой.
Обратитесь к FAQ о перенаправлении сервисов, руководству по natd(8) или одной из нескольких утилит для перенаправления из Коллекции Портов для того, чтобы сделать это правильно.
Вы можете перенаправить запрос на FTP (или другой сервис) с помощью пакаджа socket, доступного в дереве портов в категории ``sysutils''. Просто замените командную строку запуска сервиса на вызов socket, типа:
ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp
где ftp.example.com и ftp являются соответственно хостом и портом для перенаправления.
Для FreeBSD имеются три средства управления трафиком. dummynet(4), интегрированный в систему FreeBSD (более точно, в ipfw(4)); свободно распространяемый ALTQ и коммерческий продукт Bandwidth Manager от Emerging Technologies.
Вы запускаете программу, которой требуется Berkeley Packet Filter (bpf(4)), однако его нет в вашем ядре. Перекомпилируйте ядро, добавив в его конфигурационный файл следующую строку:
pseudo-device bpf # Berkeley Packet Filter
Для FreeBSD 4.X и более ранних версий вы должны также создать файл устройства. После перезагрузки системы перейдите в каталог /dev и выполните команду:
# sh MAKEDEV bpf0
Обратитесь к разделу Руководства, посвящённому созданию файлов устройств за подробной информацией по управлению устройствами.
Используйте пакет SMBFS. В него включён набор изменений в ядре и пользовательские программы. Программы и информация доступны в виде порта net/smbfs из Коллекции Портов или как часть базовой системы в 4.5-RELEASE и более поздних версиях.
12.25. Что значат эти сообщения ``icmp-response bandwidth limit 300/200 pps'' в моих журнальных файлах?
Это ядро сообщает вам, что имела место некоторая активность, приводящая к посылке большего количества ответных пакетов ICMP или сбросов TCP (RST), чем, как предполагается, это следует делать. Ответы ICMP часто генерируются в результате попыток подключения к незанятым портам UDP. Сбросы TCP генерируются в результате попыток подключения к неоткрытым портам TCP. Кроме всяких прочих, такие сообщения могут быть вызваны следующими действиями:
Лобовая атака типа отказ в обслуживании DoS (в отличие от атак в один пакет, которые используют конкретную брешь в защите).
Сканирование портов в попытке осуществить подключение к большому количеству портов (в отличие от проб нескольких известных портов).
Первое число в сообщении указывает вам, какое количество пакетов ядро посылало бы при отсутствии ограничений, а второе число указывает лимит. Вы можете управлять этим ограничением при помощи системной переменной net.inet.icmp.icmplim приводимым ниже способом, где 300 является ограничением на количество посылаемых пакетов в секунду:
# sysctl -w net.inet.icmp.icmplim=300
Если вы не хотите видеть подобные сообщения в журнальных файлах, но хотите использовать это ограничение в ядре, то можете использовать системную переменную net.inet.icmp.icmplim_output для подавления вывода, как это показано здесь:
# sysctl -w net.inet.icmp.icmplim_output=0
И наконец, если вы хотите выключить это ограничение, то можете установить значение системной переменной net.inet.icmp.icmplim (смотрите пример выше) равным 0. Выключение этого лимита не приветствуется по причинам, перечисленным выше.
Это означает, что какое-то устройство в вашей локальной сети использует MAC-адрес в формате, не распознаваемом FreeBSD. Скорее всего, это происходит из-за того, что кто-то в сети экспериментирует с сетевым адаптером. Чаще всего это происходит в сетях с кабельными модемами. Это безобидно и не должно влиять на производительность машины с FreeBSD.
12.27. Я только что установил CVSup, но при попытке его запустить получил сообщения об ошибках. Что не так?
Сначала посмотрите, есть ли среди получаемых вами сообщений то, что показано ниже.
/usr/libexec/ld-elf.so.1: Shared object "libXaw.so.6" not found
Ошибки, подобные этой, возникают при установке порта net/cvsup на машину без пакета XFree86. Если вы хотите использовать GUI, имеющийся в CVSup, то вам нужно теперь установить XFree86. Либо, если вы хотите использовать CVSup только из командной строки, то вы должны удалить ранее установленный пакадж. Затем установите порт net/cvsup-without-gui. Более подробно это описано в разделе о CVSup Руководства.
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.