diff --git a/ru_RU.KOI8-R/articles/console-server/article.sgml b/ru_RU.KOI8-R/articles/console-server/article.sgml index 4af6da7711..0a8ab7edb0 100644 --- a/ru_RU.KOI8-R/articles/console-server/article.sgml +++ b/ru_RU.KOI8-R/articles/console-server/article.sgml @@ -1,1543 +1,1555 @@ %articles.ent; ]>
Консольный сервер + Gregory Bond
gnb@itga.com.au
 + + Андрей + Захватов + Перевод на русский язык: + + + Дмитрий + Морозовский + Перевод на русский язык: + + $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.cisco; &tm-attrib.intel; &tm-attrib.lantronix; &tm-attrib.microsoft; &tm-attrib.opengroup; &tm-attrib.sun; &tm-attrib.general; В этом документе описывается, как можно использовать &os;, аппаратное и программное обеспечение, работающее с &os;, для построения консольного сервера. Консольным сервером обычно называют машину, которую можно использовать для отслеживания консолей многих других машин вместо использования многих последовательных терминалов. консольный сервер Проблема У вас есть компьютерный зал с множеством &unix;-серверов и коммуникационным оборудованием. Каждой этой машине необходима последовательная консоль. Однако последовательные терминалы трудно найти и они достаточно дороги (особенно по сравнению с ПК, обладающими гораздо большими возможностями). И всё это в компьютерном зале занимает много места. Вам необходим доступ к консоли, потому что когда что-то не работает, сообщения об ошибках направляются туда. И некоторые работы выполняются с консоли (к примеру, при возникновении проблем с загрузкой или при установке или обновлении ОС). Некоторые &unix;-системы позволяют переходить с консоли в режим монитора ПЗУ, который иногда является единственным способом заставить функционировать неработающую машину. Часто это осуществляется посылкой LINE BREAK на последовательный порт консоли. Если мы собираемся поработать с консолями, то было бы великолепно осуществить ещё несколько вещей: Удалённый доступ. Даже в одном помещении было бы неплохо иметь доступ ко всем консолям с вашего рабочего места без необходимости передвигаться по компьютерному залу. А иногда машины расположены где-то далеко, может быть, даже в другой стране. Протоколирование. Если что-то идёт не так, вам не помешает возможность посмотреть предыдущую выдачу на консоль, чтобы понять происходящее. Обычные консольные экраны дают вам последние 25 строк. Чем таких строк будет больше, тем лучше. Независимость от сети. Решение должно функционировать даже при неработающей сети. В конце концов, больше всего консоли вам нужны именно при отключении сети! Ещё лучше добиться независимости от сети с возможностью удалённого доступа. Отсутствие одной точки, критичной для работы. Консольная система, которая приводит к неработоспособности всех машин при сбое, не нужна. Это особенно важно при использовании с &unix;-хостами Sun, так как они будут воспринимать выключение терминала как BREAK и будут переходить в режим ROM-монитора. Интерфейс с пейджинговым или другим подобным устройством подачи предупреждающих сообщений. Возможность удалённого выключения и повторного включения машин. Не слишком высокая стоимость. Ещё лучше, если система будет бесплатной! Возможные решения Если для ваших серверов вы используете ПК-оборудование, то одним из возможных решений является KVM-переключатель. Такой KVM-переключатель позволяет использовать одну клавиатуру, видеомонитор и мышь с несколькими системными блоками. Это снижает остроту проблемы с физическим пространством, однако работает только с ПК-оборудованием (а не с любыми типами имеющихся коммуникационных устройств), и не обеспечивает доступ вне компьютерного зала. При этом даже отсутствует прокрутка истории или протоколирование, и вам нужно организовывать оповещение каким-то другим способом. Большим минусом является то, что это не работает с устройствами только с последовательным интерфейсом, таким, как коммуникационное оборудование. Это означает, что даже в зале, заполненном ПК-серверами, вам может оказаться нужным доступ к последовательной консоли. На самом деле, Doug Schache указал, что вы можете найти KVM-переключатели с поддержкой последовательных консолей или совместимые как с Sun, так и с ПК, но они дороги. Посмотрите, например, на сайте Avocent.) Вы можете попытаться обойтись без консольного терминала, однако когда творятся странные вещи, вам действительно нужно видеть происходящее на консоли. И вам нужно использовать консоль для загрузки и выполнения таких действий, как установка или обновление ОС. Вы можете попытаться выделить один консольный терминал и переключаться при необходимости между серверами, либо при помощи последовательного переключателя, либо просто подключая его к нужной машине. Последовательные переключатели также трудно найти и они не дёшевы, к тому же могут иметь проблемы с посылкой сигнала BREAK при переключении. И (если ваш компьютерный зал похож на наш) у вас никогда не будет совпадать комбинация кабелей для подключения к нужной машине, и даже если все кабели на месте, вы никогда с точностью не будете знать, какая именно комбинация окончаний DTE/DCE ведёт к конкретному оборудованию. Так что первые 10 минут вы потратите на возню с исходящими и входящими окончаниями, тогда как сервер не работает, а пользователи уже кричат. Конечно, это не удовлетворяет требованиям удалённого подключения к системе и протоколирования. И неизбежно консоль окажется не подключенной к нужной машине, так что вы потеряете все консольные сообщения, могущие рассказать вам о происходящем. Одним из распространённых решений является использование аппаратного терминального сервера. Обычно последовательные порты подключены к консолям различных машин, и настроены на обратный telnet-доступ. Это значит, что пользователь может подключиться по протоколу telnet к определённому IP/порту и оказаться подключенным к соответствующей консоли. Это может быть очень эффективным с точки зрения стоимости, так как подходящие старые терминальные серверы можно найти по достаточно низкой цене (полагаем, что пары таких у вас ещё нет). И, конечно, они доступны по сети, что подходит для организации управления из сети. Однако у них есть один большой недостаток: если сеть не работает, то вы теряете доступ к любой консоли, даже если находитесь прямо перед машиной. (Это может быть несколько не так, если у вас есть подходящий терминал, подключенный к одному из портов терминального сервера, с которого можно выполнять подключения, но программное обеспечение терминального сервера может этого и не поддерживать.) К тому же при этом отсутствует протоколирование и повтор консольных сообщений. Однако приложив некоторые усилия и используя определённое программное обеспечение, такое, как conserver (описано далее), эту систему можно заставить хорошо работать. Ещё один подход, предложенный Броном Гондваной (Bron Gondwana), похож на описанное выше решение. Если ваши серверы имеют несколько последовательных портов, вы можете подключить каждый свободный последовательный порт к консольному порту ближайшего сервера, создав тем самым кольцо консольных соединений (в некотором порядке). Это может достаточно хорошо работать вместе с программным обеспечением conserver, однако, с другой стороны, может несколько запутывать (в смысле необходимости запоминания, какой порт к какой консоли подключен). И этого не получится, если вам нужно использовать последовательные порты в других целях (таких, как подключение модемов) либо на ваших машинах нет свободных портов. Либо, если ваш бюджет превышает необходимость в хакерских решениях, вы можете приобрести одно из готовых решений. Они различаются по стоимости и своим возможностям. Посмотрите, к примеру, Lightwave, Perle, Avocent или Black Box. Эти решения могут оказаться достаточно дорогими - обычно от 100 до 400 долл. США за порт. Наше решение В свете требований выше мы выбрали решение на основе выделенного ПК под управлением &unix; с многопортовым последовательным адаптером и определённым программным обеспечением, предназначенным для работы с последовательными консолями. Оно состоит из следующих элементов: Подержанный ПК. Мы использовали &pentium; 166 с шиной PCI, 2-гигабайтным жёстким диском и 64 мегабайтами ОЗУ. Это превышает требования выполняемой задачи, более чем достаточным будет P-100, 500 Мб, 32 Мб. &unix;-система для ПК. Мы использовали &os; 4.3, так как в нашем офисе она использовалась и для других задач. Многопортовый последовательный адаптер. Мы выбрали 8-портовый адаптер &easyio; PCI компании Stallion Technologies. Это стоило нам порядка $AUD740, меньше чем $100 за порт, заплаченных Harris Technologies (у них есть много всего, но это не обязательно самое дешёвое место - поищите поблизости, вы можете найти место гораздо дешевле). Адаптер имеет сзади большой разъём DB80 и подключаемый кабель, имеющий блок из 8 гнёзд RJ-45. (Мы выбрали вариант с RJ-45, так как наша кабельная система полностью построена на RJ-45. Это позволяет нам переключать соединения от нужного блока к консольному серверу без дополнительных кабелей.) Это единственная вещь, которую нам пришлось приобрести, чтобы всё заработало. В России, возможно, будет проще найти карты Omega PCI компании КБ "Кроникс" / Cronyx Engineering, менее $40 за порт. [прим. перев.]. Мы построили два сервера, по одному для каждого машинного зала, с 8 портами в одном и 16 портами (двумя адаптерами &easyio; PCI) в другом. Если бы нам нужно было более 16 портов, то по стоимости более эффективным было бы использование других адаптеров Stallion. Теоретически мы можем поддерживать 128 портов на каждом сервере (при помощи 2 хост-адаптеров EasyConnect 8/64 и 8 16-портовых модулей RJ-45) общей стоимостью $AUD12,000. Модем для удалённого доступа к хосту консольного сервере при отсутствии сети. Мы ещё этого не делали, так как компьютерный зал находится рядом, но когда мы перенесем сервер в Сидней, мы добавим модем. Идея заключается в том, что при отсутствии сети вы можете позвонить, подключиться к серверной машине и запустить консольную программу локально. В целях безопасности мы, скорее всего, оставим модем выключенным, и попросим тамошних жителей Сиднея нажать хорошо видную кнопку при необходимости. Программа под названием conserver. Она выполняет всё, что требуется для включения удалённого доступа к консолям, обеспечивает повтор ввода, протоколирование и так далее. Она поставляется в виде двух блоков: сервер под именем conserver, работающий как даемон и подключающийся к последовательным портам, выполняющий ведение журналов и прочие действия, и клиентская программа под названием console, которая может подключаться к серверу, показывать консольные сообщения, посылать последовательности нажатий клавиш (и BREAK) и тому подобное. Такая архитектура обеспечивает выполнение всех основных требований, кроме удалённого управления электропитанием: Удалённый доступ обеспечивается за счёт того, что клиентская программа console работает в сети. Протоколирование ведётся программой conserver. Если сеть не работает, то мы можем использовать консоль ПК для локального запуска клиента console. В случае географически удалённых мест мы можем добавить модем для коммутируемого доступа к командной строке сервера для запуска клиента. Установив патчи на серверы &solaris; (обратитесь к ), мы можем избежать неработоспособности всего компьютерного зала при сбое в консольном сервере на базе ПК (или при отключения электропитания, или по какой-то другой причине). У нас уже есть пейджинговое оповещение с другой установленной нами системы, однако на консольном сервере есть вся нужная информация журналов, так что при необходимости это может быть легко реализовано. И даже есть модем для звонка в пейджинговую компанию! На данный момент мы не поддерживаем удалённое управление электропитанием. Некоторые версии программы conserver это поддерживают, но это требует наличия специальных адаптеров, управляемых через последовательные соединения. У нас нет острой необходимости по удалённому выключению (у нас есть обслуживающий персонал в каждом удалённом офисе, который может это сделать под нашим руководством), так что это не большая проблема, и мы можем легко это добавить, если увидим в этом необходимость и получим соответствующее оборудование. Это решение было очень дешёвым. Общая стоимость 9-портового сервера составила $AUD750 за адаптеры ввода/вывода, так как мы использовали устаревший ПК и у нас имелось оборудование в виде специальных кабелей. Если бы мы всё покупали, то это обошлось бы всего лишь примерно в $AUD1500 за 8-портовый сервер. Настройка сервера Проверка драйвера Stallion &os; адекватно поддерживает адаптеры Stallion начиная с версии 4.4. Если ваша версия старше, вам потребуется обновить ее (это нужно сделать еще и для того, чтобы ваша система не была подвержена известным проблемам защиты). Обратитесь к описанию в файле /usr/src/UPDATING и Руководстве &os; за подробной информацией об обновлении системы. Конфигурация нового ядра Драйвер Stallion не включён в используемое по умолчанию ядро GENERIC, так что вам нужно создать конфигурационный файл ядра с соответствующими записями. Обратитесь к справке по &man.stl.4; и соответствующему разделу Руководства &os;. Создание устройств Для адаптера Stallion вам нужно создать файлы устройств (которые по умолчанию не создаются). Во время выполнения описанной выше процедуры новая версия /dev/MAKEDEV с поддержкой Stallion будет создана утилитой mergemaster. Если у вас имеется адаптер Stallion с более чем 8 портами, то вам нужно отредактировать /dev/MAKEDEV и изменить определение maxport в районе строки 250. По умолчанию MAKEDEV создает файлы устройств для 8 портов, чтобы уменьшить размер каталога /dev. Выполните примерно такую команду: &prompt.root; cd /dev/ && sh MAKEDEV cuaE0 для создания устройств для исходящих звонков для первого адаптера Stallion. Для получения более полной информации обратитесь к разъяснениям в MAKEDEV и справочной странице &man.stl.4;. Компиляция conserver Посмотрите раздел о версиях conserver; используемая мной версия находится в коллекции портов &os;, однако, существуют и другие версии. Имеется два способа установки conserver. Вы можете либо скомпилировать её из исходных текстов, либо воспользоваться механизмом портов &os;. Использование механизма портов Использование портов является более ясным подходом, так как система пакетов может отслеживать установленное программное обеспечение и полностью удалять его, если оно не используется. Рекомендуем использовать порт comms/conserver-com. Перейдите в каталог этого порта и (работая как пользователь root) наберите: &prompt.root; make DEFAULTHOST=consolehost install где consolehost является именем машины, на которой работает консольный сервер. Задание этого при компиляции бинарного файла избавляет от необходимости указывать его каждый раз при запуске программы либо поддерживать файлы conserver.cf для каждого хоста. Эта команда загрузит, установит патчи, сконфигурирует, скомпилирует и установит программу conserver. После этого вы можете выполнить make package для создания бинарного пакета, который можно установить на остальных хостах &os; по команде &man.pkg.add.1;. Для дополнительной гибкости вы можете создать две версии пакета: одну для машины с консольным сервером без параметра DEFAULTHOST, а вторую для всех остальных хостов с параметром DEFAULTHOST. Это значит, что клиентская программа консоли на машине с консольным сервером по умолчанию будет использовать localhost, что будет работать при отсутствии сервера имён, при сбоях в сети, а также позволит выполнять доверяемые (то есть беспарольные) подключения через IP-адрес localhost для пользователей, подключенных к машине с консольным сервером (либо с экрана консоли, либо с вспомогательного модема). Версия для остальных машин с аргументом DEFAULTHOST означает, что пользователи могут просто использовать клиента console без указания каждый раз имени хоста, и необходимости настраивать файл conserver.cf на каждой машине. Из tar-архива исходных текстов Если вы предпочитаете такой способ, то можете загрузить conserver и скомпилировать его самостоятельно. Вам может понадобиться сделать это, если вы хотите установить клиент консоли на не-&os; системы. Мы используем клиент на наших машинах с &solaris;, и он без проблем взаимодействует с сервером на &os;. Это позволяет каждому во всей компании (многие из которых имеют ПК без доступа к хосту с &os; со своего рабочего места) обращаться к консольному серверу. Загрузите файл с FTP-сайта conserver.com. Распакуйте его в любой каталог, затем сконфигурируйте, выполнив &prompt.user; ./configure Параметр помогает избежать указания главного сервера каждый раз при удалённом запуске клиента (или постоянного обновления конфигурационных файлов на всех удалённых хостах). Параметр помогает избежать необходимости в обновлении файла на всех машинах. После этого наберите make и, работая как пользователь root, make install. Конфигурация conserver Программа conserver настраивается через файл с именем conserver.cf. Этот файл обычно находится в каталоге /usr/local/etc и он задокументирован на справочной странице &man.conserver.cf.5;. Наш конфигурационный файл выглядит примерно так: LOGDIR=/var/log/consoles gallows:/dev/cuaE0:9600p:&: roo:/dev/cuaE1:9600p:&: kanga:/dev/cuaE2:9600p:&: %% allow: itga.com.au trusted: 127.0.0.1 buzz Первая строка означает, что по умолчанию все файлы протоколов будут располагаться в каталоге /var/log/consoles. Символ & в каждой строке указывает на то, что файл журнала для этой машины будет называться /var/log/consoles/machine. В следующих трёх строках показаны три машины, к которым нам нужно подключаться. Мы используем устройства cuaEx вместо ttyEx, потому что на консольных портах обычно отсутствует несущая. Это означает, что открытие ttyEx будет зависать, и conserver никогда не сможет осуществить подключение. Использование устройства cuaEx позволяет уйти от этой проблемы. Другим решением будет использование устройств ttyEx и разрешение использования на этим портах программной несущей, возможно, путём установки этого при помощи устройства ttyiEx в файле /etc/rc.serial. Посмотрите комментарии в этом файле для выяснения всех деталей. Также посмотрите &man.sio.4; для получения информации об устройствах с начальным состоянием и с блокированным состоянием. (Драйвер Stallion также поддерживает эти соглашения). И прочтите &man.stty.1; для получения подробностей об установке режимов работы устройств. В последнем разделе указано, что любой пользователь, зарегистрировавшийся на серверной машине, имеет доступ без пароля ко всем консолям. Мы делаем так, потому что на этой машине нет учётных записей пользователей, и она безопасно изолирована от внешнего мира межсетевым экраном. Строка разрешения позволяет всем на этой машине внутри нашей организации иметь доступ к консольному серверу, если он сообщит свой пароль, который записан в файле conserver.passwd (обратитесь к следующему разделу). Задание паролей для conserver Файл conserver.passwd содержит зашифрованную версию пароля каждого пользователя. Файл описан на справочной странице conserver.cf(5). Единственной хитростью является заполнение файла зашифрованными паролями. Во &os; нет единого способа генерации зашифрованных паролей для включения в другой файл (однако смотрите ниже). Так что я наскоро создал хакерский perl-скрипт для этого: @rands = (); foreach (0..4) { push(@rands, rand 64); } $salt = join '', ('.', '/', 0..9, 'A'..'Z', 'a'..'z')[@rands]; $salt = '$1$' . $salt . '$'; print 'Enter password: '; `stty -echo`; $cleartext = <>; `stty echo`; chop($cleartext); print crypt($cleartext, $salt), "\n"; Он использует пароли &os; с MD5-шифрованием. Запуск скрипта на других вариантах &unix; или во &os; с шифрованием паролей DES, скорее всего, потребует другой базы шифрования. Недавно &a.kris; показал, что вы можете достичь того же эффекта при помощи команды openssl passwd: &prompt.user; openssl passwd -1 Password: password $1$VTd27V2G$eFu23iHpLvCBM5nQtNlKj/ Запуск <application>conserver</application> во время загрузки системы Существуют два способа это сделать. Во-первых, вы можете запускать conserver при помощи init, включив строчку в /etc/ttys, подобную следующей: cuaE0 "/usr/local/sbin/conserver" unknown on insecure Здесь есть два преимущества: init перезапустит главный консольный сервер, если по какой-то причине он аварийно завершит свою работу (но мы пока подобных случаев не наблюдали), и он обеспечивает то, что стандартная выдача процесса conserver будет направлена на указанный tty (в этом случае cuaE0). Это полезно, потому что вы можете подключить терминал к порту, а программа conserver выдаст всю консольную выдачу, не попавшую подключенному консольному клиенту. Такое использование полезно в качестве инструмента мониторинга общего характера, чтобы смотреть, что происходит. Мы сделали такой терминал в компьютерном зале видимым из основного офиса. Это очень удобная возможность. Минусом запуска conserver из файла ttys является невозможность его запуска в режиме даемона (либо &man.init.8; будет постоянно его перезапускать). Это значит, что conserver не будет записывать PID-файл, что усложняет смену журнальных файлов. Таким образом, мы запускаем conserver из rc.d-скрипта. Если вы устанавливали conserver как порт, то в каталоге /usr/local/etc/rc.d будет установлен файл conserver.sh.sample. Скопируйте и/или переименуйте его в conserver.sh для того, чтобы заставить conserver запускаться в момент загрузки системы. На самом деле мы используем модифицированную версию этого скрипта, которая также подключает conserver к терминалу посредством tty-устройства, так что мы можем отслеживать незамеченную консольную выдачу. Наш скрипт conserver.sh выглядит примерно так: #!/bin/sh # # Startup for conserver # PATH=/usr/bin:/usr/local/bin case "$1" in 'start') TTY=/dev/cuaE7 conserver -d > $TTY # get NL->CR+NL mapping so msgs look right stty < /dev/cuaE7 opost onlcr echo -n ' conserver' ;; 'stop') kill `cat /var/run/conserver.pid` && echo -n ' conserver' ;; *) echo "Usage: $0 { start | stop }" ;; esac exit 0 Отметьте использование устройства cuaE0 и необходимость задания tty-режимов для правильной обработки последовательностей NL-<CR). Обрезание журнальных файлов Во &os; имеется программа под названием newsyslog, которая будет обслуживать усечение журнального файла в автоматическом режиме. Просто добавьте некоторые строки в конфигурационный файл /etc/newsyslog.conf для журналов консолей: # # The log files from conserver /var/log/consoles/gallows 644 10 1000 * Z /var/run/conserver.pid /var/log/consoles/kanga 644 10 1000 * Z /var/run/conserver.pid /var/log/consoles/roo 644 10 1000 * Z /var/run/conserver.pid Здесь программе newsyslog (которая выполняется по таймеру один раз в каждый час) указывается, что файлы протоколов работы консолей должны архивироваться и сжиматься, как только они достигнут объёма в 1 Мбайт, что мы должны хранить 10 таких журналов, и что для подачи сигнала SIGHUP вы используете PID, записанный в файле conserver.pid. Это главный сервер, и он будет передавать сигнал всем дочерним процессам. Да, он будет посылать сигнал HUP всем клиентам, как только понадобится обновить единственный файл журнала, но это достаточно дёшево. Для выяснения всех подробностей обратитесь к &man.newsyslog.8;. Подключение кабелей Это всегда является самой сложной частью такого рода проблем. Для построения у нас имелось только около десятка кабелей/окончаний к ним, и ещё набор соответствующих инструментов и оборудования, так что мы сделали всё сами. Однако если вы к этому не готовы, либо вам нужно сделать большое количество кабелей, то вам можно приобрести их на заказ. Посмотрите справочники фирм, там найдётся на удивление много мест, где сделают всё нужное! Приобретение кабелей, сделанных на заказ, это хорошо, и вы получите более профессиональный результат, однако это может быть дороговато. К примеру, наборы переходников RJ-45 в DB-25, описываемые ниже, стоят около $10 каждый; кабели на заказ обойдутся примерно в два раза дороже (и будут доставлены через несколько недель). Подобным же образом изготовление переходника RJ-45 в RJ-45 обойдётся достаточно дёшево (скажем, по $5 каждый), но займёт много времени. Заказное гнездо RJ-45 с переходником RJ-45 стоит около $25 каждое. Во всех случаях в офисе и компьютерном заде мы использовали кабель типа RJ-45 Cat-V. Сюда включается проброс монтажных кабелей между стойками в компьютерном зале. Для последовательных соединений мы используем подключаемые соединители, у которых на задней стенке есть гнёзда RJ-45. Это позволяет нам при необходимости организовывать соединения RJ-45–DB-25. Которое также удобно, потому что есть множество неправильных способов организовать последовательные соединения на вилке RJ-45. Так что при пробросе кабелей нужно очень осторожно использовать правильное соответствие. Цветовая разметка RJ-45 Кабели и вилки RJ-45 имеют 8 контактов/проводников. Они используются как 4 соответствующих пары. Имеется несколько соглашений о том, как пары соответствуют контактам, однако в 100baseT используется самый распространённый (известный как EIA 586B). Имеются три распространённых соглашения по цветовому обозначению для отдельных проводников в кабелях RJ-45. Вот они: <!-- XXX: Добавить заголовок для этой таблицы --> Контакт Схема 1 Схема 2 (EIA 568B) Схема 3 (EIA 568A) Пара 1 Синий Белый+Зелёный Белый+Оранжевый 2+ 2 Оранжевый Зелёный Оранжевый 2- 3 Чёрный Белый+Оранжевый Белый+Зелёный 3+ 4 Красный Синий Синий 1+ 5 Зелёный Белый+Синий Белый+Синий 1- 6 Жёлтый Оранжевый Зелёный 3- 7 Коричневый Белый+Коричневый Белый+Коричневый 4+ 8 Белый или Серый Коричневый Коричневый 4-
Заметим, что стандарты EIA 468A and EIA 568B отличаются только цветом 2 и 3 пары. Подробности можно прочитать на сайте технической поддержки Cabletron. Контакты разъема RJ-45 нумеруются с 1 до 8. Первый контакт расположен слева, если держать обжатый кабель разъемом вверх и защелкой от себя. В розетке RJ-45, расположенной защелкой вверх, контакт 1 расположен справа. Вот иллюстрация (бесстыдно стянутая с сайта Cabletron), показывающая все это: В нашем случае мы имели дело с четырьмя видами оборудования: Сервера Sun Консоль сервера Sun работает в режиме DTE (т.е. посылает данные по линии TxD, принимает данные по RxD и активирует сигнал DTR) с разъемом DB-25 "мама". Для консольного сервера на базе Stallion нам потребовались переходники, работающие как DCE и обладающие разъемом DB-25 "папа" (т.е. работающие одновременно как нуль-модем и как переходник RJ-45—DB-25. Мы использовали разборные переходники, содержащие розетку RJ-45, 8 коротких проводов, заканчивающихся контактами DB-25, которые могут произвольно коммутироваться в корпус разъема DB-25. Мы использовали несколько схем соединения, в частности, MOD-TAP part no. 06-9888-999-00 и FA730 series от компании Black Box. Контакты переходников, которые попались нам, были маркированы так (контакты с 1 по 8): Синий, Оранжевый, Черный, Красный, Зеленый, Желтый, Коричневый, Белый (при взгляде со стороны розетки RJ-45, защелка сверху, контакт 1 справа). Они были скоммутированы с разъемом DB-25 вот так: <!-- XXX: Add a title here --> Контакт RJ-45 Stallion Цвет Сигнал Контакт разъема DB-25 "папа" Sun Сигнал RS232 1 Синий DCD 20 DTR 2 Оранжевый RTS 5 CTS 3 Черный Заземление 1 Заземление 4 Красный TxD 3 RxD 5 Зеленый RxD 2 TxD 6 Желтый Сигнальный ноль 7 Сигнальный ноль 7 Коричневый CTS 4 RTS 8 Белый RTS 8 DCD
Для ваших кабелей и переходников цвета могут отличаться. Например, 8 провод может быть серого, а не белого цвета. Не забудьте четко пометить переходник, так чтобы пометка не стерлась и не отвалилась со временем! Маршрутизаторы Cisco 16xx/26xx/36xx Я полагаю, что все продукты Cisco, использующие разъемы RJ-45 для консоли и работающие под управлением &ios;, требуют одинаковых кабелей, но лучше будет дополнительно проверить. Мы работали только с маршрутизаторами серий 1600, 2600 и 3600. И Stallion, и Cisco 2600 используют разъемы RJ-45, но они, разумеется, не совместимы, поэтому вам потребуется специально обжатый (и подключенный в правильной ориентации!) кабель RJ-45-RJ-45. Мы использовали стандартные провода RJ45 от маршрутизаторов до патч-панелей и специально подготовленные от патч-панели до разъемов карты Stallion. Пара специальных кабелей Stallion-Cisco была сделана путем разрезания пополам стандартного двухметрового патч-корда и набивания разъемов RJ-45 на получившиеся свободные концы. Изначальный разъем предназначается для стороны маршрутизатора Cisco, обжатый для Stallion. Цвета проводов (как и прежде, держа кабель разъемом вверх и защелкой от себя, слева направо) в нашем случае были такими: бело-зеленый, зеленый, бело-оранжевый, синий, бело-синий, оранжевый, бело-коричневый, коричневый. Для стороны Stallion следовало обрезать коричневую и зеленую пары. Затем, в уже описанной расстановке, оставшиеся провода коммутировались так: пусто, пусто, синий, оранжевый, бело-оранжевый, бело-синий, пусто, пусто, как показано ниже: <!-- XXX: add title for this table --> Контакт RJ-45 Cisco Цвет Сигнал Cisco Контакт RJ-45 Stallion Сигнал Stallion 1 бело-зеленый RTS N/C   2 зеленый DTR N/C   3 бело-оранжевый TxD 5 RxD 4 синий Gnd 3 Gnd 5 синий Gnd 6 Gnd 6 оранжевый RxD 4 TxD 7 бело-коричневый DSR N/C   8 коричневый CTS N/C  
Вновь отметим, что цвета ваших кабелей и переходников могут отличаться. Аккуратно пометьте каждый конец кабеля и тщательно протестируйте его. Тестирование может стать по-настоящему сложным, поскольку его нельзя произвести при помощи стандартного RJ-45 тестера! Заметим еще раз: убедитесь, что вы пометили новый кабель так, чтобы его было легко сразу опознать как специальный и нельзя было бы перепутать с обычным патч-кордом. Несколько советов от Хью Ирвина (Hugh Irvine): Делайте их из кабеля другого цвета Лучший способ маркировки кабеля, который мне встречался: запаять напечатанную этикетку под прозрачный термоусадочный кембрик на конец кабеля перед разделкой разъема Можно использовать маркеры типа Panduit, прикрепляемые к кабелю стяжками, но на них со временем выцветают чернила. Коммутаторы Cisco &catalyst; Как ни странно, расположение сигналов на контактах консольного порта коммутаторов &catalyst; иногда отличается от используемого в маршрутизаторах Cisco. Я полагаю, что карта сигналов определяется используемым программным обеспечением. Если коммутатор работает под управлением &ios;, применяется раскладка, описанная выше. В противном случае, следует применить хитрость. К счастью, вся разница в расположении сигналов заключается в том, что одна из раскладок является зеркальным отражением другой. Еще радостнее то, что в комплекте с оборудованием Cisco (как с коммутаторами &catalyst;, так и с 2600) поставляется специальный перевернутый (rollover) кабель; он-то нам и нужен. Мы использовали перевернутый кабель для связи консольного порта коммутаторов &catalyst; и патч-панели, а затем описанный выше для Cisco 2600 специальный кабель от патч-панели до карты Stallion. Все прекрасно работало. Перевернутый кабель имеет на обоих концах разъемы RJ-45 и предназначен для использования вместе с переходниками RJ-45 - DB-25 и RJ-45 - DB-9 (также поставляемыми в комплекте; неразборными) для присоединения к консоли. В нашем случае кабель был плоским, длиной около 2 м, голубого или черного цвета. Попытки использовать его как обычный 100-Мбитный сетевой кабель окончатся неудачей! Определить такой кабель легко, если взять оба разъема (кабелем вниз, защелкой от себя) и сравнить цвета контактов. Разъемы должны выглядеть зеркально; в нашем случае это были серый-оранжевый-черный-красный-зеленый-желтый-синий-коричневый с одной стороны, и коричневый-синий-желтый-зеленый-красный-черный-оранжевый-серый с другой. Если у вас нет под рукой перевернутого кабеля, вы можете использовать кабель для маршрутизатора 26xx, перевернув его: исходный разъем с 8 контактами в Stallion, новый с 4 контактами в коммутатор &catalyst;. Сервера &os; (или любые другие системы на базе ПК &i386;, использующие последовательную консоль) Мы используем &os; 4 на паре ПК архитектуры &i386; для различных периферийных нужд. &os; обычно использует экран и клавиатуру в качестве консоли, но может быть сконфигурирована в режим последовательной консоли (как правило, на первый последовательный порт, известный как COM1 в DOS/&windows; или ttyd0 в &unix;). Подключение таких консолей зависит от используемого оборудования. Старые ПК использовали разъем DB-25 "мама", и для них подходит описанный выше вариант для сервера Sun. Для современных ПК с разъемами DB-9 "папа" существуют два варианта: использовать переходник DB9 - DB-25 (не рекомендуется, поскольку со временем такие соединения разбалтываются и ведут к непредсказуемым потерям связи) или собрать кабель RJ-45 - DB-9: <!-- XXX: add title for this table --> Контакт RJ-45 Stallion Цвет Сигнал Контакт DB-9 "мама" Сигнал RS232 1 Синий DCD 4 DTR 2 Оранжевый RTS 8 CTS 3 Черный Защитная земля N/C   4 Красный TxD 2 RxD 5 Зеленый RxD 3 TxD 6 Желтый Сигнальный ноль 5 Сигнальный ноль 7 Коричневый CTS 7 RTS 8 Белый RTS 1 DCD
См. также раздел . В нем вы найдете советы по конфигурированию последовательной консоли в &os;. Про системы Sun и сигнал Break Всякий, кто хоть раз выключал терминал, используемый в качестве консоли для сервера Sun, знает, что происходит в результате и почему это является проблемой. Оборудование Sun считает сигнал BREAK на консоли командой остановить систему и вернуться в монитор загрузчика. Сигнал BREAK — специальный срочный сигнал последовательного порта, заключающийся в активизации (установки в уровень ниже -5 В) сигнала TxD на время большее чем требуется на передачу двух символов (около 2 мс для скорости 9600 bps). К сожалению, этот сигнал часто возникает при включении или выключении коммуникационного оборудования. В частности, карты Stallion также генерируют BREAK при отключении питания компьютера. Если не предпринимать специальных действий, это может привести к остановке всех серверов Sun, подключенных к консольному серверу, при его отключении (при отказе блока питания, или в результате неосторожных действий оператора, или по еще каким-либо причинам). Ясно, что такая ситуация неприемлема. К счастью, у компании Sun есть набор исправлений. Для ОС &solaris; версии 2.6 и более поздних, при помощи команды kbd(1) можно запретить переход в монитор загрузчика по сигналу BREAK. Это уже неплохо для начала, но лишает вас шансов восстановить повисшую машину, вернув ее в загрузчик. Начиная с &solaris; версии 8, команду kbd можно использовать для установки альтернативной последовательности прерывания: kbd -a alternate. После активации, для возврата в монитор загрузки необходимо в течение 5 секунд выдать последовательность: Return ~ CtrlB. Эта возможность может быть включена на постоянной основе путем редактирования файла /etc/default/kbd; подробнее см. справочную страницу kbd(1). Отметим, что альтернативная последовательность активируется после перехода ядра в многопользовательский режим и обработки файла начальных установок. В период начальной загрузки (включение питания и в процессе загрузки ядра) и в однопользовательском режиме для возврата в монитор загрузки нужно использовать сигнал BREAK. Из консольного клиента его можно активировать последовательностью Esc c l 1. Если у вас есть сервисный контракт с компанией Sun, вы можете скачать патчи, реализующие альтернативную последовательность прерывания, для &solaris; версий 2.6 и 2.7. &solaris; 2.6 требует патча 105924-10 или выше; &solaris; 2.7 — 107589-02 или выше. Мы применили этот патч на всех наших серверах &solaris; 2.6 и добавили его (вместе с установкой для файла /etc/default/kbd) в стартовую конфигурацию, так чтобы любой новый сервер автоматически был правильно сконфигурирован. Наши тесты показали, что ни маршрутизаторы Cisco 16xx, 26xx, ни коммутаторы &catalyst; не подвержены проблеме сигнала BREAK, возникающего при потере питания картой Stallion. В настоящее время маршрутизаторы и коммутаторы Cisco реагируют на сигнал BREAK только в течение первых 30 секунд после включения питания или перезагрузки. Использование последовательной консоли в &os; Подробно эта процедура описана в отдельной главе Руководства &os;. Здесь мы приводим краткий перечень. Проверьте конфигурацию ядра Проверьте, что файл конфигурации ядра содержит flags 0x10 в строке, описывающей устройство sio0. Этот флаг разрешает использование устройства (известного также как COM1 в DOS/&windows; или как /dev/ttyd0 в &os;) в качестве консоли. Флаг установлен в обоих примерах стандартной конфигурации ядра (GENERIC и LINT), так что, скорее всего, он установлен и в вашем ядре. Создайте файл <filename>/boot.conf</filename> file Этот файл должен состоять из одной строки, содержащей только -h (без кавычек). Этот флаг указывает загрузочным блокам &os; переключиться на последовательную консоль. Отредактируйте файл <filename>/etc/ttys</filename> Необходимы следующие изменения: Если вы не собираетесь подключать клавиатуру и монитор к этому серверу, найдите все строки для устройств ttyv, таких как ttyv1 "/usr/libexec/getty Pc" cons25 on secure Замените on на off. Это запретит запуск утилит регистрации на ненужных более видео консолях. Найдите строку, содержащую ttyd0. Измените ее с ttyd0 "/usr/libexec/getty std.9600" dialup off secure на ttyd0 "/usr/libexec/getty std.9600" vt100 on secure (замените vt100 на тип терминала вашей консоли. Хорошим выбором может быть xterm). Это позволит вам зарегистрироваться на консоли после того, как система перейдет в многопользовательский режим. Перезагрузитесь — и все! Соображения безопасности Протокол "клиент-сервер" утилиты conserver требует от пользователя клиентской утилиты console ввода пароля. Этот пароль передается по сети в открытом виде! Как следствие, утилита conserver не особенно пригодна для использования в небезопасных сетях (в том числе в интернет). Использование уникальных паролей для conserver слегка смягчает проблему, однако любой, кто способен прослушать сетевой трафик между клиентом и сервером conserver, может легко получить консольный доступ, а с консоли использовать последовательность прерывания. Для удаленной работы используйте какие-либо защищенные протоколы, такие как SSH для регистрации на консольном сервере и запускайте консольный клиент непосредственно оттуда. Различные версии Conserver Программа conserver расслоилась на несколько независимых версий. Сайт, упоминаемый ниже, судя по всему, содержит последнюю и наиболее полную версию из доступных. На момент написания статьи (июль 2004 г.) это версия 8.1.9. Сайт поддерживается Брайаном Стэнселлом (Bryan Stansell), bryan@conserver.com, который свел воедино работу многих разработчиков (перечислены на его сайте). Коллекция портов &os; содержит conserver версии 8.5 в каталоге comms/conserver. Судя по всему, он более старый, и содержит меньше возможностей, чем 8.1.9 (в частности, не поддерживает консоли, соединенные с портами терминальных серверов, или файл паролей conserver.passwd), а также написан довольно своеобразно (используя препроцессор для генерации исходного текста на языке C). Версия 8.5 ведется Кевином Браунсдорфом (Kevin S. Braunsdorf) ksb+conserver@sa.fedex.com, в прошлом основным автором conserver; Брайан основывался на его разработках. Версия 8.5 поддерживает одну возможность, не поддерживаемую 8.1.9: управление питанием удаленных машин через специальный контроллер, управляемый по последовательному порту. Начиная с декабря 2001 г., версия Брайана (в настоящее время 8.1.9) присутствует в дереве портов в каталоге comms/conserver-com. Мы рекомендуем использовать именно ее как более подходящую для построения консольного сервера. Ссылки Сайт последней версии программы conserver. ftp://ftp.conserver.com/conserver/conserver-8.1.9.tar.gz Архив исходных текстов для версии 8.1.9 программы conserver. Сайт компании Stallion Technologies. Написанный Дэвидом Харрисом (Davis Harris) Малый Свиток Знаний о Консолях, содержащий массу полезной информации о последовательных консолях и вообще о последовательных портах. Большой Свиток Знаний о Консолях содержит еще более подробную информацию о соединении одних устройств с другими. О, эти Стандарты! Дуг Хьюджес (Doug Hughes) создал схожий консольный сервер на основе утилиты screen и старой машины под управлением &sunos;. Компания Real Weasel производит видеокарты для шин ISA или PCI, в реальности производящие вывод в последовательный порт. Они могут использоваться для консолей ПК в тех операционных системах, которые не могут быть сконфигурированы в режим последовательной консоли достаточно рано в процессе загрузки. Справочные страницы console(8) conserver(8) conserver.cf(5)
diff --git a/ru_RU.KOI8-R/articles/explaining-bsd/article.sgml b/ru_RU.KOI8-R/articles/explaining-bsd/article.sgml index 5d9e211388..991c7a7fe6 100644 --- a/ru_RU.KOI8-R/articles/explaining-bsd/article.sgml +++ b/ru_RU.KOI8-R/articles/explaining-bsd/article.sgml @@ -1,654 +1,662 @@ %articles.ent; ]>
Что такое BSD Greg Lehey
grog@FreeBSD.org
 &tm-attrib.freebsd; &tm-attrib.amd; &tm-attrib.apple; &tm-attrib.linux; &tm-attrib.opengroup; &tm-attrib.sun; &tm-attrib.xfree86; &tm-attrib.general; В мире программ с открытыми исходниками, слово Linux практически стало синонимом слова Операционная Система, хотя это далеко не единственная операционная система &unix;, исходные коды которой доступны широкой публике. Согласно данным Internet Operating System Counter, в апреле 1999-го 31,3% всех подключённых к Internet машин работали под Linux. 14,6% использовали BSD &unix;. Некоторые из мировых лидеров в области Web-услуг, например Yahoo!, работают под BSD. Самый загруженный в мире FTP-сервер 1999 года (сейчас он не работает), ftp.cdrom.com, функционировал под управлением BSD и передавал 1,4 Тбайта данных в день. Очевидно, что это не узкий, специализированный рынок: можно сказать, что BSD — это тщательно скрываемая тайна. Так в чём же секрет? Почему известность BSD оставляет желать лучшего? Эта публикация ставить целью ответить на эти и другие вопросы. На протяжении всего текста обращайте внимание на выделенные отличия BSD от Linux. Что такое BSD? BSD означает Berkeley Software Distribution. Так называлось программное обеспечение, распространявшееся в исходных кодах Калифорнийским Университетом в Беркли, которое сначала представляло из себя дополнения к операционной системе &unix; компании AT&T. На основе версии 4.4BSD-Lite были созданы несколько операционных систем с открытыми исходными кодами. В их состав включены разработки других проектов, среди которых особо следует выделить Проект GNU. Вот что такое собственно операционная система BSD: Ядро BSD, отвечающее за планировку процессов, управление памятью, поддержку многопроцессорных систем (SMP), работу с устройствами и так далее. В отличие от Linux, существует несколько ядер BSD, отличающихся возможностями. Библиотека C, основной системный интерфейс программирования. Библиотека C в BSD основывается на коде из Беркли, а не из Проекта GNU. Оболочки, файловые утилиты, компиляторы, редакторы связей и другие утилиты пользователя. Некоторые из них базируются на коде GNU, а некоторые -- нет. Система X Window, отвечающая за графический интерфейс. Система X Window, которая используется в большинстве версий BSD, поддерживается одним из двух различных проектов, либо проектом &xfree86;, либо проектом X.Org. Речь идёт о том же самом коде, что используется в Linux. BSD, как правило, не делает упор на какую-то специфическую графическую среду, например, GNOME или KDE, хотя обе они доступны. Множество разных других прикладных и системных программ. Что, настоящий &unix;? Операционные системы BSD не являются клонами друг друга. Они лишь потомки общего предка, ОС &unix; от AT&T Research, которая также дала начало современной ОС &unix; System V. Это факт может удивить, если вспомнить, что AT&T никогда не открывала исходные коды своих разработок. Действительно, &unix; никогда не был программным обеспечением с открытым исходным кодом, и в законном смысле BSD определённо НЕ &unix;. Но с другой стороны, в AT&T активно использовали чужие разработки, например программное обеспечение, разрабатываемое Группой по Исследованиям в области Информатики (CSRG) Калифорнийского Университета в Беркли. С 1976 CSRG выпускала свой код на магнитных лентах под названием Berkely Software Distribution, сокращённо BSD. Изначально дистрибутивы BSD представляли собой наборы пользовательских программ, и так было до тех пор, пока CSRG не заключила контракт с Агентством по Перспективным Проектам при Министерстве Обороны США (DARPA). Целью контракта было обновление коммуникационных протоколов, на которых держалась компьютерная сеть агентства -- ARPANET. Новое семейство протоколов получило имя Internet Protocols или TCP/IP, по названиям двух основных протоколов. Их первая широко известная реализация была выпущена в составе 4.2BSD в 1982 году. В течение восьмидесятых годов образовалось несколько компаний по производству рабочих станций. Многие из них предпочли купить лицензию на &unix;, нежели разрабатывать своё ПО с нуля. Следует отметить компанию Sun, которая поступила именно таким образом и на основе 4.2BSD выпустила свою операционную систему &sunos;. Когда AT&T тоже решила заняться коммерческой продажей своей ОС &unix;, появилась на свет несколько аскетичная реализация под названием System III, за которой в скором времени последовала System V. Интересно, что эти версии не содержали в себе собственной поддержки работы в сети и использовали код BSD, в том числе реализацию TCP/IP и набор утилит, среди которых следует выделить оболочку csh и текстовый редактор vi. Все эти добавки совместно получили название Berkely Extensions. Дистрибутив BSD содержал код, принадлежавший AT&T, и, следовательно, требовал лицензии. К 1990 году финансирование CSRG прекратилось, и группа была распущена. Кое-кто из бывших членов группы решил опубликовать код BSD отдельно от закрытого кода AT&T. В концов концов это удалось, и так появилась на свет версия Networking Tape 2 или Net/2. Net/2 не была законченной, цельной операционной системой: около 20% кода ядра отсутствовало. Один из членов CSRG, William F. Jolitz, дописал недостающий код и опубликовал результат в начале 1992 года под именем 386BSD. В то же самое время другая группа бывших членов CSRG организовала коммерческую компанию Berkeley Software Design Inc. и выпустила бета-версию операционной системы BSD/386, которая базировалась на том же самом коде. Позже это название было изменено на BSD/OS. 386BSD так никогда и не стала полноценной операционной системой. Зато в 1993 году из неё выделились два проекта: NetBSD и FreeBSD. Изначально разработчики разделились на два лагеря из-за расхождений во мнениях относительно того, сколько же ещё можно ждать улучшений в 386BSD. В начале года образовалась NetBSD, а первая версия FreeBSD была готова только к его концу. Время шло, и технические различия возрастали. Вдобавок проекты поставили перед собой разные цели, как будет показано ниже. В 1996 году от NetBSD отделился ещё один проект — OpenBSD, а в 2003 году от FreeBSD отделилась DragonFlyBSD. Почему BSD недостаточно известна? Действительно, существует ряд причин этому недоразумению: Разработчики BSD часто больше заинтересованы в качестве своего кода и заняты его шлифовкой, а не рекламой. По большому счёту Linux своей популярностью обязан прежде всего внешним по отношению к проекту факторам, например средствам массовой информации и компаниям, которые решили сделать бизнес на предоставлении услуг пользователям Linux. Разработчики BSD, как правило, более опытны, чем разработчики Linux, и в силу этого часто уделяют меньше внимания облегчению жизни простым пользователям. Новичок чувствует себя более комфортно в среде Linux. В 1992 году компания AT&T подала в суд на BSDI, компанию-поставщика ОС BSD/386. Основным пунктом обвинения было то, что BSD/386 содержала в себе закрытый код, принадлежавший AT&T. Дело вроде бы уладили за пределами суда в 1994-ом, но целая серия вторичных тяжб и по сей день отравляет жизнь многим людям. Совсем недавно, в марте 2000, в Internet была опубликована статья, утверждавшая, что судебное разбирательство окончательно завершено (recently settled). В результате разбирательства прояснился вопрос с названиями: если в 80-х годах BSD была известна под именем BSD &unix;, то с исключением последних следов кода, принадлежавшего AT&T, BSD потеряла право называться &unix;. Вы можете заметить этот факт по изменившимся заглавиям книг: операционная система 4.3BSD &unix; и операционная система 4.4BSD. Существует мнение, что проекты BSD сильно отличаются и, в добавок, воюют между собой. Статья в Wall Street Journal называет это балканизацией среди проектов BSD. Можно утверждать, что такое мнение, как и описанная судебная тяжба, основывается прежде всего на событиях давно минувших дней. Сравнение BSD и Linux В чём заключается главная разница, к примеру, между Debian Linux и FreeBSD? Для среднего пользователя она на удивление мала: оба продукта представляют собой &unix;-подобные операционные системы. Оба продукта разрабатываются на некоммерческой основе (это не относится к некоторым другим дистрибутивам Linux). В этом разделе мы рассмотрим BSD в сравнении с Linux. Всё сказанное в основном будет касаться FreeBSD, которой принадлежит около 80% всех инсталляций BSD в мире, хотя отличия от NetBSD, OpenBSD и DragonFlyBSD в рамках предмета данной статьи незначительны. Кому принадлежит BSD? Нельзя сказать, что какой-то конкретный человек или корпорация владеет BSD. Разработка и распространение ведутся группой высококвалифицированных и преданных проекту специалистов со всего мира. Некоторые компоненты BSD представляют собой отдельные проекты с открытым кодом со своими законами и коллективами разработчиков. Как выглядит процесс разработки и обновления BSD? Ядра BSD используют Open Source модель разработки. Каждый проект поддерживает публично доступное дерево исходников с помощью Concurrent Versions System (CVS). Это дерево содержит абсолютно весь исходный код проекта, а также документацию и вспомогательные файлы. CVS позволяет пользователям получить копию дерева любой версии системы. Огромное число людей со всего мира участвуют в совершенствовании BSD. Все они разделены на три группы: Контрибуторы пишут код или документацию. Они не могут добавлять или изменять код непосредственно в дереве исходников проекта. Это привилегия особым образом зарегистрированных разработчиков, или коммиттеров (committers), которые просматривают и тестируют присылаемый им код и включают его в дерево. Коммиттеры являются разработчиками, которые имеют доступ на запись в дерево исходных кодов проекта. Чтобы стать коммиттером, человек должен проявить себя в той области, в которой он хочет работать. Каждый коммиттер по своему собственному усмотрению решает, нужно ли ему подтверждение правильности планируемых изменений от других разработчиков или нет. В общем случае опытный коммиттер может вносить очевидно выгодные изменения ни с кем не советуясь. К примеру, коммиттер проекта документации может исправлять опечатки или грамматические ошибки в документах без предварительного согласования. Напротив, далеко идущие или просто сложные изменения настоятельно рекомендуется представлять к обсуждению перед окончательным внесением в дерево. Бывают крайние случаи, когда член Core Team, выполняющий функцию архитектора проекта, может санкционировать немедленную отмену или откат каких-то изменений в дереве. Все коммиттеры обязательно получают уведомление о каждом изменении в дереве по электронной почте, так что их невозможно сохранить в тайне. Правление (Core Team). В проектах FreeBSD и NetBSD имеются управляющие советы, которые занимаются координационной деятельностью. Их роль, права и обязанности не всегда чётко определены. Необязательно (хотя в порядке вещей) быть коммиттером для того, чтобы входить в состав Core Team. Правила, которым следует Core Team, различаются между проектами, но в общем случае члены Core Team определяют общее направление развития системы в большей степени, чем все остальные разработчики. Такое положение вещей отличается от принятого в Linux: Не существует человека, который бы контролировал содержимое системы. На практике значение этого отличия оказывается переоценённым, так как Ведущий Архитектор может всегда потребовать откат изменений. Ко всему прочему, в проекте Linux на современном этапе изменения в код вносятся тоже не одним, а несколькими людьми. С другой стороны, существует центральное хранилище (repository), откуда можно получить полный код всей системы, причём как современных, так и предыдущих версий. Проекты BSD являются цельными Операционными Системами, а не просто ядрами. Это различие тоже иногда переоценивают: ни BSD, ни Linux не представляют ценности без приложений, а они порой одни и те же в обеих средах. В результате формализованной процедуры поддержки единого дерева исходников в CVS процесс разработки BSD является полностью открытым, и мы получаем возможность доступа к любой версии системы по номеру или по дате. CVS также очень хорошо подходит для последовательных изменений в коде: к примеру, хранилище кода FreeBSD обновляется около ста раз за день, и большинство этих изменений весьма малы и незначительны в отдельности друг от друга. Версии BSD FreeBSD, NetBSD и OpenBSD предоставляет миру три различных варианта системы. Как и в Linux, версиям присваиваются номера, например 1.4.1 или 3.5. В добавок, номер версии имеет суффикс -- обозначение варианта, которое указывает на цели той или иной версии. Версия для разработчиков носит название CURRENT. FreeBSD присваивает ей и номер, например FreeBSD 5.0-CURRENT. NetBSD использует чуть-чуть другую схему наименований и добавляет к номеру однобуквенный суффикс, обозначающий изменения во внутренних интерфейсах. Пример: NetBSD 1.4.3G. OpenBSD не нумерует разрабатываемую версию (OpenBSD-current). Все новые разработки производятся именно на этой ветке (branch) системы. Через определённые интервалы от 3 до 6 месяцев проект выпускает версию RELEASE, которая распространяется на CD-ROM и доступна для скачивания с серверов FTP. Примерами таких версий могут служить OpenBSD 2.6-RELEASE и NetBSD 1.4-RELEASE. Этот вариант предназначен для конечных пользователей. NetBSD также предоставляет так называемые исправленные релизы (patch releases), обозначаемые третьей цифрой в номере, например NetBSD 1.4.2. По мере обнаружения ошибок в версии RELEASE необходимые исправления вносятся в дерево CVS. Получающаяся система в проекте FreeBSD носит название STABLE, а в NetBSD и OpenBSD продолжает называться RELEASE. Некоторые мелкие улучшения тоже иногда вносятся в эту версию после продолжительного периода тестирования в CURRENT. Linux, напротив, поддерживает два различных дерева исходников, которые называются соответственно стабильной версией и версией для разработчиков. Стабильные версии имеют чётный вторичный номер, например 2.0, 2.2 или 2.4. Версии для разработчиков используют нечётные номера, такие как 2.1, 2.3 или 2.5. Во обоих случаях, к двойному номеру версии добавляется ещё одно число, указывающее на конкретный релиз. Стоит также отметить, что каждый поставщик предоставляет свой собственный вариант пользовательских программ (userland), так что имя дистрибутива тоже имеет значение. Естественно, что поставщики нумеруют свои изделия каждый по-своему, и, таким образом, мы получаем что-то вроде TurboLinux 6.0 с ядром 2.2.14. Какие существуют варианты BSD? В отличие от многочисленных дистрибутивов Linux, в мире существует лишь четыре крупных BSD проекта с открытыми исходными кодами. Каждый из них поддерживает своё собственное дерево исходников и своё собственное ядро. На практике однако оказывается, что пользовательские части (userland) различных BSD отличаются гораздо меньше, чем у разных дистрибутивов Linux. Цели каждого из проектов не поддаются чёткой формулировке. Различия между ними весьма субъективны. В основном, проект FreeBSD нацелен на повышение производительности и простоту в использовании конечными пользователями. FreeBSD очень ценят в среде Web-хостеров. Эта ОС работает на нескольких аппаратных платформах, в том числе системах на базе процессоров i386 (ПК), системах, построенных на 64-разрядных процессорах AMD, системах &ultrasparc;, системах, работающие на базе процессоров Alpha компании Compaq, а также системах, построенные по спецификациям NEC PC-98. Число пользователей FreeBSD значительно превышает число пользователей других проектов. проект NetBSD ставит целью максимальную мобильность (или переносимость) кода: девиз конечно NetBSD работает на этом. NetBSD поддерживает машины от крошечных палмтопов до огромных серверов и использовалась NASA в космических миссиях. Это хороший выбор для старой не-Intel аппаратуры. проект OpenBSD нацелен на безопасность и чистоту кода. С помощью комбинирования концепций открытых исходников и скрупулёзного анализа кода проект демонстрирует чудеса корректности работы системы. В силу названных причин совершенно естественно, что OpenBSD выбирают организации, для которых очень важна защита информации, например банки, фондовые биржи и различные департаменты правительства США. Также как и NetBSD, проект поддерживает целый ряд аппаратных платформ. Целью DragonFlyBSD является достижение высокой производительности и масштабируемости в любой ситуации—как для одиночных однопроцессорных, так и крупных кластерных систем. DragonFlyBSD ставит перед собой несколько долгосрочных технических задач, но основной упор делается на создание инфраструктуры для работы с SMP, которая была бы проста для понимания, поддержки и ведения в ней разработок. Следует упомянуть ещё две операционных системы BSD &unix;, которые не предоставляют публичного доступа к своим исходным кодам. Это BSD/OS компании BSDI и &macos; X компании Apple. BSD/OS являлась самым старым из потомков 4.4BSD. Исходный код был недоступен широкой публике, хотя лицензия на него стоила относительно немного. BSD/OS во многом похожа на FreeBSD. Через два года после поглощения BSDi компанией Wind River Systems, BSD/OS перестала существовать как отдельный продукт. Поддержку и исходный код ещё можно получить у Wind River, но все новые разработки сосредоточены на встраиваемой операционной системой VxWorks. &macos; X — это самая последняя версия операционной системы для линейки компьютеров &macintosh; компании Apple Computer Inc. Ядро этой операционной системы, Darwin, построенное на коде BSD, доступно в виде полностью функциональной операционной системы с открытым кодом для компьютеров архитектур x86 и PPC. Однако код графической системы Aqua/Quartz и многих других проприетарных компонентов &macos; X остаётся закрытым. Несколько разработчиков Darwin являются также коммиттерами FreeBSD и наоборот. В чём отличие между лицензией BSD и Общественной Лицензией GNU (GPL)? Linux распространяется на условиях лицензии GNU General Public License (GPL), русский перевод которой тоже существует. Эта лицензия имеет целью уничтожить программное обеспечение с закрытым исходным кодом. В частности, любое ПО, базирующееся на продукте, выпущенном на условиях лицензии GPL, тоже должно поставляться с исходными кодами по первому требованию. Лицензия BSD не накладывает таких жёстких ограничений: разрешается распространение программного обеспечения в двоичном виде (binary-only). Этот факт привлекает разработчиков встроенных (embedded) приложений. Что ещё следует знать? То обстоятельство, что приложений для BSD существует меньше, чем для Linux, вынудило разработчиков BSD позаботиться о создании дополнительной совместимости с Linux, которая позволяет запускать программы для Linux на компьютере, работающем под BSD. Программный пакет, обеспечивающий совместимость, включает в себя как ядерную реализацию системных вызовов Linux, так и разнообразные файлы, необходимые программам, скомпилированным для Linux, например библиотеку C. Разница в скорости выполнения Linux-приложений на машине с Linux и на такой же машине с BSD незаметна. Принцип вся система от одного поставщика, используемый в BSD, приводит к упрощению процедур обновления системы по сравнению с многими дистрибутивами Linux. BSD предоставляет специальные модули совместимости с устаревшими версиями системных библиотек, и таким образом делает возможным запуск откомпилированных несколько лет назад программ на обновлённой системе. Что же выбрать, BSD или Linux? Во что выливается всё вышесказанное на практике? Кому предназначена BSD, и кому -- Linux? Это действительно очень сложный вопрос. Приведём несколько советов, которые призваны помочь Вам с выбором: Не тронь, пока работает: если Вы уже успешно используете какую-нибудь Open Source ОС, и она Вас устраивает, то пожалуй не стоит ничего менять. Системы BSD, в особенности FreeBSD, могут демонстрировать большую по сравнению с Linux производительность. Но это вовсе не универсальное правило. Во многих случаях эта разница не заметна, если вообще есть. Иногда Linux может работать лучше, чем FreeBSD. В общем случае, у систем BSD очень хорошая репутация, когда дело касается надёжности. Это, в основном, связано с более зрелой базой исходных кодов. + + BSD проекты имеют более лучшую репутацию за качество и + полноту документации. Различные проекты документирования + ставят своей целью предоставлять активно изменяющуюся + документацию, в том числе и на нескольких языках и покрывающую все + аспекты системы. + + Лицензия BSD иногда может быть более привлекательной, нежели GPL. В BSD может работать большинство исполнимых файлов Linux, однако в Linux выполнимые файлы BSD запускаться не будут. Во многих реализациях BSD могут также выполняться двоичные файл и других &unix;-подобных систем. Таким образом, BSD может предложить более простой способ перехода с других систем, чем Linux. Кто предоставляет техническую поддержку, обслуживание и обучение для систем BSD? BSDi / FreeBSD Mall, Inc. уже около десяти лет предлагает контракты на поддержку FreeBSD. Кроме того, каждый из проектов постоянно обновляет список консультантов, которые оказывают поддержку за отдельную плату: FreeBSD, NetBSD и OpenBSD.
diff --git a/ru_RU.KOI8-R/articles/laptop/article.sgml b/ru_RU.KOI8-R/articles/laptop/article.sgml index 64606d1d11..e40ed7388e 100644 --- a/ru_RU.KOI8-R/articles/laptop/article.sgml +++ b/ru_RU.KOI8-R/articles/laptop/article.sgml @@ -1,302 +1,302 @@ %articles.ent; ]>
FreeBSD на лэптопах $FreeBSD$ - Перевод на русский язык &a.bvs; + Перевод на русский язык Виталий Богданов FreeBSD, за некоторым исключением, прекрасно работает на большинстве лэптопов. Далее обсуждаются вопросы, специфичные для работы FreeBSD на лэптопах, которые касаются аппаратных требований, отличающихся от настольных компьютеров. &tm-attrib.freebsd; &tm-attrib.linux; &tm-attrib.microsoft; &tm-attrib.general; FreeBSD часто воспринимается как операционная система для серверов, но она прекрасно работает и на настольных компьютерах, а если вы захотите использовать ее на вашем лэптопе, то вы получите все обычные преимущества: строгое распределение дискового пространства, простота администрирования и обновления, система портов/пакаджей для установки программного обеспечения и так далее. (Ее остальные преимущества, такие, как стабильность, высокая производительность сетевых операций и производительность при большой нагрузке, конечно, могут быть необычными для лэптопа.) Однако при ее установке на лэптопы часто возникают проблемы, которых нет на настольных машинах и редко обсуждаются (лэптопы, гораздо чаще, чем настольные машины, тонко настроены под µsoft.windows;). Эта статья предназначена для обсуждения этих проблем. Есть люди, которые задокументировали свой опыт работы с &os; на отдельных моделях лэптопов на web страничках, не являющихся частью &os; документации. Вы наверняка найдете некоторую информацию, если воспользуйтесь вашим любимым поисковиком, введя в нём модель лэптопа и слово &os;. Дополнительно существует специфичная для &os; база данных, цель которой давать информацию по аппаратным вопросам, связанным с лэптопами, Список лэптопов, совместимых с &os;. Если вы хотите пообщаться с другими пользователями &os; на лэптопах, используйте список рассылки &a.mobile.name;. Вы также можете получить дополнительную информацию о использовании лэптопов во &os; по адресу . &xorg; Последние версии &xorg; работают с большинством графических адаптеров, применяемых в лэптопах в настоящее время. Ускорители могут не поддерживаться, но обычная конфигурация для SVGA будет работать. Обратитесь к документации по вашему лэптопу для выяснения того, какой адаптер используется и к документации по &xorg; для определения, поддерживается ли этот адаптер. Если он не поддерживается, используйте стандартное устройство (не пытайтесь использовать название, которое просто выглядит похожим). Вы можете попытать счастья с командой Xorg -configure, которая автоматически распознает много конфигураций. Часто проблема заключается в настройке монитора. Доступные источники информации по &xorg; посвящены CRT-мониторам, подбор подходящего режима работы для LCD-монитора может оказаться не простым занятием. Вам может повезти и вам не придется указывать режим, или будет достаточно указать подходящие параметры HorizSync и VertRefresh. Если это не сработает, лучше всего обратиться к ресурсам Интернет, посвященным настройке X на лэптопах (часто это сайты, ориентированны на Linux, но это не имеет значения, так как в обеих системах используется &xorg;) и скопировать режим, опубликованный кем-то с похожим оборудованием. Большинство лэптопов поставляются с двумя кнопками на позиционирующем устройстве, что достаточно проблематично в X (так как средняя кнопка часто используется для вставки текста); вы можете поставить в соответствие одновременное нажатие на левую и правую кнопки в вашей конфигурации X нажатию на среднюю кнопку строчкой Option "Emulate3Buttons" в файле xorg.conf в разделе InputDevice. Модемы Лэптопы обычно поставляются со встроенными (интегрированными на плате) модемами. К сожалению, это практически всегда означает, что это winmodemы, функциональность которых реализована программно, и для них обычно имеются драйверы только для &windows; (хотя начали появляться некоторые драйверы и для других операционных систем; например, если у вашего модема Lucent LT чипсет, то он будет поддерживаться портом comms/ltmdm). Если это ваш случай вам нужно приобрести внешний модем; самым компактным решением, наверное, является модем стандарта PC Card (PCMCIA), что обсуждается ниже, но модемы с последовательным интерфейсом или интерфейсом USB могут оказаться дешевле. В общем, обычные (не-winmodem) модемы должны работать нормально. Устройства PCMCIA (PC Card) Большинство лэптопов поставляются с разъемами PCMCIA (также называемые PC Card); они прекрасно поддерживаются во FreeBSD. Просмотрите (при помощи &man.dmesg.8;) сообщения, выдаваемые при загрузке, и определите, были ли они правильно распознаны (слоты должны распознаваться как pccard0, pccard1 и так далее на устройствах типа pcic0). &os; 4.X поддерживает 16-разрядные карты PCMCIA, а &os; 5.X поддерживает как 16-разрядные, так и 32-разрядные (CardBus). База данных поддерживаемых карт находится в файле /etc/defaults/pccard.conf. Просмотрите его, и при покупке старайтесь выбрать карты, перечисленные здесь. Карты, не указанные здесь, могут также работать как стандартные устройства: в частности, большинство модемов (16-битных) должны работать нормально, при условии, что это не win-модем (они существуют и в варианте PC-карт(PC Cards), так что будьте внимательны). Если ваша карта распознается как обычный модем, заметьте, что по умолчанию в файле pccard.conf задана пауза в 10 секунд (во избежание зависания некоторых модемов); это может оказаться излишним для вашего модема, так что вы можете изменить это значение, уменьшим его или убрав совсем. Некоторые разделы pccard.conf могут потребовать редактирования. Проверьте строчку с irq и обязательно удалите любые значения, которые уже используются: в частности, если у вас есть встроенный звуковой адаптер, уберите irq 5 (в противном случае вы получите сбой при попытке вставить карту). Проверьте также наличие доступных слотов для памяти; если ваша карта не распознана, попробуйте изменить значение на одно из других разрешенных (они перечислены на справочной странице &man.pccardc.8;). Запустите даемон &man.pccardd.8;, если он еще не запущен. Для запуска его при загрузке добавьте в файл /etc/rc.conf строчку pccard_enable="YES" Теперь ваши карты должны обнаруживаться, когда вы их вставляете и вытаскиваете, и вы должны получать диагностические сообщения о появлении новых устройств. Перед релизом &os; 4.4 в коде pccard произошли большие изменения (включая перенаправление прерываний ISA для тех машин, с PCI BIOS которых &os; работать не может). Если у вас возникли проблемы, попробуйте обновить вашу систему. Управление электропитанием К сожалению, оно не очень надежно поддерживается во FreeBSD. Если вам повезло, то некоторые функции могут работать нормально; либо они не будут работать вовсе. Чтобы сделать вещи немножко сложнее, существует два стандарта по управлению электропитанием: APM и ACPI, последний заменяет собой первый и включает больше возможностей, но также вносит больше проблем. Некоторые лэптопы поддерживают и APM и ACPI (в разной степени), другие поддерживают только один из них, поэтому возможно вам придётся поэкспериментировать с обоими для получения надёжного управления питанием на вашем лэптопе. Вы не можете иметь одновременно включенными APM и ACPI, даже если если ваш лэптоп поддерживает и тот и другой стандарты. APM The APM (Advanced Power Management) BIOS предоставляет поддержку различных возможностей по управлению электропитанием, таких как ожидание (standby), приостановление (suspend), режим пониженного электропотребления (hibernation), замедление тактовых импульсов CPU (CPU clock) и так далее, и доступен во &os; 4.X и &os; 5.X. Чтобы включить поддержку APM, вы можете скомпилировать ядро с поддержкой управления электропитанием (device apm0 во &os; 4.X и device apm во &os; 5.X). Во &os; 5.X имеется модуль ядра для APM. Чтобы загрузить модуль ядра поддержки APM во время загрузки добавьте строчку apm_load="YES" в /boot/loader.conf. Во &os; 5.X, вам также нужно установить hint.apm.0.disabled="0" в /boot/device.hints. Вы можете запустить APM во время загрузки посредством добавления apm_enable="YES" в файл /etc/rc.conf. Вы возможно также захотите запустить даемон &man.apmd.8;, добавив apmd_enable="YES" в /etc/rc.conf, который позаботится о различных событиях APM, посылаемых к BIOS, так чтобы вы могли иметь на вашем лэптопе приостановление/продолжение работы с помощью нажатия некой функциональной клавиши на клавиатуре или с помощью закрытия/открытия крышки. Команды APM перечислены в справочной странице &man.apm.8;. К примеру, apm -b выдаёт статус батарей (или 255, если не поддерживается), apm -Z переводит лэптоп в режим ожидания, apm -z (или zzz) приостановит его. Для выключения и отключения машины от питания, воспользуйтесь командой shutdown -p. И снова, некоторые или все эти функции могут не работать нормально или не работать вовсе. Вы можете обнаружить, что переключение режимов suspension/standby лэптопа работает в режиме консоли, но не работает в режиме X (то есть экран не восстанавливается); если вы используйте &os; 5.X, то возможным решением может быть добавление options SC_NO_SUSPEND_VTYSWITCH в ваш конфигурационный файл ядра и перекомпилирование ядра. Другое решение - это переключение на виртуальную консоль (при помощи CtrlAltF1 или другой функциональной клавиши) и запуск &man.apm.8;. Если вы используйте &man.apmd.8;, вы можете автоматизировать это с помощью &man.vidcontrol.1;. Просто отредактируйте /etc/apmd.conf и измените его на: apm_event SUSPENDREQ { exec "vidcontrol -s 1 < /dev/console"; exec "/etc/rc.suspend"; } apm_event USERSUSPENDREQ { exec "vidcontrol -s 1 < /dev/console"; exec "sync && sync && sync"; exec "sleep 1"; exec "apm -z"; } apm_event NORMRESUME, STANDBYRESUME { exec "/etc/rc.resume"; exec "vidcontrol -s 9 < /dev/console"; } ACPI ACPI (Advanced Configuration and Power Management Interface) предлагает не только управление электропитанием, но и платформенное обнаружение оборудования (platform hardware discovery) (вытесняющее PnP и PCI BIOS). ACPI доступен только в &os; 5.X и включён по умолчанию, поэтому вам не нужно ничего специально делать чтобы включить его. Вы можете контролировать поведение ACPI с помощью &man.acpiconf.8;. К сожалению, поставщики часто поставляют лэптопы с некорректной реализацией ACPI, и поэтому наличие включённого ACPI иногда вызывает больше проблем, чем приносит пользы, вплоть до того, что вы не можете даже загрузить &os; на некоторых машинах со включённым ACPI. Если ACPI вызывает проблемы, проверьте, не выпустил ли поставщик вашего лэптопа новую версию BIOS, устраняющую некоторые ошибки. Так как реализация ACPI в &os; до сих пор быстро развивающийся код, вы также можете обновить вашу систему, поэтому есть шансы, что ваши проблемы исправлены. Если вы хотите отключить ACPI, добавьте hint.acpi.0.disabled="1" в файл /boot/device.hints. Вы можете временно отключить ACPI на стадии загрузчика, набрав команду unset acpi_load, если у вас имеются проблемы с загрузкой машины со включённым ACPI. &os; 5.1-RELEASE и последующие релизы содержат загрузочное меню, с помощью которого можно контролировать загрузку &os;. Одна из предлагаемых опций - это отключение ACPI. Итак, чтобы выключить ACPI, просто выберите пункт 2. Boot &os; with ACPI disabled в меню. Управление электропитанием дисплея X window system (&xorg;) также включает в себя систему управления электропитанием дисплея (обратитесь к справочной странице по &man.xset.1; и поищите там ключевое слово dpms). Вы можете захотеть поэкспериментировать с этой функцией. Однако это также на лэптопах работает нестабильно; часто дисплей выключается не полностью.
diff --git a/ru_RU.KOI8-R/articles/linux-comparison/article.sgml b/ru_RU.KOI8-R/articles/linux-comparison/article.sgml index 3a9107e898..91706a09e6 100644 --- a/ru_RU.KOI8-R/articles/linux-comparison/article.sgml +++ b/ru_RU.KOI8-R/articles/linux-comparison/article.sgml @@ -1,559 +1,564 @@ %articles.ent; ]>
&os;: Open Source альтернатива &linux; Dru Lavigne
dru@isecom.org
 2005 Dru Lavigne $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.linux; &tm-attrib.unix; &tm-attrib.general; &legalnotice; Цель данной статьи - объяснить некоторые из характеристик и преимуществ, предоставляемых &os;, и где возможно, сравнить эти характеристики с &linux;. Эта статья предоставляет начальную точку для тех, кто заинтересован в изучении Open Source альтернатив Линуксу. Введение &os; - это &unix; подобная операционная система, основанная на Berkeley Software Distribution. Хотя и &os; и &linux; обычно воспринимаются, как очень похожие, существуют различия: &linux; сам по себе - ядро. Дистрибутивы (например: Red Hat, Debian, Suse и другие) предоставляют установщик и утилиты доступные пользователю. На http://www.linux.org/dist представлен список, в котором перечислено более 300 существующих дистрибутивов. Предлагая пользователю максимум гибкости, существование такого количества дистрибутивов также увеличивает сложность применения навыков при переходе с одного дистрибутива на другой. Дистрибутивы отличаются не только легкостью установки и доступными программами, а также расположением каталогов, доступными командными оболочками, оконными менеджерами и процедурами установки и корректирования (patching) программного обеспечения. &os; - это полноценная операционная система (ядро и пользовательское окружение) с хорошо зарекомендовавшим себя наследием, уходящим своими корнями в истоки разработки Unix.[1] Так как и ядро и предлагаемые утилиты находятся под контролем одной группы по выпуску релизов - меньше вероятность несовместимости библиотек. Уязвимости в безопасности также могут быстро обнаруживаться командой по безопасности. Когда появляются новые утилиты или возможности ядра пользователю просто надо прочесть один файл (Release Notes, Замечания по релизу), который публично доступен на главной странице веб-сайта &os;. &os; имеет большую и хорошо организованную программную базу, которая гарантирует, что изменения будут осуществляться быстро и под контролем. Существует несколько тысяч программистов, которые вносят код на регулярной основе, но только около 300 из них имеют, так называемый, коммит бит и могут напрямую вносить изменения в ядро, утилиты и официальную документацию. Группа подготовки релизов (release engineering team) проводит качественный контроль, а команда офицеров по безопасности (security officer team) ответственна за реакцию на инциденты, связанные с безопасностью. В дополнение, существует основная выбираемая группа из 8 главных коммитеров, которые определяют общее направление Проекта. В противоположность сказанному, изменения в Linux ядро должны ждать одобрения мейнтейнером исходного кода ядра, Линусом Торвальдсом (Linus Torvalds). Варианты того, как вносятся изменения в дистрибутивы могут сильно различаться. Всё зависит от размеров каждой конкретной программной базы дистрибутива и организационного метода. Хотя и &os; и &linux; используют Open Source модель лицензирования, сами лицензии различаются. Linux ядро находится под GPL лицензией, а &os; использует BSD лицензию. Эти и другие Open Source лицензии более детально описаны на веб-сайте Open Source Инициатива. Ведущая философия GPL - гарантия того, что код останется в рамках Open Source; это достигается путём наложения ограничений на распространение кода под лицензией GPL. BSD лицензия, наоборот, не накладывает таких ограничений, что даёт возможность выбора между содержанием кода в рамках Open Source или закрытием кода в проприетарном коммерческом продукте.[2] Наличие стабильного и надёжного кода под заманчивой BSD лицензией значит, что многие операционные системы, такие как Apple OS X базируются на коде FreeBSD. Это также означает, что если вы выберете использование кода в ваших проектах под лицензией BSD, вы сможете сделать это без угрозы будущей юридической ответственности. Характеристики &os; Поддерживаемые платформы &os; имеет репутацию безопасной, стабильной операционной системы для &intel; (&i386;) платформы. Тем не менее, &os; также поддерживает следующие архитектуры: alpha amd64 ia64 &i386; pc98 &sparc64; В дополнение, продолжается работа по портированию &os; на следующие архитектуры: &arm; &mips; &powerpc; Постоянно обновляющиеся списки поддерживаемого оборудования поддерживаются для каждой архитектуры, так чтобы вы быстро могли посмотреть поддерживается ли ваше оборудование. Для серверов имеется отличная поддержка аппаратного RAID и сетевых интерфейсов. &os; также является великолепной рабочей станцией и операционной системой для лэптопов! Она поддерживает X Window System, ту же, что используется в &linux; дистрибутивах для обеспечения настольного пользовательского интерфейса. FreeBSD также поддерживает более 13,000 простых в установке приложений от третьих лиц, включая KDE, Gnome и OpenOffice. Существует несколько проектов, призванных облегчить установку &os; в качестве десктопа. Наиболее заметные: + DesktopBSD, задающийся + целью создать стабильную и мощную операционную систему для + десктоп пользователей. + FreeSBIE, предоставляющий LiveCD для &os;. PC-BSD, предоставляющий простой в использовании GUI установщик для &os;, ориентированный на десктоп пользователя. Расширяемые подсистемы &os; предлагает большое количество расширяемых подсистем, что позволяет вам настроить FreeBSD окружение под ваши собственные нужды. Некоторые из основных подсистем: Netgraph Netgraph - это модульная сетевая подсистема, которая может использоваться для дополнения существующей сетевой инфраструктуры ядра. Крючки (hooks) используются для того чтобы позволить разработчикам создавать собственные модули. Как результат, быстрое создание прототипа и промышленное развертывание улучшенных сетевых сервисов может выполняться гораздо легче и с меньшим количеством ошибок. Многие существующие работающие модули поставляются с FreeBSD и включают поддержку: PPPoE ATM ISDN Bluetooth HDLC EtherChannel Frame Relay L2TP, вот лишь некоторые из них. GEOM GEOM - это модульная дисковая подсистема трансформации запросов ввода-вывода. Так как это съёмный уровень в системе хранения, это позволяет быстро разрабатывать и полностью интегрировать в подсистему хранения FreeBSD новые сервисы, связанные с хранением. Несколько примеров где это может пригодиться: Создание решений на основе RAID. Предоставление полной криптографической защиты хранимой информации. Более новые версии FreeBSD предлагают много административных утилит для использования существующих GEOM модулей. Например, кто-нибудь может создать зеркало диска, используя &man.gmirror.8;, страйп (stripe), используя &man.gstripe.8; и разделяемое секретное устройство, используя &man.gshsec.8;. GBDE GBDE, GEOM Based Disk Encryption (Шифрование Диска на Основе GEOM) предоставляет сильную криптографическую защиту и может использоваться для защиты файловых систем, swap устройств и других видов применений носителей информации. Плюс ко всему, GBDE прозрачно шифрует целые файловые системы, а не только индивидуальные файлы. Никогда не зашифрованный текст не окажется на блине жёсткого диска. MAC MAC, Mandatory Access Control (Принудительный контроль доступа) предоставляет хорошо регулируемый доступ к файлам и предназначен для улучшения традиционной авторизации операционной системы, представленной разрешениями файлов. Так как MAC реализован в виде модульной подсистемы, FreeBSD система может быть сконфигурирована для любой требуемой политики, варьирующейся от HIPAA согласованности до нужд системы военного класса. &os; поставляется с модулями, реализующими следующие политики; тем не менее подсистема позволяет вам разработать любую требующуюся политику: Biba integrity model Port ACLs MLS или Multi-Level Security confidentiality policy LOMAC или Low-watermark Mandatory Access Control data integrity policy Process partition policy PAM Как и &linux;, &os; имеет поддержку PAM, Pluggable Authentication Modules (Подключаемые модули аутенфикации). Это позволяет администратору улучшить традиционную &unix; модель аутенфикации, логин/пароль. &os; предлагает модули для интегрирования во многие механизмы аутенфикации, включая: Kerberos 5 OPIE RADIUS TACACS+ Они также позволяют администратору определять политики контролирования вопросов, связанных с аутенфикацией, таких как качество паролей выбираемых пользователями. Безопасность Безопасность очень важна для Группы подготовки релизов FreeBSD. This manifests itself in several concrete areas: Все инциденты и исправления, связанные с безопасностью проходят через Команду по безопасности и выпускаются, как публично доступные Бюллетени по безопасности (Advisories). Команда по безопасности имеет хорошую репутацию за быстрое решение известных проблем с безопасностью. Полная информация относительно процедур работы с безопасностью во FreeBSD и где искать информацию по безопасности доступна на . Одна из проблем, связанная с Open Source программным обеспечением - это точное количество пригодных приложений. Существуют почти что десятки тысяч проектов Open Source приложений, и каждый с различными уровнями ответной реакции на инциденты, связанные с безопасностью. &os; приняла этот вызов вместе с VuXML. Всё программное обеспечение, поставляемое с операционной системой FreeBSD, так же, как и любое программное обеспечение доступное в Коллекции портов сравнивается с базой данных известных, неисправленных уязвимостей. Администратор может использовать &man.portaudit.1; утилиту, чтобы быстро определить, есть ли на &os; системе уязвимое программное обеспечение, и если есть, получить описание проблемы и URL, содержащее более детальное описание уязвимости. &os; также предоставляет множество механизмов, которые позволяют администратору настраивать операционную систему под его нужды, связанные с безопасностью: Утилита &man.jail.8; позволяет администратору заключать процесс в тюрьму; это идеально для приложений, которые не имеют собственного chroot окружения. Утилита &man.chflags.1; улучшает безопасность, предлагаемую традиционными Unix разрешениями. Она может, к примеру, предотвратить изменение или удаление указанных файлов даже суперпользователем. &os; предлагает 3 встроенных, поддерживающих NAT файерволов, предлагая больше возможностей для выбора набора правил наиболее подходящего для нужд безопасности. Ядро &os; легко модифицируется, позволяя администратору убирать ненужную функциональность. &os; также имеет поддержку загрузочных модулей ядра и предоставляет утилиты для просмотра, загрузки и выгрузки модулей ядра. Механизм sysctl позволяет администратору просматривать и изменять состояние ядра на лету без перезагрузки. Поддержка Как и &linux;, &os; предлагает много видов поддержки, как свободно доступных, так и коммерческих. Бесплатные предложения &os; - одна из лучше всего документированных операционных систем, и документация доступна и как часть операционной системы, так и в Интернете. Страницы справочника конкретны, кратки и предоставляют рабочие примеры. В Руководство по FreeBSD предоставляет вводную информацию и примеры конфигурации почти для каждой задачи, которую кто-то захочет решить, используя &os;. &os; предлагает много поддерживаемых списков рассылки, где ответы архивируются и полностью доступны для поиска. Если у вас есть вопрос, который не затрагивается Руководством, он почти наверняка уже отвечался в списке рассылки. И Руководство и списки рассылки также доступны на нескольких языках, все из которых легко доступны с . Существует множество IRC каналов, посвящённых FreeBSD, форумов и групп пользователей. Смотрите для выбора. Если вы ищите администратора &os;, разработчика или поддерживающий персонал пошлите описание работы, включающее географическое местоположение в freebsd-jobs@FreeBSD.org. Коммерческие предложения Существует много поставщиков, которые занимаются коммерческой поддержкой &os;. Ресурсы по поиску поставщика, находящегося поблизости от вас включают в себя: Страничка коммерческих поставщиков на сайте &os;: FreeBSDMall, который продаёт контракты на поддержку примерно 10 лет: База данных BSDTracker на: Существует также инициатива по сертификации системных администраторов BSD. . Если ваш проект требует Common Criteria certification, &os; включает подсистему TrustedBSD MAC для облегчения процесса сертификации. Преимущества выбора &os; Существует много преимуществ для включения решений &os; в вашу IT инфраструктуру: &os; хорошо документирована и следует множеству стандартов. Это позволит вашим существующим вспомогательным и опытным системным администраторам быстро приспособить их существующие Linux и Unix навыки для администрирования FreeBSD. Разработчики, работающие из дома имеют полный доступ ко всему коду FreeBSD[4] всех релизов вплоть до первого выпущенного. Вместе с кодом включены все лог сообщения, которые предоставляют контекст для изменений и исправлений ошибок. Дополнительно, разработчик может легко скопировать любой релиз, просто закачав код с требуемой меткой. В противоположность сказанному, &linux; по традиции не следовал данной модели, но недавно адаптировал более совершенную модель разработки. [5] Разработчики, работающие из дома также имеют полный доступ к FreeBSD базе данных сообщений об ошибках, GNATS. Они могут и запрашивать и прослеживать существующие ошибки также, как и предоставлять свои патчи на одобрение и возможное внесение в базовый код FreeBSD. BSD лицензия позволяет вам свободно модифицировать код, чтобы он подходил для ваших бизнес целей. В отличии от GPL, не существует ограничений в том, как вы выберете распространять конечный программный продукт. Заключение &os; - это зрелая &unix;-подобная операционная система, включающая в себя множество возможностей, которые можно ожидать в современной &unix; системе. Для тех, кто хочет внедрить Open Source решение в их существующую инфраструктуру, &os; будет хорошим выбором. Приложение Краткая история на . Довольно объективный взгляд на качества каждой лицензии можно посмотреть на . Используя Коллекцию портов FreeBSD: для установки программного обеспечения достаточно просто набрать pkg_add -r имя_приложения. Плюс ко всему, весь код доступен через веб-интерфейс: . Интересный обзор развивающейся модели разработки Linux может быть найден на .