diff --git a/ru_RU.KOI8-R/articles/console-server/Makefile b/ru_RU.KOI8-R/articles/console-server/Makefile index 890f58d80c..e8a458caf4 100644 --- a/ru_RU.KOI8-R/articles/console-server/Makefile +++ b/ru_RU.KOI8-R/articles/console-server/Makefile @@ -1,26 +1,26 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/console-server/Makefile,v 1.3 2004/09/06 07:19:39 marck Exp $ # -# Original revision: r21827 +# Original revision: r39631 # # Article: Console Server # DOC?= article FORMATS?= html WITH_ARTICLE_TOC?= YES INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml IMAGES_EN= tk0231-9-1.png URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/console-server/article.xml b/ru_RU.KOI8-R/articles/console-server/article.xml index c850b30717..d4261ad96e 100644 --- a/ru_RU.KOI8-R/articles/console-server/article.xml +++ b/ru_RU.KOI8-R/articles/console-server/article.xml @@ -1,1529 +1,1529 @@
Консольный сервер GregoryBond
gnb@itga.com.au
 АндрейЗахватовПеревод на русский язык: ДмитрийМорозовскийПеревод на русский язык: &tm-attrib.freebsd; &tm-attrib.cisco; &tm-attrib.intel; &tm-attrib.lantronix; &tm-attrib.microsoft; &tm-attrib.opengroup; &tm-attrib.sun; &tm-attrib.general; $FreeBSD$ $FreeBSD$ В этом документе описывается, как можно использовать &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.email; показал, что вы можете достичь того же эффекта при помощи команды 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. Мы рекомендуем использовать именно ее как более подходящую для построения консольного сервера. Ссылки http://www.conserver.com/ Сайт последней версии программы conserver. ftp://ftp.conserver.com/conserver/conserver-8.1.9.tar.gz Архив исходных текстов для версии 8.1.9 программы conserver. http://www.stallion.com/ Сайт компании Stallion Technologies. http://www.conserver.com/consoles/msock.html Написанный Дэвидом Харрисом (Davis Harris) Малый Свиток Знаний о Консолях, содержащий массу полезной информации о последовательных консолях и вообще о последовательных портах. http://www.conserver.com/consoles/ Большой Свиток Знаний о Консолях содержит еще более подробную информацию о соединении одних устройств с другими. О, эти Стандарты! http://www.eng.auburn.edu/users/doug/console.html Дуг Хьюджес (Doug Hughes) создал схожий консольный сервер на основе утилиты screen и старой машины под управлением &sunos;. http://www.realweasel.com/ Компания Real Weasel производит видеокарты для шин ISA или PCI, в реальности производящие вывод в последовательный порт. Они могут использоваться для консолей ПК в тех операционных системах, которые не могут быть сконфигурированы в режим последовательной консоли достаточно рано в процессе загрузки. Справочные страницы console(8) conserver(8) conserver.cf(5)
diff --git a/ru_RU.KOI8-R/articles/contributing/Makefile b/ru_RU.KOI8-R/articles/contributing/Makefile index 688f593070..7154591fa3 100644 --- a/ru_RU.KOI8-R/articles/contributing/Makefile +++ b/ru_RU.KOI8-R/articles/contributing/Makefile @@ -1,25 +1,25 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/contributing/Makefile,v 1.1 2005/05/25 17:54:31 andy Exp $ # # Article: Contributing to FreeBSD # -# Original revision: r21373 +# Original revision: r39631 # DOC?= article FORMATS?= html WITH_ARTICLE_TOC?= YES INSTALL_COMPRESSED?=gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/contributing/article.xml b/ru_RU.KOI8-R/articles/contributing/article.xml index ebdcce765d..cf105cb5a1 100644 --- a/ru_RU.KOI8-R/articles/contributing/article.xml +++ b/ru_RU.KOI8-R/articles/contributing/article.xml @@ -1,535 +1,535 @@
Участие в проекте FreeBSD В этой статье описаны различные способы, которыми отдельные лица и организаций могут принять участие в Проекте FreeBSD. ДжорданХаббардТекст предоставил &tm-attrib.freebsd; &tm-attrib.ieee; &tm-attrib.general; $FreeBSD$ $FreeBSD$ участие Итак, вы хотите внести свой вклад во FreeBSD? Это великолепно! Жизнеспособность FreeBSD основана на помощи её пользователей. Ваша помощь не только принимается, она жизненно необходима для продолжения роста FreeBSD. Несмотря на уверения некоторых людей, вам не нужно быть гениальным программистом или персоной, лично связанной с руководящей группой FreeBSD, чтобы ваша помощь была принята. FreeBSD разрабатывает большое и увеличивающееся количество участников со всего мира, самого разного возраста и разных областей технической экспертизы. Работы, которую необходимо сделать, всегда больше, чем разработчиков, могущих её выполнить, и дополнительная помочь всегда приветствуется. Проект FreeBSD занимается операционной системой в целом, а не только ядром или несколькими отдельными утилитами. Таким образом, в нашем TODO-списке широкий спектр задач: от документации, бета-тестирования и презентаций до программы установки системы и специфических разработок уровня ядра. Люди любого уровня практически в любой области определённо смогут помочь проекту. Коммерческие структуры, связанные с использованием FreeBSD, также приглашаются к диалогу. Нужны ли вам особые расширения, для работы вашего продукта? Вы увидите, что мы отвечаем на ваши запросы, если они не слишком необычны. Вы работаете над дополнительными продуктами? Дайте нам знать! Мы сможем работать вместе над некоторыми его аспектами. Мир свободного программного обеспечения ставит под сомнение многие существующие представления о том, как программного обеспечение разрабатывается, продаётся и поддерживается, и мы настоятельно просим вас посмотреть на него ещё раз. Что нужно В следующем перечне представлены задачи и подпроекты, являющиеся некоторым отражением различных списков TODO и запросов пользователей. Текущие задачи не для программистов Многие люди, связанные с FreeBSD, не являются программистами. В Проекте участвуют создатели документации, Web-дизайнеры и специалисты по поддержке пользователей. Все, что им нужно для участия, это своё время и желание учиться. Периодически читайте FAQ и Руководство. Если что-то описано плохо, устарело или даже полностью неправильно, дайте нам знать. Ещё лучше, если вы пришлёте нам исправление (выучить Docbook не так сложно, но и против посланий в формате ASCII никто возражать не будет). Помогите перевести документацию FreeBSD на ваш родной язык. Если документация на вашем языке уже существует, вы можете помочь перевести дополнительные документы или проверить, не устарели ли переводы. Первым делом взгляните на FAQ по переводам в Учебнике проекта документирования FreeBSD. Вас не призывают перевести все документы FreeBSD — как доброволец, вы можете делать столько переводов, сколько захотите. Если кто-то начал перевод, другие всегда присоединятся. Если у вас есть время и желание перевести одну часть документации, пожалуйста, переведите инструкции по установке. Время от времени (или даже регулярно) читайте &a.questions; и &ng.misc;. Вам может понравиться делиться своим опытом и помогать людям решать их проблемы; иногда вы сможете узнать для себя что-то новое! Эти форумы могут также стать источником идей, над которыми вам стоит поработать. Текущие задачи для программистов Большинство задач, перечисленных здесь, требуют либо значительных затрат времени, либо глубоких знаний ядра FreeBSD, либо того и другого. Однако имеется также много полезных задач, которые подойдут для воскресных хакеров. Если вы работаете с FreeBSD-CURRENT и обладаете хорошим подключением к Internet, то существует машина current.FreeBSD.org, которая строит полный релиз ежедневно—сейчас и всегда. Попробуйте установить самый последний релиз с этой машины и сообщите обо всех обнаруженных при этом ошибках. Читайте &a.bugs;. Здесь может встретиться проблема, которую вы сможете конструктивно прокомментировать или патчи, которые вы можете протестировать. Либо вы можете даже попытаться исправить какую-то проблему самостоятельно. Если вы знаете о существовании каких-либо исправлений ошибок, успешно применённых к -CURRENT, но ещё не перенесённых в -STABLE после достаточно большого интервала времени (обычно несколько недель), направьте коммиттеру вежливое напоминание. Перенос стороннего программного обеспечения в каталог src/contrib дерева исходных текстов. Проверка актуальности кода в каталоге src/contrib. Построение из дерева исходных текстов (или её части) с включением режима дополнительных предупреждений, избавление от них. Исправление предупреждений от портов, которые используют недопустимые вызовы типа gets() или включают файл объявлений malloc.h. Если вы создавали порты и вам приходилось делать специфичные для &os; исправления, пошлите ваши патчи авторам оригинального программного обеспечения (это упростит вам жизнь при выпуске следующей версии). Найдите копии официальных стандартов, например, &posix;. Вы можете найти несколько ссылок на них на странице Web-сайта Проекта соответствия FreeBSD стандартам C99 & POSIX. Сравните поведение FreeBSD с тем, что определено стандартом. Если реакция отличается, особенно в незначительных или непонятных разделах спецификации, направьте об этом PR. Если можете, найдите, как исправить это и включите в PR патч. Если вы полагаете, что в стандарте есть ошибка, направьте запрос его разработчикам. Предложите дополнительные задачи для этого списка! Работа с базой сообщений об ошибках PR база сообщений об ошибках Список сообщений об ошибках FreeBSD содержит все актуальные сообщения о проблемах и запросы на улучшения, которые были посланы пользователями FreeBSD. База данных PR содержит задачи как для программистов, так и не для них. Просмотрите открытые PR, найдите те, что привлекут ваше внимание. Некоторые из них могут быть очень простыми, требующими лишь ещё одной пары глаз, чтобы посмотреть и подтвердить, что предлагаемое в PR исправление достаточно. Другие могут быть гораздо сложнее и даже вовсе не содержать исправления. Начните с тех PR, которые никому ещё не назначены. Если PR уже за кем-то закреплено, но содержит проблему, которую вы можете решить, направьте по электронной почте письмо человеку, которому назначено это PR, и спросите, можете ли вы поработать над ней—у них уже может готов патч для тестирования или какие-то идеи, которые можно вместе обсудить. Выберите один из пунктов со странички <quote>идей</quote> Список проектов и идей для добровольцев также доступен для людей, желающих помочь проекту &os;. Список постоянно обновляется и содержит пункты, как для программистов, так и для не программистов, с информацией о каждом проекте. Как принять участие в работе Характер участия в работе над системой обычно подпадает под одну или несколько из следующих 5 категорий: Сообщения об ошибках и отзывы общего характера Идеи или пожелания общего технического характера должны направляться по электронной почте в адрес &a.hackers;. Подобным же образом тот, кто интересуется такими вещами (и устойчив к большому потоку почты!) может подписаться на список рассылки &a.hackers;. Обратитесь к Руководству FreeBSD для получения дополнительной информации об этом и других списках рассылки. Если вы нашли ошибку или предлагаете внести какое-то конкретное исправление, пожалуйста, отправьте сообщение при помощи программы &man.send-pr.1; или её Web-эквивалента. Постарайтесь заполнить все поля в сообщении об ошибке. Если его размер оно не превышает 65 Кбайт, включите все патчи непосредственно в сообщение. Если патч предназначен для дерева исходных текстов, поместите [PATCH] в теме сообщения. При включении патчей не используйте технику cut-and-paste, потому что при этом символы табуляции преобразуются в пробелы и патч становится непригодным к использованию. Если объём патчей превышает 20 Кбайт, лучше включать их в сообщение в сжатом виде, для чего упакуйте их (например, при помощи &man.gzip.1; или &man.bzip2.1;) и обработайте архив утилитой &man.uuencode.1;. После отправки сообщения вы должны получить подтверждение и номер для отслеживания. Сохраните этот номер, чтобы использовать его в дальнейшем при направлении подробностей о проблеме по электронной почте на адрес &a.bugfollowup;. Используйте номер в качестве темы письма, например, "Re: kern/3377". Дополнительная информация о любом сообщении об ошибке должна направляться этим способом. Если вы не получили подтверждения в течение разумного периода времени (от 3 дней до недели, в зависимости от вашего подключения к электронной почты) или по какой-то причине не можете воспользоваться командой &man.send-pr.1;, то можете попросить кого-нибудь направить сообщение за вас на адрес &a.bugs;. Прочтите также эту статью, чтобы узнать, как писать хорошие сообщения о проблемах. Изменения в документации посылка документации Изменения в документации обсуждаются в &a.doc;. Пожалуйста, посмотрите Учебник Проекта документирования FreeBSD для получения полных инструкций. Посылайте свои пожелания и изменения (принимаются даже самые небольшие!) при помощи &man.send-pr.1;, как это описано в разделе о сообщениях об ошибках и общих пожеланиях. Изменения к имеющемуся исходному коду FreeBSD-CURRENT Добавление нового исходного кода или внесение изменений в существующий является не такой простой задачей, и зависит во многом от того, насколько вы далеки от текущего состояния разработок во FreeBSD. Существуют специальные промежуточные релизы FreeBSD, известные как FreeBSD-CURRENT, которые доступны несколькими разными способами, удобными разработчикам, активно работающим над системой. Обратитесь к Руководству FreeBSD для получения дополнительной информации о получении и использовании FreeBSD-CURRENT. Если вы работаете с несколько устаревшими исходными текстами, то ваши изменения иногда могут оказаться уже ненужными или слишком большими, чтобы повторно интегрировать их во FreeBSD. Уменьшить такой риск можно, подписавшись на списки рассылки &a.announce; и &a.current;, в которых обсуждается текущее состояние системы. Предположим, что вы смогли получить актуальные исходные тексты, на базе которых делали свои изменения. Тогда следующим шагом является создание набора файлов, отражающих ваши изменения для их посылки тем, кто отвечает за поддержку FreeBSD. Это делается при помощи команды &man.diff.1;. Предпочтительным форматом &man.diff.1; для посылки патчей является унифицированная выдача, создаваемая командой diff -u. diff К примеру: &prompt.user; diff -u oldfile newfile или &prompt.user; diff -u -r -N olddir newdir создаст набор патчей в унифицированном формате для конкретного файла с исходным текстом или для иерархии каталогов. Дополнительную информацию можно найти в &man.diff.1;. После того, как вы получили набор diff-файлов (которые вы можете протестировать командой &man.patch.1;), вы должны прислать их для включения во FreeBSD. Воспользуйтесь программой &man.send-pr.1;, как это описано в разделе о сообщениях об ошибках и общих замечаниях. Не посылайте diff-файлы в список рассылки &a.hackers;, они будут потеряны! Нам очень нужна ваша помощь (это добровольный проект!); из-за нашей занятости мы не сможем рассмотреть его сразу, и он будет находиться в базе данных PR, пока мы не сделаем это. Укажите на вашу посылку, включив строку [PATCH] в тему сообщения. uuencode Если вы считаете, что это нужно (к примеру, вы добавляли, удаляли или переименовывали файлы), то объедините ваши изменения в tar-файл и обработайте его программой &man.uuencode.1;. Принимаются также и архивы, созданные программой &man.shar.1;. Если ваше изменение потенциально может оказаться сомнительным, например, вы не уверены в отсутствии лицензионных ограничений относительно его распространения, то вы должны послать его напрямую в список рассылки &a.core;, а не через &man.send-pr.1;. В списке рассылки &a.core; участвует гораздо меньшее количество людей, которые выполняют основную ежедневную работу над FreeBSD. Заметьте, что эта группа также очень занята, так что сюда письма нужно посылать только в случае действительной необходимости. Пожалуйста, обратитесь к справке по &man.intro.9; и &man.style.9; для получения некоторой информации о стиле кодирования. Мы надеемся, что вы хотя бы примете эту информацию к сведению перед тем, как прислать нам свой код. Новый код или большие дополнительные пакеты В случае значительного объёма присланного вами кода и соответствующей работы, либо добавления к FreeBSD важной новой функции, становится практически всегда необходимо посылать изменения в виде tar-файлов, обработанных uuencode, или передавать их на Web-сайт или FTP-сервер для получения другими людьми. Если у вас нет доступа к Web- или FTP-серверам, попросите в соответствующем списке рассылке FreeBSD кого-нибудь разместить изменения за вас. При работе с большим объёмом кода неизбежно возникает вопрос о соблюдении авторских прав. Допустимыми лицензионными соглашениями для кода, включаемого во FreeBSD, являются следующие: Лицензионное соглашение BSDлицензионное соглашение BSD. Оно является самым предпочтительным из-за отсутствия дополнительных условий и общей привлекательности для коммерческих компаний. Проект FreeBSD далёк от того, чтобы выступать против коммерческого использования, но активно популяризирует такое пересечение коммерческих интересов, которое позволит постепенно запустить механизм инвестиций во FreeBSD. GPL GNU General Public License GNU General Public License GNU General Public License, или GPL. Это лицензионное соглашение не очень популярно у нас из-за объёма требований, которые нужно выполнять всем, кто собирается использовать код в коммерческих целях. Однако, учитывая абсолютное превосходство объёма этого кода (компилятор, ассемблер, инструменты форматирования текста и так далее) было бы глупо отказываться от дополнительных разработок, подпадающих под действие этой лицензии. Код, распространяемый по условиям лицензионного соглашения GPL также размещается в отдельной части дерева исходных текстов, в /sys/gnu или /usr/src/gnu, и поэтому легко идентифицируется всяким, для кого GPL представляет проблему. Разработки, подпадающие под действие других типов лицензионных соглашений, должны быть тщательно просмотрены перед принятием решения об их включении во FreeBSD. Разработки, на которые распространяются жёсткие ограничения коммерческих лицензионных соглашений, обычно отвергаются, а авторам всегда предлагается распространять подобные изменения по собственным каналам. Для того, чтобы на вашу работу распространялись условия лицензионного ограничения в стиле BSD, разместите следующий текст в самом начале каждого файла с исходными текстами, которые вы хотите защитить, заменив текст между %% соответствующей информацией: Copyright (c) %%полные_номера_годов%% %%ваше_имя%%, %%ваш_штат%% %%ваш_почтовый_индекс%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $&os;$ Для вашего удобства копия этого текста размещена в файле /usr/share/examples/etc/bsd-style-copyright. Деньги, оборудование или Internet-доступ Мы всегда с удовольствием примем материальную помощь, нужную для дальнейшего существования Проекта FreeBSD, а в добровольном проекте, типа нашего маленькая помощь может послужить долго! Безвозмездная передача вычислительной техники также очень важна для расширения списка поддерживаемого периферийного оборудования, так как обычно у нас нет средств для самостоятельного его приобретения. Финансовая помощь The FreeBSD Foundation является некоммерческой организацией, освобождённой от уплаты налогов, созданной с целью реализации целей Проекта FreeBSD. Как организация типа 501(c)3, Фонд обычно освобождается от федерального налога США на прибыль. Суммы безвозмездных пожертвований таким организациям часто вычитаются из общей суммы налогооблагаемой прибыли. Финансовая помощь может быть направлена в виде чеков на адрес:
The FreeBSD Foundation P.O. Box 20247 Boulder, CO 80308 USA
The FreeBSD Foundation теперь может принимать помощь через Web по системе PayPal. Для направления помощи, пожалуйста, посетите Web-сайт Фонда. Дополнительную информацию о Фонде FreeBSD можно найти на странице, содержащей вводную информации о Фонде FreeBSD. Для того, чтобы обратиться в Фонд по электронной почте, напишите письмо на адрес bod@FreeBSDFoundation.org. Помощь в виде оборудования безвозмездная помощь Проект FreeBSD с удовольствие примет помощь в виде оборудования, которому он найдёт хорошее применение. Если вы заинтересованы в передаче оборудования, пожалуйста, обратитесь к Руководству Центра пожертвований.
diff --git a/ru_RU.KOI8-R/articles/cups/Makefile b/ru_RU.KOI8-R/articles/cups/Makefile index c2036ef9e1..e6a7dd26e5 100644 --- a/ru_RU.KOI8-R/articles/cups/Makefile +++ b/ru_RU.KOI8-R/articles/cups/Makefile @@ -1,21 +1,21 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # # Article: CUPS on FreeBSD # -# Original revision: r33118 +# Original revision: r39631 # DOC?= article FORMATS?= html INSTALL_COMPRESSED?=gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/cups/article.xml b/ru_RU.KOI8-R/articles/cups/article.xml index 46b7a4e58c..fc078bfe33 100644 --- a/ru_RU.KOI8-R/articles/cups/article.xml +++ b/ru_RU.KOI8-R/articles/cups/article.xml @@ -1,394 +1,394 @@
Универсальная Система Печати Unix на FreeBSD ChessGriffin
chess@chessgriffin.com
 &tm-attrib.freebsd; &tm-attrib.general; $FreeBSD$ $FreeBSD$ Эта статья посвящена конфигурированию Универсальной Системы Печати UNIX (CUPS) на &os;. Знакомимся с Универсальной Системой Печати UNIX (CUPS) printing CUPS Универсальная Система Печати UNIX (Common Unix Printing System, или сокращенно CUPS), предоставляет переносимую среду печати для &unix; и &unix;-подобных операционных систем. Она была разработана компанией Easy Software Products, чтобы предоставить стандартное решение в печати для всех разработчиков и пользователей &unix;. Универсальная Система Печати UNIX использует протокол межсетевой печати (Internet Printing Protocol, IPP) как основу для управления заданиями на печать и очередями. Также частично поддерживаются следующие протоколы: LPD, SMB и AppSocket (также известный как JetDirect). CUPS дает возможность обзора сетевых принтеров и использования опций, базирующихся на ПостСкрипт Описании Принтеров (PostScript Printer Definition, PPD), чтобы поддерживать в &unix; общепринятые традиции печати. В результате CUPS идеально подходит для совместного использования принтеров в смешанной среде из &os;, &linux;, &macos; X или &windows;. Официальный сайт Универсальной Системы Печати UNIX — http://www.cups.org/. Установка сервера печати CUPS CUPS может быть установлена из портов или уже собранных пакетов. Чтобы установить CUPS из коллекции портов, выполните с привилегиями пользователя root следующую команду: &prompt.root; cd /usr/ports/print/cups && make install clean Для установки CUPS используя пакет, запустите на выполнение такую команду: &prompt.root; pkg_add -r cups Другие необязательные, но рекомендуемые к установке порты или пакеты это print/gutenprint-cups и print/hplip, каждый из которых добавляет драйвера и утилиты для разнообразных принтеров. После установки файлы конфигурации CUPS могут быть найдены в директории /usr/local/etc/cups. Настройка сервера печати CUPS Чтобы настроить сервер CUPS необходимо отредактировать несколько конфигурационных файлов. Для начала создайте или исправьте файл /etc/devfs.rules и добавьте следующую информацию для того, чтобы установить соответствующие права на все потенциальные файлы устройств принтеров и связать принтеры с группой пользователей cups: [system=10] add path 'unlpt*' mode 0660 group cups add path 'ulpt*' mode 0660 group cups add path 'lpt*' mode 0660 group cups add path 'usb/X.Y.Z' mode 0660 group cups Замените X, Y и Z номерами соответствующего принтеру целевого устройства USB, отображаемого в каталоге /dev/usb. Чтобы найти требуемые значения, просмотрите вывод &man.dmesg.8; и найдите связанное с вашим принтером имя специального устройства ugenX.Y, последнее будет символической ссылкой на искомое устройство в каталоге /dev/usb. Затем, добавьте следующие две записи в /etc/rc.conf: cupsd_enable="YES" devfs_system_ruleset="system" Эти две записи будут запускать сервер печати CUPS во время загрузки системы и применять локальное правило devfs, созданное выше. Для того, чтобы печать CUPS стала доступна для некоторых µsoft.windows; клиентов, необходимо раскомментировать следующую запись в /usr/local/etc/cups/mime.types и /usr/local/etc/cups/mime.convs: application/octet-stream По окончанию внесения изменений службы &man.devfs.8; и CUPS необходимо перезапустить, для чего перезагрузите операционную систему или выполните от пользователя root следующие две команды: &prompt.root; /etc/rc.d/devfs restart &prompt.root; /usr/local/etc/rc.d/cupsd restart Настройка принтеров на сервере печати CUPS После того, как система CUPS была установлена и сконфигурирована, системный администратор может начать конфигурирование локальных принтеров, подключенных к серверу печати CUPS. Эта часть процесса очень похожа, если не идентична настройке принтеров CUPS в других &unix;-подобных операционных системах, таких как дистрибутивы &linux;. Основным способом управления и администрирования сервера CUPS является веб-интерфейс, на который можно попасть запустив веб-браузер и набрав http://localhost:631 в его адресной строке. Если сервер CUPS находится на другой машине в сети, замените localhost на IP адрес сервера. Веб-интерфейс CUPS достаточно очевиден, там есть разделы для управления принтерами и заданиями на печать, авторизацией пользователей и т.п. Кроме того, в правой части страницы администрирования есть несколько флажков (check-box), дающих удобный доступ к часто меняемым установкам, таким как разрешение публичного доступа к подключенным к системе принтерам, предоставление удаленного управления сервером CUPS, изменение уровня доступа пользователей к принтерам и их заданиям на печать. Добавление принтера в общем такое же простое, как нажатие Add Printer на странице администрирования веб-интерфейса сервера CUPS или как нажатие одной из кнопок New Printers Found на той же странице администрирования. Когда перед вами предстанет выпадающий список Device, просто выберите требуемый локально подключенный принтер, а дальше следуйте подсказкам интерфейса. В случае если были установлены порты или пакеты print/gutenprint-cups или print/hplip, как указывалось выше, дополнительные драйвера печати будут доступны на последующих страницах, что может обеспечить большую надежность и расширенные возможности. Конфигурирование клиентов CUPS После того, как сервер CUPS был настроен, принтеры добавлены и сделаны доступными в сети, следующий шаг — это настройка клиентов или машин, которые будут иметь доступ к серверу CUPS. Если у вас единственный настольный компьютер, который работает одновременно и сервером и клиентом, то в большинстве этой информации вы не нуждаетесь. &unix; клиенты На &unix; клиентах также потребуется установить CUPS. После установки системы печати на клиенте, CUPS-принтеры, присутствующие в сети, чаще всего автоматически находятся менеджерами принтеров разных графических оболочек, таких как GNOME или KDE. В качестве альтернативы, вы можете воспользоваться веб-интерфейсом CUPS на клиентской машине по адресу http://localhost:631 и на странице администрирования выбрать Add Printer. Когда перед вами предстанет выпадающий список Device, просто выберите сетевой CUPS принтер, если он был обнаружен автоматически, или выберите ipp или http и введите IPP или HTTP адрес (URI) сетевого CUPS принтера: ipp://server-name-or-ip/printers/printername http://server-name-or-ip:631/printers/printername Если CUPS клиент не находит в сети принтеры, доступные через сервер CUPS, то иногда помогает создание или изменение файла /usr/local/etc/cups/client.conf с добавлением единственной записи, подобной следующей: ServerName server-ip В этом случае server-ip необходимо заменить на IP адрес сервера CUPS в сети. &windows;-клиенты Версии &windows;, предшествующие XP, не имели встроенной поддержки протокола IPP. Однако &windowsxp; и более поздние версии уже обладают такой возможностью. Следовательно, добавить CUPS принтер в этих версиях &windows; довольно просто. В большинстве случаев, администратору &windows; потребуется запустить мастера установки принтера (Add Printer) выбрать сетевой принтер (Network Printer), а затем ввести URI следующего формата: http://server-name-or-ip:631/printers/printername Если используется версия &windows; без поддержки протокола IPP, то общим случаем подключения к CUPS-принтеру будет совместное использование CUPS и net/samba3. Описание этой возможности выходит за рамки данной статьи. Устранение неполадок с CUPS Проблемы c CUPS часто возникают из-за неверных прав доступа. Сначала дважды проверьте права доступа в &man.devfs.8; (сверьтесь с уже описанными выше). Затем, проверьте реальные права устройств, созданных в файловой системе. Также бывает полезным удостовериться, что ваш пользователь входит в группу cups. Если у вас складывается впечатление, что флажки прав доступа на странице администрирования веб-интерфейса CUPS не работают, то иным решением может быть резервное копирование конфигурационного файла /usr/local/etc/cups/cupsd.conf и редактирование разных опций конфигурации с подбором их комбинаций. Ниже приведено содержимое тестового файла конфигурации /usr/local/etc/cups/cupsd.conf. Пожалуйста, обратите внимание на то, что безопасность в этом примере cupsd.conf была пожертвована в угоду простоте настройки; как только администратор успешно подсоединится к серверу CUPS и сконфигурирует клиентов, рекомендуется пересмотреть данную конфигурацию и добавить разграничение доступа. # Log general information in error_log - change "info" to "debug" for # troubleshooting... LogLevel info # Administrator user group... SystemGroup wheel # Listen for connections on Port 631. Port 631 #Listen localhost:631 Listen /var/run/cups.sock # Show shared printers on the local network. Browsing On BrowseOrder allow,deny #BrowseAllow @LOCAL BrowseAllow 192.168.1.* # change to local LAN settings BrowseAddress 192.168.1.* # change to local LAN settings # Default authentication type, when authentication is required... DefaultAuthType Basic DefaultEncryption Never # comment this line to allow encryption # Allow access to the server from any machine on the LAN <Location /> Order allow,deny #Allow localhost Allow 192.168.1.* # change to local LAN settings </Location> # Allow access to the admin pages from any machine on the LAN <Location /admin> #Encryption Required Order allow,deny #Allow localhost Allow 192.168.1.* # change to local LAN settings </Location> # Allow access to configuration files from any machine on the LAN <Location /admin/conf> AuthType Basic Require user @SYSTEM Order allow,deny #Allow localhost Allow 192.168.1.* # change to local LAN settings </Location> # Set the default printer/job policies... <Policy default> # Job-related operations must be done by the owner or an adminstrator... <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs \ Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription \ Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job \ CUPS-Move-Job> Require user @OWNER @SYSTEM Order deny,allow </Limit> # All administration operations require an adminstrator to authenticate... <Limit Pause-Printer Resume-Printer Set-Printer-Attributes Enable-Printer \ Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs \ Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer \ Promote-Job Schedule-Job-After CUPS-Add-Printer CUPS-Delete-Printer CUPS-Add-Class \ CUPS-Delete-Class CUPS-Accept-Jobs CUPS-Reject-Jobs CUPS-Set-Default> AuthType Basic Require user @SYSTEM Order deny,allow </Limit> # Only the owner or an administrator can cancel or authenticate a job... <Limit Cancel-Job CUPS-Authenticate-Job> Require user @OWNER @SYSTEM Order deny,allow </Limit> <Limit All> Order deny,allow </Limit> </Policy> Настройка портов использующих CUPS Если CUPS будет служить в качестве основной системы печати, то можно по желанию добавить несколько записей в /etc/make.conf, которые выделят CUPS среди других систем. Вот некоторые из них: WITH_CUPS=YES CUPS_OVERWRITE_BASE=YES WITHOUT_LPR=YES Первая переменная, WITH_CUPS, добавляет поддержку CUPS к портам, в которых предусмотрена такая возможность. Вторая запись, CUPS_OVERWRITE_BASE, исправит некоторые символические ссылки и пути, которые иначе приводили-бы к системе печати &os; по умолчанию — LPR. Также она предотвратит откат этих изменений во время следующего обновления системы посредством buildworld. Третья переменная, WITHOUT_LPR, предотвратит включение поддержки LPR в портах, потенциально ее использующих.
diff --git a/ru_RU.KOI8-R/articles/custom-gcc/Makefile b/ru_RU.KOI8-R/articles/custom-gcc/Makefile index 86551ad20f..7d13ba38d7 100644 --- a/ru_RU.KOI8-R/articles/custom-gcc/Makefile +++ b/ru_RU.KOI8-R/articles/custom-gcc/Makefile @@ -1,21 +1,21 @@ # # $FreeBSD$ # -# Original revision: r34669 +# Original revision: r39631 # DOC?= article FORMATS?= html WITH_ARTICLE_TOC?= YES INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/custom-gcc/article.xml b/ru_RU.KOI8-R/articles/custom-gcc/article.xml index 776f5d0f78..01e27805ad 100644 --- a/ru_RU.KOI8-R/articles/custom-gcc/article.xml +++ b/ru_RU.KOI8-R/articles/custom-gcc/article.xml @@ -1,229 +1,229 @@
Использование более новых версий <application>GCC</application> и <application>binutils</application> c коллекцией портов &os; MartinMatuska
mm@FreeBSD.org
 &tm-attrib.freebsd; &tm-attrib.general; 2009 The &os; Documentation Project $FreeBSD$ $FreeBSD$ В этой статье описано, как использовать более новые версии компиляторов GCC и набора утилит binutils из коллекции портов &os;. Здесь также обсуждаются специализированные конфигурации GCC. Предисловие Компилятор, поставляемый с &os; 8.0, — это GCC версии 4.2.1. В базовую систему &os; включены binutils версии 2.15. Это довольно-таки старые версии, и в них, между прочим, отсутствует поддержка новых инструкций CPU, таких как SSSE3, SSE4.1, SSE4.2 и т.п. Ввиду лицензионных ограничений, новые версии этих приложений не будут включены в базовую систему. К счастью, есть возможность использовать более новую версию компилятора GCC (например, версию 4.4) установив его из коллекции портов &os;. Подготовка Установка binutils из портов Чтобы задействовать все новые функциональные возможности последней версии GCC, желательна установка наиболее новой версии binutils. Это не является обязательным, но без обновления binutils вы не получите поддержку новых инструкций CPU. Для того, чтоб установить наиболее новую версию binutils используя коллекцию портов &os;, выполните следующую команду: &prompt.root; cd /usr/ports/devel/binutils && make install Установка GCC из портов В коллекции портов &os; можно найти несколько новых версий GCC. В нашем примере мы устанавливаем стабильную версию 4.4. Однако, возможно установить предыдущую или более новую (развивающуюся) версию (например: lang/gcc43 или lang/gcc45). Для установки одного из вышеупомянутых портов GCC, наберите следующую команду: &prompt.root; cd /usr/ports/lang/gcc44 && make install Настройка портов на использование требуемой версии <application>GCC</application> Для использования требуемой версии GCC, установленной из коллекции портов &os;, требуется дополнительная конфигурация системы. Изменения в <filename>make.conf</filename> Добавьте следующие строки в /etc/make.conf (или исправьте существующие): .if !empty(.CURDIR:M/usr/ports/*) && exists(/usr/local/bin/gcc44) CC=gcc44 CXX=g++44 CPP=cpp44 .endif В качестве альтернативы, можно установить вручную переменные окружения ${CC} и ${CPP}. Примеры, приведённые выше, сделаны для GCC версии 4.4. Для того, чтобы использовать gcc43, замените "gcc44" на "gcc43" и "4.4" на "4.3" и т.п. Исправления в <filename>libmap.conf</filename> Многие установленные из портов приложения и библиотеки скомпонованы с libgcc_s или libstdc++. В базовую систему уже включены эти библиотеки, но от более старой версии GCC (версии 4.2.1). Чтобы предоставить rltd (и ldd) правильные версии, добавьте следующие записи к /etc/libmap.conf (или измените существующие): libgcc_s.so.1 gcc44/libgcc_s.so.1 libgomp.so.1 gcc44/libgomp.so.1 libobjc.so.3 gcc44/libobjc.so.2 libssp.so.0 gcc44/libssp.so.0 libstdc++.so.6 gcc44/libstdc++.so.6 Пример выше приведен для GCC версии 4.4. Если вы используете gcc43, замените "gcc44" на "gcc43" и т.д. Следует отметить, что все вышеупомянутые библиотеки обратно совместимы с библиотеками, поставляемыми с базовой системой. Некоторые C++ программы могут перестать работать, если отсутствует корректная компоновка этих библиотек. Если невозможно скомпоновать их все, рекомендуется сделать это по крайней мере для libstdc++.so. Специальные установки <literal>CFLAGS</literal> для коллекции портов Для портов, не поддерживающих специальные установки CFLAGS, исправьте /etc/make.conf согласно следующему примеру: .if !empty(.CURDIR:M/usr/ports/*) && exists(/usr/local/bin/gcc44) CC=gcc44 CXX=g++44 CPP=cpp44 CFLAGS+=-mssse3 .endif Возможно заменить полностью CFLAGS и/или определить CPUTYPE. Мы рекомендуем устанавливать CPUTYPE так как во многих портах флаги оптимизации выбираются, базируясь на значении этой переменной. Исключение портов, которые не собираются с новой версией <application>GCC</application> Для того, чтобы исключить порты, которые не собираются со специальной версией GCC, исправьте /etc/make.conf согласно следующему примеру: .if !empty(.CURDIR:M/usr/ports/*) && exists(/usr/local/bin/gcc44) .if empty(.CURDIR:M/usr/ports/net/openldap*) CC=gcc44 CXX=g++44 CPP=cpp44 .endif .endif Пример, приведённый выше, отменяет принудительное использование gcc 4.4 для портов net/openldap*. Также возможно указать больше портов в одной строке: .if empty(.CURDIR:M/usr/ports/net/openldap*) && empty(.CURDIR:M/usr/ports/xxx/yyy) && ... Влияние на производительность исполняемых файлов Использование GCC версии 4.4 с разрешенным набором инструкций SSSE3 (если они поддерживаются CPU) может дать до 10% увеличения средней производительности исполняемых файлов. В некоторых тестах прирост производительности превышал 20% (например, в обработке мультимедийных данных). В таблице, размещенной на http://people.freebsd.org/~mm/benchmarks/perlbench/, показано сравнение GCC в настоящее время включенного в базу &os;, GCC версии 4.3 и GCC версии 4.4 с различными комбинациями CFLAGS. Для сравнений производительности использовался тестовый пакет perlbench.
diff --git a/ru_RU.KOI8-R/articles/cvs-freebsd/Makefile b/ru_RU.KOI8-R/articles/cvs-freebsd/Makefile index 6c9f24c005..c25ad1e044 100644 --- a/ru_RU.KOI8-R/articles/cvs-freebsd/Makefile +++ b/ru_RU.KOI8-R/articles/cvs-freebsd/Makefile @@ -1,22 +1,22 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/cvs-freebsd/Makefile,v 1.3 2005/01/03 08:14:37 marck Exp $ # -# Original revision: r21827 +# Original revision: r39631 # DOC?= article FORMATS?= html INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/cvs-freebsd/article.xml b/ru_RU.KOI8-R/articles/cvs-freebsd/article.xml index 53fe1431d1..6479554016 100644 --- a/ru_RU.KOI8-R/articles/cvs-freebsd/article.xml +++ b/ru_RU.KOI8-R/articles/cvs-freebsd/article.xml @@ -1,727 +1,727 @@
Настройка хранилища CVS - подход FreeBSD StijnHoop
stijn@win.tue.nl
 2001 2002 2003 Stijn Hoop $FreeBSD$ $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.general; В этой статье описаны шаги, которые я предпринял для настройки хранилища CVS, использующего те же самые скрипты, что используются в проекте FreeBSD в их настройке. Это имеет некоторые преимущества перед стандартной настройкой CVS, в том числе более точный контроль доступа к дереву исходных текстов и посылку содержательных сообщений электронной почты при каждом коммите. Введение Большинство программных проектов с открытым кодом используют CVS в качестве системы управления исходным кодом. Хотя CVS весьма хороша в этом качестве, у неё есть свои неудобства и недостатки. Одним из них является то, что совместное использование дерева исходных текстов с другими разработчиками может быстро привести к кошмарным проблемам при администрировании, особенно если кто-то захочет защитить части дерева от общедоступности. FreeBSD является одним из проектов, использующим CVS. Здесь также имеет большое количество разработчиков, разбросанных по всему миру. Они разработали некоторые скрипты, облегчающие управление хранилищем. Недавно &a.joe.email; пересмотрел и привел в порядок эти скрипты в целях облегчения их использования в других проектах. В этой статье описан один из методов использования новых скриптов. Чтобы извлечь максимум информации из этой статьи, вы должны владеть основными методами работы с CVS. Первоначальная настройка Наверное, лучше сначала выполнить эту процедуру с пустым тестовым хранилищем, чтобы понять все последствия ваших действий. Как обычно в таких случаях, у вас должны иметься свежие читаемые резервные копии! Инициализация хранилища Первым делом при настройке нового хранилища необходимо его инициализировать, для чего выдать CVS такую команду: &prompt.user; cvs -d path-to-repository init Результатом ее выполнения будет созданный CVS служебный каталог CVSROOT, в котором выполняется вся настройка. Группа пользователей хранилища Теперь мы создадим группу, которая будет владеть хранилищем. В этой группе должны присутствовать все коммиттеры, для того, чтобы они могли писать в хранилище. Для этой группы мы примем стандартное для FreeBSD название ncvs. &prompt.root; pw groupadd ncvs Затем вы должны при помощи команды &man.chown.8; сменить владельца и группу для только что добавленного каталога: &prompt.root; chown -R :ncvs path-to-your-repository Это нужно для того, чтобы никто не мог записывать в хранилище, не являясь членом группы. Получение исходных текстов Теперь вам нужно получить каталог CVSROOT из хранилища FreeBSD. Проще всего это делается извлечением с анонимного зеркала CVS FreeBSD. Обратитесь к соответствующей главе Руководства для получения дополнительной информации. Мы будем полагать, что исходные тексты хранятся в подкаталоге CVSROOT-freebsd текущего каталога. Копирование скриптов FreeBSD Теперь мы скопируем исходные тексты FreeBSD из CVSROOT в наше хранилище. Если вы знакомы с CVS, то для вас может иметь смысл попытаться импортировать скрипты, чтобы облегчить синхронизацию с последующими версиями. Однако при этом оказывается, что CVS имеет в этой области недостаток: при импортировании исходных текстов в каталог CVSROOT она не будет обновлять необходимые административные файлы. Чтобы в этом убедиться, вам нужно проверить каждый файл после импортирования, при этом смысл cvs import теряется. Поэтому рекомендуемым методом является простое копирование скриптов. Не имеет значения, как вы относитесь к предыдущему параграфу—результат один и тот же. Просто поместите ваш CVSROOT и скопируйте файлы FreeBSD поверх ваших локальных (неизмененных) копий: &prompt.user; cvs -d path-to-your-repository checkout CVSROOT &prompt.user; cd CVSROOT &prompt.user; cp ../CVSROOT-freebsd/* . &prompt.user; cvs add * Заметим, что вы, скорее всего, получите несколько предупреждений о том, что некоторые каталоги не были скопированы; это нормально, вам они не нужны. Скрипты Теперь у вас есть рабочий каталог и точная копия скриптов, которые используются в проекте FreeBSD для работы с хранилищем. Далее следует краткое описание назначения каждого файла. access - по умолчанию при стандартной настройке этот файл не используется. Он применяется в специфичных для проекта FreeBSD настройках, где он управляет доступом к хранилищу. Вы можете удалить этот файл, если вы не собираетесь использовать такую настройку. avail - этот файл управляет доступом к хранилищу. В нем вы можете указать группы людей, которым разрешен доступ к хранилищу, а также запретить коммиты на уровне каталогов. Вы должны поднастроить его так, чтобы он содержал группы и каталоги, имеющиеся в вашем хранилище. cfg.pm - этот файл анализирует вашу конфигурацию и содержит настройки по умолчанию. Вы не должны изменять этот файл. Вместо этого размещайте ваши изменения в конфигурации в файле cfg_local.pm. cfg_local.pm - этот файл содержит все настраиваемые параметры системы. Вы должны настраивать все параметры здесь, например, куда посылается почта при коммите, с каких хостов можно выполнять коммиты, и прочее. Ниже дается более полная информация об этом. checkoutlist - эти файлы перечисляют все файлы, управляемые CVS в этом каталоге. Вы должны отредактировать его для удаления некоторых специфичных для FreeBSD файлов. commit_prep.pl - этот скрипт выполняет различные проверки перед выполнением коммита, в зависимости от того, включили ли вы их в cfg_local.pm. Вам не нужно его трогать. commitcheck - этот скрипт вызывается непосредственно из CVS. Сначала он проверяет, с использованием cvs_acls.pl, имеет ли коммитер доступ к указанной части дерева, а затем запускает commit_prep.pl для выполнения различных проверок перед коммитом. Если они выполнились нормально, то CVS позволит выполнить коммит. Вам не нужно трогать этот файл. commitinfo - этот файл используется в CVS для определения того, какой скрипт запускать перед коммитом—в данном случае commitcheckl. Вам не нужно трогать этот файл. config - конфигурационный файл для этого хранилища. Вы должны изменять его при необходимости, но большинство администраторов могут оставить все настройки по умолчанию. Дополнительную информацию о параметрах, которые могут быть здесь заданы, можно найти в руководстве по CVS. cvs_acls.pl - этот скрипт идентифицирует пользователя и то, имеет ли он доступ к дереву. Это делается на основе информации в файле avail. Вам не нужно трогать этот файл. cvsignore - этот файл перечисляет файлы, которые CVS не должна помещать в хранилище. Вы можете отредактировать его по своему усмотрению. Более полная информация об этом файле находится в руководстве по CVS. cvswrappers - этот файл используется в CVS для включения или выключения расширения ключевых слов, или должен ли файл считаться бинарным. Вы можете редактировать его по своему усмотрению. Более полная информация об этом файле находится в руководстве по CVS. Имейте ввиду, что опции CVS -t и -f некорректно работают в режиме клиент/сервер. edithook - этот файл больше не используется, но оставлен по историческим причинам. Вы можете спокойно удалить этот файл. editinfo - CVS использует этот файл для настройки редактора. FreeBSD не использует эту функциональность, так как обработка сообщений для журнала выполняется в файлах verifymsg и logcheck. Это происходит по той причине, что editinfo некорректно работает в режиме клиент/сервер, или в случаях когда используются опции -m или -F. Вам не нужно трогать этот файл. exclude - в этом файле перечислены регулярные выражения, используемые commit_prepl.pl для выделения файлов, в которых могут не содержаться заголовки с номером версии. В настройке FreeBSD все файлы содержащиеся в хранилище должны иметь заголовок с версией (типа $FreeBSD$). Все файлы с именами, которые соответствуют одной из строк этого файла, исключаются из проверки. Вы должны добавить выражения в этот файл, если вы помещаете в хранилище файлы, которые не могут иметь заголовки с версиями. Для целей установки скриптов лучшим решением может оказаться исключение CVSROOT/ из проверки заголовков. log_accum.pl - это скрипт, который принимает журнальное сообщение в виде, данном скриптом logcheck, и добавляет его к файлу журнала в хранилище для хранения резервной копии. Он также отрабатывает посылку сообщения по электронной почте на адрес, который вы зададите (в файле cfg_local.pm). Он подключается к CVS через loginfo. Вам не нужно трогать этот файл. logcheck - при коммите этот файл анализирует сообщение для журнала, которое составляют коммиттеры, и пытается его некоторым образом улучшить. Он подключается к CVS через logcheck. Вам не нужно трогать этот файл. Этот скрипт зависит от ряда локальных модификаций CVS, сделанный во FreeBSD: эта версия читает журнальное сообщение повторно после того, как этот скрипт его модифицирует. Стандартная версия CVS этого не делает, что делает этот скрипт бесполезным, так как он не может модифицировать журнальное сообщение, хотя может проверить его на предмет правильности синтаксиса. CVS версии 1.11.2 и выше может быть настроен, чтоб иметь поведение подобное FreeBSD, путем установки опции RereadLogAfterVerify=always в файле config. loginfo - этот файл используется CVS для управления того, куда посылается протокольная информация. С помощью этого файла подключается log_accum.pl. Вам не нужно трогать этот файл. modules - этот файл сохраняет своё традиционное назначение в CVS. Вы должны удалить модули FreeBSD из стандартной версии. Вы можете редактировать этот файл по своему усмотрению. Более полная информация об этом файле находится в руководстве по CVS. notify - этот файл используется в CVS в том случае, если кто-то задаст отслеживание файла. Это не используется в хранилище FreeBSD. Вы можете редактировать его по своему усмотрению. Более полная информация об этом файле находится в руководстве по CVS. options - этот файл специфичен для версии CVS от FreeBSD, но также поддерживается версией для Debian. Он содержит ключевое слово для расширения в заголовках версий. Вы должны заменить это на ключевое слово, которое вы задали в файле cfg_local.pm (если вы используете эту возможность, которая в настоящее время специфична для FreeBSD). rcsinfo - этот файл отображает каталоги в хранилище на файлы шаблонов, как например rcstemplate. По умолчанию FreeBSD использует один шаблон для всего хранилища. Вы можете добавлять другие к этому файлу по своему усмотрению. rcstemplate - этот файл является актуальным файлом шаблона, который видят коммиттеры, когда помещают что-то в хранилище. Вы должны отредактировать его для описания различных дополнительных параметров, которые вы определили в cfg_local.pm. tagcheck - эти файлы управляют доступом к созданию меток в хранилище. Стандартная для FreeBSD версия не позволяет создавать метки с именами типа RELENG* из-за пересечения с процессом создания релизов. Вы должны отредактировать этот файл по вашему усмотрению. taginfo - этот файл ставит в соответствие операции с метками над каталогами хранилища скриптам управления доступом, например tagcheck. Вам не нужно трогать этот файл. unwrap - этот скрипт нужен для автоматической обратной обработки (unwrap) двоичных файлов (посмотрите cvswrappers) при извлечении. Это не используется в текущей настройке FreeBSD по причине того, что не работает с конфигурацией клиент/сервер. Вам не нужно трогать этот файл. verifymsg - этот файл ставит в соответствие каталогам хранилища скрипты вторичной обработки журнальных сообщений, например logcheck. Вам не нужно трогать этот файл. wrap - этот скрипт может быть использован для автоматической обработки (wrap) двоичных файлов (посмотрите cvswrappers) при помещении в хранилище. Это не используется в текущей настройке FreeBSD, по причине того, что не работает с конфигурацией клиент/сервер. Вам не нужно трогать этот файл. Настройка скриптов Следующим шагом является настройка скриптов так, чтобы они работали в ваших условиях. Вы должны просмотреть все файлы в каталоге и выполнить ваши настройки. В частности, вы может потребоваться отредактировать следующие файлы: Если вы не хотите использовать специфичные для FreeBSD возможности скриптов, то вы можете без последствий удалить файл access: &prompt.user; cvs rm -f access Отредактируйте avail так, чтобы он содержал различные каталоги хранилища, доступом к которым вы хотите управлять. Обязательно сохраните строчку avail||CVSROOT, иначе вы заблокируете сами себя на следующем шаге. Другими параметрами, которые вы можете добавить в этот файл, являются группы коммиттеров. По умолчанию FreeBSD использует файл access для перечисления всех коммиттеров, но вы можете использовать любой файл. Вы можете также добавить группы, если хотите (синтаксис описан в начале файла cvs_acls.pl). Отредактируйте файл cfg_local.pm так, чтобы он содержал параметры, которые вы хотите. В частности, вы должны взглянуть на такие пункты настройки: %TEMPLATE_HEADERS - они обрабатываются скриптами ведения протокола, и вставляются ниже почтового сообщения, если они присутствуют и не являются пустыми в сообщении при коммите. Вы можете, наверное, удалить строки PR и MFC after. И, конечно, вы можете добавить свои собственные. $MAIL_BRANCH_HDR - если вы хотите в каждое сообщение при коммите вставлять заголовок, описывающий ветку, в которую был выполнен коммит, задайте это в соответствии с вашим окружением. Или оставьте это пустым, если не хотите иметь такой заголовок. @COMMIT_HOSTS - задайте здесь список хостов, с которых можно выполнять коммиты. $MAILADDRS - задайте здесь адрес администратора или списка, в который должны направляться почтовые сообщения при коммите. @LOG_FILE_MAP - измените этот массив по своему усмотрению - каждое регулярное выражение сравнивается с каталогом коммита, и протокольное сообщение при коммите сохраняется в подкаталоге commitlogs в указанном файле. $COMMITCHECK_EXTRA - если вы не хотите использовать специфичные для FreeBSD проверки доступа, то вы должны удалить определения $COMMITCHECK_EXTRA из этого файла. Изменение параметра $IDHEADER гарантированно работает только на платформах FreeBSD; это зависит от специфичных для FreeBSD модификаций в CVS. Вы можете проверить cfg.pm на предмет того, какие другие параметры могут быть изменены, но перечисленное выше является достаточным подмножеством. Отредактируйте exclude для удаления специфичных для FreeBSD записей (например, всех строк, которые начинаются с ^ports/ и так далее). Более того, закомментируйте строки, начинающиеся с ^CVSROOT/, и добавьте одну строку только с ^CVSROOT/. После установки обработчика (wrapper) вы можете добавить свои заголовки к файлам в каталоге CVSROOT и восстановить эти строки, но теперь они будут иметь смысл, только когда вы попытаетесь выполнить коммит позже. Отредактируйте файл modules и удалите всё, что относится к FreeBSD. Добавьте собственные модули, если хотите. Этот шаг необходим, если только вы задали значение для $IDHEADER в cfg_local.pm (что работает только при использовании модифицированной во FreeBSD версии CVS). Отредактируйте файл options так, чтобы он соответствовал метке, которую вы задали в cfg_local.pm. Глобальный поиск и замена FreeBSD на вашу метку должны сработать. Отредактируйте файл rcstemplate так, чтобы он содержал те же самые ключевые слова, что заданы в cfg_local.pm. Опционально удалите проверки FreeBSD из tagcheck. Вы можете просто добавить exit 0 в начало файла, чтобы запретить все проверки при установке метки. Последним действием, которое нужно сделать перед тем, как закончить работу, является проверка того, что протоколы коммитов могут сохраняться. По умолчанию они сохраняются в хранилище, в подкаталоге commitlogs каталога CVSROOT. Этот каталог должен быть создан, так что выполните следующее: &prompt.user; mkdir commitlogs &prompt.user; cvs add commitlogs А теперь, после тщательной проверки, вы должны выполнить коммит ваших изменений. Убедитесь, что вы дали сами себе доступ к каталогу CVSROOT в вашем avail до того, как его делать, так как в противном случае вы заблокируете сами себя. Так что убедитесь, что всё именно так, как вы и предполагали, а затем выполните следующее: &prompt.user; cvs commit -m '- Initial FreeBSD scripts commit' Тестирование настройки Вы готовы к первому тестированию: принудительному коммиту в файл avail, чтобы убедиться, что всё работает так, как ожидалось. &prompt.user; cvs commit -f -m 'Forced commit to test the new CVSROOT scripts' avail Если всё работает, поздравляем! Теперь у вас имеется работающая настройка скриптов FreeBSD для вашего хранилища. Если CVS всё ещё о чём-то сообщает, вернитесь и проверьте, все ли вышеупомянутые шаги были выполнены правильно. Специфичная для FreeBSD настройка Проект FreeBSD сам по себе использует несколько другую настройку, в которой также используются файлы из подкаталога freebsd каталога FreeBSD CVSROOT. Проект использует их из-за большого количества коммиттеров, которые все должны быть в одной и той же группе. Поэтому был написан простой обработчик, проверяющий, что люди имеют правильные права на выполнение коммита, а затем устанавливающий идентификатор группы, соответствующий идентификатору хранилища. Если вашему хранилищу это тоже нужно, то шаги для выполнения этого описаны ниже. Но сначала обзор связанных с этим файлов. Файлы, используемые в настройке FreeBSD access - этот файл управляет информацией о доступе. Вы должны отредактировать этот файл для включения всех участников вашего проекта. freebsd/commitmail.pl - этот файл больше не используется, но оставлен по историческим причинам. Вам не нужно трогать этот файл. freebsd/cvswrap.c - это исходный текст обработчика CVS, который вам нужно установить, чтобы проверки доступа реально заработали. Дополнительная информация об этом ниже. Вы должны отредактировать маршруты в макросах ACCESS и REALCVS так, чтобы они соответствовали вашей настройке. freebsd/mailsend.c - этот файл нужен в настройке FreeBSD для списков рассылки. Вам не нужно трогать этот файл. Процедура Отредактируйте файл access так, чтобы он содержал только ваше имя пользователя. Отредактируйте cvswrap.c так, чтобы он содержал правильный маршрут для вашей настройки. Это определено в макросе по имени ACCESS. Вы должны также изменить расположение реального выполнимого файла cvs, если оно не подходит к вашей ситуации. Для стандартного cvswrap.c предполагается, что он заменит общесистемную команду cvs, которая будет перемещена в /usr/bin/ncvs. В моём экземпляре cvswrap.c помещено следующее: #define ACCESS "/local/cvsroot/CVSROOT/access" #define REALCVS "/usr/bin/ncvs" Следующим шагом является установка обработчика для того, чтобы проверить правильность установки группы при выполнении коммита. Исходные тексты для этого размещены в cvswrap.c из вашего CVSROOT. Откомпилируйте исходные тексты, которые вы редактировали для включения правильных путей: &prompt.user; cc -o cvs cvswrap.c А затем установите их (для этого вы должны быть пользователем root): &prompt.root; mv /usr/bin/cvs /usr/bin/ncvs &prompt.root; mv cvs /usr/bin/cvs &prompt.root; chown root:ncvs /usr/bin/cvs /usr/bin/ncvs &prompt.root; chmod o-rx /usr/bin/ncvs &prompt.root; chmod u-w,g+s /usr/bin/cvs При этом обработчик будет установлен по умолчанию как команда cvs, что гарантирует всеми, использующими хранилище, получение правильных уровней доступа. Теперь вы можете убрать всех из вашей группы хранилища. Всё управление доступом выполняется вашим обработчиком, и он будет устанавливать правильную группу для доступа. Тестирование настройки Теперь ваш обработчик должен быть установлен. Конечно, вы можете протестировать его, выполнив принудительный коммит в файл access: &prompt.user; cvs commit -f -m 'Forced commit to test the new CVSROOT scripts' access И снова, если это не сработает, проверьте, правильно ли были выполнены все вышеперечисленные шаги.
diff --git a/ru_RU.KOI8-R/articles/explaining-bsd/Makefile b/ru_RU.KOI8-R/articles/explaining-bsd/Makefile index cde3d7b041..abdb5630fc 100644 --- a/ru_RU.KOI8-R/articles/explaining-bsd/Makefile +++ b/ru_RU.KOI8-R/articles/explaining-bsd/Makefile @@ -1,27 +1,27 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/explaining-bsd/Makefile,v 1.6 2005/05/28 13:32:41 andy Exp $ # # Article: Explaining BSD # -# Original revision: r21373 +# Original revision: r39631 # MAINTAINER=kappa@FreeBSD.org.ua DOC?= article FORMATS?= html WITH_ARTICLE_TOC?= YES INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/explaining-bsd/article.xml b/ru_RU.KOI8-R/articles/explaining-bsd/article.xml index e834e3d04e..ea38d34c99 100644 --- a/ru_RU.KOI8-R/articles/explaining-bsd/article.xml +++ b/ru_RU.KOI8-R/articles/explaining-bsd/article.xml @@ -1,646 +1,646 @@
Что такое BSD GregLehey
grog@FreeBSD.org
 &tm-attrib.freebsd; &tm-attrib.amd; &tm-attrib.apple; &tm-attrib.intel; &tm-attrib.linux; &tm-attrib.opengroup; &tm-attrib.sparc; &tm-attrib.sun; &tm-attrib.unix; &tm-attrib.general; $FreeBSD$ $FreeBSD$ В мире программ с открытыми исходниками, слово 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, поддерживается проектом X.Org. &os; дает пользователю возможность выбирать из множества графических оболочек, таких как Gnome, KDE или Xfce; а также из множества легких оконных менеджеров наподобие Openbox, Fluxbox или Awesome. Множество разных других прикладных и системных программ. Что, настоящий &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. В концe концов это удалось, и так появилась на свет версия 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/fbsd-from-scratch/Makefile b/ru_RU.KOI8-R/articles/fbsd-from-scratch/Makefile index 5a0f821faf..7851a7a227 100644 --- a/ru_RU.KOI8-R/articles/fbsd-from-scratch/Makefile +++ b/ru_RU.KOI8-R/articles/fbsd-from-scratch/Makefile @@ -1,41 +1,41 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/fbsd-from-scratch/Makefile,v 1.3 2005/06/12 13:51:45 gad Exp $ # # Article: FreeBSD From Scratch # -# Original revision: r20561 +# Original revision: r39631 # DOC?= article FORMATS?= html MAINTAINER= schweikh@FreeBSD.org INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= EXTRAS= stage_1.sh EXTRAS+= stage_1.conf.default EXTRAS+= stage_2.sh EXTRAS+= stage_2.conf.default EXTRAS+= stage_3.mk CLEANFILES+= ${EXTRAS} SRCS= article.xml SRCS+= ${EXTRAS} ${EXTRAS}: ${CP} ${DOC_PREFIX}/en_US.ISO8859-1/articles/fbsd-from-scratch/${.TARGET} ${.OBJDIR}/ afterinstall: .for entry in ${EXTRAS} ${INSTALL_DOCS} ${.OBJDIR}/${entry} ${DESTDIR} .endfor DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/fbsd-from-scratch/article.xml b/ru_RU.KOI8-R/articles/fbsd-from-scratch/article.xml index e5aa53ef48..8ce24fc353 100644 --- a/ru_RU.KOI8-R/articles/fbsd-from-scratch/article.xml +++ b/ru_RU.KOI8-R/articles/fbsd-from-scratch/article.xml @@ -1,637 +1,637 @@ FreeBSD From Scratch"> ]>
FreeBSD "с нуля" JensSchweikhardt
schweikh@FreeBSD.org
 2002,2003,2004,2008 Jens Schweikhardt &tm-attrib.freebsd; &tm-attrib.adobe; &tm-attrib.general; $FreeBSD$ $FreeBSD$ В этой статье описываются мои достижения в создании &scratch.ap;: полностью автоматизированной установки скомпилированной из исходных текстов системы &os;, включая компиляцию всех ваших любимых портов и преднастройку в соответствии с вашими представлениями о завершенной системе. Если вы полагаете, что концепция make world является прекрасным подходом, то &scratch.ap; расширяет это понятие до make evenmore. Введение Вы когда-либо обновляли вашу систему при помощи make world? Существует одна проблема, возникающая при наличии всего лишь одной системы на диске. Если выполнение цели installworld прерывается на середине, у вас остаётся неработоспособная система, которая может даже не загружаться. Либо цель installworld отрабатывает нормально, а новое ядро не загружается. Тогда наступает момент для поиска Fixit CD и резервных копий, которые вы делали полгода назад. Я исповедую подход сотрите данные на дисках при обновлении систем. Удаление дисков, и даже разделов, обеспечивает вам то, что нигде не остаётся никаких частей старого, то, о чём не заботятся большее число процедур обновления. Однако очистка разделов означает, что вам нужно перекомпилировать/переустановить все ваши порты и пакаджи, а также проделать все тонкие процедуры настройки. Если вы думаете, что эта задача тоже должна быть автоматизирована, то читайте дальше. Почему мне (не) нужна &scratch.ap;? Это закономерный вопрос. У нас имеется утилита sysinstall и хорошо изученный способ компиляции ядра и пользовательских приложений. Проблема с утилитой sysinstall заключается в том, что она несколько ограничена в том, что, куда и как может устанавливать. Обычно она используется для установки уже откомпилированных дистрибутивных наборов и пакаджей с некоторого носителя (CD, DVD, FTP). Она не может устанавливать результат выполнения make buildworld. Она не может устанавливать вторую систему в некоторый каталог уже работающей системы. Она не может выполнять установку в разделы Vinum или ZFS. Она не может строить порты, а лишь устанавливать уже откомпилированные пакаджи. Создание скриптов или выполнение нестандартных действий после установки затруднено. И последним, но одним из самых важных факторов, является полуофициальное прекращение дальнейшей поддержки sysinstall. Хорошо известный способ полного построения и установки системы, описанный в Руководстве, по умолчанию замещает существующую систему. При этом сохраняются только модули и ядро. Системные бинарные файлы, файлы объявлений функций и множество других файлов перезаписываются; уже ненужные файлы остаются и могут преподносить сюрпризы. Если по какой-либо причине обновление завершилось неудачно, бывает трудно и даже невозможно вернуть систему в исходное состояние. &scratch.ap; решает все эти проблемы. Её стратегия проста: использование работающей системы для установки новой в пустое дерево каталогов, при этом новые разделы монтируются в соответствующие места этого дерева. Многие конфигурационные файлы могут быть скопированы в соответствующее место, а &man.mergemaster.8; сможет позаботиться о тех, что скопировать не удалось. Тонкая настройка новой системы может быть выполнена в старой, вплоть до момента, когда вы сможете выполнить chroot в новую систему. Другими словами, мы проходим через три этапа, при этом каждый шаг представляет собой либо запуск скрипта, либо вызов команды make: stage_1.sh: Создание новой загружаемой системы в пустом каталоге и объединение либо копирование максимально большего количества необходимых файлов. Затем загрузка новой системы. stage_2.sh: Установка требуемых портов. stage_3.mk: Выполнение последующей настройки программного обеспечения, установленного на предыдущем этапе. После того, как вы воспользуетесь &scratch.ap; для построения второй системы и в течение нескольких недель убедитесь, что она работает удовлетворительно, можете затем использовать её повторно для переустановки исходной системы. С этого момента, как только вы почувствуете необходимость обновления, то просто выберите разделы, которые хотите удалить и выполнить переустановку. Может быть, вы слышали и даже пробовали использовать систему Linux From Scratch, или LFS для краткости. LFS также определяет, как построить и установить систему с нуля на пустой раздел при помощи работающей системы. LFS делает упор на выяснение роли каждого компонента системы (таких, как ядро, компилятор, устройства, командный процессор, база данных терминальных устройств и так далее) и деталей установки каждого компонента. &scratch.ap; не опускается до такого уровня детализации. Моей целью является проведение автоматизированной и полной установки, а не описание всех кровавых подробностей полного перепостроения системы. В случае, если вы хотите изучить &os; до такого уровня, начните с просмотра /usr/src/Makefile и следуйте действиям, которые выполняет make buildworld. В подходе, который применяется в &scratch.ap;, имеются свои отрицательные стороны, которые вы должны иметь в виду. При компиляции портов на втором этапе систему нельзя использовать в обычном режиме. Если вы имеете дело с сервером, работающим в режиме промышленной эксплуатации, вы должны быть готовы к простою, к которому приводит выполнение второго этапа. Порты, построенные при помощи stage_2.conf.default ниже, потребуют для сборки около 8 часов на современной системе (4 из которых займет компиляция OpenOffice.org). Если вы предпочитаете устанавливать пакеты, а не порты, то вы можете существенно сократить время простоя, примерно до 10 минут. Предварительные требования Для того, чтобы воспользоваться подходом &scratch.ap;, вам нужно иметь: Работающую систему &os; с исходными текстами и деревом портов. По крайней мере один неиспользуемый раздел, куда будет устанавливаться новая система. Опыт работы с &man.mergemaster.8;. Или по крайней мере отсутствие страха его использовать. Если у вас нет подключения или слабый канал в Internet: дистрибутивные файлы для ваших любимых портов. Знание основ написания скриптов на языке командного процессора Bourne, &man.sh.1;. Наконец, вы должны уметь указывать загрузчику системы на загрузку новой системы, либо интерактивно, либо из конфигурационного файла. Этап первый: Установка системы В первом варианте этой статьи на первом шаге использовался единственный скрипт, в котором вся настройка выполнялась его редактированием. После того, как пользователи высказали свои замечания, я решил разделить код и данные на уровне скриптов. Это позволяет создавать разные наборы конфигурационных данных для установки различных систем без внесения изменений в скрипты с кодом. Скрипт с кодом для первого этапа называется stage_1.sh, и он запускается с единственным аргументом, например &prompt.root; ./stage_1.sh default будет считывать свою конфигурацию из файла stage_1.conf.default и записывать протокол в файл stage_1.log.default. Далее приводится мой файл stage_1.conf.default. Вам необходимо подправить его в различных местах для того, чтобы он соответствовал вашим представлениям об идеальной системе. Я попытался подробно прокомментировать те места, которые вы должны исправлять. Конфигурационный скрипт должен предоставлять четыре функции для оболочки, create_file_systems, create_etc_fstab, copy_files и all_remaining_customization (в случае, если это имеет смысл: именно в такой последовательности они будут вызываться из stage_1.sh). Следует внимательно отнестись к следующим моментам: Разбиение разделов. Я не являюсь сторонником наличия одного большого раздела для всей системы. Мои системы, как правило, имеют по крайней мере по одному разделу для /, /usr и /var с каталогом /tmp, образованным символической ссылкой в /var/tmp. Вдобавок я использую файловые системы в режиме совместного доступа к /home (домашние каталоги пользователей), /home/ncvs (копия CVS-хранилища &os;), /usr/ports (дерево портов), /src (различные выгруженные из хранилища деревья исходных текстов) и /share (остальные совместно используемые данные, резервные копии которых не нужны, например, спул сервера телеконференций). Новые возможности. Это то, что вы хотите иметь сразу после загрузки новой системы и даже до запуска второго этапа. Причина отказа от создания и перехода в chroot-окружение новой системы во время первого этапа и простой установки всех моих любимых портов заключается в том, что теоретически и практически существуют проблемы начальной загрузки и целостности: на первом этапе работает ваше старое ядро, однако в chroot-окружении содержатся новые двоичные файлы программ и файлы объявлений. Если новые программы используют новый системный вызов, то они будут завершаться SIGSYS, Плохой системный вызов, так как старое ядро не поддерживает этот новый вызов. Я наблюдал и другие проблемы при попытке построения порта lang/perl5.8. Перед тем, как запускать stage_1.sh, убедитесь, что вы выполнили обычные действия при подготовке к make installworld installkernel, типа: отредактировали конфигурационный файл вашего ядра успешно выполнили make buildworld успешно выполнили make buildkernel KERNCONF=whatever Когда вы запускаете stage_1.sh первый раз, и конфигурационный файл, скопированный с работающей системы в новую, является устаревшим по сравнению с тем, что находится в каталоге /usr/src, mergemaster будет запрашивать вас на отработку этой ситуации. Я рекомендую переносить изменения. Если вам надоело отвечать на запросы, вы можете просто единожды обновить файлы в вашей работающей системе (Если только это вам подходит. Скорее всего, вам не нужно это делать, если одна из ваших систем работает под управлением -STABLE, а другая с -CURRENT. Изменения могут оказаться несовместимыми). Последующие вызовы утилиты mergemaster обнаружат, что RCS-идентификаторы версий соответствуют тем, что находятся в /usr/src, и пропустят файл. Скрипт stage_1.sh остановится на первой команде, которая завершится неудачно (возвратит ненулевой код завершения) из-за set -e, так что вы не пропустите ошибки. Он также остановится, если вы используете неустановленную переменную окружения, как правило, из-за опечатки. Вы должны исправить все ошибки в вашей версии stage_1.conf.default перед тем, как продолжить работу. В скрипте stage_1.sh мы вызываем mergemaster. Даже если никаким файлам объединение не требуется, он выведет сообщение и в конце сделает запрос *** Comparison complete *** Saving mtree database for future upgrades Do you wish to delete what is left of /var/tmp/temproot.stage1? [no] no Пожалуйста, ответьте no или просто нажмите Enter. Причина в том, что mergemaster оставит несколько файлов нулевой длины в каталоге /var/tmp/temproot.stage1, которые позже будут скопированы в новую систему (в случае, если их там еще нет). После этого mergemaster перечислит установленные им файлы и уточнит, стоит ли генерировать новый login.conf: *** You chose the automatic install option for files that did not exist on your system. The following were installed for you: /newroot/etc/defaults/rc.conf ... /newroot/COPYRIGHT *** You installed a new aliases file into /newroot/etc/mail, but the newaliases command is limited to the directories configured in sendmail.cf. Make sure to create your aliases database by hand when your sendmail configuration is done. *** You installed a login.conf file, so make sure that you run '/usr/bin/cap_mkdb /newroot/etc/login.conf' to rebuild your login.conf database Would you like to run it now? y or n [n] Ответ не имеет значения, так как stage_1.sh будет запускать &man.cap.mkdb.1; в любом случае. Вот авторский файл stage_1.conf.default, который вы должны потом существенно модифицировать. В комментариях даётся достаточно информации о том, что необходимо изменить. Скачайте stage_1.conf.default. При работе этот скрипт устанавливает систему, которая при загрузке предоставит: Унаследованные списки пользователей и групп. Подключение к Internet по Ethernet с использованием межсетевого экрана. Правильный временной пояс и NTP. Другие более мелкие конфигурационные параметры, например, /etc/ttys и inetd. Другие функции готовы к настройке, но не будут работать, пока не будет завершён второй этап. Например, мы скопировали файлы для настройки печати и X11. Однако для печати, скорее всего, необходимы приложения, отсутствующие в базовом комплекте системы, например, такие как &postscript;. X11 не будет работать, пока мы не откомпилируем сервер, библиотеки и программы. Этап второй: Установка портов На этом этапе вместо компиляции портов возможна также установка (уже откомпилированных) пакаджей. В этом случае stage_2.sh будет представлять собой не более, чем перечень команд pkg_add. Я надеюсь, что вы сумеете написать такой скрипт. Здесь мы сосредоточимся на более гибком и традиционном способе с использованием портов. Следующий скрипт stage_2.sh показывает, как я устанавливаю мои любимые порты. Он может быть запущен любое количество раз и будет пропускать все порты, которые уже установлены. Он поддерживает dryrun-параметр () для показа того, что будет выполнено. Вы запускаете его точно также, как stage_1.sh, с только одним аргументом, указывающим на конфигурационный файл, к примеру &prompt.root; ./stage_2.sh default который будет считывать перечень портов из stage_2.conf.default. Список портов состоит из строчек с двумя или большим количеством слов, разделённых пробелами: категория и порт, за которыми опционально следует команда установки, которая будет компилировать и устанавливать порт (по умолчанию: make install BATCH=yes < /dev/null). Пустые строки и строки, начинающиеся с символа #, игнорируются. В большинстве случаев в них указывается только название категории и порт. Однако некоторые порты могут быть тонко настроены при помощи указания make-переменных, к примеру: www mozilla make WITHOUT_MAILNEWS=yes WITHOUT_CHATZILLA=yes install На самом деле вы можете указать некоторые команды оболочки и не быть ограниченными простыми вызовами make: java jdk16 echo true > files/license.sh; make install BATCH=yes < /dev/null print acroread8 yes accept | make install PAGER=ls x11-fonts gnu-unifont make install && mkfontdir /usr/local/lib/X11/fonts/local news inn-stable CONFIGURE_ARGS="--enable-uucp-rnews --enable-setgid-inews" make install В первых двух строчках проиллюстрировано, как работать с портами, которые предлагают вам принять соглашения лицензии. Заметьте, что строка для news/inn-stable является примером единократного задания переменной окружения CONFIGURE_ARGS. Файл Makefile порта будет использовать это как начальное значение и определит некоторые другие необходимые аргументы. Разница в задании make-переменных в командной строке по команде news inn-stable make CONFIGURE_ARGS="--enable-uucp-rnews --enable-setgid-inews" install заключается в том, что в последнем случае значение будет переназначено, но не расширено. Выбор нужного метода зависит от конкретного порта. Убедитесь в том, что ваши порты не используют интерактивный режим установки, то есть не должны пытаться читать со стандартного устройства ввода ничего кроме того, что вы им подаёте на вход. Если это всё же происходит, то они будут считывать последующие строки из вашего перечня портов, описываемого в этом документе, и будут работать некорректно. Если скрипт stage_2.sh неожиданно пропустил порт или прекратил работу, причина может быть в этом. Ниже приводится stage_2.conf.default. Для каждого установленного им порта создаётся файл протокола LOGDIR/category+port. Скачайте stage_2.conf.default. Этап третий На втором этапе вы установили ваши любимые порты. Некоторые из них требуют небольшой настройки. Именно для этого и предназначен третий этап — этап настройки. Я мог бы интегрировать эту настройку в конец скрипта stage_2.sh. Однако я думаю, что есть концептуальное различие между установкой порта и модификацией его начальной конфигурации, и это требует отдельного шага. Я решил реализовать третий этап в виде файла Makefile, потому что это позволяет легко выбирать то, что вы хотите конфигурировать, следующим простым вызовом: &prompt.root; make -f stage_3.mk target Как и в случае с stage_2.sh, убедитесь, что файл stage_3.mk после загрузки новой системы есть в наличии, поместив его на совместно используемый раздел либо скопировав его куда-нибудь в новую систему. Ограничения Автоматизированная установка порта может оказаться затруднена, если она является интерактивной и не поддерживает команду make BATCH=YES install. Для нескольких портов интерактивность означает не более, чем ввод yes в ответ на вопрос о принятии некоторого лицензионного соглашения. Если такой ответ считывается со стандартного устройства ввода, мы просто направляем соответствующие ответы на вход установочной команды (к примеру: yes | make install). Для остальных портов вам придется разобраться, где конкретно находится интерактивная команда и соответственно ее обработать. Выше были приведены примеры для print/acroread8 and java/jdk16. Вы должны также принять во внимание вопросы обновления конфигурационных файлов. Вообще говоря, вы не знаете, когда и сменился ли вообще формат или содержимое конфигурационного файла. В файл /etc/group может быть добавлена новая группа, или в /etc/passwd может добавиться дополнительное поле. Всё это уже происходило в прошлом. Простое копирование конфигурационного файла из старой в новую систему может в большинстве случаев оказаться достаточным, но в этих случаях это не так. Если вы обновляете систему каноническим способом (путём перезаписывания старых файлов), вы должны использовать утилиту mergemaster для работы с изменениями, если вы хотите эффективно объединить вашу локальные настройки с потенциально новыми возможностями. К сожалению, mergemaster работает только с файлами базового комплекта системы, а не с любыми файлами, устанавливаемыми портами. Похоже, что стороннее программное обеспечение специально проектируется для того, чтобы я не дремал, и меняет конфигурационные файлы по два раза в месяц. Для обнаружения таких скрытых изменений, я держу копию изменённых конфигурационных файлов там же, где и stage_3.mk и сравниваю результат с помощью правил make. Например, для конфигурационного файла Apache, httpd.conf, целью будет config_apache. @if ! cmp -s /usr/local/etc/apache2/httpd.conf httpd.conf; then \ echo "ATTENTION: the httpd.conf has changed. Please examine if"; \ echo "the modifications are still correct. Here is the diff:"; \ diff -u /usr/local/etc/apache2/httpd.conf httpd.conf; \ fi Если разница между файлами несущественна я могу выполнить cp /usr/local/etc/apache2/httpd.conf httpd.conf. Я использовал систему &scratch.ap; несколько раз для обновления 7-CURRENT до 7-CURRENT и 8-CURRENT до 8-CURRENT, то есть я никогда не пытался установить 8-CURRENT из системы 7-STABLE и наоборот. Из-за количества изменений между релизами с разными старшими номерами я ожидаю, что этот процесс будет несколько более сложным. Использование &scratch.ap; для обновления внутри ветки STABLE должно проходить безболезненно (хотя я ещё не пробовал этого делать). Файлы Вот три файла, которые вам нужны кроме тех конфигурационных, что уже показаны выше. Это скрипт stage_1.sh, который вы не должны модифицировать. Скачайте stage_1.sh. Это скрипт stage_2.sh. Вам может понадобиться изменить переменные в самом начале файла. Скачайте stage_2.sh. Это мой файл stage_3.mk, который даст вам идею о том, как автоматизировать всю повторную конфигурацию. Скачайте stage_3.mk.
diff --git a/ru_RU.KOI8-R/articles/fonts/Makefile b/ru_RU.KOI8-R/articles/fonts/Makefile index 83bce9c48d..f635ca9152 100644 --- a/ru_RU.KOI8-R/articles/fonts/Makefile +++ b/ru_RU.KOI8-R/articles/fonts/Makefile @@ -1,23 +1,23 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/fonts/Makefile,v 1.4 2005/12/06 17:56:24 gad Exp $ # -# Original revision: r21827 +# Original revision: r39631 # # Article: Fonts and FreeBSD DOC?= article FORMATS?= html INSTALL_COMPRESSED?=gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/fonts/article.xml b/ru_RU.KOI8-R/articles/fonts/article.xml index 23194437a0..7da2ea9cd6 100644 --- a/ru_RU.KOI8-R/articles/fonts/article.xml +++ b/ru_RU.KOI8-R/articles/fonts/article.xml @@ -1,940 +1,940 @@
Шрифты и FreeBSDПособие DaveBodenstab
imdave@synet.net
7 августа 1996 $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.adobe; &tm-attrib.apple; &tm-attrib.linux; &tm-attrib.microsoft; &tm-attrib.opengroup; &tm-attrib.general; Этот документ содержит описание различных файлов шрифтов, которые могут использоваться с FreeBSD и драйвером системной консоли, системой X11, программами Ghostscript и Groff. Даются реально работающие примеры по переключению экрана системной консоли в режим 80x60 и использованию файлов шрифтов формата Type 1 с перечисленными выше прикладными программами. Введение Существует много мест, где можно найти файлы шрифтов, но встает вопрос о возможных способах их использования с FreeBSD. Ответ может быть найден в результате тщательного изучения документации по тем компонентам, которые вы собираетесь использовать. На это тратится очень много времени, и это пособие является попыткой дать готовые ответы для тех, кто заинтересуется такими вопросами. Основные термины Имеется множество различных форматов файлов шрифтов и соответствующих окончаний имен файлов. Здесь обсуждаются лишь следующие из них: .pfa, .pfb Файлы шрифтов &postscript; type 1. Файлы .pfa являются текстовым ( Ascii) представлением, а .pfb - двоичным (Binary). .afm Параметры (метрики) соответствующих шрифтов типа type 1. .pfm Метрики для принтеров соответствующих шрифтов типа type 1. .ttf Файл шрифтов &truetype; .fot Неявная ссылка на файл шрифтов TrueType (реальной информации о шрифте здесь не содержится) .fon, .fnt Файлы экранных шрифтов с побитным представлением Файлы .fot используются в &windows; в качестве некой символической ссылки на файл со шрифтом в формате &truetype; (.ttf). Файлы шрифтов .fon также используются в &windows;. Мне неизвестно, как можно использовать этот формат шрифтов во FreeBSD. Какие форматы файлов шрифтов я могу использовать? То, файл шрифтов какого формата будет полезен, зависит от используемого приложения. Сама по себе FreeBSD шрифтов не использует. Прикладные программы и/или драйверы могут использовать файлы шрифтов. Вот краткий справочник по типам файлов шрифтов и приложениям/драйверам: Драйвер syscons .fnt Приложение Ghostscript .pfa, .pfb, .ttf X11 .pfa, .pfb Groff .pfa, .afm Povray .ttf Окончание .fnt используется достаточно часто. Я полагаю, что когда кто-нибудь собирается создать файл шрифтов для своего приложения, чаще всего выбирается именно это окончание. Поэтому файлы с таким окончанием не все имеют одинаковый формат; в частности, формат файлов .fnt, используемых драйвером syscons во FreeBSD, может отличаться от формата файлов .fnt, встречающихся в &ms-dos;/&windows;. Я даже не пытался использовать другие файлы .fnt, кроме тех, что поставляются с FreeBSD. Настройка виртуальной консоли на режим работы 80x60 Во-первых, должен быть загружен шрифт размера 8x8. Для этого файл /etc/rc.conf должен содержать строчку (измените в ней имя файла со шрифтом на соответствующий вашей локализации): font8x8="iso-8x8" # font 8x8 from /usr/share/syscons/fonts/* (or NO). Команда для переключения режимов называется &man.vidcontrol.1;: &prompt.user; vidcontrol VGA_80x60 Различные программы, ориентированные на работу с экраном, такие, как &man.vi.1;, должны уметь определять текущие размеры экрана. Так как это делается через вызовы ioctl к драйверу консоли (такому, как &man.syscons.4;), то размеры будут определяться правильно. Чтобы это проходило более гладко, можно включить эти команды в скрипты начальной загрузки, чтобы они выполнялись при запуске системы. Чтобы это сделать, добавьте такую строчку в /etc/rc.conf allscreens_flags="VGA_80x60" # Set this vidcontrol mode for all virtual screens Справочная информация: &man.rc.conf.5;, &man.vidcontrol.1;. Использование шрифтов type 1 с системой <application>X11</application> X11 может использовать файлы шрифтов в формате .pfa или .pfb. Шрифты для X11 располагаются в различных подкаталогах в /usr/X11R6/lib/X11/fonts. На каждый файл со шрифтом имеется ссылка по его X11-имени в файле fonts.dir в каждом таком каталоге. Существует каталог по имени Type1. Самым простым способом добавить новый шрифт заключается в помещении его в этот каталог. Но лучше хранить все новые шрифты в отдельном каталоге и использовать символические ссылки для добавляемых шрифтов. Это позволяет легко управлять отдельными добавляемыми шрифтами, не путая их с изначально поставляемыми. Например: Создаем каталог для файлов шрифтов &prompt.user; mkdir -p /usr/local/share/fonts/type1 &prompt.user; cd /usr/local/share/fonts/type1 Помещаем сюда файлы .pfa, .pfb и .afm Кому-то может потребоваться хранить здесь также сопроводительные файлы и документацию к шрифтам &prompt.user; cp /cdrom/fonts/atm/showboat/showboat.pfb . &prompt.user; cp /cdrom/fonts/atm/showboat/showboat.afm . Обновление индексного файла со ссылками на файлы шрифтов &prompt.user; echo showboat - InfoMagic CICA, Dec 1994, /fonts/atm/showboat >>INDEX Теперь, чтобы использовать новый шрифт с X11, нужно дать доступ к файлу шрифтов и обновить файлы и именами шрифтов. Имена шрифтов в X11 выглядят следующим образом: -bitstream-charter-medium-r-normal-xxx-0-0-0-0-p-0-iso8859-1 | | | | | | | | | | | | \ \ | | | | | \ \ \ \ \ \ \ +----+- набор символов | | | | \ \ \ \ \ \ \ +- средняя ширина | | | | \ \ \ \ \ \ +- spacing | | | \ \ \ \ \ \ +- разрешение по вертикали | | | \ \ \ \ \ +- разрешение по горизонтали | | | \ \ \ \ +- пунктов | | | \ \ \ +- пиксел | | | \ \ \ foundry family weight slant width additional style Для каждого нового файла шрифтов необходимо создать новое имя. Если у вас есть какая-либо информация из сопроводительной документации к шрифту, то она может служить основой для создания имени. Если информации нет, то можно получить некоторую информацию от использования программы &man.strings.1; над файлом шрифта. Например: &prompt.user; strings showboat.pfb | more %!FontType1-1.0: Showboat 001.001 %%CreationDate: 1/15/91 5:16:03 PM %%VMusage: 1024 45747 % Generated by Fontographer 3.1 % Showboat 1991 by David Rakowski. Alle Rechte Vorbehalten. FontDirectory/Showboat known{/Showboat findfont dup/UniqueID known{dup /UniqueID get 4962377 eq exch/FontType get 1 eq and}{pop false}ifelse {save true}{false}ifelse}{false}ifelse 12 dict begin /FontInfo 9 dict dup begin /version (001.001) readonly def /FullName (Showboat) readonly def /FamilyName (Showboat) readonly def /Weight (Medium) readonly def /ItalicAngle 0 def /isFixedPitch false def /UnderlinePosition -106 def /UnderlineThickness 16 def /Notice (Showboat 1991 by David Rakowski. Alle Rechte Vorbehalten.) readonly def end readonly def /FontName /Showboat def --stdin-- Пользуясь этой информацией, можно составить возможное имя: -type1-Showboat-medium-r-normal-decorative-0-0-0-0-p-0-iso8859-1 Компонентами нашего имени являются: Foundry Давайте называть все новые шрифты type1. Family Имя шрифта. Weight Normal, bold, medium, semibold, и так далее. Из результата работы команды &man.strings.1; похоже, что этот шрифт имеет ширину medium. Slant roman, italic, oblique, и так далее. Так как ItalicAngle равен нулю, то будет использоваться roman. Width Normal, wide, condensed, extended, и так далее. Пока это не будет проверено, предполагаем normal. Дополнительный стиль Обычно опускается, но он будет указывать, что в шрифте есть декоративные заглавные буквы. Spacing proportional или monospaced. Используется proportional, потому что isFixedPitch равен false. Все эти имена произвольны, но нужно стараться следовать существующим соглашениям. В программе для X11 на шрифт ссылаются по имени с применением шаблонов, так что в выбираемом имени это должно учитываться. Можно начать с простого использования …-normal-r-normal-…-p-… в качестве имени, а затем использовать &man.xfontsel.1; для его проверки и изменения имени на основе того, как выглядит шрифт. Итак, завершая наш пример: Делаем шрифт доступным для X11 &prompt.user; cd /usr/X11R6/lib/X11/fonts/Type1 &prompt.user; ln -s /usr/local/share/fonts/type1/showboat.pfb . Редактируем файлы fonts.dir and fonts.scale, добавляя строку, описывающую шрифт и увеличивая количество шрифтов в первой строке. &prompt.user; ex fonts.dir :1p 25 :1c 26 . :$a showboat.pfb -type1-showboat-medium-r-normal-decorative-0-0-0-0-p-0-iso8859-1 . :wq fonts.scale идентичен fonts.dir… &prompt.user; cp fonts.dir fonts.scale Указываем X11, что произошли изменения &prompt.user; xset fp rehash Проверяем новый шрифт &prompt.user; xfontsel -pattern -type1-* Справочная информация: &man.xfontsel.1;, &man.xset.1;, The X Windows System in a Nutshell, O'Reilly & Associates. Использование шрифтов type 1 с пакетом Ghostscript Ghostscript ссылается на шрифт через свой файл Fontmap. Он должен быть подправлен так же, как и файл fonts.dir в случае X11. Ghostscript может использовать файлы шрифтов в форматах .pfa или .pfb. Взяв шрифт из предыдущего примера, его можно использовать с Ghostscript вот так: Помещаем файл со шрифтом в каталог со шрифтами Ghostscript &prompt.user; cd /usr/local/share/ghostscript/fonts &prompt.user; ln -s /usr/local/share/fonts/type1/showboat.pfb . Редактируем Fontmap, чтобы Ghostscript знал о шрифте &prompt.user; cd /usr/local/share/ghostscript/4.01 &prompt.user; ex Fontmap :$a /Showboat (showboat.pfb) ; % From CICA /fonts/atm/showboat . :wq Используем Ghostscript для проверки шрифта &prompt.user; gs prfont.ps Aladdin Ghostscript 4.01 (1996-7-10) Copyright (C) 1996 Aladdin Enterprises, Menlo Park, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Loading Times-Roman font from /usr/local/share/ghostscript/fonts/tir_____.pfb... /1899520 581354 1300084 13826 0 done. GS>Showboat DoFont Loading Showboat font from /usr/local/share/ghostscript/fonts/showboat.pfb... 1939688 565415 1300084 16901 0 done. >>showpage, press <return> to continue<< >>showpage, press <return> to continue<< >>showpage, press <return> to continue<< GS>quit Справочная информация: fonts.txt из дистрибутива Ghostscript 4.01 Использование шрифтов в формате type 1 с программой Groff Теперь, когда новый шрифт может быть использован как с X11, так и в Ghostscript, как использовать его с программой groff? Во-первых, так как мы имеем дело со &postscript;-шрифтами формата type 1, то подходящим устройством groff является ps. Для каждого шрифта, который может использоваться программой groff, должен быть создан файл шрифта. Имя шрифта для groff является просто именем файла из каталога /usr/share/groff_font/devps. В нашем примере файлом шрифта может быть /usr/share/groff_font/devps/SHOWBOAT. Файл должен быть создан с помощью утилит, поставляемых с программой groff. Первой утилитой является afmtodit. Обычно она не устанавливается, так что она должна быть получена из дистрибутива с исходными текстами. Я обнаружил, что нужно изменить первую строку файла, что я делал так: &prompt.user; cp /usr/src/gnu/usr.bin/groff/afmtodit/afmtodit.pl /tmp &prompt.user; ex /tmp/afmtodit.pl :1c #!/usr/bin/perl -P- . :wq Эта утилита создаст файл шрифтов для groff из файла метрик (с окончанием .afm). Продолжая с нашим примером: Многие файлы .afm в формате Mac … строки разделены символом ^M. Нам нужно преобразовать их в разделитель ^J в стиле &unix; &prompt.user; cd /tmp &prompt.user; cat /usr/local/share/fonts/type1/showboat.afm | tr '\015' '\012' >showboat.afm Теперь создаем файл шрифтов groff &prompt.user; cd /usr/share/groff_font/devps &prompt.user; /tmp/afmtodit.pl -d DESC -e text.enc /tmp/showboat.afm generate/textmap SHOWBOAT Теперь к шрифту можно обращаться по имени SHOWBOAT. Если в системе для управления принтерами используется программа Ghostscript, то больше ничего делать не нужно. Однако, если используются настоящие &postscript;-принтеры, то для использования шрифта его нужно загрузить в принтер (если только в принтере шрифт showboat не встроен или не имеется на диске со шрифтами). Последний шаг заключается в создании загружаемого шрифта. Утилита pfbtops используется для создания шрифта в формате .pfa, а файл для загрузки изменяется для указания нового шрифта. Файл для загрузки должен ссылаться на внутреннее имя шрифта. Оно может быть легко определено из файла шрифтов groff, как это показывается здесь: Создание файла шрифта .pfa &prompt.user; pfbtops /usr/local/share/fonts/type1/showboat.pfb >showboat.pfa Конечно, если файл .pfa уже имеется, для его использования создаем символическую ссылку на него. Получение внутреннего имени шрифта &prompt.user; fgrep internalname SHOWBOAT internalname Showboat Указываем утилите groff, что шрифт должен быть загружен &prompt.user; ex download :$a Showboat showboat.pfa . :wq Для тестирования шрифта: &prompt.user; cd /tmp &prompt.user; cat >example.t <<EOF .sp 5 .ps 16 This is an example of the Showboat font: .br .ps 48 .vs (\n(.s+2)p .sp .ft SHOWBOAT ABCDEFGHI .br JKLMNOPQR .br STUVWXYZ .sp .ps 16 .vs (\n(.s+2)p .fp 5 SHOWBOAT .ft R To use it for the first letter of a paragraph, it will look like: .sp 50p \s(48\f5H\s0\fRere is the first sentence of a paragraph that uses the showboat font as its first letter. Additional vertical space must be used to allow room for the larger letter. EOF &prompt.user; groff -Tps example.t >example.ps Для использования с ghostscript/ghostview &prompt.user; ghostview example.ps Для его печати &prompt.user; lpr -Ppostscript example.ps Справочная информация: /usr/src/gnu/usr.bin/groff/afmtodit/afmtodit.man, &man.groff.font.5;, &man.groff.char.7;, &man.pfbtops.1;. Преобразование файлов шрифтов TrueType в формат groff/PostScript для использования с groff Потенциально это требует некоторых усилий, просто потому что зависит некоторых утилит, которые в качестве части системы не устанавливаются. Это: ttf2pf Утилита для преобразования TrueType в PostScript. Она позволяет преобразовать шрифт TrueType в метрику шрифта в текстовом формате (файл .afm). Доступна по адресу http://sunsite.icm.edu.pl/pub/GUST/contrib/BachoTeX98/ttf2pf/. Замечание: Эти файлы являются PostScript-программами и должны быть скачаны на диск щелчком на ссылке при нажатой клавише Shift. В противном случае для их просмотра ваш браузер может попытаться запустить программу ghostview. Интерес представляют следующие файлы: GS_TTF.PS PF2AFM.PS ttf2pf.ps Смесь верхнего/нижнего регистров присутствует из-за того, что эти файлы предназначены и для DOS. ttf2pf.ps использует остальные с именами в верхнем регистре, так что при переименовании это нужно учитывать. (На самом деле GS_TTF.PS и PFS2AFM.PS предположительно являются частью дистрибутива Ghostscript, но их легко использовать как отдельные утилиты. В поставку FreeBSD они не включены.) Вы можете также установить их в каталог /usr/local/share/groff_font/devps(?). afmtodit Создает файлы шрифтов для использования с программой groff из текстовых файлов с метриками шрифта. Она обычно располагается в каталоге /usr/src/contrib/groff/afmtodit и для ее использования требуется проделать некоторую работу. Если вы избегаете работать в дереве /usr/src, просто скопируйте содержимое вышеупомянутого каталога во временный рабочий каталог. Во рабочем каталоге вам нужно построить утилиту. Просто введите такую команду: # make -f Makefile.sub afmtodit Вам может также потребоваться скопировать /usr/contrib/groff/devps/generate/textmap в /usr/share/groff_font/devps/generate, если его только уже не существует. Как только эти утилиты готовы, вы можете начать: Создайте файл .afm по такой команде: % gs -dNODISPLAY -q -- ttf2pf.ps TTF_name PS_font_name AFM_name Здесь TTF_name обозначает ваш файл со шрифтом TrueType, PS_font_name является именем для файла .pfa, AFM_name задает имя для файла .afm. Если вы не укажете имена выходных файлов, для форматов .pfa или .afm, то по умолчанию будут использоваться имена, получаемые из имени файла со шрифтом TrueType. При этом также будет создан файл .pfa, текстовый файл с метриками PostScript-шрифта ((.pfb для двоичного представления). Это не не обязательно, но может быть (я думаю) полезным для сервера шрифтов. Например, для преобразования шрифта 30f9 Barcode с именами файлов по умолчанию, воспользуйтесь следующей командой: % gs -dNODISPLAY -- ttf2pf.ps 3of9.ttf Aladdin Ghostscript 5.10 (1997-11-23) Copyright (C) 1997 Aladdin Enterprises, Menlo Park, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Converting 3of9.ttf to 3of9.pfa and 3of9.afm. Если вы хотите, чтобы преобразованные шрифты сохранялись в файлы A.pfa and B.afm, то выдайте такую команду: % gs -dNODISPLAY -- ttf2pf.ps 3of9.ttf A B Aladdin Ghostscript 5.10 (1997-11-23) Copyright (C) 1997 Aladdin Enterprises, Menlo Park, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Converting 3of9.ttf to A.pfa and B.afm. Создайте PostScript-файл для groff: Смените текущий каталог на /usr/share/groff_font/devps для облегчения запуска упоминаемых далее программ. Для этого вам может понадобиться иметь привилегии администратора системы. (Или, если вы избегаете здесь работать, обязательно посмотрите файлы DESC, text.enc и generate/textmap в этом каталоге.) % afmtodit -d DESC -e text.enc file.afm \ generate/textmap PS_font_name Здесь file.afm является файлом AFM_name, созданным программой ttf2pf.ps выше, а PS_font_name является именем шрифта, используемым в той команде, так же, как и имя, которое будет использовать утилита &man.groff.1; для ссылки на этот шрифт. Например, полагая, что вы использовали первую команду tiff2pf.ps выше, то шрифт 3of9 Barcode может быть создан при помощи такой команды: % afmtodit -d DESC -e text.enc 3of9.afm \ generate/textmap 3of9 Проверьте, что полученный файл PS_font_name (к примеру, 3of9 из примера выше) расположен в каталоге /usr/share/groff_font/devps, скопировав или перенеся его сюда. Заметьте, что если ttf2pf.ps назначает имя шрифта, используя один из найденных в файле шрифта TrueType, а вы хотите использовать другое имя, то вы должны отредактировать файл .afm до запуска команды afmtodit. Это имя к тому же должно совпадать с тем, что используется в файле Fontmap, если вы собираетесь перенаправлять вывод &man.groff.1; утилите &man.gs.1;. Можно ли использовать шрифты в формате TrueType с другими программами? Формат TrueType используется в Windows, Windows 95 и на компьютерах Macintosh. Он достаточно популярен и в этом формате имеется большое количество шрифтов. К сожалению, я знаю лишь несколько программ, которые могут использовать этот формат: на ум приходят Ghostscript и Povray. Его поддержка в программе Ghostscript, согласно документации, находится в зачаточном состоянии и получаемый результат хуже того, что получается при использовании шрифтов type 1. Программа Povray версии 3 также может использовать шрифты TrueType, но я очень сомневаюсь, что много кто создает документы как последовательность анимированных страниц :-). Такая весьма печальная ситуация может вскоре измениться. В рамках проекта FreeType Project в настоящее время разрабатывается полезный набор инструментов для работы с FreeType: Сервер шрифтов xfsft для X11 может работать и со шрифтами TrueType, и с обычными шрифтами. Хотя в настоящее время он еще находится в стадии отладки, но его уже можно использовать. Посмотрите страницу Juliusz Chroboczek, чтобы получить более полную информацию. Указания по переносу на FreeBSD можно найти на странице Стивена Монтгомери (Stephen Montgomery), посвященной программному обеспечению. xfstt является еще одним сервером шрифтов для X11, доступный по адресу ftp://sunsite.unc.edu/pub/Linux/X11/fonts. Программа, которая называется ttf2bdf, может генерировать BDF-файлы, которые можно использовать в системе X Window, из файлов шрифтов TrueType. Выполнимые файлы Linux могут находиться по адресу ftp://crl.nmsu.edu/CLR/multiling/General. и другие … Где можно найти дополнительные шрифты? Много шрифтов можно найти в сети Интернет. Они либо абсолютно бесплатны, либо условно-бесплатны. Кроме того, продается много недорогих компакт-дисков, содержащих много шрифтов. Вот некоторые адреса Интернет (на август 1996): http://www.simtel.net/ http://www.freshmeat.net Сгрузите шрифты, поставляемые с Коллекцией Портов в каталоге x11-fonts/ Дополнительные вопросы Для чего предназначены файлы .pfm? Можно ли получить файл .afm из файла .pfa или .pfb? Как получить файлы преобразования символов groff для PostScript-шрифтов с нестандартными названиями символов? Можно ли настроить xditview и устройства devX?? на работу всех новых шрифтов? Хорошо бы иметь примеры использования шрифтов TrueType с программами Povray и Ghostscript.
diff --git a/ru_RU.KOI8-R/articles/freebsd-questions/Makefile b/ru_RU.KOI8-R/articles/freebsd-questions/Makefile index 23294cf41a..6ebef0d245 100644 --- a/ru_RU.KOI8-R/articles/freebsd-questions/Makefile +++ b/ru_RU.KOI8-R/articles/freebsd-questions/Makefile @@ -1,23 +1,23 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/freebsd-questions/Makefile,v 1.4 2005/10/28 17:35:48 gad Exp $ # -# Original revision: r21827 +# Original revision: r39631 # DOC?= article FORMATS?= html WITH_ARICLE_TOC?= YES INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/freebsd-questions/article.xml b/ru_RU.KOI8-R/articles/freebsd-questions/article.xml index 20cce46705..e76e214370 100644 --- a/ru_RU.KOI8-R/articles/freebsd-questions/article.xml +++ b/ru_RU.KOI8-R/articles/freebsd-questions/article.xml @@ -1,616 +1,616 @@
Как работать со списком рассылки FreeBSD-questions c максимальной отдачей GregLehey
grog@FreeBSD.org
 &tm-attrib.freebsd; &tm-attrib.microsoft; &tm-attrib.opengroup; &tm-attrib.qualcomm; &tm-attrib.general; $FreeBSD$ $FreeBSD$ В этом документе содержится информация, которая будет полезна тем, кто собирается отправить письмо в список рассылки FreeBSD-questions. Даются советы и рекомендации, которые максимально увеличат шанс на получение полезных ответов. Этот документ регулярно публикуется в списке рассылки FreeBSD-questions. Введение FreeBSD-questions является списком рассылки, который поддерживается проектом FreeBSD для оказания помощи тем, у кого возникли вопросы по поводу использования FreeBSD в повседневной работе. В другом списке рассылки, FreeBSD-hackers, обсуждаются более сложные вопросы, такие, как направление будущей работы над системой. Термин хакер не имеет ничего общего с проникновением на компьютеры других людей. Правильным термином для обозначения такой деятельности является кракер, однако популярная пресса этого еще не поняла. Хакеры FreeBSD нарушением защиты не занимаются. Более полное описание хакеров находится в руководстве Эрика Рэймонда (Eric Raymond) Как стать хакером Данный регулярно рассылаемый документ предназначен для помощи как тем, кто ищет ответов на вопросы во FreeBSD-questions (новички), так и тем, кто на эти вопросы отвечает (хакеры). Несомненно, здесь существуют некоторые трения, которые проистекают из-за разных точек зрения этих двух групп. Новички обвиняют хакеров в высокомерии, заносчивости и несостоятельности в оказании помощи, когда как хакеры обвиняют начинающих в том, что последние глупы, не умеют читать по-английски и ждут, что им все будет преподнесено на блюдечке с голубой каемочкой. Конечно, есть элемент правды в обоих этих утверждениях, однако по большей части такие мнения появляются из-за чувства разочарования. В этом документе я постараюсь уменьшить это разочарование и помочь всем получить более хорошие результаты от FreeBSD-questions. В следующем разделе я дам рекомендации по посылке вопросов; после этого мы посмотрим, как нужно на них отвечать. Как подписаться на FreeBSD-questions FreeBSD-questions является списком рассылки, распространяемым по электронной почте, поэтому вам нужен доступ к системе электронной почты. Зайдите через ваш WWW браузер на информационную страничку списка рассылки FreeBSD-question. В разделе Подписка на freebsd-questions (Subscribing to freebsd-questions) заполните поле Ваш адрес электронной почты (Your email address); другие поля являются опциональными. Поля для паролей в форме для подписки предоставляют только слабую защищённость, но должны предохранить других от путаницы с вашей подпиской. Не используйте ценный пароль, потому как он будет отослан вам по почте обратно в виде незашифрованного текста. Вы получите подтверждающее письмо от mailman; следуйте включенным в него инструкциям для завершения процесса подписки. И наконец, когда вы получите приветственное письмо от mailman с подробной информацией о списке и с паролем, пожалуйста, сохраните его. Если вы когда-нибудь захотите покинуть список рассылки, вам нужна будет эта информация. За дополнительной информацией обращайтесь к следующему разделу. Как отписаться от FreeBSD-questions Когда вы подписывались на список рассылки FreeBSD-questions, вы получили приглашающее сообщение от mailman. В этом сообщении, кроме всего прочего, вам рассказывалось о том, как отписаться. Вот типичное сообщение: Welcome to the freebsd-questions@freebsd.org mailing list! To post to this list, send your email to: freebsd-questions@freebsd.org General information about the mailing list is at: http://lists.freebsd.org/mailman/listinfo/freebsd-questions If you ever want to unsubscribe or change your options (e.g., switch to or from digest mode, change your password, etc.), visit your subscription page at: http://lists.freebsd.org/mailman/options/freebsd-questions/grog%40lemsi.de You can also make such adjustments via email by sending a message to: freebsd-questions-request@freebsd.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: 12345 Normally, Mailman will remind you of your freebsd.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. Используя URL, указанный в вашем приветственном сообщении, вы можете посетить страничку по управлению учетной записью и запросить отписать вас от списка рассылки FreeBSD-questions. Подтверждающее письмо будет выслано вам от mailman; следуйте включённым в него инструкциям для завершения процесса отписки. Если вы это сделали, и до сих пор не можете понять, что происходит, отправьте письмо на freebsd-questions-request@FreeBSD.org, и они помогут вам разобраться. Не посылайте сообщений во FreeBSD-questions: здесь вам помочь не смогут. Нужно задавать вопросы в <literal>-questions</literal> или <literal>-hackers</literal>? Общим вопросам по FreeBSD посвящены два списка рассылки, FreeBSD-questions и FreeBSD-hackers. В некоторых случаях на самом деле не ясно, в каком списке нужно задавать вопрос. Следующий критерий, однако, должен помочь в 98% всех случаев: Если вопрос является общим, спрашивайте во FreeBSD-questions. Примерами могут служить вопросы по установке FreeBSD или использованию конкретных утилит &unix;. Если вы думаете, что вопрос относится к ошибке, но вы не уверены или не знаете, как ее исправить, пошлите сообщение во FreeBSD-questions. Если вопрос относится к ошибке и вы уверены, что это ошибка (например, вы можете указать место в коде, где она происходит, и, может быть, у вас есть для нее исправление), то пошлите сообщение в список рассылки FreeBSD-hackers. Если вопрос относится к усовершенствованию FreeBSD, и вы можете дать предложения по ее реализации, то посылайте сообщение во FreeBSD-hackers. Имеется также некоторое количество других специализированных списков рассылки, например, FreeBSD-isp, которые отражают интересы ISP (Поставщиков Услуг Интернет), работающих со FreeBSD. Если случилось так, что вы являетесь ISP, это вовсе не значит, что вы должны автоматически посылать свои вопросы в список рассылки FreeBSD-isp. Здесь также подходит критерий, указанный выше, и в ваших интересах следовать ему, потому что именно так можно получить результат. Перед посылкой вопроса Вы можете (и должны) что-нибудь сделать сами перед тем, как задать вопрос в одном из списков рассылки: Попытайтесь решить проблему самостоятельно. Если вы пошлёте вопрос, который покажет, что вы пытались решить проблему, ваш вопрос, как правило, привлечёт более положительное внимание со стороны людей, читающих его. Попытка решить проблему самостоятельно также увеличит уровень вашего понимания FreeBSD, и в конечном счёте позволит вам использовать ваши знания для помощи другим, отвечая на вопросы, посылаемые в списки рассылки. Прочтите страницы справочника и документацию FreeBSD (установлена в /usr/doc или доступна через WWW на http://www.FreeBSD.org), особенно Руководство пользователя и FAQ. Просмотрите и/или поищите в архивах списка рассылки, задавился ли ваш или схожий вопрос (и возможно отвечался) в списке. Вы можете просмотреть и/или поискать в архивах списков рассылки на http://www.FreeBSD.org/mail и http://www.FreeBSD.org/search/search.html#mailinglists соответственно. Это может быть сделано также и на других WWW сайтах, к примеру, на http://marc.theaimsgroup.com. Используйте поисковик, например, Google или Yahoo для поиска ответов на ваш вопрос. Google имеет даже BSD ориентированный поисковой интерфейс. Как посылать вопрос При посылке сообщения в список рассылки FreeBSD-questions, имейте в виду следующее: Помните, что за ответы на вопросы о FreeBSD никто денег не получает. Все делают это в свободное время. Вы можете привлечь внимание, послав четко сформулированный вопрос, содержащий как можно больше относящейся к делу информации. Вы можете не получить внимания, послав неполный, непонятный или примитивный вопрос. В действительности можно посылать сообщение в список рассылки FreeBSD-questions и не получить ответа, даже если вы следуете этим правилам. Еще более вероятно не получить ответа, если вы им не следуете. В оставшейся части документа мы рассмотрим, как получить максимум от вопроса во FreeBSD-questions. Не всякий человек, могущий ответить на вопрос о FreeBSD, читает все сообщения: обычно читается строка с темой письма и решается, представляет ли сообщение интерес. То есть в ваших интересах указать тему письма. FreeBSD problem или Help недостаточно. Если вы не укажете тему вообще, то многие даже не потрудятся прочесть сообщение. Если тема сообщения недостаточно конкретна, то люди, которые могут ответить, могут его не прочесть. Оформляйте ваше сообщение так, чтобы оно было читабельно, и ПОЖАЛУЙСТА, НЕ КРИЧИТЕ!!!!!. Мы понимаем, что для многих английский не является родным языком, и не исключаем этого, однако действительно очень трудно и мучительно читать сообщение, полное опечаток или в котором отсутствуют разделители строк. Не упускайте из виду эффект, который производит плохо отформатированное письмо, причем не только в списке рассылки FreeBSD-questions. По вашему почтовому сообщению люди составляют мнение о вас, и если сообщение плохо отформатировано, содержит по одной строке на абзац, неправильно разделено или полно ошибок, то о вас сложится плохое впечатление. Множество плохо форматированных сообщений возникает из-за неправильно работающих или плохо настроенных почтовых программ. Известно, что следующие почтовые программы могут посылать неправильно отформатированные сообщения без вашего ведома об этом: &eudora; exmh µsoft; Exchange µsoft; Outlook Постарайтесь не использовать MIME: многие используют программы, которые не очень хорошо работают с MIME. Проверьте правильность настроек времени и временной зоны. Это может выглядеть немножко глупо, потому что ваши сообщения все равно будут доставляться, однако многие люди получают несколько сотен сообщений в день. Зачастую они сортируют входящие сообщения по теме и дате, и если ваше сообщение не будет предшествовать первому ответу, то они могут предположить, что оно потерялось и даже не взглянут на него. Не включайте не связанные друг с другом вопросы в одно и то же письмо. Во-первых, длинное сообщение отпугивает людей, а во-вторых, труднее найти людей, которые могут ответить на все вопросы, и прочитали такое сообщение. Сообщите максимальное количество информации. Это трудно, и нужно пояснить, какую информацию нужно сообщать, а поначалу: Практически в любом случае важно знать версию FreeBSD, с которой вы работаете. Особенно, в частности, в случае FreeBSD-CURRENT вы должны также указать дату исходных текстов, хотя, конечно, вам не нужно посылать сообщения о -CURRENT в список рассылки FreeBSD-questions. В случае любой проблемы, которая может быть связана с работой оборудования, расскажите о вашем аппаратном обеспечении. В случае сомнений предположите, что это, возможно, вина оборудования. Какой тип процессора используется? Насколько он быстр? Какая материнская плата? Сколько установлено памяти? Какое периферийное оборудование? Конечно, это приговор, но вывод команды &man.dmesg.8; зачастую может оказаться очень полезным, так как он говорит не только об оборудовании, с которым вы работаете, но также и о версии FreeBSD. Если выдаются сообщения об ошибках, недостаточно написать I get error messages, напишите (например) I get the error message 'No route to host'. Если ваша система завершает работу аварийно, не пишите My system panicked, напишите (к примеру) my system panicked with the message 'free vnode isn't'. Если у вас возникли трудности при установке FreeBSD, пожалуйста, опишите ваше оборудование. В частности, важно знать адреса ввода/вывода и IRQ адаптеров, установленных в вашей машине. Если у вас возникли трудности в настройке PPP, опишите настройку. Какую версию PPP вы используете? Какой тип аутентификации? У вас используется статическое или динамическое выделение адресов IP? Какие сообщения вы получили в файле протокола? Основной объем информации, который вы должны дать, представляет собой вывод программ, таких, как &man.dmesg.8;, или консольные сообщения, которые обычно появляются в файле /var/log/messages. Не пытайтесь скопировать эту информацию, набрав ее снова; это действительно трудно, и здесь легко сделать ошибку. Чтобы послать содержимое файлов протоколов, сделайте копию файла и воспользуйтесь редактором для того, чтобы обрезать информацию, оставив только относящуюся к делу, либо скопируйте и вставьте текст в ваше сообщение. В случае вывода программ, таких, как &man.dmesg.8;, перенаправьте вывод в файл и включите его в письмо. Например, &prompt.user; dmesg > /tmp/dmesg.out Эта команда перенаправляет информацию в файл /tmp/dmesg.out. Если вы все это сделали, и все же не можете получить ответа, этому могут быть другие причины. Например, проблема столь сложна, что никто не знает ответа, или тот, кто знает, отсутствовал. Если вы не получили ответа, скажем, в течении недели, может помочь повторная посылка сообщения. Если вы не получили ответа на свое второе послание, скорее всего, вы вовсе не получите его из этого списка рассылки. Повторная посылка того же самого сообщения снова и снова только повредит вашей репутации. Подводя итог, давайте предположим, что вы знаете ответ на следующий вопрос (да, это один и тот же вопрос). Выберите, на какой вопрос вы в большей степени готовы ответить: Сообщение 1 Subject: HELP!!?!?? I just can't get hits damn silly FereBSD system to workd, and Im really good at this tsuff, but I have never seen anythign sho difficult to install, it jst wont work whatever I try so why don't you guys tell me what I doing wrong. Сообщение 2 Subject: Problems installing FreeBSD I've just got the FreeBSD 2.1.5 CDROM from Walnut Creek, and I'm having a lot of difficulty installing it. I have a 66 MHz 486 with 16 MB of memory and an Adaptec 1540A SCSI board, a 1.2GB Quantum Fireball disk and a Toshiba 3501XA CDROM drive. The installation works just fine, but when I try to reboot the system, I get the message Missing Operating System. Как дополнить вопрос Часто вам бывает нужно дать дополнительную информацию к вопросу, который вы уже отослали. Лучшим способом сделать это является ответ на первоначальное сообщение. Здесь есть три момента: Вы включаете текст исходного сообщения, чтобы люди знали, о чем вы говорите. Однако не забудьте удалить ненужный текст. Текст в строке с темой письма остается тем же самым (вы не забыли его указать, не правда ли?). Многие почтовые программы сортируют сообщения по теме письма. Это поможет при группировке сообщений. Ссылочные номера сообщений в заголовке будут указывать на предыдущее сообщение. Некоторые почтовые программы, такие, как mutt, могут упорядочивать сообщения, показывая точную связь между ними. Как отвечать на вопрос Перед тем, как отвечать на вопрос в списке рассылки FreeBSD-questions, имейте в виду: Многие замечания, касающиеся посылки вопросов, относятся и к ответам на них. Прочтите эти замечания. Ответил ли кто-либо на вопрос? Самым простым способом проверить это является сортировка входящей почты по темам писем: тогда (надеемся) вы увидите вопрос с последующими ответами все вместе. Если кто-то уже ответил на вопрос, это вовсе не значит, что вы не должны посылать свой ответ. Но сначала имеет смысл прочитать все другие ответы. Есть ли у вас что добавить сверх того, что уже было сказано? В общем случае ответы Yeah, me too сильно не помогут, хотя есть и исключения, например, когда кто-нибудь описывает свою проблему и не знает, его ли это ошибка, или что-то не так с аппаратным или программным обеспечением. Если вы посылаете сообщение me too, включите также относящуюся к делу информацию. Уверены ли вы, что поняли вопрос? Очень часто тот, кто задает вопрос, путается или не может все хорошо описать. Даже при самом полном понимании системы легко послать ответ, который не отвечает на вопрос. К сожалению, так вы никому не поможете, только ещё больше запутаете и разочаруете спрашивающего. Если никто больше не отвечает, или вы не очень уверены, то всегда можете запросить более подробную информацию. Уверены ли вы, что ваш ответ корректен? Если нет, то подождите пару дней. Если никого больше не появится с лучшим ответом, чем ваш, то вы можете ответить и сказать, например, I don't know if this is correct, but since nobody else has replied, why don't you try replacing your ATAPI CDROM with a frog?. Если нет причин поступить как-то иначе, то ответьте отправителю и в список рассылки FreeBSD-questions. Многие подписчики FreeBSD-questions таятся: они учатся на чтении сообщений, посланных и отвеченных другими. Если вы пошлете сообщение, представляющее интерес для всех, минуя список рассылки, то лишите этих людей их информации. Будьте внимательны при ответе всем; многие посылают сообщения с сотнями CC-адресатов. В таких случаях удалите лишние строки Cc:. Из исходного сообщения включите текст, который относится к делу. Избегайте излишнего цитирования, но не переусердствуйте. Тот, кто не читал первоначального сообщения, должен понять, о чём же идёт речь. Используйте приемы выделения текста, который взят из исходного сообщения и текста, который добавили вы. Лично я нахожу, что для первоначального текста лучше всего работает вставка символа > . Вставка пробела после > и пустых строк между вашим и первоначальным текстами сделает результат более читабельным. Поместите ваш ответ в правильном месте (после текста, на который вы отвечаете). Очень трудно читать набор ответов, когда каждый из них следует перед текстом, к которому относится. Большинство почтовых программ меняют строку темы письма в ответе, предваряя ее текстом типа Re: . Если ваша почтовая программа не делает это автоматически, вы должны делать это вручную. Если спрашивающий не следует соглашениям по форматированию текста (слишком длинные строки, неподходящая строка темы), пожалуйста, исправьте эти ошибки. В случае некорректной строки темы письма (типа HELP!!??) измените её, например, так: Re: Difficulties with sync PPP (was: HELP!!??). В таком случае у других людей, пытающихся отследить обсуждение, будет меньше проблем. В таких случаях хорошо сказать, что вы сделали и почему, но постарайтесь не грубить. Если вы чувствуете, что не можете ответить, не скатываясь на грубость, воздержитесь от ответа вообще. Если вы хотите ответить на сообщение лишь потому, что оно плохо оформлено, ответьте только автору, но не в список. Если хотите, то в ответ можете просто послать ему эту статью.
diff --git a/ru_RU.KOI8-R/articles/geom-class/Makefile b/ru_RU.KOI8-R/articles/geom-class/Makefile index 7ca13f2f3b..9b74ce0c2a 100644 --- a/ru_RU.KOI8-R/articles/geom-class/Makefile +++ b/ru_RU.KOI8-R/articles/geom-class/Makefile @@ -1,22 +1,22 @@ # # $FreeBSD$ # # Article: Writing a GEOM Class # -# Original revision: r25510 +# Original revision: r39631 # DOC?= article FORMATS?= html WITH_ARTICLE_TOC?= YES INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/geom-class/article.xml b/ru_RU.KOI8-R/articles/geom-class/article.xml index 254c53846d..0397b96ca4 100644 --- a/ru_RU.KOI8-R/articles/geom-class/article.xml +++ b/ru_RU.KOI8-R/articles/geom-class/article.xml @@ -1,813 +1,813 @@
Создание класса GEOM IvanVoras
ivoras@FreeBSD.org
&tm-attrib.freebsd; &tm-attrib.intel; &tm-attrib.general; $FreeBSD$ $FreeBSD$ Эта статья документирует некоторые начальные выкладки в разработке GEOM-классов, а также модулей ядра в общем. Предполагается, что читатель близко знаком с программированием на Си в контексте пространства пользовательских процессов (userland). Вступление Документация Документация по программированию для ядра скудная, это одна из немногих областей программирования, где почти нет хороших учебных пособий, и совет читай исходники! — сохраняет свою справедливость. Однако, существует несколько статей и книг разной актуальности, которые рекомендуются к изучению перед тем, как начать программировать: Руководство FreeBSD для разработчиков — часть Проекта Документации FreeBSD, ничего специфичного о программировании ядра в нем нет, зато есть немного общей полезной информации. Руководство по Архитектуре FreeBSD — также является частью Проекта Документации FreeBSD, содержит описания некоторых низкоуровневых средств и процедур. Уделите внимание разделу номер 13 — Написание драйверов устройств для FreeBSD. Несколько интересных статей об устройстве ядра можно найти на сайте FreeBSD Diary. Страницы из раздела номер 9 системного справочника, содержат важную документацию по функциям ядра. Страница справочника &man.geom.4;, а также слайды Пола-Хеннинга Кампа — общее представление о подсистеме GEOM. Страницы справочника &man.g.bio.9;, &man.g.event.9;, &man.g.data.9;, &man.g.geom.9;, &man.g.provider.9;, &man.g.consumer.9;, &man.g.access.9;, а также другие, связанные с вышеупомянутыми и раскрывающие специфический функционал подсистемы GEOM. Страница справочника &man.style.9; — документирует соглашения о стиле оформления кода, которые обязаны быть соблюдены если вы планируете передать ваш код в Subversion репозиторий FreeBSD. Подготовка Для того, чтоб заниматься разработками для ядра, желательно иметь два отдельных компьютера. Один из них предназначен для среды разработки и исходных кодов, а второй — для запуска тестов отлаживаемого кода. Второму компьютеру для работы достаточно иметь возможность выполнять начальную загрузку по сети и монтирование файловых систем по сети. В этой ситуации, если отлаживаемый код содержит ошибки и вызовет аварийную остановку системы, то это не повлечет порчу или утерю исходного кода . Второму компьютеру даже не потребуется иметь свой монитор, достаточно будет соединения асинхронных портов кабелем RS-232 или соединения при помощи KVM-устройства. Но так как далеко не у каждого есть два или более компьютеров под рукой, есть пара способов подготовить иную живую систему для разработки кода для ядра. Один из них — это разработка в VMWare или QEmu виртуальной машине (это лучшее из доступного, после, конечно-же, выделенного для тестов компьютера). Настройка системы для разработки Прежде всего необходимо иметь в ядре поддержку . Добавьте следующие строки в файл конфигурации ядра: options INVARIANT_SUPPORT options INVARIANTS Для большей информативности при отладке включите поддержку WITNESS, которая будет предупреждать вас в случае возникновения взаимоблокировок: options WITNESS_SUPPORT options WITNESS Также включите отладочные символы, если планируете выполнять отладку по дампам аварийных отказов makeoptions DEBUG=-g Установка отладочного ядра обычным способом (make installkernel) не даст привычного результата: файл ядра будет называться kernel.debug и будет находиться в /usr/obj/usr/src/sys/KERNELNAME/. Для удобства, отладочное ядро необходимо скопировать в /boot/kernel/. Также удобно иметь включенный отладчик ядра, так вы сможете исследовать паники сразу-же после их возникновения. Для включения отладчика добавьте следующие строки в файл конфигурации ядра: options KDB options DDB options KDB_TRACE Для автоматического запуска отладчика ядра после возникновения паники может понадобиться установить переменную sysctl: debug.debugger_on_panic=1 Паники системы будут происходить, поэтому уделите внимание кэшу файловой системы. Обычно, при включенном механизме softupdates, последняя версия файла может быть утеряна если паника произошла раньше сбрасывания кэша на устройство хранения. Выключение механизма softupdates (посредством монтирования файловой системы с опцией sync) значительно сказывается на производительности и, опять-же, не гарантирует целостности данных. Как компромисс, можно сократить задержки сбрасывания кэша механизма softupdates. Есть три переменных sysctl, значения которых необходимо изменить (лучше всего — прописав их в /etc/sysctl.conf): kern.filedelay=5 kern.dirdelay=4 kern.metadelay=3 Значения этих переменных — секунды. Для отладки паник ядра необходимы дампы памяти. Так как паника ядра может сломать файловую систему, дамп сначала сохраняется в сырой раздел. Обычно, это своп-раздел. Поэтому, размер своп-раздела должен быть не меньше размера ОЗУ компьютера. При последующей загрузке дамп копируется в обычный файл. Это происходит сразу-же после проверки и монтирования файловых систем, но перед активированием раздела свопа. Такое поведение контролируется следующими переменными /etc/rc.conf: dumpdev="/dev/ad0s4b" dumpdir="/usr/core" Переменная dumpdev указывает на раздел подкачки, а dumpdir сообщает системе куда перемещать дамп ядра при следующей загрузке. Сохранение дампа ядра — процесс медленный, и, если у вашего компьютера много оперативной памяти (>256M) и если паники случаются часто, то ожидание сохранения дампов может начать раздражать (вспомним, что над дампом происходит две операции: сохранение в своп-файл и перемещение на файловую систему). В таком случае может оказаться удобным ограничивание объема используемой системой памяти путем установки переменной в /boot/loader.conf: hw.physmem="256M" Если паники случаются часто и размер файловых систем большой (или же вы просто не доверяете softupdates и фоновой проверке файловых систем), рекомендуется отключить фоновую проверку файловых систем посредством установки переменной в /etc/rc.conf: background_fsck="NO" В этом случае файловые системы будут проверяться только при необходимости. Также заметьте, что в случае использования фоновой проверки, новая паника может случиться в то время, когда проверяются диски. Другими словами, наиболее безопасный способ — не иметь много локальных файловых систем, а использовать второй компьютер в качестве NFS-сервера. Начало проекта Для написания нового класса GEOM необходимо создать поддиректорию в любой доступной пользователю директории. Совсем не обязательно, чтоб ваш модуль изначально размещался в /usr/src. Makefile Правилом хорошего тона является создание Makefile-ов для каждого нетривиального проекта, примером которого конечно-же является создание модулей ядра. Создание Makefile — дело не сложное благодаря исчерпывающему набору вспомогательных средств, предоставляемых системой. В вкратце, вот как должен выглядеть Makefile для модуля ядра: SRCS=g_journal.c KMOD=geom_journal .include <bsd.kmod.mk> Этот Makefile (с измененными именами файлов) подойдет к любому модулю ядра. Класс GEOM может размещаться в одном единственном модуле ядра. Если для сборки вашего модуля требуется больше, чем один файл, то перечислите их имена, разделенные пробельными символами, в переменной SRCS. Программирование в ядре FreeBSD Выделение памяти Прочитайте &man.malloc.9; — выделение памяти лишь немного отличается от своего эквивалента, используемого в пространстве пользовательских процессов (userland). Наиболее приметно то, что malloc() и free() принимают дополнительные параметры, которые описаны в странице справочника. Тип malloc_type необходимо объявить в секции деклараций файла с исходным кодом, например: static MALLOC_DEFINE(M_GJOURNAL, "gjournal data", "GEOM_JOURNAL Data"); Для того, чтобы можно было использовать этот макрос, необходимо включить следующие заголовочные файлы: sys/param.h, sys/kernel.h и sys/malloc.h Существует еще один механизм выделения памяти — UMA (Universal Memory Allocator), описанный в &man.uma.9;. Это специфический метод, преимущественно предназначенный для быстрого выделения памяти под списки, состоящие из элементов одинакового размера (например, динамические массивы структур). Очереди и списки Ознакомьтесь с &man.queue.3; Во множестве случаев вам необходимо будет организовывать и управлять такой структурой данных, как списки. К счастью, эта структура данных реализована несколькими способами в виде макросов на Си, а также включена в систему. Наиболее гибкий и часто употребляемый тип списка — TAILQ. Этот тип списка также один из наиболее требовательных к памяти (его элементы - с двойными связями), а также — наиболее медленный (однако счет идет на несколько инструкций ЦПУ, поэтому последнее утверждение не следует воспринимать в всерьез). Если важна скорость получения данных, то возьмите на вооружение &man.tree.3; и &man.hashinit.9;. BIOs Структура bio используется для всех операций ввода/вывода, касающихся GEOM. Она содержит информацию о том, какое устройство ('поставщик geom') должно ответить на запрос, тип запроса, смещение, длину и указатель на буфер, а также набор определенных пользователем флагов и полей . Важным моментом является то, что bio обрабатываются асинхронно. Это значит, что во многих частях кода нет аналога к &man.read.2; и &man.write.2; функциям из пространства пользовательских процессов, которые не возвращают управление пока не выполнится системный вызов. Скорее, по завершении обработки запроса (или в случае ошибки при обработке) как извещение вызывается определенная пользователем функция. Асинхронная модель программирования в чем-то сложней, нежели чаще используемая императивная модель, используемая в пространстве пользовательских процессов; в любом случае, привыкание займет некоторое время. В некоторых случаях могут быть использованы вспомогательные функции g_write_data() и g_read_data(), но далеко не всегда. В частности, эти функции не могут использоваться когда захвачен мьютекс; например, мьютекс GEOM-топологии или внутренний мьютекс, удерживаемый в ходе выполнения .start() или .stop(). Программирование в системе GEOM Ggate Если максимальная производительность не требуется, то более простой способ совершать преобразования данных — это выполнять их в пространстве пользовательских процессов посредством ggate (GEOM gate). К недостаткам следует отнести невозможность простого переноса кода в ядро. Класс GEOM Класс GEOM выполняет преобразования данных. Эти преобразования могут быть скомпонованы друг с другом в виде дерева. Экземпляр класса GEOM называют geom. В каждом классе GEOM есть несколько методов класса, которые вызываются когда экземпляра класса нет в наличии (или же они не привязаны к конкретному экземпляру класса). .init вызывается тогда, когда системе GEOM становится известно о классе GEOM (например, когда загружается модуль ядра). .fini будет вызван в случае отказа GEOM системы от класса (например, при выгрузке модуля). .taste вызывается, когда в системе появляется новый класс или поставщик geom (provider). Если соответствие найдено, то эта функция обычно создает и запускает экземпляр geom. .destroy_geom вызывается при необходимости разрушить экземпляр geom. .ctlconf будет вызван, когда пользователь запросит изменение конфигурации существующего экземпляра geom Также определены функции событий GEOM, которые копируются в экземпляр geom. Поле .geom в структуре g_class — это список (LIST) экземпляров geom, реализованных из класса. Эти функции вызываются из g_event потока ядра. Softc softc — это устаревший термин для приватных данных драйвера (driver private data). Название вероятней всего происходит от устаревшего термина software control block. В системе GEOM softc это структура (точнее: указатель на структуру) которая может быть присоединена к экземпляру geom и может содержать приватные данные экземпляра. У большинства классов GEOM есть следующие члены: struct g_provider *provider : поставщик geom предоставляемый данным экземпляром geom uint16_t n_disks : Количество потребителей geom (consumer), обслуживаемых данным экземпляром geom struct g_consumer **disks : Массив struct g_consumer*. (Невозможно обойтись одинарным указателем, потому что система GEOM создает для нас структуры struct g_consumer*) Структура softc содержит состояние экземпляра geom. У каждого экземпляра есть свой softc. Метаданные Формат метаданных в той или иной мере зависит от конкретного класса, но обязан начинаться с: 16-байтного буфера для подписи — строки с завершающим нулем (обычно это имя класса) uint32 идентификатора версии Подразумевается, что классы geom знают как обращаться с метаданными с идентификаторами версий ниже, чем их собственные. Метаданные размещаются в последнем секторе поставщика geom (поэтому обязаны целиком умещаться в нем). (Все это зависит от реализации, но весь существующий код работает подобно описанному и поддерживается библиотеками.) Маркирование/создание экземпляра geom Последовательность событий следующая: пользователь запускает служебную программу &man.geom.8; программа решает каким классом geom ей придется управлять и ищет библиотеку geom_CLASSNAME.so (которая обычно находится в /lib/geom). она открывает библиотеку при помощи &man.dlopen.3;, извлекает вспомогательные функции и определения параметров командной строки. Вот так происходит создание/маркирование нового экземпляра geom: &man.geom.8; ищет команду в аргументах командной строки (обычно это ) и вызывает вспомогательную функцию. Вспомогательная функция проверяет параметры и собирает метаданные, которые записываются во все вовлеченные поставщики geom. Это повреждает (spoil) существующие экземпляры geom (если они были) и порождает новый виток тестирования поставщиков geom. Целевой класс geom опознает метаданные и активирует экземпляр geom. (Приведенная выше последовательность событий зависит от конкретной реализации, но весь существующий код работает подобно описанному и поддерживается библиотеками.) Структура команд geom Вспомогательная библиотека geom_CLASSNAME.so экспортирует структуру class_commands, которая является массивом элементов struct g_command. Эти команды одинакового формата и выглядят следующим образом: команда [-опции] имя_geom [другие] Общими командами являются: label — записать метаданные в устройства, чтобы они могли быть опознаны в процессе тестирования и использованы в соответствующих экземплярах geom destroy — разрушить метаданные, за которым последует разрушение экземпляров geom Общие опции: -v : детальный вывод -f : принудить Некоторые операции, к примеру маркирование метаданными и разрушение метаданных могут быть выполнены из пространства пользовательских процессов. Для этого, структура g_command содержит поле gc_func, которое может быть установлено на функцию (в том-же .so), которая будет вызвана для обработки команды. В случае, когда gc_func равно NULL, команда будет передана модулю ядра: функции .ctlreq класса GEOM. Экземпляры geom У экземпляров классов GEOM есть внутренние данные, которые хранятся в структурах softc, а также есть некоторые функции, посредством которых они реагируют на внешние события. Функции событий: .access : просчитывает права доступа (чтение/запись/исключительный доступ) .dumpconf : возвращает информацию о экземпляре geom; формат XML .orphan : вызывается, когда отсоединяется любой из низлежащих поставщиков geom .spoiled : вызывается, когда производится запись в низлежащий поставщик geom .start : обрабатывает ввод/вывод Эти функции вызываются из ядерного потока g_down и в этом контексте не может быть блокировок (поищите определение блокировка в других источниках), что немного ограничивает свободу действий, но способствует быстроте обработки. Из вышеупомянутых, наиболее важной и выполняющей полезную работу функцией является .start(), которая вызывается всякий раз, когда поставщику geom, управляемому экземпляром класса, приходит запрос BIO. Потоки выполнения системы geom Системой GEOM в ядре ОС создаются и используются три потока выполнения (kernel threads): g_down : Обрабатывает запросы, приходящие от высокоуровневых сущностей (таких, как запросы из пространства пользовательских процессов) на пути к физическим устройствам g_up : Обрабатывает ответы от драйверов устройств на запросы, выполненные высокоуровневыми сущностями g_event : Отрабатывает в остальных случаях, как-то создание экземпляра geom, просчитывание прав доступа, события повреждения и т.п. Когда пользовательский процесс запрашивает прочитать данные X по смещению Y файла, происходит следующее: Файловая система преобразует запрос в экземпляр структуры bio и передает его системе GEOM. Файловая система знает, что экземпляр geom должен обработать запрос, так как файловые системы размещаются непосредственно над экземпляром geom. Запрос завершается вызовом функции .start() в потоке g_down и достигает верхнего экземпляра geom. Верхний экземпляр geom (например, это секционировщик разделов (partition slicer)) определяет, что запрос должен быть переадресован нижестоящему экземпляру geom (к примеру, драйверу диска). Вышестоящий экземпляр geom создает копию запроса bio (запросы bio ВСЕГДА копируются при передаче между экземплярами geom при помощи g_clone_bio()!), изменяет поля смещения и целевого поставщика geom и запускает на обработку копию при помощи функции g_io_request() Драйвер диска также получает запрос bio, как вызов функции .start() в потоке g_down. Драйвер обращается к контроллеру диска, получает блок данных и вызывает функцию g_io_deliver() используя копию запроса bio Теперь, извещение о завершении bio всплывает в потоке g_up. Сначала в потоке g_up вызывается функция .done() секционировщика разделов, последний использует полученную информацию, разрушает клонированный экземпляр структуры bio посредством g_destroy_bio() и вызывает g_io_deliver() используя первоначальный запрос Файловая система получает данные и передает их пользовательскому процессу За информацией о том, как данные передаются в структуре bio между экземплярами geom, смотрите &man.g.bio.9; (обратите внимание на использование полей bio_parent и bio_children). Важный момент в том, что НЕЛЬЗЯ ДОПУСКАТЬ БЛОКИРОВОК В ПОТОКАХ G_UP И G_DOWN. Вот неполный перечень того, что нельзя делать в этих потоках: Вызывать функции msleep() или tsleep(). Использовать функции g_write_data() и g_read_data(), так как они блокируются в момент обмена данными с потребителями geom. Ожидать ввод/вывод. Вызывать &man.malloc.9; и uma_zalloc() с установленным флагом M_WAITOK. Использовать &man.sx.9; Это ограничение на код GEOM призвано избежать от засорения пути запроса ввода/вывода, так как блокировки обычно не имеют четких временных границ, и нет гарантий на занимаемое время (также на то есть и другие технические причины). Это также значит, что в вышеупомянутых потоках сколь-нибудь сложные операции выполнить нельзя, например: любое сложное преобразование требует выделения памяти. К счастью решение есть: создание дополнительных ядерных потоков. Ядерные потоки выполнения, предназначенные для использования в коде geom Ядерные потоки выполнения создаются функцией &man.kthread.create.9;, в своем поведении они схожи с потоками, созданными в пространстве пользовательских процессов, но есть одно отличие: они не могут известить вызвавший их поток о своем завершении; по завершению — необходимо вызывать &man.kthread.exit.9; В коде GEOM обычное назначение этих потоков — разгрузить поток g_down (функцию .start() ) от обработки запросов. Эти потоки подобны обработчикам событий (event handlers): у них есть очередь событий (которая наполняется событиями от разных функций из разных потоков; очередь необходимо защищать мьютексом), события из очереди выбираются одно за другим и обрабатываются в большом блоке switch(). Основное преимущество использования отдельного потока, который обрабатывает запросы ввода/вывода, то, что он может блокироваться по мере необходимости. Это, несомненно, привлекательно, но должно быть хорошо обдумано. Блокирование — хорошо и удобно, но может существенно снизить производительность преобразований данных в системе GEOM. Особо требовательные к производительности классы могут делать всю работу в функции .start(), уделяя особое внимание ошибкам при работе с памятью. Еще одно преимущество потока обработчика событий это сериализация всех запросов и ответов, приходящих с разных потоков geom в один поток. Это также удобно, но может быть медленным. В большинстве случаев, обработка запросов функцией .done() может быть оставлена потоку g_up. У мьютексов в ядре FreeBSD (&man.mutex.9;) есть одно различие с их аналогами из пространства пользовательских процессов — во время удержания мьютекса в коде не должно быть блокировки. Если в коде необходимо блокирование, то лучше использовать &man.sx.9;. С другой стороны, если вся ваша работа выполняется в одном потоке, вы можете обойтись вообще без мьютексов.
diff --git a/ru_RU.KOI8-R/articles/gjournal-desktop/Makefile b/ru_RU.KOI8-R/articles/gjournal-desktop/Makefile index e81a228567..8432b7dbfd 100644 --- a/ru_RU.KOI8-R/articles/gjournal-desktop/Makefile +++ b/ru_RU.KOI8-R/articles/gjournal-desktop/Makefile @@ -1,22 +1,22 @@ # # $FreeBSD$ # # Article: Implementing UFS journaling on a desktop PC # -# Original revision: r31928 +# Original revision: r39631 # DOC?= article FORMATS?= html INSTALL_COMPRESSED?=gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml IMAGES_EN= disklabel1.png IMAGES_EN+= disklabel2.png URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/gjournal-desktop/article.xml b/ru_RU.KOI8-R/articles/gjournal-desktop/article.xml index bca2a4d22d..4bb6001630 100644 --- a/ru_RU.KOI8-R/articles/gjournal-desktop/article.xml +++ b/ru_RU.KOI8-R/articles/gjournal-desktop/article.xml @@ -1,718 +1,718 @@
Настройка журналирования UFS для настольного компьютера. ManolisKiagias
manolis@FreeBSD.org
 2008 Manolis Kiagias $FreeBSD$ $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.general; Журналируемая файловая система использует лог для записи всех транзакций, происходящих в файловой системе, который также сохраняет ее целостность в случае краха системы или пропадания питания. Несмотря на то, что всё еще возможна потеря несохранённых изменений файлов, журналирование почти полностью исключает возможность повреждения структуры файловой системы, вызванное непредвиденным остановом работы. Журналирование также сокращает до минимума время, необходимое для проверки файловой системы после отказа. Несмотря на то, что в используемой &os; файловой системе UFS нет поддержки журналирования, новый класс системы GEOM в &os; 7.X может быть использован для для ведения независимого от файловой системы журналирования. Эта статья объясняет, как реализовать журналирование UFS для типичного настольного компьютера. Вступление Серверное оборудование обычно хорошо защищено от потери питания. Настольный компьютер часто подвержен неожиданным пропаданиям питания, случайным нажатиям кнопки Reset и другим происшествиям (часто связанным с неосторожностью пользователей), которые могут привести к непредвиденным выключениям. Механизм Soft Updates, как правило, достаточно эффективно защищает файловую систему в таких случаях, однако в последствии требуется длительная фоновая проверка. В очень редких случаях повреждения файловой системы достигают того уровня, при котором становится необходимым вмешательство пользователя и данные могут быть утерянными. Новая возможность журналирования, предоставленная системой GEOM, может существенно выручить в подобных случаях, исключая время, необходимое для проверки файловых систем и удостовериваясь, что файловая система быстро восстановлена в целостное состояние. Эта статья описывает порядок действий, необходимых для конфигурирования журналирования UFS на типичном настольном компьютере, в котором один жесткий диск используется для размещения как операционной системы, так и данных. В статье подразумевается установка &os; "с нуля". Шаги достаточно просты и не требуют чрезмерно сложных манипуляций с командной строкой После прочтения данной статьи вы будете знать: Как зарезервировать место для журнала во время новой установки &os;. Как загрузить модуль geom_journal (или включить поддержку журналирования в специализированном ядре системы). Как преобразовать существующую файловую систему, в систему, использующую журналирование, и какие опции монтирования использовать в /etc/fstab. Как реализовать журналирование на новых (пустых) разделах. Как диагностировать неполадки, связанные с журналированием. Перед прочтением этой статьи вам необходимо: Понимать базовые концепции таких операционных систем, как &unix; и &os;. Быть знакомым с процедурой установки &os;, а также с программой sysinstall. Процедура, описанная здесь, подразумевает подготовку к новой установке, в которой на дисках еще нет пользовательских данных. Так как эту процедуру можно модифицировать и расширить на системы, которые уже используются, вам настоятельно рекомендуется сделать резервную копию всех ценных данных. Путаница в низкоуровневых операциях с дисками и разделами может привести к фатальным ошибкам и потере данных. Реализация журналирования в &os; Журналирование, предоставляемое системой GEOM в &os; 7.X, не является особенностью файловой системы (в отличие от, например, файловой системы ext3 в &linux;), оно функционирует на блочном уровне. А это значит, что оно может быть применено к разным типам файловых систем, однако для &os; 7.0-RELEASE журналирование может быть применено только для UFS2. Возможность журналирования обеспечивается загрузкой модуля geom_journal.ko в ядро (или сборкой собственного ядра с активированием соответствующих опций) и использованием команды gjournal для конфигурирования файловой системы. В общем, вы предпочтете журналировать файловые системы большого размера, к примеру - /usr. Однако, вам придется зарезервировать некоторое количество свободного места (см. следующий раздел). Когда файловая система журналируется, некоторая часть дискового пространства требуется для хранения самого журнала. Дисковое пространство, содержащее данные, называется поставщиком данных (data provider), а часть пространства, содержащая журнал, называется поставщиком журнала (journal provider). Поставщики данных и журнала должны быть на разных разделах, если журналирование достраивается к содержащему данные разделу. А если журналирование включается для нового раздела, у вас есть возможность использовать один поставщик для данных и журнала. В любом из двух вышеупомянутых случаев команда gjournal задействует поставщики и создаст конечную журналируемую файловую систему. Например: Вы намереваетесь журналировать файловую систему /usr, размещенную на /dev/ad0s1f, файловая система уже содержит данные. Вы зарезервировали часть дискового пространства на разделе /dev/ad0s1g. Используя команду gjournal, создаем новый файл устройства /dev/ad0s1f.journal, для которого /dev/ad0s1f является поставщиком данных, а /dev/ad0s1g — поставщик журнала. Это новое устройство необходимо использовать во всех последующих операциях. Размер дискового пространства, отводимого под поставщик журнала, зависит от нагруженности файловой системы, а не от размера самого поставщика данных. Например, для типичного настольного компьютера достаточно отвести 1 Гб под поставщик журнала для файловой системы /usr, в то время как компьютеру, имеющему интенсивный дисковый ввод/вывод (например, редактирование видео) может потребоваться больше. Если свободное место на поставщике журнала заканчивается раньше, чем происходит сброс журнала на диск, — вы получите панику ядра. Очень маловероятно то, что размеры журнала, предложенные здесь, станут причиной проблем с обычным настольным компьютером (на котором вы просматриваете веб-страницы, обрабатываете текст или проигрываете мультимедийные файлы). Если работа вашего компьютера подразумевает интенсивную дисковую активность, то для обеспечения стабильности следует придерживаться следующего правила: размер ОЗУ должен уместиться в 30% размера, отведенного под журнал. Например, если в вашем компьютере установлен 1 Гб ОЗУ, создайте под поставщик журнала раздел размером около 3.3 Гб. (Умножьте размер ОЗУ в 3.3 раза, чтоб получить размер журнала). Для получения дополнительной информации о журналировании, пожалуйста, прочитайте страницу справочника, посвященную &man.gjournal.8;. Действия, необходимые во время установки &os; Выделение места под журналирование Типичный настольный компьютер обычно имеет один жесткий диск, на котором хранится как операционная система, так и пользовательские данные. Вероятно, что схема разбития винчестера (по умолчанию), выбранная в меню sysinstall, является более или менее подходящей: настольному компьютеру не требуется большой раздел /var, в то время, как для раздела /usr выделяется значительный объем дискового пространства, ввиду того, что пользовательские данные и множество пэкэджей хранятся именно в поддиректориях /usr. Разбиение по умолчанию (получаемое при нажатии A в редакторе разделов &os;, называемом Disklabel) не оставляет свободного места. Каждый подлежащий журналированию раздел требует отдельного раздела для журнала. Ввиду того, что раздел /usr — наибольший, есть смысл немного уменьшить его размер, чтобы получить пространство, необходимое для журнала. В нашем примере используется жесткий диск размером 80 Гб. Следующий скриншот показывает результаты разбиения по умолчанию, выполненного при помощи Disklabel в процессе установки операционной системы: Если это разбиение более или менее вас устраивает, то его легко модифицировать для журналирования. Используйте клавиши со стрелками для того, чтобы выделить раздел, отведенный под /usr, потом нажмите D чтобы удалить его. Теперь переведите подсвечивание к имени диска, находящемуся вверху экрана, и нажмите C — создайте новый раздел /usr. Новый раздел должен быть меньше на 1 Гб (если вы собираетесь журналировать только /usr) или на 2 Гб (если журналированию подлежат как /usr, так и /var). Во всплывающем окне выберите "создать файловую систему" и укажите /usr точкой монтирования. Следует ли журналировать /var раздел? Обычно есть смысл журналировать большие разделы. Вы можете решить не журналировать /var, однако журналирование на обычном настольном компьютере не причинит вреда. Если файловая система не нагружена (что типично для настольной системы), то можно выделить меньше дискового пространства под журнал. В этом примере подразумевается журналирование двух файловых систем: /usr и /var. Естественно, вы можете подкорректировать процедуру под свои задачи. Чтобы не усложнять описываемую методику, для создания разделов, необходимых для размещения журналов, мы будем использовать утилиту sysinstall. Однако, во время установки утилита sysinstall требует указания точек монтирования для каждого созданного вами раздела. Но разделы, содержащие журналы, вам никогда и никуда монтировать не придется. Чтобы избежать вопросов о точках монтирования, мы создадим разделы под журналы и установим их тип в swap. Раздел, предназначенный для свопа, никогда и никуда не монтируется, плюс к тому, утилита sysinstall позволяет создавать столько разделов под своп, сколько необходимо. После первой перезагрузки необходимо подредактировать файл /etc/fstab, удалив в нём лишние записи о своп-разделах. Для создания своп-раздела, используя клавиши со стрелками, перемещайте подсвечивание к верхней части экрана в утилите Disklabel так, чтобы стало подсвеченным имя диска. Потом, нажмите N, введите необходимый размер раздела (1024M), а после — выберите во всплывшем окне swap space. Повторите эти шаги для всех оставшихся журналов. В этом примере мы создаем два раздела, на которых будут размещаться журналы для /usr и /var. Конечный результат показан на следующем скриншоте: По завершении создания разделов мы рекомендуем вам записать на бумагу названия разделов и их точек монтирования: с этой информацией вы будете сверяться во время конфигурирования. Это также поможет уменьшить количество ошибок, приводящих к повреждению установки. Следующая табличка отображает наши заметки, сделанные для данного примера: Разделы и журналы Раздел Точка монтирования Журнал ad0s1d /var ad0s1h ad0s1f /usr ad0s1g
Дальше продолжайте обычную установку. Однако, мы рекомендуем вам отложить инсталляцию приложений сторонних разработчиков (пакетов) до полной настройки журналирования. Первая загрузка Ваша система загрузится нормально, однако вам необходимо будет подредактировать /etc/fstab и удалить те лишние своп-разделы, которые вы создавали под журналы. Как правило, в названии файла устройства, созданного автоматически утилитой sysinstall, присутствует суффикс b (в нашем примере это ad0s1b). Удалите другие записи о своп-разделах и перезагрузите компьютер, после чего &os; перестанет их использовать. После второй перезагрузки, компьютер будет готов к конфигурированию журналирования. Настройка журналирования Работа с командой <command>gjournal</command> Подготовив необходимые разделы, перейдем к конфигурированию журналирования. Нам будет необходимо загрузиться в однопользовательском режиме, для этого залогинимся пользователем root и напечатаем: &prompt.root; shutdown now Нажмите Enter для получения приглашения командного интерпретатора. Нам необходимо будет размонтировать разделы, которые подлежат журналированию, в нашем примере это /usr и /var. &prompt.root; umount /usr /var Загрузите модуль ядра, необходимый для журналирования: &prompt.root; gjournal load На данном этапе сверьтесь со своими записями и определите, какие разделы будут использоваться под какой журнал. В нашем примере /usr располагается на ad0s1f, а его журнал будет располагаться на ad0s1g, и, по аналогии, для /var: файловая система располагается на ad0s1d, а ее журнал — на ad0s1h. Наберите следующие команды: &prompt.root; gjournal label ad0s1f ad0s1g GEOM_JOURNAL: Journal 2948326772: ad0s1f contains data. GEOM_JOURNAL: Journal 2948326772: ad0s1g contains journal. &prompt.root; gjournal label ad0s1d ad0s1h GEOM_JOURNAL: Journal 3193218002: ad0s1d contains data. GEOM_JOURNAL: Journal 3193218002: ad0s1h contains journal. Если последний сектор любого из двух разделов (поставщиков данных) используется, команда gjournal возвратит ошибку. Вам необходимо будет использовать флаг для принудительной перезаписи, например: &prompt.root; gjournal label -f ad0s1d ad0s1h Так как это — новая установка, очень маловероятен факт, что что-нибудь будет действительно переписано. На данном этапе созданы два устройства: ad0s1d.journal и ad0s1f.journal. Они представляют /var и /usr соответственно. Перед монтированием, нам необходимо установить флаг журналирования и снять флаг механизма Soft Updates: &prompt.root; tunefs -J enable -n disable ad0s1d.journal tunefs: gjournal set tunefs: soft updates cleared &prompt.root; tunefs -J enable -n disable ad0s1f.journal tunefs: gjournal set tunefs: soft updates cleared Теперь, смонтируйте новые устройства в соответствующие места файловой системы (обратите внимание на то, что мы можем использовать опцию монтирования ): &prompt.root; mount -o async /dev/ad0s1d.journal /var &prompt.root; mount -o async /dev/ad0s1f.journal /usr Откройте /etc/fstab и исправьте записи для следующих файловых систем: /usr и /var: /dev/ad0s1f.journal /usr ufs rw,async 2 2 /dev/ad0s1d.journal /var ufs rw,async 2 2 Убедитесь, что упомянутые выше записи правильные, иначе старт системы будет проблематичным после перезагрузки! И напоследок, подредактируйте /boot/loader.conf: добавьте следующую строку и модуль &man.gjournal.8; будет загружаться автоматически при старте системы: geom_journal_load="YES" Поздравляем! Журналирование успешно сконфигурировано. Вам необходимо лишь набрать exit для возвращения в многопользовательский режим или перезагрузить систему, чтобы полностью проверить вашу конфигурацию (рекомендуется). Во время загрузки вы увидите сообщения, подобные следующим: ad0: 76293MB XEC XE800JD-00HBC0 08.02D08 at ata0-master SATA150 GEOM_JOURNAL: Journal 2948326772: ad0s1g contains journal. GEOM_JOURNAL: Journal 3193218002: ad0s1h contains journal. GEOM_JOURNAL: Journal 3193218002: ad0s1d contains data. GEOM_JOURNAL: Journal ad0s1d clean. GEOM_JOURNAL: Journal 2948326772: ad0s1f contains data. GEOM_JOURNAL: Journal ad0s1f clean. После непредвиденного останова работы системы сообщения будут немного отличаться, например: GEOM_JOURNAL: Journal ad0s1d consistent. Это обычно значит, что &man.gjournal.8; воспользовался информацией в журнале для возвращения файловой системы к целостному состоянию. Журналирование новых разделов Процедура, описанная выше, необходима для подключения журналирования разделов, содержащих данные. Журналирование пустых разделов немного проще, ввиду того, что поставщик данных и поставщик журнала могут быть размещены на одном и том же разделе. Например, предположим, что был установлен новый жесткий диск и был создан новый раздел /dev/ad1s1d. Создание журнала не сложнее набора: &prompt.root; gjournal label ad1s1d Размер журнала — 1 Гб по умолчанию. Однако, вы можете изменить это значение используя ключ . Значение можно задавать в байтах, в килобайтах, мегабайтах или гигабайтах (используя суффикс K, M или G). Имейте ввиду, что команда gjournal не позволит вам создать журнал недопустимо малого размера. К примеру, чтобы создать журнал размером в 2Гб, можно использовать следующую команду: &prompt.root; gjournal label -s 2G ad1s1d Далее, вы можете создать файловую систему на новом разделе, а также разрешить журналирование ключом : &prompt.root; newfs -J /dev/ad1s1d.journal Встраивание журналирования в специализированное ядро Если вы не желаете загружать geom_journal как модуль, то можно встроить его функции прямо в ваше специализированное ядро. Редактируя конфигурационный файл ядра, убедитесь, что в нем находятся следующие две строки: options UFS_GJOURNAL # Прим.: Это включено в GENERIC options GEOM_JOURNAL # А эту строку необходимо добавить Соберите и установите новое ядро следуя указаниям Руководства &os; . И не забудьте удалить соответствующую строку загрузки модуля (load) из /boot/loader.conf (если на предыдущем этапе она была туда внесена). Устранение неполадок с журналированием Этот раздел содержит часто задаваемые вопросы касательно неполадок, связанных с журналированием. Я получаю паники ядра во время высокой дисковой активности. Как это связано с журналированием? Вероятно, что журнал заполняется раньше, чем происходит сброс его на диск. Помните, размер журнала зависит от загруженности диска, а не от размера поставщика данных. Если загрузка диска высокая, вам потребуется раздел большего размера для журнала. См. замечания в разделе Реализация журналирования Я допустил некоторые ошибки во время конфигурирования, теперь система не загружается. Можно это как-нибудь исправить? Вы либо забыли внести запись (опечатались) в /boot/loader.conf, либо есть ошибки в файле /etc/fstab. Это легко исправить. Нажмите Enter, чтобы получить приглашение командного интерпретатора в однопользовательском режиме. Потом, проверьте возможные варианты: &prompt.root; cat /boot/loader.conf Если отсутствует запись geom_journal_load, или она содержит ошибки, журналируемые устройства не создадутся. Загрузите модуль вручную, примонтируйте все разделы и переходите в многопользовательский режим (продолжайте загрузку). &prompt.root; gjournal load GEOM_JOURNAL: Journal 2948326772: ad0s1g contains journal. GEOM_JOURNAL: Journal 3193218002: ad0s1h contains journal. GEOM_JOURNAL: Journal 3193218002: ad0s1d contains data. GEOM_JOURNAL: Journal ad0s1d clean. GEOM_JOURNAL: Journal 2948326772: ad0s1f contains data. GEOM_JOURNAL: Journal ad0s1f clean. &prompt.root; mount -a &prompt.root; exit (boot continues) Если же запись о geom_journal_load верна, то проверьте /etc/fstab. Вероятней всего, что вы обнаружите опечатку или отсутствие необходимой записи. В этом случае смонтируйте вручную оставшиеся разделы и продолжите загрузку в многопользовательский режим. Возможно ли отказаться от журналирования и вернуться к моей привычной файловой системе с механизмом Soft Updates? Несомненно. Используйте приведенную ниже последовательность действий, которая обращает изменения. Разделы, созданные для поставщиков журналов, могут позже быть использованы для других целей. Залогиньтесь root и переведите систему в однопользовательский режим: &prompt.root; shutdown now Размонтируйте журналируемые разделы: &prompt.root; umount /usr /var Синхронизируйте журналы: &prompt.root; gjournal sync Остановите поставщиков журналов: &prompt.root; gjournal stop ad0s1d.journal &prompt.root; gjournal stop ad0s1f.journal Удалите метаданные журналирования со всех задействованных устройств: &prompt.root; gjournal clear ad0s1d &prompt.root; gjournal clear ad0s1f &prompt.root; gjournal clear ad0s1g &prompt.root; gjournal clear ad0s1h Снимите флаг журналирования и установите флаг механизма Soft Updates: &prompt.root; tunefs -J disable -n enable ad0s1d tunefs: gjournal cleared tunefs: soft updates set &prompt.root; tunefs -J disable -n enable ad0s1f tunefs: gjournal cleared tunefs: soft updates set Смонтируйте вручную старые (первоначальные) устройства: &prompt.root; mount -o rw /dev/ad0s1d /var &prompt.root; mount -o rw /dev/ad0s1f /usr Откройте файл /etc/fstab и приведите его к изначальному виду: /dev/ad0s1f /usr ufs rw 2 2 /dev/ad0s1d /var ufs rw 2 2 И напоследок, удалите строку, загружающую модуль geom_journal, из файла /boot/loader.conf и перезагрузите операционную систему. Для дальнейшего ознакомления Журналирование — относительно новая функциональная возможность &os;, и как такова, она еще недостаточно документирована. Однако, вы можете сочти полезными следующие источники: Новый раздел Руководства FreeBSD, посвященный журналированию. Этот пост в списке рассылки &a.current.name;, написанный &a.pjd.email; — автором &man.gjournal.8;. Этот пост от &a.ivoras.email; в списке рассылки &a.questions.name;. Страницы справочника &man.gjournal.8; и &man.geom.8;.
diff --git a/ru_RU.KOI8-R/articles/hubs/Makefile b/ru_RU.KOI8-R/articles/hubs/Makefile index cbc11679bb..9fa1690d32 100644 --- a/ru_RU.KOI8-R/articles/hubs/Makefile +++ b/ru_RU.KOI8-R/articles/hubs/Makefile @@ -1,22 +1,22 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/hubs/Makefile,v 1.3 2004/04/12 07:55:51 marck Exp $ # -# Original revision: r20561 +# Original revision: r39631 # # Article: Mirroring FreeBSD DOC?= article FORMATS?= html WITH_ARTICLE_TOC?= YES INSTALL_COMPRESSED?=gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/hubs/article.xml b/ru_RU.KOI8-R/articles/hubs/article.xml index 31370cf514..f57a88ccce 100644 --- a/ru_RU.KOI8-R/articles/hubs/article.xml +++ b/ru_RU.KOI8-R/articles/hubs/article.xml @@ -1,1145 +1,1145 @@
Поддержка зеркал FreeBSD JunKuriyama
kuriyama@FreeBSD.org
 ValentinoVaschetto
logo@FreeBSD.org
 DanielLang
dl@leo.org
 KenSmith
kensmith@FreeBSD.org
 ДмитрийМорозовскийПеревод на русский язык: &tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.general; $FreeBSD$ $FreeBSD$ Рабочий вариант статьи, описывающей процесс создания и поддержки зеркала FreeBSD и адресованной администраторам зеркал. На текущий момент заявки на подключение новых зеркал не принимаются. Контактная информация Координаторы системы зеркал доступны по электронной почте по адресу mirror-admin@FreeBSD.org. Помимо этого, существует &a.hubs;. Требования к зеркалам FreeBSD Дисковое пространство Одним из наиболее важных требований является дисковое пространство. В зависимости от набора релизов, архитектур и степени полноты зеркала вам может потребоваться огромный объем диска. Не лишним будет помнить, что официальное зеркало, скорее всего, должно быть полным. Репозиторий CVS и веб-страницы всегда должны зеркалироваться полностью. Кроме того, учтите, что приводимые оценки объема относятся к состоянию на момент последнего редактирования данной статьи (&rel2.current;-RELEASE/&rel.current;-RELEASE). Дальнейший процесс разработки и последующие релизы только увеличат требуемый объем. Кроме того, разумно будет зарезервировать некоторое (10-20%) дополнительное пространство спокойствия ради. Вот некоторые оценки объема: Полное зеркало FTP: 1.0 TB Репозиторий CVS: 5.4 GB Комплект изменений CTM: 3.2 GB Веб-страницы: 463 MB Текущее использование диска зеркалом FTP можно посмотреть на ftp://ftp.FreeBSD.org/pub/FreeBSD/dir.sizes. Требования к сетевой связности и пропускной способности Разумеется, у вас должно быть подключение к интернет. Требуемая пропускная способность ваших каналов зависит от предполагаемого профиля использования вашего зеркала. Если вы собираетесь копировать некоторые части FreeBSD для локального использования на вашей машине или в интранете, требования могут быть много мягче, чем для публичного зеркала. Для официального зеркала необходимая пропускная способность увеличивается еще больше. Мы можем дать лишь очень грубые оценки: Зеркало для локального доступа: фактически минимум не определен, но канал шириной менее 2 Mbps может сделать процесс обновления мучительно медленным. Неофициальное публичное зеркало: 34 Mbps выглядит неплохо для начала. Официальное зеркало: рекомендуется канал шириной более 100 Mbps; кроме того, ваша машина должна стоять как можно ближе к граничным маршрутизаторам вашей сети. Системные требования, процессор и память Эти требования в первую очередь определяются максимальным ожидаемым количеством клиентов (устанавливается администратором сервера). Также, на требуемые ресурсы влияет список сервисов, которые вы будете предоставлять. Зеркала FTP и/или HTTP не требуют особенно много ресурсов. Будьте на чеку, если планируете предоставлять rsync. Выбор rsync может иметь огромное влияние на требования к аппаратным ресурсам, поскольку rsync признан "прожорливым" по памяти. Вот некоторые советы по конфигурации аппаратной части сервера: Для умеренно посещаемого сайта, предоставляющего Rsync, можно использовать процессор с частотой 800MHz - 1 GHz и по крайней мере 512MB памяти. Скорее всего, данная конфигурация может считаться минимальной для официального зеркала. Для регулярно посещаемого сайта вам потребуется больше памяти (хорошим стартом будет 2GB) и больше процессорной мощности, что может означать требование многопроцессорной (SMP) платформы. Кроме того, вам потребуется быстрая дисковая подсистема, в первую очередь, для работы с репозиторием CVS (крайне рекомендуем RAID). Контроллер SCSI, оборудованный собственной памятью, также может ощутимо ускорить процесс, поскольку большая часть сервисов связана с большим количеством дисковых запросов небольшого размера. Предоставляемые сервисы Всякое зеркало должно предоставлять набор основных сервисов. Помимо требуемого минимального набора, существуют дополнительные сервисы, которые администратор сервера может пожелать предоставлять. Этот раздел описывает, какие сервисы вы можете предоставлять, и какие действия для этого потребуются от вас. FTP (требуется для FTP зеркала) Это один из наиболее базовых сервисов; его предоставление требуется для каждого зеркала, распространяющего файлы FreeBSD по FTP. Доступ по FTP должен быть анонимным, и не должны применяться какие-либо ограничения по соотношению объема передано/принято (что вообще является, на наш взгляд, странным подходом). Закачка (upload) файлов на сервер не требуется (и должна быть запрещена в разделе FreeBSD). Кроме того, архив файлов FreeBSD должен быть доступен с путем /pub/FreeBSD. Для предоставления анонимного FTP доступа может быть использован целый ряд программ (перечислены в алфавитном порядке): /usr/libexec/ftpd: базовый FTP-даемон FreeBSD. Не забудьте прочитать &man.ftpd.8;. ftp/ncftpd: коммерческий пакет, свободен для использования в учебных целях. ftp/oftpd: FTP-даемон, написанный в основном с точки зрения защищенности. ftp/proftpd: Модульный и очень гибкий FTP-даемон. ftp/pure-ftpd: Еще один FTP-даемон, разработанный с позиций защищенности. ftp/twoftpd: См. предыдущий пункт. ftp/vsftpd: очень защищенный (very secure) ftpd. ftp/wu-ftpd: ftpd от Вашингтонского Университета (Washington University). Несколько потерял популярность из-за большого количества найденных в прошлом ошибок защиты. Если вы решите использовать его, помните о необходимости отслеживания обновлений. ftpd, proftpd, wu-ftpd и, возможно, ncftpd являются наиболее часто встречающимися FTP серверами. Прочие распространены среди существующих зеркал в существенно меньшей степени. Дополнительным поводом для рассмотрения может являться возможность гибко ограничивать количество одновременных соединений, что поможет вам удержать в нужных рамках потребление пропускной способности ваших каналов и машинные ресурсы. Rsync (необязательный сервис для FTP зеркала) Rsync часто используется для предоставления доступа к FTP-области FreeBSD, чтобы другие зеркала могли синхронизироваться по вашему. Протокол rsync во многом отличается от FTP, в частности, он гораздо гуманнее с точки зрения пропускной способности каналов, поскольку не требует передачи измененного файла целиком (передаются лишь различия). Взамен Rsync требует значительных объемов памяти. Размер каждого процесса зависит от размера синхронизируемого модуля (в основном от количества директорий и файлов). Rsync может использовать в качестве транспортного протокола rsh или ssh (по умолчанию); также, может использоваться внутренний протокол rsync (этот метод предпочтителен для публичных rsync-серверов). Поддерживается авторизация клиентов и различные ограничения. Для протокола rsync существует единственный пакет: net/rsync HTTP (требуется для веб-страниц, дополнителен для FTP зеркал) Если вы хотите поддерживать зеркало веб-страниц FreeBSD, вам потребуется установить веб-сервер. Дополнительно, вы можете предоставлять HTTP доступ к FTP-набору файлов FreeBSD. Выбор веб-сервера остается на усмотрение администратора зеркала. Некоторые из наиболее популярных веб-серверов перечислены ниже. www/apache13: Apache — самый широко распространённый в Интернете веб-сервер, активно используемый проектом FreeBSD. Вы можете также использовать веб-сервер Apache следующего поколения, доступный в коллекции портов как www/apache22. www/thttpd: Для обслуживания большого количества запросов к статическим документам сервер thttpd может оказаться более эффективным, чем Apache. thttpd отлично оптимизирован по производительности при работе под FreeBSD. www/boa: Boa — еще одна альтернатива thttpd и Apache. Этот сервер должен быть ощутимо более высокопроизводительным, чем Apache, для полностью статических страниц. На время написания данного документа, впрочем, он не так хорошо оптимизирован под FreeBSD, как thttpd. CVSup (желателен для зеркал репозитория CVS) CVSup предоставляет очень эффективный механизм распространения файлов. Он работает подобно rsync и был разработан специально для использования с репозиториями CVS. Если вы планируете предоставлять доступ к репозиторию CVS FreeBSD, стоит делать это посредством CVSup. Помимо этого, можно использовать AnonCVS, FTP, rsync или HTTP, но использование CVSup наиболее разумно. Автором CVSup является &a.jdp.email;. CVSup непросто установить на платформе, отличной от FreeBSD, поскольку он написан на языке Modula-3 и требует соответствующего окружения. &a.jdp; создал усеченную версию M3, достаточную для работы CVSup, которую намного проще установить. Подробности можно прочитать здесь: Ezm3. Относящиеся к теме пакеты: net/cvsup: Порт CVSup (клиент и сервер), требующий для сборки пакет lang/ezm3. net/cvsup-mirror: Набор для CVSup-зеркала, требующий net/cvsup-without-gui, и конфигурирующий его в процессе установки. Возможно, некоторым администраторам потребуется другой набор установок. Может также оказаться полезным пакет net/cvsup-without-gui. Если вы предпочитаете пакет, собранный статически, загляните по этой ссылке. Эта страница все еще описывает ошибку S1G. Возможно, в будущем Джон создаст универсальный сайт для загрузки статически собранных вариантов CVSup для различных платформ. При помощи CVSup можно распространять любые коллекции файлов (не только репозитории CVS), однако его конфигурация может быть непростой. Известно, что CVSup потребляет ощутимое количество процессорного времени как на сервере, так и на клиенте, поскольку сравнивает большое количество файлов. AnonCVS (дополнителен для зеркал репозитория CVS) Если вы копируете репозиторий CVS, можно дополнительно предоставить к нему анонимный доступ. Для начала, предупреждение: спрос на этот сервис не так уж велик, подготовка его требует некоторого опыта, и, наконец, вы должны знать, что делаете. Существует два основных способа удаленного доступа к репозиторию CVS: через pserver и через ssh (доступ через rsh мы рассматривать не будем). Для анонимного доступа наиболее подходит pserver; впрочем, некоторые сайты дают доступ и посредством ssh. Для последнего будет полезной специальная программа, предназначенная для использования в качестве шелла для учетной записи анонимного ssh-доступа. Она использует вызов chroot, поэтому репозиторий CVS должен располагаться внутри домашнего каталога анонимного пользователя, что приемлемо не для всех сайтов. Данное ограничение не распространяется на доступ через pserver, однако последний вариант может быть связан с дополнительным риском с точки зрения безопасности. Никаких дополнительных программ для обеспечения анонимного CVS-доступа не потребуется, поскольку &man.cvs.1; входит в базовую поставку FreeBSD. Вам нужно будет разрешить запуск cvs из inetd, для чего необходимо добавить в файл /etc/inetd.conf строку вида cvspserver stream tcp nowait root /usr/bin/cvs cvs -f -l -R -T /anoncvstmp --allow-root=/home/ncvs pserver Обратитесь к странице справочника &man.cvs.1; за дополнительной информацией по опциям. Кроме того, страницы info по CVS описывают, как удостовериться в том, что вы предоставляете доступ только для чтения. Рекомендуется создать непривилегированную учетную запись, желательно с именем anoncvs. Потребуется также создать файл passwd в каталоге /home/ncvs/CVSROOT и установить пароль (пустой или anoncvs) для пользователя anoncvs. Создание файловой системы /anoncvstmp в памяти не необходимо, но рекомендуется для ускорения работы: в ней &man.cvs.1; будет создавать временную структуру каталогов, которая не используется по завершении операции, но сильно замедляет работу, если требуются операции записи на реальный диск. Пример описания такой файловой системы в файле /etc/fstab: /dev/da0s1b /anoncvstmp mfs rw,-s=786432,-b=4096,-f=512,-i=560,-c=3,-m=0,nosuid 0 0 Эти установки (разумеется, тщательно подобранные) предложил &a.jdp.email;. Как вести зеркало FreeBSD Теперь вам известно, какая потребуется машина и как предоставлять сервисы, но не как получить их самому. :-) В этом разделе описывается процесс ведения зеркала и поддержания его в актуальном состоянии, в том числе какие инструменты использовать и какие сайты выбирать в качестве источников для синхронизации. FTP Файлы, доступные по FTP, составляют большую часть зеркала. Они включают дистрибутивные наборы, необходимые для установки по сети, ветви (branches), в которых отражено текущее состояние исходных текстов, образы ISO для записи компакт-дисков с дистрибутивами для установки, образами живых файловых систем и пакетами, дерево портов, исходные дистрибутивы для сборки портов и кучу готовых пакетов. И, разумеется, все вышеописанное — для разных версий FreeBSD и различных архитектур. При помощи программ для FTP-зеркалирования Для выкачивания файлов вы можете использовать программу FTP-зеркалирования. Вот некоторые из наиболее часто использующихся: ftp/mirror ftp/ftpmirror ftp/emirror ftp/spegla ftp/omi ftp/wget Ранее наиболее популярным вариантом был ftp/mirror, хотя из-за того, что эта программа написана на &man.perl.1;, существуют различные ограничения, в особенности при зеркалировании больших файловых структур, таких как FreeBSD. Утверждается, впрочем, что в текущей версии последняя проблема исправлена за счет дополнительного алгоритма сравнения структуры каталогов. Вообще говоря, протокол FTP не лучшим образом подходит для поддержки зеркала. Измененный файл передается целиком; кроме того, невозможно создание единого потока данных, который мог бы повысить эффективность передачи за счет большого TCP-окна. При помощи rsync Более эффективным будет синхронизация FTP-области при помощи rsync. Для этого следует установить пакет net/rsync, который был описан в разделе . Поскольку доступ по протоколу rsync не является обязательным, выбранный вами сайт может его не поддерживать. Возможно, вам придется немного поискать в сетевой окрестности зеркало, поддерживающее rsync. Поскольку от количества клиентов rsync ощутимо зависит загрузка сервера, большинство администраторов вводят ограничения доступа. Для поддержания зеркала вам следует связаться с администратором сайта, с которым вы будете синхронизироваться, для уточнения локальных правил и, возможно, для внесения в них исключения для вас (поскольку вы также поддерживаете зеркало). Строка для синхронизации FreeBSD по rsync выглядит примерно так: &prompt.user; rsync -vaz --delete ftp4.de.FreeBSD.org::FreeBSD/ /pub/FreeBSD/ Загляните в документацию по rsync, также доступную по адресу http://rsync.samba.org/ за дополнительной информацией по различным опциям rsync. Обратите внимание, что в случае синхронизации модуля целиком (а не отдельного каталога) необходимо явно указать результирующий каталог, потому что каталог с именем модуля (в данном случае "FreeBSD") не создается. Для поддержания актуальности вам потребуется создать скрипт для запуска подобной команды из &man.cron.8;. При помощи CVSup Немногие сайты, в первую очередь центральный ftp-master.FreeBSD.org предоставляют для синхронизации FTP-области доступ по протоколу CVSup. Вам потребуется клиент CVSup, предпочтительно из пакета net/cvsup (см. также ). Пример конфигурационного файла (supfile) для синхронизации с ftp-master.FreeBSD.org: # # FreeBSD archive supfile from master server # *default host=ftp-master.FreeBSD.org *default base=/usr *default prefix=/pub #*default release=all *default delete use-rel-suffix *default umask=002 # If your network link is a T1 or faster, comment out the following line. #*default compress FreeBSD-archive release=all preserve Судя по всему, синхронизация при помощи CVSup — лучший по эффективности способ поддержки зеркала, однако он доступен лишь с небольшого числа сайтов. Прочтите документацию по CVSup, например, &man.cvsup.1;, и обратите внимание на опцию . Она может уменьшить объем операций ввода-вывода, предполагая, что записанная информация о каждом файле корректна. Зеркалирование CVS репозитория Существует несколько способов синхронизации CVS репозитория. CVSup наиболее общий метод. Использование CVSup Программа CVSup немного описана в ( и ). Настроить CVSup зеркало очень просто. Установка net/cvsup-mirror проверит, что все нужные программы установлены и затем соберет всю необходимую информацию для конфигурирования зеркала. Не забудьте почитать полезную подсказку здесь. Другие методы Использование методов, отличных от CVSup, не рекомендуется. Тем не менее, мы кратко упомянем их. Поскольку большая часть зеркал дает доступ к репозиторию CVS в числе прочих файлов, доступных по FTP, по пути /pub/FreeBSD/development/FreeBSD-CVS, могут быть использованы: FTP Rsync HTTP AnonCVS не может использоваться для зеркалирования CVS репозитория, так как CVS не разрешает сам доступ к репозиторию, а только к извлечённым версиям модулей. Зеркалирование страниц WWW Лучшим способом будет извлечение (check out) из репозитория CVS модуля www. При условии наличия у вас копии репозитория, все, что для этого потребуется — выполнить команду &prompt.user; cvs -d /home/ncvs co www и сформировать задание для cron, которое будет регулярно выполнять операцию cvs up -d -P, например, каждый раз после обновления копии репозитория. Разумеется, файлы должны находиться в иерархии, доступной для публичного веб-доступа. Мы сознательно не будем обсуждать здесь процесс установки и конфигурации веб-сервера для этих целей. Если у вас нет локальной копии репозитория, можно использовать CVSup для синхронизации копии веб-страниц. Пример конфигурации можно найти в файле /usr/share/examples/cvsup/www-supfile. Приведем его здесь: # # WWW module supfile for FreeBSD # *default host=cvsup3.de.FreeBSD.org *default base=/usr *default prefix=/usr/local *default release=cvs tag=. *default delete use-rel-suffix # If your network link is a T1 or faster, comment out the following line. *default compress # This collection retrieves the www/ tree of the FreeBSD repository www Использование пакета ftp/wget или иных инструментов для создания веб-зеркал не рекомендуется. Зеркала документации FreeBSD Поскольку многие веб-страницы ссылаются на документацию, хорошей идеей является поддержка зеркала документации FreeBSD совместно с прочими зеркалами. Надо отметить, что этот процесс не столь тривиален, как поддержка зеркала веб-страниц самих по себе. Для начала вы должны создать копию исходных текстов документации (как и во многих других случаях, для этого предпочтителен CVSup). Вот пример файла конфигурации: # # FreeBSD documentation supfile # *default host=cvsup3.de.FreeBSD.org *default base=/usr *default prefix=/usr/share *default release=cvs tag=. *default delete use-rel-suffix # If your network link is a T1 or faster, comment out the following line. #*default compress # This will retrieve the entire doc branch of the FreeBSD repository. # This includes the handbook, FAQ, and translations thereof. doc-all Затем, вам потребуется несколько пакетов. К счастью, специально для этого существует мета-порт textproc/docproj. Также, необходимо установить некоторые переменные окружения, например SGML_CATALOG_FILES, и переменные в файле /etc/make.conf, главным образом переменную DOC_LANG (используйте файл /usr/share/examples/make.conf как шаблон). После этого можно выдать команду make в главном каталоге документации (по умолчанию это /usr/share/doc). Как и прежде, эти каталоги должны быть доступны для вашего веб-сервера (проверьте, что ссылки ведут в нужные места). Процесс подготовки и построения документации, а также многие сопутствующие вопросы, подробно описан в документе Учебник по Проекту Документирования &os;. Прочтите этот документ, в особенности если у вас возникли проблемы со сборкой стандартного комплекта документации. Как часто синхронизироваться? Каждое зеркало должно регулярно обновляться. Вам потребуется какой-то набор скриптов, выполняемых посредством &man.cron.8;. Поскольку каждый администратор, как правило, пишет такие скрипты сам и на свой лад, мы не можем выдать конкретных указаний. Общие же советы выглядят так: Создайте скрипт с командой, которая запустит нужное приложение для обновления зеркала. Рекомендуем использовать скрипт на языке обычного /bin/sh. Добавьте команд перенаправления вывода, чтобы записать диагностику работы в файл. Попробуйте, как ваш скрипт работает. По завершении проверьте логи. При помощи утилиты &man.crontab.1; добавьте ваш скрипт в таблицу регулярных заданий &man.crontab.5; соответствующего пользователя. Это должен быть пользователь, отличный от пользователя FTP-даемона, чтобы файлы в FTP-области без атрибута "чтение для всех" не были доступны анонимным FTP-пользователям. Данное свойство используется для тестирования перед выходом новых релизов, для того чтобы удостовериться, что все официальные зеркала содержат все необходимые файлы к моменту официального объявления релиза. Некоторые рекомендуемые установки частоты обновления: FTP-набор: раз в сутки репозиторий CVS: раз в час WWW-страницы: раз в сутки С какого сервера синхронизироваться Это важный вопрос, так что мы попытаемся пояснить, откуда берутся ответы. Для начала повторим еще несколько раз: никогда не синхронизируйтесь с ftp.FreeBSD.org . Организация системы зеркал Зеркала организуются по странам. Имена хостов всех официальных зеркал построены по принципу ftpN.CC.FreeBSD.org, где CC (country code) — домен верхнего уровня страны, где расположено зеркало, N — номер зеркала в данной стране. Этот же принцип применим к именам хостов cvsupN.CC.FreeBSD.org, wwwN.CC.FreeBSD.org и т.п. Кроме того, есть зеркала без доменной части, обозначающей страну. Все они имеют очень хорошие внешние каналы и обслуживают большое число одновременных соединений. Имя ftp.FreeBSD.org на самом деле указывает на две машины, одна из которых в настоящее время находится в Дании, а другая в США. Ни одна из этих машин НЕ является основным сайтом, и потому не должна использоваться для синхронизации. Масса документации для живых пользователей указывает на ftp.FreeBSD.org, так что автоматическим системам ведения зеркал следует выбирать другие источники синхронизации. Кроме того, существует иерархия зеркал в терминах их удаленности от центра, или слоях. Основные сайты могут быть описаны как Зеркала нулевого слоя. Зеркала, синхронизирующиеся по ним, считаются слоем 1, следующие — слоем 2 и т.д. Официальные сайты приглашаются на низкие слои, однако следует помнить, что чем меньше номер слоя, тем выше требования к зеркалу, как было описано в . Помимо того, доступ к зеркалам 1 слоя может быть ограничен; безусловно ограничен доступ к основным сайтам. Иерархия слоев не отражается в DNS и, вообще говоря, нигде (кроме мастер-сайтов) не документирована. Тем не менее, официальные зеркала с малыми (1-4, как правило) номерами обычно представляют первый слой. (Это грубая оценка, и ни в коем случае не правило). Так откуда же мне синхронизироваться? Главное — НЕ с ftp.FreeBSD.org. Короткий ответ: с зеркала, которое расположено недалеко от вас в терминах Интернет, и/или доступ к которому наилучший. Я хочу получить копию зеркала хоть откуда-нибудь! Если у вас нет каких-либо специальных предпочтений или требований, см. . Это означает: Выберите те из них, с которыми вам работать быстрее всего (меньшее число промежуточных узлов и время отклика), и которые предоставляют нужные вам сервисы (такие как rsync или CVSup). Свяжитесь с администраторами выбранного сервера, опишите ваши запросы и уточните их правила. Сконфигурируйте ваше зеркало, как описывалось выше. Я поддерживаю официальное зеркало, какой сайт мне выбрать? В основном, правила, описанные в , применимы. Дополнительно можно убедиться, что выбранный сайт принадлежит низкому слою. Другие соображения относительно официальных зеркал описаны в . Мне нужен доступ к основным сайтам! При наличии достаточных причин вы можете получить доступ к одному из основных сайтов. Доступ к ним ограничен; существуют специальные правила их использования. Наличие у вас статуса официального зеркала, безусловно, является хорошим подспорьем. В противном случае убедитесь, что ваша страна действительно нуждается еще в одном зеркале. Если их уже три или более, сначала свяжитесь с администратором соответствующей зоны DNS (hostmaster@CC.FreeBSD.org) или напишите в &a.hubs;. Доступ к одному из мастер-сайтов или подходящему зеркалу 1 уровня вам помогут обеспечить те же, кто помогал вам получить статус официального зеркала. В случае неудачи свяжитесь с mirror-admin@FreeBSD.org и попросите помощи у них. Существует три основных сайта для синхронизации набора файлов FTP и один для репозитория CVS. Веб-страницы и документация хранятся в CVS, поэтому не имеют отдельных основных сайтов. ftp-master.FreeBSD.org Это основной сервер для синхронизации FTP набора. ftp-master.FreeBSD.org поддерживает доступ по rsync и CVSup, в дополнение к FTP. Использование этих протоколов описано в разделах и . Приветствуется предоставление зеркалами 1 уровня доступа к FTP-области по протоколу rsync. cvsup-master.FreeBSD.org Это основной сервер для синхронизации репозитория CVS. cvsup-master.FreeBSD.org обеспечивает доступ только по протоколу CVSup. Детали см. в . Для получения доступа к этому серверу вам нужно связаться с &a.cvsup-master;. Не забудьте сначала прочитать Правила доступа к центральному CVSup серверу FreeBSD! Подготовьте параметры авторизации, как описано здесь. Не забудьте, что в качестве имени сервера команде cvpasswd нужно указать freefall.FreeBSD.org, несмотря на то, что устанавливать соединение вы будете с cvsup-master.FreeBSD.org. Официальные зеркала Официальные зеркала обладают следующим свойствами: a) имеют запись в домене FreeBSD.org (обычно типа CNAME). b) присутствуют в списке официальных зеркал в Руководстве по FreeBSD и другой документации. На настоящий момент это все, что отличает их от прочих зеркал. Официальные зеркала не обязательно принадлежат к Первому уровню, однако, вряд ли можно найти зеркало уровня 1, не являющееся официальным. Отдельные требования к официальным зеркалам 1 уровня Описать требования для всех официальных зеркал не так просто, поскольку проект FreeBSD достаточно мягок в этом отношении. Несколько проще указать, что требуется от официальных зеркал уровня 1. Прочие официальные зеркала должны рассматривать этот список как настойчивые пожелания. Следующее относится в основном к набору файлов FTP, поскольку репозиторий CVS всегда должен зеркалироваться полностью, а веб-страницы представляют собой несколько особый случай. Зеркала 1 уровня должны: поддерживать полный список файлов предоставлять доступ для других зеркал обеспечивать доступ по протоколам FTP и rsync. Кроме того, администратор такого зеркала должен быть подписан на &a.hubs;. См. здесь для дополнительной информации о подписке. Администраторы зеркал, в особенности 1 уровня, должны очень внимательно следить за графиком релизов. Это поможет подготовиться к крупным всплескам нагрузки на зеркало, которые всегда происходят после очередного релиза. Кроме того, важно поддерживать актуальность зеркал (в особенности зеркал уровня 1). Если Зеркало1 не синхронизировалось в течение длительного времени, то зеркала следующего уровня будут синхронизироваться по устаревшей информации и т.д. Поддерживайте актуальность ваших зеркал! Как стать официальным зеркалом? На текущий момент заявки на подключение новых зеркал не принимаются. Статистика некоторых зеркал Вот несколько ссылок на статистику использования зеркал Статистика FTP сайтов ftp.is.FreeBSD.org - hostmaster@is.FreeBSD.org - (загрузка канала) (FTP процессы) (HTTP процессы) ftp.cz.FreeBSD.org - cejkar@fit.vutbr.cz - (загрузка канала) (FTP процессы) (rsync процессы) ftp2.ru.FreeBSD.org - mirror@macomnet.ru - (Bandwidth) (HTTP and FTP users) Статистика CVSup сайтов cvsup[23456].jp.FreeBSD.org - kuriyama@FreeBSD.org - (CVSup процессы) cvsup.cz.FreeBSD.org - cejkar@fit.vutbr.cz - (CVSup процессы) cvsup4.ru.FreeBSD.org - maxim@FreeBSD.org - (CVSup процессы)
diff --git a/ru_RU.KOI8-R/articles/ipsec-must/Makefile b/ru_RU.KOI8-R/articles/ipsec-must/Makefile index f047bc5903..64934e4158 100644 --- a/ru_RU.KOI8-R/articles/ipsec-must/Makefile +++ b/ru_RU.KOI8-R/articles/ipsec-must/Makefile @@ -1,23 +1,23 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/ipsec-must/Makefile,v 1.3 2004/02/20 07:52:54 andy Exp $ # Article: Independent Verification of IPsec Functionality in FreeBSD # -# Original revision: r21827 +# Original revision: r39631 # DOC?= article FORMATS?= html INSTALL_COMPRESSED?=gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/ipsec-must/article.xml b/ru_RU.KOI8-R/articles/ipsec-must/article.xml index 89daaab896..33e3a069b5 100644 --- a/ru_RU.KOI8-R/articles/ipsec-must/article.xml +++ b/ru_RU.KOI8-R/articles/ipsec-must/article.xml @@ -1,355 +1,355 @@
Независимое исследование работы IPsec во FreeBSD DavidHonig
honig@sprynet.com
 1999-05-03 &tm-attrib.freebsd; &tm-attrib.opengroup; &tm-attrib.general; $FreeBSD$ Вы только что установили и настроили IPsec, и оно, кажется, заработало. Как это можно проверить? Я опишу метод экспериментальной проверки правильного функционирования IPsec. Постановка задачи Для начала предположим, что Вы настроили IPsec. Как Вы узнаете, что IPsec работает? Несомненно, соединения не будет, если Вы неверно его сконфигурировали. И оно, конечно, появится в выводе команды &man.netstat.1;, когда Вы всё сделаете верно. Но можно ли как-то подтвердить сам факт функционирования IPsec? Решение Для начала немножко криптографической теории: Шифрованные данные равномерно распределены по области определения, то есть каждый символ имеет максимальную энтропию; Сырые и несжатые данные как правило избыточны, то есть их энтропия меньше максимально возможной. Предположим, что у Вас имеется возможность измерить энтропию входящего и исходящего трафика на сетевом интерфейсе. В этом случае Вы сможете легко отличить зашифрованные данные от открытых, причём даже в том случае, когда часть данных в режиме шифрования передаётся в открытом виде, к примеру внешние заголовки IP, которые используются для маршрутизации. MUST Универсальный Статистический Тест для Генераторов Случайных Чисел Уэли Маурера (Ueli Maurer's Universal Statistical Test for Random Bit Generators), сокращённо MUST позволяет быстро измерить энтропию последовательного набора данных. Используемый алгоритм похож на алгоритм сжатия. В приложении приведён исходный код, позволяющий измерять энтропию последовательных кусков данных размером около четверти мегабайта. Tcpdump Ещё нам нужен способ сохранения информации, проходящей через интерфейс. Программа &man.tcpdump.1; позволяет сделать это в случае, если Вы сконфигурировали своё ядро с поддержкой Пакетного Фильтра Беркли (Berkeley Packet Filter). Команда tcpdump -c 4000 -s 10000 -w dumpfile.bin сохранит 4000 пакетов в файл dumpfile.bin. В данном примере объём записываемой информации в каждом пакете не может превышать 10,000 байтов. Эксперимент Повторите следующие шаги эксперимента: Откройте два окна терминала и свяжитесь в одном из них с каким-нибудь компьютером через канал IPsec, а в другом — с обычным, незащищённым компьютером. Теперь начните сохранять пакеты. В шифрованном окне запустите команду &unix; &man.yes.1;, которая будет выдавать бесконечный поток символов y. Немножко подождите и завершите её. Затем переключитесь в обычное окно (не использующее канал IPsec) и сделайте то же самое. Заключительный этап: запустите MUST, передав ему для обработки только что сохранённые пакеты через командную строку. Вы должны увидеть что-то вроде изображённого чуть ниже. Заметьте, что безопасное соединение имеет 93% (6,7) от ожидаемого значения (7,18), а обычное соединение — всего лишь 29% (2,1). &prompt.user; tcpdump -c 4000 -s 10000 -w ipsecdemo.bin &prompt.user; uliscan ipsecdemo.bin Uliscan 21 Dec 98 L=8 256 258560 Measuring file ipsecdemo.bin Init done Expected value for L=8 is 7.1836656 6.9396 -------------------------------------------------------- 6.6177 ----------------------------------------------------- 6.4100 --------------------------------------------------- 2.1101 ----------------- 2.0838 ----------------- 2.0983 ----------------- Замечание Этот эксперимент показывает, что IPsec действительно распределяет передаваемые байты по области определения равномерно, как и любое другое шифрование. Однако этот метод не может обнаружить множество других изъянов в системе (хотя я таковых не знаю). Для примера можно привести плохие алгоритмы генерации или обмена ключами, нарушение конфиденциальности данных или ключей, использование слабых в криптографическом смысле алгоритмов, взлом ядра и т. д. Изучайте исходный код, узнавайте, что там происходит. Определение IPsec IPsec представляет собой протокол безопасного обмена информацией по Internet. Существует в виде расширения к IPv4; является неотъемлемой частью IPv6. Содержит в себе протокол шифрования и аутентификации на уровне IP (межмашинное host-to-host взаимодействие). SSL защищает только лишь конкретный прикладной сокет; SSH защищает вход на машину; PGP защищает определённый файл или письмо. IPsec шифрует всю информацию, передаваемую между двумя машинами. Установка IPsec Большинство современных версий FreeBSD уже имеют поддержку IPsec. Вероятно, Вы должны будете лишь добавить опцию в конфигурационный файл ядра, и после сборки и инсталляции нового ядра, сконфигурировать соединение IPsec с помощью команды &man.setkey.8;. Более подробно о том, как запустить IPsec во FreeBSD можно прочесть в Руководстве пользователя. src/sys/i386/conf/KERNELNAME Для того, чтобы захватывать сетевой трафик при помощи &man.tcpdump.1;, следующие строки должны присутствовать в конфигурационном файле ядра. Не забудьте после модификации запустить &man.config.8;, и, как обычно, пересобрать и установить новое ядро. device bpf Универсальный Статистический Тест Маурера (размер блока — 8 бит) Оригинал нижеприведённого кода находится по этому адресу. /* ULISCAN.c ---blocksize of 8 1 Oct 98 1 Dec 98 21 Dec 98 uliscan.c derived from ueli8.c This version has // comments removed for Sun cc This implements Ueli M Maurer's "Universal Statistical Test for Random Bit Generators" using L=8 Accepts a filename on the command line; writes its results, with other info, to stdout. Handles input file exhaustion gracefully. Ref: J. Cryptology v 5 no 2, 1992 pp 89-105 also on the web somewhere, which is where I found it. -David Honig honig@sprynet.com Usage: ULISCAN filename outputs to stdout */ #define L 8 #define V (1<<L) #define Q (10*V) #define K (100 *Q) #define MAXSAMP (Q + K) #include <stdio.h> #include <math.h> int main(argc, argv) int argc; char **argv; { FILE *fptr; int i,j; int b, c; int table[V]; double sum = 0.0; int iproduct = 1; int run; extern double log(/* double x */); printf("Uliscan 21 Dec 98 \nL=%d %d %d \n", L, V, MAXSAMP); if (argc < 2) { printf("Usage: Uliscan filename\n"); exit(-1); } else { printf("Measuring file %s\n", argv[1]); } fptr = fopen(argv[1],"rb"); if (fptr == NULL) { printf("Can't find %s\n", argv[1]); exit(-1); } for (i = 0; i < V; i++) { table[i] = 0; } for (i = 0; i < Q; i++) { b = fgetc(fptr); table[b] = i; } printf("Init done\n"); printf("Expected value for L=8 is 7.1836656\n"); run = 1; while (run) { sum = 0.0; iproduct = 1; if (run) for (i = Q; run && i < Q + K; i++) { j = i; b = fgetc(fptr); if (b < 0) run = 0; if (run) { if (table[b] > j) j += K; sum += log((double)(j-table[b])); table[b] = i; } } if (!run) printf("Premature end of file; read %d blocks.\n", i - Q); sum = (sum/((double)(i - Q))) / log(2.0); printf("%4.4f ", sum); for (i = 0; i < (int)(sum*8.0 + 0.50); i++) printf("-"); printf("\n"); /* refill initial table */ if (0) { for (i = 0; i < Q; i++) { b = fgetc(fptr); if (b < 0) { run = 0; } else { table[b] = i; } } } } }
diff --git a/ru_RU.KOI8-R/articles/laptop/Makefile b/ru_RU.KOI8-R/articles/laptop/Makefile index bc2e5c0fd3..715ed004fb 100644 --- a/ru_RU.KOI8-R/articles/laptop/Makefile +++ b/ru_RU.KOI8-R/articles/laptop/Makefile @@ -1,22 +1,22 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/laptop/Makefile,v 1.3 2005/12/20 11:38:53 gad Exp $ # -# Original revision: r20561 +# Original revision: r39631 # # Article: FreeBSD on Laptops # DOC?= article FORMATS?= html INSTALL_COMPRESSED?=gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/laptop/article.xml b/ru_RU.KOI8-R/articles/laptop/article.xml index c56f91864c..d11ea24c3e 100644 --- a/ru_RU.KOI8-R/articles/laptop/article.xml +++ b/ru_RU.KOI8-R/articles/laptop/article.xml @@ -1,301 +1,301 @@
FreeBSD на лэптопах Перевод на русский язык Виталий Богданов FreeBSD, за некоторым исключением, прекрасно работает на большинстве лэптопов. Далее обсуждаются вопросы, специфичные для работы FreeBSD на лэптопах, которые касаются аппаратных требований, отличающихся от настольных компьютеров. &tm-attrib.freebsd; &tm-attrib.linux; &tm-attrib.microsoft; &tm-attrib.general; $FreeBSD$ $FreeBSD$ FreeBSD часто воспринимается как операционная система для серверов, но она прекрасно работает и на настольных компьютерах, а если вы захотите использовать ее на вашем лэптопе, то вы получите все обычные преимущества: строгое распределение дискового пространства, простота администрирования и обновления, система портов/пакаджей для установки программного обеспечения и так далее. (Ее остальные преимущества, такие, как стабильность, высокая производительность сетевых операций и производительность при большой нагрузке, конечно, могут быть необычными для лэптопа.) Однако при ее установке на лэптопы часто возникают проблемы, которых нет на настольных машинах и редко обсуждаются (лэптопы, гораздо чаще, чем настольные машины, тонко настроены под µsoft.windows;). Эта статья предназначена для обсуждения этих проблем. Есть люди, которые задокументировали свой опыт работы с &os; на отдельных моделях лэптопов на web страничках, не являющихся частью &os; документации. Вы наверняка найдете некоторую информацию, если воспользуйтесь вашим любимым поисковиком, введя в нём модель лэптопа и слово &os;. Дополнительно существует специфичная для &os; база данных, цель которой давать информацию по аппаратным вопросам, связанным с лэптопами, Список лэптопов, совместимых с &os;. Если вы хотите пообщаться с другими пользователями &os; на лэптопах, используйте список рассылки &a.mobile.name;. Вы также можете получить дополнительную информацию о использовании лэптопов во &os; по адресу http://tuxmobil.org/mobile_bsd.html. &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/Makefile b/ru_RU.KOI8-R/articles/linux-comparison/Makefile index 9b4f550330..d78f5416e2 100644 --- a/ru_RU.KOI8-R/articles/linux-comparison/Makefile +++ b/ru_RU.KOI8-R/articles/linux-comparison/Makefile @@ -1,22 +1,22 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/linux-comparison/Makefile,v 1.2 2005/09/13 10:23:44 gad Exp $ # $FreeBSD$ # -# Original revision: r25240 +# Original revision: r39631 # # Article: FreeBSD and Linux Comparison Whitepaper DOC?= article FORMATS?= html INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/linux-comparison/article.xml b/ru_RU.KOI8-R/articles/linux-comparison/article.xml index cf5e092475..59ee69a572 100644 --- a/ru_RU.KOI8-R/articles/linux-comparison/article.xml +++ b/ru_RU.KOI8-R/articles/linux-comparison/article.xml @@ -1,529 +1,529 @@
&os;: Open Source альтернатива &linux; DruLavigne
dru@isecom.org
 2005 Dru Lavigne $FreeBSD$ $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 Краткая история на http://www.oreilly.com/catalog/opensources/book/kirkmck.html. . Так как и ядро и предлагаемые утилиты находятся под контролем одной группы по выпуску релизов - меньше вероятность несовместимости библиотек. Уязвимости в безопасности также могут быстро обнаруживаться командой по безопасности. Когда появляются новые утилиты или возможности ядра пользователю просто надо прочесть один файл (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 или закрытием кода в проприетарном коммерческом продукте Довольно объективный взгляд на качества каждой лицензии можно посмотреть на http://en.wikipedia.org/wiki/BSD_and_GPL_licensing. . Наличие стабильного и надёжного кода под заманчивой 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 простых в установке приложений от третьих лиц Используя Коллекцию портов FreeBSD: для установки программного обеспечения достаточно просто набрать pkg_add -r имя_приложения. , включая 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 и где искать информацию по безопасности доступна на http://www.FreeBSD.org/security/. Одна из проблем, связанная с 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; предлагает много поддерживаемых списков рассылки, где ответы архивируются и полностью доступны для поиска. Если у вас есть вопрос, который не затрагивается Руководством, он почти наверняка уже отвечался в списке рассылки. И Руководство и списки рассылки также доступны на нескольких языках, все из которых легко доступны с http://www.FreeBSD.org. Существует множество IRC каналов, посвящённых FreeBSD, форумов и групп пользователей. Смотрите http://www.FreeBSD.org/support.html для выбора. Если вы ищите администратора &os;, разработчика или поддерживающий персонал пошлите описание работы, включающее географическое местоположение в freebsd-jobs@FreeBSD.org. Коммерческие предложения Существует много поставщиков, которые занимаются коммерческой поддержкой &os;. Ресурсы по поиску поставщика, находящегося поблизости от вас включают в себя: Страничка коммерческих поставщиков на сайте &os;: http://www.FreeBSD.org/commercial/ FreeBSDMall, который продаёт контракты на поддержку примерно 10 лет: http://www.freebsdmall.com База данных BSDTracker на: http://www.nycbug.org/index.php?NAV=BSDTracker Существует также инициатива по сертификации системных администраторов BSD. http://www.bsdcertification.org. Если ваш проект требует Common Criteria certification, &os; включает подсистему TrustedBSD MAC для облегчения процесса сертификации. Преимущества выбора &os; Существует много преимуществ для включения решений &os; в вашу IT инфраструктуру: &os; хорошо документирована и следует множеству стандартов. Это позволит вашим существующим вспомогательным и опытным системным администраторам быстро приспособить их существующие Linux и Unix навыки для администрирования FreeBSD. Разработчики, работающие из дома имеют полный доступ ко всему коду FreeBSD Плюс ко всему, весь код доступен через веб-интерфейс: http://www.FreeBSD.org/cgi/cvsweb.cgi/. всех релизов вплоть до первого выпущенного. Вместе с кодом включены все лог сообщения, которые предоставляют контекст для изменений и исправлений ошибок. Дополнительно, разработчик может легко скопировать любой релиз, просто закачав код с требуемой меткой. В противоположность сказанному, &linux; по традиции не следовал данной модели, но недавно адаптировал более совершенную модель разработки Интересный обзор развивающейся модели разработки Linux может быть найден на http://linuxdevices.com/articles/AT4155251624.html. . Разработчики, работающие из дома также имеют полный доступ к FreeBSD базе данных сообщений об ошибках, GNATS. Они могут и запрашивать и прослеживать существующие ошибки также, как и предоставлять свои патчи на одобрение и возможное внесение в базовый код FreeBSD. http://www.FreeBSD.org/support.html#gnats BSD лицензия позволяет вам свободно модифицировать код, чтобы он подходил для ваших бизнес целей. В отличии от GPL, не существует ограничений в том, как вы выберете распространять конечный программный продукт. Заключение &os; - это зрелая &unix;-подобная операционная система, включающая в себя множество возможностей, которые можно ожидать в современной &unix; системе. Для тех, кто хочет внедрить Open Source решение в их существующую инфраструктуру, &os; будет хорошим выбором.
diff --git a/ru_RU.KOI8-R/articles/mailing-list-faq/article.xml b/ru_RU.KOI8-R/articles/mailing-list-faq/article.xml index 52eaa53771..f79c9b7356 100644 --- a/ru_RU.KOI8-R/articles/mailing-list-faq/article.xml +++ b/ru_RU.KOI8-R/articles/mailing-list-faq/article.xml @@ -1,497 +1,497 @@
Часто задаваемые вопросы по спискам рассылки &os; The &os; Documentation Project 2004 2005 The &os; Documentation Project $FreeBSD$ $FreeBSD$ Эта статья посвящена часто задаваемым вопросам (FAQ) по спискам рассылки &os;. Если вы хотите помочь поддерживать данный документ, напишите письмо в &a.doc;. Последняя версия данного документа доступна на WWW сервере &os;. Вы можете получить данную статью в виде одного большого HTML файла, используя HTTP протокол или в виде простого текста, форматов PostScript, PDF, и других с FTP сервера &os;. Возможно вы захотите Найти FAQ. Введение Цель этого документа ответить на часто задаваемые вопросы, касающиеся списков рассылки &os;. Хотя FAQ задумывались для снижения количества задаваемых повторяющихся вопросов, они стали восприниматься, как ценные источники информации. Этот документ - попытка представить консенсус всего сообщества, и поэтому он не может считаться официальным. Если вы найдете технические неточности в данном документе или у вас есть предложения по добавлению новых пунктов, пожалуйста отправьте PR или напишите в &a.doc;. Спасибо. Зачем вообще нужны списки рассылки по &os;? Списки рассылки по &os; служат, как первичное средство связи &os; сообщества, они покрывают множество различных тем. Кто пользуется этими списками рассылки? Это зависит от темы обсуждения каждого конкретного списка рассылки. Некоторые списки больше ориентированны на разработчиков, некоторые на всё сообщество &os; в целом. Список существующих на сегодняшний день списков рассылки доступен здесь. Доступны ли списки рассылки по &os; для каждого? Повторюсь, это зависит от характера обсуждаемых тем в каждом конкретном листе. Пожалуйста прочтите устав списка рассылки перед отправлением в него письма и соблюдайте его при каждом отправлении. Это будет полезно каждому получить больше опыта по работе со списками рассылки. Если после просмотра выше расположенного списка, вы до сих пор не знаете в какой список рассылки направить письмо, то вам наверняка подойдёт freebsd-questions (но прежде прочтите ниже). Заметьте, что для отправки письма в список рассылки необязательно быть подписанным на него. Это поможет легче присоединиться к сообществу &os; и способствует открытому обмену идей. Но, из-за небрежности некоторых людей некоторые списки проводят политику предварительного ручного просмотра сообщений от не подписанных пользователей, чтобы убедиться в их целесообразности. Как я могу подписаться? Вы можете использовать web интерфейс Mailman для подписки на любой из открытых списков рассылки. Как мне отписаться? Вы можете использовать вышеупомянутый интерфейс или следовать инструкциям, находящимся в конце каждого письма, отправленного в этот список рассылки. Пожалуйста, не посылайте письма с отказом от подписки в сами публичные списки. Во-первых, вы так не отпишитесь, а во-вторых, вызовете раздражение подписчиков, и вероятно получите неприятные высказывания в свой адрес. Это классическая ошибка при работе со списками рассылки; старайтесь не повторять её. Доступны ли архивы? Да. Архивы доступны здесь. Доступны ли списки рассылки в дайджест формате? Да. Посмотрите web интерфейс Mailman. Этикет списков рассылки Участие в любом списке рассылки, как и в любом другом сообществе требует общего базиса для общения. Пожалуйста, отправляйте только подходящие сообщения и следуйте общепринятым нормам этикета. Что я должен сделать перед отправлением письма? Вы уже сделали важный шаг, решив прочитать эту статью. Если вы новичок во &os;, то сначала ознакомьтесь с программным обеспечением и связанной с нею документацией, включающей множество книг и статьей. Могут быть интересными: Часто задаваемые вопросы по &os; (FAQ), Руководство по &os; , и статьи Как работать со списком рассылки FreeBSD-questions с максимальной отдачей, Что такое BSD, и Пособие для новичков во &os;. Вы можете получить нелицеприятные высказывания в свой адрес, если зададите вопрос, ответ на который есть в приведённой выше документации. Это не потому что добровольцы, работающие над данным проектом очень плохие люди, а после многократного ответа на одни и те же вопросы - раздражение берёт своё. Это особенно справедливо, если уже существует и доступен ответ на вопрос. Не забывайте, что вся работа по улучшению &os; выполняется добровольцами, и что мы только люди. Что считается несоответствующим письмом? Письма должны соответствовать уставу списка рассылки. Избегайте личных оскорблений. Как хорошие жители сети, мы должны держать себя по высоким стандартам поведения. Спам не разрешён. Нарушители данного правила будут забаненны. Что считается хорошим этикетом при посылке писем в списки рассылки? Пожалуйста, составляйте строки длиной примерно в 75 символов, так так не каждый использует модную почтовую программу с графическим интерфейсом. Пожалуйста, обращайте внимание на тот факт, что пропускная способность ограничена. Не каждый читает почту через высокоскоростное соединение. Если вы отправляете содержимое какого-нибудь файла, например config.log или объёмную трассировку стека, то, пожалуйста, размещайте его на каком-нибудь веб-сайте и присылайте просто ссылку на на него. Помните, что такие сообщения будут заархивированны, и это просто добавит ненужные байты к архиву. Оформляйте ваше сообщение, чтобы оно было читабельно и ПОЖАЛУЙСТА, НЕ КРИЧИТЕ!!!!!. Не упускайте из виду эффект, которое производит плохо отформатированное письмо, причём не только в списках рассылки &os;. Ваше сообщение будет просмотрено другими людьми, и если оно плохо отформатировано, имеет множество ошибок и/или восклицательных знаков, то это создаст нехорошее впечатление о вас. Пожалуйста, используйте подходящий язык общения для конкретного списка рассылки. Существует много не англоязычных рассылок. Мы понимаем, что для многих английский не родной язык и поэтому мы пытаемся сделать некие пособия. Считается плохим тоном критиковать людей не говорящих по-английски за лексические и грамматические ошибки. &os; имеет отличные продвижения в этом отношении. Пожалуйста, помогайте сохранять нам эту традицию. Пожалуйста, используйте совместимый со стандартами почтовый клиент (MUA). Много плохо отформатированных сообщений исходят от неправильно работающих или плохо сконфигурированных почтовых клиентов. Известно, что следующие почтовые программы могут посылать неправильно отформатированные сообщения без вашего ведома: exmh µsoft; Exchange µsoft; &outlook; Постарайтесь не использовать MIME: многие используют программы, которые не очень хорошо работают с MIME. Проверьте правильность настроек времени и временной зоны. Это может выглядеть немножко глупо, потому что ваши сообщения все равно будут доставляться, однако многие люди получают несколько сотен сообщений в день. Зачастую они сортируют входящие сообщения по теме и дате, и если ваше сообщение не будет предшествовать первому ответу, то они могут предположить, что оно потерялось и даже не взглянут на него. Основной объем информации, который вы должны предоставить, представляет собой вывод программ, таких, как &man.dmesg.8;, или консольные сообщения, которые обычно появляются в файле /var/log/messages. Не пытайтесь скопировать эту информацию, набрав ее снова; это действительно трудно, и здесь легко сделать ошибку. Чтобы послать содержимое файлов протоколов, сделайте копию файла и воспользуйтесь редактором для того, чтобы обрезать информацию, оставив только относящуюся к делу, либо скопируйте и вставьте текст в ваше сообщение. В случае вывода программ, таких, как dmesg, перенаправьте вывод в файл и включите его в письмо. Например, &prompt.user; dmesg > /tmp/dmesg.out Данная команда перенаправит информацию в файл /tmp/dmesg.out. При использовании операций копирования и вставки учтите, что некоторые такие операции отрицательно сказываются на формате строк. Особенно это стоит учесть при посылке содержимого файлов Makefile, где tab является важным символом. Это довольно часто встречающаяся проблема в базе данных сообщений об ошибках GNATS. В Makefile символы tab меняются на пробелы, или раздражающие =3B escape последовательности. Каких правил этикета стоит придерживаться при ответе на уже существующее сообщение? Пожалуйста, включайте относящийся к теме текст из исходного письма. Сокращайте его до минимума, но не переусердствуйте. Любой, кто не читал исходное сообщение должен суметь понять о чём идёт речь. Это особенно важно для ответов, где исходное сообщение составляло сотни строчек. Отделяйте текст исходного сообщения от текста, добавляемого вами. Чаще всего строчки исходного сообщения предваряются > и пробелом. Отделяйте ваш текст от текста исходного сообщения пустыми строчками. Эти правила помогут сделать ваши сообщения более читабельными. Пожалуйста, убедитесь, что присваивания текста, который вы цитируйте корректны. Люди могут обидеться, если вы присвоите им слова, которые они не писали. Пожалуйста, не пишите ответ в начале. Это значит, что при ответе на сообщения, вставляйте ваши ответы в конец, после текста, копируемого из исходного сообщения. A: Потому что это не соответствует логическому ходу обсуждения. Q: Почему верхнее сообщение осуждает это? (Спасибо Рэнди Бушу (Randy Bush) за шутку.) Повторяющиеся темы в списках рассылки Участие в списках рассылки, как и участие в любом сообществе требует общего базиса для общения. Большое количество рассылок предполагают знание истории Проекта. В частности, существует несколько тем обсуждения, которые возникают у новичков. Обязанность каждого участника не создавать дискуссии на эти темы, тем самым помочь спискам рассылки не отрываться от обсуждаемых тем и обезопасить себя от разгорячённых бесед. Лучший способ предотвратить это - ознакомиться с архивами списков рассылки, чтобы понять, что происходило до этого. В этом случае, незаменимым окажется интерфейс поиска по спискам рассылки. (Если этот способ не принёс результатов, воспользуйтесь вашей любимой поисковой системой). Познакомившись с архивами, вы не только будете знать какие темы обсуждались до этого, а также узнаете какие тенденции общения существуют в данной рассылке, кто является участниками и какова конечная аудитория. Эти вещи довольно хорошо знать перед отправкой письма в любую рассылку, и это касается не только списков рассылки &os;. Нет сомнения, что архивы довольно объёмные и некоторые вопросы повторяются гораздо чаще чем другие, иногда в виде откликов (followups), где тема сообщения уже не соответствует новому положению дел. Тем не менее, старайтесь избегать повторяющихся тем. Что такое велосипедный навес ("Bikeshed")? В литературной нотации, велосипедный навес - это маленький внешний кожух, в который можно поместить один вид двухколёсного транспорта. Тем не менее, на языке &os;, этот термин ("bikeshed") относится к темам, которые достаточно просты, и на которые (почти) каждый может предложить собственное мнение, и часто (почти) каждый его и предлагает. Детали происхождения данного термина более подробно рассмотрены здесь. У вас должно иметься представление о данном понятии перед отправкой письма в любой список рассылки &os;. Bikeshed - это тема разговора, которая будет иметь тенденцию порождать немедленные мета-дискуссии и флэйм. Пожалуйста, помогайте сохранять списки рассылки настолько полезными для многих людей, насколько это возможно путём предотвращения bikeshed. Спасибо. Благодарности &a.grog.email; Первоначальный автор большинства материала по этикету списков рассылки, взятого из статьи Как работать со списком рассылки FreeBSD-questions с максимальной отдачей. &a.linimon.email; Создание черновой версии данного FAQ.
diff --git a/ru_RU.KOI8-R/articles/mh/Makefile b/ru_RU.KOI8-R/articles/mh/Makefile index 301b023763..b4d8cc0657 100644 --- a/ru_RU.KOI8-R/articles/mh/Makefile +++ b/ru_RU.KOI8-R/articles/mh/Makefile @@ -1,21 +1,21 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/mh/Makefile,v 1.3 2005/10/28 17:42:40 gad Exp $ # -# Original revision: r20561 +# Original revision: r39631 # # Article: An MH Primer DOC?= article FORMATS?= html INSTALL_COMPRESSED?=gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/mh/article.xml b/ru_RU.KOI8-R/articles/mh/article.xml index 94595eda98..f523c54521 100644 --- a/ru_RU.KOI8-R/articles/mh/article.xml +++ b/ru_RU.KOI8-R/articles/mh/article.xml @@ -1,814 +1,814 @@
Учебник по <application>MH</application> MattMidboe
matt@garply.com
v1.0, 16 января 1996 &tm-attrib.freebsd; &tm-attrib.opengroup; &tm-attrib.general; $FreeBSD$ В этом документе даются основы работы с MH во FreeBSD Введение MH ведет свою историю с 1977 года, с компании RAND Corporation, где были разработаны основы работы MH. MH не является единой программой для работы с электронной почтой, но подходом к тому, как лучше всего разрабатывать инструменты для чтения электронной почты. Разработчики MH провели большую работу, твердо придерживаясь принципа KISS: Keep It Simple Stupid. Вместо того, чтобы разработать одну большую программу для чтения, отсылки и обработки электронной почты, они написали специальные программы для каждого случая вашей работы с электронной почтой. Некоторым нравится MH по причине его специализации, которую очень проста и естественна. Каждый инструмент в MH выполняет одно действие, но выполняет его очень хорошо. Кроме различных инструментов, которые можно использовать для обработки своей электронной почты, MH прекрасно выполняет работу по сохранению настроек каждого из этих инструментов однообразными и соответствующими друг другу. На самом деле, если вы не совсем понимаете, как что-то должно работать, и какими должны быть аргументы некоторой команды, то вы можете попытаться угадать и окажетесь правы. Каждая команда MH однообразна в обработке конфигурационных файлов и передаче параметров командной строки. Вам полезно будет помнить, что вы всегда можете добавить к команде для вывода опций этой команды. Первым делом вам нужно убедиться, что на вашей машине с FreeBSD установлен пакет MH. Если вы устанавливали систему с компакт-диска, то для установки MH можете выполнить такую команду: &prompt.root; pkg_add /cdrom/packages/mh-6.8.3.tgz Вы увидите, что при этом будет создан каталог /usr/local/lib/mh, а в каталог /usr/local/bin будут добавлены несколько выполнимых файлов. Если вы предпочитаете откомпилировать все самостоятельно, то можете сгрузить исходный код с общедоступного ftp-сервера по адресу ftp.ics.uci.edu или louie.udel.edu. Этот учебник не является полным и подробным описанием того, как работает MH. Он предназначен для того, чтобы вы начали свой путь по дороге к более удобному и эффективному чтению электронной почты. Вы должны прочесть страницы справочной системы по различным командам. Также вас может заинтересовать телеконференция comp.mail.mh. Прочтите FAQ по MH. Лучшим источником информации по MH является книга MH и nmh Джерри Пика: электронная почта для пользователей и программистов. Чтение почты Этот раздел посвящен тому, как использовать команды inc, show, scan, next, prev, rmm, rmf и msgchk. Одной из приятнейших особенностей MH является единообразие интерфейсов программ. При использовании этих программ нужно помнить одну особенность — способ задания списков сообщений. В случае команды inc это не обязательно, но с командами типа show это полезно знать. Список сообщений может иметь вид типа 23 20 16, что будет означать сообщения 23, 20 и 16. Это весьма просто, но можно делать более полезные вещи, типа 23-30, что будет означать все сообщения с 23 до 30. Вы можете также указывать здесь в виде cur:10, что будет действовать на текущее сообщение и на следующие 9 сообщений. Сообщения cur, last и first являются особыми обозначениями, соответствующими текущему, последнему и первому сообщениям в почтовом ящике. <command>inc</command>, <command>msgchk</command>—чтение новой почты или проверка ее наличия Если вы просто наберете inc и нажмете return, то начнете работать с MH. При выполнении команды inc в первый раз, она настроит вашу учетную запись для использования настроек MH по умолчанию и запросит создание каталога Mail в вашем домашнем каталоге. Если у вас имеется почта, ожидающая сгрузки, вы увидите нечто вроде следующего: 29 01/15 Doug White Re: Another Failed to boot problem<<On Mon, 15 J 30 01/16 Jordan K. Hubbar Re: FBSD 2.1<<> Do you want a library instead of 31 01/16 Bruce Evans Re: location of bad144 table<<>> >It would appea 32 01/16 Jordan K. Hubbar Re: video is up<<> Anyway, mrouted won't run, ev 33 01/16 Michael Smith Re: FBSD 2.1<<Nate Williams stands accused of sa Это то же самое, что вы увидите при выполнении команды scan (смотрите ). Если вы просто запустили команду inc без параметров, она проверит ваш компьютер на наличие электронной почты, которая предназначается вам. Многим нравится для получения своей электронной почты использовать протокол POP. MH может работать с ним для получения вашей электронной почты. Вам нужно передать команде inc несколько аргументов командной строки. &prompt.user; inc -host mail.pop.org -user username -norpop Это укажет команде inc на соединение с mail.pop.org для сгрузки вашей электронной почты, а также сообщит о том, что ваше имя пользователя в той системе username. Параметр указывает команде inc на использование обычного POP3 для сгрузки вашей электронной почты. В MH имеется поддержка нескольких разновидностей POP. Более чем вероятно, что вам никогда не придется ими пользоваться. Хотя с inc вы можете выполнять более сложные действия, такие, как проверка файлов и сканирование формата файлов, это позволит вам начать работу. Команда msgchk используется для получения информации о том, есть ли у вас новая почта. msgchk воспринимает те же самые параметры и , что и команда inc. <command>show</command>, <command>next</command> и <command>prev</command>—вывод и передвижение по электронной почте show выводит письмо в вашей текущем почтовом ящике. Как и inc, команда show незатейлива. Если вы просто наберете show и нажмете return, то она выдаст текущее сообщение. Вы можете также указать конкретные номера выводимых сообщений: &prompt.user; show 32 45 56 По этой команде выведутся сообщения с номерами 32, 45 и 56 друг за другом. Пока вы не поменяете действия по умолчанию, команда show в основном выполняет команду more над сообщением электронной почты. next используется для перехода к следующему сообщению, а prev для перехода к предыдущему сообщению. Обе команды подразумевают выполнение команды show, поэтому при переходе к следующему сообщению оно будет автоматически выведено на экран. <command>scan</command>—сканирование ваших сообщений scan выдает краткий список сообщений в вашем текущем почтовом ящике. Вот пример того, что вам выдаст команда scan. 30+ 01/16 Jordan K. Hubbar Re: FBSD 2.1<<> Do you want a library instead of 31 01/16 Bruce Evans Re: location of bad144 table<<>> >It would appea 32 01/16 Jordan K. Hubbar Re: video is up<<> Anyway, mrouted won't run, ev 33 01/16 Michael Smith Re: FBSD 2.1<<Nate Williams stands accused of sa Как и практически все в MH, этот вывод можно настроить. Это обычный формат вывода по умолчанию. В нем дается номер сообщения, дата, отправитель, строка темы и фрагмент начала письма, если он помещается. Знак + означает, что данное сообщение является текущим, так что при выполнении команды show будет выдано именно это сообщение. Одним из полезных параметров для команды scan является . При этом ваши сообщения будут выдаваться в порядке, при котором сообщения с наибольшими номерами следуют первыми, а сообщения с меньшими номерами последними. Другим полезным параметром для scan является чтение из файла. Если вы хотите просканировать почтовый ящик с входящей почтой во FreeBSD без использования команды inc, то это можно сделать командой scan -file /var/mail/username. Это можно сделать с любым файлом в формате mbox. <command>rmm</command> и <command>rmf</command>—удаление текущего сообщения или почтового ящика rmm используется для удаления почтового сообщения. По умолчанию обычно сообщение на самом деле не удаляется, а переименовывается и игнорируется командами MH. Вам нужно периодически просматривать сообщения и физически удалять удаленные сообщения. Команда rmf используется для удаления почтовых ящиков. Она не переименовывает файлы, а действительно их удаляет с диска, так что при использовании этой команды вам нужно быть внимательными. Типичный сеанс чтения с использованием MH Сначала вам нужно получить новую почту командой inc. Так что в командной строке наберите inc и нажмите return. &prompt.user; inc Incorporating new mail into inbox... 36+ 01/19 Stephen L. Lange Request...<<Please remove me as contact for pind 37 01/19 Matt Thomas Re: kern/950: Two PCI bridge chips fail (multipl 38 01/19 Amancio Hasty Jr Re: FreeBSD and VAT<<>>> Bill Fenner said: > In &prompt.user; При этом выдается ваша новая электронная почта, которая была добавлена в ваш почтовый ящик. Так что следующими действиями будут вывод сообщений по команде show и переход от сообщения к сообщению. &prompt.user; show Received: by sashimi.wwa.com (Smail3.1.29.1 #2) id m0tdMZ2-001W2UC; Fri, 19 Jan 96 13:33 CST Date: Fri, 19 Jan 1996 13:33:31 -0600 (CST) From: "Stephen L. Lange" <stvlange@wwa.com> To: matt@garply.com Subject: Request... Message-Id: <Pine.BSD.3.91.960119133211.824A-100000@sashimi.wwa.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please remove me as contact for pindat.com &prompt.user; rmm &prompt.user; next Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8 .6.9) with SMTP id RAA24416; Fri, 19 Jan 1996 17:56:48 GMT Message-Id: <199601191756.RAA24416@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO pro tocol To: hsu@clinet.fi Cc: hackers@FreeBSD.org Subject: Re: kern/950: Two PCI bridge chips fail (multiple multiport ethernet boards) In-Reply-To: Your message of "Fri, 19 Jan 1996 00:18:36 +0100." <199601182318.AA11772@Sysiphos> X-Mailer: exmh version 1.5omega 10/6/94 Date: Fri, 19 Jan 1996 17:56:40 +0000 From: Matt Thomas <matt@lkg.dec.com> Sender: owner-hackers@FreeBSD.org Precedence: bulk This is due to a typo in pcireg.h (to which I am probably the guilty party). По команде rmm было удалено текущее сообщение, а по команде next был выполнен переход к следующему сообщению. Теперь, если я захочу просмотреть десять последних сообщений для чтения одного из них, я должен сделать следующее: &prompt.user; scan last:10 26 01/16 maddy Re: Testing some stuff<<yeah, well, Trinity has 27 01/17 Automatic digest NET-HAPPENINGS Digest - 16 Jan 1996 to 17 Jan 19 28 01/17 Evans A Criswell Re: Hey dude<<>From matt@tempest.garply.com Tue 29 01/16 Karl Heuer need configure/make volunteers<<The FSF is looki 30 01/18 Paul Stephanouk Re: [alt.religion.scientology] Raw Meat (humor)< 31 01/18 Bill Lenherr Re: Linux NIS Solaris<<--- On Thu, 18 Jan 1996 1 34 01/19 John Fieber Re: Stuff for the email section?<<On Fri, 19 Jan 35 01/19 support@foo.garpl [garply.com #1138] parlor<<Hello. This is the Ne 37+ 01/19 Matt Thomas Re: kern/950: Two PCI bridge chips fail (multipl 38 01/19 Amancio Hasty Jr Re: FreeBSD and VAT<<>>> Bill Fenner said: > In &prompt.user; Теперь, если я хочу прочесть сообщение номер 27, я выполняю команду show 27, и сообщение будет показано. Как вы можете видеть на примере этого простого сеанса работы, MH весьма легок в использовании, а просмотр электронной почты и ее вывод интуитивен и прост. Папки и поиск почты Любому, кто получает много электронной почты, определенно требуется сортировать, помечать, сжимать и нумеровать свою электронную почту различными способами. MH может делать это лучше, чем какой-либо другой инструмент. Мы пока еще не обсуждали концепцию папок. Несомненно, вы уже встречались с папками при использовании других почтовых программ. В MH также используются папки. MH может даже создавать в папках вложенные в них папки. При работе с MH вы должны помнить, что при запуске команды inc первый раз она запрашивает создание каталога Mail и начинает сохранять все в этом каталоге. Если вы посмотрите на содержимое этого каталога, то обнаружите там каталог с именем inbox. В этом каталоге находится вся ваша входящая почта, которая не была еще никуда перемещена. При создании новой папки в каталоге программы MH Mail будет создан новый каталог, а сообщения этой папки будут размещаться в этом каталоге. Когда приходит новая электронная почта, то она размещается в каталоге inbox в файле с именем, соответствующим номеру сообщения. Поэтому, даже если у вас нет ни одного инструмента MH для чтения вашей электронной почты, вы можете продолжать использовать стандартные &unix; команды для работы с этими каталогами и просмотра ваших файлов. Такой упрощенный подход на самом деле дает вам простор для действий, которые вы можете выполнять над вашей электронной почтой. Так же, как вы можете использовать список сообщений типа 23 16 42 с большинством команд MH, имеется режим и для папок, который вы можете задать практически с каждой командой MH. Если вы выполняете команду scan +freebsd, она будет сканировать вашу папку freebsd, а ваша текущая папка будет изменена на freebsd. При выполнении команды show +freebsd 23 16 42, show перейдет к вашей папке freebsd и выведет сообщения 23, 16 и 42. Поэтому запомните этот синтаксис . Вам нужно использовать такие команды для работы с разными папками. Помните, что вашей папкой для почты по умолчанию является inbox, так что выполнение команды folder +inbox должно всегда вернуть вас обратно к вашей почте. Конечно, с бесконечной гибкостью MH такое поведение может быть изменено, но в большинстве случаев лучше оставить папку inbox. <command>pick</command>—поиск почты по некоторому критерию Команда pick является одной из более сложных команд в системе MH. Так что вам может понадобиться прочесть справочную страницу по pick1 для его более полного понимания. В простейшем случае вы можете делать нечто вроде следующего: &prompt.user; pick -search pci 15 42 55 56 57 Команде pick будет указано на просмотр каждой строки всех сообщений в текущей папке и выдачу номеров тех сообщений, в которых было найдено слово pci. Затем по команде show вы можете вывести эти сообщения и прочесть их или удалить командой rmm. Вам нужно задать команды типа show 15 42 55-57 для их вывода. Более полезной сделать следующее: &prompt.user; pick -search pci -seq pick 5 hits &prompt.user; show pick При этом будут выведены те же самые сообщения, но вам не придется тратить на них столько усилий. Параметр на самом деле является сокращенным вариантом для , а pick является именем последовательности, которая содержит номера сообщений, которые удовлетворяют заданному условию. Вы можете использовать последовательности практически с любой командой MH. Так что вы можете выполнить команду rmm pick, и все эти сообщения будут удалены. Вы можете именовать последовательности как угодно. Если вы снова выполните команду pick, то она перезапишет старую последовательность, если вы используете то же самое имя. Выполнение команды pick -search может оказаться более длительной операцией, чем просто поиск сообщений от кого-то или для кого-то. Поэтому pick позволяет вам использовать такой предопределенный критерий поиска: поиск по адресату сообщения поиск по содержимому cc-списка поиск по тому, от кого исходит сообщение поиск электронной почты с заданной темой письма поиск электронных писем с указанной датой поиск по любому другому компоненту заголовка письма. (То есть для поиска всех электронных писем с определенным значением поля reply-to в заголовке) Это позволяет вам выполнять действия типа &prompt.user; pick -to freebsd-hackers@FreeBSD.org -seq hackers для получения списка всех электронных писем, посланных в список рассылки FreeBSD hackers. Команда pick также позволяет вам группировать эти критерии различными способами при помощи следующих параметров: … … … … … … Эти команды позволяют вам выполнять следующее &prompt.user; pick -to freebsd-hackers -or -cc freebsd-hackers При этом будет взята вся почта в вашем входящем почтовом ящике inbox, которая была послана по адресу freebsd-hackers или этот адрес присутствовал в cc-списке. Параметры brace позволяют вам группировать критерии поиска. Иногда это очень нужно, как в следующем примере &prompt.user; pick -lbrace -to freebsd-hackers -and -not -cc freebsd-questions -rbrace -and -subject pci В общем, это означает выбрать (во freebsd-hackers и не в cc-списке для freebsd-questions) с темой pci. По этой команде должна быть просмотрена ваша папка и найдены все сообщения, посланные в список freebsd-hackers, которые не были также включены в cc-список для freebsd-questions, и в строке темы которых присутствовало упоминание pci. Теперь вам стоит задуматься о том, что называется порядком выполнения операторов. Помните, как при вычислении значений математических выражений вы начинали слева направо и сначала умножали и делили, и только потом складывали и вычитали? В MH присутствует тот же набор правил для команды pick. Он достаточно сложен, так что вам нужно будет изучить справочную страницу. Этот документ только знакомит с MH. <command>folder</command>, <command>folders</command>, <command>refile</command>—три полезные программы для управления папками Имеются три программы, которые предназначены только для управления вашими папками. Программа folder используется для переключения между папками, их сжатия и вывода их списка. В самом простом случае вы можете выполнить команду folder +newfolder, и вы переключитесь на папку newfolder. С этого момента все ваши команды MH типа comp, repl, scan и show будут выполняться над этой папкой newfolder. Иногда при чтении и удалении сообщений в ваших папках образуются holes. Если вы выполните команду scan, то можете увидеть только сообщения 34, 35, 36, 43, 55, 56, 57, 80. Если вы выполните команду folder -pack, то она перенумерует все ваши сообщения, так что там не будет дыр. Однако она не удаляет никаких сообщений. Так что вам может понадобиться периодически просматривать и физически удалять rmm-сообщения. Если вам нужна информация о ваших папках, вы можете получить ее командами folders или folder -all, которые выводят список всех ваших папок, количество хранящихся в них сообщений, номер текущего сообщения в каждой папке, и так далее. Такая строка статистики, которую выводят эти команды для всех папок, имеет тот же самый вид, что вы получаете при смене папки по команде folder +foldername. Результат выполнения команды folders выглядит примерно так: Folder # of messages ( range ); cur msg (other files) announce has 1 message ( 1- 1). drafts has no messages. f-hackers has 43 messages ( 1- 43). f-questions has 16 messages ( 1- 16). inbox+ has 35 messages ( 1- 38); cur= 37. lists has 8 messages ( 1- 8). netfuture has 1 message ( 1- 1). out has 31 messages ( 1- 31). personal has 6 messages ( 1- 6). todo has 58 messages ( 1- 58); cur= 1. TOTAL= 199 messages in 13 folders. Команду refile нужно использовать для перемещения сообщения между папками. Когда вы выполняете команду типа refile 23 +netfuture, то сообщение номер 23 перемещается в папку netfuture. Вы можете также выполнить команду типа refile 23 +netfuture/latest, которая поместит сообщение номер 23 в папку с именем latest, вложенную в папку netfuture. Если вы хотите сохранить сообщение в текущей папке и связать его, вы можете выполнить команду refile -link 23 +netfuture, которая оставит 23 в вашем текущей папке inbox, но также и в вашей папке netfuture. Наверное, вы уже начали понимать, какие по настоящему мощные действия вы можете выполнять с MH. Посылка почты Электронная почта для большинства людей является улицей с движением в два ряда, так что вы можете захотеть послать что-то обратно. Способ, каким MH выполняет посылку почты, может сначала показаться трудным для использования, но он обеспечивает удивительную гибкость. Сначала MH копирует файл компонентов в исходящую электронную почту. Файл компонентов в основном представляет собой скелет электронного письма с уже помещенными туда заголовками To: и Subject:. Затем вы отсылаетесь к редактору текстов, в котором вы заполняете информацию заголовков и набираете тело письма ниже разделительных строк. При закрытии редактора вызывается программа whatnow. Находясь в приглашении What now?, вы можете выбрать одно из действий send, list, edit, push или quit. Большинство этих команд говорят сами за себя. Итак, процесс посылки сообщения включает копирование файла компонент, редактирование вашей электронной почты и указание программе whatnow действия, которое нужно сделать с вашей электронной почтой. <command>comp</command>, <command>forw</command>, <command>reply</command>—создание, пересылка или ответ на чье-либо сообщение Программа comp имеет несколько полезных параметров командной строки. Самой важной сейчас является опция . При установке MH используемым по умолчанию редактором обычно становится программа prompter, поставляемая с MH. Это не очень привлекательный редактор, он просто делает то, что должен делать. Так что когда вы собираетесь написать кому-либо письмо, вы можете воспользоваться командами comp -editor /usr/bin/vi или comp -editor /usr/local/bin/pico. После запуска comp вы оказываетесь в вашем редакторе и видите нечто вроде следующего: To: cc: Subject: -------- Вам нужно указать персону, которой вы посылаете почту, после строки To:. То же самое относится и к остальным заголовкам, так что вам нужно будет указать тему письма после строки Subject:. Затем вам просто нужно набрать тело письма после разделительной строки. Это может показаться несколько упрощенным, так как многие почтовые программы имеют специальные опросники, которые запрашивают у вас эту информацию, но необходимости в этом нет. Плюс это на самом деле дает вам дополнительную гибкость. To:freebsd-rave@FreeBSD.org cc: Subject:And on the 8th day God created the FreeBSD core team -------- Wow this is an amazing operating system. Thanks! Теперь вы можете сохранить это сообщение и выйти из редактора. Вы увидите приглашение What now? и здесь можете набрать send или s и нажать return. После этого основная группа разработчиков FreeBSD получит свои слова восхищения. Как я отмечал выше, вы можете также воспользоваться другими командами в приглашении What now?. Например, вы можете использовать quit, если не хотите посылать сообщение. Команда forw ошеломляюще похожа. Большим отличием является то, что сообщение, которое вы пересылаете, автоматически включается в исходящее сообщение. Когда вы выполняете команду forw, она будет пересылать ваше текущее сообщение. Вы всегда можете указать на пересылку другого сообщения, выполняя команду forw 23, после чего в исходящее сообщение будет помещено сообщение номер 23, а не текущее сообщение. Кроме этих маленьких различий, команда forw работает абсолютно так же, как comp. Вы проходите через в точности такой же процесс посылки сообщения. По команде repl будет делаться ответ на текущее сообщение, если только вы не указали другой номер сообщения. Команда repl приложит все усилия, чтобы забежать вперед и заполнить некоторые заголовки почтового сообщения. Поэтому вы заметите, что в заголовке To: уже присутствует адрес получателя. Также уже будет заполнена строка Subject:. Затем вы проходите обычный процесс написания сообщения и на этом все завершается. Здесь полезно знать о параметре командной строки . Вы можете использовать параметры all, to, cc и me после для того, чтобы repl автоматически добавила различные адреса к Cc:-списку сообщения. Вы, наверное, заметили, что исходное сообщение не будет включаться. Это происходит, потому что в большинстве настроек MH так указано изначально. Файлы <filename>components</filename> и <filename>replcomps</filename>—файлы компонент для команд <command>comp</command> и <command>repl</command> Файл components обычно располагается в каталоге /usr/local/lib/mh. Вы можете скопировать этот файл в ваш каталог Mail для MH и отредактировать его так, чтобы он содержал то, что вы хотите. Это достаточно простой файл. В начале файла расположены различные почтовые заголовки, разделительная строка и больше ничего. Команда comp просто копирует этот файл components и затем редактирует его. Вы можете добавить любой соответствующий стандарту RFC822 заголовок. Например, в вашем файле components вы можете поместить следующее: To: Fcc: out Subject: X-Mailer: MH 6.8.3 X-Home-Page: http://www.FreeBSD.org/ ------- Тогда MH будет копировать этот файл компонентов и передаст его в ваш редактор. Файл components весьма прост. Если вы хотите в сообщениях иметь подпись, просто поместите вашу подпись в этот файл components. Файл replcomps несколько более сложен. По умолчанию replcomps имеет такой вид: %(lit)%(formataddr %<{reply-to}%?{from}%?{sender}%?{return-path}%>)\ %<(nonnull)%(void(width))%(putaddr To: )\n%>\ %(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\ %<(nonnull)%(void(width))%(putaddr cc: )\n%>\ %<{fcc}Fcc: %{fcc}\n%>\ %<{subject}Subject: Re: %{subject}\n%>\ %<{date}In-reply-to: Your message of "\ %<(nodate{date})%{date}%|%(pretty{date})%>."%<{message-id} %{message-id}%>\n%>\ -------- Он имеет такой же простой формат, как и файл components, но содержит несколько дополнительных форматирующих кодов. Команда %(lit) определяет место для адреса. %(formataddr) является функцией, которая возвращает полный адрес электронной почты. Следующей частью является %<, которая означает условие если и {reply-to} соответствует полю reply-to исходного сообщения. Таким образом, это может быть проинтерпретировано следующим образом: %<if {reply-to} в исходном сообщении имеется поле reply-to то передать его в formataddr, %? else {from} взять адрес from, %? else {sender} взять адрес sender, %? else {return-path} взять return-path из исходного сообщения, %> endif. Как вы можете видеть, форматирование MH может быть достаточно сложным. Вы можете выяснить, что значат остальные функции и переменные. Вся информация по написанию строк в таком формате находится в справочной странице по MH. Действительно удобной вещью является то, что единожды создав собственный файл replcomps, вам не нужно больше его трогать. Ни одна другая почтовая программа не даст вам той мощи и гибкости, что дает вам MH.
diff --git a/ru_RU.KOI8-R/articles/new-users/article.xml b/ru_RU.KOI8-R/articles/new-users/article.xml index 8888bec7a1..afa7c6c439 100644 --- a/ru_RU.KOI8-R/articles/new-users/article.xml +++ b/ru_RU.KOI8-R/articles/new-users/article.xml @@ -1,1025 +1,1025 @@
Пособие для новичков во FreeBSD и &unix; AnneliseAnderson
andrsn@andrsn.stanford.edu
 15 августа 1997 &tm-attrib.freebsd; &tm-attrib.ibm; &tm-attrib.microsoft; &tm-attrib.opengroup; &tm-attrib.general; $FreeBSD$ Поздравляем вас с установкой FreeBSD! Это вводное пособие предназначено для тех, кто является новичком в мире FreeBSD и &unix;—так что оно начнётся с основ. Предполагается, что вы используете дистрибутив &os; версии 2.0.5 или более поздней, распространяемый &os;.org, и в вашей системе (на данный момент) имеется один пользователь (это вы)—и вы хорошо ориентируетесь в DOS/&windows; или &os2;. Регистрация в системе и выход из неё Зарегистрируйтесь в системе (когда увидите приглашение login:) как пользователь, которого вы создали во время установки, или войдите в систему как пользователь root. (В вашей установленной системе уже имеется учётная запись для пользователя root; который может переходить хоть куда и делать всё, что угодно, в том числе удаление необходимых для работы файлов, так что будьте внимательны!) Обозначения &prompt.user; и &prompt.root; в последующем тексте означают приглашения системы (ваше может отличаться от него), причём &prompt.user; обозначает обычного пользователя, а &prompt.root; пользователя root. Чтобы выйти из системы (и получить новое приглашение login:) наберите &prompt.root; exit столько раз, сколько нужно. Да, нажимайте enter после набора команд, и помните, что &unix; чувствителен к регистру букв—набирайте exit, но не EXIT. Для завершения работы машины наберите &prompt.root; /sbin/shutdown -h now Или, для перезагрузки нужно набрать &prompt.root; /sbin/shutdown -r now или &prompt.root; /sbin/reboot Перезагрузку можно также выполнить нажатием клавиш CtrlAlt Delete. Подождите некоторое время, чтобы дать этой команде отработать. В последних релизах FreeBSD она эквивалента выдаче команды /sbin/reboot и гораздо, гораздо лучше, чем нажатие кнопки сброса. Вы ведь не хотите всё переустанавливать заново, не так ли? Добавление пользователя с привилегиями root Если при установке системы вы не создали ни одного пользователя, и поэтому вошли в систему как root, то теперь вы должны создать пользователя по команде &prompt.root; adduser При первом использовании утилиты adduser она может запрашивать сохранение некоторых параметров для использования их по умолчанию. вы можете сделать оболочкой, используемой по умолчанию, командный процессор &man.csh.1;, а не &man.sh.1;, если по умолчанию вам предлагается sh. В противном случае просто нажимайте enter для принятия всех предлагаемых по умолчанию вариантов. Эти значения по умолчанию сохраняются в файле /etc/adduser.conf, в форме, доступной для редактирования. Предположим, что вы создали пользователя jack с полным именем Jack Benimble. Назначьте пользователю jack пароль, если информационная безопасность имеет значение (даже если это дети, которые могут стучать по клавиатуре). Когда вам будет задан вопрос по включению пользователя jack в другие группы, наберите wheel Login group is ``jack''. Invite jack into other groups: wheel Это позволит входить в систему как пользователь jack и использовать команду &man.su.1; для того, чтобы стать пользователем root. Тогда вас не будут больше обвинять в том, чтобы вы входите в систему как пользователь root. Вы можете прекратить работы с adduser в любой момент, нажав Ctrl C, а в завершении ввода у вас будет шанс подтвердить заведение нового пользователя или набрать n в качестве отрицательного ответа. Вам может захотеться создать второго нового пользователя, для того, чтобы при редактировании файлов для входа пользователя jack имелся горячий резерв на тот случай, если что-то пойдёт не так. После того, как вы это сделаете, воспользуйтесь командой exit для возврата к приглашению ко входу в систему и зарегистрируйтесь в ней как пользователь jack. Вообще говоря, лучше всего основную массу работы выполнять, работая как обычный пользователь, который не имеет мощь и опасность пользователя root. Если вы уже создали пользователя и хотите, чтобы он мог выполнять команду su для получения привилегий root, вы можете войти в систему как root и отредактировать файл /etc/group, добавив пользователя jack в первую строчку (в группу wheel). Однако сначала вам нужно поупражняться с программой &man.vi.1;, текстовым редактором,—или использовать более простой редактор, &man.ee.1;, имеющийся в последней версии FreeBSD. Для удаления пользователя воспользуйтесь командой rmuser. Просмотр окружения Войдя в систему как обычный пользователь, оглянитесь вокруг и попробуйте выполнить некоторые команды, дающие доступ к источникам информации и помощи внутри FreeBSD. Вот некоторые команды и то, что они делают: id Говорит вам, кто вы! pwd Показывает, где вы находитесь—текущий рабочий каталог. ls Выдаёт список файлов, находящихся в текущем каталоге. ls -F Выдаёт перечень файлов, находящихся в текущем каталоге, добавляя символы * после выполнимых файлов, / после каталогов и @ после символических ссылок. ls -l Выдаёт перечень файлов в расширенном формате—размер, дата и права доступа. ls -a Вместе со всеми выдаёт и список скрытых dot-файлов (начинающихся с точки). Если вы являетесь пользователем root, то dot-файлы выдаются и без указания флага . cd Смена каталогов. cd .. перемещает на один уровень выше; обратите внимание на промежуток после cd. cd /usr/local перейдёт в указанное место. cd ~ перейдёт в домашний каталог человека, который вошёл в систему—к примеру, /usr/home/jack. попробуйте выполнить команду cd /cdrom, а затем ls для проверки того, что ваш CDROM смонтирован и работает. view filename Позволяет вам просмотреть файл (с именем filename) без внесения в него изменений. Попробуйте выполнить команду view /etc/fstab. Для выхода наберите :q. cat filename Выдаёт содержимое filename на экран. если он слишком длинный и вы можете увидеть только его конец, нажмите ScrollLock и используйте клавишу стрелка вверх для движения назад; вы можете также использовать ScrollLock и со страницами справки. Нажмите ScrollLock снова для прекращения прокрутки. Вам может захотеться попробовать команду cat с некоторыми из dot-файлов в вашем домашнем каталоге—cat .cshrc, cat .login, cat .profile. В файле .cshrc вы заметите алиасы для некоторых из команд ls (они очень удобны). Вы можете создать другие алиасы, отредактировав файл .cshrc. Вы можете сделать эти алиасы доступными всем пользователям системы, поместив их в общесистемный конфигурационный файл для csh, /etc/csh.cshrc. Получение помощи и информации Вот несколько полезных источников получения помощи. Здесь Text обозначает что-то по вашему выбору, что вы вводите—обычно команду или имя файла. apropos text Всё, что содержит строку text в базе whatis. man text Страница справки по text. Это главный источник документации в &unix;-системах. man ls покажет вам все способы использования команды ls. Нажимайте Enter для передвижения по тексту, CtrlB для возврата на страницу назад, CtrlF для продвижения вперёд, q или CtrlC для выхода. which text Покажет, в каком месте из маршрута поиска пользователя находится команда text. locate text Все маршруты, где находится строчка text. whatis text Описывает, что делает команда text и её справочная страница. Команда whatis * расскажет вам обо всех двоичных файлах в текущем каталоге. whereis text Ищет файл text и выдаёт полный путь до него. Вы можете захотеть попробовать использоваться команду whatis с некоторыми полезными командами типа cat, more, grep, mv, find, tar, chmod, chown, date, и script. Команда more позволит вам читать постранично, как и в DOS, например, ls -l | more или more filename. Знак * работает как общий шаблон—например, ls w* выдаст перечень файлов, начинающихся с буквы w. Некоторые из этих команд работают не очень хорошо? Обе команды &man.locate.1; и &man.whatis.1; зависят от базы данных, которая перестраивается еженедельно. Если ваша машина будет оставаться включенной на выходные (и она работает под FreeBSD), то вы можете пожелать запускать определённые команды раз в день, неделю, месяц. Запускайте их как root и дайте каждой отработать, прежде чем запускать следующую. &prompt.root; periodic daily выдача опущена &prompt.root; periodic weekly выдача опущена &prompt.root; periodic monthly выдача опущена Если вам надоело ждать, нажмите AltF2 для перехода в другую виртуальную консоль, и войдите в систему снова. В конце концов, это многопользовательская и многозадачная система. Тем не менее эти команды, скорее всего, в процессе работы будут выдавать сообщения вам на экран; вы можете набрать clear в приглашении для очистки экрана. Пока они работают, вы можете смотреть в содержимое файлов /var/mail/root и /var/log/messages. Выполнение таких команд является частью системного администрирования—и как единственный пользователь &unix;-системы вы являетесь собственным системным администратором. Практически всё, для чего вам нужно быть пользователем root, это системное администрирование. Эти обязанности не описываются достаточно хорошо даже в тех больших толстых книгах по &unix;, в которых слишком много места отдаётся описанию работы с меню в оконных менеджерах. Вам может понадобиться одна из двух лучших книг по системному администрированию, либо автора Эви Немет UNIX System Administration Handbook (Prentice-Hall, 1995, ISBN 0-13-15051-7)—второе издание с красной обложкой; или автора Æleen Frisch Essential System Administration (O'Reilly & Associates, 2002, ISBN 0-596-00343-9). Я использую книгу Немет. Редактирование текста Для конфигурации вашей системы вам нужно редактировать текстовые файлы. Большинство из них будут находиться в каталоге /etc; и вам необходимо командой su получить полномочия пользователя root, чтобы их править. Вы можете использовать простой редактор ee, однако в смысле перспективности лучше изучить текстовый редактор vi. В каталоге /usr/src/contrib/nvi/docs/tutorial есть прекрасный учебник по vi, если у вас есть исходники системы. Перед тем, как редактировать файл, наверное, вы должны сохранить резервную копию. Предположим, что вы собираетесь отредактировать файл /etc/rc.conf. Вы можете воспользоваться командой cd /etc для перехода в каталог /etc и выполнить следующее: &prompt.root; cp rc.conf rc.conf.orig При этом файл rc.conf скопируется в rc.conf.orig, и в последующем вы сможете скопировать rc.conf.orig в файл rc.conf для восстановления оригинала. Но ещё лучше его переместить (переименовать), после чего скопировать обратно: &prompt.root; mv rc.conf rc.conf.orig &prompt.root; cp rc.conf.orig rc.conf потому что команда mv сохраняет исходную информацию о дате и владельце файла. Теперь вы можете редактировать rc.conf. Если вы захотите восстановить исходное состояние, то выполните mv rc.conf rc.conf.myedit (полагаем, что вы хотите сохранить отредактированную версию), а затем &prompt.root; mv rc.conf.orig rc.conf для возврата всего на место. Для редактирования файла наберите &prompt.root; vi filename Передвигайтесь по тексту при помощи клавиш со стрелками. Esc (клавиша отмены) переводит редактор vi в командный режим. Вот некоторые из них: x удалить символ, на котором находится курсор dd удалить целую строку (даже если на экране она не помещается в целую строку) i вставка текста в позиции курсора a вставка текста после курсора Сразу после набора i или a вы можете вводить текст. Esc возвратит вас обратно в командный режим, где вы можете набрать :w для записи ваших изменений на диск и продолжения редактирования :wq для записи и выхода :q! для выхода без сохранения изменений /text для перемещения курсора на text; /Enter (клавиша ввода) для поиска следующего экземпляра text. G для перехода в конец файла nG Для перехода к строке n в файле, где n является числом CtrlL для перерисовки экрана Ctrlb и Ctrlf для перемотки на экран назад и вперёд, как при работе с more и view. Поупражняйтесь с редактором vi в своём домашнем каталоге, создав новый файл по команде vi filename, добавляя и удаляя текст, сохраняя файл и вызывая его снова. Редактор vi преподносит некоторые сюрпризы, потому что он на самом деле достаточно сложный, и иногда вы можете неправильно вызвать команду, которая сделает нечто, чего вы не ожидали. (Некоторым людям действительно нравится vi—он более мощный, чем EDIT из DOS—посмотрите команду :r.) Для того, чтобы удостовериться, что вы находитесь в режиме команд, нажимайте Esc один или несколько раз, и начинайте снова с этого места, если возникли какие-то проблемы, часто сохраняйте текст командой :w и используйте :q! для того, чтобы прекратить работу и начать всё сначала (с вашей последней команды :w), если это нужно. Теперь вы можете выполнить cd для перехода в каталог /etc, su в пользователя root, использовать vi для редактирования файла /etc/group и добавлять пользователя в группу wheel, чтобы он имел полномочия пользователя root. Просто добавьте запятую и имя входа пользователя в конце первой строки этого файла, нажмите Esc и воспользуйтесь :wq для записи файла на диск и выхода. Работает всегда. (Вы не поставили пробел после запятой, ведь так?) Печать файлов из DOS На данный момент, скорее всего, принтер у вас не работает, так что вот способ создания файла из справочной страницы, перемещения её на дискету, а затем печать из DOS. Положим, что вы хотите внимательно прочесть об изменении прав доступа на файлы (весьма важно). Вы можете воспользоваться командой man chmod для того, чтобы прочесть об этом. Команда &prompt.user; man chmod | col -b > chmod.txt удалит коды форматирования и перенаправит страницу справки в файл chmod.txt, не выдавая её на экран. Теперь поместите отформатированную dos-дискету в дисковод a, выполните su, перейдя к пользователю root, и наберите &prompt.root; /sbin/mount -t msdosfs /dev/fd0 /mnt для монтирования дискеты в каталог /mnt. Теперь (и вам больше не нужно быть пользователем root, так что можете набрать exit для возврата к пользователю jack) вы можете перейти в каталог, где создали chmod.txt и скопировать файл на дискету следующей командой: &prompt.user; cp chmod.txt /mnt и воспользоваться командой ls /mnt для получения списка файлов каталога /mnt, которая теперь должна показать файл chmod.txt. Вы также можете захотеть создать файл из /sbin/dmesg, набрав &prompt.user; /sbin/dmesg > dmesg.txt и скопировав dmesg.txt на дискету. /sbin/dmesg является протоколом загрузки системы, который полезно понимать, потому что в нём перечисляется всё, что обнаружила при загрузке FreeBSD. Если вы будете задавать вопросы в списке рассылки &a.questions; или в конференции USENET—наподобие FreeBSD не обнаруживает моего ленточного накопителя, что мне делать?—отвечающие захотят узнать, что выдаёт dmesg. Теперь вы можете (как root) отмонтировать гибкий диск, чтобы его вынуть, по команде &prompt.root; /sbin/umount /mnt и перезагрузиться в DOS. Скопируйте эти файлы в каталог DOS, вызовите их при помощи редактора DOS EDIT, &windows; Notepad или Wordpad, или даже с текстовым процессором, внесите маленькое изменение, чтобы файл сохранился, и напечатайте его обычным образом из DOS или Windows. Надеемся, это срабатывает! Справочные страницы лучше всего выглядят при печати командой DOS print. (Копирование файлов из FreeBSD на смонтированный раздел DOS в некоторых случаях всё ещё немного рискованная операция.) Процесс настройки принтера на печать из FreeBSD включает в себя создание соответствующей записи в файле /etc/printcap и создание нужного каталога очереди в /var/spool/output. Если ваш принтер подключен к lpt0 (то, что в DOS называется LPT1), то вам достаточно только перейти в каталог /var/spool/output и (как root) создать каталог lpd, набрав: mkdir lpd, если её ещё не существует. Тогда принтер должен реагировать, если при загрузке системы он включён, а команда lp или lpr должны посылать файл на принтер. Будет ли файл действительно напечатан, зависит от его настройки, каковая описана в Руководстве FreeBSD. Другие полезные команды df выдаёт данные о занятом файлами пространстве и смонтированных файловых системах. ps aux показывает работающие процессы. ps ax является частоупотребительной формой. rm filename удаляет filename. rm -R dir удаляет каталог dir и все его подкаталоги—осторожно! ls -R выдаёт список файлов в текущем каталоге и всех его подкаталогах; я использовал вариант, ls -AFR > where.txt, для получения перечня всех файлов в / и (отдельно) /usr до того, как узнал о более эффективном способе поиска файлов. passwd для изменения пароля пользователя (или пароля root) man hier справочная страница по файловой структуре &unix; Используйте find для поиска filename в /usr или в любом из её подкаталогов при помощи команды &prompt.user; find /usr -name "filename" Вы можете использовать * в качестве шаблона внутри "filename" (это выражение должно быть в кавычках). Если вы укажете команде find на поиск в /, а не в /usr, то она будет искать файл(ы) во всех смонтированных файловых системах, включая CDROM и раздел DOS. Прекрасным пособием, описывающим команды и утилиты &unix;, является книга Abrahams & Larson, Unix for the Impatient (2nd ed., Addison-Wesley, 1996). Масса информации по &unix; есть и в Internet. Следующие шаги Теперь вы должны иметь инструменты, которые необходимо держать под рукой и умеете редактировать файлы, так что вы должны суметь запустить всё, что угодно. Много полезной информации содержится в Руководстве по FreeBSD (которое, скорее всего, есть на вашем жёстком диске) и Web-сайте FreeBSD. На CDROM, а также Web-сайте находятся различные пакеты и порты. В Руководстве рассказывается более подробно о том, как их использовать (получить пакет, если он существует, командой pkg_add /cdrom/packages/All/packagename, где packagename является именем файла пакета). На CDROM находится перечни пакетов и портов с их краткими описаниями в файлах cdrom/packages/index, cdrom/packages/index.txt и cdrom/ports/index, а более полные описания можно найти в /cdrom/ports/*/*/pkg/DESCR, где знаки * обозначают тематические подкаталоги с программами и названиями программ, соответственно. Если вы посчитаете, что Руководство является слишком сложной книгой (что с lndir и всё) по установке портов с CDROM, вот рецепт, который обычно срабатывает: Найдите нужный вам порт, скажем, kermit. На CDROM для него должен существовать каталог. Скопируйте этот подкаталог в каталог /usr/local (хорошее место для программного обеспечения, которое вы добавляете, и которое должно быть доступно всем пользователям) такой командой: &prompt.root; cp -R /cdrom/ports/comm/kermit /usr/local В результате должен образоваться подкаталог /usr/local/kermit, содержащий все файлы, что есть в подкаталоге kermit на CDROM. Затем создайте каталог /usr/ports/distfiles, если он ещё не существует, при помощи команды mkdir. Теперь проверьте содержимое /cdrom/ports/distfiles на предмет наличия файла с именем, говорящем о том, что это тот порт, который вы хотите иметь. Скопируйте этот файл в каталог /usr/ports/distfiles; в последних версиях вы можете пропустить этот шаг, и FreeBSD выполнит его за вас. В случае с kermit, дистрибутивного файла не существует. После этого по команде cd перейдите в подкаталог /usr/local/kermit, в котором есть файл Makefile. Наберите &prompt.root; make all install Во время выполнения порт обратится к FTP для получения всех архивных файлов, нужных ему и которых не найдено на CDROM или в каталоге /usr/ports/distfiles. Если сеть у вас ещё не работает, и файла для порта в каталоге /cdrom/ports/distfiles нет, вам потребуется получить дистрибутивный файл на другой машине и скопировать его в каталог /usr/ports/distfiles. Прочтите Makefile (при помощи команд cat, more или view), чтобы понять, как называется файл и куда нужно обратиться (основной сайт распространения), чтобы его получить. (Используйте двоичный тип передачи файлов!) Затем перейдите обратно в каталог /usr/local/kermit, найдите каталог с Makefile и наберите make all install. Ещё одной проблемой, встречающейся при установке портов или пакетов, является их потребность в какой-то другой программе. После того, как установка будет выполнена, наберите команду rehash для того, чтобы заставить FreeBSD перечитать файлы, находящиеся в маршрутах поиска, чтобы система обнаружила их появление. (Если вы получили массу сообщений path not found при использовании whereis или which, то вам необходимо сделать добавления к перечню каталогов в команде определения маршрута в файле .cshrc, находящемся а вашем домашнем каталоге. Задание маршрута в &unix; несёт ту же самую функцию, что и в DOS, за исключением работы с текущим каталогом (по умолчанию) по соображениям безопасности; если команда, которую вы хотите выполнить, находится в текущем каталоге, вам нужно набирать ./ перед названием команды, чтобы она заработала; пробелов после слэша ставить не нужно.) Ваше рабочее окружение Ваш командный процессор является самой важной частью вашего рабочего окружения. В DOS обычной оболочкой является command.com. Оболочка занимается интерпретацией команд, которые вы вводите в командной строке, и таким образом взаимодействует с остальной частью операционной системы. Вы можете также писать скрипты командного процессора, которые похожи на .bat-файлы DOS: это последовательности команд, которые должны выполняться без вашего участия. Вместе с FreeBSD устанавливаются два командный процессора: csh и sh. csh хорош для работы в командной строке, однако скрипты должны писаться на языке оболочек sh (или bash). Вы можете выяснить, какой командный процессор у вас используется, набрав echo $SHELL. Оболочка csh подходящая, однако tcsh может всё, что умеет csh и ещё больше. Она позволяет вам восстанавливать прошлые команды клавишами со стрелками и редактировать их. В нём есть автозавершение имён файлов по нажатию клавиши табуляции (в csh используется клавиша Esc) и он позволяет вам переключаться в каталог, в котором вы были ранее, по команде cd -. Также в tcsh гораздо легче изменять системное приглашение. Это гораздо упрощает жизнь. Вот три шага по установке нового командного процессора: Установите командный процессор как порт или пакет, как вы обычно это делаете с другим портом или пакетом. Используйте rehash и which tcsh (предполагается, что вы устанавливаете tcsh) для проверки того, что командный процессор установлен. Работая как пользователь root, отредактируйте файл /etc/shells, добавив в него строку с новой оболочкой, в нашем случае это /usr/local/bin/tcsh, и сохраните файл. (Некоторые порты могут делать это за вас.) Воспользуйтесь командой chsh для смены постоянно используемой вами оболочки на tcsh, либо наберите tcsh в командной строке для смены вашей оболочки без повторного входа в систему. Менять командный процессор для пользователя root на что-то, отличающееся от sh или csh, в ранних версиях FreeBSD и во многих других версиях &unix; может быть опасно; вы можете лишиться работающей оболочки при переходе системы в однопользовательский режим. Решением является использование su -m для того, чтобы стать пользователем root, что даст в качестве оболочки tcsh, но вы будете являться пользователем root, потому что оболочка является частью окружения. Вы можете сделать это постоянным, добавив в ваш файл .tcshrc в качестве алиаса по такой команде: alias su su -m При запуске tcsh он будет считывать файлы /etc/csh.cshrc и /etc/csh.login, как и csh. Эта оболочка также читает файл .login из вашего домашнего каталога, а также файл .cshrc, если только вы не создали файл .tcshrc. Это вы можете сделать простым копированием файла .cshrc в .tcshrc. Теперь, когда у вас установлен командный процессор tcsh, вы можете настроить приглашение командной строки. Все подробности можно найти на странице справки по tcsh, но всё же вот строка, которая помещается в ваш файл .tcshrc, которая может показать, сколько команд вы уже набрали, сколько сейчас времени и в каком каталоге вы находитесь. Она также выдаёт >, если вы являетесь обычным пользователем, и #, если вы являетесь пользователем root, однако tsch будет делать это в любом случае: set prompt = "%h %t %~ %# " Эта строка должна быть поставлена на то же самое место, что и существующая строка установки приглашения, если она есть, либо после строки "if($?prompt) then", если её нет. Закомментируйте старую строку; вы всегда сможете вернуться к ней обратно, если предпочтёте её. Не забудьте о пробелах и кавычках. Вы можете заставить перечитать .tcshrc, набрав source .tcshrc. Перечень других установленных переменных окружения вы можете получить, набрав env в приглашении командной строки. В результате, кроме всего прочего, будут показаны редактор, используемый по умолчанию, программа постраничной выдачи и тип терминала. Командой, полезной при входе в систему с удалённого места и невозможности запуска программы, потому что терминал не обладает некоторыми возможностями, является команда setenv TERM vt100. Остальное Работая как пользователь root, вы можете отмонтировать CDROM по команде /sbin/umount /cdrom, вытащить его из привода, вставить другой диск и смонтировать его командой /sbin/mount_cd9660 /dev/cd0a /cdrom, при этом предполагается, что cd0a является именем устройства для вашего привода CDROM. Самые последние версии FreeBSD позволяют вам монтировать CDROM просто по команде /sbin/mount /cdrom. Использование живой файловой системы—она находится на втором диске FreeBSD из набора CDROM—полезно при нехватке пространства. То, что находится в этой файловой системе, меняется от релиза к релизу. Вы можете попытаться поиграть в игры с CDROM. При этом применяется команда lndir, которая устанавливается с X Window System, и служит для указания программам, где искать необходимые файлы, потому что они находятся в файловой системе /cdrom, а не в /usr и её подкаталогах, где должны находиться. Прочтите справку по команде man lndir. Пожелания приветствуются Если вы используете это руководство, мне будет интересно знать, в каком месте оно написано непонятно и что упущено из того, что, по вашему мнению, должно быть включено ценного. Мои благодарности Eugene W. Stark, профессору информатики в SUNY-Stony Brook, и John Fieber за ценные советы. Annelise Anderson, andrsn@andrsn.stanford.edu
diff --git a/ru_RU.KOI8-R/articles/pr-guidelines/Makefile b/ru_RU.KOI8-R/articles/pr-guidelines/Makefile index 9a6a8bd72d..f59d51705b 100644 --- a/ru_RU.KOI8-R/articles/pr-guidelines/Makefile +++ b/ru_RU.KOI8-R/articles/pr-guidelines/Makefile @@ -1,23 +1,23 @@ # The FreeBSD Russian Documentation Project # # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/pr-guidelines/Makefile,v 1.2 2006/04/05 07:17:02 gad Exp $ # $FreeBSD$ # # Article: Problem Report Handling Guidelines # -# Original revision: r21827 +# Original revision: r39631 DOC?= article FORMATS?= html WITH_ARTICLE_TOC?= YES INSTALL_COMPRESSED?=gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/pr-guidelines/article.xml b/ru_RU.KOI8-R/articles/pr-guidelines/article.xml index 186e2d84d6..b9baf5b16a 100644 --- a/ru_RU.KOI8-R/articles/pr-guidelines/article.xml +++ b/ru_RU.KOI8-R/articles/pr-guidelines/article.xml @@ -1,1100 +1,1100 @@
Рекомендации по работе с сообщениями о проблемах &tm-attrib.freebsd; &tm-attrib.opengroup; &tm-attrib.general; $FreeBSD$ $FreeBSD$ Это руководство описывает рекомендуемую практику обработки сообщений об ошибках FreeBSD (Problem Reports - PR). Хотя эти рекомендации предназначены для Группы поддержки базы данных сообщений о проблемах FreeBSD (PR Database Maintenance Team) freebsd-bugbusters@FreeBSD.org, им должны следовать все, кто работает с этими сообщениями. Dag-ErlingSmørgrav HitenPandya
Введение GNATS является системой управления неисправностями (сообщениями об ошибках), которая используется в Проекте FreeBSD. Так как тщательное отслеживание заметных изъянов в программном обеспечении важно для обеспечения качества FreeBSD, правильное использование GNATS необходимо для дальнейшего развития Проекта. Доступ к GNATS даётся разработчикам FreeBSD, а также более широкому сообществу. Для того, чтобы поддерживать целостность базы данных и единства работы с пользователями, были выработаны рекомендации, покрывающие общие вопросы управления проблемами, такие, как написание отклика, обработку уже закрытых вопросов и так далее.
Жизненный цикл сообщения о проблеме Респондент посылает PR при помощи утилиты &man.send-pr.1; и получает подтверждающее сообщение. Среднестатистический коммиттер (Вася) проявляет интерес к PR и назначает его самому себе, или другой любитель ошибок (Петя) решает, что лучше всех с описанной проблемой справится именно Вася, и назначает её Васе. Вася связывается с Респондентом (при этом вся переписка должна фиксироваться) и выясняет причину появления проблемы. Затем он документирует причину в журнале аудита, и переводит PR в состояние analyzed (проанализировано). Вася проводит бессонную ночь и выпускает патч, который, по его мнению, решает означенную проблему, и затем посылает её ответом, прося Респондента протестировать его. Затем он переводит PR в состояние feedback. Через несколько таких итераций Вася и Респондент удовлетворяются получающимся патчем, и Вася переносит его в дерево -CURRENT (или непосредственно в -STABLE, если этой проблемы в -CURRENT не наблюдается), при этом при выполнении коммита в сопутствующем сообщении делается ссылка на сообщение о проблеме (а также упоминается Респондент, если он предоставил весь или часть патча), и, если это нужно, начинается отсчёт для MFC. Если патчу не нужно выполнение MFC, Вася закрывает PR. Если патч требует выполнения MFC, Вася оставляет Сообщение о проблеме в состоянии patched до выполнения операции MFC, а затем закрывает его. Многие PR присылаются с очень слабым описанием проблемы, а некоторые из них либо очень сложно решить, либо являются вершиной айсберга другой, более широкой проблемы; в этих случаях очень важно получить всю информацию, требуемую для решения проблемы. Если описанная проблема не может быть решена, или проявится снова, необходимо повторно открыть PR. Адрес электронной почты может оказаться недоступным. В этом случае ответьте на PR обычным образом и попросите Респондента (в своём сообщении) предоставить рабочий адрес электронной почты. Обычно это происходит в случаях использования &man.send-pr.1; в системах с выключенной или неустановленной почтовой системой.
Состояние сообщений о проблемах При выполнении некоторых действий очень важно обновлять состояние PR. Это состояние должно в точности отражать текущее состояние работы над PR. Маленький пример того, когда именно нужно менять состояние PR Когда PR находится в работе и ответственный разработчик(и) удовлетворён получающимся решением, то он отвечает на PR и меняет его состояние на feedback. В этот момент Респондент должен изучить исправление в своей ситуации и ответить, действительно ли был устранён дефект. Сообщение о проблеме может находится в одном из следующих состояний: open Начальное состояние; проблема была поставлена и её необходимо рассмотреть. analyzed Проблема была рассмотрена, ищется её решение. feedback Дальнейшая работа требует дополнительной информации от Респондента или сообщества; возможно помещение информации о предлагаемом решении. patched Патч был перенесён в дерево исходных текстов, но что-то (выполнение MFC или, возможно, подтверждение Респондента) ещё требуется доделать. suspended Работа над проблемой была остановлена из-за отсутствия информации или необходимых ресурсов. Это первый кандидат для тех, кто ищет проект для работы над ним. Если проблема вообще не может быть решена, она будет закрыта, а не приостановлена. Проект создания документации использует suspended для желательных нововведений, которые требуют значительной работы, для которой ни у кого пока нет времени. repocopy (устаревшее) Решение проблемы зависит от завершения операции копирования репозитория (внутренние операции репозитория CVS). Учитывая то, что на данный момент все репозитории используют Subversion, в этом состоянии более нет необходимости. В Subversion изначально присутствуют операции копирования и перемещения файлов. closed Сообщение о проблеме было закрыто, когда все изменения были перенесены, задокументированы и протестированы, либо когда исправление проблемы было отвергнуто. Состояние patched напрямую связано с предлагаемыми решениями, так что вы можете перейти сразу к состоянию closed, если Респондент не может протестировать патч, либо на ваших тестовых прогонах он работает.
Типы сообщений о проблемах При обработке сообщений об ошибках, либо в качестве разработчика, имеющего непосредственный доступ к базе данных GNATS, либо в качестве контрибутора, который просматривает базу данных и посылает свои отклики с патчами, комментариями, пожеланиями или запросами на изменение, вы будете иметь дело с несколькими различными типами PR. Никому неназначенные PR. PR, которые уже кому-то назначены. Повторы существующих PR. Заброшенные PR Некорректные PR В последующих разделах описывается, для чего предназначены те или иные типы PR, условия отнесения PR к одному из этих типов, и какую обработку требует каждый из этих типов.
Неназначенные PR По прибытии сообщениям о проблемах устанавливаются общие назначения (generic assignee). Они всегда предваряются префиксом freebsd-. Точное название назначения (assignee) зависит от категории и в большинстве случаев оно соответствует определенному списку рассылки &os;. Далее следует текущий перечень назначений (assignee), составленный в порядке от общих к частным: Назначения по умолчанию — наиболее общие Тип Категория Назначение по умолчанию базовая система bin, conf, gnu, kern, misc freebsd-bugs специфичные для архитектуры alpha, amd64, arm, i386, ia64, powerpc, sparc64 freebsd-arch коллекция портов ports freebsd-ports-bugs документация, поставляемая с системой docs freebsd-doc страницы сайта &os; (за исключением документации) www freebsd-www
Назначения по умолчанию — остальные Тип Категория Назначение по умолчанию в защиту &os; (advocacy efforts) advocacy freebsd-advocacy проблемы с &java.virtual.machine; java freebsd-java соответствие стандартам standards freebsd-standards тредовые библиотеки threads freebsd-threads подсистема &man.usb.4; usb freebsd-usb
Не удивляйтесь, если обнаружите, что автор PR присвоил ему неправильную категорию. Если вы исправите категорию, то не забудьте также подправить и назначение. (В частности, для посылающих PR является трудностью понять, что если проблема возникает на системе с архитектурой i386, то она также может быть общей для всех архитектур &os;, и поэтому более подходящей будет категория kern. Несомненно, обратное также справедливо). Назначения некоторых PR могут быть переопределены из общих любым лицом, имеющим соответствующие привилегии. Существует несколько типов назначений: специализированные списки рассылки; почтовые алиасы (расширяемые в списки электронных адресов заинтересованных людей) и назначения отдельным лицам. Если назначением является список рассылки, пожалуйста, выполняя переназначение, используйте длинную форму (например, freebsd-foo вместо foo); благодаря этому сообщение, посылаемое в список рассылки, не будет дублироваться. Так как список лиц добровольно согласившихся принимать назначения для некоторых типов PR изменяется часто, то наиболее подходящим местом для его размещения является FreeBSD wiki. Ниже приведен (возможно, неполный) перечень назначений. Общие назначения — базовая система Тип Предполагаемая категория Предполагаемое назначение Тип назначения проблема, специфичная для архитектуры &arm; arm freebsd-arm список рассылки проблема, специфичная для архитектуры &mips; kern freebsd-mips список рассылки проблема, специфичная для архитектуры &powerpc; kern freebsd-ppc список рассылки проблема с Advanced Configuration and Power Management (&man.acpi.4;) kern freebsd-acpi список рассылки проблема с драйверами ATM kern freebsd-atm список рассылки проблема с встраиваемой системой или минимальным дистрибутивом &os; (например, NanoBSD/PicoBSD/FreeBSD-arm) kern freebsd-embedded список рассылки проблема с драйверами &firewire; kern freebsd-firewire список рассылки проблема в исходном коде файловой системы kern freebsd-fs список рассылки проблема с подсистемой &man.geom.4; kern freebsd-geom список рассылки проблема с подсистемой &man.ipfw.4; kern freebsd-ipfw список рассылки проблема с драйверами ISDN kern freebsd-isdn список рассылки подсистема &man.jail.8; kern freebsd-jail список рассылки проблема с эмуляцией &linux; или SVR4 kern freebsd-emulation список рассылки проблема с сетевым стеком kern freebsd-net список рассылки проблема с подсистемой &man.pf.4; kern freebsd-pf список рассылки проблема с подсистемой &man.scsi.4; kern freebsd-scsi список рассылки проблема с звуковой подсистемой (&man.sound.4;) kern freebsd-multimedia список рассылки проблема с подсистемой &man.wlan.4; или с драйвером беспроводного устройства kern freebsd-wireless список рассылки проблема с &man.sysinstall.8; или с &man.bsdinstall.8; bin freebsd-sysinstall список рассылки проблема с системными стартовыми скриптами (&man.rc.8;) kern freebsd-rc список рассылки проблемы в работе VIMAGE, VNET, или проблемы в их коде kern freebsd-virtualization список рассылки проблема с эмуляцией Xen kern freebsd-xen список рассылки
Общие назначения — коллекция портов Тип Предполагаемая категория Предполагаемое назначение Тип назначения проблема с инфраструктурой системы портов (не с конкретным портом!) ports portmgr алиас порт, у которого мейнтейнер apache@FreeBSD.org ports apache список рассылки порт, у которого мейнтейнер autotools@FreeBSD.org ports autotools алиас порт, у которого мейнтейнер doceng@FreeBSD.org ports doceng алиас порт, у которого мейнтейнер eclipse@FreeBSD.org ports freebsd-eclipse список рассылки порт, у которого мейнтейнер gecko@FreeBSD.org ports gecko список рассылки порт, у которого мейнтейнер gnome@FreeBSD.org ports gnome список рассылки порт, у которого мейнтейнер hamradio@FreeBSD.org ports hamradio алиас порт, у которого мейнтейнер haskell@FreeBSD.org ports haskell алиас порт, у которого мейнтейнер java@FreeBSD.org ports freebsd-java список рассылки порт, у которого мейнтейнер kde@FreeBSD.org ports kde список рассылки порт, у которого мейнтейнер mono@FreeBSD.org ports mono список рассылки порт, у которого мейнтейнер office@FreeBSD.org ports freebsd-office список рассылки порт, у которого мейнтейнер perl@FreeBSD.org ports perl список рассылки порт, у которого мейнтейнер python@FreeBSD.org ports freebsd-python список рассылки порт, у которого мейнтейнер ruby@FreeBSD.org ports freebsd-ruby список рассылки порт, у которого мейнтейнер secteam@FreeBSD.org ports secteam алиас порт, у которого мейнтейнер box@FreeBSD.org ports vbox алиас порт, у которого мейнтейнер x11@FreeBSD.org ports freebsd-x11 список рассылки
PR для портов, у которых мейнтейнером является коммиттер порта, могут быть переназначены любым лицом (только учтите, что не каждый &os; коммиттер в обязательном порядке является коммиттером портов, поэтому вы не должны судить только по почтовому адресу). Для остальных PR, пожалуйста не переназначайте их другим людям (за исключением себя), если вы не уверены, что человек действительно будет работать над ними. Это поможет избежать ситуации, когда решение проблемы игнорируется другими людьми, так как подразумевается, что некто уже над ней работает. Общие назначения — остальные Тип Предполагаемая категория Предполагаемое назначение Тип назначения неполадки с самой GNATS(&man.send-pr.1;) bin bugmeister алиас неполадки с веб интерфейсом GNATS www bugmeister алиас
Назначение PR Если в PR в заполненном поле responsible указано имя разработчика FreeBSD, это значит, что PR взята этим человеком для дальнейшей работы. Уже назначенное PR не должно трогаться никем, кроме администраторов GNATS (bugmeister) и того, кому эта проблема назначена. Если у вас есть комментарии, напишите отклик. Если по какой-то причине вы думаете, что PR должна изменить своё состояние или её необходимо назначить кому-то другому, пошлите сообщение тому, кто назначен ответственным. Если этот человек не ответит в течение двух недель, смените назначение PR, а дальше действуйте по своему усмотрению.
Повторные PR Если вы обнаружите, что один и тот же вопрос описывается более чем в одном PR, выберите то, что содержит максимальный объём полезной информации и закройте все остальные, чётко указав номер более полного PR. Если несколько PR содержат не пересекающуюся информацию, перенесите всю недостающую информацию в какой-либо отклик, включая ссылки на остальные PR; затем закройте другие PR (которые теперь полностью перекрыты).
Просроченные PR PR считается простроченным, если оно не модифицировалось в течение более полугода. При обработке просроченных PR используйте следующую процедуру: Если PR достаточно подробна, попытайтесь воспроизвести проблему в дереве -CURRENT и -STABLE. Если вам это удалось, напишите отклик, описывающий ваши изыскания и попытайтесь найти кого-то, кому эту проблему можно назначить. Если это подходит, измените состояние на analyzed. Если PR описывает проблему, которая, как вы знаете, является результатом неправильного использования (некорректная настройка или что-то ещё), напишите отклик, в котором опишите, что автор исходного сделал не так, а затем закройте PR с описанием User error или Configuration error. Если в PR описывается ошибка, которая, как вы знаете, была исправлена как в -CURRENT, так и -STABLE, закройте его с сообщением, указывающим на даты исправлений в каждой ветке. Если PR описывает ошибку, которая, по вашим данным, была исправлена в -CURRENT, но не в -STABLE, попытайтесь выяснить, когда человек, исправивший эту ошибку, планирует выполнить MFC, либо попробуйте найти для этого кого-то ещё (может, это будете вы сами?). Измените состояние сообщения на patched и переназначьте его кому-либо, кто будет делать MFC. В остальных случаях запросите у автора исходного сообщения подтверждения того, что проблема всё ещё присутствует в новых версиях. Если автор не отвечает в течение месяца, закройте PR с пометкой Feedback timeout.
Незаполненные PR GNATS требовательно подходит к формату присылаемых сообщений об ошибках. Вот почему много PR заканчивают жизнь в состоянии misfiled, если посылающий забыл заполнить поле или ввёл неправильные данные в некоторые поля PR. Этот раздел поможет предоставить основной объём необходимых подробностей для разработчиков FreeBSD, который может помочь им закрыть или повторно заполнить эти PR. Если система GNATS не может понять, что делать с сообщением об ошибке, которое достигло базы данных, она определяет gnats-admin в качестве ответственного за PR и помещает сообщение в категорию pending. Теперь это PR в состоянии misfiled и оно не будет появляться в списках сообщений об ошибках, если только кто-то специально не запросит перечень всех незаполненных PR. Если у вас есть доступ к машинам в кластере FreeBSD, можете воспользоваться командой query-pr для просмотра списка PR, которые были некорректно сформированы: &prompt.user; query-pr -x -q -r gnats-admin 52458 gnats-ad open serious medium Re: declaration clash f 52510 gnats-ad open serious medium Re: lots of sockets in 52557 gnats-ad open serious medium 52570 gnats-ad open serious medium Jigdo maintainer update Как правило, PR вроде перечисленных выше оказываются незаполненными по одной из следующих причин: Отклик на существующее PR, посланный по электронной почте, имеет неверный формат заголовка Subject:. Автор PR отправил копию (Cc:) в список рассылки, а кто-нибудь ответил на этот пост вместо сообщения, сформированного GNATS. В копии, отосланной в список рассылки, нету тега категория/PRномер. (Вот почему мы рекомендуем посылающим не делать подобных движений). При заполнении шаблона &man.send-pr.1; посылающий забыл указать правильное значение для категории или класса PR. При заполнении шаблона &man.send-pr.1; посылающий установил значение поля Confidential в yes. (Так как мы позволяем каждому зеркалировать GNATS при помощи rsync, информация о PR-ах является общедоступной. Сообщения, касающиеся безопасности, не следует слать через GNATS, их необходимо отправлять на адрес команды офицеров безопасности). Это не реальное PR, а какое-то случайное сообщение, посланное на адрес bug-followup@FreeBSD.org или freebsd-gnats-submit@FreeBSD.org.
Отклики неправильно оформлены как новые PR К наиболее массовой категории неправильно оформленных PR относятся те, у которых неверна тема письма, и именно они на самом деле требует самых больших усилий от разработчиков. Это не настоящие PR, описывающие отдельные ошибки. Когда по одному из адресов, который прослушивает GNATS на предмет обработки входящих сообщений, принимается ответ на существующее PR, то тема ответа должна быть всегда в таком виде: Subject: Re: category/number: старая тема Большинство почтовых программ, когда вы отвечаете на оригинальное почтовое сообщение с PR, будут добавлять часть Re: . Часть category/number:  является соглашением, специфичным для GNATS, которое вы должны выполнить, вручную поставив его в тему письма с откликом. Все разработчики FreeBSD, имеющие прямой доступ к базе данных GNATS, могут регулярно проверять наличие таких PR и перемещать заинтересовавшие их в отклики к оригинальному PR (послав корректный отклик на сообщение об ошибке на адрес &a.bugfollowup;). Затем неправильно оформленное PR может быть закрыто с примерно таким пояснением: Your problem report was misfiled. Please use the format "Subject: category/number: original text" when following up to older, existing PRs. I've added the relevant bits from the body of this PR to kern/12345 Поиск по команде query-pr оригинального PR, на которое отвечает неправильно оформленный отклик, легко выполняется следующим образом: &prompt.user; query-pr -q -y "some text" После того, как вы обнаружили оригинальное PR и неправильно оформленный отклик на него, воспользуйтесь параметром команды query-pr для сохранения полного текста всех относящихся к делу PR в файле формата почтового ящика &unix;, то есть: &prompt.user; query-pr -F 52458 52474 > mbox Теперь вы можете использовать любую почтовую программу для просмотра всех PR, которые вы сохранили в файле mbox. Скопируйте текст всех неверно оформленных PR в отклике на оригинальное сообщение о проблеме, и обязательно включите правильный заголовок Subject:. После этого закройте неверно оформленное PR. Когда вы закрываете такие PR, помните, что автор получает оповещение по почте о том, что его PR сменило состояние на closed. В пояснении обязательно описывайте в подробностях, почему это состояние изменилось. Обычно подойдёт примерно следующий текст: Followup to ports/45364 misfiled as a new PR. This was misfiled because the subject did not have the format: Re: ports/45364: ... В этом случае автор неправильно оформленного PR будет знать, чего необходимо избегать при отправке отклика на существующее PR.
Некорректные PR с отсутствующими полями Ко второму типу неправильно оформленных PR обычно относят те, что являются результатом забывчивости авторов, которые не заполнили все необходимые поля при написании первоначального PR. Отсутствие или ошибочное задание полей category или class может привести к появлению некорректного сообщения. Разработчики могут использовать &man.edit-pr.1; для смены значений категории или класса этих неправильно оформленных PR на более подходящие и сохранить PR. Другой распространённой причиной появления неправильно оформленных PR являются вопросы форматирования, квотирование, изменение или удаление шаблона send-pr, как по вине пользователя, редактирующего шаблон, так и почтовых программ, которые проделывают странные вещи с обычными текстовыми сообщениями. Это изредка случается и может быть исправлено программой edit-pr, что требует некоторых усилий со стороны разработчика, корректирующего PR, однако в большинстве случаев это можно сделать относительно легко.
Неправильные PR, которые на самом деле не являются сообщениями об ошибках Иногда пользователь желает сообщить об ошибке и посылает GNATS по электронной почте обычное сообщение. Скрипты GNATS работает с сообщениями об ошибках, которые форматированы при помощи шаблона &man.send-pr.1;. Они не могут обрабатывать любые сообщения электронной почты. Вот почему сообщения об ошибках, посылаемые на адрес freebsd-gnats-submit@FreeBSD.org, должны быть оформлены по шаблону команды send-pr, хотя сообщения по электронной почте можно послать на &a.bugs;. Разработчики, которые видят PR, выглядящие так, будто они должны были быть посланы в адрес &a.bugs.name; или какого-то другого списка рассылки, должны закрыть PR, проинформировав его автора в протоколе изменения состояния о причинах, по которых это не является настоящим PR и куда следует посылать сообщения. Электронный адрес, который использует GNATS для приёма поступающих PR, опубликован в документации к FreeBSD, объявлялся и указан на Web-сайте. Это значит, что спамеры его увидели. Спам-сообщения, достигшие GNATS, немедленно определяются в категорию pending и остаются там до тех пор, пока кто-нибудь их не пересмотрит. Закрытие любого из таких сообщений при помощи &man.edit-pr.1; весьма раздражает, потому что GNATS отвечает автору, а адрес отправителя спам-почты никогда не бывает настоящим. Для каждого закрытого PR будут приходить сообщения о невозможности доставки. На данный момент с установкой некоторых фильтров против спама, проверяющих все добавления в базу данных GNATS, количество спама, достигающего состояния pending, весьма мало. Все разработчики, имеющие доступ к машинам кластера FreeBSD.org, приглашаются к проверке неправильно оформленных PR и немедленному закрытию тех, что являются почтовым спамом. Когда вы закрываете такое PR, пожалуйста, сделайте следующее: Выставьте Category в junk. Установите Confidential в no. Установите Responsible в gnats-admin. Смените State в closed. Для PR категории junk не выполняется резервное копирование, следовательно, перевод спам сообщений в эту категорию обозначает, что мы не желаем хранить их или тратить дисковое пространство на них. Если вы просто закрываете их без смены категории, они остаются как в главной базе, так и во всех копиях базы, зеркалируемых через cvsup.
Дополнительная литература Это перечень ресурсов, относящихся к качественному написанию и обработке сообщений об ошибках. Несомненно, этот список не является полным. Как писать Сообщения об ошибках FreeBSD—руководство для авторов PR.
diff --git a/ru_RU.KOI8-R/articles/problem-reports/Makefile b/ru_RU.KOI8-R/articles/problem-reports/Makefile index 4d21f2f957..cc3754b7e9 100644 --- a/ru_RU.KOI8-R/articles/problem-reports/Makefile +++ b/ru_RU.KOI8-R/articles/problem-reports/Makefile @@ -1,24 +1,24 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/problem-reports/Makefile,v 1.3 2005/06/30 03:23:24 gad Exp $ # -# Original revision: r21827 +# Original revision: r39631 # # Article: Writing FreeBSD Problem Reports DOC?= article FORMATS?= html WITH_ARTICLE_TOC?= YES INSTALL_COMPRESSED?=gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/problem-reports/article.xml b/ru_RU.KOI8-R/articles/problem-reports/article.xml index e62c72ed21..040dd6c6f9 100644 --- a/ru_RU.KOI8-R/articles/problem-reports/article.xml +++ b/ru_RU.KOI8-R/articles/problem-reports/article.xml @@ -1,1244 +1,1244 @@
Составление сообщений о проблеме во &os; $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.ibm; &tm-attrib.intel; &tm-attrib.sparc; &tm-attrib.sun; &tm-attrib.general; $FreeBSD$ Эта статья описывает, как наилучшим образом сформулировать и отправить сообщение о проблеме в Проект &os;. Dag-ErlingSmørgravТекст предоставил MarkLinimon сообщения о проблемах
Введение Одной из самых разочаровывающих практик, которую можно получить в качестве пользователя программного обеспечения, является отправка сообщения о проблеме, которое вскоре закрывается с кратким и ничему не помогающим объяснением типа это не проблема или неправильное PR. Подобным же образом одной из самых разочаровывающих практик, которую можно получить в качестве разработчика программного обеспечения, является получение массы сообщений о проблемах, которые на самом деле не являются сообщениями о проблемах, а запросами на получение поддержки, или которые содержат мало или вообще не содержат никакой информации о сути проблемы или способе ее воспроизведения. В этом документе делается попытка описать то, как составлять хорошие сообщения о проблемах. Что же, спросите вы, является хорошим сообщением о проблеме? Ну, если перейти прямо к сути, то хорошим сообщением об проблеме является то, которое может быть быстро проанализировано и отработано, к обоюдному удовлетворению как пользователя, так и разработчика. Хотя в основном статья фокусируется на сообщениях о проблемах во &os;, большей частью она должна хорошо подходить и другим программным проектам. Заметьте, что эта статья организована по тематическому принципу, а не хронологически, так что вы должны прочесть документ целиком прежде, чем посылать сообщение о проблеме, и не воспринимать статью как пошаговое руководство.
Когда нужно отправлять сообщение о проблеме Имеется много классов ошибок, и не все они должны приводить к появлению сообщения о проблеме. Конечно же, нет идеальных людей, и будут моменты, когда вы решите, что нашли ошибку в программе, а на самом деле вы неправильно поняли синтаксис команды или сделали опечатку в конфигурационном файле (хотя само по себе это иногда говорит о плохой документации или неправильной обработке ошибок в прикладной программе). Есть еще много случаев, когда посылка сообщения о проблеме явно не является правильным действием, а только приводит к разочарованию вас и разработчиков. И наоборот, есть случаи, когда может быть нужно послать сообщение о чем-то, не являющемся ошибкой — к примеру, запрос на доработку или расширение функциональности. Но как же определить, что является ошибкой, а что нет? Простым правилом, которому нужно следовать, является следующее – ваша проблема не является ошибкой, если она формулируется как вопрос (обычно в форме Как сделать X? или Где можно найти Y?). Не всегда это так однозначно, но правило вопроса покрывает большинство случаев. Если Вам нужен ответ, лучше всего задать свой вопрос в &a.questions;. Вот некоторые случаи, в которых может оказаться полезным отправить сообщение о чем-то, что не является ошибкой: Уведомление об обновлении программного обеспечения, которое поддерживается сторонними разработчиками (в основном порты, но также и компоненты базовой системы, разрабатываемые сторонними организациями, такие, как BIND или различные утилиты GNU). Для не поддерживаемых никем портов (переменная MAINTAINER содержит ports@FreeBSD.org), такие уведомления о обновлении будут замечены заинтересовавшимся коммиттером и вас могут попросить предоставить патч для обновления порта; предоставление патча до того, как вас попросят об этом сильно увеличит шансы того, что порт будет обновлён вовремя. Если порт поддерживается, PR-ы, указывающие о появлении новых улучшенных (upstream) релизов обычно не очень полезны, так как они прибавляют много вспомогательной работы для коммиттеров, а мэйнтейнер наверняка уже знает о новой версии. Они уже наверняка работали с разработчиками над ней или они возможно тестируют её, чтобы убедиться в отсутствии регрессии и т.п. В любом случае, следование процессу, описанному в Руководстве по созданию портов даст наилучшие результаты. (Также можно ознакомиться с статьей Контрибуция в коллекцию портов FreeBSD.) Ошибка, которую нельзя воспроизвести, вряд ли будет исправлена. Если ошибка возникла только единожды, и вы не можете ее воспроизвести, к тому же никто с ней больше не сталкивался, нет никаких шансов, что разработчики смогут ее воспроизвести или понять, что делается неправильно. Это не значит, что такого не случается, но это значит, что шансов у вашего сообщения дойти когда-либо до стадии исправления ошибки очень малы. Часто эти виды ошибок возникают из-за неудовлетворительной работы жёстких дисков, перегревшихся процессоров. Всегда, когда это возможно вы должны отслеживать такие случаи перед посылкой сообщения об ошибке. Теперь, чтобы определить кому вы должны отправить ваше сообщение об ошибке, вы должны понимать, что программное обеспечение, которое входит во &os;, составляется из нескольких различных частей: Код в базовой системе, который пишется и поддерживается контрибьюторами &os;. Такой, как ядро, библиотека C, драйвера устройств (входят в категорию kern); утилиты (bin); страницы справочника и документация (docs); веб-страницы (www). Все ошибки в этих областях должны быть сообщены разработчикам &os;. Код в базовой системе, который пишется и поддерживается другим, импортируется во &os; и адаптируется. Примеры включают в себя: bind, &man.gcc.1; и &man.sendmail.8;. Большинство ошибок, попадающие в данные области должны быть сообщены разработчикам &os;, но в некоторых случаях они должны быть отправлены изначальным разработчикам, если проблемы не являются специфичными для &os;. Обычно ошибки такого рода попадают под категории bin или gnu. Отдельные приложения, не входящие в базовую систему, но являющиеся частью Коллекции Портов &os; (категория ports). Большинство этих приложений не пишется разработчиками &os;; что предоставляет &os;, так это только лишь инфраструктуру для установки приложения. Следовательно, вы должны отправлять сообщение об ошибке разработчикам &os; только тогда, когда вы уверены в том, что проблема специфична для &os; - иначе отправляйте её авторам программного обеспечения. Затем вы должны убедиться, действительно ли проблема существует. Существует всего несколько вещей, которые раздражают разработчика больше, чем получение сообщения об ошибке, которую он уже исправил. Если проблема в базовой системе, то вам нужно сначала прочесть раздел версии &os; из FAQ, если вы ещё не знакомы с данной темой. Для &os; возможно исправлять проблемы только для некоторых недавних веток базовой системы, поэтому отправка сообщения об ошибке для более старой версии приведёт к тому, что разработчик посоветует вам обновиться до поддерживаемой версии, чтобы посмотреть присутствует ли в ней проблема. Команда офицеров безопасности поддерживает список поддерживаемых версий.. Если проблема связана с портами, помните, что вы сначала должны обновиться до самой последней версии Коллекции Портов и проверить, существует ли в ней проблема. Из-за быстрых внесений изменений в эти приложения, неосуществимым для &os; является поддержка чего-либо, кроме самых последних версий, и проблемы со устаревшими версиями приложений просто не могут быть исправлены.
Подготовка Нужно следовать хорошему правилу всегда сначала выполнять дополнительные исследования перед тем, как послать сообщение о проблеме. Может быть, о вашей проблеме уже сообщено; может быть, она недавно обсуждалась или обсуждается в списках рассылки; она может быть уже исправлена в более новой версии, чем та, что вы используете. Поэтому вы должны проверить все обычные места до того, как послать ваше сообщение о проблеме. Для &os; это значит: &os; FAQ (Ответы на часто задаваемые вопросы). FAQ содержит ответы на вопросы из самых разных категорий, в частности, аппаратной совместимости, пользовательских программ и конфигурации ядра. Списки рассылки—если Вы не подписаны на них, воспользуйтесь поиском в архивах на сайте &os;. Если ваша проблема не обсуждалась в списках рассылки, вы можете попытаться опубликовать сообщение о ней и подождать несколько дней, пока кто-нибудь не сможет увидеть то, что вы не заметили. Как вариант, весь веб—используйте вашу любимую поисковую систему для поиска каких-либо ссылок по вашей проблеме. Вы можете даже увидеть ссылки на архивы списков рассылки или телеконференций, о которых вы не знали или не думали там искать. Следующим пунктом должна быть база данных PR &os; (GNATS). Если только ваша проблема не нова или редка, есть некоторый шанс, что о ней уже сообщено. И самое важное, вы должны посмотреть не затрагивает ли документация в базовой системе вашу проблему. Для основного кода &os; вы должны тщательно изучить содержимое файла /usr/src/UPDATING или его текущую версию по адресу http://svnweb.freebsd.org/base/head/UPDATING?view=log. (Если вы переходите с одной версии на другую, особенно если вы обновляетесь до &os.current;, то в этом файле вы можете найти много важной информации). Если же ваша проблема связана с коллекцией портов &os;, вы должны обратиться к файлу /usr/ports/UPDATING (изменения, касающиеся индивидуальных портов) или к /usr/ports/CHANGES (изменения, касающиеся всей коллекции портов). Они также доступны через интерфейс svnweb: http://svnweb.freebsd.org/ports/head/UPDATING?view=log и http://svnweb.freebsd.org/ports/head/CHANGES?view=log.
Написание сообщения о проблеме Теперь, после того, как вы решили, что ваш вопрос подпадает под категорию сообщения о проблеме, и это проблема &os;, самое время написать собственно сообщение о проблеме (PR). Прежде чем мы углубимся в частности использования программы для создания и отправки PR, вот несколько советов, которые помогут вам сделать PR более эффективным.
Как писать хорошие сообщения о проблемах Основным языком общения разработчиков FreeBSD является английский. База данных по проблемам также ведется на английском. Если вы испытываете проблемы с формулировкой описания проблемы по-английски, свяжитесь со своими соотечественниками, которые помогут вам составить PR. Не оставляйте поле Synopsis (краткое описание) пустым. Сообщения о проблемах попадают как в списки рассылки, которые затем расходятся по всему миру (в них поле Synopsis определяет тему письма), так и в базу данных. Просматривающий эту базу, как правило, пройдет мимо PR с пустым кратким описанием. Не забудьте, что PR остается в базе до тех пор, пока кто-либо не закроет его; сообщение-аноним, скорее всего, просто потеряется на общем фоне. Избегайте туманных описаний в поле Synopsis. Не стоит предполагать, что читающий ваше сообщение владеет контекстом; поэтому, чем подробнее вы опишете ситуацию, тем лучше. В частности, к какой части системы относится ваша проблема? Проявляется ли она на этапе установки или во время нормальной работы? Например, вместо строки Synopsis: portupgrade is broken следовало бы написать что-то вроде Synopsis: port ports-mgmt/portupgrade coredumps on -current. В случае портированных приложений в поле Synopsis полезно указывать не только имя порта, но и категорию. Если у вас есть готовый патч, скажите об этом. PR, содержащий патч, имеет куда больше шансов быть рассмотренным. В этом случае добавьте строку [patch] (включая квадратные скобки) в начало поля Synopsis (хотя использование именно этой формы необязательно, она является стандартом де-факто). Если вы отвечаете за исходные тексты, сообщите об этом. Если вы отвечаете за часть исходных текстов (например, порт), вы можете добавить в начало поля Synopsis строку [maintainer update] (включая квадратные скобки), а также установить класс вашего PR (поле Class) в maintainer-update. В этом случае коммиттеру, обрабатывающему ваш PR, не придётся лишний раз проверять. Будьте точны в формулировках. Чем больше информации вы можете предоставить о проблеме, тем больше у вас шансов получить ответ. Включите информацию о версии &os;, которую вы используйте (существует специальное поле для его включения, смотрите ниже) и на какой архитектуре. Сообщите, используете ли вы release версию (установили с компакт-диска либо загрузили) или скачали её с помощью Subversion (и если так, то сообщите номер ревизии). Если вы используете &os.current;, то первый вопрос, который вам могут задать, будет про номер ревизии, так как исправления для этой ветки (особенно в случае серьёзных проблем) имеют тенденцию появляться слишком быстро. Включите информацию о том, какие глобальные опции вы указали в make.conf. На заметку: Объявление опций наподобие -02 и других, описанных в &man.gcc.1; во многих случаях может быть причиной ошибок. Хотя и разработчики &os; будут принимать патчи, у них не будет желания исследовать такие случаи из-за отсутствия времени и добровольцев, и вместо этого они могут ответить, что это не поддерживается. Если проблему можно легко повторить, включите необходимую информацию, чтобы разработчик смог воспроизвести ее самостоятельно. Если проблема проявляется при некоторых вводимых данных, то, по возможности, приведите их вместе с получаемым и ожидаемым выводом. Если же вводимых данных много или же их нельзя разглашать, то попробуйте выделить из них лишь небольшой фрагмент, приводящий к возникновению проблемы, и включите его в PR. Если ваша проблема связана с ядром, будьте готовы предоставить следующую информацию (вам не обязательно включать её всю, она пойдёт лишь на заполнение базы данных, но вы должны включить информацию, которая по вашему мнению актуальна): Вашу конфигурацию ядра, включая то, какие устройства у вас установлены Включены ли у вас опции отладки (например, WITNESS), и если так, то существует ли проблема после изменения значения этой опции Полный вывод обратной трассировки (backtrace), паники или иного консольного вывода, или же записи из /var/log/messages, если они были сгенерированы Вывод команды pciconf -l, а также соответствующие части вывода dmesg, в случае, если проблема связана с конкретным оборудованием Прочли ли вы src/UPDATING, описана ли там ваша проблема (кто-нибудь спросит обязательно) Запускается ли другое ядро (это для тех случаев, когда причиной сбоя стало оборудование, например отказывающие винчестеры или перегревшиеся процессоры, что может маскировать проблемы ядра) Если же ваша проблема связана с портами, то предоставьте следующую информацию (вам не обязательно включать её всю, она пойдет лишь на заполнение базы данных, но вы должны включить информацию, которая по вашему мнению актуальна): Какие порты вы устанавливали Имеются ли какие-либо переменные окружения, которые переписывают первоначально-установленные в bsd.port.mk, такие как, PORTSDIR) Прочли ли вы ports/UPDATING, и описана ли там ваша проблема (кто-нибудь спросит обязательно) Избегайте нечетких запросов о новых возможностях. Сообщение типа кто-то обязательно должен сделать так, чтобы такая-то утилита вела себя так-то имеет куда меньше шансов встретить позитивный отклик, чем более четко сформулированный запрос. Помните, что исходные тексты доступны всем, так что если вам нужна реализация какого-то нового свойства, лучший способ— взяться за работу самому! Не забудьте также, что такие моменты лучше обсуждать в списках рассылки, таких как freebsd-questions, чем делать это посредством базы данных PR. Убедитесь, что ваша проблема еще никем не описана. Мы уже говорили об этом, но стоит повториться. Потратьте пару минут на составление запросов к базе PR: http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query. (Несмотря на повторы, об этом постоянно забывают) Сообщайте об одной проблеме в одном PR. Избегайте описания двух и более проблем в одном сообщении (исключением являются взаимосвязанные проблемы). Оформляя патчи, не пытайтесь в них добавлять множество функциональных возможностей или исправлять ими несколько ошибок в одном и том же сообщении о проблеме (опять же, за исключением взаимосвязанных проблем) — для таких PR-ов потребуется значительно больше времени на обработку. Избегайте полемики. Если ваше сообщение касается области или способов реализации, которые ранее вызвали разногласия, вам стоит быть готовым предоставить не только патчи, но и внятные аргументы, почему следует поступать именно так (то есть, это Правильный Путь). Как отмечалось выше, аккуратный поиск по архиву списков рассылки http://www.FreeBSD.org/search/search.html#mailinglists никогда не помешает. Будьте вежливы. Почти каждый из тех, кто может заниматься вашим сообщением, является добровольцем. Никому не понравятся указания, как и что делать, когда он и так занимается этим, да еще и по каким-либо причинам, отличным от финансовых. Вообще говоря, этого подхода следует придерживаться, имея дело с любым проектом с Открытыми Исходными текстами (Open Source).
Прежде всего Если вы используйте утилиту &man.send-pr.1; проверьте, что переменная вашего окружения VISUAL (или EDITOR, если VISUAL не задана) задана подходящим образом. Следует также проверить работоспособность системы электронной почты. Утилита &man.send-pr.1; использует почтовую систему для отправки и отслеживания сообщения о проблеме. Если с машины, на которой вы запускаете &man.send-pr.1;, нельзя отправить почту, сообщение не попадёт в базу данных GNATS. О настройке электронной почты во &os; можно прочитать в главе Электронная почта Руководства по &os; по адресу http://www.FreeBSD.org/doc/ru_RU.KOI8-R/books/handbook/mail.html. Убедитесь, что ваш почтовый клиент не исказит сообщение по пути в GNATS. В частности, если ваш почтовый клиент автоматически переносит строки, изменяет символы табуляции на пробелы или предотвращает интерпретацию символов новой строки, любой патч, который вы пришлёте окажется непригодным. Для текста мы хотели бы, чтобы вы делали строчки размером примерно в 70 символов для читабельности PR на веб странице. Примерные соображения должны учитываться при отправке сообщения об ошибке через веб-форму вместо &man.send-pr.1;. Помните, что операции копирования-вставки могут иметь сторонние эффекты в форматировании текста. В определённых случаях может быть необходимо использовать &man.uuencode.1; для гарантии того, что патчи придут не изменёнными. И наконец, если ваше сообщение будет объёмным, вы должны приготовить его в offline, чтобы ничего не потерялось в случае, если будет проблема при его отправке. Это особенно касается веб-формы.
Вложение патчей или файлов Нижеследующее применимо к передаче сообщения о проблеме посредством электронной почты: Программа &man.send-pr.1; предусматривает присоединение файлов к сообщению о проблеме. Вы можете вложить сколько угодно файлов, но каждый с уникальным именем (имеется в виду имя файла без маршрута). Просто используйте параметр командной строки для задания имен файлов, которые вы хотите присоединить: &prompt.user; send-pr -a /var/run/dmesg -a /tmp/errors Не беспокойтесь о бинарных файлах, они будут автоматически перекодированы для того, чтобы не повредить работе вашей почтовой программы. Если вы вкладываете патч, обязательно используйте параметр или вместе с командой &man.diff.1; для создания контекстного или унифицированного diff-файла (унифицированный формат предпочтителен), и обязательно укажите точные номера SVN ревизий файлов, которые вы изменяли, чтобы разработчики, которые будут читать ваше сообщение, смогли легко его применить. Для проблем, связанных с ядром или с базовыми утилитами, предпочтительнее будет патч относительно ветки &os.current; (или Subversion-ветки HEAD), так как весь новый код должен быть сначала протестирован в ней. После завершения тестирования код будет интегрирован в ветвь &os.stable;. Если вы вставляете патч в тело сообщения, учтите, что некоторые почтовые программы имеют тенденцию заменять табуляции серией пробелов, что полностью разрушит, например, часть файла сборки (Makefile). Не отсылайте патчи в виде вложений, используя Content-Transfer-Encoding: quoted-printable. Это выполнит экранирование (escaping) символов и весь патч будет бесполезным. Следует также заметить, что включение небольших патчей в сообщение о проблеме является приемлемой практикой, в особенности если они решают проблему, описанную в сообщении, большие же патчи, а в особенности новый код, который может требовать значительного просмотра перед тем, как он будет внесен в дерево исходных текстов, должны быть размещены на web- или ftp-сервере, а в сообщение о проблеме должен быть включён только URL указывающий на этот патч. Очень часто патчи, пересылаемые по электронной почте, а в особенности если задействована GNATS, бывают искажены, и, как следствие, чем больше патч, тем труднее будет для заинтересованных людей привести его к нормальному виду. Также то, что патч будет размещён отдельно от сообщения о проблеме, даёт возможность изменять его не отсылая полный патч в дополнение к изначальному сообщению о проблеме. И наконец, большие патчи просто увеличивают размер базы данных, так как закрытые сообщения об ошибках на самом деле не удаляются, а сохраняются и помечаются, как closed. Вы должны также помнить, что пока вы явно не укажете обратного в вашем сообщении о проблеме или в самих патчах, будет предполагаться, что они подпадают под те же условия лицензирования, что и оригинальный файл, измененный вами.
Заполнение шаблона Следующие несколько абзацев применимы только к способу подачи PR через электронную почту: После запуска утилиты &man.send-pr.1; вам будет представлен шаблон сообщения о проблеме. Шаблон состоит из списка полей, некоторые из которых уже заполнены, а некоторые содержат комментарии, объясняющие назначение поля или перечисляющие подходящие значения. Не беспокойтесь о комментариях; они будут автоматически удалены, если вы их не изменяли (или удалите их сами). Вверху шаблона, ниже строк SEND-PR: находятся заголовки почтового сообщения. Вам обычно не нужно их изменять, если только вы не посылаете сообщение о проблеме с машины или от учетной записи, которая может посылать, но не может получать электронную почту, в случае чего вы можете задать в полях From: и Reply-To: ваши реальные адреса электронной почты. Вы можете также послать самому себе (или кому-то еще) копию сообщения о проблеме, добавив один или большее количество адресов к заголовку Cc:. В шаблоне вы найдете два однострочных поля: Submitter-Id: Не меняйте его. Значение по умолчанию current-users правильно, даже если вы используете &os.stable;. Confidential: Предварительно заполнено как no, его изменение не имеет значения, так как нет такого понятия, как конфиденциальное сообщение о проблеме — база данных PR распространяется по всему миру. Далее описаны общие поля для почтового и веб интерфейса: Originator: Пожалуйста, укажите ваше реальное имя, за которым опционально следует адрес вашей электронной почты в угловых скобках. Обычно, &man.send-pr.1; заполняет поле Originator содержимым поля gecos из учетной записи текущего пользователя. Предоставленный вами адрес электронной почты станет публичной информацией и может стать доступным спамерам. Поэтому совсем не лишними будут меры по борьбе со спамом на вашей стороне, или же можно воспользоваться временным адресом электронной почты. Однако, если вы укажете несуществующий почтовый адрес, то у нас не будет возможности уточнять детали по вашему PR. Organization: Все, что вы захотите здесь указать. Это поле не содержит значительной информации. Synopsis: Заполняется кратким и точным описанием проблемы. Краткое описание используется в качестве темы сообщения электронной почты о проблеме, и используется при выдаче списков и выборках сообщений о проблемах; сообщения о проблемах с непонятными краткими описаниями чаще всего игнорируются. Повторим: если к вашему сообщению о проблеме приложен патч, то, пожалуйста, начните краткое описание с [patch] (включая квадратные скобки); если PR принадлежит к категории ports и вы являетесь его мейнтейнером, то начните описание с [maintainer update] (включая квадратные скобки) и установите класс проблемы (поле Class) в maintainer-update. Severity: Одно из non-critical, serious или critical. Не переусердствуйте; избегайте пометки вашей проблемы как critical, если только это не действительно критичная проблема (повреждение данных, существенная потеря функциональности в -CURRENT), или serious, если только это не касается многих пользователей (паники ядра, блокировки (freezes), проблемы с конкретными драйверами устройств или с системными утилитами). Разработчики &os; не обязательно будут работать над вашей проблемой быстрее, если вы установите слишком высокий уровень важности, т.к. существует много других людей, которые сделали тоже самое — некоторые разработчики всё же уделят этому полю немного внимания и перейдут к следующему сообщению именно из-за этого поля. Большинство проблем с безопасностью не следует отправлять в GNATS, потому что вся эта информация становится публичной. Пожалуйста, направляйте подобные отчеты на электронный адрес &a.security-officer;. Priority: Одно из low, medium или high. high должен использоваться для проблем, которые затронут конкретно каждого пользователя &os;, а medium для чего-то, что затронет многих пользователей. Ввиду массовых злоупотреблений это поле потеряло свое значение. Category: Выберите соответствующую категорию. Первым делом необходимо решить, к какой части системы относится ваша проблема. Помните: &os; — завершенная операционная система, которая устанавливает ядро, стандартные библиотеки, множество драйверов периферийного оборудования, а также — большой набор системных утилит (базовая система). В дополнение к этому, в коллекции портов имеются тысячи приложений. Следовательно, определитесь: обнаруженная вами проблема находится в базовой системе или в чем-то, установленным через коллекцию портов. Вот описание основных категорий: Если проблема в ядре, в библиотеках (таких как стандартная библиотека С libc) или в драйвере из базовой системы, то используйте категорию kern. (Есть несколько исключений, описанных ниже). В общем, это всё, что описано в разделах 2, 3 или 4 справочника. Если проблема с бинарной программой, например с &man.sh.1; или &man.mount.8;, то вам прежде всего необходимо определить принадлежность программы к базовой системе или к установке из коллекции портов. Если вы не уверены, выполните команду whereis имя программы. В &os; для коллекции портов существует договоренность: установка ведется в /usr/local, однако это может быть переопределено системным администратором. Для таких программ следует использовать категорию ports (даже если категория порта www; см. ниже). Если программа располагается в /bin, /usr/bin, /sbin или в /usr/sbin, то это часть базовой системы, и вам следует использовать категорию bin. (Несколько программ, например &man.gcc.1;, на самом деле используют категорию gnu, но не беспокойтесь об этом сейчас.) Программы этой категории описаны в разделах 1 и 8 справочной системы. Если вы уверены, что в стартовых скриптах (rc) или в каком-то ином неисполняемом конфигурационном файле присутствует ошибка, тогда верной категорией будет conf (configuration). Эти сущности описываются в разделе 5 справочной системы. Если вы нашли проблему в наборе документации (статьи, книги, страницы справочной системы), правильным выбором будет docs. Если вы наблюдаете проблему на страницах сайта FreeBSD, то правильным выбором будет www. Если проблема с чем-то из порта, называемого www/someportname , то она все же принадлежит к категории ports. Далее представлены более специализированные категории. Если проблема принадлежит к kern, но в то же время имеет дело с подсистемой USB, то правильным выбором будет usb. Если проблема принадлежит к kern и найдена в потоковых библиотеках, правильным выбором будет threads. Если проблема принадлежит к базовой системе и касается соблюдения стандартов, таких как &posix;, правильным выбором будет standards. Если проблема связана с ошибками внутри &java.virtual.machine; (&jvm;), даже если &java; была установлена из коллекции портов, вам следует выбрать категорию java. Более общие проблемы с портами &java; попадают под категорию ports. Далее перечислены остальные категории. Если вы уверены, что проблема проявляется только на используемой вами процессорной архитектуре, выберите одну из архитектурно-специфичных категорий: это i386 для Intel-совместимых машин в 32-битном режиме; amd64 для AMD машин в 64-битном режиме (сюда также входят Intel-совместимые машины работающие в режиме EMT64); и менее распространенные arm, ia64, powerpc и sparc64. Люди часто ошибаются в выборе категории. Если вы не уверены в правильности выбора, то лучше не гадать, а выбрать misc. Правильное использование категории У вас простой ПК, и вы подозреваете, что столкнулись с проблемой, специфичной для конкретного чипсета или материнской платы: верная категория — i386. Неправильное использование категории Если вы наблюдаете проблему с периферийной картой расширения на распространенной шине или неполадки с конкретного типа жестким диском: в этом случае возможно, что неисправность наблюдается на более чем одной архитектуре, и верным выбором будет kern. Если вы не знаете в чем проблема (или вам кажется, что описание не попадает ни под какую из вышеобозначенных), используйте категорию misc. Перед тем, как написать PR, можно для начала спросить помощи в &a.questions;. Возможно, там вам подскажут, какую из существующих категорий следует выбрать. Вот текущий перечень категорий (взят из http://svnweb.freebsd.org/base/head/gnu/usr.bin/send-pr/categories): advocacy: проблемы, связанные с общественным мнением о &os;. Вышло из употребления. amd64: проблемы, специфичные для платформы AMD64. arm: проблемы, специфичные для платформы ARM. bin: проблемы с пользовательскими программами из базовой системы. conf: проблемы с файлами настройки, используемыми по умолчанию значениями и прочее. docs: проблемы со страницами справочной системы или онлайновой документацией. gnu: проблемы с портированным программным обеспечением GNU, таким как &man.gcc.1; или &man.grep.1;. i386: проблемы, специфичные для платформы &i386;. ia64: проблемы, специфичные для платформы ia64. java: проблемы, связанные с виртуальной машиной &java;. kern: проблемы с ядром или с библиотеками в базовой системе, или с драйверами устройств, не связанными с какой-либо конкретной платформой. misc: все, что не подпадает ни под какую другую категорию. (Надо отметить, что нет почти ничего, чтобы действительно соответствовало этой категории, за исключением проблем с релизами и с инфраструктурой сборки. Временные отказы при построении ветки HEAD не принадлежат к данной категории. Также надо отметить, что проблемы этой категории имеют тенденцию теряться легче всего). ports: проблемы, связанные с коллекцией портов. powerpc: проблемы, специфичные для платформы &powerpc;. sparc64: проблемы, специфичные для платформы &sparc64;. standards: проблемы, связанные с соответствием стандартам. threads: проблемы, касающиеся реализации тредов во &os; (особенно во &os.current;). usb: проблемы, относящиеся к реализации USB во &os;. www: изменения или улучшения сайта &os; Class: Выберите одно из следующего: sw-bug: ошибки в программном обеспечении. doc-bug: ошибки в документации. change-request: запросы на расширение функций или изменение в существующих. update: обновления портов или другого программного обеспечения сторонних разработчиков. maintainer-update: обновления в портах, для которых вы являетесь ответственной персоной. Release: Используемая вами версия &os;. Оно заполняется автоматически программой &man.send-pr.1; и требует изменения, если только вы отсылаете сообщение о проблеме с системы, отличающейся от той, где вы столкнулись с проблемой. И наконец, последовательность многострочных полей: Environment: Оно должно максимально точно описывать окружение, в котором встречается проблема. Сюда включается версия операционной системы, версия конкретной программы или файла, содержащего проблему, и любая другая информация, такая, как конфигурация системы, другое программное обеспечение, которое влияет на проблему, и так далее—просто все, что разработчик должен знать для создания условий появления проблемы. Description: Полное и точное описание проблемы, с которой вы столкнулись. Попытайтесь избежать своих предположений о причинах проблемы, если только вы не уверены, что правы, так как вы можете привести разработчика к неправильным предположениям о проблеме. How-To-Repeat: Последовательность действий, которые должны быть выполнены для повторения проблемы. Fix: Предпочтителен патч, или по крайней мере обходной путь (который не только поможет другим людям обойти ту же самую проблему, но также поможет разработчику понять ее причины), однако если у вас нет никаких здравых идей, то лучше оставить это поле пустым, чем строит догадки.
Отправка сообщения о проблеме Если вы используете &man.send-pr.1;: Как только вы заполните шаблон, сохраните его и выйдете из редактора, &man.send-pr.1; запросит вас s)end, e)dit or a)bort?. Вы можете нажать s для продолжения и отправки сообщения о проблеме, e для повторного запуска редактора и выполнения дальнейших изменений, или a для отказа от вашего сообщения. Если вы выберете последнее, то ваше сообщение о проблеме останется на диске (&man.send-pr.1; укажет вам имя файла перед завершением работы), так что вы сможете отредактировать его на свой вкус или передать в систему с лучшим подключением к сети, перед тем, как послать его при помощи параметра программы &man.send-pr.1;: &prompt.user; send-pr -f ~/my-problem-report При этом будет прочитан указанный файл, будет проверено содержимое, убраны комментарии и сообщение будет отослано. Если вы используете веб форму: Перед нажатием submit вам потребуется заполнить проверочное поле текстом, представленным на картинке рядом. Эта непопулярная мера была принята в связи со злоупотреблениями со стороны роботов и некоторых неверно сориентированных индивидуумов. Это необходимая мера, которая никому не нравится, и, пожалуйста, не просите нас убрать её. Отметим, что вам настоятельно рекомендуется сохранить вашу работу (PR) куда-нибудь перед нажатием кнопки submit. Распространенная пользовательская ошибка: отображение браузером устаревшей проверочной картинки из его кэша. Если это произойдет в вашем случае, ваше сообщение будет отвергнуто и ваши труды пропадут. Если по какой-либо причине вы не имеете возможности видеть проверочную картинку, а также не можете воспользоваться &man.send-pr.1;, пожалуйста примите наши извинения за неудобства и пришлите ваш PR электронной почтой команде freebsd-bugbusters@FreeBSD.org.
Отслеживание После того, как ваше сообщение будет принято, вы получите по электронной почте уведомление, в котором будет указан номер для отслеживания, который был назначен вашему сообщению о проблеме и URL, который вы можете использовать для проверки его состояния. В случае удачи кто-нибудь проявит интерес к вашей проблеме и попытается ее решить, или, как это бывает, описать, почему это не является проблемой. Вы будете автоматически оповещаться о любом изменении состояния и получать копии всех комментариев или патчей, которые будут присоединяться в процессе отработки вашего сообщения о проблеме. Если кто-то запросит дополнительную информацию от вас, или вы вспомните или обнаружите нечто, что не указали в начальном сообщении, пожалуйста пошлите ваше дополнение (отклик) с помощью одного из этих способов: Самый простой путь это использовать соответствующую ссылку (followup) на индивидуальной веб страничке сообщения об ошибки, к которой можно перейти, используя страничку поиска PR. Кликнув на этой ссылке откроется окно для отправки email с уже корректно заполненными полями To: и Subject: (если ваш браузер сконфигурирован для этого). Или просто пошлите письмо на адрес &a.bugfollowup;, включив отслеживаемый номер в теме письма, чтобы система отслеживания сообщений могла знать, к какому сообщению о проблеме его присоединить. Если вы не включите отслеживаемый номер, GNATS растеряется и создаст совершенно новое PR, которое будет закреплено за администратором GNATS. В результате ваш отклик затеряется до тех пор пока кто-нибудь не начнёт разгребать скопившийся мусор, что может произойти спустя дни или даже недели. Неправильно: Subject: that PR I sent Правильно: Subject: Re: ports/12345: compilation problem with foo/bar Если сообщение о проблеме остается открытым после того, как проблема была решена, просто отправьте сообщение (так, как это описано выше), с указанием, что сообщение о проблеме может быть закрыто, и если это возможно, объясните, как и когда проблема была устранена.
Проблемы взаимодействия с GNATS Большинство PR проходят сквозь систему и принимаются быстро; однако, во время загруженности GNATS, подтверждение на ваше сообщение о проблеме может задержаться на 10 и более минут. Пожалуйста, сохраняйте спокойствие. Помимо всего прочего, так как GNATS получает все данные через электронную почту, становится понятным, почему &os; пропускает все сообщения через спамфильтры. Если подтверждение не приходит на протяжении часа-двух, то, возможно, что ваше сообщение попало под них; если так, то, пожалуйста, свяжитесь с администраторами GNATS по адресу bugmeister@FreeBSD.org и попросите помощи. Среди антиспам мер есть одна, которая сопоставляет сообщения с множеством злоупотреблений, наблюдаемых в электронной почте с HTML-форматированием текста (однако, сюда не относится простое включение HTML в PR). Мы настоятельно рекомендуем не использовать HTML-форматированный текст при посылке PR: не только из-за вероятности попадания в спамфильтры, но и из-за загромождения базы данных. Отдайте предпочтение простому старому текстовому формату. В редких случаях вы можете столкнуться с ошибкой GNATS, когда PR принят и ему присвоен номер, но он не отображается в списках PR ни на одной из страниц веб поиска PR. Вероятно, что рассинхронизировался индекс базы с самой базой. Этот случай можно проверить, обратившись к страничке Query PR Database и проконтролировав наличие вашего PR. Если он есть, пожалуйста, известите администраторов GNATS (bugmeister@FreeBSD.org). Следует отметить, что перестройка базы выполняется периодически по cron, и если вам не к спеху, то не предпринимайте никаких шагов.
Дополнительная литература Это список информационных ресурсов, относящихся к правильному написанию и обработке сообщений о проблемах. Он, без сомнения, не полон. How to Report Bugs Effectively—прекрасное эссе, которое написал Simon G. Tatham о составлении полезных (не специфичных для &os;) сообщений о проблемах. Problem Report Handling Guidelines—интересный взгляд на обработку сообщений о проблемах самими разработчиками &os;.
diff --git a/ru_RU.KOI8-R/articles/relaydelay/Makefile b/ru_RU.KOI8-R/articles/relaydelay/Makefile index c34023f087..1e5088aeb5 100644 --- a/ru_RU.KOI8-R/articles/relaydelay/Makefile +++ b/ru_RU.KOI8-R/articles/relaydelay/Makefile @@ -1,21 +1,21 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/relaydelay/Makefile,v 1.1 2005/06/16 17:50:42 andy Exp $ # -# Original revision: r21216 +# Original revision: r39631 # # Article: Using greylisting with FreeBSD DOC?= article FORMATS?= html INSTALL_COMPRESSED?=gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/relaydelay/article.xml b/ru_RU.KOI8-R/articles/relaydelay/article.xml index c230b6329a..53e947fea5 100644 --- a/ru_RU.KOI8-R/articles/relaydelay/article.xml +++ b/ru_RU.KOI8-R/articles/relaydelay/article.xml @@ -1,251 +1,251 @@
Использование технологии серых списков во &os; ТомРодес
trhodes@FreeBSD.org
 2004 The &os; Documentation Project $FreeBSD$ $FreeBSD$ Эта статья создана исключительно для описания технологии задержки передачи сообщений на почтовом сервере &os;. Сервер с технологией задержки передачи (relaydelay) или попаданием в серый список (greylisting) снижает уровень спама просто за счёт выдачи диагностического сообщения TEMPFAIL на каждое входящее почтовое сообщение. Смысл этой технологии заключается в том, что большинство спамеров для выполнения своей работы используют собственные персональные компьютеры и специализированное программное обеспечение. Настоящий почтовый сервер должен помещать сообщения в очередь и пытаться доставить его позже. Таким образом, скорее всего, спамер перейдёт к следующему хосту вместо того, чтобы попытаться снова послать электронное послание. Это прекрасная идея; по крайней мере, до тех пор, пока спамеры не начнут использовать программное обеспечение, которое будет обеспечивать повтор передачи. Но как именно это работает? Итак, в процессе приёма сообщения электронной почты ID сообщения сохраняется в базе данных, а в качестве результата возвращается TEMPFAIL вместе с электронной почтой. Если сообщение электронной почты посылается повторно, то ID сообщения будет сверяться с ID сообщений, сохранёнными в базе данных. Если в базе данных оно существует, то посланию электронной почты разрешается доставка по назначению. В противном случае ID сохраняется, а в качестве результата возвратится TEMPFAIL. Этот цикл будет повторяться для каждого сообщения, поступающего на сервер. По моему личному опыту, это действительно отсекает 90% спама. Базовая настройка Нам потребуется perl с поддержкой многопоточного выполнения. Установите lang/perl5.8 с установленной переменной USE_THREADS=yes. Сначала может потребоваться удалить текущую версию perl; на необходимость сделать это укажут ошибки в процессе установки. При этом потребуется, чтобы все порты, которым нужен perl, были перестроены и переустановлены; ports-mgmt/portupgrade хорошо для этого подходит. По крайней мере, он укажет, какие порты были удалены и какие необходимо переустановить. Теперь что касается сервера базы данных; MySQL прекрасно подходит для такого типа работы. Установите databases/mysql40-server вместе с databases/p5-DBD-mysql40. Предыдущий порт должен подразумевать установку databases/p5-DBI-137, так что один шаг будет пропущен. Установите переносимый подключаемый серверный модуль на базе perl, порт net/p5-Net-Daemon. Большинство установок этих портов должны проходить без проблем. Следующий шаг будет более трудоёмким. Теперь установите порт mail/p5-Sendmail-Milter. На момент написания этого документа в файле Makefile имелась строка, начинающаяся с BROKEN, просто уберите или закомментируйте её. Она помечена так лишь потому, что в &os; по умолчанию не включался и не устанавливался пакет perl с поддержкой многопоточного выполнения. После удаления этой строки он должен строиться и устанавливаться без ошибок. Создайте каталог для размещения временных конфигурационных файлов: &prompt.root; mkdir /tmp/relaydelay &prompt.root; cd /tmp/relaydelay Теперь, когда у нас имеется временный каталог для работы, команде fetch нужно передать следующие URL-адреса: &prompt.root; fetch http://projects.puremagic.com/greylisting/releases/relaydelay-0.04.tgz &prompt.root; fetch http://lists.puremagic.com/pipermail/greylist-users/attachments/20030904/b8dafed9/relaydelay-0.04.bin Теперь необходимо распаковать исходный код: &prompt.root; gunzip -c relaydelay-0.04.tgz | tar xvf - На этот момент во временном каталоге должно оказаться несколько файлов. Теперь необходимая информация может передаваться серверу базы данных импортированием её из файла mysql.sql: &prompt.root; mysql < relaydelay-0.04/mysql.sql Установите патч relaydelay.bin для остальных файлов, запустив такую команду: &prompt.root; patch -d /tmp/relaydelay/relaydelay-0.04 < relaydelay.bin Отредактируйте файлы relaydelay.conf и db_maintenance.pl, добавив в них корректное имя пользователя и пароль для СУБД MySQL. Если СУБД была построена и установлена так, как описано выше, то в ней отсутствуют пользователи и пароли. Эта ситуация должна быть исправлена до перевода системы в промышленную эксплуатацию, что описано в документации к СУБД и выходит за рамки данной статьи. Смените рабочий каталог на relaydelay-0.04: &prompt.root; cd relaydelay-0.04 Скопируйте или переместите конфигурационные файлы в соответствующие каталоги: &prompt.root; mv db_maintenance.pl relaydelay.pl /usr/local/sbin &prompt.root; mv relaydelay.conf /etc/mail &prompt.root; mv relaydelay.sh /usr/local/etc/rc.d/ Протестируйте получившуюся конфигурацию, выполнив такую команду: &prompt.root; sh /usr/local/etc/rc.d/relaydelay.sh start Этот файл не будет существовать, если предыдущие команды &man.mv.1; не были выполнены. Если всё отработало корректно, то в каталоге /var/log должен появиться новый файл, relaydelay.log. В нём должен находиться текст, подобный следующему: Loaded Config File: /etc/mail/relaydelay.conf Using connection 'local:/var/run/relaydelay.sock' for filter relaydelay DBI Connecting to DBI:mysql:database=relaydelay:host=localhost:port=3306 Spawned relaydelay daemon process 38277. Starting Sendmail::Milter 0.18 engine. Если файл не появился, то что-то сработало неправильно, пересмотрите экранную диагностику или просмотрите журнальный файл messages на предмет появления новой информации. Объедините всё вместе, добавив следующую строку в файл /etc/mail/sendmail.mc или специфичный для вашей системы mc-файл: INPUT_MAIL_FILTER(`relaydelay', `S=local:/var/run/relaydelay.sock, T=S:1m;R:2m;E:3m')dnl Перестройте и переустановите файлы в каталоге /etc/mail и перезапустите sendmail. Короткая команда make restart должна сделать всё необходимое. Сгрузите скрипт на языке perl, размещённый по адресу http://lists.puremagic.com/pipermail/greylist-users/2003-November/000327.html и сохраните его в каталог relaydelay-0.04. В следующем примере этот скрипт обозначается как addlist.pl. Отредактируйте файл whitelist_ip.txt, модифицировав его так, чтобы в него были включены IP-адреса серверов, которые должны иметь возможность игнорировать фильтры relaydelay. То есть это домены, при получении электронной почты от которых диагностическое сообщение TEMPFAIL выдаваться не будет. Как пример можно привести: 192.168. # My internal network. 66.218.66 # Yahoo groups has unique senders. Файл blacklist_ip.txt должен иметь похожее назначение, но с обратными правилами. Укажите в этом файле IP-адреса, которые должны отвергаться без выдачи диагностического сообщения TEMPFAIL. Этот перечень доменов никогда не получит даже возможность сообщить о том, что они являются реально существующими почтовыми серверами. Эти файлы теперь должны быть импортированы в базу данных посредством скрипта addlist.pl, который был получен несколькими строками выше: &prompt.root; perl addlist.pl -whitelist 9999-12-31 23:59:59 < whitelist_ip.txt &prompt.root; perl addlist.pl -blacklist 9999-12-31 23:59:59 < blacklist_ip.txt Для включения технологии relaydelay при каждой загрузке системы, добавьте строчку в файл /etc/rc.conf. Журнальный файл /var/log/relaydelay.log должен постепенно пополняться удачными прохождениями. В зависимости от загрузки вашего почтового сервера, вскоре должны появиться строчки, подобные следующим. === 2004-05-24 21:03:22 === Stored Sender: <someasshole@flawed-example.com> Passed Recipient: <local_user@pittgoth.com> Relay: example.net [XXX.XX.XXX.XX] - If_Addr: MY_IP_ADDRESS RelayIP: XX.XX.XX.XX - RelayName: example.net - RelayIdent: - PossiblyForged: 0 From: someasshole@flawed-example.com - To: local_user InMailer: esmtp - OutMailer: local - QueueID: i4P13Lo6000701111 Email is known but block has not expired. Issuing a tempfail. rowid: 51 IN ABORT CALLBACK - PrivData: 0<someasshole@flawed-example.com> В файл /etc/newsyslog.conf теперь можно добавить следующую строку, которая обеспечивает ротацию журналов relaydelay.log при достижении размера в 100 Кбайт: /var/log/relaydelay.log 644 3 100 * Z В какой-то момент появлялась ошибка о неполном определении переменных perl в файле /etc/mail/relaydelay.conf. Если те две переменные раскомментированы, то конфигурационный файл может быть обработан нормально. Просто не забудьте убрать их из комментариев до того, как начать работу с технологией relaydelay.
diff --git a/ru_RU.KOI8-R/articles/releng-packages/Makefile b/ru_RU.KOI8-R/articles/releng-packages/Makefile index f2eb2b2d7c..33a558bdd9 100644 --- a/ru_RU.KOI8-R/articles/releng-packages/Makefile +++ b/ru_RU.KOI8-R/articles/releng-packages/Makefile @@ -1,22 +1,22 @@ # The FreeBSD Russian Documentation Project # # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/releng-packages/Makefile,v 1.2 2005/07/01 07:07:44 gad Exp $ # $FreeBSD$ # -# Original revision: r20561 +# Original revision: r39631 # # Article: FreeBSD Release Engineering of Third Party Software Packages DOC?= article FORMATS?= html INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml CSS_SHEET_ADDITIONS= extra.css DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/releng-packages/article.xml b/ru_RU.KOI8-R/articles/releng-packages/article.xml index 33b65c0b31..08b29a391d 100644 --- a/ru_RU.KOI8-R/articles/releng-packages/article.xml +++ b/ru_RU.KOI8-R/articles/releng-packages/article.xml @@ -1,412 +1,412 @@
Подготовка релизов FreeBSD в части программных пакетов сторонних разработчиков StevePrice
steve@FreeBSD.org
 &tm-attrib.freebsd; &tm-attrib.intel; &tm-attrib.xfree86; &tm-attrib.general; $FreeBSD$ $FreeBSD$ В этом документе описывается подход, используемый группой менеджеров портов FreeBSD для создания высококачественного набора пакетов, предназначенного для размещения на носителях с официальными релизами FreeBSD. Этот документ находится в состоянии доработки, и постепенно он покроет весь процесс построения целостного набора пакетов в Кластере Портов проекта FreeBSD.org, опишет, как настроить любой другой набор машин в качестве кластера портов, как разделить пакеты для размещения на носителях с релизом и как проверить целостность набора пакетов. Построение пакетов из Коллекции Портов Коллекция портов FreeBSD представляет собой собрание более чем &os.numports; программных пакетов сторонних разработчиков, доступных для FreeBSD. За поддержку дерева портов, которое может использоваться для подготовки бинарных пакетов, идущих с некоторым релизом FreeBSD, в рабочем состоянии, отвечает &a.portmgr;. Кластер портов Для подготовки целостного набора пакетов сторонних разработчиков для релизов FreeBSD каждый порт строиться в отдельном окружении с изменённым корнем файловой системы, с изначально пустыми каталогами /usr/local и /usr/X11R6. Требуемые зависимости устанавливаются в виде пакетов до момента начала построения. Это обеспечивает целостность процесса построения пакетов. Запуская построение пакета в чистом окружении, мы можем гарантировать, что метаданные пакета (такие, как требуемые зависимости) корректны. Таким образом, мы никогда не создаём пакеты, которые, в зависимости от ранее установленного программного обеспечения, на одних системах работать могут, а на других работать не будут. Кластер портов для архитектуры x86 в настоящее время состоит из центрального узла (Dual &pentium; III 733MHz) и 8 подчинённых узлов (&pentium; III 800MHz), выполняющих реальное построение пакетов. В такой конфигурации полное построение пакетов занимает более 24 часов. Эти машины размещены вместе с остальным оборудованием Проекта FreeBSD в углу с оборудованием компании Yahoo у провайдера Exodus в калифорнийском городе Санта-Клара. Кластер портов для архитектуры Alpha состоит из 7 машин PWS 500A, предоставленных компанией Compaq, и они также расположены вместе с оборудованием компании Yahoo. Разделение пакетов Для FreeBSD 4.4 было создано более 4.1 гигабайт пакетов. Это привело к проблемам для распространения на CDROM, так как нам нужно записать как можно больше пакетов без необходимости заставлять пользователя вставлять другой диск для поиска зависимостей. Решением является создание кластеров близких пакетов с похожими зависимостями и группировать их на отдельные диски. В этом разделе описывается программное обеспечение и методология, использованная при создании таких наборов пакетов для официальных дисков FreeBSD с релизами. Скрипты и остальные файлы, необходимые для выполнения разделения пакетов, можно найти в дереве CVS в каталоге ports/Tools/scripts/release. Скопируйте этот каталог на машину с свободным дисковым пространством, достаточным для хранения 2 или 3 копий набора пакетов, который вы хотите разделить. В этом каталоге находятся следующие скрипты: config В этом файле находится свободное пространство на каждом диске и то, разрешено ли на этих дисках размещать пакеты, дистрибутивные файлы или оба типа файлов одновременно. Первая колонка содержит название диска. Оно должно быть в виде disc[0-9a-z]. На данный момент настройка выполнена на 10 дисков (4 для релиза и 6 для инструментального набора). При этом подразумевается дополнительный диск под названием scratch, куда помещаются остальные дистрибутивные файлы и пакеты, если они больше никуда не помещаются. Вторая колонка может быть 1 или 0, где 1 означает возможность размещения на этом диске пакетов. Третья колонка работает так же, но контролирует размещение на этом диске пакетов. Последняя колонка отмечает количество байтов свободного пространства на диске. doit.sh Это рабочая лошадка. Как только все файлы будут на своих местах и всё будет полностью настроено, этот скрипт управляет процессом разделения пакетов. Имейте в виду, что он интерактивный, так что вам нужно присматривать за его работой. Подробности о том, что делает скрипт, будут даны позже. checkdeps.pl Проверяет наличие всех зависимостей по файлу INDEX и каталогу с пакетами. oneshot.pl Здесь происходит основное волшебство (я использую это слово с некоторой натяжкой, так как большей частью всё решается в лоб). Имея перечень требуемых пакетов для каждого диска и набор пакетов/дистрибутивных файлов, этот скрипт размещает пакеты или дистрибутивные файлы по дискам вместе со всеми их зависимостями. print-cdrom-packages.sh Этот файл является копией src/release/scripts/print-cdrom-packages.sh из релиза, над которым вы работаете. scrubindex.pl Этот скрипт удаляет строки из файла INDEX для отсутствующих пакетов. Он также удаляет зависимости &xfree86;. ЗАМЕЧАНИЕ: вам нужно изменить значение переменной xdep, чтобы обеспечить правильность номера версии. setup.sh Это вспомогательный скрипт, используемый мною в кластере сборки пакетов для получения копии дерева портов и соответствующего набора пакетов/дистрибутивных файлов. Вот контрольный список того, что вам нужно будет проверить или настроить перед тем, как продолжить. Отредактируйте config, отметив количество имеющихся у вас дисков, их размеры и собираетесь ли вы размещать на них пакеты, дистрибутивные файлы, оба типа файлов или ничего из них. Проверьте, что вы удалили каталог gen, который мог остаться от предыдущих работ. Этот каталог содержит рабочие файлы, которые будут актуальны только для текущих действий. При первом вашем прогоне лучше всего избежать копирования пакетов и дистрибутивных файлов. Это сохранит как время, так и дисковое пространство, пока вы сможете проделать пару пробных запусков, чтобы удостовериться в том, что всё помещается, и так далее. В файле oneshot.pl задайте переменную fake в значение 1 и вместо реального копирования файлов он будет только выполнять над ними команду &man.touch.1;. Обязательно выключите эту возможность или установите переменную fake в значение 0 перед тем, как передавать получающиеся диски тому, кто будет тиражировать диски, в противном случае каталоги будут заполнены файлами с нулевыми размерами. Убедитесь, что у вас есть последняя копия файла print-cdrom-packages.sh, и он взят из соответствующего релиза. Проверьте, что зависимость &xfree86; в файле scrubindex.pl имеет корректный номер версии. Вам также нужно будет проверять, что это значение правильно задано в файле doit.sh. Теперь вам нужно сделать копию дерева портов, пакетов и дистрибутивных файлов из последнего построения кластера пакетов. Посмотрите файл setup.sh в качестве рабочего примера, но здесь описано всё необходимое. Возьмите копию ports.tar.gz и распакуйте её в каталог ports отдельно от файла doit.sh и каталога scripts. Удалите каталог packages/distfiles или символические ссылки на него. В bento имеются эти символические ссылки и вы будете получать смешанные результаты, если не избавитесь от них перед обработкой. Создайте новый каталог ports/packages и скопируйте набор пакетов из кластера построения пакетов. Создайте новый каталог ports/distfiles и скопируйте дистрибутивные файлы из кластера построения пакетов. ЗАМЕЧАНИЕ: если вы не хотите копировать дистрибутивные файлы, просто создайте каталог и оставьте его пустым. Этот каталог должен существовать, даже если в нём ничего нет. Теперь мы окончательно готовы к весёлому занятию по реальному разделению пакетов. Запускайте обработку командой ./doit.sh. Вот что она делает при первом её запуске. Создаёт список ограниченных к распространению (которые не могут находиться на главном FTP-сервере) портов. Запросит у вас, нужно ли удаление ограниченных к распространению портов. В большинстве случаев здесь вам лучше ответить (y)es. Создаёт перечень пакетов/дистрибутивных файлов, которые не могут быть размещены на дисках. Запросит у вас разрешение на удаление пакетов/дистрибутивных файлов, которые не размещаются на компакт-диск. В большинстве случаев здесь лучше ответить (y)es. Копирует файл INDEX из каталога ports в каталог gen. При этом она удаляет строчки портов, для которых нет пакетов. Также проверяется наличие всех требуемых зависимых пакетов. Создаёт список пакетов, требуемых для размещения на каждом диске. Делает запрос на создание дисков. После генерации каждого диска она проверяет отсутствующие зависимости, вычищает файл INDEX и создаёт файл CHECKSUM.MD5. Выполняет проверку того, что на каждом диске размещены требуемые пакеты и выдаёт общую статистику по размерам каждого диска. Если вам повезёт с первого раза, то все требуемые пакеты будут построены и размещены по дискам. Всё, что вам нужно сделать, это задать в качестве значения переменной fake в 0 в файле oneshot.pl и перезапустить ./doit.sh. При втором и последующем запусках шаги 1-5 выше будут пропускаться. Если вы хотите выполнить любые из тех шагов повторно, обратитесь к doit.sh, чтобы выяснить, какие файлы необходимо удалить для того, чтобы не пропустить эти этапы. Если вы хотите повторить все эти шаги, то проще всего выполнить rm -rf gen. К моменту успешного завершения пакеты и дистрибутивные файлы будут располагаться в каталогах disc*, а оставшиеся файлы будут находиться в каталоге scratch. Что делать, если что-то происходит не так? Вот некоторые распространённые проблем и их решения. Отсутствие требуемых пакетов Такое часто случается. Вам нужно подождать появления нового набора пакетов, где будут построены отсутствующие пакеты, либо попросить кого-нибудь перезапустить построение пакетов для вас. Не пытайтесь строить отсутствующие пакеты на собственной машине и добавлять их. Хотя вам может удастся обойтись этим, если вы очень осторожны, все же в большинстве случаев вы, скорее всего, пропустите какую-то маленькую деталь и простой процесс добавления одного пакета может привести к неожиданной неработоспособности сотен остальных. Требуемые пакеты не помещаются Такое тоже случается, и это относительно легко исправить. Просто отредактируйте файл print-cdrom-packages.sh, перенося пакеты, пока они не станут помещаться. Да, это итерационный процесс, и это одна из причин, по которой вы должны включать fake в oneshot.pl, пока не получите то, что хотите. Перезапустите ./doit.sh после того, как внесли свои изменения. Требуемые пакеты располагаются не на том (или ни на каком) диске Обычно это означает, что вы не добавили их в файл print-cdrom-packages.sh или разместили их не на том диске. Этот скрипт является святым источником, по которому в целом определяется, где должен находиться пакет. Если вы хотите обеспечить расположение пакета на определённом диске, то это единственное место, гарантирующее требуемое вам расположение. Если вы окончательно запутались, и не можете понять, почему всё работает неправильно и как это исправить, то пошлите письмо в адрес &a.steve.email; с просьбой о помощи.
diff --git a/ru_RU.KOI8-R/articles/releng/article.xml b/ru_RU.KOI8-R/articles/releng/article.xml index 9d07220513..e3d2dd2513 100644 --- a/ru_RU.KOI8-R/articles/releng/article.xml +++ b/ru_RU.KOI8-R/articles/releng/article.xml @@ -1,1123 +1,1123 @@ The Release Engineering of Third Party Packages'> ]>
Подготовка релизов &os; Ноябрь 2001 BSDCon Europe MurrayStokely Я участвовал в разработке продуктов на основе &os; с 1997 года в компаниях Walnut Creek CDROM, BSDi, а теперь Wind River Systems. &os; 4.4 была первым официальным релизом &os;, в выпуске которого я принимал значительное участие.
murray@FreeBSD.org http://www.FreeBSD.org/~murray/
&tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.intel; &tm-attrib.general; $FreeBSD$ $FreeBSD$ В этой статье описывается подход, который используется группой подготовки релизов &os; для создания качественных версий Операционной Системы &os;. В ней детально описывается методология, используемая для официальных релизов &os; и рассказывается об инструментах, доступных тем, кто интересуется созданием модифицированных релизов &os; для тиражирования внутри организации или в коммерческих целях. Введение Разработка &os; представляет собой весьма открытый процесс. &os; составляется в результате общих усилий тысяч людей по всему миру. Проект &os; предоставляет анонимный публичный доступ по протоколу CVS[1], так что любой может получить доступ к журналу изменений, разницам (патчам) между ветками разработки и другим продвинутым возможностям, которые даёт строгое управление исходным кодом. Это сильно помогает в привлечении к &os; всё большего количества талантливых разработчиков. Однако, и я думаю, что все со мной согласятся, наступит хаос, если доступ по записи будет открыт всем в Internet. Поэтому только избранная группа примерно из 300 человек имеет доступ по записи в CVS-хранилище. Эти коммиттеры[5] отвечают в целом за разработку &os;. Выбираемая из самых заслуженных разработчиков группа правления[6] обеспечивает некоторый уровень управления проектом. Темп разработок, ведущихся во &os;, оставляет мало времени на тщательную доводку системы до качества продуктивного релиза. Для решения этой проблемы разработка ведётся в два параллельных потока. Основной веткой разработки является HEAD, она же основная линия нашего дерева CVS, известная также под именем &os;-CURRENT или, для краткости, -CURRENT. Поддерживается и более стабильная ветка, известная как &os;-STABLE или, для краткости, -STABLE. Обе ветки находятся в основном CVS-хранилище в Калифорнии и реплицируются при помощи CVSup[2] на зеркала по всему миру. &os;-CURRENT[7] является передним краем работ над FreeBSD, через который попадают все изменения в системе. &os;-STABLE является веткой разработки, из которой создаются основные релизы. В эту ветку изменения попадают разными путями, и предполагается, что сначала они попали в &os;-CURRENT, где были тщательно протестированы сообществом наших пользователей. В промежутке между релизами машинами Проекта &os;, выделенными для построения системы, ежемесячно автоматически собираются снэпшоты, которые доступны для закачки по адресу ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/. Общедоступность снэпшотов бинарных релизов, а также желание сообщества наших пользователей отслеживать работу над -STABLE при помощи CVSup и make world[7] помогает поддержать весьма хорошее качество &os;-STABLE, даже до выполнения мероприятий проверки качества, предваряющих выпуск основных релизов. В процессе выпуска релиза пользователи постоянно присылают сообщения об ошибках и пожелания по расширению функциональности. Сообщения о проблемах попадают в нашу базу данных GNATS[8] по электронной почте, посредством утилиты &man.send-pr.1; или через Web-интерфейс, доступный по адресу http://www.FreeBSD.org/send-pr.html. Для удовлетворения наших самых консервативно настроенных пользователей, начиная с &os; 4.3, появились ветки для отдельных релизов. Эти ветки создаются вскоре после того, как выпускается окончательный релиз. После его выхода в ветку релиза помещаются только самые критичные исправления и добавления, касающиеся безопасности. Кроме обновлений исходных текстов посредством CVS, для систем веток RELENG_X_Y имеются и бинарные наборы патчей. Что обсуждается в данном документе? В последующих главах этой статьи обсуждаются: Различные этапы процесса подготовки релиза вплоть до построения актуальной системы. Процесс сборки. Как базовый релиз может быть расширен третьими сторонами. Некоторые из уроков, полученных при выпуске релиза &os; 4.4. Направления будущих работ. Процесс выпуска релиза Новые релизы &os; выпускаются из ветки -STABLE с интервалом примерно в четыре месяца. Процесс выпуска релизов &os; начинается за 45 дней до предполагаемой даты релиза с того, что ответственный за релиз посылает сообщение по электронной почте в адрес списков рассылки для разработчиков, чтобы напомнить последним о наличии всего лишь 15 дней на внесение новых изменений до момента заморозки кода. В этот период многие разработчики выполняют действия, известные как MFC-переносы. MFC означает Merge From CURRENT (перенос из CURRENT) и описывает процесс переноса протестированных изменений из нашего дерева разработки -CURRENT в наше дерево -STABLE. Просмотр кода За тридцать дней до предполагаемого релиза хранилище исходных текстов переводится в режим стабилизации кода. В этот период все изменения в дереве -STABLE должны подтверждаться &a.re;. В первый 15-дневный период разрешены следующие типы изменений: Исправления ошибок. Обновление документации. Исправления любого характера, касающиеся безопасности. Незначительные исправления в драйверах устройств, такие, как, например, добавление новых ID устройств. Любые другие изменения, которые одобряет группа подготовки релиза, с учётом потенциального риска. После первых 15 дней стабилизации кода выпускается предварительный релиз, предназначенный для широкого тестирования, а код переводится в состояние заморозки, когда становится гораздо труднее доказывать необходимость внесения новых изменений в систему, если они не касаются исправления серьёзных ошибок или информационной безопасности. Во время заморозки кода каждую неделю выпускается не менее одной предварительной версии релиза, до тех пор, пока не будет готов окончательный вариант релиза. В дни, предшествующие выпуску окончательного релиза, группа его подготовки работает в постоянном контакте со службой безопасности и людьми, поддерживающими документацию и порты, чтобы обеспечить доступность всех компонентов, необходимых для успешного выпуска релиза. Контрольный список для проверки окончательного релиза После того, как для широкого тестирования было выпущено несколько предварительных релизов и все основные проблемы были решены, может начаться процесс шлифовки окончательного релиза. Создание ветки релиза Как сказано во вводной части, ветка RELENG_X_Y является сравнительно новым добавлением в нашей методологии подготовки релизов. Первым шагом в создании этой ветки является проверка того, что вы работаете с самой последней версией исходных текстов RELENG_X, из которой вы хотите создать новую ветку. /usr/src&prompt.root; cvs update -rRELENG_4 -P -d Следующим шагом является создание тэга точки ответвления, чтобы диффы облегчили работу с началом ветки в CVS: /usr/src&prompt.root; cvs rtag -rRELENG_4 RELENG_4_8_BP src После этого создаётся тэг новой ветки по команде: /usr/src&prompt.root; cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src Использование тэгов RELENG_* разрешено только менеджерам CVS и участникам группы по выпуску релизов. Тэгом в понятии CVS называют метку, которая идентифицирует исходный текст в некоторый момент времени. Вводя тэг в дерево, мы обеспечиваем то, что в будущем тот, кто строит релиз, всегда сможет воспользоваться тем же самым кодом, что использовался нами для создания официальных релизов Проекта &os;. Ветви разработки &os; Ветка &os; 3.x STABLE Ветка &os; 4.x STABLE Ветка &os; 5.x STABLE Ветка &os; 6.x STABLE Ветка &os; 7.x STABLE Ветка &os; 8.x STABLE Ветка &os; 9.x STABLE Увеличение номера версии Перед тем, как окончательный релиз будет помечен, построен и выпущен, необходимо модифицировать следующие файлы, отразив в них корректную версию &os;: doc/ru_RU.KOI8-R/books/handbook/mirrors/chapter.xml doc/en_US.ISO8859-1/books/porters-handbook/book.xml doc/share/xml/freebsd.ent src/Makefile.inc1 src/UPDATING src/gnu/usr.bin/groff/tmac/mdoc.local src/release/Makefile src/release/doc/en_US.ISO8859-1/share/xml/release.dsl src/release/doc/share/examples/Makefile.relnotesng src/release/doc/share/xml/release.ent src/share/examples/cvsup/standard-supfile src/sys/conf/newvers.sh src/sys/sys/param.h src/usr.sbin/pkg_install/add/main.c www/en/docs/man.xml www/en/cgi/ports.cgi ports/Tools/scripts/release/config Новый релиз должен быть также отражён в файлах замечаний к релизу и информации о замеченных ошибках (в ветке релиза), а файлы соответствующим образом обрезаны (в ветке stable/current): src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml src/release/doc/en_US.ISO8859-1/errata/article.xml Утилита sysinstall должна быть обновлена и указывать количество доступных портов и объём дискового пространства, требуемого для Коллекции Портов[4]. На данный момент эта информация хранится в файле src/usr.sbin/sysinstall/dist.c. После построения релиза для оповещения мирового сообщества о выпуске релиза необходимо обновить некоторые файлы. doc/share/images/articles/releng/branches-relengX.pic www/share/xml/advisories.xml www/share/xml/includes.release.xml www/share/xml/includes.release.xsl www/en/releases/* www/en/releng/index.xml www/en/news/news.xml www/en/search/web.atoz src/share/misc/bsd-family-tree Подготовка новой старшей релиз ветки (RELENG_<replaceable>X</replaceable>) Когда новая старшая релиз ветка, такая как RELENG_6 ответвляется из HEAD, некоторые дополнительные файлы должны быть обновлены перед тем, как релизы будут созданы из этой новой ветки. src/share/examples/cvsup/stable-supfile - когда применимо, должен быть обновлен, чтобы указывать на новую -STABLE ветку. Создание тэгов релиза При готовности окончательного релиза следующая команда создаст тэг RELENG_4_8_0_RELEASE. /usr/src&prompt.root; cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src Менеджеры документации и портов отвечают за внесение тэга в соответствующие ветки с тэгом RELEASE_4_8_0. Иногда в последний момент, уже после создания последних тэгов может потребоваться внесение исправлений. На практике это не является проблемой, так как CVS позволяет выполнять манипуляции с тэгами по команде cvs tag -d tagname filename. Очень важно, чтобы все последние изменения были помечены соответствующим тэгом, как часть релиза. Релизы &os; должны быть всегда повторяемыми. Локальные изменения в параметры окружения выпускающего релиз недопустимы. Построение релизов Релизы &os; могут быть построены любым человеком, имеющим быстродействующую машину и доступ к хранилищу исходных текстов. (Это должен быть любой, так как мы предоставляем анонимный доступ к CVS! Обратитесь к Руководству для прояснения деталей.) Единственным особым требованием является наличие устройства &man.md.4;. Если устройство в вашем ядре не подгружено, то модуль ядра должен быть подгружен автоматически при выполнении команды &man.mdconfig.8; на этапе создания носителя для загрузки. Все инструменты, необходимые для построения релиза, доступны из хранилища CVS в каталоге src/release. Эти инструменты предоставляют единый метод построения релизов &os;. Полный релиз может быть реально построен при помощи лишь одной команды, включая создание ISO-образов, подходящих для записи на CDROM, установочных дискет и установочного каталога FTP. Эта команда называется соответствующим образом: make release. <command>make release</command> Для успешного построения релиза вы должны сначала заполнить каталог /usr/obj, запустив команду make world или просто make buildworld. Цель, выполняемая для построения релиза, требует корректного задания нескольких переменных, используемых при его сборке: CHROOTDIR - Каталог, используемый в среде с изменённой корневой файловой системой при построении полного релиза. BUILDNAME - Наименование строящегося релиза. CVSROOT - Местонахождение CVS-хранилища. RELEASETAG - Тэг CVS, соответствующий релизу, который вы собираетесь строить. Если у вас ещё нет доступа к локальному CVS-хранилищу, то вы можете зеркалировать одно из них при помощи CVSup. Поставляемый sup-файл, /usr/share/examples/cvsup/cvs-supfile, может служить хорошей отправной точкой для зеркалирования хранилища CVS. Если RELEASETAG опущен, то релиз будет строиться из ветки HEAD (известной как -CURRENT). Релизы, строящиеся из этой ветки обычно называют снэпшотами -CURRENT. Для настройки построения релиза существует много других переменных Большинство из этих переменных описаны в начале файла src/release/Makefile. Точная команда, служащая для построения официального релиза &os; 4.7 (x86) такова: make release CHROOTDIR=/local3/release \ BUILDNAME=4.7-RELEASE \ CVSROOT=/host/cvs/usr/home/ncvs \ RELEASETAG=RELENG_4_7_0_RELEASE Makefile для релиза может быть разбит на несколько различных шагов. Создание чистого системного окружения в отдельной иерархии каталогов по команде make installworld. Выгрузка из CVS чистой версии исходных текстов системы, документации и портов в иерархию для построения релиза. Создание копии /etc и /dev в окружении с изменённым корнем файловой системы. Смена корневой файловой системы на иерархию построения релиза, чтобы избежать влияния внешнего окружения на построение. Выполнение make world в окружении с изменённой корневой файловой системой. Построение бинарных файлов для работы с Kerberos. Построение ядра GENERIC. Создание промежуточного дерева каталогов, где будут строиться бинарные файлы и формироваться дистрибутивы. Построение и установка инструментов для работы с документацией, необходимых для преобразования исходных текстов документации (SGML) в формат HTML и текстовые документы, которые сопутствуют релиз. Построение и установка актуальной документации (руководства пользователей, учебники, замечания к релизу, перечень аппаратной совместимости и так далее.) Построение свёрнутых бинарных файлов, используемых на установочных дискетах. Подготовка дистрибутивных архивов бинарных файлов и исходных текстов. Создание загрузочного носителя и fixit-дискеты. Создание иерархии для установки при помощи FTP. (опционально) Создание образов ISO для носителей CDROM/DVD. Для получения более полной информации об инфраструктуре построения релизов, пожалуйста, обратитесь к справочной странице по &man.release.7;. Важно, чтобы из файла /etc/make.conf были удалены все установки, специфичные для конкретного хоста. К примеру, будет глупо распространять бинарные файлы, построенные на системе с переменной CPUTYPE, указывающей на определённый тип процессора. Программное обеспечение третьих лиц (<quote>ports</quote>) Коллекция портов &os; содержит более &os.numports; программных пакетов сторонних разработчиков, которые доступны для &os;. За поддержку целостности дерева портов, которое может использоваться для создания бинарных пакетов, поставляемых с официальными релизами &os;, отвечает &a.portmgr;. Рассмотрение работ с нашей коллекцией пакетов сторонних разработчиков при подготовке релизов выходит за рамки этого документа. Этот вопрос глубоко рассмотрен в отдельной статье, &art.re.pkgs;. ISO с релизами Начиная с &os; 4.4, Проект &os; принял решение распространять все четыре образа ISO, ранее продаваемые через BSDi/Wind River Systems/FreeBSD Mall как официальные дистрибутивы на CDROM. Каждый из четырёх дисков должен содержать файл README.TXT, описывающий содержимое диска, файл CDROM.INF, в котором находятся мета-данные о диске для того, чтобы &man.sysinstall.8; мог проверять и использовать содержимое, а также файл filename.txt, содержащий перечень содержимого на диске. Этот перечень может быть создан простой командой: /stage/cdrom&prompt.root; find . -type f | sed -e 's/^\.\///' | sort > filename.txt Специфичные требования для каждого CD описываются ниже. Диск 1 Первый диск практически полностью создаётся командой make release. Единственным изменением, которое нужно внести в каталог disc1, является добавление подкаталога tools, а также перенос максимально возможного количества программных пакетов сторонних разработчиков, которые поместятся на диск. Каталог tools содержит программное обеспечение, позволяющее пользователям создавать установочные дискеты из других операционных систем. Этот диск нужно сделать загрузочным, чтобы пользователям современных ПК не нужно было создавать установочные дискеты. Если в релиз необходимо включить специализированное ядро, то необходимо модифицировать &man.sysinstall.8; и &man.release.7;, добавив в них инструкции по установке. Соответствующий код находится в src/release и src/usr.sbin/sysinstall. В частности, в src/usr.sbin/sysinstall необходимо будет редактировать src/release/Makefile, dist.c, dist.h, menus.c, install.c и Makefile. Также может потребоваться обновить sysinstall.8. Диск 2 Второй диск также в основном создаётся по команде make release. Он содержит живую файловую систему, которую можно использовать из &man.sysinstall.8; для исправления процесса установки &os;. Этот диск должен быть загрузочным и содержать также упакованную копию хранилища CVS в каталоге CVSROOT и демонстрационные версии коммерческого программного обеспечения в каталоге commerce. Диски 3 и 4 Оставшиеся два диска содержат дополнительные программные пакеты для &os;. Они должны быть объединены в группы (кластеры), чтобы отдельный пакет и все его зависимости находились на одном и том же диске. Дополнительная информация о создании этих дисков находится в статье &art.re.pkgs;. Поддержка нескольких дисков Sysinstall поддерживает установку пакетов с нескольких дисков. Для это нужно, чтобы на каждом диске был файл INDEX, содержащий названия всех пакетов со всех дисков, с дополнительным полем, указывающем на каком диске содержится данный конкретный пакет. Также, на каждом диске, в файле cdrom.inf должна быть указана переменная CD_VOLUME для того, чтобы sysinstall мог определить какой этой диск. Когда пользователь будет пытаться установить пакет, которого нет на текущем диске, sysinstall выдаст запрос на вставку соответствующего диска. Распространение Серверы FTP После того, как релиз был тщательно протестирован и подготовлен к распространению, должен быть обновлён главный FTP-сервер. Все официальные общедоступные серверы FTP-серверы &os; являются зеркалами главного сервера, открытого только другим серверам FTP. Этот сервер известен под именем ftp-master. Когда релиз готов, на сервере ftp-master должны быть изменены следующие строки: /pub/FreeBSD/releases/arch/X.Y-RELEASE/ Установочный каталог FTP, получаемый по команде make release. /pub/FreeBSD/ports/arch/packages-X.Y-release/ Полный комплект построенных пакетов для этого релиза. /pub/FreeBSD/releases/arch/X.Y-RELEASE/tools Символическая ссылка на ../../../tools. /pub/FreeBSD/releases/arch/X.Y-RELEASE/packages Символическая ссылка на ../../../ports/arch/packages-X.Y-release. /pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso ISO-образы. Здесь * это disc1, disc2 и так далее. Только если здесь есть disc1 и альтернативный первый установочный CD (например, обрезанная установка без оконной системы), то здесь может быть также и mini. Для получения дополнительной информации о системе зеркальных FTP-серверов &os;, пожалуйста, прочтите статью о Зеркалировании &os;. Может пройти от нескольких часов до двух дней между тем, как обновится ftp-master, и на основной массе FTP-серверов 1-го уровня появится новое программное обеспечение, в зависимости от того, в тоже самое ли время пакет был загружен. Обязательно, чтобы выпускающие релиз координировали свои действия с &a.mirror-announce; до того, как объявлять об общедоступности нового программного обеспечения с серверов FTP. В идеальном случае набор пакетов к релизу должен быть загружен по крайней мере за четыре дня до момента выпуска релиза. Релиз должен быть загружен в промежутке от 24 до 48 часов до момента выхода запланированного релиза с выключенными полномочиями other. Это позволит зеркалирующим серверам сгрузить его, но никто не сможет получить его с зеркальных серверов. В момент выхода релиза должно быть послано сообщение в адрес &a.mirror-announce;, говорящее о том, что релиз выпущен и наступило время для открытия доступа на зеркальных серверах. Обязательно вместе со временем укажите и часовой пояс, например, относительно GMT. Тиражирование CD-ROM Вскоре появится: Советы по передаче ISO-образов &os; на тиражирование и применяемые меры по контролю качества. Расширяемость Хотя &os; представляет собой законченную операционную систему, ничего не заставляет вас использовать систему только в том виде, который приготовлен нами для распространения. Мы попытались спроектировать систему максимально расширяемой, чтобы она могла выполнять роль платформы, на основе которой можно строить другие коммерческие продукты. Единственным правилом, которое мы налагаем, является настоятельная рекомендация документировать улучшения, вносимые вами в дистрибутив &os; с нетривиальными изменениями! Сообщество &os; может помогать только пользователям того программного обеспечения, которое распространяем мы. Мы определённо приветствуем улучшения в форме, например, инструментов установки и администрирования, но не можем отвечать на вопросы о них. Создание модифицированных загрузочных дискет Во многих местах имеются сложные условия, которые требуют размещения дополнительных модулей ядра или пользовательских инструментов на установочные дискеты. Быстрым и неаккуратным способом сделать это является изменение промежуточного каталога в существующей иерархии при выполнении make release: Примените патчи или добавьте дополнительные файлы в каталог построения релиза с изменённых корнем файловой системы. rm ${CHROOTDIR}/usr/obj/usr/src/release/release.[59] перестройте &man.sysinstall.8;, ядро и остальные части системы, которые коснулись ваши изменения. chroot ${CHROOTDIR} ./mk floppies Дискеты нового релиза будут находиться в ${CHROOTDIR}/R/stage/floppies. Либо может быть вызвана цель boot.flp построения или скрипт создания файловой системы, src/release/scripts/doFS.sh, которые может быть вызван напрямую. Локальные патчи могут быть также приложены к построению релиза при помощи задания переменной LOCAL_PATCH при выполнении make release. Скрипты <command>sysinstall</command> Инструмент установки и настройки системы &os;, &man.sysinstall.8;, может работать по сценарию, полезному для автоматизированной установки в больших компаниях. Эта функциональность может использоваться совместно с технологией &intel; PXE[12] для первоначальной установки систем из сети, или с модифицированными загрузочными дискетами со скриптами sysinstall. Пример скрипта для sysinstall доступен в дереве CVS в виде файла src/release/sysinstall/install.cfg. Уроки, извлечённые из &os; 4.4 Формально процесс подготовки релиза для 4.4 начался 1 августа 2001 года. После этой даты все без исключения изменения в ветке RELENG_4 &os; подтверждались &a.re;. Первый предварительный релиз для архитектуры x86 был выпущен 16 августа, за ним выходило ещё 4 предварительных релиза, и всё закончилось 18 августа выпуском окончательного релиза. Руководитель службы безопасности очень плотно занимался процессом выпуска в последнюю неделю, так как в предыдущих предварительных релизах были найдены проблемы, касающиеся информационной безопасности. Чуть более чем за месяц в адрес &a.re; поступило более 500 писем. Сообщество наших пользователей весьма чётко показало, что безопасность и стабильность релиза &os; не должна приноситься в жертву любым назначенным срокам окончания работ или планируемым датам выхода релиза. Проект &os; за время своего существования значительно вырос, и никогда ранее необходимость в стандартизации процедур подготовки релизов не стояла так остро. Это стало ещё более важно, когда &os; была перенесена на новые аппаратные платформы. Направления будущих работ Нашим работам по подготовке релизов жизненно важно расти вместе с увеличением количества пользователей системы. Вместе с этим мы очень плотно работаем над документированием действий, выполняемых при выпуске релизов &os;. Параллелизм - некоторые этапы построения релиза на самом деле выполнять параллельно затруднительно. Большинство выполняемых задач весьма интенсивно работают с I/O, так что для ускорения процесса make release наличие нескольких высокоскоростных дисков гораздо более важно, чем использование нескольких процессоров. Если для различных иерархий в &man.chroot.2;-окружении используется несколько дисков, то извлечение из CVS деревьев ports и doc может выполняться одновременно с командой make world на другом диске. Использование RAID-решений (аппаратных или программных) может значительно сократить общее время построения. Кроссплатформенное построение релизов - Построить релиз для IA-64 или Alpha на x86-оборудовании? make TARGET=ia64 release. Тестирование - Нам нужна улучшенная автоматизированная система тестирования корректности для &os;. Инструменты установки - Наша программа установки давно пережила свой век. В разработке находятся несколько проектов, которые должны дать улучшенную технологию установки. Одним из таких проектов был libh, целью которого было создание новой интеллектуальной технологии работы с пакетами и программы установки с GUI. Благодарности Я рад поблагодарить Джордана Хаббарда (Jordan Hubbard) за то, что он дал мне возможность взять под свою ответственность некоторые части процесса подготовки релиза &os; 4.4, а также за все годы его работы, сделавшие &os; такой, какой она является сейчас. Конечно, релиз не был бы возможен без той работы, которую проделали &a.asami.email;, &a.steve.email;, &a.bmah.email;, &a.nik.email;, &a.obrien.email;, &a.kris.email;, &a.jhb.email; и остальные члены сообщества разработчиков &os;. Я также рад выразить благодарность &a.rgrimes.email; и &a.phk.email;, а также остальным, работавшим над инструментами подготовки релизов в первые годы существования &os;. Эта статья была также написана под впечатлением документации по подготовке релизов от CSRG[13], NetBSD Project[10] и замечаний Джона Балдвина (John Baldwin) по предлагаемому процессу подготовки релизов[11]. Справочная литература [1] CVS - Concurrent Versions System http://www.cvshome.org [2] CVSup - The CVS-Optimized General Purpose Network File Distribution System http://www.polstra.com/projects/freeware/CVSup [3] http://pointyhat.FreeBSD.org [4] Коллекция портов &os; http://www.FreeBSD.org/ports [5] Коммиттеры &os; http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-committers.html [6] Правление &os; &url.base;/administration.html#t-core [7] Руководство &os; http://www.FreeBSD.org/doc/ru_RU.KOI8-R/books/handbook [8] GNATS: The GNU Bug Tracking System http://www.gnu.org/software/gnats [9] Статистика &os; PR http://www.FreeBSD.org/prstats/index.html [10] NetBSD Developer Documentation: Release Engineering http://www.NetBSD.org/developers/releng/index.html [11] John Baldwin's &os; Release Engineering Proposal http://people.FreeBSD.org/~jhb/docs/releng.txt [12] PXE Jumpstart Guide http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/pxe/index.html [13] Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: The Release Engineering of 4.3BSD
diff --git a/ru_RU.KOI8-R/articles/solid-state/Makefile b/ru_RU.KOI8-R/articles/solid-state/Makefile index 18eb92fc82..1d36d5f63d 100644 --- a/ru_RU.KOI8-R/articles/solid-state/Makefile +++ b/ru_RU.KOI8-R/articles/solid-state/Makefile @@ -1,22 +1,22 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/solid-state/Makefile,v 1.4 2006/03/28 16:20:06 gad Exp $ # -# Original revision: r20561 +# Original revision: r39631 # # Article: FreeBSD and Solid State Devices DOC?= article FORMATS?= html WITH_ARTICLE_TOC?=YES INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/solid-state/article.xml b/ru_RU.KOI8-R/articles/solid-state/article.xml index fe3e5faee4..7cd6a77dec 100644 --- a/ru_RU.KOI8-R/articles/solid-state/article.xml +++ b/ru_RU.KOI8-R/articles/solid-state/article.xml @@ -1,479 +1,479 @@
FreeBSD и твердотельные устройства JohnKozubik
john@kozubik.com
 2001 2009 The FreeBSD Documentation Project $FreeBSD$ $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.general; &legalnotice; В этой статье описывается использование твердотельных дисковых устройств для создания встраиваемых систем на основе &os; Встраиваемые системы имеют преимущество в повышенной надежности по причине отсутствия в них движущихся частей (жестких дисков). Однако, следует принять во внимание, что системе, как правило, доступно очень малое дисковое пространство и ограниченный объем запоминающего устройства. К отдельно рассматриваемым вопросам относятся типы и характеристики твердотельных носителей, подходящих для использования в качестве дисков во &os;, параметры ядра, которые представляют интерес в таких условиях, механизмы rc.initdiskless, автоматизирующие инициализацию таких систем и удовлетворяющие требованиям файловых систем, доступных только для чтения, а также построение файловых систем с нуля. Статья заканчивается описанием некоторых общих стратегий для случаев малых систем &os; и работ в режиме только для чтения. Твердотельные дисковые устройства Эта статья будет ограничиваться рассмотрением твердотельных дисковых устройств, которые делаются на основе флэш-памяти. Флэш-память является твердотельным (здесь нет движущихся частей) запоминающим устройством, которое является энергонезависимым (данные остаются в памяти даже после отключения всех источников питания). Флэш-память может быть нечувствительной к сильным физическим воздействиям и достаточно быстра (решения на основе флэш-памяти, описываемые в этой статье, гораздо медленнее, чем диски EIDE для операций записи, и гораздо быстрее их в случае выполнения операций чтения). Одним из очень важных свойств флэш-памяти, различные варианты которого будут рассмотрены далее в этой статье, является то, что каждый сектор имеет ограниченные возможности по перезаписыванию. Вы можете только записывать, стирать и снова записывать на сектор флэш-памяти определенное количество раз до того, как сектор станет полностью неработоспособным. Хотя многие продукты на основе флэш-памяти автоматически перенаправляют испорченные блоки, а некоторые даже распределяют операции записи по всему модулю, фактом является наличие ограничения на количество операций записи, которые могут выполняться с устройством. Современные модули имеют характеристики от 1,000,000 до 10,000,000 циклов записи на сектор. Эти характеристики могут зависеть от температуры рабочей среды. В частности, мы обсудим компактные модули флэш-памяти, совместимые со стандартом ATA, которые стали весьма популярными в качестве носителя данных для цифровых камер. Особый интерес представляет тот факт, что они соответствуют шине IDE по контактам и совместимы с набором команд ATA. Таким образом, при помощи очень простого и дешевого адаптера такие устройства могут подключаться непосредственно к шине IDE компьютера. Если поступить таким образом, то такие операционные системы, как &os;, распознают диск как обычный винчестер (весьма маленький). Существуют и другие решения для твердотельных дисков, но их стоимость, безвестность и сравнительная сложность использования выводят их за рамки этой статьи. Параметры ядра Для тех, кто создает встраиваемую систему &os;, интерес представляют несколько параметров ядра. Все встраиваемые системы &os;, которые используют флэш-память в качестве системного диска, заинтересованы в использовании дисков в памяти и файловых систем в памяти. Из-за ограниченного количества циклов записи, которые можно выполнить с флэш-памятью, диск и файловые системы на нем будут, скорее всего, монтироваться в режиме доступа только для чтения. В таком случае файловые системы типа /tmp и /var монтируются как файловые системы в памяти для того, чтобы позволить системе создать журналы и обновить счетчики и временные файлы. Файловые системы в памяти являются критическим компонентом успешной работы &os; на твердотельных устройствах. Вы должны удостовериться, что в конфигурационном файле вашего ядра присутствуют следующие строки: options MFS # Memory Filesystem options MD_ROOT # md device usable as a potential root device pseudo-device md # memory disk Подсистема <literal>rc</literal> и файловые системы в режиме только чтения Инициализация встраиваемой системы &os; после загрузки управляется /etc/rc.initdiskless. /etc/rc.d/var монтирует /var как файловую систему в памяти, создает указываемый список каталогов в /var при помощи команды &man.mkdir.1;, изменяет режимы доступа на некоторые из этих каталогов. В процессе выполнения /etc/rc.d/var задействуется еще одна переменная rc.conf – varsize. Скрипт /etc/rc.d/var создает раздел /var на основе значения этой переменной из rc.conf: varsize=8192 Запомните, что по умолчанию это значение указано в секторах. Факт использования файловой системы /var в режиме чтения и записи является важным признаком, так как раздел / (и любые другие разделы, которые могут находиться на флэш-носителе) должен монтироваться в режиме только для чтения. Вспомните, что в мы касались ограничений флэш-памяти - особенно ограничений, касающихся возможностей записи. Важно не монтировать файловые системы на флэш-носителях в режимах чтения и записи, и важность отказа от файла подкачки не может быть переоценена. Файл подкачки на загруженной системе может пережечь кусок флэш-носителя менее чем за год. Частое журналирование и создание временных файлов приводят к тому же результату. Поэтому, кроме удаления записи swap из вашего файла /etc/fstab, вы должны также изменить поле параметров каждой файловой системы на ro таким образом: # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1a / ufs ro 1 1 В результате этих изменений в среднестатистической системе несколько приложений немедленно перестанут работать. Например, cron не будет нормально запускаться в результате отсутствия таблиц для него в каталоге /var, созданном /etc/rc.d/var, а syslog и dhcp будут испытывать проблемы из-за доступа файловой системы только для чтения, а также отсутствия записей в /var, который был создан скриптом /etc/rc.d/var. Хотя эти проблемы являются временными и обсуждаются вместе с решением проблем с запуском распространенных программных пакетов, в . Важно помнить, что файловая система, которая была смонтирована только для чтения при помощи файла /etc/fstab, в любой момент может быть сделана доступной по чтению и записи выдачей команды: &prompt.root; /sbin/mount -uw partition и может быть возвращена к режиму доступа только для чтения по такой команде: &prompt.root; /sbin/mount -ur partition Создание файловой системы с нуля Так как совместимые с ATA компактные флэш-карты распознаются во &os; как обычные жесткие диски IDE, то теоретически вы можете установить &os; по сети при помощи дискет kern и mfsroot или с компакт-диска. Однако даже маленькая установка &os; при помощи обычных процедур установки может привести к созданию системы размером, превышающим 200 мегабайт. Так как большинство людей используют устройства флэш-памяти меньшего размера (128 мегабайт считается весьма большим - 32 или даже 16 мегабайт используются гораздо чаще), то установка обычным образом не подходит—просто на диске нет места даже для самой минимальной установки. Самым простым способом обойти это ограничение на объем является установка &os; обычным образом на обычный жесткий диск. После окончания установки, обрежьте операционную систему до размера, который помещается на ваш флэш-носитель, а затем полностью заархивируйте файловую систему. Следующие шаги поведут вас через процесс подготовки части флэш-памяти для вашей заархивированной файловой системы. Запомните, что из-за того, что обычная установка не выполнялась, такие операции, как разбиение на разделы, разметка, создание файловой системы и так далее должны быть выполнены вручную. Кроме дискет kern и mfsroot вам также нужно воспользоваться дискетой fixit. Разбиение вашего флэш-носителя на разделы После загрузки при помощи дискет kern и mfsroot, выберите пункт custom из меню установки. Из следующего пункта меню выберите partition. В меню работы с разделами вы должны удалить все существующие разделы при помощи клавиши d. После удаления всех имеющихся разделов создайте раздел при помощи клавиши c и согласитесь с предлагаемым по умолчанию размером раздела. Когда вы будете опрошены на предмет типа раздела, удостоверьтесь, что значение типа равно 165. Теперь запишите эту таблицу разделов на диск, нажав клавишу w (на этом экране эта опция скрыта). Если вы используете компактную флэш-карту, совместимую с ATA, вы должны выбрать FreeBSD Boot Manager. Теперь нажмите клавишу q для выхода из меню работы с разделами. Должно быть выдано еще раз меню для выбора менеджера загрузки - повторите то, что вы выбирали ранее. Создание файловых систем на вашем устройстве флэш-памяти Выйдите из меню установки custom, и из главного меню установки выберите пункт fixit. После входа в режим работы fixit, введите следующую команду: &prompt.root; disklabel -e /dev/ad0c В этот момент вы войдете в редактор vi из-под команды disklabel. Затем, вам нужно добавить строку a: в конце файла. Эта строка a: должна выглядеть примерно так: a: 123456 0 4.2BSD 0 0 Здесь 123456 является числом, в точности совпадающим с тем, что характеризует размер имеющейся записи для c:. В общем, вы копируете существующую строку для c: для строки a:, не забывая определить fstype как 4.2BSD. Сохраните файл и завершите редактирование. &prompt.root; disklabel -B -r /dev/ad0c &prompt.root; newfs /dev/ad0a Размещение вашей файловой системы на флэш-носителе Смонтируйте только что подготовленный флэш-носитель: &prompt.root; mount /dev/ad0a /flash Подключите эту машину к сети, чтобы можно было перенести наш tar-файл и распаковать его в файловую систему на флэш-носителе. Вот пример того, как это можно сделать: &prompt.root; ifconfig xl0 192.168.0.10 netmask 255.255.255.0 &prompt.root; route add default 192.168.0.1 Теперь, когда машина находится в сети, перепишите ваш tar-файл. Здесь вы можете столкнуться с некоторой проблемой - если объем вашей флэш-памяти равен, к примеру, 128 мегабайтам, а ваш tar-файл превышает 64 мегабайта, то вы не можете одновременно разместить tar-файл на флэш-носителе и распаковать его - вам не хватит места. Одним из решений этой проблемы, если вы используете FTP, является распаковка файла во время его передачи по FTP. Если вы передаете файл именно так, то вы никогда не получите на диске одновременно архивный файл и его содержимое: ftp> get tarfile.tar "| tar xvf -" Если ваш файл обработан утилитой gzip, вы также можете этого добиться: ftp> get tarfile.tar "| zcat | tar xvf -" После того, как вы получили содержимое вашей заархивированной файловой системы на файловой системе флэш-памяти, вы можете размонтировать флэш-память и выполнить перезагрузку: &prompt.root; cd / &prompt.root; umount /flash &prompt.root; exit Полагая, что вы правильно настроили вашу файловую систему при ее построении на обычном диске (с вашей файловой системой, смонтированной в режиме доступа только для чтения, и необходимыми параметрами, присутствующими в ядре) вы должны успешно загрузить вашу встраиваемую систему на основе &os;. Стратегии работы с системой для случаев небольших и доступных только для чтения файловых систем В было указано, что файловая система /var, создаваемая скриптом /etc/rc.d/var, и наличие корневой файловой системы, доступной только для чтения, приводят к проблемам при работе многих распространенных программных пакетов, используемых во &os;. В этой статье будут даны рекомендации по настройке нормальной работы cron и syslog, установке портов и веб-сервера Apache. cron Во время загрузки содержимое каталогa /var формируется скриптом /etc/rc.d/var используя данные из /etc/mtree/BSD.var.dist, поэтому в нем создается несколько стандартных каталогов, в числе которых — cron, cron/tabs, at. Однако это не решает проблему с сохранением cron-таблиц между перезагрузками. Когда система перезагружается, то файловая система /var, которая располагается в памяти, будет уничтожена, вместе со всеми cron-таблицами, которые вы могли там иметь. Поэтому одним из решений может стать создание cron-таблиц для пользователей, которым они нужны, монтирование вашей файловой системы / в режиме чтения и записи, и копирование этих cron-таблиц в безопасное место, например, в /etc/tabs, и последующее добавление строки в конец скрипта /etc/rc.initdiskless для копирования этих cron-таблиц в каталог /var/cron/tabs после его создания во время инициализации системы. Вам может также потребоваться добавить строку, которая изменяет режимы доступа и права на каталоги, которые вы создали, и на файлы, которые вы скопировали в скрипте /etc/rc.initdiskless. syslog В файле syslog.conf задано местоположение некоторых файлов протоколов, которые имеются в каталоге /var/log. Эти файлы не создаются скриптом /etc/rc.d/var во время инициализации системы. Поэтому где-нибудь в скрипте /etc/rc.d/var, после секции, создающей каталоги в /var, вам нужно добавить нечто вроде следующего: &prompt.root; touch /var/log/security /var/log/maillog /var/log/cron /var/log/messages &prompt.root; chmod 0644 /var/log/* Установка портов Перед тем, как обсудить изменения, которые нужно сделать для успешного использования дерева портов, необходимо напомнить о том, что ваши файловые системы на флэш-носителях доступны только для чтения. Поэтому вам нужно временно монтировать их в режиме чтения и записи, используя параметры командной строки, как это показано в . Вы всегда должны перемонтировать эти файловые системы в режим только для чтения после окончания работ - излишние записи на флеш носитель могут значительно сократить его срок эксплуатации. Чтобы можно было войти в каталог с портами и успешно выполнить команду make install, необходимо создать каталог для пакаджей в файловой системе, не располагающейся в памяти, где будут храниться пакаджи между перезагрузками. Так как для установки пакаджа в любом случае требуется монтирование ваших файловых систем для чтения и записи, имеет смысл выделить область флэш-носителя также и для записи информации о пакадже. Прежде всего создайте каталог с базой данных о пакаджах. Обычно это каталог /var/db/pkg, но мы не можем разместить базу именно здесь, так как она исчезнет после перезагрузки системы. &prompt.root; mkdir /etc/pkg Теперь в скрипт /etc/rc.d/var добавьте строку, которая связывает каталог /etc/pkg с /var/db/pkg. Например: &prompt.root; ln -s /etc/pkg /var/db/pkg Теперь каждый раз при монтировании ваших файловых систем для чтения и записи и установки пакаджа, команда make install будет работать, а информация о пакадже будет успешно записана в каталог /etc/pkg (так как файловая система будет в это время смонтирована для чтения и записи), который всегда будет доступным операционной системе как /var/db/pkg. Веб-сервер Apache Шаги, описанные в этой части статьи, необходимо выполнить лишь в том случае, если Apache настроен сохранять свой pid или лог файл вне каталога /var. С настройками по умолчанию Apache формирует свой pid файл в /var/run/httpd.pid, а лог файлы — в /var/log. Далее в статье подразумевается, что Apache сохраняет свои лог файлы в каталог apache_log_dir вне каталога /var. Когда этот каталог расположен на файловой системе, смонтированной в режиме только для чтения, Apache не сможет сохранять лог файлы, что в свою очередь может вызывать проблемы в работе веб-сервера. В таком случае необходимо добавить новый каталог к списку каталогов из /etc/rc.d/var для их создания в каталоге /var и связать apache_log_dir с /var/log/apache. Нужно также задать права доступа и владельца нового каталога. Сначала добавьте каталог log/apache к списку каталогов, создаваемых скриптом /etc/rc.d/var. Затем добавьте в скрипт /etc/rc.d/var после секции создания каталогов такие команды: &prompt.root; chmod 0774 /var/log/apache &prompt.root; chown nobody:nobody /var/log/apache И наконец, удалите существующий каталог apache_install/logs и замените его ссылкой: &prompt.root; rm -rf apache_log_dir &prompt.root; ln -s apache_log_dir
diff --git a/ru_RU.KOI8-R/articles/vm-design/Makefile b/ru_RU.KOI8-R/articles/vm-design/Makefile index 34e3bc8d74..b2543022ea 100644 --- a/ru_RU.KOI8-R/articles/vm-design/Makefile +++ b/ru_RU.KOI8-R/articles/vm-design/Makefile @@ -1,26 +1,26 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/vm-design/Makefile,v 1.6 2005/06/12 04:12:31 gad Exp $ # -# Original revision: r20561 +# Original revision: r39631 # # Article: Design elements of the FreeBSD VM system DOC?= article FORMATS?= html WITH_ARTICLE_TOC?= YES INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml IMAGES_EN= fig1.eps IMAGES_EN+= fig2.eps IMAGES_EN+= fig3.eps IMAGES_EN+= fig4.eps DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/vm-design/article.xml b/ru_RU.KOI8-R/articles/vm-design/article.xml index 631d96a252..de019aa026 100644 --- a/ru_RU.KOI8-R/articles/vm-design/article.xml +++ b/ru_RU.KOI8-R/articles/vm-design/article.xml @@ -1,981 +1,981 @@
Элементы архитектуры системы виртуальной памяти во &os; MatthewDillon
dillon@apollo.backplane.com
&tm-attrib.freebsd; &tm-attrib.linux; &tm-attrib.microsoft; &tm-attrib.opengroup; &tm-attrib.general; $FreeBSD$ $FreeBSD$ Название статьи говорит лишь о том, что я попытаюсь описать в целом VM-систему понятным языком. Последний год я сосредоточил усилия в работе над несколькими основными подсистемами ядра &os;, среди которых подсистемы VM и подкачки были самыми интересными, а NFS оказалась необходимой рутиной. Я переписал лишь малую часть кода. Что касается VM, то я единственным большим обновлением, которое я сделал, является переделка подсистемы подкачки. Основная часть моей работы заключалась в зачистке и поддержке кода, с единственной заметной переделкой кода и без значительной переделки алгоритмов в VM-подсистеме. В основном теоретическая база работы VM-подсистемы осталась неизменной, а большинство благодарностей за современных нововведения за последние несколько лет принадлежат John Dyson и David Greenman. Не являясь историком, как Керк, я не буду пытаться связать различные возможности системы с именами, потому что обязательно ошибусь. Первоначально эта статья была опубликована в номере DaemonNews за январь 2000 года. Эта версия статьи может включать добавления, касающиеся изменений в реализации VM во &os; от Мэтта и других авторов. Введение Перед тем, как перейти непосредственно к существующей архитектуре, потратим немного времени на рассмотрение вопроса о необходимости поддержки и модернизации любого длительно живущего кода. В мире программирования алгоритмы становятся более важными, чем код, и именно из-за академических корней BSD изначально большое внимание уделялось проработке алгоритмов. Внимание, уделенное архитектуре, в общем отражается на ясности и гибкости кода, который может быть достаточно легко изменен, расширен или с течением времени заменен. Хотя некоторые считают BSD старой операционной системой, те их нас, кто работает над ней, видят ее скорее системой со зрелым кодом с различными компонентами, которые были заменены, расширены или изменены современным кодом. Он развивается, и &os; остается передовой системой, вне зависимости от того, насколько старой может быть часть кода. Это важное отличие, которое, к сожалению, не всеми понимается. Самой большой ошибкой, которую может допустить программист, является игнорирование истории, и это именно та ошибка, которую сделали многие другие современные операционные системы. Самым ярки примером здесь является &windowsnt;, и последствия ужасны. Linux также в некоторой степени совершил эту ошибку—достаточно, чтобы мы, люди BSD, по крайней мере по разу отпустили по этому поводу шутку. Проблема Linux заключается просто в отсутствии опыта и истории для сравнения идей, проблема, которая легко и быстро решается сообществом Linux точно так же, как она решается в сообществе BSD—постоянной работой над кодом. Разработчики &windowsnt;, с другой стороны, постоянно совершают те же самые ошибки, что были решены в &unix; десятки лет назад, а затем тратят годы на их устранение. Снова и снова. Есть несколько случаев проработка архитектуры отсутствует и мы всегда правы, потому что так говорит наш отдел продаж. Я плохо переношу тех, кого не учит история. Большинство очевидной сложности архитектуры &os;, особенно в подсистеме VM/Swap, является прямым следствием того, что она решает серьезные проблемы с производительностью, которые проявляются при различных условиях. Эти проблемы вызваны не плохой проработкой алгоритмов, а возникают из окружающих факторов. В любом прямом сравнении между платформами эти проблемы проявляются, когда системные ресурсы начинают истощаться. Так как я описываю подсистему VM/Swap во &os;, то читатель должен всегда иметь в виду два обстоятельства: Самым важным аспектом при проектировании производительности является то, что называется “оптимизацией критического маршрута”. Часто случается, что оптимизация производительности дает прирост объема кода ради того, чтобы критический маршрут работал быстрее. Четкость общей архитектуры оказывается лучше сильно оптимизированной архитектуры с течением времени. Когда как обобщенная архитектура может быть медленнее, чем оптимизированная архитектура, при первой реализации, при обобщенной архитектуре легче подстраиваться под изменяющиеся условия и чрезмерно оптимизированная архитектура оказывается непригодной. Любой код, который должен выжить и поддаваться поддержке годы, должен поэтому быть тщательно продуман с самого начала, даже если это стоит потери производительности. Двадцать лет назад были те, кто отстаивал преимущество программирования на языке ассемблера перед программированием на языке высокого уровня, потому что первый генерировал в десять раз более быстрый код. В наши дни ошибочность этого аргумента очевидна — можно провести параллели с построением алгоритмов и обобщением кода. Объекты VM Лучше всего начать описание VM-системы &os; с попытки взглянуть на нее с точки зрения пользовательского процесса. Каждый пользовательский процесс имеет единое, принадлежащее только ему и неразрывное адресное пространство VM, содержащее несколько типов объектов памяти. Эти объекты имеют различные характеристики. Код программы и ее данные являются единым файлом, отображаемым в память (это выполняющийся двоичный файл), однако код программы доступен только для чтения, когда как данные программы размещаются в режиме копирования-при-записи. BSS программы представляет собой всего лишь выделенную область памяти, заполненную, если это требовалось, нулями, что называется обнулением страниц памяти по требованию. Отдельные файлы могут также отображаться в адресное пространство, именно так работают динамические библиотеки. Такие отображения требуют изменений, чтобы оставаться принадлежащими процессу, который их выполнил. Системный вызов fork добавляет переводит проблему управления VM полностью в новую плоскость, вдобавок к уже имеющимся сложностям. Иллюстрирует сложность страница данных двоичной программы (которая является страницей копируемой-при-записи). Двоичная программа содержит секцию предварительно инициализированных данных, которая первоначально отображается непосредственно из файла программы. Когда программа загружается в Vm-пространство процесса, эта область сначала отображается в память и поддерживается бинарным файлом программы, позволяя VM-системе освобождать/повторно использовать страницу, а потом загружать ее снова из бинарного файла. Однако в момент, когда процесс изменяет эти данные, VM-система должна сделать копию страницы, принадлежащую только этому процессу. Так как эта копия была изменена, то VM-система не может больше освобождать эту страницу, так как впоследствии ее невозможно будет восстановить. Вы тут же заметите, что то, что сначала было простым отображением файла в память, становится гораздо более сложным предметом. Данные могут модифицироваться постранично, когда как отображение файла выполняется для многих страниц за раз. Сложность еще более увеличивается, когда процесс выполняет вызов fork. При этом порождаются два процесса—каждый со с собственным адресным пространством, включающим все изменения, выполненные исходным процессом до вызова функции fork(). Было бы глупо для VM-системы делать полную копию данных во время вызова fork(), так как весьма вероятно, что один из двух процессов будет нужен только для чтения из той страницы, что позволяет использование исходной страницы. То, что было страницей, принадлежащей только процессу, сделается снова страницей, копируемой при записи, так как каждый из процессов (и родитель, и потомок) полагают, что их собственные изменения после разветвления будут принадлежать только им, и не затронут родственный процесс. &os; управляет всем этим при помощи многоуровневой модели VM-объектов. Исходный файл с двоичной программой переносится на самый нижний уровень объектов VM. Уровень страниц, копируемых при записи, находится выше него, и хранит те страницы, которые были скопированы из исходного файла. Если программа модифицирует страницы данных, относящиеся к исходному файлу, то система VM обнаруживает это и переносит копию этой страницы на более высокий уровень. Когда процесс разветвляется, добавляются новые уровни VM-объектов. Это можно показать на простом примере. Функция fork() является общей операцией для всех систем *BSD, так что в этом примере будет рассматриваться программа, которая запускается, а затем разветвляется. Когда процесс запускается, VM-система создает некоторый уровень объектов, обозначим его A: +---------------+ | A | +---------------+ Рисунок A соответствует файлу—по необходимости страницы памяти могут высвобождаться и подгружаться с носителя файла. Подгрузка с диска может потребоваться программе, однако на самом деле мы не хотим, чтобы она записывалась обратно в файл. Поэтому VM-система создает второй уровень, B, который физически поддерживается дисковым пространством подкачки: +---------------+ | B | +---------------+ | A | +---------------+ При первой записи в страницу после выполнения этой операции, в B создается новая страница, содержимое которой берется из A. Все страницы в B могут сбрасываться и считываться из устройства подкачки. Когда программа ветвится, VM-система создает два новых уровня объектов—C1 для порождающего процесса и C2 для порожденного—они располагаются поверх B: +-------+-------+ | C1 | C2 | +-------+-------+ | B | +---------------+ | A | +---------------+ В этом случае, допустим, что страница в B была изменена начальным родительским процессом. В процессе возникнет ситуация копирования при записи и страница скопируется в C1, при этом исходная страница останется в B нетронутой. Теперь допустим, что та же самая страница в B изменяется порожденным процессом. В процессе возникнет ситуация копирования при записи и страница скопируется в C2. Исходная страница в B теперь полностью скрыта, так как и C1, и C2 имеют копии, а B теоретически может быть уничтожена, если она не представляет собой реального файла). Однако такую оптимизацию не так уж просто осуществить, потому что она делается на уровне мелких единиц. Во &os; такая оптимизация не выполняется. Теперь положим (а это часто случается), что порожденный процесс выполняет вызов exec(). Его текущее адресное пространство обычно заменяется новым адресным пространством, представляющим новый файл. В этом случае уровень C2 уничтожается: +-------+ | C1 | +-------+-------+ | B | +---------------+ | A | +---------------+ В этом случае количество потомков B становится равным одному и все обращения к B теперь выполняются через C1. Это означает, что B и C1 могут быть объединены. Все страницы в B, которые также существуют и в C1, во время объединения из B удаляются. Таким образом, хотя оптимизация на предыдущем шаге может не делаться, мы можем восстановить мертвые страницы при окончании работы процессов или при вызове exec(). Такая модель создает некоторое количество потенциальных проблем. Первая, с которой вы можете столкнуться, заключается в сравнительно большой последовательности уровней объектов VM, на сканирование которых тратится время и память. Большое количество уровней может возникнуть, когда процессы разветвляются, а затем разветвляются еще раз (как порожденные, так и порождающие). Вторая проблема заключается в том, что вы можете столкнуться с мертвыми, недоступными страницами глубоко в иерархии объектов VM. В нашем последнем примере если как родитель, так и потомок изменяют одну и ту же страницу, они оба получают собственные копии страницы, а исходная страница в B становится никому не доступной. такая страница в B может быть высвобождена. &os; решает проблему с глубиной вложенности с помощью приема оптимизации, который называется “All Shadowed Case”. Этот случай возникает, если в C1 либо C2 возникает столько случаев копирования страниц при записи, что они полностью закрывают все страницы в B. Допустим, что такое произошло в C1. C1 может теперь полностью заменить B, так что вместо цепочек C1->B->A и C2->B->A мы теперь имеем цепочки C1->A и C2->B->A. Но посмотрите, что получается—теперь B имеет только одну ссылку (C2), так что мы можем объединить B и C2. В конечном итоге B будет полностью удален и мы имеем цепочки C1->A и C2->A. Часто B будет содержать большое количество страниц, и ни C1, ни C2 не смогут полностью их заменить. Если мы снова породим процесс и создадим набор уровней D, при этом, однако, более вероятно, что один из уровней D постепенно сможет полностью заместить гораздо меньший набор данных, представленный C1 и C2. Та же самая оптимизация будет работать в любой точке графа и главным результатом этого является то, что даже на сильно загруженной машине с множеством порождаемых процессов стеки объектов VM не часто бывают глубже четырех уровней. Это так как для порождающего, так и для порожденного процессов, и остается в силе как в случае, когда ветвление делает родитель, так и в случае, когда ветвление выполняет потомок. Проблема с мертвой страницей все еще имеет место, когда C1 или C2 не полностью перекрывают B. Из-за других применяемых нами методов оптимизации этот случай не представляет большой проблемы и мы просто позволяем таким страницам существовать. Если система испытывает нехватку оперативной памяти, она выполняет их выгрузку в область подкачки, что занимает некоторое пространство в области подкачки, но это все. Преимущество модели VM-объектов заключается в очень быстром выполнении функции fork(), так как при этом не выполняется реального копирования данных. Минусом этого подхода является то, что вы можете построить сравнительно сложную иерархию объектов VM, которая несколько замедляет обработку ситуаций отсутствия страниц памяти, и к тому же тратится память на управление структурами объектов VM. Приемы оптимизации, применяемые во &os;, позволяют снизить значимость этих проблем до степени, когда их можно без особых потерь игнорировать. Уровни области подкачки Страницы с собственными данными первоначально являются страницами, копируемыми при записи или заполняемыми нулями. Когда выполняется изменение, и, соответственно, копирование, начальное хранилище объекта (обычно файл) не может больше использоваться для хранения копии страницы, когда VM-системе нужно использовать ее повторно для других целей. В этот момент на помощь приходит область подкачки. Область подкачки выделяется для организации хранилища памяти, которая иначе не может быть доступна. &os; создает структуру управления подкачкой для объекта VM, только когда это действительно нужно. Однако структура управления подкачкой исторически имела некоторые проблемы: Во &os; 3.X в структуре управления областью подкачки предварительно выделяется массив, который представляет целый объект, требующий хранения в области подкачки—даже если только несколько страниц этого объекта хранятся в области подкачки. Это создает проблему фрагментации памяти ядра в случае, когда в память отображаются большие объекты или когда ветвятся процессы, занимающие большой объем памяти при работе (RSS). Также для отслеживания памяти подкачки в памяти ядра поддерживается список дыр, и он также несколько фрагментирован. Так как список дыр является последовательным списком, то производительность при распределении и высвобождении памяти в области подкачки неоптимально и ее сложность зависит от количества страниц как O(n). Также в процессе высвобождения памяти в области подкачки требуется выделение памяти в ядре, и это приводит к проблемам блокировки при недостатке памяти. Проблема еще более обостряется из-за дыр, создаваемых по чередующемуся алгоритму. Кроме того, список распределения блоков в области подкачки легко оказывается фрагментированным, что приводит к распределению непоследовательных областей. Память ядра также должна распределяться по ходу работы для дополнительных структур по управлению областью подкачки при выгрузке страниц памяти в эту область. Очевидно, что мест для усовершенствований предостаточно. Во &os; 4.X подсистема управления областью подкачки была полностью переписана мною: Структуры управления областью подкачки распределяются при помощи хэш-таблицы, а не через линейный массив, что дает им фиксированный размер при распределении и работу с гораздо меньшими структурами. Вместо того, чтобы использовать однонаправленный связный список для отслеживания выделения пространства в области подкачки, теперь используется побитовая карта блоков области подкачки, выполненная в основном в виде древовидной структуры с информацией о свободном пространстве, находящейся в узлах структур. Это приводит к тому, что выделение и высвобождение памяти в области подкачки становится операцией сложности O(1). Все дерево также распределяется заранее для того, чтобы избежать распределения памяти ядра во время операций с областью подкачки при критически малом объеме свободной памяти. В конце концов, система обращается к области подкачки при нехватке памяти, так что мы должны избежать распределения памяти ядра в такие моменты для избежания потенциальных блокировок. Для уменьшения фрагментации дерево может распределять большой последовательный кусок за раз, пропуская меньшие фрагментированные области. Я не сделал последний шаг к заведению указателя на распределение, который будет передвигаться по участку области подкачки при выделении памяти для обеспечения в будущем распределения последовательных участков, или по крайней мере местоположения ссылки, но я убежден, что это может быть сделано. Когда освобождать страницу Так как система VM использует всю доступную память для кэширования диска, то обычно действительно незанятых страниц очень мало. Система VM зависит от того, как она точно выбирает незанятые страницы для повторного использования для новых распределений. Оптимальный выбор страниц для высвобождения, возможно, является самой важной функцией любой VM-системы, из тех, что она может выполнять, потому что при неправильном выборе система VM вынуждена будет запрашивать страницы с диска, значительно снижая производительность всей системы. Какую дополнительную нагрузку мы может выделить в критическом пути для избежания высвобождения не той страницы? Каждый неправильный выбор будет стоить нам сотни тысяч тактов работы центрального процессора и заметное замедление работы затронутых процессов, так что мы должны смириться со значительными издержками для того, чтобы была заведомо выбрана правильная страница. Вот почему &os; превосходит другие системы в производительности при нехватке ресурсов памяти. Алгоритм определения свободной страницы написан на основе истории использования страниц памяти. Для получения этой истории система использует возможности бита использования памяти, которые имеются в большинстве аппаратных таблицах страниц памяти. В любом случае, бит использования страницы очищается, и в некоторый более поздний момент VM-система обращается к странице снова и обнаруживает, что этот бит установлен. Это указывает на то, что страница активно используется. Периодически проверяя этот бит, накапливается история использования (в виде счетчика) физической страницы. Когда позже VM-системе требуется высвободить некоторые страницы, проверка истории выступает указателем при определении наиболее вероятной кандидатуры для повторного использования. Что, если аппаратура не имеет бита использования страницы? Для тех платформ, что не имеют этой возможности, система эмулирует этот бит. Она снимает отображение или защищает страницу, что приводит к ошибке доступа к странице, если к странице выполняется повторное обращение. При возникновении этой ошибки система просто помечает страницу как используемую и снимает защиту со страницы, так что она может использоваться. Хотя использование такого приема только для определения использования страницы весьма накладно, это выгоднее, чем повторно использовать страницу для других целей и обнаружить, что она снова нужна процессу и подгружать ее с диска. &os; использует несколько очередей страниц для обновления выбора страниц для повторного использования, а также для определения того, когда же грязные страницы должны быть сброшены в хранилище. Так как таблицы страниц во &os; являются динамическими объектами, практически ничего не стоит вырезать страницу из адресного пространства любого использующего ее процесса. После того, как подходящая страница, на основе счетчика использования, выбрана, именно это и выполняется. Система должна отличать между чистыми страницами, которые теоретически могут быть высвобождены в любое время, и грязными страницами, которые сначала должны быть переписаны в хранилище перед тем, как их можно будет использовать повторно. После нахождения подходящей страницы она перемещается в неактивную очередь, если она является грязной, или в очередь кэша, если она чистая. Отдельный алгоритм, основывающийся на отношении количества грязных страниц к чистым, определяет, когда грязные страницы в неактивной очереди должны быть сброшены на диск. Когда это выполнится, сброшенные страницы перемещаются из неактивной очереди в очередь кэша. В этот момент страницы в очереди кэша могут быть повторно активизированы VM со сравнительно малыми накладными расходами. Однако страницы в очереди кэша предполагается высвобождать немедленно и повторно использовать в LRU-порядке (меньше всего используемый), когда системе потребуется выделение дополнительной памяти. Стоит отметить, что во &os; VM-система пытается разделить чистые и грязные страницы во избежание срочной необходимости в ненужных сбросах грязных страниц (что отражается на пропускной способности ввода/вывода) и не перемещает беспричинно страницы между разными очередями, когда подсистема управления памятью не испытывает нехватку ресурсов. Вот почему вы можете видеть, что при выполнении команды systat -vm в некоторых системах значение счетчика очереди кэша мало, а счетчик активной очереди большой. При повышении нагрузки на VM-систему она прилагает большие усилия на поддержку различных очередей страниц в соотношениях, которые являются наиболее эффективными. Годами ходили современные легенды, что Linux выполняет работу по предотвращению выгрузки на диск лучше, чем &os;, но это не так. На самом деле &os; старается сбросить на диск неиспользуемые страницы для освобождения места под дисковый кэш, когда как Linux хранит неиспользуемые страницы в памяти и оставляет под кэш и страницы процессов меньше памяти. Я не знаю, остается ли это правдой на сегодняшний день. Оптимизация ошибок доступа к страницам и их обнуления Полагая, что ошибка доступа к странице памяти в VM не является операцией с большими накладными расходами, если страница уже находится в основной памяти и может быть просто отображена в адресное пространство процесса, может оказаться, что это станет весьма накладно, если их будет оказываться регулярно много. Хорошим примером этой ситуации является запуск таких программ, как &man.ls.1; или &man.ps.1;, снова и снова. Если бинарный файл программы отображен в память, но не отображен в таблицу страниц, то все страницы, к которым обращалась программа, окажутся недоступными при каждом запуске программы. Это не так уж необходимо, если эти страницы уже присутствуют в кэше VM, так что &os; будет пытаться восстанавливать таблицы страниц процесса из тех страниц, что уже располагаются в VM-кэше. Однако во &os; пока не выполняется предварительное копирование при записи определенных страниц при выполнении вызова exec. Например, если вы запускаете программу &man.ls.1; одновременно с работающей vmstat 1, то заметите, что она всегда выдает некоторое количество ошибок доступа к страницам, даже когда вы запускаете ее снова и снова. Это ошибки заполнения нулями, а не ошибки кода программы (которые уже были обработаны). Предварительное копирование страниц при выполнении вызовов exec или fork находятся в области, требующей более тщательного изучения. Большой процент ошибок доступа к страницам, относится к ошибкам при заполнении нулями. Вы можете обычно видеть это, просматривая вывод команды vmstat -s. Это происходит, когда процесс обращается к страницам в своей области BSS. Область BSS предполагается изначально заполненной нулями, но VM-система не заботится о выделении памяти до тех пор, пока процесс реально к ней не обратится. При возникновении ошибки VM-система должна не только выделить новую страницу, но и заполнить ее нулями. Для оптимизации операции по заполнению нулями в системе VM имеется возможность предварительно обнулять страницы и помечать их, и запрашивать уже обнуленные страницы при возникновении ошибок заполнения нулями. Предварительное заполнение нулями происходит, когда CPU простаивает, однако количество страниц, которые система заранее заполняет нулями, ограничено, для того, чтобы не переполнить кэши памяти. Это прекрасный пример добавления сложности в VM-систему ради оптимизации критического пути. Оптимизация таблицы страниц Оптимизация таблицы страниц составляет самую содержательную часть архитектуры VM во &os; и она проявляется при появлении нагрузки при значительном использовании mmap(). Я думаю, что это на самом деле особенность работы большинства BSD-систем, хотя я не уверен, когда это проявилось впервые. Есть два основных подхода к оптимизации. Первый заключается в том, что аппаратные таблицы страниц не содержат постоянного состояния, а вместо этого могут быть сброшены в любой момент с малыми накладными расходами. Второй подход состоит в том, что каждая активная таблица страниц в системе имеет управляющую структуру pv_entry, которая связана в структуру vm_page. &os; может просто просматривать эти отображения, которые существуют, когда как в Linux должны проверяться все таблицы страниц, которые могут содержать нужное отображение, что в некоторых ситуация дает увеличение сложности O(n^2). Из-за того, что &os; стремится выбрать наиболее подходящую к повторному использованию или сбросу в область подкачки страницу, когда ощущается нехватка памяти, система дает лучшую производительность при нагрузке. Однако во &os; требуется тонкая настройка ядра для соответствия ситуациям с большим совместно используемым адресным пространством, которые могут случиться в системе, обслуживающей сервер телеконференций, потому что структуры pv_entry могут оказаться исчерпанными. И в Linux, и во &os; требуются доработки в этой области. &os; пытается максимизировать преимущества от потенциально редко применяемой модели активного отображения (к примеру, не всем процессам нужно отображать все страницы динамической библиотеки), когда как Linux пытается упростить свои алгоритмы. &os; имеет здесь общее преимущество в производительности за счет использования дополнительной памяти, но &os; выглядит хуже в случае, когда большой файл совместно используется сотнями процессов. Linux, с другой стороны, выглядит хуже в случае, когда много процессов частично используют одну и ту же динамическую библиотеку, а также работает неоптимально при попытке определить, может ли страница повторно использоваться, или нет. Подгонка страниц Мы закончим рассмотрением метода оптимизации подгонкой страниц. Подгонка является методом оптимизации, разработанным для того, чтобы доступ в последовательные страницы виртуальной памяти максимально использовал кэш процессора. В далеком прошлом (то есть больше 10 лет назад) процессорные кэши предпочитали отображать виртуальную память, а не физическую. Это приводило к огромному количеству проблем, включая необходимость очистки кэша в некоторых случаях при каждом переключении контекста и проблемы с замещением данных в кэше. В современных процессорах кэши отображают физическую память именно для решения этих проблем. Это означает, что две соседние страницы в адресном пространстве процессов могут не соответствовать двух соседним страницам в кэше. Фактически, если вы об этом не позаботились, то соседние страницы в виртуальной памяти могут использовать ту же самую страницу в кэше процессора—это приводит к сбросу кэшируемых данных и снижению производительности CPU. Это так даже с множественными ассоциативными кэшами (хотя здесь эффект несколько сглажен). Код выделения памяти во &os; выполняет оптимизацию с применением подгонки страниц, означающую то, что код выделения памяти будет пытаться найти свободные страницы, которые являются последовательными с точки зрения кэша. Например, если страница 16 физической памяти назначается странице 0 виртуальной памяти процесса, а в кэш помещается 4 страницы, то код подгонки страниц не будет назначать страницу 20 физической памяти странице 1 виртуальной памяти процесса. Вместо этого будет назначена страница 21 физической памяти. Код подгонки страниц попытается избежать назначение страницы 20, потому что такое отображение перекрывается в той же самой памяти кэша как страница 16, и приведет к неоптимальному кэшированию. Как вы можете предположить, такой код значительно добавляет сложности в подсистему выделения памяти VM, но результат стоит того. Подгонка страниц делает память VM предсказуемой, как и обычная физическая память, относительно производительности кэша. Заключение Виртуальная память в современных операционных системах должна решать несколько различных задач эффективно и при разных условиях. Модульный и алгоритмический подход, которому исторически следует BSD, позволяет нам изучить и понять существующую реализацию, а также сравнительно легко изменить большие блоки кода. За несколько последних лет в VM-системе &os; было сделано некоторое количество усовершенствований, и работа над ними продолжается. Дополнительный сеанс вопросов и ответов от Аллена Бриггса (Allen Briggs) <email>briggs@ninthwonder.com</email> Что это за “алгоритм чередования”, который вы упоминали в списке недостатков подсистемы управления разделом подкачки во &os; 3.X? &os; использует в области подкачки механизм чередования, с индексом по умолчанию, равным четырем. Это означает, что &os; резервирует пространство для четырех областей подкачки, даже если у вас имеется всего лишь одна, две или три области. Так как в области подкачки имеется чередование, то линейное адресное пространство, представляющее четыре области подкачки, будет фрагментироваться, если у вас нет на самом деле четырех областей подкачки. Например, если у вас две области A и B, то представление адресного пространства для этой области подкачки во &os; будет организовано с чередованием блоков из 16 страниц: A B C D A B C D A B C D A B C D &os; 3.X использует последовательный список свободных областей для управления свободными областями в разделе подкачки. Идея состоит в том, что большие последовательные блоки свободного пространства могут быть представлены при помощи узла односвязного списка (kern/subr_rlist.c). Но из-за фрагментации последовательный список сам становится фрагментированным. В примере выше полностью неиспользуемое пространство в A и B будет показано как свободное, а C и D как полностью занятое. Каждой последовательности A-B требуется для учета узел списка, потому что C и D являются дырами, так что узел списка не может быть связан со следующей последовательностью A-B. Почему мы организуем чередование в области подкачки вместо того, чтобы просто объединить области подкачки в одно целое и придумать что-то более умное? Потому что гораздо легче выделять последовательные полосы адресного пространства и получать в результате автоматическое чередование между несколькими дисками, чем пытаться выдумывать сложности в другом месте. Фрагментация вызывает другие проблемы. Являясь последовательным списком в 3.X и имея такое огромную фрагментацию, выделение и освобождение в области подкачки становится алгоритмом сложности O(N), а не O(1). Вместе с другими факторами (частое обращение к области подкачки) вы получаете сложность уровней O(N^2) и O(N^3), что плохо. В системе 3.X также может потребоваться выделение KVM во время работы с областью подкачки для создания нового узла списка, что в условии нехватки памяти может привести к блокировке, если система попытается сбросить страницы в область подкачки. В 4.X мы не используем последовательный список. Вместо этого мы используем базисное дерево и битовые карты блоков области подкачки, а не ограниченный список узлов. Мы принимаем предварительное выделение всех битовых карт, требуемых для всей области подкачки, но при этом тратится меньше памяти, потому что мы используем битовые карты (один бит на блок), а не связанный список узлов. Использование базисного дерева вместо последовательного списка дает нам производительность O(1) вне зависимости от фрагментации дерева. Как разделение чистых и грязных (неактивных) страниц связано с ситуацией, когда вы видите маленький счетчик очереди кэша и большой счетчик активной очереди в выдаче команды systat -vm? Разве системная статистика не считает активные и грязные страницы вместе за счетчик активной очереди? Я не понял следующее:
Стоит отметить, что во &os; VM-система пытается разделить чистые и грязные страницы во избежание срочной необходимости в ненужных сбросах грязных страниц (что отражается на пропускной способности ввода/вывода) и не перемещает беспричинно страницы между разными очередями, когда подсистема управления памятью не испытывает нехватку ресурсов. Вот почему вы можете видеть, что при выполнении команды systat -vm в некоторых системах значение счетчика очереди кэша мало, а счетчик активной очереди большой.
Да, это запутывает. Связь заключается в “желаемом” и “действительном”. Мы желаем разделить страницы, но реальность такова, что пока у нас нет проблем с памятью, нам это на самом деле не нужно. Это означает, что &os; не будет очень сильно стараться над отделением грязных страниц (неактивная очередь) от чистых страниц (очередь кэша), когда система не находится под нагрузкой, и не будет деактивировать страницы (активная очередь -> неактивная очередь), когда система не нагружена, даже если они не используются. В примере с &man.ls.1; / vmstat 1 могут ли некоторые ошибки доступа к странице быть ошибками страниц данных (COW из выполнимого файла в приватные страницы)? То есть я полагаю, что ошибки доступа к страницам являются частично ошибками при заполнении нулями, а частично данных программы. Или вы гарантируете, что &os; выполняет предварительно COW для данных программы? Ошибка COW может быть ошибкой при заполнении нулями или данных программы. Механизм в любом случае один и тот же, потому что хранилище данных программы уже в кэше. Я на самом деле не рад ни тому, ни другому. &os; не выполняет предварительное COW данных программы и заполнение нулями, но она выполняет предварительно отображение страниц, которые имеются в ее кэше. В вашем разделе об оптимизации таблицы страниц, не могли бы вы более подробно рассказать о pv_entry и vm_page (или vm_page должна быть vm_pmap—как в 4.4, cf. pp. 180-181 of McKusick, Bostic, Karel, Quarterman)? А именно какое действие/реакцию должно потребоваться для сканирования отображений? Что делает Linux в тех случаях, когда &os; работает плохо (совместное использование отображения файла между многими процессами)? vm_page представляет собой пару (object,index#). pv_entry является записью из аппаратной таблицы страниц (pte). Если у вас имеется пять процессов, совместно использующих одну и ту же физическую страницу, и в трех таблицах страниц этих процессов на самом деле отображается страница, то страница будет представляться одной структурой vm_page и тремя структурами pv_entry. Структуры pv_entry представляют страницы, отображаемые MMU (одна структура pv_entry соответствует одной pte). Это означает, что, когда нам нужно убрать все аппаратные ссылки на vm_page (для того, чтобы повторно использовать страницу для чего-то еще, выгрузить ее, очистить, пометить как грязную и так далее), мы можем просто просмотреть связный список структур pv_entry, связанных с этой vm_page, для того, чтобы удалить или изменить pte из их таблиц страниц. В Linux нет такого связного списка. Для того, чтобы удалить все отображения аппаратной таблицы страниц для vm_page, linux должен пройти по индексу каждого объекта VM, который может отображать страницу. К примеру, если у вас имеется 50 процессов, которые все отображают ту же самую динамическую библиотеку и хотите избавиться от страницы X в этой библиотеке, то вам нужно пройтись по индексу всей таблицы страниц для каждого из этих 50 процессов, даже если только 10 из них на самом деле отображают страницу. Так что Linux использует простоту подхода за счет производительности. Многие алгоритмы VM, которые имеют сложность O(1) или (N малое) во &os;, в Linux приобретают сложность O(N), O(N^2) или хуже. Так как pte, представляющий конкретную страницу в объекте, скорее всего, будет с тем же смещением во всех таблицах страниц, в которых они отображаются, то уменьшение количества обращений в таблицы страниц по тому же самому смещению часто позволяет избежать разрастания кэша L1 для этого смещения, что приводит к улучшению производительности. Во &os; введены дополнительные сложности (схема с pv_entry) для увеличения производительности (уменьшая количество обращений только к тем pte, которые нужно модифицировать). Но во &os; имеется проблема масштабирования, которой нет в Linux, потому что имеется ограниченное число структур pv_entry, и это приводит к возникновению проблем при большом объеме совместно используемых данных. В этом случае у вас может возникнуть нехватка структур pv_entry, даже если свободной памяти хватает. Это может быть достаточно легко исправлено увеличением количества структур pv_entry при настройке, но на самом деле нам нужно найти лучший способ делать это. Что касается использования памяти под таблицу страниц против схемы с pv_entry: Linux использует постоянные таблицы страниц, которые не сбрасываются, но ему не нужны pv_entry для каждого потенциально отображаемого pte. &os; использует сбрасываемые таблицы страниц, но для каждого реально отображаемого pte добавляется структура pv_entry. Я думаю, что использование памяти будет примерно одинакова, тем более что у &os; есть алгоритмическое преимущество, заключающееся в способности сбрасывать таблицы страниц с очень малыми накладными расходами. Наконец, в разделе о подгонке страниц хорошо бы было иметь краткое описание того, что это значит. Я не совсем это понял. Знаете ли вы, как работает аппаратный кэш памяти L1? Объясняю: Представьте машину с 16МБ основной памяти и только со 128К памяти кэша L1. В общем, этот кэш работает так, что каждый блок по 128К основной памяти использует те же самые 128К кэша. Если вы обращаетесь к основной памяти по смещению 0, а затем к основной памяти по смещению 128К, вы перезаписываете данные кэша, прочтенные по смещению 0! Я очень сильно все упрощаю. То, что я только что описал, называется напрямую отображаемым аппаратным кэшем памяти. Большинство современных кэшей являются так называемыми 2-сторонними множественными ассоциативными или 4-сторонними множественными ассоциативными кэшами. Множественная ассоциативность позволяет вам обращаться к вплоть до N различным областям памяти, которые используют одну и ту же память кэша без уничтожения ранее помещенных в кэш данных. Но только N. Так что если у меня имеется 4-сторонний ассоциативный кэш, я могу обратиться к памяти по смещению 0, смещению 128К, 256К и смещению 384K, затем снова обратиться к памяти по смещению 0 и получу ее из кэша L1. Однако, если после этого я обращусь к памяти по смещению 512К, один из ранее помещенных в кэш объектов данных будет из кэша удален. Это чрезвычайно важно… для большинства обращений к памяти процессора чрезвычайно важно, чтобы данные находились в кэше L1, так как кэш L1 работает на тактовой частоте работы процессора. В случае, если данных в кэше L1 не обнаруживается, и они ищутся в кэше L2 или в основной памяти, процессор будет простаивать, или, скорее, сидеть, сложив ручки, в ожидании окончания чтения из основной памяти, хотя за это время можно было выполнить сотни операций. Основная память (динамическое ОЗУ, которое установлено в компьютере) работает по сравнению со скоростью работы ядра современных процессоров медленно. Хорошо, а теперь рассмотрим подгонку страниц: Все современные кэши памяти являются так называемыми физическими кэшами. Они кэшируют адреса физической памяти, а не виртуальной. Это позволяет кэшу не принимать во внимание переключение контекстов процессов, что очень важно. Но в мире &unix; вы работаете с виртуальными адресными пространствами, а не с физическими. Любая программа, вами написанная, имеет дело с виртуальным адресным пространством, ей предоставленным. Реальные физические страницы, соответствующие виртуальному адресному пространству, не обязательно расположены физически последовательно! На самом деле у вас могут оказаться две страницы, которые в адресном пространстве процессов являются граничащими, но располагающимися по смещению 0 и по смещению 128К в физической памяти. Обычно программа полагает, что две граничащие страницы будут кэшироваться оптимально. То есть вы можете обращаться к объектам данных в обеих страницах без замещений в кэше данных друг друга. Но это имеет место, если только физические страницы, соответствующие виртуальному адресному пространству, располагаются рядом (в такой мере, что попадают в кэш). Это именно то, что выполняет подгонка. Вместо того, чтобы назначать случайные физические страницы виртуальным адресам, что может привести к неоптимальной работе кэша, при подгонке страниц виртуальным адресам назначаются примерно подходящие по порядку физические страницы. Таким образом, программы могут писаться в предположении, что характеристики низлежащего аппаратного кэша для виртуального адресного пространства будут такими же, как если бы программа работала непосредственно в физическом адресном пространстве. Заметьте, что я сказал примерно подходящие, а не просто последовательные. С точки зрения напрямую отображаемого кэша в 128К, физический адрес 0 одинаков с физическим адресом 128К. Так что две граничащие страницы в вашем виртуальном адресном пространстве могут располагаться по смещению 128К и 132К физической памяти, но могут легко находиться по смещению 128К и по смещению 4К физической памяти, и иметь те же самые характеристики работы кэша. Так что при подгонке не нужно назначать в действительности последовательные страницы физической памяти последовательным страницам виртуальной памяти, достаточно просто добиться расположения страниц по соседству друг с другом с точки зрения работы кэша.