diff --git a/ru_RU.KOI8-R/articles/5-roadmap/article.sgml b/ru_RU.KOI8-R/articles/5-roadmap/article.sgml index 54b58b903f..b8e79bbd53 100644 --- a/ru_RU.KOI8-R/articles/5-roadmap/article.sgml +++ b/ru_RU.KOI8-R/articles/5-roadmap/article.sgml @@ -1,699 +1,715 @@ %articles.ent; RELENG_3"> RELENG_4"> RELENG_5"> RELENG_5_1"> RELENG_5_2"> RELENG_5_3"> HEAD"> ]>
Направления работ в 5-STABLE The &os; Release Engineering Team $FreeBSD$ 2003 The &os; Release Engineering Team &tm-attrib.freebsd; &tm-attrib.ieee; &tm-attrib.intel; &tm-attrib.sparc; &tm-attrib.sun; &tm-attrib.opengroup; &tm-attrib.general; + + + Данный документ теперь имеет в основном историческое значение. + Он рассказывал о направлении работ в разработке версий &os; + &t.releng.5; ветки. Первоначальная версия документа появилась в феврале 2003 г. (между + релизами 5.0 и 5.1), и предполагалось, что он будет использоваться + для предоставления плана по переводу &t.releng.5; ветки в стабильное + состояние, как по качеству кода, так и по доработке различных API/ABI. + В качестве иного взгляда на проблему может быть интересна статья + + Выбор подходящей для вас версии &os; + . Она была написана в Августе 2005 г. (на два с половиной + года позже) и содержит раздел, в котором описывается как разворачивались + планы и события, а также какие уроки были получены. + + Введение и информация общего характера В январе 2003 года, после примерно трёх лет работы, была выпущена &os; 5.0. Такие её возможности, как технология GEOM, мандатный контроль доступа, ACPI, поддержка архитектур &sparc64; и ia64, работа с мгновенными копиями UFS, фоновая проверка целостности файловой системы и 64-разрядная размерность узлов файловой системы делают эту операционную систему привлекательной как для корпоративного, так и персонального использования. Однако работа над некоторыми важными возможностями ещё не завершена. Программная основа для высокоточной блокировки и вытесняемости задач в ядре уже имеется, однако предстоит сделать ещё больше. Производительность и стабильность по сравнению с &os; 4.X несколько снизилась, однако эти характеристики должны быть восстановлены и даже улучшены. Это несколько напоминает ситуацию, с которой &os; сталкивалась в линейке 3.X. Работа над 3-CURRENT затягивалась до бесконечности, и наконец было принято решение просто выпустить её, а доработать позже. Такое решение привело к тому, что качество релизов 3.0 и 3.1 не могло удовлетворить большинство пользователей, и так было до версии 3.2, когда линейка была признана стабильной. Хуже того, ветка &t.releng.3; была создана на основе релиза 3.0. а ветка &t.releng.head; должна была вести к 4-CURRENT. В результате ветки &t.releng.head; и &t.releng.3; стали сильно отличаться, что значительно осложнило поддержку ветки &t.releng.3;. &os; 2.2.8 была оставлена как последняя версия &os;, подходящая для продуктивной эксплуатации. Нашей задачей является недопущение повторения такого сценария во &os; 5.x. Откладывание ветки &t.releng.5; до момента, когда она станет стабильной и достигнет качества продукта, готового к реальной эксплуатации, обеспечит будущую поддержку этой ОС и объективную причину перехода с версии 4.X, Для этого мы должны определить слабые места и наметить способы их устранения. В этом документе описаны те моменты, которые мы, как группа по подготовке релизов, считаем значительными и те вопросы, которые должны быть решены до создания ветки &t.releng.5;. Здесь не определяются все аспекты работы над &os;, и мы готовы к дальнейшему обсуждению. Ничего из того, что написано далее, не является инсинуациями против какой бы то ни было персоны или группы, целью не является упрощение никакой сделанной кем-то работы. Однако имеются некоторые важные вопросы, которые требуют решительных и беспристрастных действий. Основные вопросы Успех линейки 5.X зависит от возможности предоставить высокоточное управление потоками выполнения и повторяемость вызовов в ядре (что известно как SMPng), а также поддержки на уровне ядра POSIX-потоков выполнения пользовательского уровня, не жертвуя при этом общей стабильностью или производительностью системы. SMPng Работам над SMPng и блокировками на уровне ядра уделяется самое большое внимание для 5.X. На текущий момент было выпущено несколько версий системы с глобальными семафорами на всё ядро, известными как Giant. Страница о состоянии работ над SMP по адресу содержит исчерпывающую информацию об общем состоянии SMPng. Информация по конкретно работам над SMPng в драйверах устройств может быть найдена на странице . В целом: VM: Функция ядра malloc изолирована и освобождена от Giant. Распределитель зон UMA также не использует Giant. Изоляция vm_object находится в работе и является важным шагом в исключении Giant из работы с буферами/кэшем. Изоляция pmap ещё не реализовывалась. GEOM: Уровень блоков GEOM был разработан с учётом работы без Giant и он позволяет работать модулям GEOM и низлежащим драйверам блочных устройств без Giant. На данный момент только драйверы &man.ata.4; и &man.aac.4; разделены и работают без Giant. Работа над остальными драйверами блочных устройств ведётся. Изоляция CAM-подсистемы требует отказа от использования Giant практически во всех драйверах SCSI; работа над этим ещё не начиналась. Кроме того, в GEOM имеется опасность снижения производительности из-за обработки ею вышестоящих и нижестоящих потоков данных в потоках выполнения ядра. В решении этой проблемы может помочь улучшение и упрощение технологии переключения контекстов выполнения. Сеть: Работа по переводу на изоляцию сетевого стека была начата заново. Изначально целями были таблицы маршрутизации, ARP, функции моста, IPFW, Fast-Forward, TCP, UDP, IP, Fast IPSEC и уровни интерфейсов, а также некоторые драйверы устройств Ethernet. Позже были поставлены цели по изоляции уровней сокетов, IPv6 и других сетевых протоколов. Основной задачей этой работы является восстановление производительности, достигнутой во &os; 4.X. Затраты на переключение контекстов на ithreads и netisr в драйверах устройств всё ещё сильно влияют на производительность. VFS: Начата предварительная подготовка. буфер/кэш: Закончена начальная работа по изоляции буферов. Proc: Начальное изоляция proc уже есть, во &os; 5.2 ожидается ещё больший прогресс. CAM: На уровне CAM SCSI значительной работы не проделано. Newbus: была проделана некоторая работа по изоляции структуры device_t. Pipes: завершено Файловые дескрипторы: завершено. Process accounting: jails, credentials, MAC labels и планировщик не используют Giant. Технология MAC: завершено Timekeeping: завершено kernel encryption: криптографические драйверы и ядро технологии &man.crypto.4; не используют Giant. KAME IPsec не отделяются. Аудио-подсистема: завершено, однако остаются проблемы с обратным порядком изоляций. вытесняемость ядра: включена вытесняемость для потоков выполнения прерываний. Однако несогласованность из-за того, что Giant используется в большинстве кода ядра и подпрограммах обработки прерываний драйверов устройств, вызывает множество лишних переключений контекста и может на самом деле сказаться на производительности. Ведётся работа по выяснению того, как сделать вытесняемость условной. Задержки на прерывания и их обработка В SMPng появилась концепция выделенных потоков выполнения ядра, известных под названием ithreads, для обслуживания прерываний. С ними подпрограммы обслуживания прерываний от устройств могут создавать блокировки для выставления семафоров, выделения памяти и так далее. Хотя это облегчает написание драйверов, при этом понижается реактивность системы из-за того, что для обслуживания ithread должно быть выполнено полное переключение контекста процесса. Это усугубляется значительным использованием ядром семафора Giant, и часто приводит к множеству пауз и переключений контекстов для обслуживания прерывания. Драйверы, которые зарегистрировали свои прерывания как INTR_MPSAFE, меньше всего почувствуют этот эффект, однако потери на переключение контекста останутся. Подпрограммы обслуживания прерываний, зарегистрированные как INTR_FAST, работают непосредственно из контекста прерывания, и на них вовсе не сказываются эти проблемы. Однако указание свойства INTR_FAST заставляет линию прерываний стать эксклюзивной; её нельзя использовать одновременно с чем-то. Большое количество совместно используемых прерываний на PC-системах делает это нежелательным. Для помощи в решении этой проблемы были предложены несколько идей: Возможно, особый случай облегчённых ithread. При этом может, придётся уменьшить количество сохраняемых данных контекста для ithread, заимствовать стек из другого kthread и/или создавать новый быстрый способ обхода подпрограммы mi_switch(). Можно ввести новую модель обработки прерываний, которая позволит драйверам регистрировать 'фильтр прерываний' вместе с обычной процедурой обработки. Это будет похоже на используемую сейчас в Mac OS X модель. Процедуры фильтрации прерываний позволят драйверу определять, должен ли он участвовать в обработке прерывания, позволят ему подавлять источник прерываний и, возможно, определять и планировать действия по его обработке. Она будет работать в том же самом контексте, что и низкоуровневая процедура обслуживания прерывания, так что паузы будут жёстко запрещены. Если требуются действия, которые приводят к паузам или блокировке на долгий период, фильтр будут сигнализировать об этом вызывающей стороне, что должна быть запланирована обычная ithread-процедура. Потоки приложений, поддерживаемые ядром В процессе работы над FreeBSD 5.1 пакет KSE был доведён до весьма пригодного к использованию состояния. Также появился THR, альтернативный пакет по управлению потоками выполнения, основанный на некоторых примитивах KSE уровня ядра, но реализующий исключительно подход планирования задач 1:1, также находится в подобном экспериментальном, но пригодном к работе состоянии. Пользователи могут менять эти две библиотеки со старой библиотекой libc_r посредством перекомпоновки своих приложений или при помощи новой техники libmap компоновщика времени выполнения. Такой значительный прогресс в ходе работ должен привести к их завершению до момента появления ветки &t.releng.5;, так что пакет libc_r может оказаться ненужным. Компоненты уровня ядра и пользовательского уровня для KSE и THR должны быть созданы для все платформ уровня Tier-1. Решение о том, какой пакет реализации потоков выполнения будет использоваться по умолчанию, будет, скорее всего, приниматься для каждой платформы отдельно, в зависимости от стабильности и завершённости каждого пакета. Состояние KSE Платформа Уровень ядро Пользовательский уровень Работает? i386 ДА ДА ДА alpha НЕТ ДА НЕТ sparc64 ДА НЕТ НЕТ ia64 ДА ДА ДА amd64 ДА ДА ДА
Состояние THR Платформа Уровень ядра Пользовательский уровень Работает? i386 ДА ДА ДА alpha ДА ДА ДА sparc64 ДА ДА НЕТ ia64 ДА ДА ДА amd64 НЕТ НЕТ НЕТ
KSE должен пройти набор тестов ACE на всех платформах статуса Tier-1. Чтобы убедиться в том, что все библиотеки на самом деле работоспособны, необходимо выполнить дополнительное тестирование на реальных задачах. Как минимум, должны быть протестированы следующие пакеты: OpenOffice KDE Desktop Apache 2.x BIND 9.2.x MySQL &java; 1.4.x Требования к 5-STABLE Ветка &t.releng.5 должна дать пользователям такую же стабильность и производительность, которая сейчас достигнута в ветке &t.releng.4;. Хотя целью работ над SMPng является значительное повышение производительности по сравнению с имеющейся в &t.releng.4; и родственных вариантах BSD, получение хотя бы ранее достигнутой производительности является самой важной задачей. Ветка должна быть достаточно готовой, чтобы избежать изменений в ABI и API, но позволять решать потенциальные проблемы. Стабильность ABI/API/инфраструктуры Инфраструктура должна быть достаточно подготовленной и устоявшейся, чтобы исправления из ветки &t.releng.head; можно было легко и безболезненно переносить в &t.releng.5;. Кроме того, мы должны определиться, какие подсистемы должны работать с блокировками при переходе к 5-STABLE. KSE: И компоненты уровня ядра, и компоненты пользовательского уровня должны достичь одинакового уровня функциональности во всех платформах уровня Tier-1 в UP и SMP конфигурациях. Определение того, что является платформами ранга Tier-1, можно найти в . При приближении к выпуску ветки &t.releng.5; должно продолжиться тестирование на пакете тестов ACE. В KSE не должно допускаться уменьшение функциональности для будущей программы сертификации &java;. Распространённые прикладные и серверные приложения должны работать в KSE без проблем. Должна быть определена политика относительно того, на каких платформах KSE будет использоваться в качестве стандартного пакета для организации потоков выполнения, как пользователь может переключаться между такими пакетами и как пакеты сторонних разработчиков должны отслеживать такие изменения. интерфейс и драйверы busdma: такие архитектуры, как PAE/&i386; и sparc64, в которых отсутствует прямое отображение адресного пространства хоста в адресное пространство плат расширения, требуют исключения функции vtophys() и ей подобных. Интерфейс busdma был создал для решения именно этой проблемы, однако многие драйверы его ещё не используют. Проект busdma на странице отслеживает ход этих работ и это можно использовать для определения того, какие драйверы должны быть преобразованы для &t.releng.5;, а какие можно оставить. В дереве исходных текстов &os; не должно быть новых драйверов для устройств хранения или сетевых драйверов. Исключения для других классов драйверов нужно согласовывать в открытом обсуждении. распределение ресурсов PCI: соответствие спецификации PC2003 требует, что системы x86 не конфигурировали устройства PCI из системной BIOS, оставляя эту задачу исключительно ОС. Во &os; должна появиться возможность управления и распределения ресурсов памяти PCI своими силами. Реализация этого должна принять во внимание существование требований cardbus, PCI-HotPlug и доков для лэптопов. Эта возможность станет ещё более критичной в течение жизни ветки &t.releng.5;, и поэтому является требованием к выпуску &t.releng.5;. Производительность Производительность зависит от хода работ над инфраструктурой SMPng и в следующих областях: Устройства хранения: Технология GEOM позволяет драйверам устройств хранения работать без использования Giant. Все драйверы, которые взаимодействуют напрямую с GEOM (в противоположность тем, что находятся ниже уровня CAM или другого промежуточного слоя), должны изолироваться и избавляться от использования Giant как в части strategy, так и completion. Их обработчики прерываний также должны избавиться от Giant. Сеть: уровни в работе IPv4, лежащие ниже уровня сокетов, должны быть изолированными и не использовать Giant. Сюда включается протокол, маршрутизация, организация моста, фильтрация и аппаратный уровень. Скидки должны быть сделаны для протоколов, которые не изолируются, особенно IPv6. Для достижения стабильности, корректности и производительности также необходимо выполнить тестирование. Прерывания и переключение контекстов: Как обсуждалось выше, задержки в прерываниях и переключениях контекстов имеют большое влияние на производительность. Переключение контекстов для ithread и kthread на всех платформах должно быть улучшено. Должна быть исследована и реализована возможность создания новой модели обработки прерываний, которая позволяет выполнять более быструю и гибкую обработку как обычных, так и MSI прерываний. Стандартные тесты и тестирование производительности Для выявления проблем с производительностью и борьбы с её ухудшением необходимо информативное и надёжное проведение тестов. Вскоре должна быть сформирована группа производительности из людей и ресурсов для формулирования, разработки и выполнения стандартных тестов производительности. Сравнения должны делаться как с &os; 4.X, так и Linux 2.4/2.6. Предполагаются следующие тесты: классический worldstone webstone: www/webstone Fstress: ApacheBench: www/p5-ApacheBench netperf: benchmarks/netperf Web Polygraph: Замечание: пока не компилируется с gcc 3.x. Особые возможности: NEWCARD/OLDCARD: Подсистема NEWCARD во &os; 5.0 сделана используемой по умолчанию. К сожалению, в ней отсутствует поддержка для не-Cardbus мостов и на некоторых лэптопах она не работает из-за проблем с маршрутизацией прерываний. Классическая реализации поддержки 16-битных мостов, OLDCARD, продолжает существовать и может быть вкомпилирована, однако это неудобно для пользователей старых лэптопов. Если от OLDCARD для &t.releng.5; нельзя будет полностью отказаться, то должны быть сделаны шаги, которые позволят пользователям легко устанавливать ядро с поддержкой OLDCARD. Должна быть написана документация в помощь пользователям по переходу от OLDCARD к NEWCARD и от &man.pccardd.8; к &man.devd.8;. Функциональность по управлению электропитанием и dumpcis утилиты &man.pccardc.8; должна быть усилена поддержкой NEWCARD, а также возможностью подгружать информацию о нестандартном оборудовании CIS. Основной объём этих функций может быть интегрирован в &man.devd.8; и &man.devctl.4;. Новый планировщик задач: Он уже готов, и пользователи могут выбирать между классическим планировщиком 44BSD и новым планировщиком ULE. В ветке &t.releng.5; должен быть планировщик, имеющий привязку к процессору, поддержку HyperThreading и KSE, а также отсутствие снижения производительности или времени реакции системы. GDB: GDB в основном системном наборе должен работать со sparc64, а также понимать потоки KSE. Уже имеется GDB 5.3, сообщается, что он решает проблемы со sparc64. Документация: Справочные страницы, Руководство и FAQ должны быть очищены от содержимого, специфичного для &os; 4.X, то есть весь текст должен подходить и для &os; 5.X. Больше всего работы здесь предстоит сделать в разделе Руководства по установке. Документация к релизу должна быть полной и точной для всех архитектур уровня Tier-1. Особого внимания требуют замечания по оборудованию и инструкции по установке. Направление работ после &t.releng.5; Как это происходит и с другими ветками -STABLE, в основном работа над ней должна заключаться в исправлении ошибок и последовательном улучшении. Как обычно, всё должно проходить проверку в ветке &t.releng.head;, а затем внимательно переноситься в &t.releng.5;. Новые драйверы устройств, дополнительные возможности и тому подобные разработки приветствуются в этой ветке только после проверки в &t.releng.head;. Дальнейшая изоляция SMPng будет разделена на две категории, драйвер и подсистема. Единственной подсистемой, которая будет достаточно изолированной к выходу &t.releng.5;, будет GEOM, так что постепенное изолирование драйверов устройств под её управлением является достойной задачей этой ветки. Полная изоляция подсистемы будет выполнена и опробована в ветке &t.releng.head; до того, как будет принято решение о переносе её в ветку &t.releng.5;.
diff --git a/ru_RU.KOI8-R/articles/hats/article.sgml b/ru_RU.KOI8-R/articles/hats/article.sgml index e3938e6d86..c736b168b4 100644 --- a/ru_RU.KOI8-R/articles/hats/article.sgml +++ b/ru_RU.KOI8-R/articles/hats/article.sgml @@ -1,133 +1,133 @@ %articles.ent; ]>
Работа должностных лиц Уорнер Лош Текст предоставил $FreeBSD$ 2002 2003 Уорнер Лош Этот документ не является официальным заявлением Правления, но персональной интерпретацией одного из его членов позиции Правления, как действительного члена Правления и как бывшего руководителя департамента безопасности. Это всего лишь общие указания, а не палка для битья. Как &man.style.9; выступает в роли общего руководства для написания исходного кода, так и этот документ не претендует на роль тесного костюма. Когда управляющий совет назначает кому-то должность, его участники полагают, что человек будет отвечать за определённую часть дерева исходных текстов. Правление считает, что назначенной персоне будет принадлежать последнее слово в этой области кода, либо человек будет понимать, что его квалификации не хватает, и обратится за квалифицированной помощью. Правление рассчитывает на то, что этот человек будет руководить разработками этой части кода. Иногда это означает ведение ежедневной проактивной деятельности, а в некоторых случаях предполагает реактивный подход к просмотру кода, размещаемого в дереве исходных текстов. Когда разработчики предлагают патчи, которые потенциально могут отразиться на данной области дерева исходных текстов, Правление ожидает, что должностное лицо или его полномочный представитель просмотрят эти патчи. Правление полагает, что должностное лицо будет работать с человеком, предложившим патч, для решения проблем, которые могут возникнуть с этим патчем. Правление считает, что должностное лицо предложит решения и будет работать с разработчиком до момента достижения компромисса. Правление ожидает от должностного лица корректного поведения. В порядке вещей требовать от должностных лиц следования обычным правилам проекта при просмотре патчей (к примеру, что они в целом соответствуют &man.style.9; или общепринятому формату файла, что изменения в оформлении и содержимом - файла будут выполняться отдельно, и так далее). + файла будут выполняться отдельно.). При возникновении разногласий Правление ожидает, что должностное лицо приложит все усилия для нахождения компромисса либо другого способа разрешения конфликта. Должностное лицо должно общаться со всеми участниками корректно. Правление понимает, что в особо острых случаях должностному лицу требуется большая дубинка и возможность сказать нет, это изменение нам не подходит и не может быть включено в исходный код (или должно быть отменено). Правление рассматривает это проявление власти как последнее из возможных средств, и не будет одобрять действия должностных лиц, применяющих его слишком часто или в качестве первой реакции. Зачастую реальная жизнь пересекается с возможностью должностного лица по выполнению своих обязанностей. Условием, соблюдение которого Правление обычно требует от должностного лица, является наличие представителя, который может выполнять работу при отсутствии самого должностного лица. Ожидается, что этот представитель является активным участником той команды, которой руководит должностное лицо, и хорошо знает все проблемы, относящиеся к той части дерева исходных текстов, которой занимается должностное лицо. Предполагается, что представитель сможет работать в отсутствие должностного лица. К примеру, представители руководителя департамента безопасности рассылают бюллетени безопасности, когда руководителя нет рядом. В особых случаях представитель может отложить решение вопроса до появления должностного лица, но это должно быть скорее исключением, чем правилом, особенно если должностное лицо должно вернуться только в далёком будущем. Должностные лица отвечают перед Правлением. Если они работают хорошо, то Правление оставляют их в покое. Если должностные лица с работой не справляются, то Правление может освободить их от занимаемой должности. Предполагается, что должностные лица работают с Правлением, если у него есть претензии к выполнению обязанностей должностных лиц. Должностные лица выполняют волю Правления. Иногда Правление выдвигает дополнительные и специфические требования к определённому должностному лицу, которые отличаются от требований ко всем остальным должностям. Эти условия со временем могут меняться. От коммиттеров и прочие лиц, работающих с должностными лицами, ожидается соблюдение общих норм поведения и проявление вежливости по отношению к должностным лицам. Предполагается, что они работают с должностным лицом и его группой доя выработки решения, подходящего всем. В случае, если компромисс не может быть достигнут, от коммиттеров ожидается тактичное следование решению, принятому должностным лицом. В исключительных случаях против этого решения может быть подана апелляция Правлению. Однако обычно Правление не отменяет решения должностных лиц, если только они не теряют доверия или объективности. Правление не является техническим советом, и назначает должностных лиц для выполнения функций технических советов небольших масштабов, чтобы обсуждения проходили в соответствующей среде. Если коммиттер считает, что должностное лицо превышает свои полномочия или часто грубит разработчикам, то они должны сообщить об этом Правлению. Эта проблема может иметь технический, социальный или процедурный характер, а может представлять собой некую комбинацию или подмножество всех указанных признаков. Правление рассмотрит ваш случай и вынесет своё решение. Правление рассматривает конкретные жалобы, а не претензии общего характера, так как их легче разрешить. Правление считает, что коммиттеры работают вместе над решением своих проблем в соответствующих списках рассылки. Должностное лицо и его группа должны относительно редко выступать в роли именно должностного лица, а обычно как просто рядовой коммиттер. (Одним из исключением из этого правила является должность руководителя департамента безопасности, который должен устранять уязвимости втайне, до момента объявления об их наличии.) Должностное лицо должно быть первым среди равных, а не председателем совета директоров.
diff --git a/ru_RU.KOI8-R/articles/hubs/article.sgml b/ru_RU.KOI8-R/articles/hubs/article.sgml index 1ba324b232..4c121d1026 100644 --- a/ru_RU.KOI8-R/articles/hubs/article.sgml +++ b/ru_RU.KOI8-R/articles/hubs/article.sgml @@ -1,1105 +1,1110 @@ %articles.ent; ]>
Поддержка зеркал FreeBSD $FreeBSD$ Jun Kuriyama
kuriyama@FreeBSD.org
 Valentino Vaschetto
logo@FreeBSD.org
 Daniel Lang
dl@leo.org
 Ken Smith
kensmith@FreeBSD.org
 Дмитрий Морозовский Перевод на русский язык: &tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.general; Рабочий вариант статьи, описывающей процесс создания и поддержки зеркала FreeBSD и адресованной администраторам зеркал. Контактная информация Координаторы системы зеркал доступны по электронной почте по адресу mirror-admin@FreeBSD.org. Помимо этого, существует &a.hubs;. Требования к зеркалам FreeBSD Дисковое пространство Одним из наиболее важных требований является дисковое пространство. В зависимости от набора релизов, архитектур и степени полноты зеркала вам может потребоваться огромный объем диска. Не лишним будет помнить, что официальное зеркало, скорее всего, должно быть полным. Репозиторий CVS и веб-страницы всегда должны зеркалироваться полностью. Кроме того, учтите, что приводимые оценки объема относятся к состоянию на момент последнего редактирования данной статьи (&rel2.current;-RELEASE/&rel.current;-RELEASE). Дальнейший процесс разработки и последующие релизы только увеличат требуемый объем. Кроме того, разумно будет зарезервировать некоторое (10-20%) дополнительное пространство спокойствия ради. Вот некоторые оценки объема: - Полное зеркало FTP: 126 GB - Репозиторий CVS: 2.7 GB - Комплект изменений CTM: 1.8 GB - Веб-страницы: 300 MB + Полное зеркало FTP: 373 GB + Репозиторий CVS: 3.1 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 не требуют особенно много ресурсов; значительно больше памяти и вычислительной производительности потребляют CVSup, rsync или AnonCVS. Особенно "прожорливым" по памяти является rsync; CVSup требует достаточной производительности процессора. Для предоставления доступа по AnonCVS хорошей идеей будет создание виртуальной файловой системы в памяти (MFS) по крайней мере 300 MB размером, так что учтите это при планировании. Вот некоторые советы по конфигурации аппаратной части сервера: Для умеренно посещаемого сайта, предоставляющего 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;. CVSup непросто установить на платформе, отличной от FreeBSD, поскольку он написан на языке Modula-3 и требует соответствующего окружения. Джон Полстра создал усеченную версию 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,nodev 0 0 Эти установки (разумеется, тщательно подобранные) предложил &a.jdp;. Как вести зеркало 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. Короткий ответ: с зеркала, которое расположено недалеко от вас в терминах Интернет, и/или доступ к которому наилучший. Я хочу получить копию зеркала хоть откуда-нибудь! Если у вас нет каких-либо специальных предпочтений или требований, см. . Это означает: Посмотрите на список доступных зеркал в вашей стране. Вам может помочь База данных зеркал FreeBSD. Выберите те из них, с которыми вам работать быстрее всего (меньшее число промежуточных узлов и время отклика), и которые предоставляют нужные вам сервисы (такие как 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 не синхронизировалось в течение длительного времени, то зеркала следующего уровня будут синхронизироваться по устаревшей информации и т.д. Поддерживайте актуальность ваших зеркал! Как стать официальным зеркалом? Небезынтересный вопрос, в особенности если учитывать последствия становления официальным зеркалом, например, увеличившиеся счета за интернет от вашего провайдера (ведь нагрузка на ваш сервер неизбежно увеличится). Статус официального зеркала может быть ключевым требованием для доступа к основному сайту. Прежде чем отправлять заявку, убедитесь в необходимости дополнительного официального зеркала в вашем регионе. Справьтесь у администратора вашей зоны (hostmaster@CC.FreeBSD.org) или, в случае, если вам не отвечают, здесь: &a.hubs;. Собственно процедура такова: Обеспечьте работоспособность и актуальность зеркала (скорее всего, синхронизируясь не по основному сайту). Подпишитесь здесь на &a.hubs;. После успешного завершения предыдущих пунктов, напишите администратору DNS вашего региона (страны) и попросите его создать запись в зоне для вашего сайта. Почтовый адрес администратора hostmaster@CC.FreeBSD.org, где CC — код вашей страны (и суффикс домена верхнего уровня). Формат вашей записи в DNS описан в . Если для вашей страны пока не создано поддомена, свяжитесь с mirror-admin@FreeBSD.org или сначала напишите в &a.hubs;. Персона, помогавшая вам получить статус официального зеркала, должна послать письмо mirror-admin@FreeBSD.org, чтобы ваш сайт был включен в список официальных зеркал в Руководстве FreeBSD. Статистика некоторых зеркал Вот несколько ссылок на статистику использования зеркал Статистика 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 процессы)
diff --git a/ru_RU.KOI8-R/articles/laptop/article.sgml b/ru_RU.KOI8-R/articles/laptop/article.sgml index e40ed7388e..20c0b93882 100644 --- a/ru_RU.KOI8-R/articles/laptop/article.sgml +++ b/ru_RU.KOI8-R/articles/laptop/article.sgml @@ -1,302 +1,302 @@ %articles.ent; ]>
FreeBSD на лэптопах $FreeBSD$ Перевод на русский язык Виталий Богданов FreeBSD, за некоторым исключением, прекрасно работает на большинстве лэптопов. Далее обсуждаются вопросы, специфичные для работы FreeBSD на лэптопах, которые касаются аппаратных требований, отличающихся от настольных компьютеров. &tm-attrib.freebsd; &tm-attrib.linux; &tm-attrib.microsoft; &tm-attrib.general; FreeBSD часто воспринимается как операционная система для серверов, но она прекрасно работает и на настольных компьютерах, а если вы захотите использовать ее на вашем лэптопе, то вы получите все обычные преимущества: строгое распределение дискового пространства, простота администрирования и обновления, система портов/пакаджей для установки программного обеспечения и так далее. (Ее остальные преимущества, такие, как стабильность, высокая производительность сетевых операций и производительность при большой нагрузке, конечно, могут быть необычными для лэптопа.) Однако при ее установке на лэптопы часто возникают проблемы, которых нет на настольных машинах и редко обсуждаются (лэптопы, гораздо чаще, чем настольные машины, тонко настроены под µsoft.windows;). Эта статья предназначена для обсуждения этих проблем. Есть люди, которые задокументировали свой опыт работы с &os; на отдельных моделях лэптопов на web страничках, не являющихся частью &os; документации. Вы наверняка найдете некоторую информацию, если воспользуйтесь вашим любимым поисковиком, введя в нём модель лэптопа и слово &os;. Дополнительно существует специфичная для &os; база данных, цель которой давать информацию по аппаратным вопросам, связанным - с лэптопами, Список + с лэптопами, Список лэптопов, совместимых с &os;. Если вы хотите пообщаться с другими пользователями &os; на лэптопах, используйте список рассылки &a.mobile.name;. Вы также можете получить дополнительную информацию о использовании лэптопов во &os; по адресу . &xorg; Последние версии &xorg; работают с большинством графических адаптеров, применяемых в лэптопах в настоящее время. Ускорители могут не поддерживаться, но обычная конфигурация для SVGA будет работать. Обратитесь к документации по вашему лэптопу для выяснения того, какой адаптер используется и к документации по &xorg; для определения, поддерживается ли этот адаптер. Если он не поддерживается, используйте стандартное устройство (не пытайтесь использовать название, которое просто выглядит похожим). Вы можете попытать счастья с командой Xorg -configure, которая автоматически распознает много конфигураций. Часто проблема заключается в настройке монитора. Доступные источники информации по &xorg; посвящены CRT-мониторам, подбор подходящего режима работы для LCD-монитора может оказаться не простым занятием. Вам может повезти и вам не придется указывать режим, или будет достаточно указать подходящие параметры HorizSync и VertRefresh. Если это не сработает, лучше всего обратиться к ресурсам Интернет, посвященным настройке X на лэптопах (часто это сайты, ориентированны на Linux, но это не имеет значения, так как в обеих системах используется &xorg;) и скопировать режим, опубликованный кем-то с похожим оборудованием. Большинство лэптопов поставляются с двумя кнопками на позиционирующем устройстве, что достаточно проблематично в X (так как средняя кнопка часто используется для вставки текста); вы можете поставить в соответствие одновременное нажатие на левую и правую кнопки в вашей конфигурации X нажатию на среднюю кнопку строчкой Option "Emulate3Buttons" в файле xorg.conf в разделе InputDevice. Модемы Лэптопы обычно поставляются со встроенными (интегрированными на плате) модемами. К сожалению, это практически всегда означает, что это winmodemы, функциональность которых реализована программно, и для них обычно имеются драйверы только для &windows; (хотя начали появляться некоторые драйверы и для других операционных систем; например, если у вашего модема Lucent LT чипсет, то он будет поддерживаться портом comms/ltmdm). Если это ваш случай вам нужно приобрести внешний модем; самым компактным решением, наверное, является модем стандарта PC Card (PCMCIA), что обсуждается ниже, но модемы с последовательным интерфейсом или интерфейсом USB могут оказаться дешевле. В общем, обычные (не-winmodem) модемы должны работать нормально. Устройства PCMCIA (PC Card) Большинство лэптопов поставляются с разъемами PCMCIA (также называемые PC Card); они прекрасно поддерживаются во FreeBSD. Просмотрите (при помощи &man.dmesg.8;) сообщения, выдаваемые при загрузке, и определите, были ли они правильно распознаны (слоты должны распознаваться как pccard0, pccard1 и так далее на устройствах типа pcic0). &os; 4.X поддерживает 16-разрядные карты PCMCIA, а &os; 5.X поддерживает как 16-разрядные, так и 32-разрядные (CardBus). База данных поддерживаемых карт находится в файле /etc/defaults/pccard.conf. Просмотрите его, и при покупке старайтесь выбрать карты, перечисленные здесь. Карты, не указанные здесь, могут также работать как стандартные устройства: в частности, большинство модемов (16-битных) должны работать нормально, при условии, что это не win-модем (они существуют и в варианте PC-карт(PC Cards), так что будьте внимательны). Если ваша карта распознается как обычный модем, заметьте, что по умолчанию в файле pccard.conf задана пауза в 10 секунд (во избежание зависания некоторых модемов); это может оказаться излишним для вашего модема, так что вы можете изменить это значение, уменьшим его или убрав совсем. Некоторые разделы pccard.conf могут потребовать редактирования. Проверьте строчку с irq и обязательно удалите любые значения, которые уже используются: в частности, если у вас есть встроенный звуковой адаптер, уберите irq 5 (в противном случае вы получите сбой при попытке вставить карту). Проверьте также наличие доступных слотов для памяти; если ваша карта не распознана, попробуйте изменить значение на одно из других разрешенных (они перечислены на справочной странице &man.pccardc.8;). Запустите даемон &man.pccardd.8;, если он еще не запущен. Для запуска его при загрузке добавьте в файл /etc/rc.conf строчку pccard_enable="YES" Теперь ваши карты должны обнаруживаться, когда вы их вставляете и вытаскиваете, и вы должны получать диагностические сообщения о появлении новых устройств. Перед релизом &os; 4.4 в коде pccard произошли большие изменения (включая перенаправление прерываний ISA для тех машин, с PCI BIOS которых &os; работать не может). Если у вас возникли проблемы, попробуйте обновить вашу систему. Управление электропитанием К сожалению, оно не очень надежно поддерживается во FreeBSD. Если вам повезло, то некоторые функции могут работать нормально; либо они не будут работать вовсе. Чтобы сделать вещи немножко сложнее, существует два стандарта по управлению электропитанием: APM и ACPI, последний заменяет собой первый и включает больше возможностей, но также вносит больше проблем. Некоторые лэптопы поддерживают и APM и ACPI (в разной степени), другие поддерживают только один из них, поэтому возможно вам придётся поэкспериментировать с обоими для получения надёжного управления питанием на вашем лэптопе. Вы не можете иметь одновременно включенными APM и ACPI, даже если если ваш лэптоп поддерживает и тот и другой стандарты. APM The APM (Advanced Power Management) BIOS предоставляет поддержку различных возможностей по управлению электропитанием, таких как ожидание (standby), приостановление (suspend), режим пониженного электропотребления (hibernation), замедление тактовых импульсов CPU (CPU clock) и так далее, и доступен во &os; 4.X и &os; 5.X. Чтобы включить поддержку APM, вы можете скомпилировать ядро с поддержкой управления электропитанием (device apm0 во &os; 4.X и device apm во &os; 5.X). Во &os; 5.X имеется модуль ядра для APM. Чтобы загрузить модуль ядра поддержки APM во время загрузки добавьте строчку apm_load="YES" в /boot/loader.conf. Во &os; 5.X, вам также нужно установить hint.apm.0.disabled="0" в /boot/device.hints. Вы можете запустить APM во время загрузки посредством добавления apm_enable="YES" в файл /etc/rc.conf. Вы возможно также захотите запустить даемон &man.apmd.8;, добавив apmd_enable="YES" в /etc/rc.conf, который позаботится о различных событиях APM, посылаемых к BIOS, так чтобы вы могли иметь на вашем лэптопе приостановление/продолжение работы с помощью нажатия некой функциональной клавиши на клавиатуре или с помощью закрытия/открытия крышки. Команды APM перечислены в справочной странице &man.apm.8;. К примеру, apm -b выдаёт статус батарей (или 255, если не поддерживается), apm -Z переводит лэптоп в режим ожидания, apm -z (или zzz) приостановит его. Для выключения и отключения машины от питания, воспользуйтесь командой shutdown -p. И снова, некоторые или все эти функции могут не работать нормально или не работать вовсе. Вы можете обнаружить, что переключение режимов suspension/standby лэптопа работает в режиме консоли, но не работает в режиме X (то есть экран не восстанавливается); если вы используйте &os; 5.X, то возможным решением может быть добавление options SC_NO_SUSPEND_VTYSWITCH в ваш конфигурационный файл ядра и перекомпилирование ядра. Другое решение - это переключение на виртуальную консоль (при помощи CtrlAltF1 или другой функциональной клавиши) и запуск &man.apm.8;. Если вы используйте &man.apmd.8;, вы можете автоматизировать это с помощью &man.vidcontrol.1;. Просто отредактируйте /etc/apmd.conf и измените его на: apm_event SUSPENDREQ { exec "vidcontrol -s 1 < /dev/console"; exec "/etc/rc.suspend"; } apm_event USERSUSPENDREQ { exec "vidcontrol -s 1 < /dev/console"; exec "sync && sync && sync"; exec "sleep 1"; exec "apm -z"; } apm_event NORMRESUME, STANDBYRESUME { exec "/etc/rc.resume"; exec "vidcontrol -s 9 < /dev/console"; } ACPI ACPI (Advanced Configuration and Power Management Interface) предлагает не только управление электропитанием, но и платформенное обнаружение оборудования (platform hardware discovery) (вытесняющее PnP и PCI BIOS). ACPI доступен только в &os; 5.X и включён по умолчанию, поэтому вам не нужно ничего специально делать чтобы включить его. Вы можете контролировать поведение ACPI с помощью &man.acpiconf.8;. К сожалению, поставщики часто поставляют лэптопы с некорректной реализацией ACPI, и поэтому наличие включённого ACPI иногда вызывает больше проблем, чем приносит пользы, вплоть до того, что вы не можете даже загрузить &os; на некоторых машинах со включённым ACPI. Если ACPI вызывает проблемы, проверьте, не выпустил ли поставщик вашего лэптопа новую версию BIOS, устраняющую некоторые ошибки. Так как реализация ACPI в &os; до сих пор быстро развивающийся код, вы также можете обновить вашу систему, поэтому есть шансы, что ваши проблемы исправлены. Если вы хотите отключить ACPI, добавьте hint.acpi.0.disabled="1" в файл /boot/device.hints. Вы можете временно отключить ACPI на стадии загрузчика, набрав команду unset acpi_load, если у вас имеются проблемы с загрузкой машины со включённым ACPI. &os; 5.1-RELEASE и последующие релизы содержат загрузочное меню, с помощью которого можно контролировать загрузку &os;. Одна из предлагаемых опций - это отключение ACPI. Итак, чтобы выключить ACPI, просто выберите пункт 2. Boot &os; with ACPI disabled в меню. Управление электропитанием дисплея X window system (&xorg;) также включает в себя систему управления электропитанием дисплея (обратитесь к справочной странице по &man.xset.1; и поищите там ключевое слово dpms). Вы можете захотеть поэкспериментировать с этой функцией. Однако это также на лэптопах работает нестабильно; часто дисплей выключается не полностью.
diff --git a/ru_RU.KOI8-R/articles/new-users/article.sgml b/ru_RU.KOI8-R/articles/new-users/article.sgml index 6beee1f76f..91c5820307 100644 --- a/ru_RU.KOI8-R/articles/new-users/article.sgml +++ b/ru_RU.KOI8-R/articles/new-users/article.sgml @@ -1,1073 +1,1073 @@ %articles.ent; ]>
Пособие для новичков во FreeBSD и &unix; Annelise Anderson
andrsn@andrsn.stanford.edu
 15 августа 1997 &tm-attrib.freebsd; &tm-attrib.ibm; &tm-attrib.microsoft; &tm-attrib.netscape; &tm-attrib.opengroup; &tm-attrib.general; Поздравляем вас с установкой 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 Выдаёт перечень файлов, находящихся в текущем каталоге, добавляя символы * после выполнимых файлов, / после каталогов и @ после символических ссылок. ls Выдаёт перечень файлов в расширенном формате—размер, дата и права доступа. ls Вместе со всеми выдаёт и список скрытых 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 msdos /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. Надеемся, это срабатывает! справочные страницы лучше всего + 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 через дискету или ваш раздел DOS. Прочтите Makefile (при помощи команд cat, more или view), чтобы понять, куда нужно обратиться (на основной сайт распространения) для получения файла и какого его название. Его имя будет усекаться при сгрузке в DOS, а после того, как вы перенесёте его в каталог /usr/ports/distfiles, вы должны его переименовать (по команде mv) в его первоначальное название, чтобы он мог быть найден. (Используйте двоичный тип передачи файлов!) Затем перейдите обратно в каталог /usr/local/kermit, найдите каталог с Makefile и наберите make all install. Ещё одной проблемой, встречающейся при установке портов или пакетов, является их потребность в какой-то другой программе. Если установка чего-либо прекращается с выдачей сообщения can't find unzip или ему подобного, вам может потребоваться установка пакета или порта для утилиты unzip, чтобы продолжить. После того, как установка будет выполнена, наберите команду rehash для того, чтобы заставить FreeBSD перечитать файлы, находящиеся в маршрутах поиска, чтобы система обнаружила их появление. (Если вы получили массу сообщений path not found при использовании whereis или which, то вам необходимо сделать добавления к перечню каталогов в команде определения маршрута в файле .cshrc, находящемся а вашем домашнем каталоге. Задание маршрута в &unix; несёт ту же самую функцию, что и в DOS, за исключением работы с текущим каталогом (по умолчанию) по соображениям безопасности; если команда, которую вы хотите выполнить, находится в текущем каталоге, вам нужно набирать ./ перед названием команды, чтобы она заработала; пробелов после слэша ставить не нужно.) Вам может потребоваться получить самую последнюю версию &netscape; с их FTP-сайта. (&netscape; требует X Window System.) На данный момент существует и версия для FreeBSD, так что посмотрите вокруг внимательней. Просто воспользуйтесь командой gunzip filename и tar xvf filename с полученным файлом, перенесите его в каталог /usr/local/bin или куда-то ещё, где хранятся бинарные файлы, выполните команду rehash, а затем добавьте следующие строки в файлы .cshrc в домашних каталогах всех пользователей или (что проще) в файл /etc/csh.cshrc, общесистемный файл для запуска csh: setenv XKEYSYMDB /usr/X11R6/lib/X11/XKeysymDB setenv XNLSPATH /usr/X11R6/lib/X11/nls При этом предполагается, что файл XKeysymDB и каталог nls находятся в /usr/X11R6/lib/X11; если это не так, найдите их и поместите сюда. Если изначально вы получили &netscape; в виде порта при помощи CDROM (или FTP), не заменяйте файл /usr/local/bin/netscape новым бинарным файлом netscape; это всего лишь скрипт командного процессора, который настраивает для вас переменные окружения. Вместо этого переименуйте новый бинарный файл в netscape.bin и замените старый двоичный файл, а именно /usr/local/netscape/netscape. Ваше рабочее окружение Ваш командный процессор является самой важной частью вашего рабочего окружения. В 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/portbuild/article.sgml b/ru_RU.KOI8-R/articles/portbuild/article.sgml index fdef327ccd..8c7dd0c2bc 100644 --- a/ru_RU.KOI8-R/articles/portbuild/article.sgml +++ b/ru_RU.KOI8-R/articles/portbuild/article.sgml @@ -1,750 +1,756 @@ %articles.ent; ]>
Процесс построения пакетов Группа поддержки портов &os; $FreeBSD$ 2003 2004 2005 2006 Группа поддержки портов &os; &tm-attrib.freebsd; &tm-attrib.intel; &tm-attrib.sparc; &tm-attrib.general; Введение Для того, чтобы подготовить предкомпилированные версии поддерживаемых приложений для &os;, на одном из Кластеров сборки пакетов регулярно производится сборка полного дерева портов. В настоящее время существует два таких кластера: pointyhat.FreeBSD.org и dosirak.kr.FreeBSD.org. Большая часть магии процесса сборки сосредоточена в дереве каталогов /var/portbuild. Если не оговаривается иное, все пути указаны относительно этого каталога. ${arch} используется для указания на архитектуру платформы сборки (&i386;, alpha, &sparc64;, ia64 или amd64); ${branch} описывает ветвь построения (4, 5, 5-exp, 6, 6-exp и 7). Конфигурация машин-клиентов Клиенты архитектур &i386;, alpha, amd64 и два из &sparc64; клиентов загружаются по сети с pointyhat; прочие sparc64 клиенты и машины для сборки ia64 загружаются самостоятельно. Так или иначе, все они в процессе загрузки подготавливаются к сборке пакетов. В серии последних обновлений была добавлена поддержка несвязанных (disconnected) узлов кластера. Несвязанный узел не монтирует мастер-машину кластера по NFS, и может, таким образом, быть достаточно удален от центра. Мастер-машина копирует нужные данные (иерархии портов, исходных текстов системы, архивы системы, скрипты и т.п.) при помощи rsync на этапе начальной конфигурации узлов. Затем, каталог portbuild монтируется как nullfs для сборок пакетов. Псевдо-пользователь ports-${arch} может выполнить команду &man.ssh.1; от имени root на любую клиентскую машину архитектуры ${arch}. Скрипт scripts/allgohans используется для выполнения команд на всех клиентах архитектуры ${arch}. Скрипт scripts/checkmachines отслеживает уровень загрузки узлов кластера и распределяет, какой из узлов будет строить очередной порт. Этот скрипт не слишком умен и время от времени умирает. Лучше всего запускать его при загрузке основной машины кластера (pointyhat или dosirak) в цикле &man.while.1;. Подготовка ограниченной среды сборки Пакеты собираются в ограниченной (chroot) среде, которая разворачивается скриптом portbuild из архива ${arch}/${branch}/tarballs/bindist.tar. Этот архив создается при помощи скрипта mkbindist, конфигурация которого описывается файлом ${arch}/${branch}/mkbindist.conf. Скрипт должен запускаться с правами пользователя root и следующими параметрами: /var/portbuild&prompt.root; scripts/mkbindist ${arch} ${branch} При указании в файле mkbindist.conf параметра ftp=1 с адреса ftp://${ftpserver}/${ftpurl}/${rel} будет загружен предварительно собранный релиз. Если указано ftp=0 и buildworld=1, скрипт mkbindist выполнит makeworld для того, чтобы собрать релиз на месте [XXX Эта часть в настоящее время не работает]. Если оба параметра равны нулю (ftp=0 и buildworld=0), то mkbindist будет использовать существующее на момент запуска состояние дерева ${worlddir} для создания bindist.tar. На практике это означает, что вы должны предварительно установить систему в ${worlddir}, что обычно делается при помощи скрипта makeworld: /var/portbuild&prompt.root; scripts/makeworld ${arch} ${branch} [-nocvs] Эта команда соберет систему на базе исходных текстов в дереве ${arch}/${branch}/src и установит ее в ${worlddir}. Исходные тексты будут обновлены, если не указан параметр -nocvs. Содержимое архива bindist.tar будет распаковано на каждом клиенте в период загрузки, а также на старте каждого прохода скрипта dopackages. Запуск сборки Для сборки пакетов используются скрипты scripts/dopackages*. Наиболее полезными являются: dopackages.4 - собирает пакеты для версии 4.X dopackages.5 - собирает пакеты для версии 5.X dopackages.5-exp - производит сборку ветви для версии 5.X с экспериментальными изменениями (ветвь 5-exp) dopackages.6 - собирает пакеты для версии 6.X dopackages.6-exp - производит сборку ветви для версии 6.X с экспериментальными изменениями (ветвь 6-exp) dopackages.7 - собирает пакеты для версии 7.X Все они вызывают универсальный скрипт dopackages, и являются символьными ссылками на dopackages.wrapper. Для создания скрипта для сборки пакетов новой ветви достаточно создать символическую ссылку dopackages.${branch}, указывающую на dopackages.wrapper. Могут быть указаны многочисленные параметры, например: dopackages.6 ${arch} [-options] [-options] может быть произвольным набором из следующих опций: -nofinish - Не производить пост-обработку по завершении сборки. Полезно, если процесс сборки потребуется рестартовать. В обычных ситуациях эту опцию следует использовать всегда. -finish - Произвести пост-обработку (и только: собственно сборку не производить). -restart - Рестартовать прерванный (или незавершенный, т.е. запущенный без флага -finish) процесс сборки с самого начала. При этом порты, попытка сборки которых на предыдущем проходе завершилась неудачно, будут пересобраны. -continue - Продолжить прерванный (или незавершенный) процесс сборки. Порты, не прошедшие сборку, не пересобираются. -incremental - Сравнить необходимые поля в текущем файле INDEX с его предыдущим состоянием, удалить пакеты и журналы их сборки для обновившихся портов и пересобрать их. Этот ключ позволяет существенно сократить время сборки, поскольку нет необходимости пересобирать каждый раз не изменившиеся порты. -cdrom - Текущая сборка предназначена для помещения на CD-ROM, поэтому исходные архивы и пакеты портов, помеченных NO_CDROM должны быть удалены при пост-обработке. -nobuild - Произвести первоначальную подготовку, не запуская собственно процесс сборки пакетов. -noindex - Не перестраивать файл INDEX в ходе препроцессинга. -noduds - Не перестраивать файл duds (список портов, которые не будут строиться, например, помеченные признаками IGNORE, NO_PACKAGE и т.п.) перед процессом сборки. -trybroken - Пытаться собрать порты, помеченные как BROKEN (по умолчанию выключено, поскольку кластер архитектуры &i386; довольно быстр, и при - инкрементальной сборке больше времени тратится на пересборку + инкрементной сборке больше времени тратится на пересборку того, что все равно не сможет собраться. С другой стороны, кластеры других архитектур достаточно медленны, так что пытаться собирать на них порты с флагом BROKEN было бы напрасной тратой времени. -nocvs - Не выполнять обновление (cvs update) дерева исходных текстов (src) на этапе препроцессинга. -noportscvs - Не обновлять (cvs update) дерево портов (ports) на этапе препроцессинга. -nodoccvs - Не обновлять (cvs update) дерево документации (doc) в ходе препроцессинга. (устаревшая опция) -norestr - Не пытаться компилировать порты, помеченные как RESTRICTED. -plistcheck - Считать ошибкой оставление лишних файлов после деинсталляции порта. -distfiles - Собрать архивы исходных файлов (distfiles) для дальнейшего их переноса на ftp-master. Эту опцию следует использовать изредка, поскольку она требует очень много места. Исходные архивы следует удалить после загрузки их на ftp-master. -fetch-original - Загружать исходные архивы с оригинальных сайтов, определенных переменными MASTER_SITES, а не с ftp-master. Убедитесь, что процесс сборки пакетов для архитектуры ${arch} запускается от имени пользователя ports-${arch}; в противном случае ошибки неизбежны. Сборка пакетов производится в два идентичных прохода. Иногда временные проблемы, такие как ошибки NFS или недоступность FTP-сайтов, могут прервать сборку. Дублирование попыток позволяет обойти подобные проблемы. Проверьте, чтобы ports/Makefile не ссылался на пустые подкаталоги. В особенности это важно для сборки ветви -exp. Если процесс сборки обнаруживает пустой каталог, обе фазы сборки вскоре остановятся. При этом в файлы ${arch}/${branch}/make.[0|1] будет записано сообщение об ошибке примерно такого вида: don't know how to make dns-all(continuing) Для исправления ситуации просто закомментируйте или удалите строчки SUBDIR, указывающие на пустые подкаталоги. После этого вы можете перезапустить сборку командой dopackages, добавив ей параметр -restart. Та же проблема возникает при создании файла Makefile для новой категории, не содержащего ни одной ссылки на подкаталоги (SUBDIR). Это, скорее всего, ошибка, подлежащая исправлению. Процесс сборки Полный процесс сборки без каких-либо ключей, начинающихся с -no, выполняет следующую последовательность операций: Обновление из CVS-репозитория текущего дерева ports [*] Обновление из CVS-репозитория дерева src необходимой ветви [*] Проверка файлов Makefile на отсутствие строк SUBDIR [*] Создание файла duds, содержащего список портов, которые не надо пытаться собирать [*] [+] Генерация нового файла INDEX [*] [+] Начальная подготовка узлов, которые будут участвовать в сборке [*] [+] Построение списка портов ограниченного распространения (restricted) [*] [+] Сборка пакетов (фаза 1) [++] Повторная установка узлов сборки [+] Сборка пакетов (фаза 2) [++] [*] Результаты выполнения этих шагов записываются в файл ${arch}/${branch}/build.log, а также в стандартный вывод для ошибок консоли, с которой запускался скрипт dopackages. [+] При неудачном завершении любого из этих шагов процесс прекращается. [++] Результаты выполнения пишутся в файл ${arch}/${branch}/make.[0|1], где make.0 соответствует первой, а make.1 второй фазе сборки. Журналы сборки отдельных портов записываются в файлы ${arch}/${branch}/logs, а журналы портов, собравшихся неудачно, в ${arch}/${branch}/errors. Ранее из репозитория извлекалось также дерево документации; в настоящий момент это считается ненужным. Прерывание процесса сборки Для прерывания процесса сборки обычно достаточно послать сигнал HUP процессам dopackages* или вызванным ими процессам make. Процессы, запущенные на узлах сборки, завершатся самостоятельно в течение нескольких минут (их наличие следует проверять командой ps x). Обычно достаточно следующей команды: &prompt.user; killall -HUP sh ssh make Удалите файл ${arch}/lock перед тем, как перезапустите сборку. Слежение за процессом Команда scripts/stats ${branch} показывает количество собранных на настоящий момент пакетов. Команда cat /var/portbuild/*/loads/* покажет текущую загрузку клиентских машин и количество процессов сборки, запущенных на них. Выполнение tail -f ${arch}/${branch}/build.log продемонстрирует общее состояние процесса сборки. В случае, если порт не собирается, и из логов не понятны причины этого, вы можете сохранить рабочий каталог сборки (WRKDIR) для последующего анализа. Для этого создайте файл .keep в каталоге порта. При следующей сборке порта кластером архив WRKDIR будет помещен в файл ${arch}/${branch}/wrkdirs. Следите за выводом команды &man.df.1;. Если файловая система, содержащая /var/portbuild, переполнится, будет Очень Плохо. Сборка пакетов для релизов При сборке пакетов для включения в релиз может потребоваться ручное обновление иерархий ports и src до нужного тэга, а также использование опций -nocvs и -noportscvs. Для подготовки комплекта пакетов для помещения на CD-ROM используйте параметр -cdrom при запуске dopackages. Если на кластере достаточно дискового пространства, можно применить ключ -distfiles для выкачивания дистрибутивных архивов. Первая сборка должна быть произведена с параметром -distfiles. По завершении первого процесса сборки перезапустите его с параметрами -restart -distfiles -fetch-original, для того чтобы выкачать обновленные дистрибутивы. Затем, на этапе финальной обработки, соберите список файлов при помощи команды &prompt.user; cd ${arch}/${branch} &prompt.user; find distfiles > distfiles-${release} Этот файл обычно копируют в каталог i386/${branch} главной машины кластера. Данная процедура помогает чистить комплект дистрибутивных архивов, располагающийся на ftp-master. Если дисковое пространство заканчивается, можно сохранить архивы для свежих релизов, а прочие — удалить. После копирования дистрибутивов (см. ниже) надо создать окончательный комплект пакетов для релиза. Для полного спокойствия, запустите скрипт ${arch}/${branch}/cdrom.sh вручную, чтобы быть уверенным, что все пакеты ограниченного распространения и их исходные архивы удалены. Затем скопируйте каталог ${arch}/${branch}/packages в ${arch}/${branch}/packages-${release}. После того, как пакеты переложены в надежное место, свяжитесь с группой &a.re; и сообщите им расположение финального комплекта пакетов. Помните о необходимости координации с группой &a.re; по поводу времени и статуса сборки пакетов для релизов. Загрузка пакетов для раздачи После завершения сборки пакеты и/или их исходные архивы могут быть загружены на ftp-master для раздачи по сети зеркал FTP. Если сборка велась с ключом -nofinish, не забудьте произвести пост-обработку при помощи команды dopackages -finish (будут удалены пакеты, помеченные как RESTRICTED и NO_CDROM, а также пакеты, отсутствующие в файле INDEX, из файла INDEX будут удалены ссылки на не собравшиеся пакеты, и, наконец, будет создан файл CHECKSUM.MD5 с контрольными суммами собранных пакетов; кроме того, эта фаза переместит исходные архивы из каталога distfiles/.pbtmp в distfiles/, а также удалит исходные архивы для портов, помеченных как RESTRICTED и NO_CDROM). Хорошей идеей является запустить вручную скрипты restricted.sh и/или cdrom.sh после завершения работы dopackages просто для собственного спокойствия. Скрипт restricted.sh запускается перед копированием на ftp-master; затем, перед подготовкой финального набора пакетов для релиза выполните cdrom.sh. Пакеты можно копировать во временную область на ftp-master примерно такой командой: &prompt.root; cd /var/portbuild/${arch}/${branch} &prompt.root; tar cfv - packages/ | ssh portmgr@ftp-master tar xfC - w/ports/${arch}/tmp/${branch} Затем, на машине ftp-master, убедитесь, что набор пакетов скопирован корректно, удалите старый набор (из каталога ~/w/ports/${arch}), и переместите новый на его место. Некоторые каталоги на ftp-master на самом деле являются символьными ссылками. Убедитесь, что вы перемещаете новый набор пакетов в реальный каталог, а не на место расположения одной из ссылок. + Для инкрементных сборок пакеты должны загружаться посредством + rsync. Так мы не создаём сильной загрузки на + зеркалах: + + &prompt.root; rsync -n -r -v -l -t -p --delete packages/ portmgr@ftp-master:w/ports/${arch}/${branch}/ | tee log + Дистрибутивные архивы копируются при помощи команды rsync: &prompt.root; cd /var/portbuild/${arch}/${branch} &prompt.root; rsync -r -v -l -p -c -n distfiles/ portmgr@ftp-master:w/ports/distfiles/ | tee log ВСЕГДА для начала используйте ключ -n команды rsync и проверяйте ее вывод. Если все выглядит нормально, перезапустите rsync без опции -n. Экспериментальная сборка Время от времени для тестирования новых возможностей или исправлений общей инфраструктуры портов (bsd.port.mk), а также для тестирования крупных обновлений, затрагивающих существенную часть пакетов, проводится сборка с экспериментальными патчами. Текущей экспериментальной веткой является 6-exp в архитектуре &i386;. В целом, экспериментальная сборка производится так же, как и обычная. Основное отличие: перед запуском скрипта dopackages нужно применить к дереву портов необходимые изменения. Хорошей идеей будет сохранить копии всех изменяемых файлов, а также их список. К списку вы сможете вернуться перед произведением окончательного коммита. Для создания контрольного экземпляра для сравнения следует сначала произвести сборку той ветви архитектуры &i386;, на которой основана экспериментальная ветвь (в настоящее время это ветвь 6). Перед экспериментальной сборкой выгрузите деревья src и ports на момент произведения контрольной сборки. В этом случае вы можете быть уверены, что сравниваете яблоки с яблоками. Два кластера сборки могут производить контрольную и экспериментальную сборку одновременно. Это может ощутимо сэкономить общее время сборки. По завершении сборки сравните результаты контрольной и экспериментальной сборок примерно такой командой (предполагается, что контрольной является ветка 6, а экспериментальной — 6-exp): &prompt.user; cd /var/portbuild/i386/6-exp/errors &prompt.user; find . -name \*.log\* | sort > /tmp/6-exp-errs &prompt.user; cd /var/portbuild/i386/6/errors &prompt.user; find . -name \*.log\* | sort > /tmp/6-errs Если с момента завершения одной из сборок прошло достаточно много времени, журналы сборки могут быть автоматически архивированы bzip2. В этом случае используйте sort | sed 's,\.bz2,,g'. &prompt.user; comm -3 /tmp/6-errs /tmp/6-exp-errs | less Результатом работы последней команды будет отчет, состоящий из двух столбцов. В первой колонке будут перечислены порты, сборка которых не удалась в контрольном, но не в экспериментальном случае; второй столбец описывает противоположную ситуацию. Причины, по которым порт может оказаться в первом списке, включают: Порт был исправлен с момента последнего контрольного запуска, или обновлен до более свежей версии, которая также не собирается (порт с новой версией появится во втором столбце) Сборка порта исправлена патчами экспериментальной версии Порт не собирается экспериментальной сборкой из-за ошибок в зависимых портах Во втором столбце порт может оказаться по следующим причинам: Порт не собирается с экспериментальными изменениями [1] Порт был обновлен с момента контрольной сборки и стал несобираемым [2] Порт не собрался по причине временных ошибок (недоступный FTP сайт, ошибка ввода-вывода на клиенте и т.п.) Перед коммитом экспериментальных обновлений необходимо изучить содержимое обоих столбцов. Чтобы отличить ситуации [1] и [2], можно пересобрать соответствующие пакеты в контрольной ветке: &prompt.user; cd /var/portbuild/i386/6/ports Не забудьте обновить дерево портов до той же даты, что и дерево экспериментальной сборки. Для подготовки контрольной ветви используйте команду: &prompt.user; /var/portbuild/scripts/dopackages.6 -noportscvs -nobuild -nocvs -nofinish Сборка должна производиться из каталога packages/All. Изначально этот каталог должен быть пуст, за исключением символьной ссылки Makefile. Если этой ссылки нет, создайте ее: &prompt.user; cd /var/portbuild/i386/6/packages/All &prompt.user; ln -sf ../../Makefile . &prompt.user; make -k -j<#> <список пакетов для сборки> <#> описывает уровень параллелизма сборки. Обычно, это сумма весов клиентских машин, указанных в /var/portbuild/i386/mlist, если у вас нет причин проводить более тяжелую или, наоборот, облегченную сборку. <список пакетов для сборки> представляет собой список имен пакетов (включая их версии) в том виде, как они представлены в файле INDEX. Суффикс PKGSUFFIX (.tgz or .tbz) является необязательным. Будут собраны только указанные пакеты, а также их зависимые порты. Процесс сборки можно контролировать так же, как и стандартную сборку. После того, как все ошибки исправлены, вы можете произвести коммит комплекта исправлений. Является хорошим тоном отправить письмо с темой HEADS UP в списки рассылки ports@FreeBSD.org и ports-developers@FreeBSD.org с информацией о внесенных изменениях. Краткая аннотация изменений также должна быть добавлена в файл /usr/ports/CHANGES.
diff --git a/ru_RU.KOI8-R/articles/relaydelay/article.sgml b/ru_RU.KOI8-R/articles/relaydelay/article.sgml index a8c784496e..ff1fc68ced 100644 --- a/ru_RU.KOI8-R/articles/relaydelay/article.sgml +++ b/ru_RU.KOI8-R/articles/relaydelay/article.sgml @@ -1,292 +1,292 @@ %articles.ent; ]>
Использование технологии серых списков во &os; Том Родес
trhodes@FreeBSD.org
 2004 The &os; Documentation Project Эта статья создана исключительно для описания технологии задержки передачи сообщений на почтовом сервере &os;. Сервер с технологией задержки передачи (relaydelay) или попаданием в серый список (greylisting) снижает уровень спама просто за счёт выдачи диагностического сообщения TEMPFAIL на каждое входящее почтовое сообщение. Смысл этой технологии заключается в том, что большинство спамеров для выполнения своей работы используют собственные персональные компьютеры и специализированное программное обеспечение. Настоящий почтовый сервер должен помещать сообщения в очередь и пытаться доставить его позже. Таким образом, скорее всего, спамер перейдёт к следующему хосту вместо того, чтобы попытаться снова послать электронное послание. Это прекрасная идея; по крайней мере, до тех пор, пока спамеры не начнут использовать программное обеспечение, которое будет обеспечивать повтор передачи. Но как именно это работает? Итак, в процессе приёма сообщения электронной почты ID сообщения сохраняется в базе данных, а в качестве результата возвращается TEMPFAIL вместе с электронной почтой. Если сообщение электронной почты посылается повторно, то ID сообщения будет сверяться с ID сообщений, сохранёнными в базе данных. Если в базе данных оно существует, то посланию электронной почты разрешается доставка по назначению. В противном случае ID сохраняется, а в качестве результата возвратится TEMPFAIL. Этот цикл будет повторяться для каждого сообщения, поступающего на сервер. По моему личному опыту, это действительно отсекает 90% спама. Базовая настройка В базовый комплект &os; 4.X включён perl, но нам нужен perl с поддержкой многопоточного выполнения. Пользователи &os; 5.X смогут начать работу после того, как прочтут замечание ниже. Удалите базовый perl и все следы присутствия perl в системе при помощи следующей команды: &prompt.root find / -name '*perl*' | xargs rm -rf При этом потребуется, чтобы все порты, которым нужен perl, были перестроены и переустановлены; - sysutils/portupgrade хорошо для + ports-mgmt/portupgrade хорошо для этого подходит. По крайней мере, он укажет, какие порты были удалены и какие необходимо переустановить. Установите lang/perl5.8 с установленной переменной USE_THREADS=yes. Сначала может потребоваться удалить текущую версию perl; на необходимость сделать это укажут ошибки в процессе установки. Пользователям &os; 4.X необходимо будет запустить команду use.perl в каталоге work. Для того, чтобы сделать файл исполнимым, может понадобиться изменение его прав доступа, я просто установил их значение в 755 при помощи утилиты chmod. Начиная с этого момента, всем пользователям &os; 4.X нужно раскомментировать параметр NOPERL в их локальном файле make.conf. В противном случае базовый perl при следующем обновлении будет переустановлен. Теперь что касается сервера базы данных; 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.