https://www.altlinux.org/api.php?action=feedcontributions&user=AntonFarygin&feedformat=atomALT Linux Wiki - Вклад [ru]2024-03-28T14:36:16ZВкладMediaWiki 1.38.2https://www.altlinux.org/index.php?title=%D0%90%D1%80%D1%85%D0%B8%D0%B2_%D0%A1%D0%B8%D0%B7%D0%B8%D1%84%D0%B0&diff=78878Архив Сизифа2024-03-12T09:21:50Z<p>AntonFarygin: на download.basealt.ru нет архива</p>
<hr />
<div>[[Category:Sisyphus]]<br />
<br />
<br />
== Архив Сизифа ==<br />
<br />
В [http://ftp.altlinux.org/pub/distributions/archive/sisyphus/ архиве Сизифа] фиксируется состояние репозитория по окончании коммита каждого задания. Каждое такое состояние доступно для apt как обычный репозиторий. Пример {{path|sources.list}} для [http://git.altlinux.org/tasks/archive/done/_262/268717/ задачи #268717] (262 -- результат целочисленного деления 268717/1024):<br />
rpm [alt] http://ftp.altlinux.org/pub/distributions/archive/sisyphus/task/archive/_262/268717/ x86_64 classic<br />
rpm [alt] http://ftp.altlinux.org/pub/distributions/archive/sisyphus/task/archive/_262/268717/ noarch classic<br />
<br />
Для более старых задач доступны только ссылки на ежедневный срез, впервые включающий её результаты. Пример {{path|sources.list}} для задания #119753 (116 -- результат целочисленного деления 119753/1024):<br />
rpm [alt] http://ftp.altlinux.org/pub/distributions/archive/sisyphus/task/archive/_116/119753/daily i586 classic<br />
rpm [alt] http://ftp.altlinux.org/pub/distributions/archive/sisyphus/task/archive/_116/119753/daily noarch classic<br />
<br />
В архиве [http://lists.altlinux.org/pipermail/devel/2013-October/197860.html доступны] индексы по исходным пакетам и по дате.<br />
<br />
'''[http://ftp.altlinux.org/pub/distributions/archive/sisyphus/date/ Индекс по дате]''' отражает состояние репозитория в конкретный день и также доступен для подключения к apt (см. также [[Downgrade]]). Пример {{path|sources.list}} для использования архива за определённую дату (7 октября 2013 года):<br />
rpm [alt] http://ftp.altlinux.org/pub/distributions/archive/sisyphus/date/2013/10/07 x86_64 classic<br />
rpm [alt] http://ftp.altlinux.org/pub/distributions/archive/sisyphus/date/2013/10/07 noarch classic<br />
<br />
'''[http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/src/ Индекс по исходным пакетам]''' позволяет увидеть, в каких заданиях и подзаданиях был собран пакет, дату и время сборки и версию собранного пакета. Примеры:<br />
* <tt>git</tt>: http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/src/g/git/.<br />
* <tt>kernel-source-ipt-netflow</tt> был удалён в [http://git.altlinux.org/tasks/archive/done/_132/135884/ задаче 135884], поэтому вместо номера версии стоит "-": http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/src/k/kernel-source-ipt-netflow/<br />
<br />
== Подключение архива через [[EPM]] ==<br />
# epm repo add archive 2019/09/26<br />
<br />
== Другие архивы (t7 .. p10) ==<br />
=== Пример для p9 ===<br />
<br />
Аналогично Sisyphus, см. индекс [http://ftp.altlinux.org/pub/distributions/archive/p9/index/src/ по исходным пакетам] и [http://ftp.altlinux.org/pub/distributions/archive/p9/date/ по дате]; (аналогично и для всех остальных от t7, p7 и p8 .. p10 и будущего p11 ... pN.<br />
<br />
Пример:<br />
rpm http://ftp.altlinux.org/pub/distributions/archive/p9/date/2019/09/26 x86_64 classic<br />
rpm http://ftp.altlinux.org/pub/distributions/archive/p9/date/2019/09/26 noarch classic<br />
rpm http://ftp.altlinux.org/pub/distributions/archive/p9/date/2019/09/26 x86_64-i586 classic<br />
<br />
=== Старый архив ===<br />
<br />
Закончил своё функционирование по техническим причинам (дисковое пространство и затруднительность переноса такого массива жёстких ссылок) до того, как был опубликован новый; тем временем благодаря {{man|naf}} [ftp://ftp.ossg.ru/Sisyphus-snapshots/ доступен] ещё один, и [ftp://ftp.ossg.ru/ рядом] есть аналогичные архивы копий 5.1, t6 и (в будущем) t7.</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%9A%D0%BE%D0%BC%D0%BF%D0%B0%D0%BD%D0%B8%D1%8F_%C2%AB%D0%91%D0%B0%D0%B7%D0%B0%D0%BB%D1%8C%D1%82_%D0%A1%D0%9F%D0%9E%C2%BB&diff=78671Компания «Базальт СПО»2024-02-23T19:59:09Z<p>AntonFarygin: </p>
<hr />
<div>[[Image:Basealt_logo.png|thumb|right|Логотип компании «Базальт СПО]]<br />
'''Компания «Базальт СПО»''' — коммерческая организация, занимающаяся, в числе прочего, разработкой, продажей и поддержкой решений и [[Releases|дистрибутивов ALT]] (под торговой маркой Альт) на базе разрабатываемого ALT Linux Team репозитория [[Sisyphus]] и [[Branches|стабильных веток репозитория]].<br />
<br />
Компания также занимается (с сентября 2015 года):<br />
* принимает участие вместе с ALT Linux Team в разработке инфраструктуры и пакетной базы Sisyphus <br />
* оказывает поддержку инфраструктуре Sisyphus и ресурсам сообщества в домене altlinux.org<br />
* помогает с портированием на [[ports/e2k|новые]] [[ports/aarch64|архитектуры]]<br />
<br />
== Ссылки ==<br />
* '''[http://basealt.ru/ Компания «Базальт СПО»]'''<br />
* [http://basealt.ru/about/news/archive/view/bazalt-spo-pervaja-rossiiskaja-os-urovnja-predprijati/ «Базальт СПО»: первая российская ОС уровня предприятия готова к масштабному применению в госсекторе]<br />
* [http://www.it-weekly.ru/it-news/thoughts/114568.html Алексей Смирнов: «Российские операционные системы уровня предприятия»]<br />
<br />
[[Категория:BaseALT]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=Shared_Libs_Policy&diff=78668Shared Libs Policy2024-02-22T11:44:16Z<p>AntonFarygin: /* Упаковка библиотек */</p>
<hr />
<div>{{DraftPolicy<br />
|responsible=PavlovKonstantin, MikhailGusarov, IgorVlasenko<br />
|metabug=repocop тесты library-pkgnames, lib-contains-devel-so<br />
}}<br />
<br />
Под библиотекой будем понимать .so файл, предназначенный для совместного использования многими программами.<br />
Под действие данного полиси не попадают .so файлы, которые явно загружаются конкретной программой (плагины).<br />
<br />
Библиотеки могут потенциально использоваться многими программами, из-за чего несовместимое изменение интерфейса любой библиотеки требует большого объёма работы по адаптации её клиентов. Для упрощения процесса обновления и уменьшения количества сломанных в каждый момент времени пакетов библиотеки различных несовместимых версий должны уметь сосуществовать в установленной системе.<br />
<br />
В дальнейшем несовместимое изменение ABI библиотеки будет называться «ломкой».<br />
<br />
'''Полиси одной строкой:<br>не стоит класть новый [[soname]] в пакет с тем же именем (где лежал старый soname).'''<br />
<br />
=== Упаковка библиотек ===<br />
<br />
Библиотека должна быть упакована в пакет, имя которого меняется при каждой ломке ABI.<br />
<br />
Пакет должен иметь название lib%name%abiversion, где %abiversion является изменяемой частью (если название библиотеки заканчивается на цифру, то во всех именах пакетов перед %abiversion нужно добавить '_': lib%{name}_%{abiversion}, lib%{name}_%{abiversion}-devel etc).<br />
<br />
В пакете с разделяемой библиотекой не должно быть файлов или каталогов, имена или пути которых не содержат версию ABI. Это позволит избежать в дальнейшем кофликтов по файлам между пакетами с библиотекой разных версий. При необходимости такие файлы стоит выносить в отдельный -common подпакет. Например, так сделано в [https://packages.altlinux.org/sisyphus/srpms/libxmlb/specfiles/ пакете libxmlb].<br />
<br />
В пакет с одной версией библиотеки нельзя паковать файлы библиотеками, имеющими разную версионированности ABI. Каждую из таких библиотек стоит упаковать в отдельный подпакет (пример см. [https://packages.altlinux.org/sisyphus/srpms/ffmpeg/ пакеты библиотек из ffmpeg] ).<br />
<br />
development-часть библиотек должны быть выделены в отдельный пакет, который должен иметь название lib%name-devel. <br />
Если планируется поддерживать несколько development-версий для разных версий библиотек (что далеко не всегда оправданно, см. ниже) то lib%name%abiversion-devel.<br />
<br />
Под development-частями библиотеки понимаются не только headers, но и при наличии у библиотеки soname - симлинк с расширением .so<br />
(без soname), используемый для линковки с данной библиотекой.<br />
<br />
Исключение составляют .so файлы, которые используются не как библиотеки, а как плагины (явно загружаются в память приложением).<br />
Примером является пакет tomcat-native, у которого libtcnative-1.so не используется для линковки.<br />
О известных исключениях такого рода необходимо сообщать в Bugzilla на тест altlinux-policy-shared-lib-contains-devel-so.<br />
<br />
Статические библиотеки, собираемые в дополнение к динамическим, должны быть выделены в отдельный пакет lib%name-devel-static или lib%name%abiversion-devel-static (сооветственно стилю -devel-пакета). Если же собирается только статическая библиотека, без динамической, то пакет должен называться -devel.<br />
<br />
Таким образом, именование пакетов вида lib%name%abiversion и lib%name-devel позволит избавиться от проблем с обновлениями пакетов, когда они не пересобраны с новой библиотекой.<br />
<br />
Если же библиотеки с разным ABI сосуществовать в системе не могут по каким-то причинам (будь то файловые конфликты или что-то другое), то данное полиси неприменимо, поскольку содержание двух пакетов в репозитории не будет иметь смысла и майнтайнер при обновлении библиотеки вместо изменения названия пакета должен пересобрать все зависимые пакеты.<br />
<br />
=== Выбор правильного %abiversion в имени пакета ===<br />
<br />
Если авторы библиотеки явно используют soversion для указания моментов ломки, то в качестве %abiversion нужно использовать именно его. Если авторы библиотеки soversion не используют, или используют нестандартно (скажем, изменяя его вне зависимости от реальной смены ABI), то можно использовать любую другую удобную в данном конкретном случае схему именования (рекомендуется использовать последовательно возрастающие числа, начинающиеся с 0 и увеличивающиеся на 1 при каждой ломке).<br />
<br />
В случае, если существует несколько поддерживаемых веток одной библиотеки, %soversion может соответствовать major-версии библиотеки (libqt3, libqt4) или иметь вид major.minor (libdb4.0, libdb4.1). Можно также использовать часть soname’а библиотеки (напр., libcurl4, libflac8).<br />
<br />
=== Переезд со старого именования ===<br />
<br />
Не секрет, что сейчас в Сизифе подобным образом запакованы очень немногие библиотеки. Предположим, что библиотека libfoo обновилась и в ней сменился soname с N на M.<br />
<br />
При сборке новой версии пакета libfoo предлагается сделать следующее:<br />
#Переименовать бинарный пакет libfoo в libfooM<br />
<!--#Добавить в пакет libfooM Provides: libfoo = %version-%release--><br />
<br />
=== Политика адаптации клиентов разделяемых библиотек к новым версиям ===<br />
<br />
За исключением особых случаев (например, qt3 и qt4, которые по сути являются различными библиотеками, а не разными версиями одной), настоятельно рекомендуется поддерживать наличие ровно одного -devel пакета (соответствующего самой новой версии библиотеки) для любой библиотеки, сколько бы старых версий этой библиотеки не присутствовало в Сизифе. При выполнении этого правила новые собираемые версии клиентов библиотек будут автоматически собираться с новой версией библиотеки (см. тж. [http://lists.altlinux.org/pipermail/devel/2006-December/039664.html письмо в devel@]). В виде исключения, если новая версия библиотеки приводит к несобираемости большого количества пакетов, допустимо поддерживать две версии пакетов -devel, с проставлением тегов Conflicts в этих пакетах -devel друг на друга и соответствующим разделением зависимых пакетов на собирающиеся с новой и со старой версией библиотеки.<br />
<br />
Старые библиотеки должны быть перемещены в группу 'System/Legacy libraries' при появлении в Сизифе новой версии. Аналогично пакетам -devel, в исключительных случаях разрешается иметь более одной версии библиотеки не в Legacy.<br />
<br />
Когда библиотека из группы 'System/Legacy libraries' не требуется ни одним пакетом из Сизифа, она должна быть удалена из него. Пакеты из группы 'System/Legacy Libraries' (и, соответственно, пакеты, зависящие от них) объявляются непригодными к выпуску в [[Branches|стабильной ветке]].<br />
<br />
=== Бэкпорты ===<br />
<br />
Поскольку предлагаемое изменение именования библиотек жёстко прикрепляет soname к имени пакета, а также позволяет сосуществовать разным версиям библиотек, становится возможным бэкпортить новые версии библиотек и программы, зависящие от новых версий библиотек, что значительно ослабляет условие 5 в [[BackportsPolicy|backports policy]].<br />
<br />
=== Область применимости ===<br />
<br />
SharedLibsPolicy рассчитывает на то, что API не меняется. В случае смены API лучше делать ещё и два devel-пакета - для возможности сборки и со старой, и с новой библиотекой. При этом такие devel-пакеты вполне могут конфликтовать между собой, одновременную установку обязательно обеспечивать только для runtime-части.<br />
<br />
Для нового пакета вида libfooM-devel желательно сделать<br />
Provides: libfoo-devel = %version<br />
чтобы обеспечить возможность указания в спеке зависимость без версии (это особенно удобно, если версия часто меняется).<br />
<br />
=== Примечания ===<br />
<br />
Если оставить старое название, можно столкнуться с [http://lists.altlinux.org/pipermail/devel/2009-May/171113.html багофичей apt]: он плохо переносит переименования пакетов в случае, когда содержимое старой версии пакета переносится в пакет с новым именем, но при этом пакет со старым именем остаётся существовать; порой приходится разделять обновление на задания, чтобы сперва «физически» провести удаление (под)пакета.<br />
<br />
После проведения начального перехода на новую версию ABI обычно пробуют удалить старую версию библиотеки для получения списка собранных с ней пакетов (т.е. ''делают'' compat-сборку, чтобы не переусложнять задание с обновкой, затем пересобирают клиентов с новой -- это может быть более растянутый во времени процесс, вплоть до ожидания исправлений в соответствующих апстримах; и затем, если нет веских поводов вроде необходимости долгосрочного сохранения важной части ABI, старую версию удаляют уже не в пробном режиме).<br />
<br />
Стоит иметь в виду, что параллельные версии библиотек могут приводить к неочевидным ошибкам в случае непрямого попадания в адресное пространство одного итогового процесса (например, приложение A связано с библиотеками libX и libY, при этом libX связана с libZ1, а libY — с libZ2).<br />
<br />
== Ссылки ==<br />
* [[Shared Libs Policy Comments Комментарий к Shared Libs Policy с пошаговой инструкцией]]<br />
* [http://www.us.debian.org/doc/debian-policy/ch-sharedlibs.html http://www.us.debian.org/doc/debian-policy/ch-sharedlibs.html]<br />
* [[API or ABI changing|Смена API/ABI]]<br />
* [[Shared Libs Policy and updates|Данное полиси и обновления]]<br />
* [[Shared Library Symbol Versioning HOWTO]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog&diff=75939Руководство по написанию changelog2023-11-04T11:03:19Z<p>AntonFarygin: /* Примеры */</p>
<hr />
<div>[[Категория:Руководства]]<br />
[[category:RPM spec]]<br />
[[category:devel]]<br />
<br />
__TOC__<br />
Этот документ описывает рекомендуемые правила оформления секции <tt>%changelog</tt> spec-файла пакета и характер/объём включаемой в неё информации.<br />
<br />
== Примеры ==<br />
<br />
Тривиальный случай:<br />
<br />
<pre><br />
* Mon Feb 21 2022 Alexey Shabalin <shaba@altlinux> 2.0.112-alt1<br />
- Initial build.<br />
</pre><br />
<br />
либо<br />
<br />
<pre><br />
* Thu Feb 24 2022 Denis G. Samsonenko <ogion@altlinux> 1.0.1365-alt1<br />
- new version<br />
</pre><br />
<br />
Выпуск, включающий совместную работу:<br />
<br />
<pre><br />
* Sun Jun 08 2008 Dmitry V. Levin <ldv@altlinux> 4.1.2-alt3<br />
- Removed c++filt from alternatives (at@).<br />
- Added libgcj-src subpackage (viy@).<br />
- Moved NLS files to new locales subpackage (closes: #11510).<br />
- Do not package changelog files.<br />
</pre><br />
<br />
Ещё вариант написания changelog с совместной работой:<br />
<br />
<pre><br />
* Sun Jun 08 2008 Dmitry V. Levin <ldv@altlinux> 4.1.2-alt3<br />
- Removed c++filt from alternatives (thnx zerg@).<br />
- Added libgcj-src subpackage (thnx Igor Vlasenko).<br />
- Updated russian translation (ALT #21475), thnx Alexandre Prokoudine.<br />
</pre><br />
<br />
== Термины ==<br />
<br />
Здесь<br />
; запись<br />
: Всё, что относится к сборке 4.6.2-alt7.pre1<br />
; группа<br />
: имя в квадратных скобках<br />
; пункт<br />
: текст, начинающийся с дефиса («- make visible_tabs and visible_tws mcedit options configurable through config file (Debian)»)<br />
; подпункт<br />
: текст, начинающийся с плюса («+ recognize man pages with additional suffixes other than 'x', such as write.3p (Debian)»)<br />
; строка<br />
: одна строка файла спека («- make visible_tabs and visible_tws mcedit options configurable through config»)<br />
<br />
== Синтаксис чейнджлога ==<br />
* (Опциональная) группа состоит из имени в квадратных скобках и начинается с первой позиции строки.<br />
* Пункт верхнего уровня начинается с 1-й позиции в строке и состоит из дефиса, пробела и собственно текста.<br />
* Подпункт начинается с 3-й позиции в строке и состоит из плюса, пробела и собственно текста.<br />
* Строки переносятся по словам и содержат не более 78 символов. При этом текст новой строки выравнивается по началу текста предыдущей (то есть 3-я позиция для пунктов верхнего уровня и 5-я для подпунктов).<br />
* Начинать новую строку с символа # нельзя (такая строка будет воспринята как комментарий).<br />
* При использовании макросов следует экранировать символ "%" ещё одним "%" во избежание раскрытия оных, т.е. напрмер вместо <tt>%name</tt> следует записать <tt>%%name</tt>.<br />
<br />
Пример:<br />
- syntax:<br />
+ recognize .hh and .hpp as c++ again<br />
+ recognize man pages with additional suffixes other than 'x', such as<br />
write.3p (Debian)<br />
- make visible_tabs and visible_tws mcedit options configurable through config<br />
file (Debian)<br />
<br />
== Содержимое ==<br />
* '''Чейнджлог пишется на английском языке.'''<br />
* При сборке новой upstream-версии это указывается первым пунктом.<br />
** При сборке из снэпшота системы контроля версий необходимо указать информацию, позволяющую идентифицировать это снэпшот (дата и время для CVS, ревизия SVN, 8 первых символов идентификатора коммита для git, mtn, bzr, hg, либо вывод git-describe для git).<br />
* Если в сборке версии существенно принимало участие более одного человека, то изменения, вносимые разными людьми, собираются в группы по авторам, иначе группы не нужны.<br />
'''Информация об уязвимостях (CVE и т.д.) в Changelog обязана соответствовать [[Vulnerability_Policy]].'''<br />
* '''Изменения, произведённые апстримом (кроме исправлений ошибок безопасности), в чейнджлоге не указываются (для этого есть чейнджлоги апстрима, зачастую включаемые в пакет).'''<br />
* Косметические изменения спек-файла, не влияющие на получаемый пакет, указываются максимум одной строкой («<tt>spec cleanup</tt>»), либо не указываются вовсе. Это не относится к исправлениям тега License, изменениям параметров сборки и т. д.<br />
* Исправления, необходимые для успешной сборки, соответствия требованиям ALT Linux и т. д., не указываются, если они были сопряжены с упаковкой новой версии и для старой версии были не нужны (эти исправления — адаптация новой версии, то есть часть процесса её упаковки). Если же они были вызваны изменением требований либо окружения, желательно это указать (пример: «fix FTBFS with new autotools», [[Sisyphus/FTBFS|FTBFS]] == failure to build from source).<br />
* Если .spec-файл адаптирован из другого дистрибутива, то майнтейнер вправе как оставить старые записи %changelog, так и удалить их. Следует помнить, что<br />
** Записи в %changelog содержат информацию о том, как шла разработка пакета до импорта — в них есть адреса майнтейнеров и протокол их действий. Эта информация часто бывает полезной.<br />
** Сам адаптированный спек является модификацией исходного кода, авторские права на который принадлежат не вам. Некоторые лицензии требуют сохрания атрибуции непосредственно в тексте исходного кода. Самый простой способ сделать это — оставить прошлый %changelog в неприкосновенности<br />
** Формат унаследованного %changelog может отличаться от принятого в ALT, это иногда приводит к сбою в инструментах работы со спеками.<br />
** Если вы оставляете исходный %changelog, первую запись о сборке адаптированного пакета стоит делать видимой (традиционно она содержит слова "Initial build for ALT"). Это поможет отделить историю пакета в ALT от исходной истории разработки <br />
* Используйте спеллчекер :)<br />
<br />
== Указание источников и контекста ==<br />
* Если изменение взято извне либо основано на взятом извне, в соответствующем изменению пункте чейнджлога в скобках указывается источник. Это может быть название дистрибутива/репозитория, название внешней BTS и номер бага в ней, ID участника ALT Linux Team или произвольное указание на человека или сайт. Здесь под изменением подразумевается готовый патч, адаптированный патч или иные аналогичные указания.<br />
Примеры:<br />
- move global configs to /etc (RH)<br />
- linked libnetpbm.so against -lm (RH #165980)<br />
- use optflags (drool@)<br />
<br />
== Автозакрытие багов ==<br />
* Если изменение связано с багрепортом из [[altbug:|bugzilla.altlinux.org]], в соответствующем пункте можно указать (по вкусу; регистр не учитывается, но обязательно в скобках):<br />
** <tt>(Closes: NNNN)</tt><br />
** <tt>(ALT NNNN)</tt><br />
** <tt>(ALT bug NNNN)</tt><br />
с опциональным знаком <tt>#</tt> перед номером бага. Можно также указать несколько багов: <tt>(Closes: NNNN, MMMM, ZZZZ)</tt>. Синтаксис такого рода закрывает указанный баг после прохождения пакета в репозиторий при условии присутствия соответствующей записи в выводе {{cmd|rpmquery --lastchange}}.<br />
* Номера багов в скобках разделяются запятыми.<br />
Примеры:<br />
- add option to build with libslang2 (closes: 10591)<br />
- recognize .3gp as video, not manpage (ALT #14982, #14999)<br />
<br />
Обратите внимание, что других слов в скобках при этом нельзя указывать.<br />
<br />
'''Полный regexp для поиска номеров багов в changelog можно посмотреть [http://git.altlinux.org/people/ldv/packages/?p=girar.git;a=blob;f=gb/gb-x-parse-bugs-from-changelog;hb=HEAD здесь].'''<br />
<br />
== Указание устраненных уязвимостей ==<br />
{{main|Vulnerability Policy}}<br />
<br />
== Лучшие практики оформления changelog ==<br />
<br />
* Если changelog пакета оформлен единообразно, не нарушайте это единообразие (если оно не противоречит этому руководству). Если же changelog хаотичен, то оставленный перед changelog комментарий о рекомендуемом стиле ведения changelog поможет избежать продолжения хаоса в будущем.<br />
* Старайтесь, чтобы все предложения в changelog были в одной форме («fix memory leaks», «fixed memory leaks», «memory leaks fixed»), в таком виде их гораздо удобнее читать.<br />
* Единообразно оформляйте предложения changelog’а: либо начинайте, либо не начинайте их все с большой буквы; либо заканчивайте, либо не заканчивайте их точкой.<br />
* Группировка сходных пунктов в подпункты позволяет уменьшить размер changelog’а и улучшить его читаемость.<br />
<br />
== Разное ==<br />
<br />
* Для форматирования changelog существует команднострочная утилита [[add_changelog]], а также макросы для [[редактирование changelog в Vim|Vim]] и [[редактирование changelog в Emacs|Emacs]].<br />
* [[Changelogs guide/example|Пример хорошего changelog’а]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog&diff=75938Руководство по написанию changelog2023-11-04T10:54:47Z<p>AntonFarygin: /* Примеры */ тяжеловесный вариант за много лет ни разу не использовался и вводит в заблуждение</p>
<hr />
<div>[[Категория:Руководства]]<br />
[[category:RPM spec]]<br />
[[category:devel]]<br />
<br />
__TOC__<br />
Этот документ описывает рекомендуемые правила оформления секции <tt>%changelog</tt> spec-файла пакета и характер/объём включаемой в неё информации.<br />
<br />
== Примеры ==<br />
<br />
Тривиальный случай:<br />
<br />
<pre><br />
* Mon Feb 21 2022 Alexey Shabalin <shaba@altlinux> 2.0.112-alt1<br />
- Initial build.<br />
</pre><br />
<br />
либо<br />
<br />
<pre><br />
* Thu Feb 24 2022 Denis G. Samsonenko <ogion@altlinux> 1.0.1365-alt1<br />
- new version<br />
</pre><br />
<br />
Выпуск, включающий совместную работу:<br />
<br />
<pre><br />
* Sun Jun 08 2008 Dmitry V. Levin <ldv@altlinux> 4.1.2-alt3<br />
- Removed c++filt from alternatives (at@).<br />
- Added libgcj-src subpackage (viy@).<br />
- Moved NLS files to new locales subpackage (closes: #11510).<br />
- Do not package changelog files.<br />
</pre><br />
<br />
== Термины ==<br />
<br />
Здесь<br />
; запись<br />
: Всё, что относится к сборке 4.6.2-alt7.pre1<br />
; группа<br />
: имя в квадратных скобках<br />
; пункт<br />
: текст, начинающийся с дефиса («- make visible_tabs and visible_tws mcedit options configurable through config file (Debian)»)<br />
; подпункт<br />
: текст, начинающийся с плюса («+ recognize man pages with additional suffixes other than 'x', such as write.3p (Debian)»)<br />
; строка<br />
: одна строка файла спека («- make visible_tabs and visible_tws mcedit options configurable through config»)<br />
<br />
== Синтаксис чейнджлога ==<br />
* (Опциональная) группа состоит из имени в квадратных скобках и начинается с первой позиции строки.<br />
* Пункт верхнего уровня начинается с 1-й позиции в строке и состоит из дефиса, пробела и собственно текста.<br />
* Подпункт начинается с 3-й позиции в строке и состоит из плюса, пробела и собственно текста.<br />
* Строки переносятся по словам и содержат не более 78 символов. При этом текст новой строки выравнивается по началу текста предыдущей (то есть 3-я позиция для пунктов верхнего уровня и 5-я для подпунктов).<br />
* Начинать новую строку с символа # нельзя (такая строка будет воспринята как комментарий).<br />
* При использовании макросов следует экранировать символ "%" ещё одним "%" во избежание раскрытия оных, т.е. напрмер вместо <tt>%name</tt> следует записать <tt>%%name</tt>.<br />
<br />
Пример:<br />
- syntax:<br />
+ recognize .hh and .hpp as c++ again<br />
+ recognize man pages with additional suffixes other than 'x', such as<br />
write.3p (Debian)<br />
- make visible_tabs and visible_tws mcedit options configurable through config<br />
file (Debian)<br />
<br />
== Содержимое ==<br />
* '''Чейнджлог пишется на английском языке.'''<br />
* При сборке новой upstream-версии это указывается первым пунктом.<br />
** При сборке из снэпшота системы контроля версий необходимо указать информацию, позволяющую идентифицировать это снэпшот (дата и время для CVS, ревизия SVN, 8 первых символов идентификатора коммита для git, mtn, bzr, hg, либо вывод git-describe для git).<br />
* Если в сборке версии существенно принимало участие более одного человека, то изменения, вносимые разными людьми, собираются в группы по авторам, иначе группы не нужны.<br />
'''Информация об уязвимостях (CVE и т.д.) в Changelog обязана соответствовать [[Vulnerability_Policy]].'''<br />
* '''Изменения, произведённые апстримом (кроме исправлений ошибок безопасности), в чейнджлоге не указываются (для этого есть чейнджлоги апстрима, зачастую включаемые в пакет).'''<br />
* Косметические изменения спек-файла, не влияющие на получаемый пакет, указываются максимум одной строкой («<tt>spec cleanup</tt>»), либо не указываются вовсе. Это не относится к исправлениям тега License, изменениям параметров сборки и т. д.<br />
* Исправления, необходимые для успешной сборки, соответствия требованиям ALT Linux и т. д., не указываются, если они были сопряжены с упаковкой новой версии и для старой версии были не нужны (эти исправления — адаптация новой версии, то есть часть процесса её упаковки). Если же они были вызваны изменением требований либо окружения, желательно это указать (пример: «fix FTBFS with new autotools», [[Sisyphus/FTBFS|FTBFS]] == failure to build from source).<br />
* Если .spec-файл адаптирован из другого дистрибутива, то майнтейнер вправе как оставить старые записи %changelog, так и удалить их. Следует помнить, что<br />
** Записи в %changelog содержат информацию о том, как шла разработка пакета до импорта — в них есть адреса майнтейнеров и протокол их действий. Эта информация часто бывает полезной.<br />
** Сам адаптированный спек является модификацией исходного кода, авторские права на который принадлежат не вам. Некоторые лицензии требуют сохрания атрибуции непосредственно в тексте исходного кода. Самый простой способ сделать это — оставить прошлый %changelog в неприкосновенности<br />
** Формат унаследованного %changelog может отличаться от принятого в ALT, это иногда приводит к сбою в инструментах работы со спеками.<br />
** Если вы оставляете исходный %changelog, первую запись о сборке адаптированного пакета стоит делать видимой (традиционно она содержит слова "Initial build for ALT"). Это поможет отделить историю пакета в ALT от исходной истории разработки <br />
* Используйте спеллчекер :)<br />
<br />
== Указание источников и контекста ==<br />
* Если изменение взято извне либо основано на взятом извне, в соответствующем изменению пункте чейнджлога в скобках указывается источник. Это может быть название дистрибутива/репозитория, название внешней BTS и номер бага в ней, ID участника ALT Linux Team или произвольное указание на человека или сайт. Здесь под изменением подразумевается готовый патч, адаптированный патч или иные аналогичные указания.<br />
Примеры:<br />
- move global configs to /etc (RH)<br />
- linked libnetpbm.so against -lm (RH #165980)<br />
- use optflags (drool@)<br />
<br />
== Автозакрытие багов ==<br />
* Если изменение связано с багрепортом из [[altbug:|bugzilla.altlinux.org]], в соответствующем пункте можно указать (по вкусу; регистр не учитывается, но обязательно в скобках):<br />
** <tt>(Closes: NNNN)</tt><br />
** <tt>(ALT NNNN)</tt><br />
** <tt>(ALT bug NNNN)</tt><br />
с опциональным знаком <tt>#</tt> перед номером бага. Можно также указать несколько багов: <tt>(Closes: NNNN, MMMM, ZZZZ)</tt>. Синтаксис такого рода закрывает указанный баг после прохождения пакета в репозиторий при условии присутствия соответствующей записи в выводе {{cmd|rpmquery --lastchange}}.<br />
* Номера багов в скобках разделяются запятыми.<br />
Примеры:<br />
- add option to build with libslang2 (closes: 10591)<br />
- recognize .3gp as video, not manpage (ALT #14982, #14999)<br />
<br />
Обратите внимание, что других слов в скобках при этом нельзя указывать.<br />
<br />
'''Полный regexp для поиска номеров багов в changelog можно посмотреть [http://git.altlinux.org/people/ldv/packages/?p=girar.git;a=blob;f=gb/gb-x-parse-bugs-from-changelog;hb=HEAD здесь].'''<br />
<br />
== Указание устраненных уязвимостей ==<br />
{{main|Vulnerability Policy}}<br />
<br />
== Лучшие практики оформления changelog ==<br />
<br />
* Если changelog пакета оформлен единообразно, не нарушайте это единообразие (если оно не противоречит этому руководству). Если же changelog хаотичен, то оставленный перед changelog комментарий о рекомендуемом стиле ведения changelog поможет избежать продолжения хаоса в будущем.<br />
* Старайтесь, чтобы все предложения в changelog были в одной форме («fix memory leaks», «fixed memory leaks», «memory leaks fixed»), в таком виде их гораздо удобнее читать.<br />
* Единообразно оформляйте предложения changelog’а: либо начинайте, либо не начинайте их все с большой буквы; либо заканчивайте, либо не заканчивайте их точкой.<br />
* Группировка сходных пунктов в подпункты позволяет уменьшить размер changelog’а и улучшить его читаемость.<br />
<br />
== Разное ==<br />
<br />
* Для форматирования changelog существует команднострочная утилита [[add_changelog]], а также макросы для [[редактирование changelog в Vim|Vim]] и [[редактирование changelog в Emacs|Emacs]].<br />
* [[Changelogs guide/example|Пример хорошего changelog’а]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%9A%D0%BE%D0%BC%D0%BF%D0%B0%D0%BD%D0%B8%D1%8F_%C2%AB%D0%90%D0%BB%D1%8C%D1%82_%D0%9B%D0%B8%D0%BD%D1%83%D0%BA%D1%81%C2%BB&diff=75233Компания «Альт Линукс»2023-10-17T08:24:46Z<p>AntonFarygin: </p>
<hr />
<div>[[Image:Logo_alt_company_small.png|thumb|right|Логотип компании «Альт Линукс»]]<br />
'''ООО «Альт Линукс»''' (основана в 2001 году) — закрытая российская коммерческая организация, занимающаяся до 2015 года, в числе прочего, разработкой, продажей и поддержкой решений и [[Releases|дистрибутивов ALT Linux]] на базе [[Sisyphus]] и [[Branches|стабильных веток репозитория]].<br />
<br />
Компания также занималась:<br />
* разработкой Sisyphus <br />
* поддержкой инфраструктуры Sisyphus<br />
<br />
Более подробно о направлениях деятельности компании вы можете ознакомится в [http://web.archive.org/web/20090426064146/http://www.altlinux.ru/go/about-company/sphere-of-activity/ соответствующем разделе сайта компании].<br />
<br />
== Ссылки ==<br />
[http://web.archive.org/web/20090426064146/http://www.altlinux.ru/ Компания «Альт Линукс»]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=Team/Famous&diff=75231Team/Famous2023-10-17T07:55:15Z<p>AntonFarygin: /* Anton Farygin */ - убрана информация об Anton Farygin</p>
<hr />
<div>== Известные люди ALT Linux Team ==<br />
<br />
Список далеко не полон; сортировка аполитична. Если считаете, что кого-то забыли — допишите.<br />
<br />
=== Aleksey Novodvorsky ===<br />
[http://users.livejournal.com/aen_/profile Алексей Новодворский] — {{man|aen}}<br />
<br />
Сооснователь ООО «Альт Линукс», директор по развитию, некогда школьный учитель математики.<br />
<br />
Добр и чувствителен, порой до обидчивости. Человек большой души, но даже искреннюю критику в свой адрес (особенно в адрес сизифа) порой принимает с очень большим трудом. Впрочем, неискренней тоже хватает.<br />
<br />
В первые годы существования Sisyphus собственноручно поддерживал около трети пакетов в нём, помимо другой деятельности.<br />
<br />
=== Dmitry Levin ===<br />
Дмитрий Левин — {{man|ldv}}<br />
<br />
Генеральный архитектор Sisyphus, главный конструктор ООО «Альт Линукс», математик и вообще хороший человек (если не умудриться вывести из себя).<br />
<br />
Поддерживает базовую систему сизифа, отвечает за инфраструктуру. Замечен как в помощи по написанию [http://tinyurl.com/22fwog безопасного кода] и анализу/исправлению потенциально небезопасного (C, shell…), так и в [http://freeschool.altlinux.ru/wp-content/uploads/2009/01/ldv01.jpg собирании грибов] на LinuxFest :)<br />
<br />
=== Vitaly Lipatov ===<br />
Виталий Липатов — {{man|lav}}<br />
<br />
Генеральный директор [http://etersoft.ru/ ООО Этерсофт], собирает примерно [http://sisyphus.ru/packager/lav/srpms десятую часть] сизифа, для облегчения чего создал [[Etersoft-build-utils howto|etersoft-build-utils]].<br />
<br />
Перед участием в некоторых особо напряжённых темах в smoke-room@ порой помогает почитать его ответы в предыдущих витках.<br />
<br />
=== Sergey Vlasov ===<br />
Сергей Власов — {{man|vsu}}<br />
<br />
Легендарный муромский богатырь. Долгое время сопровождал ядра высочайшего качества в ALT, создал или неисправимо улучшил многие инфраструктурные инструменты.<br />
<br />
Поднимался вопрос об издании трёхтомника трудов — коммитов, changelog’ов и писем в рассылки.<br />
<br />
=== Sergey Turchin ===<br />
Сергей Турчин — {{man|zerg}}<br />
<br />
«Мистер KDE», каковое поддерживает практически в две руки. Если «из коробки» заработала 3D-акселерация на старенькой nvidia — вспоминать добрым словом его же.<br />
<br />
Вполне отзывчив, хотя иногда долго добирается ответить.<br />
<br />
=== Stanislav Ievlev ===<br />
Станислав Иевлев — {{man|inger}}<br />
<br />
Тихий, незаметный и неконфликтный человек, проделавший огромное количество работы по самым разным частям инфраструктуры и дистрибутивов, включая кластерный и RSBAC-дистрибутив, installer, alterator…<br />
<br />
Один из двух людей, наиболее основательно занимавшихся безопасностью пакетной базы и дистрибутивов ALT Linux от самого их начала.<br />
<br />
=== Alexey Gladkov ===<br />
Алексей Гладков — {{man|legion}}<br />
<br />
Участник проекта Mozilla, результаты деятельности которого порой доносит и до сизифа. Источник заметной части оригинальных наработок последних лет, включая [[libshell]], [[mkimage]] и [[make-initrd]]. Много сделал для [[alterator]] и инфраструктуры.<br />
<br />
Крайне тщателен и педантичен; его скрипты бывает полезно почитать для самообразования.<br />
<br />
=== Alexey Tourbin ===<br />
<span style="border-style: solid; border-width: 1px;">Алексей Турбин</span> — {{man|at}}<br />
<br />
Правая рука ldv@ по работам над инфраструктурой. Поддерживает [[perl]] и толерантность в devel@, хотя на самом деле человек не только грамотный, но и интересный.<br />
<br />
Если исчезает — подождите.<br />
<br />
К великому сожалению уже не дождемся его никогда. Светлая память.<br />
<br />
=== Damir Shayhutdinov ===<br />
[http://los-t.livejournal.com/profile Дамир Шайхутдинов] — {{man|damir}}<br />
<br />
Яркий представитель «новой волны» (после 2005): юморист и профессиональный разработчик на C/C++, который нередко помогал с пониманием и решением проблем как непосредственно с кодом, так и с его [[UpStream/AsNeeded|линковкой]] и упаковкой (особенно на x86_64).<br />
<br />
=== Andrey Rahmatullin ===<br />
[http://wrar.livejournal.com/profile Андрей Рахматуллин] — {{man|wrar}}<br />
<br />
Ещё один яркий представитель «новой волны», и тоже много кому помог с исправлением проблем в коде.<br />
<br />
Иногда его краткие ответы на точно процитированный вопрос напоминали советскую документацию — написана правда, но вот понять это получается только при понимании как всего вопроса, так и всего ответа.<br />
<br />
=== Valery Inozemtsev ===<br />
Валерий Иноземцев — {{man|shrek}}<br />
<br />
На удивление сообразно логину отличается в поведении на (электронной) публике и при личном общении: в переписке бывает невыносим, а вообще же он добрый и умеет улыбаться.<br />
<br />
Отличается быстрой реакцией на баги, нередко оказывающейся WONTFIX, но порой и FIXED нетривиальных проблем. Поддерживает угрожающе много пакетов в сизифе.<br />
<br />
=== Michael Shigorin ===<br />
[http://sdelanounas.ru/blog/shigorin Михаил Шигорин] — {{man|mike}}<br />
<br />
Традиционно больше говорит, чем делает. Пытается влезть в каждую дырку и особенно в каждый конфликт, чем нередко приводит к их раздуванию вместо искомого затухания. Знает лично добрых полкоманды, при необходимости подрабатывает телефонисткой.<br />
<br />
«Админ» с претензией на «манагера»; как разработчик довольно слаб. Порой *долго* отвечает.<br />
<br />
=== Motsyo Gennadi ===<br />
Моцьо Геннадий — {{man|drool}}<br />
<br />
Не соответствует своему логину. Знает много, даже то, о чем не догадывается. Всегда рад помочь, но и не забывает иногда послать в рассылку или на форум. Иногда раздувает много политической шумихи внутри community.<br />
<br />
=== Andrey Cherepanov ===<br />
[http://sibskull.livejournal.com/ Андрей Черепанов] — {{man|cas}}<br />
<br />
Также известен как Skull или Sibskull. Умудряется схватиться за всё и сделать достаточно многое (например, выпуски на [[Branches/p5|p5]]). Модератор [http://forum.altlinux.org/ forum.altlinux.org], был когда-то крайний по [[QA]].<br />
<br />
Терпит много незаслуженных тумаков за других.<br />
<br />
=== Denis Smirnov ===<br />
[http://mithraen.livejournal.com/ Денис Смирнов] — {{man|mithraen}}<br />
<br />
Бывший слакварист и фидошник, затем Mr. Asterisk сизифа. Порой жутко флеймил и даже бросался в крайности, потом хватался за напильник и искупал это.<br />
<br />
=== George Kouryachy ===<br />
[http://frbrgeorge.livejournal.com/ Георгий Курячий] — {{man|george}}<br />
<br />
Бывший BSD-шник, продолжает активно заниматься [http://uneex.ru/LecturesCMC/ образовательной деятельностью] (это [https://www.youtube.com/playlist?list=PL387B38E91536055B надо видеть], жестикуляция непередаваемая).<br />
<br />
Обычно вдруг появляется, вбухивает пачку пакетов в сизиф и ещё одну — писем в рассылки, убегает до следующего подходящего момента. Пакеты в основном образовательные, игрушечные или редкостные.<br />
<br />
=== Kirill Shutemov ===<br />
[http://www.facebook.com/people/Kirill-Shutemov/100000522921177 Кирилл Шутемов] — {{man|kas}}<br />
<br />
Больше делает, чем говорит. Начал с qemu; выручал ldv@ по части gcc и openssl; вместе с legion@ пилил [[make-initrd]]; занимался [[Ports/arm|ARM-портом]].<br />
<br />
На удивление неконфликтный и толковый специалист.<br />
<br />
=== Igor Vlasenko ===<br />
Игорь Власенко — {{man|viy}}<br />
<br />
Более всего известен как автор [[repocop]] и участник [[QA]] Team; также виновен в успешной попытке упаковки [[Java]]-стека в сизиф (путём создания механизма импорта jpackage.org).<br />
<br />
У многих вызывает сильные эмоции — или симпатию, или осуждение.<br />
<br />
=== Eugeny Rostovtsev ===<br />
<span style="border-style: solid; border-width: 1px;">Евгений Ростовцев</span> — {{man|real}}<br />
<br />
Тихо и незаметно тянул огромное количество пакетов в сизифе, существенно пополнив python-подсистему и упаковав немало [[Orphaned#REAL_aka_Eugeny_A._Rostovtsev|научного софта]] (кто с таким сталкивался, тот понимает, насколько это бывает сложно). Покинул нас [http://web.archive.org/web/20151002102035/http://cnit.kemsu.ru/articles/15 осенью 2015] года.<br />
<br />
=== Gleb Fotengauer-Malinovskiy ===<br />
Глеб Фотенгауэр-Малиновский — {{man|glebfm}}<br />
<br />
Начав в компании с тестировщика, стремительно вырос в одного из наиболее ценных специалистов в команде; по сути зам. ldv@ (а в [[Team/Join|принимающих]] так просто по факту). Пожалуй что рекордсмен по количеству [[ports|портов]] альта, к которым приложил руку.<br />
<br />
=== Ivan Melnikov ===<br />
Иван Мельников — {{man|iv}}<br />
<br />
Давний участник команды, порой выручающий по нетривиальным вопросам; забрал у Глеба [[ports/mipsel|mipsel]] и продолжил успешно развивать в качестве вторичной архитектуры.<br />
<br />
=== Yuri Sedunov ===<br />
Юрий Седунов — {{man|aris}}<br />
<br />
Ещё один давний участник, много лет единолично сопровождающий пакеты GNOME и сопредельные, помимо всего прочего. При ''вежливом'' обращении способен помочь в сложных моментах, а вот "эй, ты" склонен игнорировать.<br />
<br />
=== Aleksei Nikiforov ===<br />
Алексей Никифоров — {{man|darktemplar}}<br />
<br />
Яркий представитель молодого обнинского поколения, достаточно грамотный, чтобы умудриться ненароком сломать {{pkg|apt}} двумя выстрелами в собственную ногу из-за спины (виноват оказался апстрим, но всё равно впечатлило). Толковый, но при отсутствии внятного объяснения проблемы может отказываться её видеть; что, впрочем, шире известно как "bug# or didn't happen".<br />
<br />
{{Category navigation|title=Team|category=Team|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%93%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0&diff=75230Главная страница2023-10-17T07:53:28Z<p>AntonFarygin: временно выключил компанию ALT Linux с главной страницы в связи с её реорганизацией.</p>
<hr />
<div>__NOTOC__<br />
<br />
[[Изображение:Gnome-media-optical.svg]] '''[[Пользователю]]''' &nbsp;<br />
[[Изображение:Gnome-preferences-system.svg]] '''[[Sysadmin|Системному администратору]]''' &nbsp;<br />
[[Изображение:Gnome-applications-development.svg]] '''[[Sisyphus|Разработчику]]''' &nbsp;<br />
[[Изображение:Migration.png]] '''[[Миграция]]''' &nbsp;<br />
[[Изображение:Education.png]] '''[[ALT Education|Образование]]''' &nbsp;<br />
<br />
----<br />
{| style="float: right;"<br />
|-<br />
|<br />
<br />
{| style="text-align:center; padding:.8em;"<br />
|-<br />
|<br />
<br />
<span class="plainlinks" style="background-color: #ffc905; padding: 12px 16px; font-weight: bold;border-radius: 5px;">[https://getalt.org ЗАГРУЗИТЬ&nbsp;«АЛЬТ»]</span><br />
<br />
|}<br />
<br />
{| style="border:1px solid #AAA; background:#F9F9FF; width:250px; margin: 0 0 1em 1em; padding:.2em; text-align:left; " class=noprint<br />
|-<br />
|[[Изображение:ru.png|right]]<br />
* '''[[:en:Main Page|English]]'''<br />
<!-- * '''[[:uk:Main Page|Українська]]''' заброшена после 2009 года --><br />
----<br />
* [[Статистика wiki]]<br />
<!-- * [http://altlinux.com.br/wiki/ Português] --><br />
|}<br />
<br />
{| style="border:1px solid #AAA; background:#F9F9FF; width:250px; margin: 0 0 1em 1em; padding:.2em; text-align:left; " class=noprint<br />
|-<br />
|<br />
'''Выпуски'''<br />
* [[Образование]]<br />
* [[Workstation]]<br />
* [[Workstation K]]<br />
* [[Simply Linux]]<br />
* [[Starterkits]]<br />
* [[Rescue]]<br />
* [[Releases|все]] | [[Releases/Download|скачать]]<br />
'''Популярные страницы'''<br />
* [[Install|Установка и обновление программ]]<br />
* [[Write|Запись на DVD и USB Flash]]<br />
* [[Su|Как получить права суперпользователя]]<br />
* [[Эльбрус]]<br />
'''[[Вопросы по вики]]'''<br />
|}<br />
<!--<br />
{| style="border:4px solid #0F9528;background:#E3FFC7;width:200px; margin: 0 0 1em 1em; padding:.2em; text-align:left;border-radius: 9px;float:right;" class=noprint<br />
|-<br />
|<br />
<center>[[Image:Bug-slanted.png]]<br />
'''17 сентября 2011 года, суббота'''<br />
----<br />
[[BugDay|Cубботник по исправлению ошибок]]</center><br />
|}<br />
--><br />
|}<br />
<br />
[[Изображение:Gnome-stock_person.svg]] '''Об ALT Linux'''<br />
* [[ALT Linux Team]] (команда ALT Linux)<br />
* [[Alt_Linux_Active_Users_Club | Страница "Клуба активных пользователей ALT Linux"]]<br />
* [[QuickStart/Выбор_дистрибутива | Как выбрать дистрибутив по вашему вкусу]]<br />
* [[Registry|Реестр докер-образов]]<br />
* [[Tips | Советы и рекомендации от "Клуба активных пользователей ALT Linux"]]<br />
* [[FAQ|Часто задаваемые вопросы и ответы на них]] (FAQ)<br />
* [[Факты]]<br />
* [[Sisyphus|Сизиф]] ([[Что такое Sisyphus?]]) — см. тж. [[Changes|метеосводку]]<br />
* [https://docs.altlinux.org Документация ALT Linux Team/Базальт СПО]<br />
* [https://packages.altlinux.org/ru/sisyphus/ База данных пакетов и обновлений]<br />
* [[Компания «Базальт СПО»]]<br />
* [https://www.basealt.ru/products/ Покупка дистрибутивов]<br />
* [[Обновление ОС]] (тоже FAQ :)<br />
* [[Features|Особенности операционной системы ALT Linux]]<br />
* [[BugTracking|Сообщить об ошибке]]<br />
<br />
[[Изображение:Internet-group-chat.svg]] '''Общение'''<br />
* [[MailingLists|Списки рассылки]]<br />
* [http://forum.altlinux.org/ Форум]<br />
* [https://telegram.me/alt_linux Telegram]<br />
* Matrix (Element, Nheko): [https://matrix.to/#/#altlinux-ru:matrix.org #altlinux-ru:matrix.org]<br />
<!--* [http://planet.altlinux.org/ Планета] (блоги)--><br />
* [https://vk.com/altlinux ВКонтакте] (+[https://vk.com/simplylinux Simply]), [https://www.facebook.com/groups/136328550579/ Facebook]<br />
* [[IRC|IRC]]<br />
* [[Contacts|Контакты]]<br />
<br />
[[Image:Applications-graphics.svg]] '''Медиа'''<br />
* [[Логотипы]]<br />
* [[Журнал ALT-review]]<br />
* [[Видео]]<br />
<br />
[[Изображение:Compat.png]] '''Совместимость'''<br />
* [[HCL|Совместимое оборудование]]<br />
* [[:Категория:Enterprise Software|Совместимость стороннего программного обеспечения]]<br />
<br />
<br />
[[Категория:ALT Linux|*]]<br />
<br />
[[en:Main Page]]<br />
[[uk:Main Page]]<br />
<!-- [[pt:Página_principal]]--></div>AntonFaryginhttps://www.altlinux.org/index.php?title=ALT_Packaging_HOWTO&diff=71515ALT Packaging HOWTO2023-07-25T18:21:57Z<p>AntonFarygin: /* Разделяемые библиотеки */</p>
<hr />
<div>[[Категория:Devel]]<br />
[[Категория:RPM spec]]<br />
<br />
== ALT Packaging HOWTO (revision 0.3) ==<br />
<br />
Dmitry V. Levin <ldv@altlinux.ru><br />
ALT Linux Team<br />
<br />
=== Введение ===<br />
<br />
При разработке изменений и дополнений к rpm решались следующие задачи:<br />
*Обеспечить желаемую функциональность:<br />
наши пакеты должны отвечать определенным правилам, о которых пойдет речь несколько позже. Для этого надо, чтобы ''spec''-файлы обеспечивали выполнение этих правил. <br />
*Помочь разработчику:<br />
так как ''spec''-файлы все еще пишут люди, то их работу нужно свести к тому минимуму, который, собственно, и требует участия человека. Разработчик не должен копировать блоки кода из файла в файл, ибо эта неинтеллектуальная работа отнимает массу сил и чревата ошибками. Для этого есть макросы. Если какой-то код появляется в разных ''spec''-файлах более одного раза, то надо написать макрос(ы). <br />
*Сделать ''spec''-файлы более читабельными:<br />
те, кто эти файлы читает - тоже живые люди. Им будет удобнее, если в наименовании, расположении и использовании различных элементов ''spec''-файлов будет определенный порядок. <br />
<br />
=== Особенности этой версии rpm ===<br />
<br />
==== Новые макросы ====<br />
<br />
'''Макросы для часто используемых каталогов'''<br />
<br />
*<s>X11R6: {{rpmmacro|_x11dir}}, {{rpmmacro|_x11bindir}}, {{rpmmacro|_x11libdir}}, {{rpmmacro|_x11includedir}}, {{rpmmacro|_x11mandir}}, {{rpmmacro|_x11datadir}}</s><br>''NB: устарели с X11R7, используем {{rpmmacro|_bindir}} и прочие без x11''<br />
<br />
*лицензии: {{rpmmacro|_licensedir}} <br />
<br />
*меню: <s>{{rpmmacro|_menudir}}</s>, {{rpmmacro|_iconsdir}}, {{rpmmacro|_miconsdir}}, {{rpmmacro|_liconsdir}}<br />
<br />
*emacs: {{rpmmacro|_emacslispdir}}<br />
<br />
*другие системные: {{rpmmacro|_initddir}} ({{rpmmacro|_initir}} и {{rpmmacro|_initrddir}} [https://bugzilla.altlinux.org/show_bug.cgi?id=24290 объявлены устаревшими]), {{rpmmacro|_lockdir}}, {{rpmmacro|_logdir}}. <br />
<br />
'''Управление опциями компилятора gcc'''<br />
<br />
{{rpmmacro|add_optflags}} <options>: добавить указанные параметры в стандартный набор {{rpmmacro|_%opflags}}<br />
<br />
{{rpmmacro|remove_optflags}} <options>: убрать указанные параметры из стандартного набора {{rpmmacro|_%opflags}}<br />
<br />
{{rpmmacro|optflags_core}}: базовые параметры<br />
<br />
{{rpmmacro|__optlevel}}: уровень оптимизации<br />
<br />
{{rpmmacro|optflags_optimization}}: параметры, отвечающие за оптимизацию, кроме архитектурно-зависимых<br />
<br />
{{rpmmacro|optflags_warnings}}: ''warning options''<br />
<br />
{{rpmmacro|optflags_debug}}: ''debugging options''<br />
<br />
{{rpmmacro|optflags_shared}}: параметры, применяемые для создания relocatable файлов<br />
<br />
{{rpmmacro|optflags_nocpp}}: параметры, отключающие поддержку C++ exceptions и C++ RTTI<br />
<br />
{{rpmmacro|optflags_notraceback}}: ''-fomit-frame-pointer''<br />
<br />
{{rpmmacro|optflags_fastmath}}: ''-ffast-math''<br />
<br />
{{rpmmacro|optflags_strict}}: ''-fstrict-aliasing''<br />
<br />
{{rpmmacro|optflags_kernel}}: параметры, используемые при компиляции ядра и его модулей.<br />
<br />
По умолчанию, стандартный набор {{rpmmacro|optflags}} состоит из "{{rpmmacro|optflags_core}} {{rpmmacro|optflags_warnings}} {{rpmmacro|optflags_optimization}}".<br />
<br />
'''Макросы-надстройки над утилитой make'''<br />
<br />
{{rpmmacro|make_build}}: вызов make с параметром, обеспечивающим оптимальную параллельную сборку в данной среде<br />
<br />
{{rpmmacro|make_install}}: вызов make c инициализацией переменной INSTALL, что в случае корректной реализации Makefile'ов пакета позволяет сохранить дату последней модификации файлов, что особенно важно для документации;<br />
<br />
{{rpmmacro|makeinstall}}: make <инициализация других переменных, используемых многими Makefile'ами> install. Переопределяет все пути, куда устанавливаются файлы, добавляя к ним buildroot (используется для неправильных установочных скриптов, в которых забыто DESTDIR);<br />
<br />
{{rpmmacro|makeinstall_std}}: выполняет %make_install install DESTDIR=%buildroot, нужное для установки программы, собранной через autotools;<br />
<br />
<s>'''Регистрация документации в формате info''</s><br />
<br />
<s>{{rpmmacro|install_info}}: регистрация новых/обновленных ''info''-страниц.</s><br />
<br />
<s>{{rpmmacro|uninstall_info}}: отмена регистрации удаленных ''info''-страниц.</s><br />
<br />
''Устарело с появлением filetriggers''<br />
<br />
<s>'''Регистрация меню'''</s><br />
<br />
<s>{{rpmmacro|update_menus}}: регистрация новых/обновленных меню.</s><br />
<br />
<s>{{rpmmacro|clean_menus}}: отмена регистрации удаленных меню.</s><br />
<br />
''Устарело с появлением filetriggers''<br />
<br />
'''Вспомогательные макросы %configure'''<br />
<br />
{{rpmmacro|__libtoolize}}: путь к скрипту ''libtoolize''<br />
<br />
{{rpmmacro|_configure_script}}: путь к скрипту ''configure''<br />
<br />
{{rpmmacro|_configure_target}}: целевая платформа для ''configure''<br />
<br />
{{rpmmacro|_configure_gettext}}: ''-without-included-gettext''. <br />
<br />
'''Серверные макросы'''<br />
<br />
{{rpmmacro|post_service}}: регистрация нового сервиса при установке, перезапуск при обновлении<ref>НИКОГДА не используйте {{rpmmacro|post_service}} для<br />
перезапуска сторонних сервисов. ([http://lists.altlinux.org/pipermail/devel/2010-September/184624.html raorn@])<pre>/sbin/service %apache2_dname condreload|condrestart ||:</pre></ref><ref>%post_service предназначен для<br />
* регистрации сервиса при первой установке пакета;<br />
* перезапуске сервиса при обновлении пакета.<br />
Запускать сервис автоматически сразу при первой установке пакета не положено. ([http://lists.altlinux.org/pipermail/devel/2010-September/184646.html ldv@])</ref><br />
<br />
{{rpmmacro|preun_service}}: отмена регистрации сервиса и его выключение при удалении. <br />
<br />
'''Макросы, определяющие некоторые аспекты packaging policy'''<br />
<br />
{{rpmmacro|buildroot}}: значение ''BuildRoot''<br />
<br />
{{rpmmacro|_defattr}}: атрибуты файлов и каталогов по умолчанию для каждой секции ''%files'' и для каждого файла, включаемого в этих секциях<br />
<br />
{{rpmmacro|_compress_method}}: метод, используемый при сжатии документации в секции ''%install''<br />
<br />
{{rpmmacro|_strip_method}}: метод, используемый при обработке ELF-файлов в секции ''%install'' (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|findreq_default_method}}: метод, используемый по умолчанию при поиске требуемых зависимостей <br />
<br />
{{rpmmacro|findprov_default_method}}: метод, используемый по умолчанию при поиске предоставляемых зависимостей<br />
<br />
{{rpmmacro|set_strip_method}}: изменить значение макроса ''%_strip_method'' (макрос удален с версии rpm-4.0.4-alt100.36, вместо него с параметром ''none'' пользуйтесь {{rpmmacro|brp_strip_none}})<br />
<br />
'''Вызов вспомогательных программ'''<br />
<br />
{{rpmmacro|find_lang}}: вызов ''/usr/lib/rpm/find-lang''<br />
<br />
{{rpmmacro|strip_executable}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF executables (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|strip_relocatable}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF relocatables (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|strip_shared}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF shared objects (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|strip_static}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF ar archives (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|cleanup_build}}: вызов ''/usr/lib/rpm/brp-cleanup''<br />
<br />
{{rpmmacro|compress_docs}}: вызов ''/usr/lib/rpm/brp-compress'' <br />
<br />
{{rpmmacro|strip_binaries}}: вызов ''/usr/lib/rpm/brp-strip'' (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|clean_buildroot}}: выполнение ''rm -rf %buildroot'', если ''%buildroot'' не указывает на настоящий ''/''. <br />
<br />
'''Управление процессом сборки'''<br />
<br />
{{rpmmacro|buildmulti}}: Альтернативная директива ''%build'' для случая, когда в секции ''%build'' происходит заполнение ''%buildroot''. Вообще говоря, такой техники стоит избегать во всех случаях, когда это возможно. <br />
<br />
'''Версии некоторых установленных в системе пакетов'''<br />
<br />
'''glibc''': {{rpmmacro|__glibc_version}}, {{rpmmacro|__glibc_version_major}}, {{rpmmacro|__glibc_version_minor}} <br />
<br />
'''python''': {{rpmmacro|__python_version}} <br />
<br />
{{rpmmacro|get_version}}: Версия указанного пакета <br />
<br />
{{rpmmacro|get_release}}: Релиз указанного пакета<br />
<br />
{{rpmmacro|get_serial}}: Serial указанного пакета<br />
<br />
{{rpmmacro|add_serial}}: Serial указанного пакета в виде, пригодном для включения в ''spec''-файл. <br />
<br />
Эти макросы, как правило, используются в пакетах, сборка которых возможна с различными версиями этих программ, если эти версии правильно учитывать.<br />
<br />
'''Прочие макросы'''<br />
<br />
{{rpmmacro|intel}}: список архитектур ''intel'', совместимых с ''i386''<br />
<br />
{{rpmmacro|amd}}: список архитектур ''amd'', совместимых с ''i386''<br />
<br />
{{rpmmacro|ix86}}: список всех архитектур, совместимых с ''i386''<br />
<br />
компоненты макроса {{rpmmacro|packager}}: {{rpmmacro|packagerName}}, {{rpmmacro|packagerAddress}}.<br />
<br />
==== Новыe параметры rpm ====<br />
<br />
-'''bE''': новый режим работы ''rpm'', при котором происходит только подстановка макросов<br />
<br />
-'''nowait-lock''': не блокировать процесс, если база данных ''rpm'' занята <br />
<br />
-'''fancypercent''': отображать дополнительную информацию о процентах проделанной работы при установке/обновлении пакетов. <br />
<br />
==== Новые возможности rpm ====<br />
<br />
'''Автоматический поиск требуемых и предоставляемых зависимостей'''<br />
<br />
В дополнение к стандартному поиску зависимостей от/для разделяемых библиотек, реализована поддержка поиска требуемых зависимостей для ''shell'' и ''perl''-скриптов, а также поддержка поиска предоставляемых зависимостей для ''perl''-скриптов. (См. также [[rpm/AutoReq]].)<br />
<br />
'''Изменение семантики тэгов, управляющих поиском зависимостей'''<br />
<br />
Новые возможности ''rpm'' по автоматическому поиску зависимостей при сборке пакетов управляются, как и прежде, значениями тэгов ''AutoReq'', ''AutoProv'' и ''AutoReqProv''. К стандартным значениям ''yes/no'' (''true/false''), таким образом, добавлены новые возможные значения, являющиеся именами методов поиска зависимостей:<br />
<br />
*''lib'': включение поиска зависимостей от/для разделяемых библиотек<br />
*''shell'': включение поиска зависимостей в ''shell''-скриптах<br />
*''perl'': включение поиска зависимостей в ''perl''-скриптах<br />
*''nolib'': выключение поиска зависимостей от/для разделяемых библиотек<br />
*''noshell'': выключение поиска зависимостей в ''shell''-скриптах<br />
*''noperl'': выключение поиска зависимостей в ''perl''-скриптах<br />
*''default'': то же, что и ''yes'';<br />
*''none,off'': то же, что и ''no'';<br />
*''all'': включение всех возможных методов поиска зависимостей.<br />
<br />
Значением тэга может являться как один метод, так и перечисление методов. По умолчанию, для каждого под пакета собираемого пакета ''AutoReq'' = ''AutoProv'' = ''yes'', что на практике означает использование макросов <br />
{{rpmmacro|findreq_default_method}} и {{rpmmacro|findprov_default_method}} для определения методов поиска зависимостей.<br />
<br />
'''Автоматическое сжатие ''man'' и ''info''-документации с поддержкой различных методов сжатия'''<br />
<br />
Вся документация пакета, распознаваемая как ''man'' или ''info''-документация, по окончании работы секции ''%install'', сжимается согласно выбранному методу. Поддерживаются следующие методы сжатия:<br />
<br />
*''bzip2'': сжатие с помощью ''bzip2 -9''<br />
*''gzip'': сжатие с помощью ''gzip -9n''<br />
*''auto'': сжатие с помощью ''gzip -9n'' либо ''bzip2 -9'' в зависимости от того, какой вариант окажется эффективнее<br />
*''none'': производится декомпрессия файлов вместо сжатия<br />
*''skip'': процедура сжатия пропускается полностью.<br />
<br />
Какой метод будет использован в каждом конкретном случае, зависит от значения макроса {{rpmmacro|_compress_method}}; значение по умолчанию для этого макроса - ''auto''. По окончании процедуры сжатия производится выравнивание ссылок, которые, возможно, требуют коррекции в связи с изменениями имен файлов в процессе их сжатия.<br />
<br />
'''Автоматическое удаление отладочной информации из ELF-файлов с поддержкой различных стратегий выбора файлов, подлежащих обработке'''<br />
<br />
''Начиная с версии rpm-4.0.4-alt100.36 этот раздел устарел, brp-strip удален и вместо него используется brp-debuginfo (%_brp_strip_{debug,none}). <ref>http://lists.altlinux.org/pipermail/devel/2011-January/187944.html</ref><ref>http://lists.altlinux.org/pipermail/devel/2011-February/188021.html</ref>''<br />
<br />
Зачастую возможно уменьшить размер получаемых в результате сборки пакета ELF-файлов без потери качества за счет удаления из них отладочной информации. Поэтому по окончании работы секции ''%install'' все ELF-файлы выбранных типов обрабатываются программой ''strip''. Выбор типов файлов определяется значением макроса {{rpmmacro|_strip_method}}, которое есть набор из следующих возможных значений:<br />
<br />
*''executable'': ELF executable;<br />
*''relocatable'': ELF relocatable;<br />
*''shared'': ELF shared object;<br />
*''static'': ar archive.<br />
<br />
Кроме того, есть возможность вызывать ''strip'' вручную, для этой цели предназначены макросы {{rpmmacro|strip_executable}}, {{rpmmacro|strip_relocatable}}, {{rpmmacro|strip_shared}}, {{rpmmacro|strip_static}}. Синтаксис этих макросов подробно изложен в ''/usr/lib/rpm/brp-strip -help''.<br />
<br />
'''Автоматическая перекомпиляция python-модулей'''<br />
<br />
Как известно, python-модули обычно компилируют в байтовую форму для увеличения быстродействия при последующей работе с ними. Каждый такой модуль, помимо всего прочего, хранит время своего создания и полное имя файла, в котором должен находиться. В связи с последним обстоятельством скомпилированные модули, созданные в результате работы секции ''%install'', непригодны, ибо не могут быть использованы после установки пакета. По этой причине теперь по окончании работы секции ''%install'' производится перекомпиляция всех python-модулей таким образом, чтобы их можно было использовать после установки пакета. В качестве байт-компилятора будет использоваться программа, имя которой хранится в макросе {{rpmmacro|__python}}. Обычно это ''/usr/bin/python'', однако в некоторых случаях может потребоваться изменить это значение на другое (например, в случае сборки пакета python или если по какой-то причине перекомпиляция не нужна).<br />
<br />
'''BuildRoot'''<br />
<br />
Времена, когда тэг ''BuildRoot'' в ''spec''-файле определял, какой каталог ''rpm'' будет использовать в качестве ''BuildRoot'', прошли безвозвратно. Теперь этот таг не несет никакой информации и может (и должен) быть опущен. Вместо этого используется значение макроса {{rpmmacro|buildroot}}, который определен как ''%{_tmppath}/%{name}-buildroot'' в файле ''/usr/lib/rpm/macros'' и может быть переопределен в любом месте, где допускается определять макросы. В случае, если макрос {{rpmmacro|buildroot}} не определен либо его значение представляет собой недопустимое значение ''/'', сборка пакета не будет выполнена.<br />
<br />
'''Автоматическая очистка BuildRoot'''<br />
<br />
Перед выполнением секции ''%install'' и по окончании выполнения секции ''%clean'' ''rpm'' автоматически очищает ''BuildRoot'' с помощью макроса {{rpmmacro|clean_buildroot}}. Это значит, что больше не нужно использовать эти ужасные ''rm -rf $RPM_BUILD_ROOT''. Секция ''%clean'' вообще может (и должна) быть опущена, если в ней не содержится ничего, кроме этого ''rm''. В тех редких случаях, когда в ''spec''-файле производится заполнение ''BuildRoot'' не в секции ''%install'', как это должно быть, а в секции ''%build'', что в принципе неправильно, можно перенести точку очистки ''BuildRoot'' из начала секции ''%install'' в начало секции ''%build'', если заменить директиву ''%build'' на макрос {{rpmmacro|buildmulti}}.<br />
<br />
'''Упрощение секции %files'''<br />
<br />
Ранее в начале каждой секции %files было необходимо указывать атрибуты файлов и каталогов создаваемых пакетов с помощью довольно однообразно используемой директивы %defattr. Теперь это происходит автоматически в начале каждой секции %files, а также в начале каждого файла, включаемого в секцию %files с помощью опции -f. Точнее говоря, в качестве этой директивы используется значение макроса %_defattr. Таким образом, прежнее использование директивы %defattr в начале секций и файлов следует считать упраздненным.<br />
<br />
'''Сборка пакетов привилегированным пользователем'''<br />
<br />
То, что когда-то было необходимостью, со временем стало излишним, а порой и просто опасным. Теперь, когда все пакеты, кроме одного-единственного MAKEDEV, можно (и нужно) собирать непривилегированным пользователем во избежание риска разрушения системы и некорректной сборки, сборка пакетов привилегированным пользователем по умолчанию запрещена. Этот запрет можно снять путем изменения значения макроса {{rpmmacro|_allow_root_build}}.<br />
<br />
=== Пожелания packager'у ===<br />
<br />
==== Устаревшие конструкции ====<br />
<br />
Не следует использовать устаревшие конструкции - они лишь загромождают ''spec''-файл, снижая тем самым его читабельность. К устаревшим конструкциям, в частности, относятся:<br />
* тэг ''BuildRoot:'' (BuildRoot выбирается автоматически);<br />
* тэг ''Packager:'' (Packager заполняется автоматически);<br />
* cтроки вида ''rm -rf $RPM_BUILD_ROOT'' (BuildRoot очищается автоматически);<br />
* {{rpmmacro|_defattr}} со стандартными аргументами в начале файлов и секций ''%files'' (такое поведение действует по умолчанию);<br />
* секция ''%clean'', пустая либо без разумного содержания.<br />
<br />
==== Фигурные скобки ====<br />
<br />
Нет смысла засорять текст spec-файла ненужными фигурными скобками. Избавится от них легко:<br />
<br />
''perl -pi -e 's/%\{([A-Za-z_0-9]+)\}([^A-Za-z_0-9?*]|$)/%$1$2/g' spec''-файл<br />
<br />
Или с помощью утилиты ''cleanup_spec'' из пакета ''rpm-utils''.<br />
<br />
==== Выравнивание ====<br />
<br />
Используйте табуляции для выравнивания. Избегайте пробельных символов в конце строк.<br />
<br />
==== Значения тэгов ====<br />
<br />
Значение тэга от его имени следует разделять одним пробелом. Элементы списка значений следует разделять запятой с последующим пробелом. Значение тэга Summary следует начинать с прописной буквы и не следует завершать точкой. Значения тэга ''Summary'' и секции ''%description'' могут содержать названия команд только в не изменённом виде.<br />
<br />
==== Порядок тэгов ====<br />
<br />
Рекомендуемый порядок заголовочных тэгов: <br />
*Name<br />
*Version<br />
*Release<br />
*Epoch или Serial<br />
<br />
далее<br />
<br />
*Summary<br />
*License<br />
*Group<br />
*Url<br />
*Packager (устарело, использование не рекомендовано)<br />
*BuildArch<br />
<br />
далее<br />
<br />
*Provides<br />
*Requires<br />
*PreReqs<br />
*Conflicts<br />
<br />
потом (влияющие на процесс сборки, но не то, как пакет выглядит снаружи)<br />
<br />
*Source<br />
*Patch<br />
<br />
и, наконец,<br />
<br />
*Prefix<br />
*BuildPreReqs<br />
*BuildRequires.<br />
<br />
Разумеется, не все из вышеперечисленных тэгов, как правило, используются, равно как встречаются и другие редко используемые тэги. В связи с тем, что ''BuildRequires'' зарезервирован для автоматически вычисляемых зависимостей, для указания особых зависимостей следует использовать ''BuildPreReq''.<br />
<br />
==== Файлы локализации ====<br />
<br />
Если в состав пакета входят файлы локализации либо другие файлы на разных языках, стоит использовать макрос {{rpmmacro|find_lang}}. Подробная информация есть в ''/usr/lib/rpm/find-lang -h''<br />
<br />
==== Группы ====<br />
<br />
Следите за значением тэгов ''Group'': они должны соответствовать действительности и при этом принадлежать фиксированному множеству, перечисленному в файле ''/usr/lib/rpm/GROUPS''.<br />
<br />
==== ChangeLog ====<br />
{{Main|Руководство по написанию changelog}}<br />
Для формирования первой строки changelog-записи удобно использовать утилиту ''[[add_changelog]]'' из пакета ''rpm-utils''.<br />
<br />
==== Внутрипакетные зависимости ====<br />
<br />
При работе с мультипакетными spec-файлами соблюдайте правило внутрипакетных зависимостей: Если один пакет в какой-либо мере зависит от другого подпакета, то эта зависимость должна быть указана полностью, включая не только имя, но также верcию, релиз и serial (если есть). Например, ''Requires: %name = %version-%release'' или Requires: %name = %epoch:%version-%release. Обратите внимание на синтаксис: знак равенства, в отличие от дефиса, окружен пробелами.<br />
<br />
==== Разделяемые библиотеки ====<br />
<br />
Пакеты, содержащие как разделяемые библиотеки, так и использующие их программы, должны быть разделены на подпакеты таким образом, чтобы в подпакет, содержащий разделяемые библиотеки, не входили использующие их программы. Это позволит уменьшить количество циклических зависимостей. По традиции, имена пакетов, состоящих только из разделяемых библиотек, должны начинаться с префикса ''lib'' либо содержать его внутри слова. При разделении подпакетов следует помнить о внутрипакетных зависимостях.<br />
Обратите внимание, что при сборке и именовании пакетов с разделяемыми библиотеками важно соблюдение [[Shared_Libs_Policy]].<br />
<br />
==== Статические библиотеки ====<br />
<br />
Статические библиотеки должны паковаться в отдельные подпакеты, что связано со спецификой их использования. Если имя ''devel''-подпакета заканчивается суффиксом ''-devel'', то имя нового ''devel-static''-подпакета будет заканчиваться суффиксом ''-devel-static''. При разделении подпакетов следует помнить о внутрипакетных зависимостях: В списке зависимостей ''devel-static''-подпакета должна присутствовать зависимость от ''-devel = %version-%release''.<br />
<br />
==== Переименование пакетов ====<br />
<br />
Иногда пакеты переименовывают. Например, это случается при упаковке разделяемых библиотек. В таких случаях следует указывать правильную информацию о зависимостях, необходимую для корректного обновления. В частности, должен присутствовать:<br />
тэг ''Provides: старое_имя = %EVR''<br />
тэг ''Obsoletes: старое_имя < %EVR'' <br />
<br />
(Примечание: [[Реагирует ли сборочница на переименование пакетов]].)<br />
<br />
==== Наименование патчей ====<br />
<br />
При создании новых патчей, а также при импортировании патчей из других источников необходимо придерживаться единых правил наименования имён патч-файлов: NAME-VERSION-ORIGIN-WHAT.patch, где <br />
<br />
* NAME и VERSION — имя и версия пакета, для которого сделан патч; <br />
* ORIGIN — аббревиатуры источников патча (обычно дистрибутивов); <br />
* WHAT — краткое описание патча. <br />
<br />
В случае, когда патч образован из нескольких частей, полученных из разных источников, компонента имени ORIGIN должна содержать аббревиатуры всех источников. Если патч был создан или адаптирован для ALT Linux, то в ORIGIN, соответственно, должно присутствовать -alt-. Для патчей, созданных на базе CVS, компонента имени ORIGIN должна начинаться с cvs-YYYYMMDD. <br />
<br />
При составлении описания патча следует иметь в виду следующие общепринятые сокращения: <br />
* makefile - патчи, затрагивающие исключительно makefile*; <br />
* bound - проверки на границы (буфера, целых чисел, и т.п.);<br />
* config - патчи, затрагивающие исключительно конфигурационные файлы;<br />
* configure - патчи, затрагивающие исключительно configure*; <br />
* doc - патчи, затрагивающие исключительно документацию;<br />
* fixes - кумулятивные патчи и/или исправления по надёжности и/или безопасности;<br />
* format - патчи на использование форматирования строк (printf); <br />
* install - патчи, направленные на возможность выполнения make install непривилегированным пользователем; <br />
* linux - патчи, предназначенные для портирования ПО на Linux;<br />
* man - патчи, затрагивающие исключительно man-страницы; <br />
* texinfo - патчи, затрагивающие исключительно документацию в формате texinfo;<br />
* tmp - патчи, предназначенные для решения различных вопросов, связанных с временными файлами;<br />
* vitmp - патчи, направленные на поддержку vitmp(1); <br />
* warnings - патчи, исправляющие ошибки, найденные компилятором.<br />
<br />
== Литература ==<br />
<br />
*[http://www.rpm.org/ Официальный web-сайт rpm]<br />
*[http://lists.rpm.org/mailman/listinfo/rpm-list Список рассылки для разработчиков rpm 4.x]<br />
*[http://www.rpm.org/max-rpm-snapshot/index.html Maximum RPM], Edward C. Bailey February 17, 1997. (снэпшот книги)<br />
<br />
== Примечания ==<br />
* исходная версия этого документа доступна [http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/doc/ здесь] или [http://docs.altlinux.org/archive/2.4/master/alt-docs-devel/ch04.html в документации Master 2.4]<br />
<references /><br />
{{Category navigation|title=Сборка пакетов|category=Сборка пакетов|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=ALT_Packaging_HOWTO&diff=71514ALT Packaging HOWTO2023-07-25T18:17:52Z<p>AntonFarygin: /* Переименование пакетов */</p>
<hr />
<div>[[Категория:Devel]]<br />
[[Категория:RPM spec]]<br />
<br />
== ALT Packaging HOWTO (revision 0.3) ==<br />
<br />
Dmitry V. Levin <ldv@altlinux.ru><br />
ALT Linux Team<br />
<br />
=== Введение ===<br />
<br />
При разработке изменений и дополнений к rpm решались следующие задачи:<br />
*Обеспечить желаемую функциональность:<br />
наши пакеты должны отвечать определенным правилам, о которых пойдет речь несколько позже. Для этого надо, чтобы ''spec''-файлы обеспечивали выполнение этих правил. <br />
*Помочь разработчику:<br />
так как ''spec''-файлы все еще пишут люди, то их работу нужно свести к тому минимуму, который, собственно, и требует участия человека. Разработчик не должен копировать блоки кода из файла в файл, ибо эта неинтеллектуальная работа отнимает массу сил и чревата ошибками. Для этого есть макросы. Если какой-то код появляется в разных ''spec''-файлах более одного раза, то надо написать макрос(ы). <br />
*Сделать ''spec''-файлы более читабельными:<br />
те, кто эти файлы читает - тоже живые люди. Им будет удобнее, если в наименовании, расположении и использовании различных элементов ''spec''-файлов будет определенный порядок. <br />
<br />
=== Особенности этой версии rpm ===<br />
<br />
==== Новые макросы ====<br />
<br />
'''Макросы для часто используемых каталогов'''<br />
<br />
*<s>X11R6: {{rpmmacro|_x11dir}}, {{rpmmacro|_x11bindir}}, {{rpmmacro|_x11libdir}}, {{rpmmacro|_x11includedir}}, {{rpmmacro|_x11mandir}}, {{rpmmacro|_x11datadir}}</s><br>''NB: устарели с X11R7, используем {{rpmmacro|_bindir}} и прочие без x11''<br />
<br />
*лицензии: {{rpmmacro|_licensedir}} <br />
<br />
*меню: <s>{{rpmmacro|_menudir}}</s>, {{rpmmacro|_iconsdir}}, {{rpmmacro|_miconsdir}}, {{rpmmacro|_liconsdir}}<br />
<br />
*emacs: {{rpmmacro|_emacslispdir}}<br />
<br />
*другие системные: {{rpmmacro|_initddir}} ({{rpmmacro|_initir}} и {{rpmmacro|_initrddir}} [https://bugzilla.altlinux.org/show_bug.cgi?id=24290 объявлены устаревшими]), {{rpmmacro|_lockdir}}, {{rpmmacro|_logdir}}. <br />
<br />
'''Управление опциями компилятора gcc'''<br />
<br />
{{rpmmacro|add_optflags}} <options>: добавить указанные параметры в стандартный набор {{rpmmacro|_%opflags}}<br />
<br />
{{rpmmacro|remove_optflags}} <options>: убрать указанные параметры из стандартного набора {{rpmmacro|_%opflags}}<br />
<br />
{{rpmmacro|optflags_core}}: базовые параметры<br />
<br />
{{rpmmacro|__optlevel}}: уровень оптимизации<br />
<br />
{{rpmmacro|optflags_optimization}}: параметры, отвечающие за оптимизацию, кроме архитектурно-зависимых<br />
<br />
{{rpmmacro|optflags_warnings}}: ''warning options''<br />
<br />
{{rpmmacro|optflags_debug}}: ''debugging options''<br />
<br />
{{rpmmacro|optflags_shared}}: параметры, применяемые для создания relocatable файлов<br />
<br />
{{rpmmacro|optflags_nocpp}}: параметры, отключающие поддержку C++ exceptions и C++ RTTI<br />
<br />
{{rpmmacro|optflags_notraceback}}: ''-fomit-frame-pointer''<br />
<br />
{{rpmmacro|optflags_fastmath}}: ''-ffast-math''<br />
<br />
{{rpmmacro|optflags_strict}}: ''-fstrict-aliasing''<br />
<br />
{{rpmmacro|optflags_kernel}}: параметры, используемые при компиляции ядра и его модулей.<br />
<br />
По умолчанию, стандартный набор {{rpmmacro|optflags}} состоит из "{{rpmmacro|optflags_core}} {{rpmmacro|optflags_warnings}} {{rpmmacro|optflags_optimization}}".<br />
<br />
'''Макросы-надстройки над утилитой make'''<br />
<br />
{{rpmmacro|make_build}}: вызов make с параметром, обеспечивающим оптимальную параллельную сборку в данной среде<br />
<br />
{{rpmmacro|make_install}}: вызов make c инициализацией переменной INSTALL, что в случае корректной реализации Makefile'ов пакета позволяет сохранить дату последней модификации файлов, что особенно важно для документации;<br />
<br />
{{rpmmacro|makeinstall}}: make <инициализация других переменных, используемых многими Makefile'ами> install. Переопределяет все пути, куда устанавливаются файлы, добавляя к ним buildroot (используется для неправильных установочных скриптов, в которых забыто DESTDIR);<br />
<br />
{{rpmmacro|makeinstall_std}}: выполняет %make_install install DESTDIR=%buildroot, нужное для установки программы, собранной через autotools;<br />
<br />
<s>'''Регистрация документации в формате info''</s><br />
<br />
<s>{{rpmmacro|install_info}}: регистрация новых/обновленных ''info''-страниц.</s><br />
<br />
<s>{{rpmmacro|uninstall_info}}: отмена регистрации удаленных ''info''-страниц.</s><br />
<br />
''Устарело с появлением filetriggers''<br />
<br />
<s>'''Регистрация меню'''</s><br />
<br />
<s>{{rpmmacro|update_menus}}: регистрация новых/обновленных меню.</s><br />
<br />
<s>{{rpmmacro|clean_menus}}: отмена регистрации удаленных меню.</s><br />
<br />
''Устарело с появлением filetriggers''<br />
<br />
'''Вспомогательные макросы %configure'''<br />
<br />
{{rpmmacro|__libtoolize}}: путь к скрипту ''libtoolize''<br />
<br />
{{rpmmacro|_configure_script}}: путь к скрипту ''configure''<br />
<br />
{{rpmmacro|_configure_target}}: целевая платформа для ''configure''<br />
<br />
{{rpmmacro|_configure_gettext}}: ''-without-included-gettext''. <br />
<br />
'''Серверные макросы'''<br />
<br />
{{rpmmacro|post_service}}: регистрация нового сервиса при установке, перезапуск при обновлении<ref>НИКОГДА не используйте {{rpmmacro|post_service}} для<br />
перезапуска сторонних сервисов. ([http://lists.altlinux.org/pipermail/devel/2010-September/184624.html raorn@])<pre>/sbin/service %apache2_dname condreload|condrestart ||:</pre></ref><ref>%post_service предназначен для<br />
* регистрации сервиса при первой установке пакета;<br />
* перезапуске сервиса при обновлении пакета.<br />
Запускать сервис автоматически сразу при первой установке пакета не положено. ([http://lists.altlinux.org/pipermail/devel/2010-September/184646.html ldv@])</ref><br />
<br />
{{rpmmacro|preun_service}}: отмена регистрации сервиса и его выключение при удалении. <br />
<br />
'''Макросы, определяющие некоторые аспекты packaging policy'''<br />
<br />
{{rpmmacro|buildroot}}: значение ''BuildRoot''<br />
<br />
{{rpmmacro|_defattr}}: атрибуты файлов и каталогов по умолчанию для каждой секции ''%files'' и для каждого файла, включаемого в этих секциях<br />
<br />
{{rpmmacro|_compress_method}}: метод, используемый при сжатии документации в секции ''%install''<br />
<br />
{{rpmmacro|_strip_method}}: метод, используемый при обработке ELF-файлов в секции ''%install'' (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|findreq_default_method}}: метод, используемый по умолчанию при поиске требуемых зависимостей <br />
<br />
{{rpmmacro|findprov_default_method}}: метод, используемый по умолчанию при поиске предоставляемых зависимостей<br />
<br />
{{rpmmacro|set_strip_method}}: изменить значение макроса ''%_strip_method'' (макрос удален с версии rpm-4.0.4-alt100.36, вместо него с параметром ''none'' пользуйтесь {{rpmmacro|brp_strip_none}})<br />
<br />
'''Вызов вспомогательных программ'''<br />
<br />
{{rpmmacro|find_lang}}: вызов ''/usr/lib/rpm/find-lang''<br />
<br />
{{rpmmacro|strip_executable}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF executables (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|strip_relocatable}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF relocatables (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|strip_shared}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF shared objects (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|strip_static}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF ar archives (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|cleanup_build}}: вызов ''/usr/lib/rpm/brp-cleanup''<br />
<br />
{{rpmmacro|compress_docs}}: вызов ''/usr/lib/rpm/brp-compress'' <br />
<br />
{{rpmmacro|strip_binaries}}: вызов ''/usr/lib/rpm/brp-strip'' (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|clean_buildroot}}: выполнение ''rm -rf %buildroot'', если ''%buildroot'' не указывает на настоящий ''/''. <br />
<br />
'''Управление процессом сборки'''<br />
<br />
{{rpmmacro|buildmulti}}: Альтернативная директива ''%build'' для случая, когда в секции ''%build'' происходит заполнение ''%buildroot''. Вообще говоря, такой техники стоит избегать во всех случаях, когда это возможно. <br />
<br />
'''Версии некоторых установленных в системе пакетов'''<br />
<br />
'''glibc''': {{rpmmacro|__glibc_version}}, {{rpmmacro|__glibc_version_major}}, {{rpmmacro|__glibc_version_minor}} <br />
<br />
'''python''': {{rpmmacro|__python_version}} <br />
<br />
{{rpmmacro|get_version}}: Версия указанного пакета <br />
<br />
{{rpmmacro|get_release}}: Релиз указанного пакета<br />
<br />
{{rpmmacro|get_serial}}: Serial указанного пакета<br />
<br />
{{rpmmacro|add_serial}}: Serial указанного пакета в виде, пригодном для включения в ''spec''-файл. <br />
<br />
Эти макросы, как правило, используются в пакетах, сборка которых возможна с различными версиями этих программ, если эти версии правильно учитывать.<br />
<br />
'''Прочие макросы'''<br />
<br />
{{rpmmacro|intel}}: список архитектур ''intel'', совместимых с ''i386''<br />
<br />
{{rpmmacro|amd}}: список архитектур ''amd'', совместимых с ''i386''<br />
<br />
{{rpmmacro|ix86}}: список всех архитектур, совместимых с ''i386''<br />
<br />
компоненты макроса {{rpmmacro|packager}}: {{rpmmacro|packagerName}}, {{rpmmacro|packagerAddress}}.<br />
<br />
==== Новыe параметры rpm ====<br />
<br />
-'''bE''': новый режим работы ''rpm'', при котором происходит только подстановка макросов<br />
<br />
-'''nowait-lock''': не блокировать процесс, если база данных ''rpm'' занята <br />
<br />
-'''fancypercent''': отображать дополнительную информацию о процентах проделанной работы при установке/обновлении пакетов. <br />
<br />
==== Новые возможности rpm ====<br />
<br />
'''Автоматический поиск требуемых и предоставляемых зависимостей'''<br />
<br />
В дополнение к стандартному поиску зависимостей от/для разделяемых библиотек, реализована поддержка поиска требуемых зависимостей для ''shell'' и ''perl''-скриптов, а также поддержка поиска предоставляемых зависимостей для ''perl''-скриптов. (См. также [[rpm/AutoReq]].)<br />
<br />
'''Изменение семантики тэгов, управляющих поиском зависимостей'''<br />
<br />
Новые возможности ''rpm'' по автоматическому поиску зависимостей при сборке пакетов управляются, как и прежде, значениями тэгов ''AutoReq'', ''AutoProv'' и ''AutoReqProv''. К стандартным значениям ''yes/no'' (''true/false''), таким образом, добавлены новые возможные значения, являющиеся именами методов поиска зависимостей:<br />
<br />
*''lib'': включение поиска зависимостей от/для разделяемых библиотек<br />
*''shell'': включение поиска зависимостей в ''shell''-скриптах<br />
*''perl'': включение поиска зависимостей в ''perl''-скриптах<br />
*''nolib'': выключение поиска зависимостей от/для разделяемых библиотек<br />
*''noshell'': выключение поиска зависимостей в ''shell''-скриптах<br />
*''noperl'': выключение поиска зависимостей в ''perl''-скриптах<br />
*''default'': то же, что и ''yes'';<br />
*''none,off'': то же, что и ''no'';<br />
*''all'': включение всех возможных методов поиска зависимостей.<br />
<br />
Значением тэга может являться как один метод, так и перечисление методов. По умолчанию, для каждого под пакета собираемого пакета ''AutoReq'' = ''AutoProv'' = ''yes'', что на практике означает использование макросов <br />
{{rpmmacro|findreq_default_method}} и {{rpmmacro|findprov_default_method}} для определения методов поиска зависимостей.<br />
<br />
'''Автоматическое сжатие ''man'' и ''info''-документации с поддержкой различных методов сжатия'''<br />
<br />
Вся документация пакета, распознаваемая как ''man'' или ''info''-документация, по окончании работы секции ''%install'', сжимается согласно выбранному методу. Поддерживаются следующие методы сжатия:<br />
<br />
*''bzip2'': сжатие с помощью ''bzip2 -9''<br />
*''gzip'': сжатие с помощью ''gzip -9n''<br />
*''auto'': сжатие с помощью ''gzip -9n'' либо ''bzip2 -9'' в зависимости от того, какой вариант окажется эффективнее<br />
*''none'': производится декомпрессия файлов вместо сжатия<br />
*''skip'': процедура сжатия пропускается полностью.<br />
<br />
Какой метод будет использован в каждом конкретном случае, зависит от значения макроса {{rpmmacro|_compress_method}}; значение по умолчанию для этого макроса - ''auto''. По окончании процедуры сжатия производится выравнивание ссылок, которые, возможно, требуют коррекции в связи с изменениями имен файлов в процессе их сжатия.<br />
<br />
'''Автоматическое удаление отладочной информации из ELF-файлов с поддержкой различных стратегий выбора файлов, подлежащих обработке'''<br />
<br />
''Начиная с версии rpm-4.0.4-alt100.36 этот раздел устарел, brp-strip удален и вместо него используется brp-debuginfo (%_brp_strip_{debug,none}). <ref>http://lists.altlinux.org/pipermail/devel/2011-January/187944.html</ref><ref>http://lists.altlinux.org/pipermail/devel/2011-February/188021.html</ref>''<br />
<br />
Зачастую возможно уменьшить размер получаемых в результате сборки пакета ELF-файлов без потери качества за счет удаления из них отладочной информации. Поэтому по окончании работы секции ''%install'' все ELF-файлы выбранных типов обрабатываются программой ''strip''. Выбор типов файлов определяется значением макроса {{rpmmacro|_strip_method}}, которое есть набор из следующих возможных значений:<br />
<br />
*''executable'': ELF executable;<br />
*''relocatable'': ELF relocatable;<br />
*''shared'': ELF shared object;<br />
*''static'': ar archive.<br />
<br />
Кроме того, есть возможность вызывать ''strip'' вручную, для этой цели предназначены макросы {{rpmmacro|strip_executable}}, {{rpmmacro|strip_relocatable}}, {{rpmmacro|strip_shared}}, {{rpmmacro|strip_static}}. Синтаксис этих макросов подробно изложен в ''/usr/lib/rpm/brp-strip -help''.<br />
<br />
'''Автоматическая перекомпиляция python-модулей'''<br />
<br />
Как известно, python-модули обычно компилируют в байтовую форму для увеличения быстродействия при последующей работе с ними. Каждый такой модуль, помимо всего прочего, хранит время своего создания и полное имя файла, в котором должен находиться. В связи с последним обстоятельством скомпилированные модули, созданные в результате работы секции ''%install'', непригодны, ибо не могут быть использованы после установки пакета. По этой причине теперь по окончании работы секции ''%install'' производится перекомпиляция всех python-модулей таким образом, чтобы их можно было использовать после установки пакета. В качестве байт-компилятора будет использоваться программа, имя которой хранится в макросе {{rpmmacro|__python}}. Обычно это ''/usr/bin/python'', однако в некоторых случаях может потребоваться изменить это значение на другое (например, в случае сборки пакета python или если по какой-то причине перекомпиляция не нужна).<br />
<br />
'''BuildRoot'''<br />
<br />
Времена, когда тэг ''BuildRoot'' в ''spec''-файле определял, какой каталог ''rpm'' будет использовать в качестве ''BuildRoot'', прошли безвозвратно. Теперь этот таг не несет никакой информации и может (и должен) быть опущен. Вместо этого используется значение макроса {{rpmmacro|buildroot}}, который определен как ''%{_tmppath}/%{name}-buildroot'' в файле ''/usr/lib/rpm/macros'' и может быть переопределен в любом месте, где допускается определять макросы. В случае, если макрос {{rpmmacro|buildroot}} не определен либо его значение представляет собой недопустимое значение ''/'', сборка пакета не будет выполнена.<br />
<br />
'''Автоматическая очистка BuildRoot'''<br />
<br />
Перед выполнением секции ''%install'' и по окончании выполнения секции ''%clean'' ''rpm'' автоматически очищает ''BuildRoot'' с помощью макроса {{rpmmacro|clean_buildroot}}. Это значит, что больше не нужно использовать эти ужасные ''rm -rf $RPM_BUILD_ROOT''. Секция ''%clean'' вообще может (и должна) быть опущена, если в ней не содержится ничего, кроме этого ''rm''. В тех редких случаях, когда в ''spec''-файле производится заполнение ''BuildRoot'' не в секции ''%install'', как это должно быть, а в секции ''%build'', что в принципе неправильно, можно перенести точку очистки ''BuildRoot'' из начала секции ''%install'' в начало секции ''%build'', если заменить директиву ''%build'' на макрос {{rpmmacro|buildmulti}}.<br />
<br />
'''Упрощение секции %files'''<br />
<br />
Ранее в начале каждой секции %files было необходимо указывать атрибуты файлов и каталогов создаваемых пакетов с помощью довольно однообразно используемой директивы %defattr. Теперь это происходит автоматически в начале каждой секции %files, а также в начале каждого файла, включаемого в секцию %files с помощью опции -f. Точнее говоря, в качестве этой директивы используется значение макроса %_defattr. Таким образом, прежнее использование директивы %defattr в начале секций и файлов следует считать упраздненным.<br />
<br />
'''Сборка пакетов привилегированным пользователем'''<br />
<br />
То, что когда-то было необходимостью, со временем стало излишним, а порой и просто опасным. Теперь, когда все пакеты, кроме одного-единственного MAKEDEV, можно (и нужно) собирать непривилегированным пользователем во избежание риска разрушения системы и некорректной сборки, сборка пакетов привилегированным пользователем по умолчанию запрещена. Этот запрет можно снять путем изменения значения макроса {{rpmmacro|_allow_root_build}}.<br />
<br />
=== Пожелания packager'у ===<br />
<br />
==== Устаревшие конструкции ====<br />
<br />
Не следует использовать устаревшие конструкции - они лишь загромождают ''spec''-файл, снижая тем самым его читабельность. К устаревшим конструкциям, в частности, относятся:<br />
* тэг ''BuildRoot:'' (BuildRoot выбирается автоматически);<br />
* тэг ''Packager:'' (Packager заполняется автоматически);<br />
* cтроки вида ''rm -rf $RPM_BUILD_ROOT'' (BuildRoot очищается автоматически);<br />
* {{rpmmacro|_defattr}} со стандартными аргументами в начале файлов и секций ''%files'' (такое поведение действует по умолчанию);<br />
* секция ''%clean'', пустая либо без разумного содержания.<br />
<br />
==== Фигурные скобки ====<br />
<br />
Нет смысла засорять текст spec-файла ненужными фигурными скобками. Избавится от них легко:<br />
<br />
''perl -pi -e 's/%\{([A-Za-z_0-9]+)\}([^A-Za-z_0-9?*]|$)/%$1$2/g' spec''-файл<br />
<br />
Или с помощью утилиты ''cleanup_spec'' из пакета ''rpm-utils''.<br />
<br />
==== Выравнивание ====<br />
<br />
Используйте табуляции для выравнивания. Избегайте пробельных символов в конце строк.<br />
<br />
==== Значения тэгов ====<br />
<br />
Значение тэга от его имени следует разделять одним пробелом. Элементы списка значений следует разделять запятой с последующим пробелом. Значение тэга Summary следует начинать с прописной буквы и не следует завершать точкой. Значения тэга ''Summary'' и секции ''%description'' могут содержать названия команд только в не изменённом виде.<br />
<br />
==== Порядок тэгов ====<br />
<br />
Рекомендуемый порядок заголовочных тэгов: <br />
*Name<br />
*Version<br />
*Release<br />
*Epoch или Serial<br />
<br />
далее<br />
<br />
*Summary<br />
*License<br />
*Group<br />
*Url<br />
*Packager (устарело, использование не рекомендовано)<br />
*BuildArch<br />
<br />
далее<br />
<br />
*Provides<br />
*Requires<br />
*PreReqs<br />
*Conflicts<br />
<br />
потом (влияющие на процесс сборки, но не то, как пакет выглядит снаружи)<br />
<br />
*Source<br />
*Patch<br />
<br />
и, наконец,<br />
<br />
*Prefix<br />
*BuildPreReqs<br />
*BuildRequires.<br />
<br />
Разумеется, не все из вышеперечисленных тэгов, как правило, используются, равно как встречаются и другие редко используемые тэги. В связи с тем, что ''BuildRequires'' зарезервирован для автоматически вычисляемых зависимостей, для указания особых зависимостей следует использовать ''BuildPreReq''.<br />
<br />
==== Файлы локализации ====<br />
<br />
Если в состав пакета входят файлы локализации либо другие файлы на разных языках, стоит использовать макрос {{rpmmacro|find_lang}}. Подробная информация есть в ''/usr/lib/rpm/find-lang -h''<br />
<br />
==== Группы ====<br />
<br />
Следите за значением тэгов ''Group'': они должны соответствовать действительности и при этом принадлежать фиксированному множеству, перечисленному в файле ''/usr/lib/rpm/GROUPS''.<br />
<br />
==== ChangeLog ====<br />
{{Main|Руководство по написанию changelog}}<br />
Для формирования первой строки changelog-записи удобно использовать утилиту ''[[add_changelog]]'' из пакета ''rpm-utils''.<br />
<br />
==== Внутрипакетные зависимости ====<br />
<br />
При работе с мультипакетными spec-файлами соблюдайте правило внутрипакетных зависимостей: Если один пакет в какой-либо мере зависит от другого подпакета, то эта зависимость должна быть указана полностью, включая не только имя, но также верcию, релиз и serial (если есть). Например, ''Requires: %name = %version-%release'' или Requires: %name = %epoch:%version-%release. Обратите внимание на синтаксис: знак равенства, в отличие от дефиса, окружен пробелами.<br />
<br />
==== Разделяемые библиотеки ====<br />
<br />
Пакеты, содержащие как разделяемые библиотеки, так и использующие их программы, должны быть разделены на подпакеты таким образом, чтобы в подпакет, содержащий разделяемые библиотеки, не входили использующие их программы. Это позволит уменьшить количество циклических зависимостей. По традиции, имена пакетов, состоящих только из разделяемых библиотек, должны начинаться с префикса ''lib'' либо содержать его внутри слова. При разделении подпакетов следует помнить о внутрипакетных зависимостях.<br />
<br />
==== Статические библиотеки ====<br />
<br />
Статические библиотеки должны паковаться в отдельные подпакеты, что связано со спецификой их использования. Если имя ''devel''-подпакета заканчивается суффиксом ''-devel'', то имя нового ''devel-static''-подпакета будет заканчиваться суффиксом ''-devel-static''. При разделении подпакетов следует помнить о внутрипакетных зависимостях: В списке зависимостей ''devel-static''-подпакета должна присутствовать зависимость от ''-devel = %version-%release''.<br />
<br />
==== Переименование пакетов ====<br />
<br />
Иногда пакеты переименовывают. Например, это случается при упаковке разделяемых библиотек. В таких случаях следует указывать правильную информацию о зависимостях, необходимую для корректного обновления. В частности, должен присутствовать:<br />
тэг ''Provides: старое_имя = %EVR''<br />
тэг ''Obsoletes: старое_имя < %EVR'' <br />
<br />
(Примечание: [[Реагирует ли сборочница на переименование пакетов]].)<br />
<br />
==== Наименование патчей ====<br />
<br />
При создании новых патчей, а также при импортировании патчей из других источников необходимо придерживаться единых правил наименования имён патч-файлов: NAME-VERSION-ORIGIN-WHAT.patch, где <br />
<br />
* NAME и VERSION — имя и версия пакета, для которого сделан патч; <br />
* ORIGIN — аббревиатуры источников патча (обычно дистрибутивов); <br />
* WHAT — краткое описание патча. <br />
<br />
В случае, когда патч образован из нескольких частей, полученных из разных источников, компонента имени ORIGIN должна содержать аббревиатуры всех источников. Если патч был создан или адаптирован для ALT Linux, то в ORIGIN, соответственно, должно присутствовать -alt-. Для патчей, созданных на базе CVS, компонента имени ORIGIN должна начинаться с cvs-YYYYMMDD. <br />
<br />
При составлении описания патча следует иметь в виду следующие общепринятые сокращения: <br />
* makefile - патчи, затрагивающие исключительно makefile*; <br />
* bound - проверки на границы (буфера, целых чисел, и т.п.);<br />
* config - патчи, затрагивающие исключительно конфигурационные файлы;<br />
* configure - патчи, затрагивающие исключительно configure*; <br />
* doc - патчи, затрагивающие исключительно документацию;<br />
* fixes - кумулятивные патчи и/или исправления по надёжности и/или безопасности;<br />
* format - патчи на использование форматирования строк (printf); <br />
* install - патчи, направленные на возможность выполнения make install непривилегированным пользователем; <br />
* linux - патчи, предназначенные для портирования ПО на Linux;<br />
* man - патчи, затрагивающие исключительно man-страницы; <br />
* texinfo - патчи, затрагивающие исключительно документацию в формате texinfo;<br />
* tmp - патчи, предназначенные для решения различных вопросов, связанных с временными файлами;<br />
* vitmp - патчи, направленные на поддержку vitmp(1); <br />
* warnings - патчи, исправляющие ошибки, найденные компилятором.<br />
<br />
== Литература ==<br />
<br />
*[http://www.rpm.org/ Официальный web-сайт rpm]<br />
*[http://lists.rpm.org/mailman/listinfo/rpm-list Список рассылки для разработчиков rpm 4.x]<br />
*[http://www.rpm.org/max-rpm-snapshot/index.html Maximum RPM], Edward C. Bailey February 17, 1997. (снэпшот книги)<br />
<br />
== Примечания ==<br />
* исходная версия этого документа доступна [http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/doc/ здесь] или [http://docs.altlinux.org/archive/2.4/master/alt-docs-devel/ch04.html в документации Master 2.4]<br />
<references /><br />
{{Category navigation|title=Сборка пакетов|category=Сборка пакетов|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=Su&diff=70199Su2023-07-06T20:25:13Z<p>AntonFarygin: </p>
<hr />
<div>{{DISPLAYTITLE:su}}<br />
'''Вопрос:''' Как перейти в режим суперпользователя (переключиться в root)?<br />
<br />
'''Ответ:''' В терминале наберите команду (для читающих по диагонали: '''минус важен!'''):<br />
<br />
<div style="font-size: 180%"><source lang="bash">su -</source></div><br />
<br />
''Пояснения:'' при переходе в режим суперпользователя командой {{prg|su}} происходит просто вызов командного интерпретатора с правами root. При этом значения переменных окружения, в частности {{path|$PATH}}, остается таким же, как у пользователя. То есть в переменной {{path|$PATH}} не окажется каталогов {{path|/sbin}}, {{path|/usr/sbin}}, и без указания полного имени будут недоступны команды {{prg|route}}, {{prg|lilo}}, {{prg|mkswap}} и другие. Более того, переменная {{path|$HOME}} будет указывать на каталог пользователя и все программы, запущенные в режиме суперпользователя, сохранят свои настройки с правами рута в каталоге пользователя, что в дальнейшем может вызвать проблемы.<br />
<br />
Чтобы избежать этого, следует использовать {{cmd|su -}}. В этом режиме {{prg|su}} запустит командный интерпретатор в качестве login shell (подробнее см. {{cmd|man bash}} {{term|/INVOCATION}}), и он будет вести себя в точности так, как если бы в систему залогинился root.<br />
<br />
Для раздачи ограниченных прав суперпользователя применяется утилита {{prg|[[sudo]]}}.<br />
<br />
Ввиду наличия псевдонима работает также<br />
<br />
<div style="font-size: 180%"><source lang="bash">su-</source></div><br />
<br />
<source lang="bash">$ alias su-<br />
alias su-='su -'</source><br />
<br />
== Ограничения запуска ==<br />
<br />
'''Проблема'''<br />
<br />
При попытке переключиться в администратора в терминале появляется следующая ошибка:<br />
<source lang="Bash">$ su -<br />
bash: /bin/su: Отказано в доступе</source><br />
<br />
'''Решение'''<br />
<br />
Штатно пользователю для этого нужно быть в группе '''wheel''' (что автоматически выполняется для первого пользователя, заведённого при установке, и настраивается в Центре управления системой). Другие режимы регулируются командой [[control]]:<br />
<source lang="Bash">$ /usr/sbin/control su<br />
wheelonly<br />
$ ls -l `which su`<br />
-rws--x--- 1 root wheel 22316 авг 25 2012 /bin/su<br />
$ groups | grep wheel<br />
cas wheel uucp proc cdrom floppy cdwriter audio radio sambashare vboxusers camera xgrp scanner<br />
$ su -<br />
Password: <br />
#</source><br />
<br />
Также можно разрешить для всех:<br />
control su public<br />
(залогиниться первым пользователем или в консоли {{button|Ctrl}}+{{button|ALT}}+{{button|F2}} самим [[root]].<br />
<br />
== Ошибки, возникающие при неправильном использовании su ==<br />
Чаще всего пользователь, который неправильно запускал su сталкивается с некорректной работой различных программ - не сохраняются конфигурационные файлы, не работают настройки, происходят произвольные сообщения об ошибках записи.<br />
Рекомендуется проверить домашний каталог на наличие файлов, принадлежащих пользователю root командой:<br />
<source lang="Bash"><br />
$ find $HOME -user root<br />
</source><br />
если ваша система исправна, то список файлов будет пустой.<br />
<br />
<br />
== Ссылки ==<br />
* [https://bugzilla.altlinux.org/23700 Bug 23700: Совместимость по параметрам и поведению с версией из Red Hat]<br />
* [[Получение_прав_root]]<br />
* [[sudo|Настройка sudo]]<br />
* [http://web.archive.org/web/20081204101725/core.nix.bofh.ru/docs/noroot2.htm Как обойтись без прав root. Часть 2]<br />
<br />
{{Category navigation|title=root|category=root|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%9F%D0%B0%D0%BA%D0%B5%D1%82%D0%B0_%D0%BD%D0%B5%D1%82_%D0%B2_Sisyphus&diff=68673Пакета нет в Sisyphus2023-06-18T10:39:21Z<p>AntonFarygin: /* 4. Подгоняем spec под alt linux policy */</p>
<hr />
<div>== Предварительная подготовка ==<br />
Статья предполагает применение {{pkg|etersoft-build-utils}} (''см. [[Etersoft-build-utils howto]]'').<br />
<br />
== Ищем инородный src.rpm ==<br />
<br />
=== 1. Поиск по дистрибутивам с пакетами rpm ===<br />
<br />
$ rpmgp -a Имя_пакета<br />
<br />
<pre><br />
$ rpmgp -a synapse<br />
<br />
List for alt:<br />
synapse-0.2.99.1-alt2.src.rpm<br />
<br />
List for altautoimports:<br />
perl-Business-OnlinePayment-SynapseGateway-0.01-alt1.src.rpm<br />
perl-Synapse-CLI-Config-0.1-alt1.src.rpm<br />
perl-Synapse-Logger-0.1-alt1.src.rpm<br />
perl-Synapse-MailSender-1.4-alt1.src.rpm<br />
perl-Synapse-Monitor-Listener-0.3-alt1.src.rpm<br />
<br />
List for rosa2014c:<br />
synapse-0.2.10-2.src.rpm<br />
<br />
List for suse:<br />
synapse-0.2.10-10.1.6.src.rpm.mirrorlist<br />
<br />
List for suse-factory:<br />
synapse-0.2.99.1-1.2.src.rpm<br />
<br />
List for gitaltgears:<br />
/gears/s/synapse.git<br />
</pre><br />
<br />
=== 2. Качаем нужный src.rpm ===<br />
<br />
$ rpmgp -da Имя_пакета.src.rpm <br />
<br />
<pre><br />
$ rpmgp -da synapse-0.2.99.1-1.2.src.rpm<br />
--2015-10-05 21:08:01-- http://ftp5.gwdg.de/pub/opensuse/source/factory/repo/oss/suse/src//synapse-0.2.99.1-1.2.src.rpm<br />
Распознаётся ftp5.gwdg.de (ftp5.gwdg.de)… 134.76.12.5, 2001:638:60f:110::1:1<br />
Подключение к ftp5.gwdg.de (ftp5.gwdg.de)|134.76.12.5|:80... соединение установлено.<br />
HTTP-запрос отправлен. Ожидание ответа... 200 OK<br />
Длина: 440583 (430K) [application/x-rpm]<br />
Сохранение в: «synapse-0.2.99.1-1.2.src.rpm»<br />
<br />
100%[=====================================================================================>] 440 583 42,9KB/s за 9,9s <br />
<br />
2015-10-05 21:08:12 (43,6 KB/s) - «synapse-0.2.99.1-1.2.src.rpm» сохранён [440583/440583]<br />
<br />
<br />
List for suse-factory:<br />
synapse-0.2.99.1-1.2.src.rpm<br />
<br />
$ ls<br />
synapse-0.2.99.1-1.2.src.rpm<br />
</pre><br />
<br />
=== 3. Готовим gear-репозиторий ===<br />
<br />
$ gear-srpimport Имя_пакета.src.rpm <br />
<br />
<pre><br />
$ mkdir synapse<br />
$ cd synapse<br />
$ git init<br />
$ gear-srpmimport ../synapse-0.2.99.1-1.2.src.rpm<br />
</pre><br />
<br />
=== 4. Подгоняем spec под alt linux policy ===<br />
<br />
$ rpmcs<br />
<br />
Читаем об ошибках и исправляем их.<br />
<br />
Успешное завершение выглядит примерно так<br />
<br />
<pre><br />
$ rpmcs <br />
Using autodetected spec /home/users/wikitest/synapse/synapse.spec...<br />
предупреждение: Macro %suse_update_desktop_file not found<br />
cleanup_spec for /home/users/wikitest/synapse/synapse.spec.tmpspecbeforechangelog...<br />
исправляем название и релиз...<br />
предупреждение: Macro %suse_update_desktop_file not found<br />
fix obsoleted constructions...DONE<br />
fix build requires...<br />
предупреждение: Macro %suse_update_desktop_file not found<br />
fix package requires...<br />
предупреждение: Macro %suse_update_desktop_file not found<br />
fix groups...<br />
предупреждение: Macro %suse_update_desktop_file not found<br />
<br />
Total used replacement rules: <br />
Add changelog with initial build<br />
предупреждение: Macro %suse_update_desktop_file not found<br />
предупреждение: Macro %suse_update_desktop_file not found<br />
предупреждение: Macro %suse_update_desktop_file not found<br />
DONE<br />
</pre><br />
<br />
В данном примере макрос %suse_update_desktop_file всё таки нужно подправить( найти аналоги в alt или узнать во что раскрывается этот макрос в suse )<br />
<br />
=== 5. [[Собираем в Hasher]] ===<br />
<pre> <br />
$ rpmbsh<br />
</pre><br />
<br />
=== 6. [[Оправляем в Сизиф]] ===<br />
<pre><br />
$ ginit git.alt<br />
$ rpmbs git.alt -u<br />
</pre><br />
<br />
== Качаем исходники ==<br />
<br />
=== 1. Качаем исходники ===<br />
<br />
$ wget www.internet.net/Имя_пакета.{bz2,gzip,xz}<br />
<br />
=== 2. Создаём gear-репозиторий ===<br />
<pre><br />
$ mkdir -p synapse/.gear<br />
$ cd synapse<br />
$ git init<br />
$ touch .gear/rules<br />
$ gear-update -c ../synapse.tar.xz synapse<br />
</pre><br />
<br />
=== 3. Заполняем согласно Alt linux policy файл .gear/rules [[Руководство по gear]] ===<br />
<br />
=== 4. Пишем spec [[SampleSpecs]] ===<br />
<br />
=== 5. Фиксируем изменения в gear-репозитории ===<br />
<pre><br />
$ git add .<br />
$ gear-commit -a<br />
</pre><br />
=== 6. [[Собираем в Hasher]] ===<br />
<pre> <br />
$ rpmbsh<br />
</pre><br />
=== 7. [[Оправляем в Сизиф]] ===<br />
<pre><br />
$ ginit git.alt<br />
$ rpmbs git.alt -u<br />
</pre><br />
<br />
[[Категория: Новый пакет]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=SampleSpecs/empty&diff=68672SampleSpecs/empty2023-06-18T10:38:13Z<p>AntonFarygin: </p>
<hr />
<div>__FORCETOC__<br />
<br />
==Пример пустого спека==<br />
Подходит для разжатого тарбола с названием <tt>имя-версия.tar</tt>, содержащего каталог <tt>имя-версия/</tt>, штатно собирающегося {{cmd|./configure && make}} и устанавливающегося {{cmd|make install}}.<br />
<br />
Внимание: тэги с пустым значением (<tt>Patch:</tt>) приведены для пояснения порядка их следования; метаданные задаются в ASCII, пример с переводами см. в [[SampleSpecs/program]].<br />
<br />
<pre><br />
Name: <имя-пакета><br />
Version: <версия-пакета><br />
Release: alt<релиз-пакета><br />
<br />
Summary: <однострочное описание><br />
License: <лицензия><br />
Group: <группа><br />
<br />
Url: <URL><br />
Source: %name-%version.tar<br />
Patch:<br />
<br />
PreReq:<br />
Requires:<br />
Provides:<br />
Conflicts:<br />
<br />
BuildPreReq:<br />
BuildRequires:<br />
%{?!_without_test:%{?!_disable_test:%{?!_without_check:%{?!_disable_check:BuildRequires: }}}}<br />
BuildArch:<br />
<br />
%description<br />
<многострочное<br />
описание><br />
<br />
%prep<br />
%setup<br />
%patch1 -p1<br />
<br />
%build<br />
%configure<br />
%make_build<br />
<br />
%install<br />
%makeinstall_std<br />
<br />
%check<br />
%make_build check<br />
<br />
%files<br />
%_bindir/*<br />
%_man1dir/*<br />
%doc AUTHORS NEWS README<br />
<br />
%changelog<br />
* <дата> <ваше имя> <$login@altlinux.org> <версия_пакета>-<релиз_пакета><br />
- initial build for ALT Linux Sisyphus<br />
</pre><br />
<br />
===Примечания===<br />
<br />
====BuildRequires только для %check====<br />
О выражении <code>%{?!_without_test:%{?!_disable_test:%{?!_without_check:%{?!_disable_check:BuildRequires: }}}}</code> смотри [[Spec#BuildRequires только для %check]].<br />
<br />
{{Category navigation|title=SampleSpecs|category=SampleSpecs|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=SampleSpecs/apache2module&diff=68671SampleSpecs/apache2module2023-06-18T10:38:02Z<p>AntonFarygin: </p>
<hr />
<div><pre><br />
%define modname sample<br />
<br />
Name: apache2-mod_%modname<br />
Version: 0.0.1<br />
Release: alt1<br />
Epoch: ...<br />
<br />
Summary: ...<br />
License: ...<br />
Group: System/Servers<br />
<br />
Url: ...<br />
BuildArch: ...<br />
<br />
Source: mod_%modname-%version.tar<br />
Source1: %modname.load<br />
Source2: %modname.start<br />
Source3: %modname.conf<br />
Patch: ...<br />
<br />
PreReq: ...<br />
Requires: %apache2_name-base > 2.2.22-alt15<br />
Requires: %apache2_name-mmn = %apache2_mmn<br />
Requires: %apache2_libaprutil_name >= %apache2_libaprutil_evr<br />
Requires: %apache2_libapr_name >= %apache2_libapr_evr<br />
Provides: ...<br />
Conflicts: ...<br />
<br />
BuildRequires(pre): apache2-devel > 2.2.22-alt15<br />
BuildPreReq: ...<br />
BuildRequires: ...<br />
<br />
%description<br />
...<br />
<br />
%prep<br />
%setup -n mod_%modname-%version<br />
%patch0 -p1<br />
<br />
%build<br />
%apache2_apxs ... -c -Wc,-std=gnu99 mod_%modname.c<br />
<br />
%install<br />
install -pDm0644 .libs/mod_%modname.so %buildroot%apache2_moduledir/mod_%modname.so<br />
install -pDm0644 %SOURCE1 %buildroot%apache2_mods_available/%modname.load<br />
install -pDm0644 %SOURCE3 %buildroot%apache2_mods_available/%modname.conf<br />
install -pDm0644 %SOURCE2 %buildroot%apache2_mods_start/100-%modname.conf<br />
<br />
# for %%ghost<br />
mkdir -p %buildroot%apache2_mods_enabled/<br />
touch %buildroot%apache2_mods_enabled/%modname.load<br />
touch %buildroot%apache2_mods_enabled/%modname.conf<br />
<br />
%files<br />
%doc ...<br />
%config(noreplace) %apache2_mods_available/*.load<br />
%config(noreplace) %apache2_mods_available/*.conf<br />
%config(noreplace) %apache2_mods_start/*.conf<br />
%ghost %apache2_mods_enabled/*.load<br />
%ghost %apache2_mods_enabled/*.conf<br />
%apache2_moduledir/*<br />
<br />
%changelog<br />
...</pre><br />
<br />
[http://git.altlinux.org/people/solo/public/?p=specs.git;a=blob;f=sample.spec;h=065b3a9a5fa0a851f9f70ace8c2ebe05e7482665;hb=ALT/apache2/mod Шаблон спека на git.alt]<br />
<br />
{{Category navigation|title=SampleSpecs|category=SampleSpecs|sortkey={{SUBPAGENAME}}}}<br />
<br />
[[Категория:Apache2]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=SampleSpecs/texmf-latex&diff=68670SampleSpecs/texmf-latex2023-06-18T10:37:44Z<p>AntonFarygin: </p>
<hr />
<div>== Пример спека для модуля TEXMF (макропакет LaTeX) ==<br />
<br />
Подробнее см. [[TeXPolicy]]<br />
<br />
<pre><br />
%define srcName sample<br />
<br />
Name: texmf-latex-%srcName<br />
Version: 0.1<br />
Release: alt1<br />
Summary: Sample spec for texmf-latex module<br />
License: %lppl<br />
Group: Publishing<br />
Url: http://www.ctan.org/<br />
<br />
<br />
BuildArch: noarch<br />
<br />
BuildRequires(pre): rpm-build-texmf rpm-build-licenses<br />
BuildRequires: ctanify texlive-latex-base<br />
<br />
Source0: %srcName-%version.tar<br />
<br />
%description<br />
Long description here.<br />
CTAN package info page is a good source for description in English.<br />
<br />
%prep<br />
%setup -n %srcName-%version<br />
<br />
%build<br />
latex %srcName.ins<br />
latex %srcName.dtx<br />
latex %srcName.dtx<br />
<br />
%install<br />
mkdir -p %buildroot%_texmfmain<br />
# ctanify is not universal, but is a recommended way to create TEXMF file layouts <br />
# for packages. Adjustments may be necessary in some cases, see ctanify(1) for more info.<br />
ctanify --pkgname=%srcName --tdsdir=%buildroot/%_texmfmain *<br />
<br />
%files<br />
%_texmfmain/tex/latex/*<br />
%_texmfmain/doc/latex/*<br />
%_texmfmain/source/latex/*<br />
<br />
%changelog<br />
* Thu Jun 11 2009 Kirill Maslinsky <kirill@altlinux.ru> 0.1-alt1<br />
- initial revision<br />
<br />
</pre><br />
<br />
{{Category navigation|title=TeX|category=TeX}}<br />
{{Category navigation|title=SampleSpecs|category=SampleSpecs|sortkey=*}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=SampleSpecs/pecl&diff=68669SampleSpecs/pecl2023-06-18T10:37:06Z<p>AntonFarygin: </p>
<hr />
<div><pre><br />
%define php5_extension perl<br />
%define pecl_name perl<br />
<br />
Name: pecl-%pecl_name<br />
Version: 1.0.0<br />
Release: alt4<br />
<br />
Summary: Embedded Perl<br />
<br />
License: PHP<br />
Group: Development/Other<br />
Url: http://pecl.php.net/package/%pecl_name<br />
<br />
Source: http://pecl.php.net/get/%pecl_name-%version.tar<br />
<br />
BuildPreReq: rpm-build-pecl<br />
<br />
# Automatically added by buildreq on Sat Mar 01 2008<br />
BuildRequires: gcc-c++ perl-devel php5-devel<br />
<br />
%description<br />
This extension embeds Perl Interpreter into PHP. It allows execute<br />
Perl files, evaluate Perl code, access Perl variables and instantiate<br />
Perl objects.<br />
<br />
%prep<br />
%setup -c<br />
<br />
%build<br />
cd %pecl_name-%version<br />
phpize<br />
%pecl_configure '--with-php-config=%_bindir/php-config'<br />
%make_build<br />
<br />
# Disabled due disabled proc_open<br />
# make test<br />
<br />
%install<br />
%pecl_install<br />
%pecl_install_doc CREDITS EXPERIMENTAL README TODO<br />
<br />
%post<br />
%php5_extension_postin<br />
<br />
%preun<br />
%php5_extension_preun<br />
<br />
%files<br />
%pecl_files<br />
<br />
%changelog<br />
* Tue Mar 09 2010 Anton Farygin <rider@altlinux.ru> 1.0.0-alt4<br />
- Rebuild with php5-5.2.13.20100205-alt1<br />
<br />
</pre><br />
<br />
Update:<br />
PECL can also be installed using YUM/CentOS as mentioned in this tutorial: http://programmingbulls.com/pecl-install<br />
{{Category navigation|title=SampleSpecs|category=SampleSpecs|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=SampleSpecs/pearmodule&diff=68668SampleSpecs/pearmodule2023-06-18T10:36:57Z<p>AntonFarygin: </p>
<hr />
<div><pre>%define pear_name File<br />
<br />
Name: pear-File<br />
Version: 1.3.0<br />
Release: alt3<br />
<br />
Summary: Common file and directory routines, also CSV handling<br />
<br />
License: PHP<br />
Group: Development/Other<br />
Url: http://pear.php.net/package/%pear_name<br />
<br />
Source: http://pear.php.net/get/%pear_name-%version.tar.bz2<br />
<br />
BuildArchitectures: noarch<br />
<br />
Requires: pear-core<br />
BuildRequires: pear-core rpm-build-pear<br />
<br />
%description<br />
Provides easy access to read/write to files along with<br />
some common routines to deal with paths.<br />
<br />
Also provides interface for handling CSV files.<br />
<br />
%prep<br />
%setup -c<br />
%pear_build<br />
<br />
%install<br />
%pear_install_std<br />
<br />
%post<br />
%register_pear_module<br />
<br />
%preun<br />
%unregister_pear_module<br />
<br />
%files<br />
%doc LICENSE CHANGELOG<br />
%pear_dir/File/<br />
%pear_testdir/File/<br />
%pear_dir/File.php<br />
%pear_xmldir/%pear_name.xml<br />
<br />
%changelog<br />
* Fri Jan 04 2008 Vitaly Lipatov <lav@altlinux.org> 1.3.0-alt1<br />
- initial build for ALT Linux Sisyphus<br />
</pre><br />
<br />
<br />
{{Category navigation|title=SampleSpecs|category=SampleSpecs|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=SampleSpecs/cmakeprogram&diff=68667SampleSpecs/cmakeprogram2023-06-18T10:36:06Z<p>AntonFarygin: </p>
<hr />
<div><pre>Name: sampleprog<br />
Version: 1.0<br />
Release: alt1<br />
<br />
Summary: Sample program specfile<br />
License: GPLv2+<br />
Group: Development/Other<br />
<br />
Url: http://www.altlinux.org/SampleSpecs/cmakeprogram<br />
Source: %name-%version.tar.bz2<br />
<br />
BuildRequires(pre): cmake rpm-macros-cmake<br />
<br />
%description<br />
This specfile is provided as a sample specfile<br />
for a package built with cmake.<br />
<br />
%prep<br />
%setup<br />
<br />
%build<br />
%cmake_insource<br />
%make_build # VERBOSE=1<br />
<br />
%install<br />
%makeinstall_std<br />
%find_lang %name<br />
<br />
%files -f %name.lang<br />
%doc AUTHORS ChangeLog NEWS README THANKS TODO contrib/ manual/<br />
%_bindir/*<br />
%_man1dir/*<br />
<br />
%changelog<br />
* Sat Jan 33 3001 Example Packager <example@altlinux.org> 1.0-alt1<br />
- initial build</pre><br />
<br />
{{Category navigation|title=SampleSpecs|category=SampleSpecs|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=SampleSpecs/program&diff=68666SampleSpecs/program2023-06-18T10:35:54Z<p>AntonFarygin: </p>
<hr />
<div>''TODO: добавить файл .desktop''<br />
<br />
<pre><br />
Name: sampleprog<br />
Version: 1.0<br />
Release: alt1<br />
<br />
Summary: Sample program specfile<br />
Summary(ru_RU.UTF-8): Пример спек-файла для программы<br />
<br />
License: GPLv2+<br />
Group: Development/Other<br />
Url: http://www.altlinux.org/SampleSpecs/program<br />
<br />
Source: %name-%version.tar<br />
Patch0: %name-1.0-alt-makefile-fixes.patch<br />
<br />
%description<br />
This specfile is provided as sample specfile for packages with programs.<br />
It contains most of usual tags and constructions used in such specfiles.<br />
<br />
%description -l ru_RU.UTF-8<br />
Этот спек-файл является примером спек-файла для пакета с программой. Он содержит<br />
основные теги и конструкции, используемые в подобных спек-файлах.<br />
<br />
%prep<br />
%setup<br />
%patch0 -p1<br />
<br />
%build<br />
%configure<br />
%make_build<br />
<br />
%install<br />
%makeinstall_std<br />
%find_lang %name<br />
<br />
%files -f %name.lang<br />
%doc AUTHORS ChangeLog NEWS README THANKS TODO contrib/ manual/<br />
%_bindir/*<br />
%_man1dir/*<br />
<br />
%changelog<br />
* Sat Sep 33 3001 Sample Packager <sample@altlinux.org> 1.0-alt1<br />
- initial build</pre><br />
<br />
<br />
{{Category navigation|title=SampleSpecs|category=SampleSpecs|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=SampleSpecs/python3module&diff=68665SampleSpecs/python3module2023-06-18T10:35:41Z<p>AntonFarygin: </p>
<hr />
<div>''примечание: адаптировано mike@, который не питонист ни разу; проверьте/поправьте при надобности''<br />
<br />
''примечание: устарело согласно [[Python packaging guide]]''<br />
<br />
<pre><br />
%define modulename foo<br />
<br />
Name: python3-module-%modulename<br />
Version: 1.0<br />
Release: alt1<br />
<br />
Summary: ...<br />
License: GPLv3+<br />
Group: Development/Python3<br />
<br />
Url: http://...<br />
BuildArch: noarch<br />
Source: %name-%version.tar<br />
<br />
BuildRequires(pre): rpm-build-python3<br />
#BuildRequires(pre): rpm-macros-sphinx3<br />
<br />
# %%add_python3_req_skip ...<br />
<br />
%description<br />
...<br />
<br />
%prep<br />
%setup<br />
<br />
%build<br />
%python3_build<br />
<br />
%install<br />
%python3_install<br />
<br />
%files<br />
%python3_sitelibdir/%modulename/<br />
%python3_sitelibdir/*.egg-info</pre><br />
<br />
</pre><br />
<br />
{{Category navigation|title=SampleSpecs|category=SampleSpecs|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=ALT_Packaging_HOWTO&diff=68664ALT Packaging HOWTO2023-06-18T08:16:29Z<p>AntonFarygin: /* Порядок тэгов */</p>
<hr />
<div>[[Категория:Devel]]<br />
[[Категория:RPM spec]]<br />
<br />
== ALT Packaging HOWTO (revision 0.3) ==<br />
<br />
Dmitry V. Levin <ldv@altlinux.ru><br />
ALT Linux Team<br />
<br />
=== Введение ===<br />
<br />
При разработке изменений и дополнений к rpm решались следующие задачи:<br />
*Обеспечить желаемую функциональность:<br />
наши пакеты должны отвечать определенным правилам, о которых пойдет речь несколько позже. Для этого надо, чтобы ''spec''-файлы обеспечивали выполнение этих правил. <br />
*Помочь разработчику:<br />
так как ''spec''-файлы все еще пишут люди, то их работу нужно свести к тому минимуму, который, собственно, и требует участия человека. Разработчик не должен копировать блоки кода из файла в файл, ибо эта неинтеллектуальная работа отнимает массу сил и чревата ошибками. Для этого есть макросы. Если какой-то код появляется в разных ''spec''-файлах более одного раза, то надо написать макрос(ы). <br />
*Сделать ''spec''-файлы более читабельными:<br />
те, кто эти файлы читает - тоже живые люди. Им будет удобнее, если в наименовании, расположении и использовании различных элементов ''spec''-файлов будет определенный порядок. <br />
<br />
=== Особенности этой версии rpm ===<br />
<br />
==== Новые макросы ====<br />
<br />
'''Макросы для часто используемых каталогов'''<br />
<br />
*<s>X11R6: {{rpmmacro|_x11dir}}, {{rpmmacro|_x11bindir}}, {{rpmmacro|_x11libdir}}, {{rpmmacro|_x11includedir}}, {{rpmmacro|_x11mandir}}, {{rpmmacro|_x11datadir}}</s><br>''NB: устарели с X11R7, используем {{rpmmacro|_bindir}} и прочие без x11''<br />
<br />
*лицензии: {{rpmmacro|_licensedir}} <br />
<br />
*меню: <s>{{rpmmacro|_menudir}}</s>, {{rpmmacro|_iconsdir}}, {{rpmmacro|_miconsdir}}, {{rpmmacro|_liconsdir}}<br />
<br />
*emacs: {{rpmmacro|_emacslispdir}}<br />
<br />
*другие системные: {{rpmmacro|_initddir}} ({{rpmmacro|_initir}} и {{rpmmacro|_initrddir}} [https://bugzilla.altlinux.org/show_bug.cgi?id=24290 объявлены устаревшими]), {{rpmmacro|_lockdir}}, {{rpmmacro|_logdir}}. <br />
<br />
'''Управление опциями компилятора gcc'''<br />
<br />
{{rpmmacro|add_optflags}} <options>: добавить указанные параметры в стандартный набор {{rpmmacro|_%opflags}}<br />
<br />
{{rpmmacro|remove_optflags}} <options>: убрать указанные параметры из стандартного набора {{rpmmacro|_%opflags}}<br />
<br />
{{rpmmacro|optflags_core}}: базовые параметры<br />
<br />
{{rpmmacro|__optlevel}}: уровень оптимизации<br />
<br />
{{rpmmacro|optflags_optimization}}: параметры, отвечающие за оптимизацию, кроме архитектурно-зависимых<br />
<br />
{{rpmmacro|optflags_warnings}}: ''warning options''<br />
<br />
{{rpmmacro|optflags_debug}}: ''debugging options''<br />
<br />
{{rpmmacro|optflags_shared}}: параметры, применяемые для создания relocatable файлов<br />
<br />
{{rpmmacro|optflags_nocpp}}: параметры, отключающие поддержку C++ exceptions и C++ RTTI<br />
<br />
{{rpmmacro|optflags_notraceback}}: ''-fomit-frame-pointer''<br />
<br />
{{rpmmacro|optflags_fastmath}}: ''-ffast-math''<br />
<br />
{{rpmmacro|optflags_strict}}: ''-fstrict-aliasing''<br />
<br />
{{rpmmacro|optflags_kernel}}: параметры, используемые при компиляции ядра и его модулей.<br />
<br />
По умолчанию, стандартный набор {{rpmmacro|optflags}} состоит из "{{rpmmacro|optflags_core}} {{rpmmacro|optflags_warnings}} {{rpmmacro|optflags_optimization}}".<br />
<br />
'''Макросы-надстройки над утилитой make'''<br />
<br />
{{rpmmacro|make_build}}: вызов make с параметром, обеспечивающим оптимальную параллельную сборку в данной среде<br />
<br />
{{rpmmacro|make_install}}: вызов make c инициализацией переменной INSTALL, что в случае корректной реализации Makefile'ов пакета позволяет сохранить дату последней модификации файлов, что особенно важно для документации;<br />
<br />
{{rpmmacro|makeinstall}}: make <инициализация других переменных, используемых многими Makefile'ами> install. Переопределяет все пути, куда устанавливаются файлы, добавляя к ним buildroot (используется для неправильных установочных скриптов, в которых забыто DESTDIR);<br />
<br />
{{rpmmacro|makeinstall_std}}: выполняет %make_install install DESTDIR=%buildroot, нужное для установки программы, собранной через autotools;<br />
<br />
<s>'''Регистрация документации в формате info''</s><br />
<br />
<s>{{rpmmacro|install_info}}: регистрация новых/обновленных ''info''-страниц.</s><br />
<br />
<s>{{rpmmacro|uninstall_info}}: отмена регистрации удаленных ''info''-страниц.</s><br />
<br />
''Устарело с появлением filetriggers''<br />
<br />
<s>'''Регистрация меню'''</s><br />
<br />
<s>{{rpmmacro|update_menus}}: регистрация новых/обновленных меню.</s><br />
<br />
<s>{{rpmmacro|clean_menus}}: отмена регистрации удаленных меню.</s><br />
<br />
''Устарело с появлением filetriggers''<br />
<br />
'''Вспомогательные макросы %configure'''<br />
<br />
{{rpmmacro|__libtoolize}}: путь к скрипту ''libtoolize''<br />
<br />
{{rpmmacro|_configure_script}}: путь к скрипту ''configure''<br />
<br />
{{rpmmacro|_configure_target}}: целевая платформа для ''configure''<br />
<br />
{{rpmmacro|_configure_gettext}}: ''-without-included-gettext''. <br />
<br />
'''Серверные макросы'''<br />
<br />
{{rpmmacro|post_service}}: регистрация нового сервиса при установке, перезапуск при обновлении<ref>НИКОГДА не используйте {{rpmmacro|post_service}} для<br />
перезапуска сторонних сервисов. ([http://lists.altlinux.org/pipermail/devel/2010-September/184624.html raorn@])<pre>/sbin/service %apache2_dname condreload|condrestart ||:</pre></ref><ref>%post_service предназначен для<br />
* регистрации сервиса при первой установке пакета;<br />
* перезапуске сервиса при обновлении пакета.<br />
Запускать сервис автоматически сразу при первой установке пакета не положено. ([http://lists.altlinux.org/pipermail/devel/2010-September/184646.html ldv@])</ref><br />
<br />
{{rpmmacro|preun_service}}: отмена регистрации сервиса и его выключение при удалении. <br />
<br />
'''Макросы, определяющие некоторые аспекты packaging policy'''<br />
<br />
{{rpmmacro|buildroot}}: значение ''BuildRoot''<br />
<br />
{{rpmmacro|_defattr}}: атрибуты файлов и каталогов по умолчанию для каждой секции ''%files'' и для каждого файла, включаемого в этих секциях<br />
<br />
{{rpmmacro|_compress_method}}: метод, используемый при сжатии документации в секции ''%install''<br />
<br />
{{rpmmacro|_strip_method}}: метод, используемый при обработке ELF-файлов в секции ''%install'' (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|findreq_default_method}}: метод, используемый по умолчанию при поиске требуемых зависимостей <br />
<br />
{{rpmmacro|findprov_default_method}}: метод, используемый по умолчанию при поиске предоставляемых зависимостей<br />
<br />
{{rpmmacro|set_strip_method}}: изменить значение макроса ''%_strip_method'' (макрос удален с версии rpm-4.0.4-alt100.36, вместо него с параметром ''none'' пользуйтесь {{rpmmacro|brp_strip_none}})<br />
<br />
'''Вызов вспомогательных программ'''<br />
<br />
{{rpmmacro|find_lang}}: вызов ''/usr/lib/rpm/find-lang''<br />
<br />
{{rpmmacro|strip_executable}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF executables (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|strip_relocatable}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF relocatables (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|strip_shared}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF shared objects (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|strip_static}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF ar archives (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|cleanup_build}}: вызов ''/usr/lib/rpm/brp-cleanup''<br />
<br />
{{rpmmacro|compress_docs}}: вызов ''/usr/lib/rpm/brp-compress'' <br />
<br />
{{rpmmacro|strip_binaries}}: вызов ''/usr/lib/rpm/brp-strip'' (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|clean_buildroot}}: выполнение ''rm -rf %buildroot'', если ''%buildroot'' не указывает на настоящий ''/''. <br />
<br />
'''Управление процессом сборки'''<br />
<br />
{{rpmmacro|buildmulti}}: Альтернативная директива ''%build'' для случая, когда в секции ''%build'' происходит заполнение ''%buildroot''. Вообще говоря, такой техники стоит избегать во всех случаях, когда это возможно. <br />
<br />
'''Версии некоторых установленных в системе пакетов'''<br />
<br />
'''glibc''': {{rpmmacro|__glibc_version}}, {{rpmmacro|__glibc_version_major}}, {{rpmmacro|__glibc_version_minor}} <br />
<br />
'''python''': {{rpmmacro|__python_version}} <br />
<br />
{{rpmmacro|get_version}}: Версия указанного пакета <br />
<br />
{{rpmmacro|get_release}}: Релиз указанного пакета<br />
<br />
{{rpmmacro|get_serial}}: Serial указанного пакета<br />
<br />
{{rpmmacro|add_serial}}: Serial указанного пакета в виде, пригодном для включения в ''spec''-файл. <br />
<br />
Эти макросы, как правило, используются в пакетах, сборка которых возможна с различными версиями этих программ, если эти версии правильно учитывать.<br />
<br />
'''Прочие макросы'''<br />
<br />
{{rpmmacro|intel}}: список архитектур ''intel'', совместимых с ''i386''<br />
<br />
{{rpmmacro|amd}}: список архитектур ''amd'', совместимых с ''i386''<br />
<br />
{{rpmmacro|ix86}}: список всех архитектур, совместимых с ''i386''<br />
<br />
компоненты макроса {{rpmmacro|packager}}: {{rpmmacro|packagerName}}, {{rpmmacro|packagerAddress}}.<br />
<br />
==== Новыe параметры rpm ====<br />
<br />
-'''bE''': новый режим работы ''rpm'', при котором происходит только подстановка макросов<br />
<br />
-'''nowait-lock''': не блокировать процесс, если база данных ''rpm'' занята <br />
<br />
-'''fancypercent''': отображать дополнительную информацию о процентах проделанной работы при установке/обновлении пакетов. <br />
<br />
==== Новые возможности rpm ====<br />
<br />
'''Автоматический поиск требуемых и предоставляемых зависимостей'''<br />
<br />
В дополнение к стандартному поиску зависимостей от/для разделяемых библиотек, реализована поддержка поиска требуемых зависимостей для ''shell'' и ''perl''-скриптов, а также поддержка поиска предоставляемых зависимостей для ''perl''-скриптов. (См. также [[rpm/AutoReq]].)<br />
<br />
'''Изменение семантики тэгов, управляющих поиском зависимостей'''<br />
<br />
Новые возможности ''rpm'' по автоматическому поиску зависимостей при сборке пакетов управляются, как и прежде, значениями тэгов ''AutoReq'', ''AutoProv'' и ''AutoReqProv''. К стандартным значениям ''yes/no'' (''true/false''), таким образом, добавлены новые возможные значения, являющиеся именами методов поиска зависимостей:<br />
<br />
*''lib'': включение поиска зависимостей от/для разделяемых библиотек<br />
*''shell'': включение поиска зависимостей в ''shell''-скриптах<br />
*''perl'': включение поиска зависимостей в ''perl''-скриптах<br />
*''nolib'': выключение поиска зависимостей от/для разделяемых библиотек<br />
*''noshell'': выключение поиска зависимостей в ''shell''-скриптах<br />
*''noperl'': выключение поиска зависимостей в ''perl''-скриптах<br />
*''default'': то же, что и ''yes'';<br />
*''none,off'': то же, что и ''no'';<br />
*''all'': включение всех возможных методов поиска зависимостей.<br />
<br />
Значением тэга может являться как один метод, так и перечисление методов. По умолчанию, для каждого под пакета собираемого пакета ''AutoReq'' = ''AutoProv'' = ''yes'', что на практике означает использование макросов <br />
{{rpmmacro|findreq_default_method}} и {{rpmmacro|findprov_default_method}} для определения методов поиска зависимостей.<br />
<br />
'''Автоматическое сжатие ''man'' и ''info''-документации с поддержкой различных методов сжатия'''<br />
<br />
Вся документация пакета, распознаваемая как ''man'' или ''info''-документация, по окончании работы секции ''%install'', сжимается согласно выбранному методу. Поддерживаются следующие методы сжатия:<br />
<br />
*''bzip2'': сжатие с помощью ''bzip2 -9''<br />
*''gzip'': сжатие с помощью ''gzip -9n''<br />
*''auto'': сжатие с помощью ''gzip -9n'' либо ''bzip2 -9'' в зависимости от того, какой вариант окажется эффективнее<br />
*''none'': производится декомпрессия файлов вместо сжатия<br />
*''skip'': процедура сжатия пропускается полностью.<br />
<br />
Какой метод будет использован в каждом конкретном случае, зависит от значения макроса {{rpmmacro|_compress_method}}; значение по умолчанию для этого макроса - ''auto''. По окончании процедуры сжатия производится выравнивание ссылок, которые, возможно, требуют коррекции в связи с изменениями имен файлов в процессе их сжатия.<br />
<br />
'''Автоматическое удаление отладочной информации из ELF-файлов с поддержкой различных стратегий выбора файлов, подлежащих обработке'''<br />
<br />
''Начиная с версии rpm-4.0.4-alt100.36 этот раздел устарел, brp-strip удален и вместо него используется brp-debuginfo (%_brp_strip_{debug,none}). <ref>http://lists.altlinux.org/pipermail/devel/2011-January/187944.html</ref><ref>http://lists.altlinux.org/pipermail/devel/2011-February/188021.html</ref>''<br />
<br />
Зачастую возможно уменьшить размер получаемых в результате сборки пакета ELF-файлов без потери качества за счет удаления из них отладочной информации. Поэтому по окончании работы секции ''%install'' все ELF-файлы выбранных типов обрабатываются программой ''strip''. Выбор типов файлов определяется значением макроса {{rpmmacro|_strip_method}}, которое есть набор из следующих возможных значений:<br />
<br />
*''executable'': ELF executable;<br />
*''relocatable'': ELF relocatable;<br />
*''shared'': ELF shared object;<br />
*''static'': ar archive.<br />
<br />
Кроме того, есть возможность вызывать ''strip'' вручную, для этой цели предназначены макросы {{rpmmacro|strip_executable}}, {{rpmmacro|strip_relocatable}}, {{rpmmacro|strip_shared}}, {{rpmmacro|strip_static}}. Синтаксис этих макросов подробно изложен в ''/usr/lib/rpm/brp-strip -help''.<br />
<br />
'''Автоматическая перекомпиляция python-модулей'''<br />
<br />
Как известно, python-модули обычно компилируют в байтовую форму для увеличения быстродействия при последующей работе с ними. Каждый такой модуль, помимо всего прочего, хранит время своего создания и полное имя файла, в котором должен находиться. В связи с последним обстоятельством скомпилированные модули, созданные в результате работы секции ''%install'', непригодны, ибо не могут быть использованы после установки пакета. По этой причине теперь по окончании работы секции ''%install'' производится перекомпиляция всех python-модулей таким образом, чтобы их можно было использовать после установки пакета. В качестве байт-компилятора будет использоваться программа, имя которой хранится в макросе {{rpmmacro|__python}}. Обычно это ''/usr/bin/python'', однако в некоторых случаях может потребоваться изменить это значение на другое (например, в случае сборки пакета python или если по какой-то причине перекомпиляция не нужна).<br />
<br />
'''BuildRoot'''<br />
<br />
Времена, когда тэг ''BuildRoot'' в ''spec''-файле определял, какой каталог ''rpm'' будет использовать в качестве ''BuildRoot'', прошли безвозвратно. Теперь этот таг не несет никакой информации и может (и должен) быть опущен. Вместо этого используется значение макроса {{rpmmacro|buildroot}}, который определен как ''%{_tmppath}/%{name}-buildroot'' в файле ''/usr/lib/rpm/macros'' и может быть переопределен в любом месте, где допускается определять макросы. В случае, если макрос {{rpmmacro|buildroot}} не определен либо его значение представляет собой недопустимое значение ''/'', сборка пакета не будет выполнена.<br />
<br />
'''Автоматическая очистка BuildRoot'''<br />
<br />
Перед выполнением секции ''%install'' и по окончании выполнения секции ''%clean'' ''rpm'' автоматически очищает ''BuildRoot'' с помощью макроса {{rpmmacro|clean_buildroot}}. Это значит, что больше не нужно использовать эти ужасные ''rm -rf $RPM_BUILD_ROOT''. Секция ''%clean'' вообще может (и должна) быть опущена, если в ней не содержится ничего, кроме этого ''rm''. В тех редких случаях, когда в ''spec''-файле производится заполнение ''BuildRoot'' не в секции ''%install'', как это должно быть, а в секции ''%build'', что в принципе неправильно, можно перенести точку очистки ''BuildRoot'' из начала секции ''%install'' в начало секции ''%build'', если заменить директиву ''%build'' на макрос {{rpmmacro|buildmulti}}.<br />
<br />
'''Упрощение секции %files'''<br />
<br />
Ранее в начале каждой секции %files было необходимо указывать атрибуты файлов и каталогов создаваемых пакетов с помощью довольно однообразно используемой директивы %defattr. Теперь это происходит автоматически в начале каждой секции %files, а также в начале каждого файла, включаемого в секцию %files с помощью опции -f. Точнее говоря, в качестве этой директивы используется значение макроса %_defattr. Таким образом, прежнее использование директивы %defattr в начале секций и файлов следует считать упраздненным.<br />
<br />
'''Сборка пакетов привилегированным пользователем'''<br />
<br />
То, что когда-то было необходимостью, со временем стало излишним, а порой и просто опасным. Теперь, когда все пакеты, кроме одного-единственного MAKEDEV, можно (и нужно) собирать непривилегированным пользователем во избежание риска разрушения системы и некорректной сборки, сборка пакетов привилегированным пользователем по умолчанию запрещена. Этот запрет можно снять путем изменения значения макроса {{rpmmacro|_allow_root_build}}.<br />
<br />
=== Пожелания packager'у ===<br />
<br />
==== Устаревшие конструкции ====<br />
<br />
Не следует использовать устаревшие конструкции - они лишь загромождают ''spec''-файл, снижая тем самым его читабельность. К устаревшим конструкциям, в частности, относятся:<br />
* тэг ''BuildRoot:'' (BuildRoot выбирается автоматически);<br />
* тэг ''Packager:'' (Packager заполняется автоматически);<br />
* cтроки вида ''rm -rf $RPM_BUILD_ROOT'' (BuildRoot очищается автоматически);<br />
* {{rpmmacro|_defattr}} со стандартными аргументами в начале файлов и секций ''%files'' (такое поведение действует по умолчанию);<br />
* секция ''%clean'', пустая либо без разумного содержания.<br />
<br />
==== Фигурные скобки ====<br />
<br />
Нет смысла засорять текст spec-файла ненужными фигурными скобками. Избавится от них легко:<br />
<br />
''perl -pi -e 's/%\{([A-Za-z_0-9]+)\}([^A-Za-z_0-9?*]|$)/%$1$2/g' spec''-файл<br />
<br />
Или с помощью утилиты ''cleanup_spec'' из пакета ''rpm-utils''.<br />
<br />
==== Выравнивание ====<br />
<br />
Используйте табуляции для выравнивания. Избегайте пробельных символов в конце строк.<br />
<br />
==== Значения тэгов ====<br />
<br />
Значение тэга от его имени следует разделять одним пробелом. Элементы списка значений следует разделять запятой с последующим пробелом. Значение тэга Summary следует начинать с прописной буквы и не следует завершать точкой. Значения тэга ''Summary'' и секции ''%description'' могут содержать названия команд только в не изменённом виде.<br />
<br />
==== Порядок тэгов ====<br />
<br />
Рекомендуемый порядок заголовочных тэгов: <br />
*Name<br />
*Version<br />
*Release<br />
*Epoch или Serial<br />
<br />
далее<br />
<br />
*Summary<br />
*License<br />
*Group<br />
*Url<br />
*Packager (устарело, использование не рекомендовано)<br />
*BuildArch<br />
<br />
далее<br />
<br />
*Provides<br />
*Requires<br />
*PreReqs<br />
*Conflicts<br />
<br />
потом (влияющие на процесс сборки, но не то, как пакет выглядит снаружи)<br />
<br />
*Source<br />
*Patch<br />
<br />
и, наконец,<br />
<br />
*Prefix<br />
*BuildPreReqs<br />
*BuildRequires.<br />
<br />
Разумеется, не все из вышеперечисленных тэгов, как правило, используются, равно как встречаются и другие редко используемые тэги. В связи с тем, что ''BuildRequires'' зарезервирован для автоматически вычисляемых зависимостей, для указания особых зависимостей следует использовать ''BuildPreReq''.<br />
<br />
==== Файлы локализации ====<br />
<br />
Если в состав пакета входят файлы локализации либо другие файлы на разных языках, стоит использовать макрос {{rpmmacro|find_lang}}. Подробная информация есть в ''/usr/lib/rpm/find-lang -h''<br />
<br />
==== Группы ====<br />
<br />
Следите за значением тэгов ''Group'': они должны соответствовать действительности и при этом принадлежать фиксированному множеству, перечисленному в файле ''/usr/lib/rpm/GROUPS''.<br />
<br />
==== ChangeLog ====<br />
{{Main|Руководство по написанию changelog}}<br />
Для формирования первой строки changelog-записи удобно использовать утилиту ''[[add_changelog]]'' из пакета ''rpm-utils''.<br />
<br />
==== Внутрипакетные зависимости ====<br />
<br />
При работе с мультипакетными spec-файлами соблюдайте правило внутрипакетных зависимостей: Если один пакет в какой-либо мере зависит от другого подпакета, то эта зависимость должна быть указана полностью, включая не только имя, но также верcию, релиз и serial (если есть). Например, ''Requires: %name = %version-%release'' или Requires: %name = %epoch:%version-%release. Обратите внимание на синтаксис: знак равенства, в отличие от дефиса, окружен пробелами.<br />
<br />
==== Разделяемые библиотеки ====<br />
<br />
Пакеты, содержащие как разделяемые библиотеки, так и использующие их программы, должны быть разделены на подпакеты таким образом, чтобы в подпакет, содержащий разделяемые библиотеки, не входили использующие их программы. Это позволит уменьшить количество циклических зависимостей. По традиции, имена пакетов, состоящих только из разделяемых библиотек, должны начинаться с префикса ''lib'' либо содержать его внутри слова. При разделении подпакетов следует помнить о внутрипакетных зависимостях.<br />
<br />
==== Статические библиотеки ====<br />
<br />
Статические библиотеки должны паковаться в отдельные подпакеты, что связано со спецификой их использования. Если имя ''devel''-подпакета заканчивается суффиксом ''-devel'', то имя нового ''devel-static''-подпакета будет заканчиваться суффиксом ''-devel-static''. При разделении подпакетов следует помнить о внутрипакетных зависимостях: В списке зависимостей ''devel-static''-подпакета должна присутствовать зависимость от ''-devel = %version-%release''.<br />
<br />
==== Переименование пакетов ====<br />
<br />
Иногда пакеты переименовывают. Например, это случается при упаковке разделяемых библиотек. В таких случаях следует указывать правильную информацию о зависимостях, необходимую для корректного обновления. В частности, должен присутствовать:<br />
тэг ''Provides: старое_имя = %version''<br />
тэг ''Obsoletes: старое_имя''<br />
<br />
(Примечание: [[Реагирует ли сборочница на переименование пакетов]].)<br />
<br />
==== Наименование патчей ====<br />
<br />
При создании новых патчей, а также при импортировании патчей из других источников необходимо придерживаться единых правил наименования имён патч-файлов: NAME-VERSION-ORIGIN-WHAT.patch, где <br />
<br />
* NAME и VERSION — имя и версия пакета, для которого сделан патч; <br />
* ORIGIN — аббревиатуры источников патча (обычно дистрибутивов); <br />
* WHAT — краткое описание патча. <br />
<br />
В случае, когда патч образован из нескольких частей, полученных из разных источников, компонента имени ORIGIN должна содержать аббревиатуры всех источников. Если патч был создан или адаптирован для ALT Linux, то в ORIGIN, соответственно, должно присутствовать -alt-. Для патчей, созданных на базе CVS, компонента имени ORIGIN должна начинаться с cvs-YYYYMMDD. <br />
<br />
При составлении описания патча следует иметь в виду следующие общепринятые сокращения: <br />
* makefile - патчи, затрагивающие исключительно makefile*; <br />
* bound - проверки на границы (буфера, целых чисел, и т.п.);<br />
* config - патчи, затрагивающие исключительно конфигурационные файлы;<br />
* configure - патчи, затрагивающие исключительно configure*; <br />
* doc - патчи, затрагивающие исключительно документацию;<br />
* fixes - кумулятивные патчи и/или исправления по надёжности и/или безопасности;<br />
* format - патчи на использование форматирования строк (printf); <br />
* install - патчи, направленные на возможность выполнения make install непривилегированным пользователем; <br />
* linux - патчи, предназначенные для портирования ПО на Linux;<br />
* man - патчи, затрагивающие исключительно man-страницы; <br />
* texinfo - патчи, затрагивающие исключительно документацию в формате texinfo;<br />
* tmp - патчи, предназначенные для решения различных вопросов, связанных с временными файлами;<br />
* vitmp - патчи, направленные на поддержку vitmp(1); <br />
* warnings - патчи, исправляющие ошибки, найденные компилятором.<br />
<br />
== Литература ==<br />
<br />
*[http://www.rpm.org/ Официальный web-сайт rpm]<br />
*[http://lists.rpm.org/mailman/listinfo/rpm-list Список рассылки для разработчиков rpm 4.x]<br />
*[http://www.rpm.org/max-rpm-snapshot/index.html Maximum RPM], Edward C. Bailey February 17, 1997. (снэпшот книги)<br />
<br />
== Примечания ==<br />
* исходная версия этого документа доступна [http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/doc/ здесь] или [http://docs.altlinux.org/archive/2.4/master/alt-docs-devel/ch04.html в документации Master 2.4]<br />
<references /><br />
{{Category navigation|title=Сборка пакетов|category=Сборка пакетов|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=ALT_Packaging_HOWTO&diff=68663ALT Packaging HOWTO2023-06-18T08:16:01Z<p>AntonFarygin: /* Устаревшие конструкции */</p>
<hr />
<div>[[Категория:Devel]]<br />
[[Категория:RPM spec]]<br />
<br />
== ALT Packaging HOWTO (revision 0.3) ==<br />
<br />
Dmitry V. Levin <ldv@altlinux.ru><br />
ALT Linux Team<br />
<br />
=== Введение ===<br />
<br />
При разработке изменений и дополнений к rpm решались следующие задачи:<br />
*Обеспечить желаемую функциональность:<br />
наши пакеты должны отвечать определенным правилам, о которых пойдет речь несколько позже. Для этого надо, чтобы ''spec''-файлы обеспечивали выполнение этих правил. <br />
*Помочь разработчику:<br />
так как ''spec''-файлы все еще пишут люди, то их работу нужно свести к тому минимуму, который, собственно, и требует участия человека. Разработчик не должен копировать блоки кода из файла в файл, ибо эта неинтеллектуальная работа отнимает массу сил и чревата ошибками. Для этого есть макросы. Если какой-то код появляется в разных ''spec''-файлах более одного раза, то надо написать макрос(ы). <br />
*Сделать ''spec''-файлы более читабельными:<br />
те, кто эти файлы читает - тоже живые люди. Им будет удобнее, если в наименовании, расположении и использовании различных элементов ''spec''-файлов будет определенный порядок. <br />
<br />
=== Особенности этой версии rpm ===<br />
<br />
==== Новые макросы ====<br />
<br />
'''Макросы для часто используемых каталогов'''<br />
<br />
*<s>X11R6: {{rpmmacro|_x11dir}}, {{rpmmacro|_x11bindir}}, {{rpmmacro|_x11libdir}}, {{rpmmacro|_x11includedir}}, {{rpmmacro|_x11mandir}}, {{rpmmacro|_x11datadir}}</s><br>''NB: устарели с X11R7, используем {{rpmmacro|_bindir}} и прочие без x11''<br />
<br />
*лицензии: {{rpmmacro|_licensedir}} <br />
<br />
*меню: <s>{{rpmmacro|_menudir}}</s>, {{rpmmacro|_iconsdir}}, {{rpmmacro|_miconsdir}}, {{rpmmacro|_liconsdir}}<br />
<br />
*emacs: {{rpmmacro|_emacslispdir}}<br />
<br />
*другие системные: {{rpmmacro|_initddir}} ({{rpmmacro|_initir}} и {{rpmmacro|_initrddir}} [https://bugzilla.altlinux.org/show_bug.cgi?id=24290 объявлены устаревшими]), {{rpmmacro|_lockdir}}, {{rpmmacro|_logdir}}. <br />
<br />
'''Управление опциями компилятора gcc'''<br />
<br />
{{rpmmacro|add_optflags}} <options>: добавить указанные параметры в стандартный набор {{rpmmacro|_%opflags}}<br />
<br />
{{rpmmacro|remove_optflags}} <options>: убрать указанные параметры из стандартного набора {{rpmmacro|_%opflags}}<br />
<br />
{{rpmmacro|optflags_core}}: базовые параметры<br />
<br />
{{rpmmacro|__optlevel}}: уровень оптимизации<br />
<br />
{{rpmmacro|optflags_optimization}}: параметры, отвечающие за оптимизацию, кроме архитектурно-зависимых<br />
<br />
{{rpmmacro|optflags_warnings}}: ''warning options''<br />
<br />
{{rpmmacro|optflags_debug}}: ''debugging options''<br />
<br />
{{rpmmacro|optflags_shared}}: параметры, применяемые для создания relocatable файлов<br />
<br />
{{rpmmacro|optflags_nocpp}}: параметры, отключающие поддержку C++ exceptions и C++ RTTI<br />
<br />
{{rpmmacro|optflags_notraceback}}: ''-fomit-frame-pointer''<br />
<br />
{{rpmmacro|optflags_fastmath}}: ''-ffast-math''<br />
<br />
{{rpmmacro|optflags_strict}}: ''-fstrict-aliasing''<br />
<br />
{{rpmmacro|optflags_kernel}}: параметры, используемые при компиляции ядра и его модулей.<br />
<br />
По умолчанию, стандартный набор {{rpmmacro|optflags}} состоит из "{{rpmmacro|optflags_core}} {{rpmmacro|optflags_warnings}} {{rpmmacro|optflags_optimization}}".<br />
<br />
'''Макросы-надстройки над утилитой make'''<br />
<br />
{{rpmmacro|make_build}}: вызов make с параметром, обеспечивающим оптимальную параллельную сборку в данной среде<br />
<br />
{{rpmmacro|make_install}}: вызов make c инициализацией переменной INSTALL, что в случае корректной реализации Makefile'ов пакета позволяет сохранить дату последней модификации файлов, что особенно важно для документации;<br />
<br />
{{rpmmacro|makeinstall}}: make <инициализация других переменных, используемых многими Makefile'ами> install. Переопределяет все пути, куда устанавливаются файлы, добавляя к ним buildroot (используется для неправильных установочных скриптов, в которых забыто DESTDIR);<br />
<br />
{{rpmmacro|makeinstall_std}}: выполняет %make_install install DESTDIR=%buildroot, нужное для установки программы, собранной через autotools;<br />
<br />
<s>'''Регистрация документации в формате info''</s><br />
<br />
<s>{{rpmmacro|install_info}}: регистрация новых/обновленных ''info''-страниц.</s><br />
<br />
<s>{{rpmmacro|uninstall_info}}: отмена регистрации удаленных ''info''-страниц.</s><br />
<br />
''Устарело с появлением filetriggers''<br />
<br />
<s>'''Регистрация меню'''</s><br />
<br />
<s>{{rpmmacro|update_menus}}: регистрация новых/обновленных меню.</s><br />
<br />
<s>{{rpmmacro|clean_menus}}: отмена регистрации удаленных меню.</s><br />
<br />
''Устарело с появлением filetriggers''<br />
<br />
'''Вспомогательные макросы %configure'''<br />
<br />
{{rpmmacro|__libtoolize}}: путь к скрипту ''libtoolize''<br />
<br />
{{rpmmacro|_configure_script}}: путь к скрипту ''configure''<br />
<br />
{{rpmmacro|_configure_target}}: целевая платформа для ''configure''<br />
<br />
{{rpmmacro|_configure_gettext}}: ''-without-included-gettext''. <br />
<br />
'''Серверные макросы'''<br />
<br />
{{rpmmacro|post_service}}: регистрация нового сервиса при установке, перезапуск при обновлении<ref>НИКОГДА не используйте {{rpmmacro|post_service}} для<br />
перезапуска сторонних сервисов. ([http://lists.altlinux.org/pipermail/devel/2010-September/184624.html raorn@])<pre>/sbin/service %apache2_dname condreload|condrestart ||:</pre></ref><ref>%post_service предназначен для<br />
* регистрации сервиса при первой установке пакета;<br />
* перезапуске сервиса при обновлении пакета.<br />
Запускать сервис автоматически сразу при первой установке пакета не положено. ([http://lists.altlinux.org/pipermail/devel/2010-September/184646.html ldv@])</ref><br />
<br />
{{rpmmacro|preun_service}}: отмена регистрации сервиса и его выключение при удалении. <br />
<br />
'''Макросы, определяющие некоторые аспекты packaging policy'''<br />
<br />
{{rpmmacro|buildroot}}: значение ''BuildRoot''<br />
<br />
{{rpmmacro|_defattr}}: атрибуты файлов и каталогов по умолчанию для каждой секции ''%files'' и для каждого файла, включаемого в этих секциях<br />
<br />
{{rpmmacro|_compress_method}}: метод, используемый при сжатии документации в секции ''%install''<br />
<br />
{{rpmmacro|_strip_method}}: метод, используемый при обработке ELF-файлов в секции ''%install'' (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|findreq_default_method}}: метод, используемый по умолчанию при поиске требуемых зависимостей <br />
<br />
{{rpmmacro|findprov_default_method}}: метод, используемый по умолчанию при поиске предоставляемых зависимостей<br />
<br />
{{rpmmacro|set_strip_method}}: изменить значение макроса ''%_strip_method'' (макрос удален с версии rpm-4.0.4-alt100.36, вместо него с параметром ''none'' пользуйтесь {{rpmmacro|brp_strip_none}})<br />
<br />
'''Вызов вспомогательных программ'''<br />
<br />
{{rpmmacro|find_lang}}: вызов ''/usr/lib/rpm/find-lang''<br />
<br />
{{rpmmacro|strip_executable}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF executables (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|strip_relocatable}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF relocatables (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|strip_shared}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF shared objects (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|strip_static}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF ar archives (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|cleanup_build}}: вызов ''/usr/lib/rpm/brp-cleanup''<br />
<br />
{{rpmmacro|compress_docs}}: вызов ''/usr/lib/rpm/brp-compress'' <br />
<br />
{{rpmmacro|strip_binaries}}: вызов ''/usr/lib/rpm/brp-strip'' (макрос удален с версии rpm-4.0.4-alt100.36)<br />
<br />
{{rpmmacro|clean_buildroot}}: выполнение ''rm -rf %buildroot'', если ''%buildroot'' не указывает на настоящий ''/''. <br />
<br />
'''Управление процессом сборки'''<br />
<br />
{{rpmmacro|buildmulti}}: Альтернативная директива ''%build'' для случая, когда в секции ''%build'' происходит заполнение ''%buildroot''. Вообще говоря, такой техники стоит избегать во всех случаях, когда это возможно. <br />
<br />
'''Версии некоторых установленных в системе пакетов'''<br />
<br />
'''glibc''': {{rpmmacro|__glibc_version}}, {{rpmmacro|__glibc_version_major}}, {{rpmmacro|__glibc_version_minor}} <br />
<br />
'''python''': {{rpmmacro|__python_version}} <br />
<br />
{{rpmmacro|get_version}}: Версия указанного пакета <br />
<br />
{{rpmmacro|get_release}}: Релиз указанного пакета<br />
<br />
{{rpmmacro|get_serial}}: Serial указанного пакета<br />
<br />
{{rpmmacro|add_serial}}: Serial указанного пакета в виде, пригодном для включения в ''spec''-файл. <br />
<br />
Эти макросы, как правило, используются в пакетах, сборка которых возможна с различными версиями этих программ, если эти версии правильно учитывать.<br />
<br />
'''Прочие макросы'''<br />
<br />
{{rpmmacro|intel}}: список архитектур ''intel'', совместимых с ''i386''<br />
<br />
{{rpmmacro|amd}}: список архитектур ''amd'', совместимых с ''i386''<br />
<br />
{{rpmmacro|ix86}}: список всех архитектур, совместимых с ''i386''<br />
<br />
компоненты макроса {{rpmmacro|packager}}: {{rpmmacro|packagerName}}, {{rpmmacro|packagerAddress}}.<br />
<br />
==== Новыe параметры rpm ====<br />
<br />
-'''bE''': новый режим работы ''rpm'', при котором происходит только подстановка макросов<br />
<br />
-'''nowait-lock''': не блокировать процесс, если база данных ''rpm'' занята <br />
<br />
-'''fancypercent''': отображать дополнительную информацию о процентах проделанной работы при установке/обновлении пакетов. <br />
<br />
==== Новые возможности rpm ====<br />
<br />
'''Автоматический поиск требуемых и предоставляемых зависимостей'''<br />
<br />
В дополнение к стандартному поиску зависимостей от/для разделяемых библиотек, реализована поддержка поиска требуемых зависимостей для ''shell'' и ''perl''-скриптов, а также поддержка поиска предоставляемых зависимостей для ''perl''-скриптов. (См. также [[rpm/AutoReq]].)<br />
<br />
'''Изменение семантики тэгов, управляющих поиском зависимостей'''<br />
<br />
Новые возможности ''rpm'' по автоматическому поиску зависимостей при сборке пакетов управляются, как и прежде, значениями тэгов ''AutoReq'', ''AutoProv'' и ''AutoReqProv''. К стандартным значениям ''yes/no'' (''true/false''), таким образом, добавлены новые возможные значения, являющиеся именами методов поиска зависимостей:<br />
<br />
*''lib'': включение поиска зависимостей от/для разделяемых библиотек<br />
*''shell'': включение поиска зависимостей в ''shell''-скриптах<br />
*''perl'': включение поиска зависимостей в ''perl''-скриптах<br />
*''nolib'': выключение поиска зависимостей от/для разделяемых библиотек<br />
*''noshell'': выключение поиска зависимостей в ''shell''-скриптах<br />
*''noperl'': выключение поиска зависимостей в ''perl''-скриптах<br />
*''default'': то же, что и ''yes'';<br />
*''none,off'': то же, что и ''no'';<br />
*''all'': включение всех возможных методов поиска зависимостей.<br />
<br />
Значением тэга может являться как один метод, так и перечисление методов. По умолчанию, для каждого под пакета собираемого пакета ''AutoReq'' = ''AutoProv'' = ''yes'', что на практике означает использование макросов <br />
{{rpmmacro|findreq_default_method}} и {{rpmmacro|findprov_default_method}} для определения методов поиска зависимостей.<br />
<br />
'''Автоматическое сжатие ''man'' и ''info''-документации с поддержкой различных методов сжатия'''<br />
<br />
Вся документация пакета, распознаваемая как ''man'' или ''info''-документация, по окончании работы секции ''%install'', сжимается согласно выбранному методу. Поддерживаются следующие методы сжатия:<br />
<br />
*''bzip2'': сжатие с помощью ''bzip2 -9''<br />
*''gzip'': сжатие с помощью ''gzip -9n''<br />
*''auto'': сжатие с помощью ''gzip -9n'' либо ''bzip2 -9'' в зависимости от того, какой вариант окажется эффективнее<br />
*''none'': производится декомпрессия файлов вместо сжатия<br />
*''skip'': процедура сжатия пропускается полностью.<br />
<br />
Какой метод будет использован в каждом конкретном случае, зависит от значения макроса {{rpmmacro|_compress_method}}; значение по умолчанию для этого макроса - ''auto''. По окончании процедуры сжатия производится выравнивание ссылок, которые, возможно, требуют коррекции в связи с изменениями имен файлов в процессе их сжатия.<br />
<br />
'''Автоматическое удаление отладочной информации из ELF-файлов с поддержкой различных стратегий выбора файлов, подлежащих обработке'''<br />
<br />
''Начиная с версии rpm-4.0.4-alt100.36 этот раздел устарел, brp-strip удален и вместо него используется brp-debuginfo (%_brp_strip_{debug,none}). <ref>http://lists.altlinux.org/pipermail/devel/2011-January/187944.html</ref><ref>http://lists.altlinux.org/pipermail/devel/2011-February/188021.html</ref>''<br />
<br />
Зачастую возможно уменьшить размер получаемых в результате сборки пакета ELF-файлов без потери качества за счет удаления из них отладочной информации. Поэтому по окончании работы секции ''%install'' все ELF-файлы выбранных типов обрабатываются программой ''strip''. Выбор типов файлов определяется значением макроса {{rpmmacro|_strip_method}}, которое есть набор из следующих возможных значений:<br />
<br />
*''executable'': ELF executable;<br />
*''relocatable'': ELF relocatable;<br />
*''shared'': ELF shared object;<br />
*''static'': ar archive.<br />
<br />
Кроме того, есть возможность вызывать ''strip'' вручную, для этой цели предназначены макросы {{rpmmacro|strip_executable}}, {{rpmmacro|strip_relocatable}}, {{rpmmacro|strip_shared}}, {{rpmmacro|strip_static}}. Синтаксис этих макросов подробно изложен в ''/usr/lib/rpm/brp-strip -help''.<br />
<br />
'''Автоматическая перекомпиляция python-модулей'''<br />
<br />
Как известно, python-модули обычно компилируют в байтовую форму для увеличения быстродействия при последующей работе с ними. Каждый такой модуль, помимо всего прочего, хранит время своего создания и полное имя файла, в котором должен находиться. В связи с последним обстоятельством скомпилированные модули, созданные в результате работы секции ''%install'', непригодны, ибо не могут быть использованы после установки пакета. По этой причине теперь по окончании работы секции ''%install'' производится перекомпиляция всех python-модулей таким образом, чтобы их можно было использовать после установки пакета. В качестве байт-компилятора будет использоваться программа, имя которой хранится в макросе {{rpmmacro|__python}}. Обычно это ''/usr/bin/python'', однако в некоторых случаях может потребоваться изменить это значение на другое (например, в случае сборки пакета python или если по какой-то причине перекомпиляция не нужна).<br />
<br />
'''BuildRoot'''<br />
<br />
Времена, когда тэг ''BuildRoot'' в ''spec''-файле определял, какой каталог ''rpm'' будет использовать в качестве ''BuildRoot'', прошли безвозвратно. Теперь этот таг не несет никакой информации и может (и должен) быть опущен. Вместо этого используется значение макроса {{rpmmacro|buildroot}}, который определен как ''%{_tmppath}/%{name}-buildroot'' в файле ''/usr/lib/rpm/macros'' и может быть переопределен в любом месте, где допускается определять макросы. В случае, если макрос {{rpmmacro|buildroot}} не определен либо его значение представляет собой недопустимое значение ''/'', сборка пакета не будет выполнена.<br />
<br />
'''Автоматическая очистка BuildRoot'''<br />
<br />
Перед выполнением секции ''%install'' и по окончании выполнения секции ''%clean'' ''rpm'' автоматически очищает ''BuildRoot'' с помощью макроса {{rpmmacro|clean_buildroot}}. Это значит, что больше не нужно использовать эти ужасные ''rm -rf $RPM_BUILD_ROOT''. Секция ''%clean'' вообще может (и должна) быть опущена, если в ней не содержится ничего, кроме этого ''rm''. В тех редких случаях, когда в ''spec''-файле производится заполнение ''BuildRoot'' не в секции ''%install'', как это должно быть, а в секции ''%build'', что в принципе неправильно, можно перенести точку очистки ''BuildRoot'' из начала секции ''%install'' в начало секции ''%build'', если заменить директиву ''%build'' на макрос {{rpmmacro|buildmulti}}.<br />
<br />
'''Упрощение секции %files'''<br />
<br />
Ранее в начале каждой секции %files было необходимо указывать атрибуты файлов и каталогов создаваемых пакетов с помощью довольно однообразно используемой директивы %defattr. Теперь это происходит автоматически в начале каждой секции %files, а также в начале каждого файла, включаемого в секцию %files с помощью опции -f. Точнее говоря, в качестве этой директивы используется значение макроса %_defattr. Таким образом, прежнее использование директивы %defattr в начале секций и файлов следует считать упраздненным.<br />
<br />
'''Сборка пакетов привилегированным пользователем'''<br />
<br />
То, что когда-то было необходимостью, со временем стало излишним, а порой и просто опасным. Теперь, когда все пакеты, кроме одного-единственного MAKEDEV, можно (и нужно) собирать непривилегированным пользователем во избежание риска разрушения системы и некорректной сборки, сборка пакетов привилегированным пользователем по умолчанию запрещена. Этот запрет можно снять путем изменения значения макроса {{rpmmacro|_allow_root_build}}.<br />
<br />
=== Пожелания packager'у ===<br />
<br />
==== Устаревшие конструкции ====<br />
<br />
Не следует использовать устаревшие конструкции - они лишь загромождают ''spec''-файл, снижая тем самым его читабельность. К устаревшим конструкциям, в частности, относятся:<br />
* тэг ''BuildRoot:'' (BuildRoot выбирается автоматически);<br />
* тэг ''Packager:'' (Packager заполняется автоматически);<br />
* cтроки вида ''rm -rf $RPM_BUILD_ROOT'' (BuildRoot очищается автоматически);<br />
* {{rpmmacro|_defattr}} со стандартными аргументами в начале файлов и секций ''%files'' (такое поведение действует по умолчанию);<br />
* секция ''%clean'', пустая либо без разумного содержания.<br />
<br />
==== Фигурные скобки ====<br />
<br />
Нет смысла засорять текст spec-файла ненужными фигурными скобками. Избавится от них легко:<br />
<br />
''perl -pi -e 's/%\{([A-Za-z_0-9]+)\}([^A-Za-z_0-9?*]|$)/%$1$2/g' spec''-файл<br />
<br />
Или с помощью утилиты ''cleanup_spec'' из пакета ''rpm-utils''.<br />
<br />
==== Выравнивание ====<br />
<br />
Используйте табуляции для выравнивания. Избегайте пробельных символов в конце строк.<br />
<br />
==== Значения тэгов ====<br />
<br />
Значение тэга от его имени следует разделять одним пробелом. Элементы списка значений следует разделять запятой с последующим пробелом. Значение тэга Summary следует начинать с прописной буквы и не следует завершать точкой. Значения тэга ''Summary'' и секции ''%description'' могут содержать названия команд только в не изменённом виде.<br />
<br />
==== Порядок тэгов ====<br />
<br />
Рекомендуемый порядок заголовочных тэгов: <br />
*Name<br />
*Version<br />
*Release<br />
*Epoch или Serial<br />
<br />
далее<br />
<br />
*Summary<br />
*License<br />
*Group<br />
*Url<br />
*Packager<br />
*BuildArch<br />
<br />
далее<br />
<br />
*Provides<br />
*Requires<br />
*PreReqs<br />
*Conflicts<br />
<br />
потом (влияющие на процесс сборки, но не то, как пакет выглядит снаружи)<br />
<br />
*Source<br />
*Patch<br />
<br />
и, наконец,<br />
<br />
*Prefix<br />
*BuildPreReqs<br />
*BuildRequires.<br />
<br />
Разумеется, не все из вышеперечисленных тэгов, как правило, используются, равно как встречаются и другие редко используемые тэги. В связи с тем, что ''BuildRequires'' зарезервирован для автоматически вычисляемых зависимостей, для указания особых зависимостей следует использовать ''BuildPreReq''.<br />
<br />
==== Файлы локализации ====<br />
<br />
Если в состав пакета входят файлы локализации либо другие файлы на разных языках, стоит использовать макрос {{rpmmacro|find_lang}}. Подробная информация есть в ''/usr/lib/rpm/find-lang -h''<br />
<br />
==== Группы ====<br />
<br />
Следите за значением тэгов ''Group'': они должны соответствовать действительности и при этом принадлежать фиксированному множеству, перечисленному в файле ''/usr/lib/rpm/GROUPS''.<br />
<br />
==== ChangeLog ====<br />
{{Main|Руководство по написанию changelog}}<br />
Для формирования первой строки changelog-записи удобно использовать утилиту ''[[add_changelog]]'' из пакета ''rpm-utils''.<br />
<br />
==== Внутрипакетные зависимости ====<br />
<br />
При работе с мультипакетными spec-файлами соблюдайте правило внутрипакетных зависимостей: Если один пакет в какой-либо мере зависит от другого подпакета, то эта зависимость должна быть указана полностью, включая не только имя, но также верcию, релиз и serial (если есть). Например, ''Requires: %name = %version-%release'' или Requires: %name = %epoch:%version-%release. Обратите внимание на синтаксис: знак равенства, в отличие от дефиса, окружен пробелами.<br />
<br />
==== Разделяемые библиотеки ====<br />
<br />
Пакеты, содержащие как разделяемые библиотеки, так и использующие их программы, должны быть разделены на подпакеты таким образом, чтобы в подпакет, содержащий разделяемые библиотеки, не входили использующие их программы. Это позволит уменьшить количество циклических зависимостей. По традиции, имена пакетов, состоящих только из разделяемых библиотек, должны начинаться с префикса ''lib'' либо содержать его внутри слова. При разделении подпакетов следует помнить о внутрипакетных зависимостях.<br />
<br />
==== Статические библиотеки ====<br />
<br />
Статические библиотеки должны паковаться в отдельные подпакеты, что связано со спецификой их использования. Если имя ''devel''-подпакета заканчивается суффиксом ''-devel'', то имя нового ''devel-static''-подпакета будет заканчиваться суффиксом ''-devel-static''. При разделении подпакетов следует помнить о внутрипакетных зависимостях: В списке зависимостей ''devel-static''-подпакета должна присутствовать зависимость от ''-devel = %version-%release''.<br />
<br />
==== Переименование пакетов ====<br />
<br />
Иногда пакеты переименовывают. Например, это случается при упаковке разделяемых библиотек. В таких случаях следует указывать правильную информацию о зависимостях, необходимую для корректного обновления. В частности, должен присутствовать:<br />
тэг ''Provides: старое_имя = %version''<br />
тэг ''Obsoletes: старое_имя''<br />
<br />
(Примечание: [[Реагирует ли сборочница на переименование пакетов]].)<br />
<br />
==== Наименование патчей ====<br />
<br />
При создании новых патчей, а также при импортировании патчей из других источников необходимо придерживаться единых правил наименования имён патч-файлов: NAME-VERSION-ORIGIN-WHAT.patch, где <br />
<br />
* NAME и VERSION — имя и версия пакета, для которого сделан патч; <br />
* ORIGIN — аббревиатуры источников патча (обычно дистрибутивов); <br />
* WHAT — краткое описание патча. <br />
<br />
В случае, когда патч образован из нескольких частей, полученных из разных источников, компонента имени ORIGIN должна содержать аббревиатуры всех источников. Если патч был создан или адаптирован для ALT Linux, то в ORIGIN, соответственно, должно присутствовать -alt-. Для патчей, созданных на базе CVS, компонента имени ORIGIN должна начинаться с cvs-YYYYMMDD. <br />
<br />
При составлении описания патча следует иметь в виду следующие общепринятые сокращения: <br />
* makefile - патчи, затрагивающие исключительно makefile*; <br />
* bound - проверки на границы (буфера, целых чисел, и т.п.);<br />
* config - патчи, затрагивающие исключительно конфигурационные файлы;<br />
* configure - патчи, затрагивающие исключительно configure*; <br />
* doc - патчи, затрагивающие исключительно документацию;<br />
* fixes - кумулятивные патчи и/или исправления по надёжности и/или безопасности;<br />
* format - патчи на использование форматирования строк (printf); <br />
* install - патчи, направленные на возможность выполнения make install непривилегированным пользователем; <br />
* linux - патчи, предназначенные для портирования ПО на Linux;<br />
* man - патчи, затрагивающие исключительно man-страницы; <br />
* texinfo - патчи, затрагивающие исключительно документацию в формате texinfo;<br />
* tmp - патчи, предназначенные для решения различных вопросов, связанных с временными файлами;<br />
* vitmp - патчи, направленные на поддержку vitmp(1); <br />
* warnings - патчи, исправляющие ошибки, найденные компилятором.<br />
<br />
== Литература ==<br />
<br />
*[http://www.rpm.org/ Официальный web-сайт rpm]<br />
*[http://lists.rpm.org/mailman/listinfo/rpm-list Список рассылки для разработчиков rpm 4.x]<br />
*[http://www.rpm.org/max-rpm-snapshot/index.html Maximum RPM], Edward C. Bailey February 17, 1997. (снэпшот книги)<br />
<br />
== Примечания ==<br />
* исходная версия этого документа доступна [http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/doc/ здесь] или [http://docs.altlinux.org/archive/2.4/master/alt-docs-devel/ch04.html в документации Master 2.4]<br />
<references /><br />
{{Category navigation|title=Сборка пакетов|category=Сборка пакетов|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=BugTracking/BugzillaMiniHowto&diff=65830BugTracking/BugzillaMiniHowto2023-03-01T07:57:40Z<p>AntonFarygin: /* Заведение нового бага */</p>
<hr />
<div>== ALT Linux Bugzilla mini-HOWTO ==<br />
<br />
''Как театр начинает с вешалки, так и багзилла начинается с регистрации. Конечно же, всегда есть возможность зайти в театр, поглазеть на афиши идущих в этом сезоне спектаклей (поиск существующих багов в багзиле), но тогда пропадает самое главное достоинство — интерактивность происходящего. Напомню, что речь идет о театре, находящемся по адресу [https://bugzilla.altlinux.org/ bugzilla.altlinux.org] Внешний вид театра классический. Конечно, это не греческий амфитеатр, но в то же время сделан по образу и подобию многих таких же построек.''<br />
<br />
Скажу сразу, что вдаваться в подробности устройства театра «Глюкозавр» (c) pilot@ я не собираюсь, и рассказывать, что происходит за сценой — у меня цели тоже нет. Моя задача провести вас в зал — дать, так сказать, контрамарку $)<br />
<br />
Итак, коллективный дух взял верх или желание иметь отклик от систем перебороло лень.<br />
<br />
=== Регистрация ===<br />
<br />
Для тех, кто уже имеет постоянный именной абонемент, этот абзац скорее всего будет неинтересен, и я предлагаю пропустить его, дабы не тратить драгоценное время. Остальным же сообщаю, что для регистрации в Bugzilla на главной странице присутствует линк с гордым именем <tt>Регистрация</tt>/<tt>New Account</tt> (самая нижняя строка, вторая справа ссылка слева от <tt>Вход в систему</tt>/<tt>Login</tt>). Все, что нужно указать на появившейся странице по ссылке — это только реальный email (первое поле). Ну а дальше система вышлет на зарегистрированный электронный адрес письмо для подтверждения регистрации, при переходе по ссылки в котором можно будет установить пароль. Пароль в дальнейшем можно будет поменять при входе в систему (<tt>Команды: Параметры</tt>/<tt>Actions: Preferences</tt>).<br />
<br />
Получив доступ в систему, можем смело действовать.<br />
<br />
=== Поиск существующих ошибок ===<br />
<br />
Итак, поищем описание проблемы среди имеющихся (регистрации не требует):<br />
* кликаем по ссылке <tt>Поиск</tt>/<tt>Search</tt> внизу страницы;<br />
* в появившейся форме выбираем продукт, например <tt>Sisyphus</tt>;<br />
* в поле <tt>Компонент</tt>/<tt>Component</tt> вводим название пакета, для которого ищем проблему (здесь тоже действует автодополнение);<br />
* в принципе на этом можно остановиться и нажать кнопку <tt>Поиск</tt>/<tt>Search</tt>. В этом случае мы получим полный список известных проблем для заданного пакета (компонента). Можно сузить список найденных проблем, задав определённый статус:<br />
** <tt>UNCONFIRMED</tt> — неподтвержденный,<br />
** <tt>NEW</tt> — новый,<br />
** <tt>RESOLVED</tt> — (раз)решённый,<br />
** <tt>CLOSED</tt> — закрытый,<br />
** <tt>REOPENED</tt> — открытый повторно,<br />
и т. д. Это, несомненно, сократит количество найденных багов.<br />
* каждая страничка багрепорта похожа по своей структуре на плоский тред форума. То есть внутри может быть беседа одного, двух или более лиц по существу поставленной проблемы. Также там могут находится патчи и возможные (временные) исправления проблемы или предложения разработчику (имеются в виду не поздравления с днем рождения или другими праздниками, и не предложения утопиться в ближайшем пруду, а желание реализовать ту или иную недостающую функциональность).<br />
* если при попытке открыть багрепорт получаем <tt>Access Denied. You are not authorized to access bug #nnnn.</tt> — скорее всего, проблема или имеет отношение к безопасности и до сих пор не публична, или помечена как таковая по ошибке.<br />
<br />
Если в списке найденных ошибок в разумный срок не нашлось то, чего нам нужно или о чем мы хотим поделиться с майнтейнером пакета — значит, нам нужно завести новую запись об ошибке.<br />
<br />
=== Поиск ошибки по номеру ===<br />
<br />
Еще одна разновидность поиска — по номеру ошибки. Допустим, вам пришло уведомление от глюкоробота или же где-то на просторах интернета вы встретили упомнинание вида «#6629» со смысловым смещением (указанием) в сторону багзилы. В этом случае достаточно ввести «магические цифры» (номер ошибки, 6629 в нашем примере) в поле в шапке или подвале страницы поле рядом с кнопкой <tt>Поиск</tt>/<tt>Search</tt> и нажать оную. Система сразу же переместит вас на страницу с описанием ошибки (если такая зарегистрирована).<br />
<br />
Как вариант, можно вбить руками адрес <tt>bugzilla.altlinux.org/nnnn</tt>.<br />
<br />
=== Поиск с помощью packages.altlinux.org ===<br />
<br />
На сайте [http://packages.altlinux.org/ru packages.altlinux.org] находите пакет, на который вы хотите повесить отчёт об ошибке, например, [http://packages.altlinux.org/ru/Sisyphus/srpms/kde5-krusader kde5-krusader] -- и щёлкаете по заголовку '''[https://packages.altlinux.org/ru/Sisyphus/srpms/kde5-krusader/bugs Bugs and FR]'''; в результате попадаете на страницу, где отмечены все ошибки (баги) и пожелания, "повешенные" на данный пакет.<br />
<br />
=== Заведение нового бага ===<br />
<br />
* Жмём кнопку <tt>Зарегистрировать ошибку</tt>/<tt>New bug</tt><br />
* Если логин (email)/пароль введены ещё не были, система спросит их и предложит выбрать раздел — вешаем ли мы баг на дистрибутивы, в нестабильную ветку или на неправильно работающий web-сайт ALT Linux. После этого выберем «продукт», на который вешаем баг. Под продуктом подразумеваются конкретная часть системы, как-то дистрибутив, Sisyphus, документация, переводы. Определившись, на что именно вешаем багу — выбираем нужный продукт. В некоторых разделах этот шаг отсутствует.<br />
* Дальше заполняем поле <tt>Компонент</tt>/<tt>Component</tt> (пакет, на который мы вешаем багу, или конкретный web-сайт). Если компонентов в данном продукте мало — там будет выпадающий список, если много — поле ввода с автодополнением.<br />
* Следующее поле (<tt>Платформа</tt>/<tt>Platform</tt>) можно оставить без изменений, если только ваша ошибка не проявляется исключительно на 64-битной системе или на системе с процессорами ARM или PowerPC.<br />
* А вот поле <tt>Severity</tt> имеет [[Bug Severity Policy|глубинный смысл]], ведь это сурьёзность заводимого сообщения об ошибке. Если сомневаетесь — оставьте <tt>Normal</tt>.<br />
** <tt>blocker</tt> — наиболее чреватые проблемами ошибки, включая серьёзные проблемы безопасности или функциональности;<br />
** <tt>critical</tt> — критичные для функционирования пакета;<br />
** <tt>major</tt> — выдающиеся относительно обычных;<br />
** <tt>normal</tt> — «обычные» (умолчание);<br />
** <tt>minor</tt> — незначительные, но тем не менее;<br />
** <tt>trivial</tt> — тривиальные в исправлении (например, опечатки в описании пакета или меню);<br />
** <tt>enhancement</tt> — не сообщение об ошибке, а предложение по улучшению.<br />
* Если ошибка касается безопасности и предоставляемая информация имеет чувствительный характер — есть отдельная галочка <tt>Security group</tt> (злоупотреблять не стоит — баг можно направить в эту группу только при его открытии, а снять пометку могут только члены этой группы; баги с пометками видят только члены сразу всех групп, на которые проставлены пометки).<br />
* Заполняем поле <tt>Суть</tt>/<tt>Summary</tt>. В этом поле можно в двух-трех-десяти словах (одним предложением) описать суть проблемы, чтобы легче было искать и ориентироваться другим пользователям глюкозавра. '''Принцип «краткость — сестра таланта» здесь действует как никогда.'''<br />
* Поле <tt>Подробное описание</tt>/<tt>Description</tt> подразумевает полное (детальное) описание проблемы, в котором нужно указать версию и название установленного дистрибутива, даты последних обновлений. Если есть понимание - версию пробного пакета. Приложить логи (в случае ошибки с ядром - dmesg), для ошибок, связанных с оборудованием - список оборудования (выводы команд lspci -nn и lsusb -v). Если надо - скриншоты ошибки.<br />
* Если все поля заполнены верно, то жмём кнопку <tt>Сохранить</tt>/<tt>Commit</tt>.<br />
<br />
Скорее всего, ошибка будет добавлена в базу и майнтейнер пакета будет уведомлен по электронной почте о неисправности в его пакете.<br />
<br />
К существующему описанию ошибки можно добавить комментарий или прикрепить файл (патч, описание, пример). Майнтейнер в состоянии изменить статус ошибки (по мере необходимости или завершённости) или перенаправить её другому майнтейнеру. Пользователь может переоткрыть ошибку (изменить статус на <tt>REOPEN</tt>) в случае, если ошибка осталась или проявилась в новой версии или несколько версий спустя.<br />
<br />
Информация о дальнейшей активности в рамках описанной или подписанной (полем <tt>Исполнитель</tt>/<tt>Assign to</tt> можно переложить ответственность на другого разработчика; для дополнения списка уведомляемых есть <tt>Подписка</tt>/<tt>Cc:</tt>) ошибки будет сваливаться на указанный при регистрации электронный адрес. Под активностью подразумевается изменение статуса ошибки, комментарии других пользователей, добавление патчей или текстовых файлов и т. д. (к слову, все это вы можете настроить по своему вкусу). Кого добавлять в список Сс: — можно узнать, например, из Changelog пакета (например, если маинтейнером пакета является некая packaging team, то стоит добавить в Сс: несколько человек из неё); автоматически добавляются указанные в [[ACL]] пакета. При этом указывать в поле Сс: следует в формате <tt><login@altlinux.org></tt>.<br />
<br />
=== Закрытие бага ===<br />
<br />
Майнтейнер пакета может исправить (или не исправить) ошибку и изменить её статус на <tt>RESOLVED</tt> (исправлена), при этом указывается способ исправления (resolution) ошибки:<br />
* <tt>FIXED</tt> — ошибка исправлена, как правило, исправлением исходных кодов или spec-файла.<br />
* <tt>NOTABUG</tt> — майнтейнер считает, что сообщение об ошибке некорректно (например, если это не баг, а фича).<br />
* <tt>WONTFIX</tt> — майнтейнер признал наличие ошибки, но по каким-то причинам не может или не собирается ее исправлять. Также применяется для случаев, когда действительная ошибка осталась на пакете, который более не поддерживается в Sisyphus и по факту отсутствует в репозитории.<br />
* <tt>DUPLICATE</tt> — сообщение об ошибке дублирует другую ранее внесенную в базу кляузу, майнтейнер должен указать ее номер.<br />
* <tt>WORKSFORME</tt> — майнтейнер не может воспроизвести ошибку и просит у пользователя дополнительную информацию.<br />
Если исправление ошибки удовлетворило пользователя (например, он скачал обновлённую версию пакета и убедился в исправлении), пользователь должен изменить статус ошибки на <tt>CLOSED</tt> (закрыта). Если исправление не удовлетворило пользователя, он может переоткрыть ошибку, изменив статус на <tt>REOPEN</tt> (см. тж. чуть ниже).<br />
<br />
К сожалению, пользователю трудно обнаруживать исправленные (<tt>FIXED</tt>), но не закрытые (<tt>CLOSED</tt>) ошибки, поскольку такие ошибки не обнаруживаются стандартным поиском «My bugs». Для обнаружения таких ошибок рекомендуется воспользоваться поиском по ошибкам, имеющим статус <tt>FIXED</tt>, или использовать гиперссылку в письме, которую вы получите после изменения майнтейнером статуса ошибки на <tt>FIXED</tt>.<br />
<br />
Не вполне, но местами всё же применимый [https://bugzilla.redhat.com/bugzilla/page.cgi?id=bug_status.html CV баги].<br />
<br />
''И напоследок, старайтесь пользоваться театром, не причиняя вреда и неудобства другим зрителям или актёрам. Актёр должен чувствовать себя комфортно на сцене, а зритель — в зале. Чем больше полезной информации донесёт зритель до актёра, тем больше вероятности, что актёр осчастливит зрителя свой блестящей игрой $)''<br />
<br />
В частности, если у вас проблема с каким-то пакетом, а не «вообще» — указывайте его версию.<br />
<br />
И ещё — не вешайте баги «отсутствует перевод» или «ошибка в переводе», особенно если заметно что проблема в консерватории (ну то есть в дирекции театра :)). В этом случае лучше сделать или поправить перевод и прислать его разработчикам программы. Мантейнерам хватает забот, и не все они переводчики.<br />
<br />
=== Переоткрыть или повесить новый? ===<br />
<br />
[https://bugzilla.altlinux.org/show_bug.cgi?id=5771#c35 > Переоткрою. Чуть-чуть бы доделать.]<br />
<br />
Не надо так делать — у каждой хорошей баги должны быть чёткие начало, формулировка и конец. Когда начинаются бесконечные самоуточняющиеся портянки, незаметно растёт наклад времени на их разбор и «diff» для выяснения, что ж там ещё; теряют точность ссылки на багу в %changelog (или же приходится сопоставлять и время); многих подобное подвигает в сторону «забить».<br />
<br />
Проверено на случае, где «портянки» дошли до клинических и в итоге пришлось писать внутренний регламент.<br />
<br />
Есть отдельная проблема — есть отдельная бага.<br />
<br />
=== Полезности ===<br />
<br />
==== Firefox/Mozilla bookmarklet ====<br />
<br />
'''Закладка на панели, по клику на которую спрашивается номер бага для открытия.'''<br />
<br />
Добавьте в букмарки (в папку «toolbar») такую ссылку (в одну строчку):<br />
<source lang="java"><br />
javascript:q = "" + (window.getSelection ? window.getSelection() : <br />
document.getSelection ? document.getSelection() : <br />
document.selection.createRange().text); <br />
if (!q) q = prompt("You didn't select any text. Enter altbug id:", ""); <br />
if (q!=null) location=("https://bugzilla.altlinux.org/"+q); void 0<br />
</source><br />
<br />
==== Firefox/Mozilla Internet Keyword ====<br />
<br />
''Переход к багу с номером NNN при вбивании в строку адреса altbug NNN либо всем багам пакета ABC по altbug ABC''<br />
<br />
Добавьте закладку со следующими параметрами:<br />
<br />
* Имя (Name): <tt>ALT Linux Bugzilla</tt><br />
* Адрес (Location): <tt><nowiki>https://bugzilla.altlinux.org/%s</nowiki></tt><br />
* Краткое имя (Keyword): <tt>altbug</tt><br />
<br />
Может также пригодиться расширение [https://addons.mozilla.org/en-US/firefox/addon/8703 URL Alias], рекомендуемое [http://lists.altlinux.org/pipermail/sisyphus/2009-June/340044.html legion@].<br />
<br />
==== Opera Search Engine ====<br />
<br />
''Переход к багу с номером NNN при вбивании в строку адреса altbug NNN''<br />
<br />
Добавьте Search Engine {{nav|Tools|Preferences|Search|Add}} со следующими параметрами:<br />
<br />
* Имя (Name): <tt>ALT Linux Bugzilla</tt><br />
* Краткое имя (Keyword): <tt>altbug</tt><br />
* Адрес (Address): <tt><nowiki>https://bugzilla.altlinux.org/%s</nowiki></tt><br />
<br />
==== Opera Search Field ====<br />
<br />
''Поле ввода типа «google search» для перехода к багу по номеру''<br />
<br />
Добавьте Search Engine, созданный на предыдущем шаге, на любую панель инструментов: {{nav|(Right Click)|Customize|Buttons|Search}}. Перетащите «ALT Linux Bugzilla» в нужное вам место на панели инструментов.<br />
<br />
=== Ссылки ===<br />
* [https://bugzilla.altlinux.org/docs/html/using.html Руководство по эксплуатации Bugzilla (en)]<br />
* [http://lib.custis.ru/Bugzilla О Bugzilla по-русски]<br />
* [http://egorfine.com/ru/articles/effective-bugreports/ Эффективные баг-репорты]<br />
* [http://www.chiark.greenend.org.uk/~sgtatham/bugs-ru.html Как эффективно сообщать об ошибках] ([http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively])<br />
* [https://bugs.eclipse.org/bugs/bugwritinghelp.html How to Write a Useful Bug Report]<br />
* [http://developer.mozilla.org/en/docs/Bug_writing_guidelines Bug Writing Guidelines]<br />
* [[Файл:New_bug.jpg|[http://www.youtube.com/watch?v=t1TLReSv75o&feature=youtu.be Видеоролик "Создание запроса на улучшение пакета"]] [http://www.youtube.com/watch?v=t1TLReSv75o&feature=youtu.be Видеоролик "Создание запроса на улучшение пакета"]<br />
<br />
{{Category navigation|title=HOWTO|category=HOWTO|sortkey={{SUBPAGENAME}}}}<br />
{{Category navigation|title=BugTracking|category=BugTracking|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%90%D0%BB%D1%8C%D1%82_%D0%A0%D0%B0%D0%B1%D0%BE%D1%87%D0%B0%D1%8F_%D1%81%D1%82%D0%B0%D0%BD%D1%86%D0%B8%D1%8F_10&diff=65218Альт Рабочая станция 102023-01-31T13:07:30Z<p>AntonFarygin: /* 10.1 */</p>
<hr />
<div>{| style="border:1px solid #AAA; background:#F9F9F9; margin: 0 0 1em 1em; padding:.2em; text-align:center; float: right;" class=noprint<br />
|[[Файл:Download.png|link=http://getalt.org/ru/alt-workstation/]]<br />
<br />
|-<br />
|[http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/x86_64/alt-workstation-10.1-x86_64.iso x86_64] <small>(~7&nbsp;Гб)</small><br />
|-<br />
|[http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/i586/alt-workstation-10.1-i586.iso i586] <small>(~6&nbsp;Гб)</small><br />
|-<br />
|[http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/aarch64/alt-workstation-10.1-aarch64.iso aarch64] <small>(~5&nbsp;Гб)</small><br />
|-<br />
|[http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/aarch64/alt-workstation-10.1-aarch64.img.xz RPi 3] <small>[[write/rootfs#Запись_образа_img_на_SD-карту|инструкция]]</small><br />
|-<br />
|[http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/aarch64/alt-workstation-10.0-rpi4-aarch64.img.xz RPi 4] <small>[[write/rootfs#Запись_образа_img_на_SD-карту|инструкция]]</small><br />
|-<br />
|[[эльбрус/дистрибутивы|e2k, e2kv4, e2kv5]] <small>(по запросу)</small><br />
|-<br />
|'''[http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/ ftp.altlinux.org]'''<br />
|-<br />
|[http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/license.ru.html лицензия]<br />
|-<br />
|}<br />
<br />
== Альт Рабочая станция ==<br />
<br />
'''Альт Рабочая станция 10''' — дистрибутив, разработанный [https://www.basealt.ru ООО «Базальт СПО»] на [[Десятая платформа|Деcятой платформе]].<br />
<br />
== Возможности ==<br />
<br />
Альт Рабочая станция представляет собой решение для организации<br />
рабочих мест конечных пользователей и подходит для применения как<br />
в офисной среде, так и дома.<br />
Дистрибутив может использоваться в инфраструктуре Active Directory (аутентификация в домене, доступ к файловым ресурсам и ресурсам печати) и гетерогенной сети под управлением [[Альт_Сервер_10|Альт Сервер]].<br />
Систему можно использовать для решения широкого круга задач:<br />
* работы в сети интернет: в браузере, с электронной почтой, для обмена мгновенными сообщениями;<br />
* создания и редактирования текстов, электронных таблиц, презентаций;<br />
* работы с видео и звуковыми файлами, сложной графикой и анимацией.<br />
<br />
=== Основные новшества в Деcятой платформе ===<br />
<br />
* OpenUDS — решение для VDI.<br />
* Расширение набора групповых политик.<br />
* Центр администрирования Active Directory (admc).<br />
* Модуль настройки многотерминального режима alterator-multiseat.<br />
* Поддержка устройств на базе процессоров Байкал-М.<br />
<br />
=== Поддерживаемые аппаратные платформы ===<br />
Альт Рабочая станция 10 выпускается для следующих аппаратных платформ:<br />
* [https://ru.wikipedia.org/wiki/X86 x86] — 32-разрядные процессоры Intel и AMD;<br />
* [https://ru.wikipedia.org/wiki/X86-64 x86_64] — 64-разрядные процессоры Intel и AMD;<br />
* [https://ru.wikipedia.org/wiki/ARM_(%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0)#ARMv8_%D0%B8_%D0%BD%D0%B0%D0%B1%D0%BE%D1%80_%D0%BA%D0%BE%D0%BC%D0%B0%D0%BD%D0%B4_ARM_64_%D0%B1%D0%B8%D1%82 aarch64] — 64-разрядные процессоры ARMv8 и совместимые с ними;<br />
* [https://ru.wikipedia.org/wiki/%D0%AD%D0%BB%D1%8C%D0%B1%D1%80%D1%83%D1%81_2000 e2k*] — 64-разрядные процессоры Эльбрус<ref> [[эльбрус/архитектура|третьего-пятого поколений]] (с 4С по 8СВ)</ref>; о доступности [[#Получить образы Альт Рабочая станция 10 для Эльбрус|см. далее]].<br />
<br />
== Сроки поддержки ==<br />
<div style="border-left:3px solid #2590B7;border-right:3px solid #2590B7;padding:7px;margin-top: 7px;margin-bottom: 7px;background-color:#E0EEF3;">В части обновлений по безопасности (если иное не предусмотрено условиями поставки):<br />
* '''31 декабря 2024 года''' для дистрибутива Альт Рабочая станция 10, но не ранее полугода с момента выпуска новой версии (11.0).</div><br />
<br />
=== Версии программного обеспечения на день релиза ===<br />
<br />
==== 10.0 ====<br />
* ядра Linux (std-def) 5.10.82<br />
* языки программирования Perl 5.34.0, Python 3.9.6, GCC 10.3.1<br />
* рабочая среда MATE 1.24<br />
* офисный пакет LibreOffice-still 7.1.7.2<br />
* веб-браузер Firefox ESR 91.3.0<br />
* среда запуска приложений на Win32 API — WINE 6.14.1<br />
* редактор растровой графики GIMP 2.10.28<br />
* редактор векторной графики Inkscape 1.1<br />
* 3D-редактор Blender 2.93.1<br />
<br />
==== 10.1 ====<br />
* ядра Linux std-def-5.10.164 (i586, x86_64, aarch64), un-def-5.15.89 (x86_64), rpi-un-6.1.0 (aarch64)<br />
* рабочая среда MATE 1.26<br />
* офисный пакет LibreOffice-still 7.3.7.2<br />
* веб-браузер Firefox ESR 102.6.0<br />
* среда запуска приложений на Win32 API — WINE 7.22.1<br />
* клиент брокера подключений для создания и управления виртуальными рабочими местами OpenUDS 3.5.0<br />
<br />
Скачать эту версию и посмотреть входящие пакеты можно [https://packages.altlinux.org/ru/p10/images/alt-workstation?version=10.1.0 здесь]<br />
<br />
==== Основные изменения в 10.1 ====<br />
* В iso образах для x86_64 и aarch64 при установке доступны 2 ядра на выбор (std-def и un-def для x86_64, std-def и rpi-un для aarch64).<br />
* Используется другой интерфейс для шага разбивки диска при установке;<br />
* Добавлен flatpak (не устанавливается по умолчанию)<br />
* Новый index.html;<br />
* Исправлена проблема загрузки с флеш-накопителя на некоторых UEFI;<br />
* Добавлен wine-cpcsp_proxy;<br />
* Добавлен cryptopro-preinstall;<br />
* Добавлен gpui;<br />
* Добавлен alterator-limits;<br />
* используется пакет samba-usershares;<br />
* На live используется тот же набор приложений для сканирования, что и в install варианте;<br />
* добавлен krb5-ticket-watcher;<br />
* Приложения из раздела "Обработка графики" (gimp, inkscape) теперь устанавливаются по умолчанию.<br />
* Различные багфиксы.<br />
<br />
== Дата выпуска ==<br />
* 15 декабря 2021 года — выпуск 10.0<br />
<br />
== Скачать образы ==<br />
<br />
Все дистрибутивы доступны для загрузки и использования без ограничений для физических лиц, для юридических лиц необходимо приобретение лицензии. [https://www.basealt.ru/products/alt-workstation/license/ Лицензионный договор на операционную систему Альт Рабочая станция].<br />
<br />
Все образы являются гибридными, то есть пригодны для записи как на DVD-диски, так и на USB-флеш-диски. Запись на USB-флеш диски осуществляется утилитой dd (на весь диск целиком, а не на раздел, то есть, например, не на /dev/sdb1, а на '''/dev/sdb''') в соответствии с [[Write|инструкцией по записи образов.]]<br />
<br />
{{Attention|UNetbootin и UltraISO вместо простой записи гибридного образа ALT Linux на флеш-накопитель портят загрузку, поэтому использование этих программ для записи образов '''не рекомендуется'''.}}<br />
'''Системные требования'''<br />
{|class="standard"<br />
|-<br />
!Дистрибутив<br />
!Минимальный размер ОЗУ<br />
!Рекомендуемый размер ОЗУ<br />
!Место на жёстком диске<br />
|-<br />
|Альт Рабочая станция 10||1 ГБ||от 2 ГБ||от 11 до 30 ГБ<br />
|}<br />
{{ISO<br />
|iso=http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/x86_64/alt-workstation-10.1-x86_64.iso<br />
|name=Альт Рабочая станция 10.1 (x86_64)<br />
|size=6.9<br />
|md5sum=84605e6eb98ae4015da7a7d719235941<br />
|filelist=http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/x86_64/alt-workstation-10.1-x86_64.iso.txt<br />
}}<br />
{{ISO<br />
|iso=http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/aarch64/alt-workstation-10.1-aarch64.iso<br />
|name=Альт Рабочая станция 10.1 (aarch64)<br />
|size=5.2<br />
|md5sum=8cd4ae0777e5308ef9fa8dc7f33df1e7<br />
|filelist=http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/aarch64/alt-workstation-10.1-aarch64.iso.txt<br />
}}<br />
{{ISO<br />
|iso=http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/i586/alt-workstation-10.1-i586.iso<br />
|name=Альт Рабочая станция 10.1 (i586)<br />
|size=6.0<br />
|md5sum=dcc01f428a8fa65ed51491f3ec6ed38b<br />
|filelist=http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/i586/alt-workstation-10.1-i586.iso.txt<br />
}}<br />
<br />
== Скачать образ файловой системы ==<br />
<!--<br />
{{ISO<br />
|iso=http://ftp.altlinux.org/pub/beta/workstation/aarch64/alt-workstation-rpi4-9.920_beta2-aarch64.tar.xz<br />
|name=Альт Рабочая станция 10.0 бета для Raspberry Pi 3<br />
|size=_<br />
|md5sum=<br />
}}<br />
--><br />
<!--<br />
{{ISO<br />
|iso=http://ftp.altlinux.ru/pub/distributions/ALTLinux/p10/images/workstation/armh/alt-workstation-mcom02-10.0-armh.tar.xz<br />
|name=Альт Рабочая станция 10.0 для MCom-02 (Салют-ЭЛ24ПМ2)<br />
|size=1.1<br />
|md5sum=10c87f079a8aed11cdaeb4581b7f03c8<br />
}}<br />
Записать образ файловой системы можно по [[write/rootfs|этой инструкции]].<br />
{{ISO<br />
|iso=http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/mipsel/alt-workstation-tavolga-10.0-mipsel.recovery.tar<br />
|name=Альт Рабочая станция 10.0 для «Таволга Терминал» 2BT1<br />
|size=1.4<br />
|md5sum=349f038afdba40b653dbbc63a248fa44<br />
}}<br />
Записать образ файловой системы в формате recovery.tar можно по [[Ports/mipsel/Прошивка_образа_в_формате_recovery.tar_на_Таволга_Терминал|этой инструкции]]. Для установки рекомендуется устройство с флешкой на 16Gb или дополнительным жёстким диском.<br />
{{ISO<br />
|iso=http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/images/workstation/mipsel/alt-workstation-bfk3-10.0-mipsel.tar.xz<br />
|name=Альт Рабочая станция 10.0 для BFK3.1<br />
|size=1.1<br />
|md5sum=b73dfbd52f474349963972ce7f40bcb7<br />
}}<br />
Записать образ файловой системы для BFK3.1 можно по [[Установка Альт из тарболов rootfs на BFK3.1|этой инструкции]].<br />
--><br />
<br />
<br />
{{Note|Для установки на Raspberry Pi 4 предпочтительным является образ SD карты. Образ файловой системы опубликован в ознакомительных целях.}}<br />
<br />
{{ISO<br />
|iso=http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/aarch64/alt-workstation-10.0-rpi4-aarch64.tar.xz<br />
|name=Альт Рабочая станция 10.0 для Raspberry Pi 4<br />
|size=1.4<br />
|md5sum=cf9e27f9418eb7d9a8d21ee412e6c44f<br />
}}<br />
<br />
Записать образ файловой системы для Raspberry Pi 4 можно по [[write/rootfs#Raspberry_Pi_4|этой инструкции]].<br />
<br />
== Скачать образ SD карты ==<br />
{{ISO<br />
|iso=http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/aarch64/alt-workstation-10.1-aarch64.img.xz<br />
|name=Альт Рабочая станция 10.1 для Raspberry Pi 3<br />
|size=1.6<br />
|md5sum=03d500e2f933c335fb35db65f495f56d<br />
}}<br />
<br />
{{ISO<br />
|iso=http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/aarch64/alt-workstation-10.0-rpi4-aarch64.img.xz<br />
|name=Альт Рабочая станция 10.0 для Raspberry Pi 4<br />
|size=1.4<br />
|md5sum=dd9941c775eff9a1321069a0b16e9351<br />
}}<br />
<br />
Записать образ SD карты можно по [[write/rootfs#Запись_образа_img_на_SD-карту|этой инструкции]].<br />
<br />
== Некоторые отличия Альт Рабочая станция 10 для Raspberry Pi 4 ==<br />
<br />
* редактор растровой графики GIMP, редактор векторной графики Inkscape, 3D-редактор Blender, центр администрирования Active Directory (admc) не установлены.<br />
<br />
* веб-браузер Firefox ESR заменён на Chromium для обхода проблемы с воспроизведением видео https://bugzilla.altlinux.org/41486<br />
<br />
== Получить образы Альт Рабочая станция 10 для Эльбрус ==<br />
<br />
Выпуск дистрибутива Альт Рабочая станция 10 для [[Эльбрус]] доступен по [http://basealt.ru/about/contacts/ письменному запросу] обладателей оборудования, т.к. требуется NDA с [http://mcst.ru МЦСТ].<br />
<br />
Поддерживаются рабочие станции "[http://www.ineum.ru/arm-elbrus401 Эльбрус 401-РС]" ([[эльбрус/архитектура|e2k]]), "[http://www.ineum.ru/elbrus_801-pc Эльбрус 801-РС]" ([[эльбрус/архитектура|e2kv4]]) и "Эльбрус 901-РС" ([[эльбрус/архитектура|e2kv5]]), в том числе в [[эльбрус/горыныч|многоместных вариантах]]<!--; доступна экспериментальная поддержка "[http://www.ineum.ru/elbrus_101-pc Эльбрус 101-РС]" (требуются доработки в части 3D-акселератора) и "Эльбрус 201-РС" (e2kv6) -->.<br />
<br />
Образы предназначены для [[write|записи на флэшку]] при помощи скрипта <tt>[[write.sh]]</tt> в их составе; также обратите внимание на [[эльбрус/загрузчик|порядок выбора загрузочного носителя]].<br />
<br />
Дистрибутив основан на ядре Linux 5.4.163. <!-- Опубликованы списки пакетов в составе образов: [http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/e2k/contents/ e2k], [http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/images/workstation/e2kv4/contents/ e2kv4], [http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/images/workstation/e2kv5/contents/ e2kv5]. --><br />
<br />
== Известные проблемы ==<br />
<br />
* Иногда после блокировки экрана невозможно выполнить разблокировку. При вводе правильного пароля происходит сбой аутентификации. Для обхода нужно переключиться на другой экран, например ctrl-alt-f2 и подать команду от root:<br />
<br />
control tcb_chkpwd tcb<br />
<br />
* Только на Raspberry Pi. Не работает Bluetooth клавиатура. Для обхода нужно обновить ядро rpi-un на последнее в p10 и использовать его.<br />
<br />
== Снимки экрана ==<br />
<br />
<gallery perrow="4"><br />
<br />
Image:WS10_desktop.png|Альт Рабочая станция 10, Рабочий стол<br />
Image:WS10_menu.png|Альт Рабочая станция 10, Меню<br />
Image:WS10_apps.png|Альт Рабочая станция 10, Приложения<br />
</gallery><br />
<br />
{{Category navigation|title=Десятая платформа|category=Десятая платформа|sortkey={{SUBPAGENAME}}}}<br />
{{Category navigation|title=Дистрибутивы|category=Дистрибутивы|sortkey={{SUBPAGENAME}}}}<br />
<br />
[[Категория:Дистрибутивы]]<br />
[[Категория:Десятая платформа]]<br />
[[Категория:Releases/100]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%90%D0%BB%D1%8C%D1%82_%D0%A0%D0%B0%D0%B1%D0%BE%D1%87%D0%B0%D1%8F_%D0%A1%D1%82%D0%B0%D0%BD%D1%86%D0%B8%D1%8F_%D0%9A_10&diff=63773Альт Рабочая Станция К 102022-11-18T05:58:27Z<p>AntonFarygin: /* Основные новшества в 10.1 */</p>
<hr />
<div>{{stub}}<br />
<br />
== Альт Рабочая станция К ==<br />
<br />
'''Альт Рабочая станция К''' — дистрибутив, разработанный [https://www.basealt.ru ООО «Базальт СПО»] на [[Десятая платформа|Деcятой платформе]].<br />
<br />
== Возможности ==<br />
<br />
Альт Рабочая станция К представляет собой решение для организации<br />
рабочих мест конечных пользователей и подходит для применения как<br />
в офисной среде, так и дома.<br />
Дистрибутив может использоваться в инфраструктуре Active Directory (аутентификация в домене, доступ к файловым ресурсам и ресурсам печати) и гетерогенной сети под управлением [[Альт_Сервер_10|Альт Сервер]].<br />
Систему можно использовать для решения широкого круга задач:<br />
* работы в сети интернет: в браузере, с электронной почтой, для обмена мгновенными сообщениями;<br />
* создания и редактирования текстов, электронных таблиц, презентаций;<br />
* работы с видео и звуковыми файлами, сложной графикой и анимацией;<br />
* использования аппаратного ускорения 3D и OpenCL с фирменными драйверами видеокарт NVIDIA;<br />
<br />
=== Основные новшества в 10.1 ===<br />
<br />
Обновлено:<br />
* KDE: Plasma 5.24, Gear 22.04, Frameworks 5.97<br />
* Mesa 22.0<br />
Добавлено:<br />
* Возможность установки при использовании Ventoy<br />
* Профиль установки: ВЕБ-Терминал<br />
* Включен сервис слежения за свободной памятью systemd-oomd<br />
* Уведомление пользователя при принудительном завершении приложений сервисом oomd<br />
* Возможность создавать подразделы BTRFS при установке<br />
* Профиль автоматической разметки дисков для Timshift<br />
* Создание точки восстановления перед обновлением системы при использовании BTRFS<br />
* Запуск восстановления системы из Discover при обнаружении неудачи обновления<br />
Исправлено:<br />
* Раздача папок от доменного пользователя по сети Windows из Dolphin<br />
* Сброс языковых раскладок клавиатуры при подключении USB-устройств<br />
* Настройка прокси-сервера в центре управления<br />
<br />
Скачать эту версию можно [https://packages.altlinux.org/ru/p10/images/alt-kworkstation?version=10.1.0 здесь]<br />
<br />
=== Основные новшества в 10.0 ===<br />
<br />
Обновлено:<br />
* Ядро: 5.15<br />
* KDE: Plasma 5.23, Gear 21.12, Frameworks 5.92<br />
Добавлено:<br />
* Отечественные корневые сертификаты шифрования.<br />
* Локальная двухфакторная аутентификация по аппаратным токенам(Рутокен, JaCarta, ESMART).<br />
* Переход на ядро 5.15 для поддержки современного оборудования.<br />
* Безопасное обновление системы:<br />
** При появлении обновлений предлагается перезагрузка, при которой происходит обновление системы.<br />
** Вместо apt-indicator используется plasma5-discover-packagekit.<br />
* Для Flatpak по умолчанию подключен репозиторий flathub.<br />
* В Discover поддержка SNAP-приложений (https://snapcraft.io).<br />
* Графический редактор GIMP заменён на Krita.<br />
* Видеопроигрыватель SMplayer заменён на Haruna.<br />
* Улучшена поддержка планшетных компьютеров.<br />
* Возможность делать снимки экрана при установке.<br />
* Меню сетевой установки при загрузке с установочного носителя в EFI<br />
* Поддержка процессоров Intel Alder Lake (поколение 12).<br />
* "Бесшовная" загрузка системы (не видны системные сообщения).<br />
* kernel-modules-bcmwl исключён из дистрибутива, т.к. устарел (bug#41620).<br />
* Различные полезные утилиты: glxinfo, vulkan-tools, clinfo и другие.<br />
* Больше драйверов принтеров(OKI, Brother и др.).<br />
* Больше драйверов сканеров (Epson и др.).<br />
Исправлено:<br />
* Зависание графической подсистемы X11 при изменении имени узла.<br />
Примечания:<br />
* Установочный образ больше не умещается на DVD-5.<br />
* Безопасное обновление пока не работает с репозиториями на сетевых файловых системах.<br />
* В VirtualBox, если не запускается установщик, живая или установленная система, необходимо в настройках VB вместо VMSVGA установить графический контроллер VBoxSVGA без 3D.<br />
<br />
== Сроки поддержки ==<br />
<div style="border-left:3px solid #2590B7;border-right:3px solid #2590B7;padding:7px;margin-top: 7px;margin-bottom: 7px;background-color:#E0EEF3;">В части обновлений по безопасности (если иное не предусмотрено условиями поставки):<br />
* '''31 декабря 2024 года''' для дистрибутива Альт Рабочая станция К 10, но не ранее полугода с момента выпуска новой версии (11).</div><br />
<br />
=== Версии программного обеспечения на день релиза ===<br />
<br />
==== 10.1 ====<br />
* Графическая среда KDE: Plasma 5.24, Gear 22.04, Frameworks 5.97<br />
* Ядро Linux 5.15.72<br />
* Mesa 22.0.4<br />
* xorg-server 20.14<br />
* Веб-браузер Сhromium-gost 102.0.5005.61<br />
* Офисный пакет LibreOffice-still 7.3.6.2<br />
* Драйверы NVIDIA 515.65.01, 470.141.03, 390.154, 340.108<br />
* Qt 5.15.4<br />
* Среда запуска приложений на Win32/64 API — WINE 7.17.1<br />
<br />
==== 10.0 ====<br />
* Графическая среда KDE: Plasma 5.23, Gear 21.12, Frameworks 5.92<br />
* Ядро Linux 5.15.34<br />
* Mesa 21.1.5<br />
* xorg-server 20.14<br />
* Веб-браузер Сhromium-gost 97.0.4692.99<br />
* Офисный пакет LibreOffice-still 7.2.6.2<br />
* Драйверы NVIDIA 510.60.02, 470.103.01, 390.147, 340.108<br />
* Qt 5.15.2<br />
* Среда запуска приложений на Win32 API — WINE 6.14.1<br />
<br />
== Дата выпуска ==<br />
<!--<br />
* __ месяца 20__ года — выпуск __<br />
* __ месяца 20__ года — выпуск __<br />
* __ месяца 20__ года — выпуск __<br />
--><br />
<br />
== Скачать образы ==<br />
<br />
Все дистрибутивы доступны для загрузки и использования без ограничений для физических лиц. Для юридических лиц необходимо приобретение лицензии. [https://www.basealt.ru/products/alt-workstation/license/ Лицензионный договор на операционную систему Альт Рабочая станция].<br />
<br />
Все образы являются гибридными, то есть пригодны для записи как на DVD-диски, так и на USB-флеш-диски. <br />
Запись на USB-флеш диски осуществляется утилитой dd (на весь диск целиком, а не на раздел, то есть, например, не на /dev/sdc1, а на '''/dev/sdc''') в соответствии с [[Write|инструкцией по записи образов.]]<br />
<br />
{{Attention|UNetbootin и UltraISO вместо простой записи гибридного образа ALT Linux на флеш-накопитель портят загрузку, поэтому использование этих программ для записи образов '''не рекомендуется'''.}}<br />
'''Системные требования'''<br />
{|class="standard"<br />
|-<br />
!Дистрибутив<br />
!Минимальный размер ОЗУ<br />
!Рекомендуемый размер ОЗУ<br />
!Место на жёстком диске<br />
|-<br />
|Альт Рабочая станция К 10||1 ГБ||от 4 ГБ||от 32 ГБ<br />
|}<br />
* [https://ru.wikipedia.org/wiki/X86-64 x86_64] — 64-разрядный процессор Intel или AMD;<br />
* Видеокарта с 3D-ускорением: NVIDIA GeForce >= 8100(поддержка NVIDIA Optimus), Intel (кроме i8xx, Poulsbo), AMD/ATI. Рекомендуется NVIDIA >= GeForce GTX 750.<br />
<br />
{{ISO<br />
|iso=http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/kworkstation/alt-kworkstation-10-install-x86_64.iso<br />
|name=Альт Рабочая станция К 10 (x86_64 установка)<br />
|size=5.8<br />
|md5sum=http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/kworkstation/MD5SUM<br />
}}<br />
{{ISO<br />
|iso=http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/kworkstation/alt-kworkstation-10-live-x86_64.iso<br />
|name=Альт Рабочая станция К 10 (x86_64 живая система)<br />
|size=4.1<br />
|md5sum=http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/kworkstation/MD5SUM<br />
}}<br />
<br />
== Известные ошибки ==<br />
<br />
<br />
== Снимки экрана ==<br />
<br />
<!--<br />
<gallery perrow="4"><br />
Image:Name.png|Название<br />
Image:Name.png|Название<br />
Image:Name.png|Название<br />
</gallery><br />
--><br />
<br />
== См. также ==<br />
<br />
<br />
<br />
[[Категория:Дистрибутивы]]<br />
[[Категория:Десятая платформа]]<br />
[[Категория:Releases/100]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=Branches&diff=62062Branches2022-08-05T08:23:49Z<p>AntonFarygin: /* Поддерживаемые ветки */</p>
<hr />
<div>Стабильные ветки репозитория пакетов ALT Linux ("бранчи") создаются на основе нестабильного [[Репозиторий СПО|репозитория]] [[Sisyphus]] путём отпочковывания и стабилизации с целью разделения темпов изменений при разработке и эксплуатации.<br />
<br />
На основе стабильных веток разрабатываются [[Releases|дистрибутивы ALT Linux]], из них же и обновляются.<br />
<br />
{{main|Репозитории ALT Linux}}<br />
<br />
== /etc/apt/sources.list ==<br />
Как правило, годится такой вид (<tt>BRANCH</tt> — имя ветки, <tt>ARCH</tt> — i586 либо x86_64; может быть добавлен третий репозиторий при необходимости [[Biarch|установки 32-битных пакетов на 64-битную систему]]):<br />
<pre><br />
rpm [updates] http://ftp.altlinux.org/pub/distributions/ALTLinux/$BRANCH/branch $ARCH classic<br />
rpm [updates] http://ftp.altlinux.org/pub/distributions/ALTLinux/$BRANCH/branch noarch classic<br />
</pre><br />
{{attention|не добавляйте в конфигурацию сразу несколько бранчей, это склонно приводить к путанице.}}<br />
== /etc/rpm/macros.d/ ==<br />
Начиная с бранча p10 используется %_priority_distbranch в rpm. Для p10, помимо sources.list, следует добавить "%_priority_distbranch p10" в конфиг rpm, например так:<br />
<br />
echo "%_priority_distbranch p10" > /etc/rpm/macros.d/p10<br />
<br />
== Нестабильные репозитории ==<br />
<br />
* [[Branches/Sisyphus|Sisyphus]] — основной репозиторий разработчиков, нередко имеющих дело с ещё не стабильными версиями программ;<br />
<br />
* [[Autoports]] — дополнительные репозитории; представляют собой собрание последних версий пакетов из Сизифа, собранных роботом под соответствующие бранчи.<br />
<br />
== Поддерживаемые ветки ==<br />
{|class="standard"<br />
!Название<br />
!Дата создания<br />
!Окончание поддержки<br />
![[Releases|Выпущенные дистрибутивы]]<br />
|-<br />
|[[Branches/p10|p10]]<br />
|июль 2021<br />
|'''30 июня 2024 года'''<br />
|[[Альт Сервер 10]], [[Альт Рабочая станция 10]], [[Альт Образование 10]], [[Альт Сервер Виртуализации 10]], [[Simply Linux 10]]<br />
|-<br />
|[[Branches/p9|p9]]<br />
|июнь 2019<br />
|'''31 декабря 2023 года'''<br />
|[[Альт Сервер 9]], [[Альт Рабочая станция 9]], [[Альт Образование 9]], [[Альт Сервер Виртуализации 9]], [[Simply Linux 9]]<br />
|-<br />
|[[Branches/c9f2|c9f2]]<br />
|&nbsp;<br />
|&nbsp;<br />
|[http://altsp.su/ Альт 8 СП]<br />
|}<br />
<!-- p9: 15 мая 2019 года --><br />
<!-- c8: данные? --><br />
<br />
== Архив ==<br />
<!-- == Предыдущая стабильная ветка == --><br />
* [[Branches/p8|Branch p8]] — июнь 2016, поддерживался до 16 декабря 2019 года (выпущены: Альт Сервер 8.0, [[Альт Рабочая станция 8]], [[Образование/8|Альт Образование 8]], [[Альт Рабочая станция К 8]], [[Simply Linux 8]])<br />
* [[Branches/c7|Branch c7]] — март 2017, поддерживался до 22 марта 2020 года (выпущен Альт Линукс СПТ 7.0)<br />
* [[Branches/c6|Branch c6]] — декабрь 2010, поддерживался до 18 апреля 2016 (выпущен Альт Линукс СПТ 6.0)<br />
* [[Branches/p7|Branch p7]] — апрель 2013, поддерживался до 30 августа 2015 года (выпущены [[Альт Линукс 7.0 Кентавр]], [[Альт Линукс 7.0 KDesktop]], [[Simply Linux 7.0]])<br />
* [[Branches/t7|Branch t7]] — октябрь 2013 (community branch, параллельный [[Branches/p7|p7]]) неофициальные сборки: [http://enp.itx.ru/linux/alt/t7/iso/ enp@]<br />
* [[Branches/p6|Branch p6]] — май 2011, поддерживался до 30 августа 2013 года (выпущены [[Альт Линукс 6.0 Кентавр]], [[ALTLinux 6.0 KDesktop]], [[Simply]] Linux 6.0, [[Альт Линукс 6.0 Школьный|Информика 6.0 Школьный]])<br />
* [[Branches/t6|Branch t6]] — май 2011 (community branch, параллельный [[Branches/p6|p6]])<br />
* [[Branches/5.1|Branch 5.1]] — 2009, осень (community branch, параллельный [[Branches/p5|p5]])<br />
* [[Branches/p5|Branch p5]] — 2009, осень (выпущены дистрибутивы [[Альт Линукс 5.0 Ковчег|5.0 Ковчег]], [[Альт Линукс 5.0 Школьный|5.0 Школьный]], 5.0 Desktop KDE и [http://slinux.ru Simply Linux])<br />
* [[Branches/5.0|Branch 5.0]] — 2008, осень (выпуск дистрибутивов отменён)<br />
* [[Branches/4.1|Branch 4.1]] — 2008, весна (закрыта)<br />
* [[Branches/4.0|Branch 4.0]] — 2007, весна (закрыта)<br />
* [[Branches/3.1|Branch 3.1]] — 2006, осень (отменена)<br />
* [[Branches/3.0|Branch 3.0]] — 2005, осень (закрыта)<br />
<br />
Дистрибутивы с версиями ниже 3.0 выпускались без предварительного создания стабильной ветки. Вместо этого Sisyphus замораживался на время релиза.<br />
<br />
Репозитории остаются публично доступными и после окончания поддержки.<br />
<br />
== Политика выпуска ==<br />
* [[Branches/Release|Устаревшая политика выпуска версий]].<br />
<br />
[[en:Stable branches]]<br />
<br />
{{Category navigation|title=Branches|category=Branches|sortkey=*}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%93%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0&diff=57989Главная страница2021-12-24T10:56:19Z<p>AntonFarygin: </p>
<hr />
<div>__NOTOC__<br />
<br />
[[Изображение:Gnome-media-optical.svg]] '''[[Пользователю]]''' &nbsp;<br />
[[Изображение:Gnome-preferences-system.svg]] '''[[Sysadmin|Системному администратору]]''' &nbsp;<br />
[[Изображение:Gnome-applications-development.svg]] '''[[Sisyphus|Разработчику]]''' &nbsp;<br />
[[Изображение:Migration.png]] '''[[Миграция]]''' &nbsp;<br />
<span class="plainlinks" style="background-color: #ffc905; padding: 12px 16px; font-weight: bold;border-radius: 5px;">[https://getalt.org ЗАГРУЗИТЬ «АЛЬТ»]</span><br />
<br />
----<br />
{| style="float: right;"<br />
|-<br />
|<br />
<br />
{| style="border:1px solid #AAA; background:#F9F9FF; width:250px; margin: 0 0 1em 1em; padding:.2em; text-align:left; " class=noprint<br />
|-<br />
|[[Изображение:ru.png|right]]<br />
* '''[[:en:Main Page|English]]'''<br />
* '''[[:uk:Main Page|Українська]]'''<br />
----<br />
* [[Статистика wiki]]<br />
<!-- * [http://altlinux.com.br/wiki/ Português] --><br />
|}<br />
<br />
{| style="border:1px solid #AAA; background:#F9F9FF; width:250px; margin: 0 0 1em 1em; padding:.2em; text-align:left; " class=noprint<br />
|-<br />
|<br />
'''Выпуски'''<br />
* [[Образование]]<br />
* [[Workstation]]<br />
* [[Simply Linux]]<br />
* [[KWorkstation]]<br />
* [[Starterkits]]<br />
* [[Rescue]]<br />
* [[Releases|все]] | [[Releases/Download|скачать]]<br />
'''Популярные страницы'''<br />
* [[Install|Установка и обновление программ]]<br />
* [[Write|Запись на DVD и USB Flash]]<br />
* [[Su|Как получить права суперпользователя]]<br />
* [[Эльбрус]]<br />
|}<br />
<!--<br />
{| style="border:4px solid #0F9528;background:#E3FFC7;width:200px; margin: 0 0 1em 1em; padding:.2em; text-align:left;border-radius: 9px;float:right;" class=noprint<br />
|-<br />
|<br />
<center>[[Image:Bug-slanted.png]]<br />
'''17 сентября 2011 года, суббота'''<br />
----<br />
[[BugDay|Cубботник по исправлению ошибок]]</center><br />
|}<br />
--><br />
|}<br />
<br />
[[Изображение:Gnome-stock_person.svg]] '''Об ALT Linux'''<br />
* [[ALT Linux Team]] (команда ALT Linux)<br />
* [[Sisyphus|Сизиф]] ([[Что такое Sisyphus?]]) — см. тж. [[Changes|метеосводку]]<br />
* [https://docs.altlinux.org Документация ALT Linux Team/Базальт СПО]<br />
* [https://packages.altlinux.org/ru/sisyphus/ База данных пакетов и обновлений]<br />
* [[Компания «Альт Линукс»]]<br />
* [[Компания «Базальт СПО»]]<br />
* [https://www.basealt.ru/products/ Покупка дистрибутивов]<br />
* [[FAQ|Часто задаваемые вопросы и ответы на них]] (FAQ)<br />
* [[Обновление ОС]] (тоже FAQ :)<br />
* [[Features|Особенности операционной системы ALT Linux]]<br />
* [[BugTracking|Сообщить об ошибке]]<br />
<br />
[[Изображение:Internet-group-chat.svg]] '''Общение'''<br />
* [[MailingLists|Списки рассылки]]<br />
* [http://forum.altlinux.org/ Форум]<br />
* [https://telegram.me/alt_linux Telegram]<br />
* Matrix (Element, Nheko): [https://matrix.to/#/#altlinux-ru:matrix.org #altlinux-ru:matrix.org]<br />
<!--* [http://planet.altlinux.org/ Планета] (блоги)--><br />
* [https://vk.com/altlinux ВКонтакте] (+[https://vk.com/simplylinux Simply]), [https://www.facebook.com/groups/136328550579/ Facebook]<br />
* [[IRC|IRC]]<br />
* [[Contacts|Контакты]]<br />
<br />
[[Image:Applications-graphics.svg]] '''Медиа'''<br />
* [[Логотипы]]<br />
* [[Журнал ALT-review]]<br />
<br />
[[Изображение:Compat.png]] '''Совместимость'''<br />
* [[HCL|Совместимое оборудование]]<br />
* [[:Категория:Enterprise Software|Совместимость стороннего программного обеспечения]]<br />
<br />
<br />
[[Категория:ALT Linux|*]]<br />
<br />
[[en:Main Page]]<br />
[[uk:Main Page]]<br />
<!-- [[pt:Página_principal]]--></div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%9E%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5:%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog&diff=56703Обсуждение:Руководство по написанию changelog2021-10-20T10:53:30Z<p>AntonFarygin: </p>
<hr />
<div>Удаление информации об авторстве кода, включая строки spec — недопустимо и является нарушением авторского права.<br />
Не обязательно сохранять весь changelog в неизменном виде, но обязательно сохранять перечень всех авторов. -- (это был @Bircoph)<br />
<br />
Мне кажется, это жестко можно требовать только для лицензий типа OLD BSD, где необходимо упоминание авторства непосредственно ''в исходном тексте''. Однако непонятно, где ещё сохранить автора ''спека'' — обычно они больше ничего не пишет) Так что да, лучше changelog вообще не трогать, всем будет проще. -- @FrBrGeorge<br />
<br />
В этом я не согласен - specfile помимо самой инструкции по сборке ещё сохраняет историю сборок этого пакета в репозиторий. Т.е. - фактически, сохранив changelog мы утверждаем что данный пакет был собран под ALT теми, кто про это ничего не знает. Мне кажется, что у нас обсуждался вопрос сохранения changelog спек-файла в отдельном файле или упоминание авторов в комментариях. Но я видел очень много заимствованных spec-файлов в других репозиториев и ещё не встречал такого, что бы changelog _пакета_ содержал людей, которые этот _пакет_ никогда не собирали. -- @rider</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog&diff=56698Руководство по написанию changelog2021-10-20T07:49:07Z<p>AntonFarygin: Содержимое изменено в соответствии с фактически используемым подходом к заимствованию spec-файлов</p>
<hr />
<div>[[Категория:Руководства]]<br />
[[category:RPM spec]]<br />
[[category:devel]]<br />
<br />
__TOC__<br />
Этот документ описывает рекомендуемые правила оформления секции <tt>%changelog</tt> spec-файла пакета и характер/объём включаемой в неё информации.<br />
== Термины ==<br />
Пример секции:<br />
<pre>* Wed Apr 02 2008 Andrey Rahmatullin <wrar@altlinux> 4.6.2-alt7.pre1<br />
[ Andrey Rahmatullin ]<br />
- syntax:<br />
+ recognize .hh and .hpp as c++ again<br />
+ recognize man pages with additional suffixes other than 'x', such as<br />
write.3p (Debian)<br />
<br />
[ Vladislav Primerov ]<br />
- make visible_tabs and visible_tws mcedit options configurable through config<br />
file (Debian)<br />
<br />
[ Alexander Sluchainyi ]<br />
- specfile cleanup<br />
<br />
* Sat Mar 29 2008 Andrey Rahmatullin <wrar@altlinux> 4.6.2-alt6.pre1<br />
- build with slang2</pre><br />
<br />
Здесь<br />
; запись<br />
: Всё, что относится к сборке 4.6.2-alt7.pre1<br />
; группа<br />
: имя в квадратных скобках<br />
; пункт<br />
: текст, начинающийся с дефиса («- make visible_tabs and visible_tws mcedit options configurable through config file (Debian)»)<br />
; подпункт<br />
: текст, начинающийся с плюса («+ recognize man pages with additional suffixes other than 'x', such as write.3p (Debian)»)<br />
; строка<br />
: одна строка файла спека («- make visible_tabs and visible_tws mcedit options configurable through config»)<br />
<br />
== Синтаксис чейнджлога ==<br />
* (Опциональная) группа состоит из имени в квадратных скобках и начинается с первой позиции строки.<br />
* Пункт верхнего уровня начинается с 1-й позиции в строке и состоит из дефиса, пробела и собственно текста.<br />
* Подпункт начинается с 3-й позиции в строке и состоит из плюса, пробела и собственно текста.<br />
* Строки переносятся по словам и содержат не более 78 символов. При этом текст новой строки выравнивается по началу текста предыдущей (то есть 3-я позиция для пунктов верхнего уровня и 5-я для подпунктов).<br />
* Начинать новую строку с символа # нельзя (такая строка будет воспринята как комментарий).<br />
* При использовании макросов следует экранировать символ "%" ещё одним "%" во избежание раскрытия оных, т.е. напрмер вместо <tt>%name</tt> следует записать <tt>%%name</tt>.<br />
<br />
Пример:<br />
- syntax:<br />
+ recognize .hh and .hpp as c++ again<br />
+ recognize man pages with additional suffixes other than 'x', such as<br />
write.3p (Debian)<br />
- make visible_tabs and visible_tws mcedit options configurable through config<br />
file (Debian)<br />
<br />
== Содержимое ==<br />
* '''Чейнджлог (обязательно!) пишется на английском языке.'''<br />
* При сборке новой upstream-версии это указывается первым пунктом.<br />
** При сборке из снэпшота системы контроля версий необходимо указать информацию, позволяющую идентифицировать это снэпшот (дата и время для CVS, ревизия SVN, 8 первых символов идентификатора коммита для git, mtn, bzr, hg, либо вывод git-describe для git).<br />
* Если в сборке версии существенно принимало участие более одного человека, то изменения, вносимые разными людьми, собираются в группы по авторам, иначе группы не нужны.<br />
'''Информация об уязвимостях (CVE и т.д.) в Changelog обязана соответствовать [[Vulnerability_Policy]].'''<br />
* '''Изменения, произведённые апстримом (кроме исправлений ошибок безопасности), в чейнджлоге не указываются (для этого есть чейнджлоги апстрима, зачастую включаемые в пакет).'''<br />
* Косметические изменения спек-файла, не влияющие на получаемый пакет, указываются максимум одной строкой («<tt>spec cleanup</tt>»), либо не указываются вовсе. Это не относится к исправлениям тега License, изменениям параметров сборки и т. д.<br />
* Исправления, необходимые для успешной сборки, соответствия требованиям ALT Linux и т. д., не указываются, если они были сопряжены с упаковкой новой версии и для старой версии были не нужны (эти исправления — адаптация новой версии, то есть часть процесса её упаковки). Если же они были вызваны изменением требований либо окружения, желательно это указать (пример: «fix FTBFS with new autotools», [[Sisyphus/FTBFS|FTBFS]] == failure to build from source).<br />
* '''Если .spec-файл адаптирован из другого дистрибутива, то старые записи %changelog обязательно должны быть удалены''' (записи в %changelog фактически являются информацией о сборке данного пакета под ALT их недопустимо оставлять в истории, т.к. пакет собирается под ALT первый раз), но при этом желательно сделать упоминание дистрибутива-донора в первой записи changelog, информирующей о первой сборке пакета под ALT Linux.<br />
* Используйте спеллчекер :)<br />
<br />
== Указание источников и контекста ==<br />
* Если изменение взято извне либо основано на взятом извне, в соответствующем изменению пункте чейнджлога в скобках указывается источник. Это может быть название дистрибутива/репозитория, название внешней BTS и номер бага в ней, ID участника ALT Linux Team или произвольное указание на человека или сайт. Здесь под изменением подразумевается готовый патч, адаптированный патч или иные аналогичные указания.<br />
Примеры:<br />
- move global configs to /etc (RH)<br />
- linked libnetpbm.so against -lm (RH #165980)<br />
- use optflags (drool@)<br />
<br />
== Автозакрытие багов ==<br />
* Если изменение связано с багрепортом из [[altbug:|bugzilla.altlinux.org]], в соответствующем пункте можно указать (по вкусу; регистр не учитывается, но обязательно в скобках):<br />
** <tt>(Closes: NNNN)</tt><br />
** <tt>(ALT NNNN)</tt><br />
** <tt>(ALT bug NNNN)</tt><br />
с опциональным знаком <tt>#</tt> перед номером бага. Можно также указать несколько багов: <tt>(Closes: NNNN, MMMM, ZZZZ)</tt>. Синтаксис такого рода закрывает указанный баг после прохождения пакета в репозиторий при условии присутствия соответствующей записи в выводе {{cmd|rpmquery --lastchange}}.<br />
* Номера багов в скобках разделяются запятыми.<br />
Примеры:<br />
- add option to build with libslang2 (closes: 10591)<br />
- recognize .3gp as video, not manpage (ALT #14982, #14999)<br />
<br />
Обратите внимание, что других слов в скобках при этом нельзя указывать.<br />
<br />
'''Полный regexp для поиска номеров багов в changelog можно посмотреть [http://git.altlinux.org/people/ldv/packages/?p=girar.git;a=blob;f=gb/gb-x-parse-bugs-from-changelog;hb=HEAD здесь].'''<br />
<br />
== Указание устраненных уязвимостей ==<br />
{{main|Vulnerability Policy}}<br />
<br />
== Лучшие практики оформления changelog ==<br />
<br />
* Если changelog пакета оформлен единообразно, не нарушайте это единообразие (если оно не противоречит этому руководству). Если же changelog хаотичен, то оставленный перед changelog комментарий о рекомендуемом стиле ведения changelog поможет избежать продолжения хаоса в будущем.<br />
* Старайтесь, чтобы все предложения в changelog были в одной форме («fix memory leaks», «fixed memory leaks», «memory leaks fixed»), в таком виде их гораздо удобнее читать.<br />
* Единообразно оформляйте предложения changelog’а: либо начинайте, либо не начинайте их все с большой буквы; либо заканчивайте, либо не заканчивайте их точкой.<br />
* Группировка сходных пунктов в подпункты позволяет уменьшить размер changelog’а и улучшить его читаемость.<br />
<br />
== Разное ==<br />
<br />
* Для форматирования changelog существует команднострочная утилита [[add_changelog]], а также макросы для [[редактирование changelog в Vim|Vim]] и [[редактирование changelog в Emacs|Emacs]].<br />
* [[Changelogs guide/example|Пример хорошего changelog’а]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=APT_%D0%B2_ALT_Linux/CreateRepositoryMirror&diff=56390APT в ALT Linux/CreateRepositoryMirror2021-09-23T06:11:34Z<p>AntonFarygin: </p>
<hr />
<div>[[en:Mirror]]<br />
= Существующие зеркала =<br />
{{main|Download}}<br />
<br />
= Создание =<br />
== rsync ==<br />
<br />
Наименее затратным по времени и трафику является использование для зеркалирования <tt>rsync</tt>. Хотя возможно и ручное зеркалирование, удобнее воспользоваться инструментом, который называется [[sisyphus-mirror]]; существует также веб-интерфейс в виде [[Alterator-mirror|{{pkg|alterator-mirror}}]].<br />
<br />
Для исключения части пакетов из зеркалирования (например, игрушек, которые часто весьма объёмны) можно воспользоваться [http://sisyphus.ru/rsync/ сервисом], позволяющим отфильтровать пакеты по RPM-группе. Полученный список можно добавить в аргумент --exclude-from к rsync или в exclude-файл <tt>sisyphus-mirror</tt>.<br />
<br />
Перед собственно зеркалированием можно запустить rsync с ключом -n для оценки трафика.<br />
<br />
=== <tt>sisyphus-mirror</tt> ===<br />
<br />
Смотри [[sisyphus-mirror]]<br />
<br />
=== Ручное зеркалирование ===<br />
<br />
Пример:<br />
<source lang="bash"><br />
rsync -va --stats --delete-after rsync.altlinux.org::ALTLinux/Sisyphus/ /srv/public/mirror/Sisyphus/<br />
</source><br />
<br />
Также можно [http://sisyphus.ru/ru/rsync.shtml сформировать] exclude-file, позволяющий не зеркалировать ненужные пакеты.<br />
<source lang="bash"><br />
rsync -va --stats --delete-after --exclude-from=/path/to/exclude-file \<br />
rsync.altlinux.org::ALTLinux/Sisyphus/ /srv/public/mirror/Sisyphus/<br />
</source><br />
<br />
'''При использовании exclude-file подразумевается, что замкнутость и работоспособность загруженного репозитория не гарантируется и возлагается на конечного пользователя.'''<br />
<br />
Для зеркалирования [[branches|стабильной ветки]] замените <tt>Sisyphus</tt> на, например, <tt>p8/branch/</tt><br />
<br />
== HTTP/FTP ==<br />
<br />
NB: Использование HTTP и FTP для зеркал APT-репозиториев ALT Linux и Sisyphus неэкономично по трафику по сравнению с rsync из-за специфичной структуры репозиториев.<br />
<br />
Пример:<br />
<source lang="bash"><br />
mkdir -p /srv/public/mirror<br />
cd /srv/public/mirror<br />
wget \<br />
--mirror \<br />
--convert-links \<br />
--backup-converted \<br />
--html-extension \ <br />
http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/<br />
</source><br />
<br />
= Использование =<br />
{{path|/etc/apt/apt.conf.local}}:<br />
Dir::Etc::main "/dev/null";<br />
Dir::Etc::parts "/var/empty";<br />
Dir::Etc::SourceParts "/var/empty";<br />
Dir::Etc::sourcelist "/etc/apt/sources.list.local";<br />
<br />
{{path|/etc/apt/sources.list.local}} для i586:<br />
rpm file:/srv/public/mirror/Sisyphus i586 classic<br />
rpm file:/srv/public/mirror/Sisyphus noarch classic<br />
#rpm-dir file:/home/me/hasher/repo i586 hasher<br />
<br />
{{path|/etc/apt/sources.list.local}} для x86_64:<br />
rpm file:/srv/public/mirror/Sisyphus x86_64 classic<br />
rpm file:/srv/public/mirror/Sisyphus noarch classic<br />
#rpm-dir file:/home/me/hasher/repo x86_64 hasher<br />
<br />
{{Category navigation|title=APT|category=APT|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%94%D0%B5%D1%81%D1%8F%D1%82%D0%B0%D1%8F_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0&diff=55262Десятая платформа2021-07-29T15:04:39Z<p>AntonFarygin: </p>
<hr />
<div>{{Stub}}<br />
<br />
<!-- ссылки на коллег:<br />
''[http://www.opennet.ru/opennews/art.shtml?num=51041 дебиановские замечания к выпуску] (opennet)''<br />
--><br />
<br />
[[Категория:Branches]]<br />
[[Категория:Миграция]]<br />
[[en:ALT Linux Wiki:TenPlatform]]<br />
<br />
Десятая платформа p10 (Aronia), новая стабильная ветка репозиториев ALT, предназначена для разработки, тестирования, распространения, обновления и поддержки комплексных решений всех уровней — от встроенных устройств до серверов предприятий и датацентров, созданная и развиваемая в рамках проекта Sisyphus командой ALT ([[ALT Linux Team]]). Десятая платформа поддерживается [http://basealt.ru ООО «Базальт СПО»].<br />
<br />
__TOC__<br />
<div id="whatsnew"></div><br />
== Что нового? ==<br />
<br />
=== Архитектуры Десятой платформы ===<br />
<br />
Синхронная сборка p10 производится для пяти основных [[ports|архитектур]]:<br />
<br />
* 64-битных x86_64, aarch64 и ppc64le<br />
* 32-битных i586, armh (armv7hf)<br />
<br />
Для 32-битной архитектуры mipsel бранч p10 не создается, поддержка mipsel в p9 осуществляется в заявленные сроки.<br />
<br />
Производится также сборка для трех версий закрытой 64-битной [[эльбрус/архитектура|архитектуры "Эльбрус"]]:<br />
<br />
* e2k (v3, 4С) и e2kv4 (8С/1С+);<br />
* новой e2kv5 (8СВ).<br />
<br />
Для архитектур e2k бранчевание p10 намечено на сентябрь 2021 года.<br />
<br />
В середине 202''1'' года планируется отделение бранча p10 архитектуры RISC-V64.<br />
<br />
=== Ядра реального времени ===<br />
<br />
Для архитектуры x86_64 собраны два ядра [[Realtime]] : Xenomai и Real Time Linux.<br />
<br />
=== OpenUDS — решение для VDI ===<br />
<br />
[[VDI/OpenUDS|OpenUDS]] — это многоплатформенный брокер подключений для создания и управления виртуальными рабочими местами и приложениями. Пользователь VDI через браузер выбирает шаблон и с помощью клиента ([[xrdp|RDP]], [[X2Go]]) подключается к своему рабочему столу на терминальном сервере или в виртуальной машине в облаке [[OpenNebula]].<br />
<br />
=== Расширение набора групповых политик ===<br />
<br />
[[Групповые политики]] поддерживают параметры gsettings для управления рабочими средами Mate и XFCE.<br />
<br />
=== Центр администрирования Active Directory ===<br />
<br />
{{pkg|admс}} — графическое приложение для управления пользователями, группами и групповыми политиками домена Active Directory, аналогичный [https://wiki.samba.org/index.php/Installing_RSAT_on_Windows_for_AD_Management Remote Server Administration Tools] под Microsoft Windows.<br />
<br />
[[Файл:Admc-ou-edit.png]]<br />
<br />
=== Расширение платформы deploy ===<br />
<br />
Платформа [[Deploy]] предназначена для разворачивания и настройки ролей (например, PostgreSQL или Moodle). Добавлены следующие роли:<br />
* apache<br />
* mariadb<br />
* mediawiki<br />
* moodle<br />
* nextcloud<br />
<br />
При этом для ролей {{term|mediawiki}}, {{term|moodle}} и {{term|nextcloud}} можно изменять пароль администратора, не заботясь о внутренней реализации в том или ином веб-приложении.<br />
<br />
=== alterator-multiseat ===<br />
<br />
Модуль настройки многотерминального режима [[Alterator-multiseat]].<br />
<br />
=== Поддержка платы устройств на базе процессоров Байкал-М ===<br />
<br />
Поддержка платы [https://edelweiss-tech.ru/product/komplektuyushchie-edelveys/platy-edelveys/plata-na-baykal-m/ tf307-mb] на процессоре ''Байкал-М'' ([https://www.baikalelectronics.ru/products/238/ BE-M1000]) с ревизиями S-D и MB-A0 с [https://share.baikalelectronics.ru/index.php/s/BGX49njz2Wg98Lc SDK-M-5.2]. А также поддержка платы [https://ru.lagrangeproject.com/carrier-boards Lagrange LGB-01B (mini-ITX)].<br />
<br />
== Версии подсистем и пакетов ==<br />
Репозитории Деcятой платформы будут обновляться в течение срока поддержки. На момент официального анонса '''p10''' они содержат в том числе:<br />
<br />
{|class="standard"<br />
!ПО<br />
!Версия<br />
|-<br />
|Ядро Linux (std-def)||5.10.51<br />
|-<br />
|Ядро Linux (un-def)||5.12.18<br />
|-<br />
|Ядро Real Time Linux (rt)||5.10.47<br />
|-<br />
|Ядро Realtime Xenomai (xenomai)||4.19.192<br />
|-<br />
|Ядро Linux ([[OpenVZ7|ovz-el7]])||3.10.0-1160.31.1.vz7.181.9<br />
|-<br />
|[[systemd]]||249.1<br />
|-<br />
|[[sysvinit]]||2.88<br />
|-<br />
|GNU Libc||2.32<br />
|-<br />
|selinux||3.2<br />
|-<br />
|GCC||10.3.1<br />
|-<br />
|[[LLVM]]||12.0 и 11.01<br />
|-<br />
|Python||3.9.6 и 2.7.18<br />
|-<br />
|Perl||5.34.0<br />
|-<br />
|PHP||8.0 и 7.4<br />
|-<br />
|Ruby||2.7.3<br />
|-<br />
|Java||11.0.9.11<br />
|-<br />
|Rust||1.53<br />
|-<br />
|Mono||6.12.0.122<br />
|-<br />
|.NET Core||6.0<br />
|-<br />
|Node||14.17.2<br />
|-<br />
|X.Org Server||1.20.12<br />
|-<br />
|Mesa||21.1.5<br />
|-<br />
|[[GNOME]]||40.3 <!-- по gnome-shell, спрашивал когда-то aris@ ради changelog регулярок // mike@ --><br />
|-<br />
|[[KDE|KDE Frameworks]]||5.84.0<br />
|-<br />
|[[KDE|KDE Plasma Desktop]]||5.22.3<br />
|-<br />
|[[MATE]]||1.24.1<br />
|-<br />
|[[Xfce]]||4.16.0<br />
|-<br />
|[[Enlightenment]]||0.24.2<br />
|-<br />
|[[Cinnamon]]||5.0.3<br />
|-<br />
|[[LXQt]]||{{pkg|liblxqt}} 0.17.0<br />
|-<br />
|[[Starterkits/gnustep|GNUstep]]||{{pkg|gnustep-base}} 1.28.0<br />
|-<br />
|[[Deepin]]|| 5, {{pkg|deepin-desktop-base}} 2021.06.16 <br />
|-<br />
|[[IceWM]]||2.6.0<br />
|-<br />
|[[Firefox]]||90.0.1, {{pkg|firefox-esr}} 78.12.0<br />
|-<br />
|[[Thunderbird]]||78.12.0<br />
|-<br />
|[[Chromium]]||91.0.4472.164, {{pkg|chromium-gost}} 91.0.4472.114<br />
|-<br />
|LibreOffice||7.2.0.1 {{pkg|LibreOffice-still}} 7.0.6.2<br />
|-<br />
|Rosegarden||21.0.6<br />
|- <br />
|Calligra||3.2.1<br />
|- <br />
|GCompis-qt||1.1<br />
|- <br />
|[[Samba]]||4.14.6 (с [[SambaDC|samba-dc]])<br />
|-<br />
|Bash||4.4.23<br />
|-<br />
|[[BIND]]||9.11.32<br />
|-<br />
|[[CUPS]]||2.3.3<br />
|-<br />
|[[dhcp]]||4.4.2<br />
|-<br />
|[[Apache2|Apache httpd]]||2.4.48<br />
|-<br />
|nginx||1.20.1<br />
|-<br />
|MariaDB||10.4.20 <!-- см. тж. [[MySQL]] --><br />
|-<br />
|[[PostgreSQL]]||13.3, 12.6 для [[1C]]<br />
|-<br />
|[[Postfix]]||3.6.0<br />
|-<br />
|[[Dovecot]]||2.3.14<br />
|-<br />
|[[SOGo]]||5.1.1<br />
|-<br />
|[[ГОСТ в OpenSSL|OpenSSL]]||1.1.1k<br />
|-<br />
|GTK+||3.24.30<br />
|-<br />
|Qt||5.15.2<br />
|-<br />
|Tomcat||9.0.45<br />
|-<br />
|[[Docker]]||20.10.7<br />
|-<br />
|[[PVE]]||6.3.3<br />
|-<br />
|[[Kubernetes]]||1.20.8<br />
|-<br />
|[[OpenNebula]]||5.10.5<br />
|-<br />
|[[VDI/OpenUDS|OpenUDS]]||3.0.0<br />
|-<br />
|[[Ansible]]||2.9.24<br />
|-<br />
|[[Puppet]]||7.9.0<br />
|}<br />
<br />
Состав и версии других пакетов можно посмотреть на сайте [http://packages.altlinux.org/ru/p10/home/ packages.altlinux.org].<br />
<br />
<div id="starterkits"></div><br />
<br />
== Быстрое начало работы с репозиториями Десятой платформы ==<br />
<br />
===Стартовые наборы (starterkits)===<br />
<br />
Многие пользователи, предпочитающие и умеющие самостоятельно определять состав системы и ее оформление, оценят возможность использовать для начала работы с новой платформой небольшие установочные образы с различными окружениями рабочего стола. Для реализации такого стиля работы с репозиториями Десятой платформы созданы и доступны образы комплектов входа (starter kits) для архитектур [http://nightly.altlinux.org/p10/release/ x86_64, i586], [http://nightly.altlinux.org/p10-aarch64/release/ aarch64], [http://nightly.altlinux.org/p10-armh/release/ armh] (окружения рабочего стола Cinnamon, GNOME, IceWM, KDE5, LXDE, '''LXQt''', '''MATE''', GNUstep, '''Xfce''', а также '''минимальный инсталятор (JeOS)''', и серверный инсталятор ; выделенные варианты доступны в сборках для всех поддерживаемых архитектур).<br />
<br />
Владельцам ВК «[[Эльбрус]]» ''будут'' доступны стартовые наборы Cinnamon, LXQt, MATE, Xfce для [[ports/e2k|e2k/e2kv4]].<br />
<br />
<!--По сравнению с p9 варианты ... TDE и KDE4 исключены в связи с прекращением поддержки в репозитории; вариант WindowMaker убран как дублирующий GNUStep, где является по сути основой; вариант Enlightenment отложен для более тщательной [https://bugzilla.altlinux.org/show_bug.cgi?id=36913 проверки].--><br />
<br />
Ассортимент образов входа в p10 расширяется с выпуском обновлений, которые поставлены в плановый квартальный режим (с надлежащим тестированием). Экспериментальные сборки бывают доступны [http://nightly.altlinux.org/p10/beta/ здесь] и в аналогичных подкаталогах для иных архитектур.<br />
<br />
{{Attention|Важно заметить, что '''образы для начала работы с p10 не являются дистрибутивами''', так как не содержат ни законченных решений, ни целостного оформления, но предоставляют лишь основу.}}<br />
<br />
{{main|starterkits}}<br />
<br />
<!--<br />
===Официальные образы Docker===<br />
Официальный образ десятой платформы (p10) расположен на сайте https://hub.docker.com/, его можно получить по ссылке https://hub.docker.com/_/alt/. Официальный образ доступен для архитектур: aarch64, i586, ppc64le и x86_64.<br />
<br />
{{main|Docker}}<br />
<br />
===Образы lxc/lxd===<br />
Официальные образы десятой платформы (p10) для lxc и lxd расположены на сайте https://images.linuxcontainers.org. Официальные образы доступны для архитектур: aarch64, i586, ppc64le и x86_64.<br />
<br />
{{main|LXD}}<br />
--><br />
<br />
== Дистрибутивные решения на Десятой платформе ==<br />
<br />
=== Скачать образы ===<br />
<br />
{{Note|Образы дистрибутивов ожидаются осенью 2021 года.}}<br />
<br />
<!--<br />
Доступны выпуски дистрибутивов:<br />
* [[Альт Рабочая станция 9]];<br />
* [[Альт Рабочая Станция К 9]];<br />
* [[Альт Сервер 9]];<br />
* [[Альт Сервер В 9]] (Сервер виртуализации);<br />
* [[Альт Образование 9]];<br />
* [[Simply Linux 9]];<br />
а также [[Starterkits/Download|стартовые наборы]] и бета-версия дистрибутива [[Альт Рабочая Станция К 9]].<br />
<br />
При перегрузке основного сервера пользуйтесь [http://mirror.yandex.ru/altlinux/p9/images/ яндекс-зеркалом] либо [http://torrent.altlinux.org/ торрентами].<br />
--><br />
<br />
== Обновление системы до Десятой платформы ==<br />
При переходе на Десятую платформу с установленной системы внимательно прочитайте [[Update/p10|рекомендации по обновлению]]. В случае затруднений не торопитесь, задайте вопрос в [http://lists.altlinux.org/mailman/listinfo/community/ списке рассылки] или на [http://forum.altlinux.org/ нашем форуме].<br />
<br />
== Известные проблемы ==<br />
<br />
Основной метабаг по ошибкам и пожеланиям на Десятую платформу: {{Altbug|40561}}<br />
<br />
= Пакетная база =<br />
{{:Branches/p10}}<br />
<br />
= Выпуск =<br />
<br />
== Выпуск репозитория ==<br />
<br />
22 июля 2021 года<br />
<br />
= Поддержка =<br />
<br />
<div style="border-left:3px solid #2590B7;border-right:3px solid #2590B7;padding:7px;margin-top: 7px;margin-bottom: 7px;background-color:#E0EEF3;">В части обновлений по безопасности поддержка репозитория будет закончена '''31 мая 2024''' года, но не ранее полугода после выпуска следующей платформы (p11). Сроки поддержки продуктов на основе Десятой платформы могут быть иными.</div><br />
<div id="repos"></div></div>AntonFaryginhttps://www.altlinux.org/index.php?title=Etcnet&diff=54486Etcnet2021-06-02T05:12:56Z<p>AntonFarygin: /* Linux bridge посредством iproute2 (начиная с p9) */</p>
<hr />
<div>{{DISPLAYTITLE:etcnet}}<br />
{{span|font-size: 180%|Подсказки пользователю /etc/net}}<br />
<br />
{|<br />
|-valign="top"<br />
|Дополнительные страницы:<br />
* [[etcnet/qos|настройка QoS]]<br />
* [[etcnet/firewall|настройка сетевого экрана (firewall)]]<br />
Совсем быстрая настройка «с нуля»:<br />
# сконфигурируйте интерфейсы вручную, как надо;<br />
# запустите {{cmd|/etc/net/scripts/contrib/initconf write}};<br />
# проверьте содержимое подкаталогов {{path|/etc/net/ifaces/}}.<br />
|<br />
{| style="border:1px solid #AAA; background:#F9F9F9; width:280px; margin: 0 0 1em 1em; padding:.2em; text-align:center;" class=noprint<br />
|-<br />
|[[Image:Information.svg|20x20px]]Начиная с [[Branches/p5|пятой ветки]],<br /> <div style="display: inline; color: red;">в ALT Linux может использоваться и<br />[[NetworkManager/feature|NetworkManager]]</div> (используйте <tt>NM_CONTROLLED=no</tt><br />в {{path|$iface/options}}, если хотите использовать etcnet).<br />
|}<br />
|<br />
{| style="border:1px solid #AAA; background:#F9F9F9; width:155px; margin: 0 0 1em 1em; padding:.2em; float: right;" class=noprint<br />
|-<br />
|[[Image:Information.svg|20x20px]] external links:<br />
* [http://packages.altlinux.org/ru/Sisyphus/srpms/etcnet package info]<br />
* [http://git.altlinux.org/people/sbolshakov/packages/?p=etcnet.git;a=summary source git repo]<br />
|}<br />
|}<br />
<br />
<!-- Не убирайте div-ы, на них есть внешние ссылки! --><br />
<div id="quickstart"></div><br />
<br />
== Быстрый старт ==<br />
<div id="docs"></div><br />
<br />
=== Источники информации по /etc/net ===<br />
Обратите внимание, что начиная с версии 0.8.0 документация по /etc/net была собрана из комментариев, расположенных во множестве файлов, в несколько страниц руководств (man). Список всех файлов документации пакета <tt>etcnet</tt> можно получить командой:<br />
<pre>$ rpmquery -d etcnet</pre><br />
<br />
<div id="onecard"></div><br />
<br />
=== Быстрая настройка сетевого интерфейса стандарта Ethernet ===<br />
Для настройки одного сетевого интерфейса следует выполнить следующие шаги:<br />
<br />
Шаг 1: Создать каталог {{path|/etc/net/ifaces/eth0}}. Это каталог конфигурации данного интерфейса (<tt>eth0</tt>), в котором будут храниться файлы с настройками.<br />
<br />
Шаг 2: Определить, какой модуль необходим для вашей сетевой карты. Для этого можно использовать команды: <tt>lspci, lspcidrake, pciscan</tt>.<br />
<br />
Шаг 3: В каталоге конфигурации сетевого интерфейса создать файл <tt>options</tt> и записать в этот файл строку:<br />
<pre>MODULE=<имя модуля></pre> <br />
На данном этапе работу с файлом <tt>options</tt> можно завершить.<br />
<div style='padding:6px;border:1px solid red;'>Шаг 3 имеет смысл только в случае, если модули сетевых карт не грузятся автоматически другими средствами, например посредством udev. Если модуль уже загружен, параметр MODULE бесполезен.</div><br />
<br />
Шаг 4: Выяснить, какой IP-адрес должен быть назначен вашему интерфейсу. Если ваш сетевой интерфейс конфигурируется по DHCP, то в файл {{path|/etc/net/ifaces/eth0/options}} следует записать строку:<br />
<pre>BOOTPROTO=dhcp</pre><br />
и перейти к шагу 7.<br />
<br />
'''Замечание:''' В ряде случаев в файле <tt>options</tt> может понадобиться запись:<br />
<pre>DHCP_HOSTNAME=<имя машины без домена></pre><br />
Эта опция описана в странице руководства <tt>etcnet-options(5)</tt>.<br />
<br />
'''Замечание:''' В конце файла <tt>options</tt> необходимо наличие пустой строки.<br />
<br />
У сетевого интерфейса существуют два взаимосвязанных атрибута: <br />
* IP-адрес;<br />
* сетевая маска (mask). <br />
Шаг 5: Текущие значение адреса можно просмотреть командой:<br />
{{cmd|# /sbin/ip address show}} <br />
Вероятнее всего вы увидите, что интерфейс-петля lo (loopback) уже сконфигурирован с адресом 127.0.0.1/8 (что эквивалентно IP-адресу 127.0.0.1 и маске подсети 255.0.0.0). <tt>/8</tt> означает длину префикса CIDR (Classless InterDomain Routing).<br />
Для задания IP-адреса и маски подсети интерфейса <tt>eth0</tt> необходимо создать файл {{path|/etc/net/ifaces/eth0/ipv4address}}, в который следует записать IP-адрес с длиной маски, например:<br />
<pre>10.0.0.20/24</pre> <br />
<br />
Наиболее популярны маски /24 (т.е. длина префикса CIDR равная 24 эквивалентна маске сети 255.255.255.0 - это одна сеть класса C на 254 хоста) и /30. Для справки приводится таблица соответствия сетевых масок в различных нотациях.<br />
<ref><br />
{|<br />
|<br />
{| class="standard"<br />
|-<br />
!маска<br />в битах!!маска<br />точечно-<br />десятичная<br />
|-<br />
|/32||255.255.255.255<br />
|-<br />
|/31||255.255.255.254<br />
|-<br />
|/30||255.255.255.252<br />
|-<br />
|/29||255.255.255.248<br />
|-<br />
|/28||255.255.255.240<br />
|-<br />
|/27||255.255.255.224<br />
|-<br />
|/26||255.255.255.192<br />
|-<br />
|/25||255.255.255.128<br />
|-<br />
|/24||255.255.255.0<br />
|-<br />
|/23||255.255.254.0<br />
|-<br />
|/22||255.255.252.0<br />
|-<br />
|/21||255.255.248.0<br />
|-<br />
|/20||255.255.240.0<br />
|-<br />
|/19||255.255.224.0<br />
|-<br />
|/18||255.255.192.0<br />
|-<br />
|/17||255.255.128.0<br />
|}<br />
|<br />
| ||<br />
{| class="standard"<br />
|-<br />
!маска<br />в битах!!маска<br />точечно-<br />десятичная<br />
|-<br />
|/16||255.255.0.0<br />
|-<br />
|/15||255.254.0.0<br />
|-<br />
|/14||255.252.0.0<br />
|-<br />
|/13||255.248.0.0<br />
|-<br />
|/12||255.240.0.0<br />
|-<br />
|/11||255.224.0.0<br />
|-<br />
|/10||255.192.0.0<br />
|-<br />
|/9||255.128.0.0<br />
|-<br />
|/8||255.0.0.0<br />
|-<br />
|/7||254.0.0.0<br />
|-<br />
|/6||252.0.0.0<br />
|-<br />
|/5||248.0.0.0<br />
|-<br />
|/4||240.0.0.0<br />
|-<br />
|/3||224.0.0.0<br />
|-<br />
|/2||192.0.0.0<br />
|-<br />
|/1||128.0.0.0<br />
|}<br />
|}<br />
</ref><br />
<br />
Шаг 6: Выяснить адрес вашего шлюза (маршрут по умолчанию). Например, IP-адрес вашего шлюза — <tt>10.0.0.254</tt>. Тогда необходимо создать файл {{path|/etc/net/ifaces/eth0/ipv4route}}, в который записать строку:<br />
<pre>default via 10.0.0.254</pre><br />
Шаг 7: Убедиться, что всё выполнено правильно, выполнив команду:<br />
{{cmd|# service network restart}}<br />
Ваш интерфейс <tt>eth0</tt> должен быть успешно сконфигурирован. Если вы конфигурировали <tt>eth0</tt>, используя DHCP-сервер, но адрес интерфейсу не был назначен, то следует искать сообщение от DHCP-сервера в файле {{path|/var/log/messages}}.<br />
<br />
<div id="ifplugd"></div><br />
<br />
=== Настройка ifplugd ===<br />
Начиная с версии 0.7.10, /etc/net управляет ifplugd самостоятельно. Это было сделано для лучшей интеграции пакетов и для возможности следить за несколькими сетевыми интерфейсами одновременно. Для корректного использования ifplugd необходимо выполнить команду:<br />
# chkconfig ifplugd off<br />
<br />
и назначить переменную <tt>USE_IFPLUGD</tt> (USE_IFPLUGD=yes или USE_IFPLUGD=auto) в файлах <tt>options</tt> соответствующих интерфейсов (<tt>/etc/net/ifaces/<имя интерфейса>/options</tt>). Комментарий по данной переменной дан в странице руководства <tt>etcnet-options(5)</tt>.<br />
<br />
<div id="ppp"></div><br />
<br />
=== Настройка PPP-интерфейса ===<br />
Для настройки обычного модемного PPP-соединения необходимо:<br />
# Создать каталог конфигурации PPP-интерфейса, например, {{path|/etc/net/ifaces/ppp5}}. Вы можете задавать имена PPP-интерфейса вида pppN, pppNN, pppNNN и т. п., где N - любая цифра от 0 до 9;<br />
# Прочитать файл: {{path|/etc/net/ifaces/default/options-ppp}};<br />
# Создать файлы конфигурации. Вероятнее всего вам понадобятся <tt>pppconnect</tt> и <tt>pppdisconnect</tt>, чтобы <tt>pppd</tt> "знал", как дозваниваться и соединяться. Это скрипты для программы <tt>chat(8)</tt>. Кроме этого в файле <tt>pppoptions</tt> можно (часто нужно) перечислить опции <tt>pppd(8)</tt>, определяющие способ авторизации, скорость и название порта и т. п.;<br />
# Заполнить {{path|/etc/ppp/chap-secrets}} или {{path|/etc/ppp/pap-secrets}}.<br />
<br />
{{Attention|Использование опций "persist" и "maxfail 0", которые требуются pppd для непрерывных попыток восстановить интерфейс в случае проблем, может привести к невозможности загрузки системы в случае проблем с соединением. Вариант решения есть в {{altbug|23556#c1}} }}<br />
<br />
==== Настройка USB 3G-модема ====<br />
{{main|Установка и настройка 3G USB модема Huawei E1550}}<br />
<br />
<div id="ppp-pptp-pppoe"></div><br />
<br />
==== Настройка PPTP-интерфейса и PPPoE-интерфейса ====<br />
{{main|VPN (PPTP PPPoE)}}<br />
<br />
Хотя PPtP-соединения могут быть настроены и как обычные PPP-соединения, в /etc/net версии 0.7.10 для удобства пользователей была введена опция <tt>PPPTYPE</tt>. Она может принимать следующие значения:<br />
* <tt>dialup</tt> - обычный PPP-интерфейс.<br />
* <tt>pppoe</tt> - интерфейс PPPoE. Для такого интерфейса необходимо в опции <tt>HOST</tt> указывать имя Ethernet-интерфейса, через который будет производиться работа PPPoE. Побочным положительным эффектом будет то, что этот интерфейс будет при необходимости автоматически подниматься (т.е настраиваться) (см. [[#Зависимости между интерфейсами|Зависимости между интерфейсами]]).<br />
* <tt>pptp</tt> - интерфейс PPTP. Для такого интерфейса необходимо в опции <tt>PPTP_SERVER</tt> указывать имя хоста или IP-адрес PPtP-сервера, к которому будет производиться подключение. Обратите внимание, что хотя такие интерфейсы не имеют опции <tt>HOST</tt>, в большинстве случаев есть необходимость указать в опции <tt>REQUIRES</tt> интерфейс, через который будет достижим хост, указанный в <tt>PPTP_SERVER</tt>.<br />
<br />
См. также [[#Замечания о настройке VPN-подключения и туннелей|Замечания о настройке VPN-подключения и туннелей]].<br />
<br />
<div id="DNSandPPP"></div><br />
<br />
==== DNS и PPP-соединения ====<br />
<div style="display: inline; color: red;">Внимание: здесь описывается проблема, которая на самом деле была создана, а не решена — т.е. ради специфики [https://bugzilla.altlinux.org/show_bug.cgi?id=13789 kppp] была создана чётная ошибка в [https://bugzilla.altlinux.org/show_bug.cgi?id=13773 ppp-common]; последняя уже исправлена.</div><br />
<br />
Довольно долгое время существовала проблема неправильной модификации {{path|/etc/resolv.conf}} при установке PPP-соединений: [https://bugzilla.altlinux.org/show_bug.cgi?id=4249 #4249]. Сейчас она решена, но необходимо дать пояснения. Прежде всего убедитесь, что в файле {{path|/etc/resolv.conf}} есть строка:<br />
<pre># ppp temp entry</pre><br />
Если этой строки нет, то в файле не будут модифицироваться строки nameserver, если только какая-нибудь программа типа kppp это не сделает специально. Если такая строка есть, то {{path|/etc/resolv.conf}} будет модифицироваться в зависимости от значения булевой (логической) переменной RESOLV_MODS, которую необходимо задать в файле {{path|/etc/sysconfig/network}}.<br />
<br />
<div style="display: inline; color: red;">Внимание</div>: при ppp-common >= 0.4-alt1 строки <tt># ppp temp entry</tt> в файле {{path|/etc/resolv.conf}} при отсутствии PPP-соединения, поднятого какой-либо программой-«звонилкой», запущенной от администратора системы (пользователь root) — быть '''не должно'''! Если это есть, следует убрать, чтобы {{cmd|/etc/ppp/ip-up}} занимался обновлением записей про DNS в этом файле.<br />
<br />
<div id="restartreload"></div><br />
<br />
=== restart, reload и другие команды ===<br />
У сервиса <tt>network</tt> имеется ряд команд:<br />
* <tt>start</tt> - запустить все стационарные интерфейсы. hotplug-интерфейсы будут сконфигурированы при поступлении соответствующего вызова от hotplug.<br />
* <tt>startwith <имя профиля> </tt> - старт с указанным именем профиля, а не определённым автоматически.<br />
* <tt>stop</tt> - остановить все стационарные интерфейсы. hotplug-интерфейсы будут расконфигурированы при поступлении соответствующего вызова от hotplug.<br />
* <tt>stopwith <имя профиля> </tt> - стоп с указанным именем профиля, а не определённым автоматически.<br />
* <tt>restart</tt> - эквивалентно <tt>stop</tt> с последующим <tt>start</tt>, как и в большинстве других сервисов.<br />
* <tt>restartwith <имя профиля> </tt> - рестарт в контексте указанного профиля, эквивалентно <tt>stopwith <имя профиля> и startwith <имя профиля></tt>.<br />
* <tt>switchto <имя профиля> </tt> - переключение в указанный профиль, эквивалентно <tt>stop</tt> и <tt>startwith <имя профиля></tt>.<br />
* <tt>reload</tt> - семантически обозначает «актуализировать текущую конфигурацию». Для всех сконфигурированных в настоящий момент интерфейсов будет выполнена реконфигурация при наличии конфигурации.<br />
* <tt>check</tt> - автоматическая проверка конфигурационной базы.<br />
<br />
<div id="bootproto"></div><br />
<br />
=== Протоколы конфигурации адресов ===<br />
С помощью опции <tt>BOOTPROTO</tt> вы можете управлять тем, как у интерфейса будут появляться адреса и маршруты (это относится только к протоколу IPv4, так как протоколы IPv6 и IPX получают адреса только статически).<br />
* <tt>static</tt> — адреса и маршруты будут взяты из <tt>ipv4address</tt> и <tt>ipv4route</tt>.<br />
* <tt>dhcp</tt> — интерфейс будет сконфигурирован по DHCP.<br />
* <tt>ipv4ll</tt> — интерфейс будет сконфигурирован с помощью IPv4LL (link-local), ранее известному как ZCIP (zeroconf IP). Это значит, что из сети 169.254.0.0/16 будет подобран ещё не использованный адрес и назначен на интерфейс.<br />
Существует несколько комбинированных способов:<br />
* <tt>dhcp-static</tt> — если конфигурация по DHCP не удалась, конфигурировать методом static.<br />
* <tt>dhcp-ipv4ll</tt> — если конфигурация по DHCP не удалась, конфигурировать методом ipv4ll.<br />
* <tt>dhcp-ipv4ll-static</tt> — если конфигурация по DHCP не удалась, конфигурировать методом ipv4ll. Если и это не удалось, конфигурировать методом static.<br />
<br />
<div id="internals"></div><br />
<br />
=== Интеграция с systemd, или что делать если не поднимается интерфейс при старте. ===<br />
Начиная с версии 0.9.12 в etcnet добавлен Unit для включения интерфейсов по мере их появления в системе. Это позволяет избежать "гонок", когда сетевая подсистема поднимается раньше, чем ОС загружает драйвера для сетевых устройств.<br />
Для этого нужно выставить <tt>ONBOOT=no</tt> в файле options интерфейса и включить его подъём через systemd при загрузке: <tt>systemctl enable network@<имя интерфейса></tt>.<br />
<br />
== Устройство /etc/net ==<br />
<div id="generalinfo"></div><br />
<br />
=== Общие сведения ===<br />
/etc/net — это система конфигурации сети в Linux, т.е. эта система позволяет администратору Linux достаточно просто произвести настройки сети. Если же вы читаете эту страницу, то, вероятно, у вас возникли трудности с её использованием. Для решения возможных проблем полезно знать:<br />
<br />
<!--# [http://etcnet.org/ http://etcnet.org/] - сайт проекта, на котором можно найти примеры конфигурации и статьи по настройке системы. ?Рекурсия? --><br />
# /etc/net интегрирован в ALT Linux Sisyphus в виде пакетов:<br />
#* {{pkg|etcnet}} - базовые сценарии;<br />
#* {{pkg|etcnet-full}} - виртуальный пакет с зависимостями на все пакеты, которые могут использоваться сценариями /etc/net, с указанием их точных версий;<br />
#* {{pkg|etcnetconf}} - '''прототип''' конфигуратора;<br />
#* {{pkg|etcnet-defaults-desktop}} - умолчания для рабочей станции;<br />
#* {{pkg|etcnet-defaults-server}} - умолчания для сервера; <br />
# Пакеты {{pkg|etcnet}} и {{pkg|net-scripts}} — две конфликтующие реализации «подсистемы конфигурации сети» (network-config-subsystem).<br />
# При установке etcnet вместо net-scripts (или наоборот) сервис <tt>network</tt> оказывается выключенным. Это означает, что при загрузке системы сеть не будет сконфигурирована, что можно проверить командой {{cmd|chkconfig --list network}}. Для быстрого исправления проблемы можно дать команду {{cmd|chkconfig network reset}}.<br />
# etcnet '''НЕ''' импортирует автоматически настройки net-scripts. Если вы только что установили etcnet, и ваши сетевые интерфейсы всё ещё остаются сконфигурированными (несмотря на уже отсутствующий пакет net-scripts), то вы можете запустить сценарий {{cmd|/etc/net/scripts/contrib/initconf}}. Он попытается проанализировать текущее состояние интерфейсов и выведет вам результат. Никаких файлов при этом записано не будет. Если вам подходит вывод initconf, то запустите его с параметром write и он проделает то же самое, но уже с сохранением конфигурации.<br />
# Для корректной работы системы в целом необходимо, чтобы содержимое файла {{path|/etc/sysconfig/network}} было корректным.<br />
# Переменные <tt>sysctl</tt> в ОС ALT Linux конфигурируются в следующих местах<ref>{{altbug|26498}}</ref>:<br />
#* {{path|/etc/sysctl.conf}} (глобальные системные);<br />
#* {{path|/etc/sysconfig/network-scripts/sysctl.conf}} (общие сетевые в net-scripts, исходно файл не существует);<br />
#* {{path|/etc/net/sysctl.conf}} (общие сетевые в /etc/net);<br />
#* <tt>/etc/net/ifaces/*/sysctl.conf*</tt> (частные для конкретных интерфейсов или их типов в /etc/net, создаются вручную при необходимости).<br />
Скрипты etcnet используют эти файлы в указанном порядке.<br />
<br />
<div id="options.d"></div><br />
<br />
=== Организация опций /etc/net по умолчанию ===<br />
Методология /etc/net предусматривает несколько шагов наследования опций, первый из которых — загрузка опций по умолчанию. В ранних версиях это происходило из одного файла <tt>/etc/net/options</tt>, сейчас же в вашем распоряжении есть каталог {{path|/etc/net/options.d}}, из которого будут последовательно прочитаны все файлы.<br />
<br />
Иными словами, оригинальный архив etcnet содержит только файл {{path|/etc/net/options.d/00-default}}. Упаковщик etcnet, вместо того, чтобы добавить патч в какой-либо дистрибутив, просто добавляет файл с бОльшим номером, который переопределяет нужные опции.<br />
<br />
Ввиду решения различных задач, администратору системы может не подойти содержание дистрибутивного набора. В этом случае администратор может создать файл с ещё более высоким номером и определить настройки умолчания для своей системы. В результате такого подхода:<br />
# Уменьшается количество патчей (хотя их свойство "отваливаться" от пакета при его упаковке бывает полезным).<br />
# Не изменяются файлы с опциями, принадлежащие пакету. Это делает обновление пакета намного более корректным.<br />
# Можно легко увидеть, какие опции переопределяются на каждом этапе.<br />
<br />
<div id="iftab"></div><br />
<br />
=== Назначение iftab ===<br />
<br />
Начиная с дистрибутивов, основанных на ветках p5 и 5.1, переименование интерфейсов возложено на udev; см. тж. [http://lists.altlinux.org/pipermail/sisyphus/2009-June/340033.html это письмо] и <s>[https://bugzilla.altlinux.org/show_bug.cgi?id=19313 #19313]</s> и [http://packages.altlinux.org/ru/Sisyphus/srpms/wireless-tools/changelog %changelog ifrename]. В дистрибутивах на базе p8 и новее может быть полезным пакет udev-rule-generator-net, который заполняет /etc/udev/rules.d/70-persistent-net.rules. Возможно, следует отказаться от имён интерфейсов вида ethN и использовать, например, etherN ввиду того, что в новом systemd/udev официально сломан механизм переименования. Данное нововведение в ALT пока отменено; см. тж. [https://bugzilla.altlinux.org/32167 #32167].<br />
<br />
Имена сетевых интерфейсов по умолчанию, как правило, содержат их тип (eth, ppp, wifi, ipsec) и индекс: 0 - для первого созданного интерфейса, 1 - для второго и т. д. При этом соответствие автоматически назначенных имён физическим устройствам может не сохраняться.<br />
<br />
Эта особенность неудобна, когда машина с Linux имеет более одного интерфейса каждого типа. Типичными примерами являются маршрутизаторы и ноутбуки. В маршрутизаторах, как правило, используются однотипные сетевые карты и при их замене или изменении порядка на PCI-шине соответствие оказывается нарушенным. В ноутбуках используются ethernet и wifi-устройства с горячим подключением, при этом слотов и карт может быть более чем 1. В этом случае пользователь/администратор скорее всего пожелает закрепить за каждой сменной картой её конфигурацию.<br />
<br />
/etc/net при конфигурации интерфейса использует то имя, под которым он сконфигурирован, а именно имя каталога, в котором хранятся файлы конфигурации интерфейса.<br />
<br />
Для привязки сетевой карты к имени интерфейса в простых случаях можно воспользоваться файлом {{path|/etc/iftab}}, man-страница по формату которого входит в пакет <tt>ifrename</tt> (<tt>iftab(5)</tt>).<br />
<br />
Использование {{path|/etc/iftab}} удобно, поскольку позволяет сохранять традиционные имена интерфейсов (например, eth0), но этот механизм не поддерживает расширенную функциональность /etc/net (в частности, ''профили'' /etc/net).<br />
<br />
Средством, позволяющим использовать все возможности <tt>etcnet</tt>, является файл {{path|/etc/net/iftab}}, обрабатываемый не утилитой <tt>ifrename</tt>, а непосредственно <tt>etcnet</tt>. Синтаксис этого файла совпадает с синтаксисом {{path|/etc/iftab}}. Ограничением же является невозможность использовать стандартные имена интерфейсом (<tt>ethX</tt>, <tt>pppX</tt>), так как переименование интерфейсов происходит уже после конфигурации интерфейса ядром. В случае, если вам необходим {{path|/etc/net/iftab}}, имеет смысл переименовать интерфейсы, давая им либо двухзначные номера (<tt>eth00</tt>, <tt>eth01</tt>...), либо осмысленные названия (<tt>isplink</tt>, <tt>lan</tt>...)<br />
<br />
См. письмо про [http://lists.altlinux.org/pipermail/sisyphus/2009-March/337924.html важность /etc/iftab]<br />
и тж. это письмо про [http://lists.altlinux.org/pipermail/devel/2007-October/065097.html отличия etcnet и сервиса ifrename]:<br />
{{начало цитаты}} Комментарии к письмам этого треда (с некоторыми пояснениями):<br />
<br />
1. «etcnet уже научился менять местами eth0 и eth1?»<br />
<br />
Освоение этого приема обладает сомнительной пользой. Рекомендуется <br />
рассматривать eth0 как временное имя с малым сроком жизни,<br />
а для повышения комфорта пользователей Ethernet-интерфейсы предлагается<br />
называть eth00, eth01, eth02 etc.<br />
<br />
2. «Существование (номинальное) net-scripts вынуждает поддерживать<br />
ряд сервисов, которые иначе могли бы быть упразднены»<br />
<br />
Эти сервисы можно "обезвредить" (отключить) контролем CONFMETHOD<br />
из /etc/sysconfig/network. При этом зависимости на пакет etcnet<br />
не возникнет, только на network-config-subsystem. Примеры таких<br />
пакетов должны быть в Sisyphus.<br />
<br />
3. «после приведения в порядок /etc/udev/rules.d/19-udev-ifrename.rules<br />
нужности в /etc/net/iftab я не заметил»<br />
<br />
Важнейшее принципиальное отличие /etc/net/iftab от /etc/iftab —<br />
нахождение /etc/net/iftab в специальном пространстве имён. Для него<br />
действуют механизмы определения профиля и хоста конфигурации. Это,<br />
например, позволит, при необходимости, составить конфигурацию так, что срочный<br />
ремонт маршрутизатора сведётся к переносу диска (или массива)<br />
из сгоревшего шасси в запасное. Возможны и другие примеры, которые<br />
станут невозможными при помещении iftab в /etc и его прямой<br />
интерпретации.<br />
<br />
Конечно, пользователю единственного ноутбука с одним-двумя сетевыми<br />
интерфейсами такая практика — полный overkill (т.е. такая практика ему не нужна), но его никто и не<br />
заставляет видеть всю подводную часть (т.е. все тонкости работы и настройки). В этом и гибкость.{{конец цитаты}}<br />
<br />
<div id="specifaces"></div><br />
<br />
=== Интерфейсы lo, default и unknown ===<br />
Сразу после установки пакета <tt>etcnet</tt> в каталоге {{path|/etc/net/ifaces}} (в котором хранятся конфигурации интерфейсов) находятся три каталога: <br />
* lo<br />
* default<br />
* unknown<br />
<br />
Интерфейс '''lo''' — стандартная "петля" (loopback), которая должна быть во всякой Linux-системе, поэтому конфигурация для него включена по умолчанию. В остальном он ничем не отличается от любого другого интерфейса и конфигурируется точно так же файлами <tt>options</tt> и <tt>ipv4address</tt>.<br />
<br />
Интерфейс '''default''' — это не интерфейс, а специальный каталог, файлы в котором обрабатываются следующим образом:<br />
* <tt>resolv.conf</tt> — если присутствует, то копируется в {{path|/etc/resolv.conf}}.<br />
* <tt>options</tt> — файл опций, читается после опций по умолчанию.<br />
* <tt>options-<вид интерфейса></tt> — этот файл содержит опции, специфичные для данного вида интерфейсов. Некоторые из них не обязательны и позволяют использовать особенности данного вида интерфейсов, например, <tt>LINKDETECT</tt> в <tt>options-eth</tt>; другие обязательны, например, <tt>HOST</tt> в <tt>options-bri</tt>. Обратите внимание, что эти файлы не рекомендуется редактировать. Если вам нужно задать опцию для интерфейса, то, как правило, это можно сделать в файле <tt>options</tt> в конфигурационном каталоге данного интерфейса. Это облегчит процесс обновления пакета etcnet.<br />
* <tt>sysctl.conf-<вид интерфейса></tt> — файл с переменными sysctl, которые необходимо изменить. Сейчас единственный такой файл — <tt>sysctl.conf-dvb</tt>, который отключает <tt>return path filter</tt>, что всегда нужно в случае асимметричной маршрутизации.<br />
* <tt>iplink-<вид интерфейса></tt> — файл с командами iplink, специфичными для данного вида.<br />
* <tt>selectprofile</tt> — если этот файл исполняемый, то он будет вызван из сценариев <tt>ifup/ifdown</tt>, <tt>setup/shutdown</tt> для того, чтобы вернуть на стандартном выводе имя профиля, которое необходимо использовать. Это позволяет автоматически переключать профили в зависимости от каких-либо условий. В поставку включен пример сценария: {{path|/etc/net/scripts/contrib/selectprofile}}.<br />
* <tt>fw</tt> — каталог с настройками сетевого экрана по умолчанию.<br />
<br />
Интерфейс '''unknown''' — специальная конфигурация, которая будет использована в том случае, когда /etc/net просят сконфигурировать hotplug-интерфейс, для которого не существует каталога конфигурации. Это будет работать только в том случае, если включена опция <tt>ALLOW_UNKNOWN</tt>.<br />
<br />
<div id="broadcast"></div><br />
<br />
=== broadcast address===<br />
<br />
Периодически возникает вопрос: почему после старта /etc/net при запуске <tt>ifconfig</tt> можно видеть <tt>Bcast:0.0.0.0</tt>, хотя при использовании net-scripts это поле было правильным? <br />
<br />
Ответ: net-scripts оперируют адресом, маской, адресом сети и широковещательным адресом, пытаясь определить неизвестные компоненты из известных, а <tt>config-ipv4</tt> просто передаёт утилите <tt>ip</tt> содержимое файла <tt>ipv4address</tt>, не проверяя его содержание.<br />
Важно заметить, что:<br />
* Если <tt>iproute2</tt> изменит свой синтаксис, то с очень вероятно, что администратору будет необходимо редактировать только конфигурационные файлы.<br />
* Не было найдено проблем с «отсутствующим» broadcast address. Он есть в таблице маршрутизации <tt>local</tt>. <br />
* Администратор всегда может назначить адрес broadcast в файле <tt>ipv4address</tt>. Это можно сделать с помощью выражения <tt>broadcast +</tt><ref><br />
Выдержка из файла ip-cref.ps, который входит в документацию пакета iproute2:<br />
<br />
<pre><br />
* broadcast ADDRESS<br />
<br />
the broadcast address on the interface.<br />
It is possible to use the special symbols '+' and '-' instead of the broadcast address. In this case, <br />
the broadcast address is derived by setting/resetting the host bits of the interface prefix.<br />
NB. Unlike ifconfig, the ip utility does not set any broadcast address unless explicitly requested.<br />
</pre><br />
</ref>.<br />
'''Замечание:''' В версии 0.8.0 появилась опция <tt>AUTO_BROADCAST</tt> для автоматического дополнения каждой строки <tt>ipv4address</tt>.<br />
<br />
<div id="never_rmmod"></div><br />
<br />
=== Ядро 2.6 и "пропадающие" интерфейсы ===<br />
Иногда возможна ситуация: Если два интерфейса используют один и тот же модуль ядра, и у них определена опция <tt>MODULE</tt> (то есть скрипты /etc/net сами загружают и выгружают модули), то при опускании (отключении) одного интерфейса пропадает и второй интерфейс. <br />
<br />
Такая ситуация почти наверняка возникает при использовании ядра 2.6, особенностью которого являются значения счётчика ссылок (третий столбец вывода {{cmd|lsmod}}). Когда счетчик оказывается равен нулю (довольно часто), скрипты могут попытаться выгрузить модуль интерфейса, для которого запущен ifdown. И такая выгрузка происходит, несмотря на то, что другой интерфейс, использующий этот же модуль, находится в состоянии UP (т.е. он активен).<br />
<br />
Чтобы заблокировать выгрузку модулей, можно использовать булеву переменную <tt>NEVER_RMMOD</tt>. Возможно, позже это будет происходить автоматически для ядер следующих версий.<br />
<br />
<div id="removables"></div><br />
<br />
=== Cценарии конфигурации сети и hotplug-интерфейсы ===<br />
<br />
==== Cценарии конфигурации сети ====<br />
Существует несколько сценариев конфигурации сети.<br />
<br />
* Первый и самый простой — выполнение {{cmd|service network start}} при старте системы или вручную. При этом требуется только сформировать погруппные (потиповые) списки интерфейсов, подлежащих обработке, и последовательно выполнить требуемые действия. Модули ядра при этом загружаются сценариями /etc/net, при этом имена модулей берутся из опции <tt>MODULE</tt> (в этой опции можно в кавычках перечислить несколько имён и они будут последовательно загружены). Этот метод часто используется на практике и лучше всего подходит для маршрутизаторов. Преимущество метода в том, что вся необходимая информация сконцентрирована в одном месте — каталоге {{path|/etc/net}}. Если опция <tt>MODULE</tt> не определена, то будет предпринята попытка загрузки по имени интерфейса, подразумевая, что файл {{path|/etc/modules.conf}} правильно заполнен.<br />
<br />
* Второй сценарий — реакция на событие <tt>ifplugd</tt>. В предыдущих версиях существовала сложность, так как требовалась синхронная настройка сервиса <tt>ifplugd</tt>. Сейчас логика работы определена, что выражено в том, что /etc/net взяла управление <tt>ifplugd</tt> на себя. В части загрузки модуля этот сценарий не отличается от первого.<br />
<br />
* Третий сценарий — реакция на появление или исчезновение сменного устройства. Для обработки таких событий предназначены сценарии <tt>/etc/net/scripts/{ifup,ifdown}-removable</tt>, которые вызываются из сценариев пакетов hotplug и pcmcia-cs. Сложность заключается в том, что для сменных PCMCIA-карт вызовы могут дублироваться: для одного и того же события первый раз ifup-removable будет вызван из hotplug, второй — из pcmcia-cs. Кроме того, hotplug также реагирует на загрузку модулей ядра для обычных карт PCI и, более того, включает сценарии, которые пытаются загружать модули самостоятельно. В этом контексте /etc/net получает слишком много вызовов от hotplug и по умолчанию их игнорирует (<tt>USE_HOTPLUG=no</tt>).<br />
<br />
* Четвёртый сценарий - реакция на появление сетевого интерфейса через systemd. Такое событие обрабатывается через сервис network@.service, которому в качестве аргумента, следующего за @ нужно передать имя интерфейса. Например - systemctl enable network@eth0. В этом случае интерфейс будет подниматься после его появления в системе, что полезно в некоторых случаях, когда система загружается быстрее появления интерфейсов и на момент запуска сервиса network сетевых интерфейсов в системе ещё нет.<br />
<br />
==== hotplug-интерфейсы ====<br />
Рассмотрим использование hotplug-интерфейсов. <br />
<br />
Пусть администратору необходимо настроить действительно сменную карту. После заполнения {{path|/etc/iftab}} или {{path|/etc/net/iftab}} в файле <tt>options</tt> необходимо будет задать <tt>USE_HOTPLUG=yes</tt>. После этого при получении события от hotplug /etc/net будет работать в том контексте, что модуль в загрузке и выгрузке не нуждается. <br />
<br />
Важно заметить, что '''такой интерфейс будет пропущен при обычном старте сети''', т.к. если он сменный, то единственный достоверный способ узнать, что он присутствует — получить вызов от hotplug. Из факта выполнения {{cmd|service network start}} совсем не следует, что какой-то один или несколько из сконфигурированных hotplug-интерфейсов сейчас в наличии и требуют конфигурации. Если вы хотите вручную расконфигурировать hotplug-интерфейс до его извлечения, используйте команду {{cmd|ifdown}}. Для повторной конфигурации вставьте его ещё раз.<br />
<br />
Также существует опция <tt>USE_PCMCIA</tt>. Если события для вашей карты генерирует pcmcia-cs, то вам нужно её включить. Если события генерируются только hotplug, то используйте опцию <tt>USE_HOTPLUG</tt>.<br />
<br />
<div id="eth0"></div><br />
<br />
=== Проблема стандартных имен интерфейсов (eth0 и др.)===<br />
<br />
При использовании файла {{path|/etc/net/iftab}}, то есть в случае применения сложных конфигураций, возникает следующая проблема:<br />
* При загрузке модулей имена интерфейсов принимают вид eth0, eth1, eth2… Какие именно — в общем случае контролировать нельзя.<br />
* Имя eth0 обладает наибольшей вероятностью оказаться занятым.<br />
* ifrename не может переименовать интерфейс, если целевое имя уже занято (udev использует <tt>ifrename -t</tt>, но это не работает после начальной загрузки, см. руководство к ifrename).<br />
<br />
С учётом вышеизложенного, если {{path|/etc/net/iftab}} содержит тот же набор имён интерфейсов, что уже имеется после загрузки модулей (то есть <tt>eth0</tt>/<tt>eth1</tt> и другие «стандартные» названия), то единственный случай, когда etcnet сможет без ошибок обработать такой файл — изначальное соответствие, не требующее переименования.<br />
<br />
Таким образом, при использовании {{path|/etc/net/iftab}} имеет смысл давать интерфейсам названия, отличные по виду от тех, что назначает ядро. В простых случаях лучше использовать {{path|/etc/udev/rules.d/70-persistent-net.rules}} ({{path|/etc/iftab}} до бранчей p5/5.1).<br />
<br />
<div id="advanced"></div><br />
<br />
== Расширенные возможности ==<br />
<div id="multipleIPs"></div><br />
<br />
=== Несколько IP-адресов или маршрутов на одном интерфейсе ===<br />
<br />
Вы можете помещать произвольное количество IP-адресов в файл <tt>ipv4address</tt> по одному адресу на каждой строке. То же самое относится к статическим маршрутам и файлу <tt>ipv4route</tt>.<br />
<br />
Обратите внимание, что /etc/net не анализирует содержимое этих файлов, а формирует на основе каждой строки командную строку для утилиты {{cmd|ip}}. Это означает, что вы можете помещать в этих файлах произвольные поддерживаемые {{cmd|ip}} опции и они будут обработаны. Например, в файле <tt>ipv4route</tt> можно поместить строку:<br />
<pre>10.0.1.0/24 via 10.0.0.253 metric 50 weight 5 table 100</pre><br />
<br />
<div id="requires"></div><br />
<br />
=== Зависимости между интерфейсами ===<br />
У интерфейсов:<br />
* vlan<br />
* bond <br />
* bri <br />
* teql <br />
входящих в группу зависимых физических, должна быть определена опция <tt>HOST</tt> со списком интерфейсов, необходимых для инициализации текущего интерфейса. Если хост-интерфейс не сконфигурирован при поднятии зависимого интерфейса, то это будет исправлено.<br />
<br />
Кроме обязательной для определённых интерфейсов опции <tt>HOST</tt>, может быть задана и необязательная для всех остальных интерфейсов опция <tt>REQUIRES</tt>. Интерфейсы, перечисленные в этой опции, будут считаться зависимостями текущего интерфейса. Например, по умолчанию попытка сконфигурировать интерфейс А, который зависит от Б и В, приведёт сначала к конфигурации Б и В. Аналогично, при расконфигурации Б или В сначала будет расконфигурирован А.<br />
<br />
Зависимость одного интерфейса от другого не всегда формальна. Например, в сценарии <tt>ifup-pre</tt> одного интерфейса может использоваться команда, которая потребует разрешения DNS-имени, которое может быть разрешено только с помощью <tt>resolv.conf</tt>, инсталлируемого другим интерфейсом. Или это может быть PPPoE/PPtP-интерфейс, требующий Ethernet-интерфейс для работы.<br />
<br />
Для того, чтобы избежать неожиданных сбоев в таких случаях, правильно задавайте опцию <tt>REQUIRES</tt>.<br />
<br />
<div id="postpre"></div><br />
<br />
=== Пользовательские сценарии post и pre ===<br />
Существует возможность поместить в каталог конфигурации интерфейса файлы, которые будут выполнены в определённые моменты. Для этого они должны быть исполняемыми и называться следующим образом:<br />
* <tt>ifup-pre</tt> — для выполнения перед конфигурированием интерфейса.<br />
* <tt>ifup-post</tt> — для выполнения после конфигурирования интерфейса. Например, можно запустить почтовую систему.<br />
* <tt>ifdown-pre</tt> — для выполнения перед расконфигурированием интерфейса. Например, можно остановить почтовую систему.<br />
* <tt>ifdown-post</tt> — для выполнения после расконфигурирования интерфейса.<br />
<br />
Также в версии до 0.8.0 возможно использовать следующие сценарии (они должны быть исполняемыми):<br />
* <tt>/etc/net/scripts/ifup-pre-local</tt><br />
* <tt>/etc/net/scripts/ifup-post-local</tt><br />
* <tt>/etc/net/scripts/ifdown-pre-local</tt><br />
* <tt>/etc/net/scripts/ifdown-post-local</tt><br />
<br />
Они будут вызваны для каждого интерфейса. Начиная с версии 0.8.0 эти сценарии называются так:<br />
* <tt>/etc/net/ifup-pre</tt><br />
* <tt>/etc/net/ifup-post</tt><br />
* <tt>/etc/net/ifdown-pre</tt><br />
* <tt>/etc/net/ifdown-post</tt><br />
Семантика сохранена.<br />
<br />
<div id="iplink"></div><br />
<br />
=== Управление канальными параметрами интерфейсов ===<br />
<br />
Если поместить в конфигурационный каталог интерфейса файл <tt>iplink</tt>, в котором в каждой строке будут записаны команды режима link утилиты {{cmd|ip}}, то они будут выполнены при конфигурации интерфейса. <br />
<br />
Например, если необходимо, чтобы интерфейс net1 имел MAC-адрес aa:bb:cc:dd:ee:ff и MTU 200 байт, то в файл {{path|/etc/net/ifaces/net1/iplink}} нужно поместить следующее:<br />
<pre>address aa:bb:cc:dd:ee:ff<br />
mtu 200</pre><br />
<br />
Обратите внимание, что в этом случае в {{path|/etc/net/iftab}} вам необходимо будет использовать селектор <tt>businfo</tt> или <tt>driver</tt> вместо <tt>mac</tt>.<br />
<br />
<div id="ethtool"></div><br />
<br />
=== Управление физическими параметрами интерфейсов ===<br />
Если поместить в конфигурационный каталог интерфейса файл <tt>ethtool</tt>, в котором будет строка с параметрами программы ethtool, то она будет выполнена при конфигурации интерфейса. <br />
<br />
Например, если есть необходимость, чтобы интерфейс net1 имел скорость 10Мбит/с и авто-согласование скорости было отключено, то в файл {{path|/etc/net/ifaces/net1/ethtool}} нужно поместить следующую строку:<br />
<br />
<pre>speed 10 autoneg off</pre><br />
<br />
<div id="bridge"></div><br />
<br />
=== Настройка Ethernet-моста ===<br />
<br />
Для настройки Ethernet-моста (далее — моста) есть 3 пути: <br />
# Linux bridge посредством bridge-utils<br />
# Linux bridge посредством iproute2<br />
# Openvswitch<br />
<br />
Linux bridge наиболее простая реализация. Если вам не нужно все, что умеет [http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=README;hb=HEAD openvswitch] , то можно использовать Linux bridge.<br />
<br />
==== Linux bridge посредством bridge-utils (до p8 включительно) ====<br />
Перед настройкой Ethernet-моста (далее — моста) с помощью etcnet сначала необходимо убедиться, что установлен пакет bridge-utils. Etcnet использует утилиту brctl для настройки моста, и, если утилита не установлена, то при перезапуске системы сеть станет недоступна. Если интерфейсы, входящие в состав моста, являются единственными физически подключенными и настройка моста происходит с удаленного узла через эти интерфейсы, то требуется соблюдать осторожность, т.к. эти интерфейсы перестанут быть доступны. В случае ошибки в конфигурации потребуется физический доступ к серверу. Для страховки, перед перезапуском сервиса network можно открыть ещё одну консоль и запустить там, например, команду: {{cmd|sleep 500 && reboot}}.<br />
<br />
Также имейте ввиду, что если вы подключаетесь по ssh к серверу через bridge-интерфейс (по его ip-адресу), то по умолчанию при опускании любого интерфейса-члена моста Etcnet так же опустит и сам мост (и ваше подключение пропадет). Чтобы избежать этого, установите в файле {{path|options}} того интерфейса, который нужно опускать, переменную <tt>IFDOWN_CHILDREN=no</tt>. Но учтите, что и включаться в бридж при старте тогда этот интерфейс по умолчанию не будет. <br />
<br />
Предположим, требуется настроить Ethernet-мост, пусть он будет называться <tt>br0</tt>. <br />
Тогда для его настройки необходимо завести каталог {{path|/etc/net/ifaces/br0}} и создать там файлы со следующими данными:<br />
<br />
* <tt>brctl</tt><br />
<br />
<pre> stp AUTO on </pre><br />
<br />
* <tt>ipv4address</tt>:<br />
<pre> 192.168.100.200/24 </pre><br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=bri<br />
HOST='eth0 tap0'<br />
BOOTPROTO=static </pre><br />
<br />
Содержимое файла <tt>brctl</tt> передаётся утилите brctl. <tt>AUTO</tt> означает, что скрипт {{cmd|setup-bri}} самостоятельно определит имя bridge-интерфейса (см. файл {{path|/usr/share/doc/etcnet-*/README.bridge}}). Если же в вашей сети этот мост один и рассылать пакеты протокола STP не нужно, тогда файл brctl с указанной опцией не нужен. По умолчанию [http://xgu.ru/wiki/man:brctl#Spanning_Tree_Protocol_.28.D0.9F.D1.80.D0.BE.D1.82.D0.BE.D0.BA.D0.BE.D0.BB_.D0.BE.D1.81.D1.82.D0.BE.D0.B2.D0.BD.D0.BE.D0.B3.D0.BE_.D0.B4.D0.B5.D1.80.D0.B5.D0.B2.D0.B0.29 STP выключен].<br />
<br />
IP-адрес для интерфейса, как обычно, будет взят из <tt>ipv4address</tt>.<br />
<br />
В опции <tt>HOST</tt> файла <tt>options</tt> нужно указать те интерфейсы, которые будут входить в мост. Если в него будут входить интерфейсы, которые до этого имели IP-адрес (например, eth0), то этот адрес должен быть удалён (например, можно закомментировать содержимое файла {{path|ifaces/eth0/ipv4address}}).<br />
<br />
При старте сети сначала поднимаются интерфейсы, входящие в мост, затем сам мост (автоматически). Для назначения адреса мосту можно также использовать DHCP (<tt>BOOTPROTO=dhcp</tt>). Но при этом важно обратить внимание на параметр <tt>forwarding delay</tt> (man brctl / setfd), так как интерфейс, подключенный к мосту, не сразу входит в режим передачи пакетов, и это может вызвать dhcp таймаут. Версии etcnet в дистрибутивах ALT Linux Server 4 и Desktop 4.1 (0.9.7-alt0.M40/M41) имеют эту недоработку, которая исправлена только в версии 0.9.9-alt1. <br />
Документацию по настройке моста с вопросами и ответами (перевод) можно найти на http://xgu.ru/wiki/Linux_Bridge, а его оригинал доступен на http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge.<br />
<br />
Внимание: инструкция на xgu.ru чуть устарела. Команда<br />
<pre>$ brctl setfd br0 0</pre><br />
не выключает задержку, а лишь приводит к величине задержки по умолчанию (15 или даже 30 секунд). Можно попробовать задать задержку в 1сек для уменьшения времени инициализации сети.<br />
<br />
С пакетом etcnet поставляются примеры конфигурации. Один из них показывает, как из двух ethernet-интерфейсов port0 и port1 можно собрать мост bridge (каталог документации examples/Ethernet-bridge-GRE/).<br />
<br />
Безотносительно к etcnet, следует иметь ввиду проблему, связанную с NAT: <s>[http://bugzilla.kernel.org/show_bug.cgi?id=13079 http://bugzilla.kernel.org/show_bug.cgi?id=13079]</s><br />
<br />
==== Linux bridge посредством iproute2 (начиная с p9) ====<br />
Настройка идентична параметрам, применяемым для настройки в случае с bridge-utils (до p9). <br/><br />
Исключение составляют опции настройки VLAN. <br/><br />
В частности, теперь для поддержки VLAN нужно сделать такие настойки в файле options:<br />
<pre><br />
VLAN_AWARE=yes<br />
VIDS="2 4-10 15"<br />
</pre><br />
В этом случае VIDS применятся для всех trunk интерфейсов, входящих в bridge.<br/><br />
Если же вам нужно настроить каждый из trunk интерфейсов индивидуально, то дополнительно введён конфигурационный файл bridge (в каталоге интерфейса bridge), в котором можно перечислить передаваемые утилите bridge команды.<br/><br />
Например, содержимое /etc/net/ifaces/br0/bridge для моста, в который входят интерфейсы eth0 и eth1:<br />
<pre><br />
vlan add dev eth0 vid 100 master<br />
vlan add dev eth0 vid 200 master<br />
vlan add dev eth1 vid 200 master<br />
vlan add dev eth1 vid 300 master<br />
</pre><br />
Дискуссия на момент перехода: https://lists.altlinux.org/pipermail/devel/2018-October/205769.html<br />
<br />
==== openvswitch ====<br />
Как настраивать openvswitch, описано [[Etcnet/openvswitch|тут]].<br />
<br />
<div id="vlan"></div><br />
<br />
=== Настройка VLAN ===<br />
<br />
Для настройки 802.1q VLAN (например, id 4094 на eth1) следует, создав каталог {{path|ifaces/eth1.4094}}, поместить в него файлы со следующим содержимым:<br />
<br />
* <tt>ipv4address</tt>:<br />
<pre>192.168.100.200/24</pre><br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=vlan<br />
HOST=eth1<br />
VID=4094<br />
BOOTPROTO=static</pre><br />
<br />
Содержимое переменных <tt>HOST</tt> и <tt>VID</tt> будет передано утилите <tt>vconfig</tt>; использование файла <tt>vlantab</tt> необязательно (и не рекомендуется по причине невозможности использовать ifup для отдельного интерфейса). Пример конфигурации можно найти в каталоге examples/VLAN-without-vlantab/ документации etcnet.<br />
<br />
Следует обратить внимание, что 4094 является верхней допустимой границей идентификатора валидного VLAN, а [http://www.candelatech.com/pipermail/vlan/2004-November/000128.html 4095 используется технически в процессе отбрасывания трафика по неверным VLAN]. (следует отметить, что это не ограничение Linux: [http://en.wikipedia.org/wiki/802.1Q в стандарте под VID отведено 12 бит])<br />
<br />
Обратите внимание, что '''ISC DHCP сервер на интерфейсе VLAN''', скорее всего, у вас не будет работать, пока вы не добавите опцию VLAN_REORDER_HDR=on в настройки vlan интерфейса. Эта опция переведёт vlan интерфейс в режим работы, в котором пакеты на интерфейсе не будут содержать тэгов vlan и их сможет получить dhcpd.<br />
<br />
<br />
'''Для настройки Q-in-Q интерфейса''', например, eth1.123.513 (дважды тегированный трафик: внешняя метка -- 123, внутренняя -- 513) следует файл <tt>options</tt> в каталоге {{path|ifaces/eth1.123.513}} заполнить следующим образом:<br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=vlan<br />
HOST=eth1.123 # "родительский" интерфейс; может называться иначе<br />
VID=513<br />
VLAN_REORDER_HDR=0<br />
BOOTPROTO=static</pre><br />
<br />
Родительский интерфейс должен быть сконфигурирован (можно с или без <tt>BOOTPROTO</tt>, с или без <tt>ipv4address</tt> и т.п.).<br />
<br />
Таким образом, можно каскадировать интерфейсы "как угодно глубоко" (Q-in-Q-in-Q-in-Q....). Необходимо только учитывать, что длина имени интерфейса ограничена (16-ю символами).<br />
<br />
<div id="bonding"></div><br />
<br />
=== Настройка bonding ===<br />
Bonding - объединение нескольких физических сетевых интерфейсов в один логический, для достижения отказоустойчивости, увеличения скорости и балансировки нагрузки. Возможны несколько режимов работы и много параметров для настроек, подробнее см. http://www.linuxfoundation.org/collaborate/workgroups/networking/bonding<br />
<br />
Для создания агрегированного bond-интерфейса средствами etcnet создаем, как обычно, директорию для интерфейса (например, <tt>bond0</tt>) с <tt>options</tt>, <tt>ipv4address</tt>, и прочими необходимыми файлами. В <tt>options</tt> указываем тип интерфейса <tt>bond</tt>, перечисляем в переменной <tt>HOST</tt> родительские интерфейсы, которые будут входить в наш агрегированный интерфейс, указываем в переменной <tt>BONDMODE</tt> режим (по умолчанию 0), и опции для модуля ядра <tt>bonding</tt> в <tt>BONDOPTIONS</tt>.<br><br />
Так, для создания LACP-агрегированного канала (802.3ad), у нас получится такой <tt>options</tt>:<br />
TYPE=bond<br />
ONBOOT=yes<br />
BOOTPROTO=static<br />
HOST="eth0 eth1"<br />
BONDMODE=4<br />
BONDOPTIONS="miimon=100 lacp_rate=1"<br />
Интерфейсы eth0 и eth1 должны тоже быть описаны в etcnet.<br />
<br />
Как правило, для создания агрегированного интерфейса требуется, чтобы входящие в него физические интерфейсы имели одинаковые характеристики - скорость, дуплекс, etc.<br />
<br />
Не стоит указывать режим в переменной <tt>BONDOPTIONS</tt>: попытки изменить какие-то режимоспецифичные параметры до установки правильного режима могут быть отвергнуты. Поэтому, первым делом нужно установить необходимый режим, указав его для этого в <tt>BONDMODE</tt>.<br />
<br />
Информацию о получившемся агрегированном интерфейсе можно посмотреть в {{path|/proc/net/bonding/bond0}}<br />
<br />
<div id="tun/tap"></div><br />
<br />
=== Настройка tun/tap интерфейса ===<br />
<br />
Etcnet поддерживает простое создание интерфейсов типа tun/tap. Это виртуальный тип интерфейсов для передачи пакетов между ядром и программами, который не передает данных через физические устройства.<br />
'''tun''' — это интерфейс типа point-to-point, работающий с кадрами IP.<br />
'''tap''' — интерфейс типа ethernet, работающий с кадрами ethernet.<br />
<br />
Потребуется использование утилиты tunctl, находящейся в одноименном пакете.<br />
Пусть требуется создать и настроить tun/tap интерфейс, например, с именем tap0. Для этого необходимо:<br />
* создать каталог интерфейса:<br />
<br />
/etc/net/ifaces/tap0<br />
<br />
* создать в каталоге интерфейса {{path|/etc/net/ifaces/tap0}} файл настройки <tt>options</tt> со следующим содержанием:<br />
<br />
TYPE=tuntap<br />
TUNTAP_USER=combr<br />
<br />
<br />
<tt>TUNTAP_USER</tt> — это аккаунт или цифровой id пользователя, которому будут даны права на использование интерфейса tap0 (устройство /dev/net/tun).<br />
Этот параметр будет передан утилите <tt>tunctl</tt> как аргумент опции <tt>-u</tt> (см. руководство на tunctl).<br />
С версии ядра 2.6.18 произошли изменения в управлении этим типом интерфейсов, потребовавшие<br />
обязательного применения <tt>tunctl</tt> для разрешения доступа обычных<br />
пользователей к tap-интерфейсам. В предыдущих версиях любой<br />
пользователь, имеющий доступ к <tt>/dev/net/tun</tt>, мог создать любое<br />
количество сетевых интерфейсов с произвольными именами. Начиная с<br />
2.6.18, для создания интерфейса через <tt>/dev/net/tun</tt> требуется<br />
<tt>CAP_NET_ADMIN</tt> (обычно эту привилегию имеет только root), а обычный<br />
пользователь, имеющий доступ к <tt>/dev/net/tun</tt>, может только использовать<br />
уже созданные интерфейсы, к которым разрешён доступ для его uid.<br />
<br />
=== Настройка интерфейса типа OpenVPN ===<br />
<br />
Настройка OpenVPN может быть произведена большим количеством способов и вариантов с разными целями, и достойна отдельной статьи. Здесь, для начала, будет описан вариант openvpn-сервера в режиме bridging.<br />
Для этого надо проделать подготовку:<br />
* создать ключи [http://openvpn.net/index.php/open-source/documentation/howto.html#pki англ. HOWTO]<br />
(до версии 2.3 утилиты easy-rsa шли в составе дистрибутива openvpn, потом отдельно).<br />
* настроить [http://www.altlinux.org/Etcnet#.D0.9D.D0.B0.D1.81.D1.82.D1.80.D0.BE.D0.B9.D0.BA.D0.B0_Ethernet-.D0.BC.D0.BE.D1.81.D1.82.D0.B0 мост] (между внутренним физическим интерфейсом и интерфейсом tap, который будет использовать openvpn) "средствами системы".<br />
<br />
Далее надо сделать так (скрипты etcnet по умолчанию ожидают это):<br />
* создать каталог интерфейса:<br />
<br />
/etc/net/ifaces/tap0<br />
<br />
* создать в каталоге интерфейса {{path|/etc/net/ifaces/tap0}} файл настройки <tt>options</tt> со следующим содержанием:<br />
<br />
TYPE=ovpn<br />
<br />
(необязательно, но желательно указать '''REQUIRES'''=''<имя ethernet-интерфейса>'', с которым будет связан туннель)<br />
<br />
* Конфигурационный файл для openvpn (из примера в пакете openvpn-docs - такой, как /usr/share/doc/openvpn-docs-2.2.2/sample-config-files/server.conf) надо переделать, удалив параметры, которые etcnet подставляет самостоятельно при запуске:<br />
<br />
dev<br />
ca<br />
cert<br />
key<br />
persist-key<br />
persist-tun<br />
<br />
И обязательно добавив параметры, которых по умолчанию в конфиге-примере нет:<br />
<br />
tls-server<br />
script-security 2<br />
<br />
Параметр script-security был введен начиная с версии 2.1_rc9. Поскольку etcnet запускает openvpn так, что в процессе тот запускает скрипт scripts/openvpn.action, который считается "пользовательским", то для этого значение должно быть 2.<br />
<br />
* скопировать в каталог интерфейса ключи и измененный конфиг-файл openvpn.<br />
Файлы надо переименовать (ключи - после easy-rsa) таким образом:<br />
{| align="center" border="1"<br />
|ключ easy-rsa<br />
|ключ etcnet-ovpn<br />
|-<br />
|ca.crt <br />
|ovpnca<br />
|-<br />
|server.crt<br />
|ovpncrt<br />
|-<br />
|server.key<br />
|ovpnkey<br />
|-<br />
|server.conf<br />
|ovpnoptions<br />
|}<br />
<br />
<br />
<br />
После всего этого можно попробовать запустить интерфейс: ifup tun0 (или весь мост, например ifup br0). Но если, например, openvpn считает ошибочной какую-либо опцию, то он молча выйдет с кодом выхода 1, и скрипт ifup ничего не напишет (в логе так же не будет попытки запуска openvpn). Потребуется отладка (например, можно запустить openvpn вручную без параметра --daemon и со всеми параметрами, которые подставил etcnet).<br />
<br />
<div id="wireguard"></div><br />
<br />
=== Настройка WireGuard VPN туннеля ===<br />
<br />
WireGuard используется для быстрого создания VPN туннелей, является более легким и безопасным чем OpenVPN. Для использования wireguard необходимо '''ядро std-def версии 3.10+''', установленный модуль ядра '''kernel-modules-wireguard-std-def''' и пакет '''wireguard-tools'''. Для настройки интерфейса необходимо:<br />
* создать каталог интерфейса {{path|/etc/net/ifaces/wg0}}<br />
* добавить файл с конфигурацией {{path|/etc/net/ifaces/wg0/options}}<br />
<source lang='ini'><br />
TYPE=wg<br />
LISTENPORT=51820<br />
</source><br />
* добавить файл с поддерживающимися wireguard опциями пиров {{path|/etc/net/ifaces/wg0/peers}} (одна строка - один пир)<br />
<source lang='bash'><br />
peer PUBLICPEERKEY allowed-ips IFACESSUBNET endpoint PUBLICIP:ALLOWPORT<br />
</source><br />
* добавить файл содержащий локальные и удаленные ip адреса {{path|/etc/net/ifaces/wg0/ipv4address}}<br />
первым делом указывается выделенная интерфейсу локальная подсеть, после чего указываются соответствия локального и удаленного ip адресов, каждое соответствие с новой строки<br />
<source lang='bash'><br />
10.1.0.0/16<br />
10.1.0.1 10.2.0.1<br />
</source><br />
* добавить файл содержащий приватный ключ {{path|/etc/net/ifaces/wg0/privatekey}}<br />
Ключи могут быть созданы стандартной утилитой wireguard:<br />
<source lang='bash'><br />
$ umask 077<br />
$ wg genkey > privatekey<br />
$ wg pubkey < privatekey > publickey<br />
</source><br />
<br />
<div id="iptun"></div><br />
<br />
=== Настройка и использование IP-туннелей ===<br />
<br />
IP-туннели — средство, позволяющее улучшить IP-сети. Поддерживаются IP-туннели трёх видов: <br />
* IPIP<br />
* GRE<br />
* SIT <br />
* VTI<br />
<br />
Прежде всего следует определить необходимый вид туннеля для решаемой задачи. <br />
<br />
* Туннели '''IPIP''' — самые простые.<br />
<br />
* Туннели '''GRE''' (general incapsulation) обычно используются в маршрутизаторах Cisco. По туннелям этого типа могут передаваться broadcast и multicast пакеты. Кроме того, эти туннели поддерживают контрольные суммы и контроль упорядоченности пакетов. Также GRE-туннели обладают опциональным атрибутом key в виде произвольного 4-байтового числа, который позволяет конфигурировать несколько GRE туннелей между одной парой IP-адресов несущей сети (в отличие от IPIP-туннелей, с которыми это невозможно).<br />
<br />
* Туннели '''SIT''' предназначены для транспортировки пакетов IPv6 через сети IPv4.<br />
<br />
* Туннели '''VTI''' используются для построения IPsec туннелей. Работают используя один из демонов, strongswan или libreswan.<br />
<br />
Тип туннеля определяется опцией <tt>TUNTYPE (ipip, gre, sit, vti)</tt>. По умолчанию <tt>TUNTYPE=ipip</tt>. Кроме типа туннеля для конфигурации всегда требуется адрес удалённого хоста и почти всегда — локальный адрес. Эти адреса определяются опциями <tt>TUNREMOTE</tt> и <tt>TUNLOCAL</tt> соответственно. В некоторых случаях локальный адрес можно не указывать. В этом случае опция <tt>TUNLOCAL</tt> всё равно обязательна, но принимает значение <tt>any</tt>. Не забудьте назначить туннельному интерфейсу адреса и маршруты в соответствующих файлах.<br />
<br />
Пример: Конфигурация GRE-туннеля между 10.0.1.2 и 10.0.2.3 с двумя ключами для исходящих и входящих пакетов, проверкой очерёдности пакетов, TTL 8 и вычислением контрольных сумм. Туннель должен использовать только интерфейс gw1. Пусть имя создаваемого туннеля будет <tt>mytunnel</tt>.<br />
<br />
Тогда необходимо сделать следующие операции:<br />
* Создать каталог туннеля: {{path|/etc/net/ifaces/mytunnel}}<br />
<br />
* Создать в каталоге туннеля файл настроек <tt>options</tt>: {{path|/etc/net/ifaces/mytunnel/options}}<br />
<br />
* Отредактировать файл настроек <tt>options</tt>: <br />
<br />
<source lang="ini"><br />
TYPE=iptun<br />
TUNTYPE=gre<br />
TUNLOCAL=10.0.1.2<br />
TUNREMOTE=10.0.2.3<br />
TUNTTL=8<br />
HOST=gw1<br />
TUNOPTIONS='ttl 64 seq ikey 2020 okey 2030 csum'<br />
</source><br />
<br />
<div id="vpn"></div><br />
<br />
Про <tt>ttl 64</tt>. Если параметр ttl не задан, значение берётся из инкапсулируемого пакета (это надо проверить). В некоторых случаях ttl может получиться слишком мал (например, Quagga формирует OSPF-пакеты с TTL 1).<br />
<br />
Стоит помнить, что имена <tt>tunl0, gre0 и sit0</tt> являются зарезервированными в iproute2 ("base devices") и имеют особое поведение: http://www.liveinternet.ru/users/stasikos/post71435454/<br />
<br />
Процедура создания vti интерфейса стандартна, однако, предварительно необходимо установить и настроить один из демонов (strongswan, libreswan), о том, как это сделать можно найти в соответствующей документации. После чего необходимо создать каталог интерфейса (к примеру он будет называться vti0) {{path|/etc/net/ifaces/vti0}}, и добавить в него файл настроек туннеля {{path|/etc/net/ifaces/vti0/options}}, куда нужно прописать необходимую конфигурацию:<br />
<source lang='ini'><br />
TYPE=iptun<br />
TUNTYPE=vti<br />
TUNLOCAL=119.81.184.173<br />
TUNREMOTE=119.81.177.236<br />
TUNOPTIONS='key 42'<br />
</source><br />
Параметр key должен соответствовать параметру mark, указанному при настройке strongswan/libreswan.<br />
<br />
=== Настройка IPv6 ===<br />
==== Отключение IPv6 ====<br />
<br />
* '''Вариант 1'''<br />
Чтобы отключить IPv6 на всех сетевых интерфейсах в работающей системе с загруженным модулем ipv6, нужно изменить значение параметра ядра net.ipv6.conf.all.disable_ipv6, где 'all' подразумевает все интерфейсы, а net.ipv6.conf.eth0.disable_ipv6 -- отключение протокола IPv6 только на интерфейсе eth0 и т.д.<br />
<pre><br />
sysctl net.ipv6.conf.all.disable_ipv6=1<br />
</pre><br />
Также можно добавить данную директиву в {{path|/etc/sysctl.conf}}:<br />
<source lang="bash"><br />
echo 'net.ipv6.conf.all.disable_ipv6 = 1' >> /etc/sysctl.conf<br />
sysctl -f<br />
</source><br />
<br />
* '''Вариант 2'''<br />
Добавить параметр в командную строку загрузки ядра. Для GRUB2 нужно изменить параметры загрузки ядра в файле {{path|/etc/sysconfig/grub2}}, изменив переменную GRUB_CMDLINE_LINUX_DEFAULT или GRUB_CMDLINE_LINUX<br />
<pre><br />
...<br />
GRUB_CMDLINE_LINUX='failsafe vga=normal ipv6.disable=1'<br />
...<br />
</pre><br />
и обновив конфигурационный файл grub<br />
<source lang="bash"><br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
</source><br />
<br />
* '''Вариант 3'''<br />
<source lang="bash"><br />
echo 'options ipv6 disable=1' >> /etc/modprobe.d/options-local.conf<br />
</source><br />
Вступит в силу только после перезагрузки.<br />
<br />
==== Включение IPv6 ====<br />
<br />
* Во-первых, следует убедиться, что не применяется какой-либо вариант совета из предыдущего пункта. <br />
* Во-вторых, следует проверить значение CONFIG_IPV6 в etcnet. Переменная может быть описана в /etc/net/options.d/*, /etc/net/ifaces/default/*, /etc/net/ifaces/*/options. Наибольший приоритет у описания в ifaces/*/options.<br />
<br />
'''Замечание:''' В etcnet-0.9.10-alt5, в /etc/net/ifaces/default/options содержится CONFIG_IPV6=no<br />
<br />
==== Туннели 6-to-4 ====<br />
<br />
Требуется:<br />
* ядро с поддержкой IPv6 (CONFIG_IPV6 в /boot/config-*; наличие модуля ipv6);<br />
* ядро с поддержкой tun (CONFIG_TUN в /boot/config-*; наличие модуля tun);<br />
* доступность узла 192.88.99.1 - через него маршрутизируется трафик в сети IPv6.<br />
<br />
Далее в {{path|/etc/net/ifaces}} создаётся каталог с названием, например,<br />
tun6to4. В нём создаются файлы:<br />
iplink : <pre><br />
mtu 1472 </pre><br />
<br />
ipv6address : <pre><br />
# first six octets: ipv6calc --ipv4_to_6to4addr $TUNLOCAL<br />
2002:c000:201::1/16 </pre><br />
<br />
ipv6route : <pre><br />
2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 </pre><br />
<br />
options : <pre><br />
TYPE=iptun<br />
TUNTYPE=sit<br />
TUNLOCAL=192.0.2.1<br />
TUNREMOTE=any<br />
TUNOPTIONS="ttl 64"<br />
DONT_FLUSH=yes<br />
CONFIG_IPV6=yes </pre><br />
<br />
Адрес TUNLOCAL в options - имеющийся внешний IPv4, в ipv6address<br />
адрес IPv6 выбирается исходя из него же.<br />
<br />
В настройках iptables должно быть разрешение на приём пакетов протокола<br />
ipv6 на внешний адрес IPv4.<br />
<br />
Далее поднимается интерфейс tun6to4, ну и проверяется доступность <br />
чего-либо в IPv6.<br />
<br />
Туннели 6to4 - это RFC 3964.<br />
Miredo - это реализация протокола Teredo, RFC 4380.<br />
6to4 требует наличия внешнего адреса IPv4.<br />
Teredo не требует наличия внешнего адреса, и может работать через NAT.<br />
Через Teredo не получится получить симметричное соединение, т.е. доступ<br />
в IPv6 будет односторонний, на компьютер в общем случае извне<br />
подключиться не получится.<br />
И Teredo позволяет получить только адрес /32, т.е. для подключения сетей<br />
он мало пригоден.<br />
<br />
этот раздел скопирован из письма рассылки community (c) Nikolay A. Fetisov 8 сентября 2011 12:03:30<br />
<br />
=== Замечания о настройке VPN-подключения и туннелей ===<br />
<br />
Часто при настройке VPN-подключения (под которыми здесь будут подразумеваться все туннельные подключения, то есть подключения поверх IP) не учитывают, что использование опции pppd '<tt>defaultroute</tt>' маршрут по-умолчанию после подключения будет изменен. При этом, если VPN-сервер находится в другой, отличной от клиента, сети, то после подключения (и изменения маршрута по-умолчанию) VPN-сервер становится недоступным, следовательно, недоступными становятся все внешние адреса, и подключение, как правило, прекращается по тайм-ауту.<br />
<br />
Решением, как обычно (и рекомендовано), служит указание ''отдельного'' маршрута на VPN-сервер (или его сеть). Для этого необходимо прописать (в примере - для маршрута через eth0) в {{path|/etc/net/ifaces/eth0/ipv4route}} строку вида:<br />
<br />
10.0.1.0/24 via 10.0.0.1<br />
<br />
В данном примере подразумевается, что VPN-сервер находится в сети 10.0.1.0/24 (например, имеет адрес 10.0.1.1), клиент — в сети 10.0.0.0/24 (и имеет адрес, например, 10.0.0.10), а маршрутизатор имеет адрес 10.0.0.1.<br />
<br />
Теперь, при использовании опции '<tt>defaulroute</tt>' для pppd (которая указывает, что необходимо изменить на вновь созданное подключение маршрут по-умолчанию), даже после замены маршрута по-умолчанию новым, сеть 10.0.1.0, в которой в нашем примере и находится VPN-сервер, останется доступной.<br />
<br />
Как более точечный вариант (применяется в alterator-net-pptp 0.5.x) можно использовать скрипты {{cmd|ifup-pre}} и {{cmd|ifdown-post}} в каталоге конфигурируемого PPP-интерфейса.<br />
<br />
Наример:<br />
<source lang="bash"><br />
#!/bin/sh<br />
# sample /etc/net/ifaces/ppp0/ifup-pre; replace variables yourself<br />
ip route add VPN_SERVER via DEF_GW<br />
</source><br />
<source lang="bash"><br />
#!/bin/sh<br />
# sample /etc/net/ifaces/ppp0/ifdown-post; replace variables yourself<br />
ip route del VPN_SERVER via DEF_GW<br />
</source><br />
<br />
Не забудьте подставить нужные IP-адреса вместо VPN_SERVER и DEF_GW (не сеть, где VPN-сервер, а ее /32 префикс CIDR) и выполнить команду: {{cmd|chmod +x ifup-pre ifdown-post}}<br />
<br />
<div id="iprule"></div><br />
<br />
=== Сложная маршрутизация (или несколько таблиц маршрутизации) ===<br />
<br />
Под «сложной маршрутизацией» подразумевается наличие нескольких таблиц маршрутизации. Для их использования необходимо сконфигурировать правила ядра. В правилах по умолчанию можно увидеть следующее:<br />
<br />
<pre># ip rule show<br />
0: from all lookup local <br />
32766: from all lookup main <br />
32767: from all lookup default</pre><br />
<br />
Для настройки «сложной маршрутизациии» необходимо выполнить следующие операции:<br />
<br />
Шаг 1 : Сами таблицы определены в файле {{path|/etc/iproute2/rt_tables}}. Для создания конфигурации «сложной маршрутизации» необходимо вначале «создать» нужные таблицы в этом файле (если вы хотите использовать имена таблиц, а не числа).<br />
<br />
Шаг 2 : Необходимо заполнить таблицы. В конфигурационном каталоге интерфейса в файле <tt>ipv4route</tt> необходимо добавить маршрутные записи, не забывая указать <tt>table XX</tt>. Важно учитывать, что если строка начинается с режима ip route (add, del, replace, append, change), то по умолчанию будет использован режим <tt>DEFAULT_IPV4ROUTE_CMD</tt> (<tt>append</tt>).<br />
<br />
Шаг 3 : Определить правила в файле <tt>ipv4rule</tt>. Здесь есть особенности, связанные автоматической заменой/добавлением параметров. Если строка не начинается с операции del или add, то нужный режим будет подставлен автоматически. Это подходит для тех случаев, когда вам при "поднятии" интерфейса необходимо добавить правила, а при "опускании" — удалить. Возможность указывать del или add реализована для обратных случаев: если при "поднятии" интерфейса вам необходимо удалить правила, а при "опускании" — добавить. В этом случае add и del будут в нужный момент автоматически заменены на del и add.<br />
<br />
Пример такой конфигурации входит в /etc/net 0.7.12: (каталог документации examples/routing-LARTC-1/)<br />
<br />
=== Простое переключение маршрутов ===<br />
<br />
Пусть имеется eth-интерфейс, который используется постоянно, и настроен маршрут по умолчанию.<br />
Часто бывает необходимость настроить второй маршрут по умолчанию через беспроводной интерфейс,<br />
но с меньшей метрикой, чем у проводного интерфейса.<br />
В этом случае при поднятии WI-FI маршрут по умолчанию «развернется» в нужную сторону.<br />
<br />
Например:<br />
<br />
Для eth-интерфейса файл настроек {{path|/etc/net/ifaces/eth0/ipv4route}} будет таким:<br />
<pre>default via 192.168.3.254 metric 10</pre><br />
а для WI-FI-интерфейса файл настроек {{path|/etc/net/ifaces/ath0/ipv4route}} таким:<br />
<pre>default via 192.168.123.1 metric 5</pre><br />
<br />
<div id="wireless"></div><br />
=== Беспроводный Ethernet (или настройка WI-FI) ===<br />
Большинство беспроводных интерфейсов сейчас представлено системе как интерфейсы Ethernet. Соответственно беспроводный интерфейс будет иметь <b>TYPE=eth</b> (<s>[https://bugzilla.altlinux.org/show_bug.cgi?id=6283 #6283]</s>). Чтобы интерфейс нормально функционировал, необходимо кроме загрузки модуля с параметрами, воспользоваться утилитами {{cmd|iwconfig}} из пакета wireless-tools или {{cmd|wpa_supplicant}} из такого же пакета. Вместо того, чтобы запускать их вручную, можно поместить в конфигурационный каталог интерфейса файл <tt>iwconfig</tt> с командами iwconfig или файл <tt>wpa_supplicant.conf</tt> с конфигурацией wpa_supplicant. Они будут использованы автоматически.<br />
<br />
Пример [http://hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wireless.html конфигурации] (совместно с <tt>[http://ndiswrapper.sourceforge.net/ ndiswrapper]</tt>):<br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/options}}<br />
<pre>TYPE=eth<br />
MODULE=ndiswrapper<br />
NEVER_RMMOD=yes<br />
BOOTPROTO=dhcp<br />
USE_HOTPLUG=no<br />
ONBOOT=no</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/iwconfig}}<br />
<pre>essid default<br />
#key bababababa</pre><br />
<br />
<br />
Еще один пример использования etcnet для настройки беспроводной сети:<br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/options}}<br />
<pre>TYPE=eth<br />
USE_HOTPLUG=NO<br />
BOOTPROTO=static<br />
module=ipw2200<br />
WPA_DRIVER=wext</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/iwconfig}}<br />
<pre>essid homenet<br />
mode 1<br />
ap 00:11:D8:22:AD:0D<br />
channel 3<br />
rate 11M</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}}<br />
<pre>ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=0<br />
eapol_version=1<br />
ap_scan=1<br />
fast_reauth=1<br />
<br />
network={<br />
ssid="homenet"<br />
scan_ssid=1<br />
key_mgmt=WPA-PSK<br />
psk="this is my mega secret password string to wpa supplicant"<br />
}</pre><br />
<br />
Если вы хотите воспользоваться WPS:<br />
# создайте {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}} следующего вида:<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
update_config=1<br />
</pre><br />
# поднимите беспроводной интерфейс (ifup wlan0)<br />
# запустите wpa_cli и дайте команды wps_pbc (после этого нужно соответственно нажать кнопку WPS на точке доступа и подождать окончания обмена данными) и save_config (для записи конфигурации в <tt>wpa_supplicant.conf</tt>). Или же можно воспользоваться утилитой wpa_gui, отображающей процесс более наглядно.<br />
<br />
Пример файла {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}} при подключении к сети, использующей протокол WPA2-PSK(AES)<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=0<br />
eapol_version=1<br />
ap_scan=1<br />
fast_reauth=1<br />
<br />
network={<br />
ssid="home-lg"<br />
bssid=00:1B:11:87:C7:EA<br />
proto=RSN<br />
key_mgmt=WPA-PSK<br />
pairwise=CCMP TKIP<br />
group=CCMP TKIP<br />
psk="this is my mega secret password string to wpa supplicant"<br />
priority=2<br />
}<br />
</pre><br />
<br />
<div id="infiniband"></div><br />
<br />
=== Настройка Infiniband ===<br />
На сейчас ничем не отличается от настройки Ethernet, специфическая поддержка отсутствует (и для [[Infiniband#IP_over_IB|IP-over-IB]] не требуется). Пример конфигурации для Mellanox:<br />
<br />
Файл: <tt>/etc/modules</tt><br />
<pre>mlx4_ib<br />
ib_umad<br />
ib_ipoib</pre><br />
<br />
Файл: <tt>/etc/net/ifaces/ib0/options</tt><br />
<pre>TYPE=eth<br />
BOOTPROTO=dhcp<br />
ONBOOT=yes</pre><br />
<br />
<div id="sysctl"></div><br />
<br />
=== Использование автодополнения в sysctl.conf ===<br />
<br />
В конфигурационном каталоге интерфейса может находиться файл <tt>sysctl.conf</tt>, в котором можно перечислить переменные <tt>sysctl(8)</tt>. Но переменные могут быть как общесистемными, так и относящимися к интерфейсу. Естественно, запись в sysctl.conf настроек вида <tt>net.ipv4.conf.eth0.log_martians = 1</tt> достаточно неудобна, а при переименовании интерфейса велик риск не отредактировать файл <tt>sysctl.conf</tt> соответствующим образом.<br />
<br />
Эта проблема решается следующим способом : производится запись в файл только имени переменной и значение, а система /etc/net сама найдет путь к этой переменной и вызовет <tt>sysctl</tt> с полным именем. <br />
<br />
Пример содержания файла <tt>sysctl.conf</tt>:<br />
<pre>log_martians=1<br />
rp_filter=1</pre><br />
<br />
<div id="profiles"></div><br />
<br />
=== Подключение к Wi-Fi с сертификатом на аппаратном токене ===<br />
Для беспроводного подключения в корпоративных сетях могут использоваться сертификаты, записанные на аппаратном токене, например, Aladdin eToken. Для настройки такого подключения необходимо использовать {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}}.<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=wheel<br />
#eapol_version=1<br />
#ap_scan=2<br />
#fast_reauth=1<br />
pkcs11_engine_path=/usr/lib/openssl/engines/engine_pkcs11.so<br />
pkcs11_module_path=/usr/lib/libeTPkcs11.so<br />
update_config=0<br />
<br />
network={<br />
ssid="test"<br />
key_mgmt=WPA-EAP<br />
pairwise=CCMP TKIP<br />
group=CCMP TKIP<br />
eap=TLS<br />
identity="email@address.ru"<br />
engine_id="pkcs11"<br />
key_id="xxxxxxxxx"<br />
cert_id="xxxxxxxxx"<br />
engine=1<br />
}<br />
</pre><br />
где key_id и cerd_id взяты из вывода команды<br />
<pre><br />
# pkcs11-tool --module /usr/lib/libeTPkcs11.so -O -l<br />
</pre><br />
<br />
Используются оригинальные ("родные") драйвера Aladdin - pkiclient-5.00.28-0, и пакет openssl-engine_pkcs11-0.1.5-alt1.<br />
<br />
=== Профили конфигурации ===<br />
<br />
==== Определение профилей ====<br />
Профиль — именованный вариант конфигурации, в той или иной степени изменяющий базовую конфигурацию системы. Профили могут быть применены, например, для конфигурации ноутбука в разных сетевых окружениях, или при подготовке новой или тестовой конфигурации с возможностью быстрого возврата к старой. Практически профили реализуются следующим образом: для какого-либо из файлов, составляющих общесистемную конфигурацию или конфигурацию интерфейса, создаётся альтернативный вариант, который отличается добавлением в конце названия файла знака # и имени профиля.<br />
<br />
Например, пусть единственное отличие между профилями заключается в том, какой модуль ядра будет загружен для интерфейса eth0. В этом случае файл {{path|/etc/net/ifaces/eth0/options}} необходимо скопировать в {{path|/etc/net/ifaces/eth0/options#profile1}} и изменить значение переменной <tt>MODULE</tt> в одном из них. Далее при использовании конфигурации по умолчанию будет использован файл <tt>options</tt>, а при использовании профиля profile1 — файл <tt>options#profile1</tt>. Если при этом для назначения интерфейсу имени используется файл {{path|/etc/net/iftab}}, то скорее всего необходимо будет создать соответствующий файл {{path|/etc/net/iftab#profile1}}, так как другой модуль ядра указывает на другой физический интерфейс и исходный файл <tt>iftab</tt> работать не будет.<br />
<br />
Профили могут использоваться также и для отключения каких-то параметров конфигурации. Например, если используется файл <tt>ipv4route</tt> для установки маршрутов для интерфейса, то можно создать файл нулевого размера <tt>ipv4route#profile2</tt>, чтобы при использовании профиля profile2 никаких маршрутов не конфигурировалось.<br />
<br />
==== Выбор профиля при загрузке ====<br />
Если при загрузке системы ядру был передан параметр netprofile, то его значение будет использовано как имя профиля по умолчанию. Это может быть использовано для создания собственных пунктов меню загрузчиков LILO и GRUB с заранее определённым профилем сетевой конфигурации. Заданный таким образом профиль может быть далее переопределён другими методами. Следует понимать разницу между различными конфигурациями и различными результатами применения одной конфигурации. Например, если в двух разных сетях используется DHCP, то смысла в разных профилях конфигурации нет.<br />
<br />
Для загрузчика LILO секции <tt>/etc/lilo.conf</tt> могут выглядеть следующим образом:<br />
<pre>image=/boot/vmlinuz-up<br />
label=linux-up home<br />
append=" netprofile=home"<br />
[...]<br />
image=/boot/vmlinuz-up<br />
label=linux-up office<br />
append=" netprofile=office"<br />
[...]</pre><br />
Для приведённого примера необходимо будет создать варианты для файлов, отличающихся в профилях home и office, и можно будет выбирать при загрузке, какой из профилей необходимо использовать. Использование этого метода удобно, если смена сетевого окружения происходит синхронно с загрузкой системы.<br />
<br />
==== Выбор профиля по умолчанию ====<br />
Если требуется, чтобы определенный профиль конфигурации использовался по умолчанию, то необходимо записать его название в файл <tt>/etc/net/profile</tt>. Этот метод имеет приоритет над параметром ядра netprofile. Использование такого способа выбора профиля целесообразно, когда переключение между конфигурациями происходит реже, чем перезагрузка системы.<br />
<br />
==== Смена профиля во время работы ====<br />
Если требуется переконфигурировать сеть без перезагрузки или редактирования файла {{path|/etc/net/profile}}, то следует использовать параметры сервиса network, описанные в разделе [[#restart, reload и другие команды|restart, reload и другие команды]]. Этот метод имеет приоритет над профилем по умолчанию и профилем, выбранным при загрузке. Целесообразно его использовать, если смена сетевого окружения происходит чаще, чем перезагрузка системы.<br />
<br />
==== Определение профиля во время конфигурации интерфейса ====<br />
Если в каталоге конфигурации интерфейса существует исполняемый файл ненулевого размера с именем <tt>selectprofile</tt>, то этот файл будет выполнен и первое слово первой строки его стандартного вывода использовано как имя профиля, которое должно быть использовано для конфигурации данного интерфейса. Этот метод имеет приоритет над всеми остальными методами. Исходной задачей, требующей такого решения, являлось конфигурирование беспроводного интерфейса в зависимости от доступных точек доступа.<br />
<br />
Следует учитывать, что число вызовов файла <tt>selectprofile</tt> может меняться в зависимости от контекста и время его выполнения может быть различным, поэтому при написании такого файла следует учитывать, что первым параметром будет являться имя текущего сценария. В настоящее время это могут быть ifup*, ifdown*, setup* и shutdown*. Для приведённого выше примера имеет смысл реагировать только на вызовы из ifup или ifup-common.<br />
<br />
== См. также ==<br />
* [[Ресолвер]]<br />
<br />
== Примечания ==<br />
<references/><br />
<br />
{{Category navigation|title=etcnet|category=etcnet|sortkey=*}}<br />
[[Категория:WiFi]]<br />
{{Category navigation|title=Wi-Fi|category=WiFi|sortkey={{SUBPAGENAME}}}}<br />
[[Категория:Admin]]<br />
{{Category navigation|title=Системному администратору|category=Admin|sortkey={{SUBPAGENAME}}}}<br />
[[en:etcnet]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=Otrs&diff=54407Otrs2021-05-27T12:02:33Z<p>AntonFarygin: </p>
<hr />
<div>==OTRS (аббр. от англ. Open-source Ticket Request System) — открытая система обработки заявок.==<br />
<br />
[http://www.otrs.com/?lang=ru Официальный сайт], [https://ru.wikipedia.org/wiki/OTRS Страница в Википедии], [http://otrs.github.io/doc/manual/admin/stable/ru/html/ Руководство администратора], [http://otrs.ru/forum/ Русскоязычный форум].<br />
<br />
===Установка OTRS из репозитория p9===<br />
<br />
Для работы системы необходима база данных и веб-сервер, в примере используется MySQL и Apache. Для установки и обновления пакетов используются консольные команды, но вы можете использовать другие возможности ОС. Более подробно о способах обновления и установки пакетов можно прочесть на странице: [http://www.altlinux.org/%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%B0%D0%BC%D0%B8#.D0.9A.D0.BE.D0.BD.D1.81.D0.BE.D0.BB.D1.8C.D0.BD.D1.8B.D0.B5_.D0.BA.D0.BE.D0.BC.D0.B0.D0.BD.D0.B4.D1.8B_apt управление пакетами]. Все команды необходимо выполнять с правами [http://www.altlinux.org/Su администратора системы].<br /><br />
*Обновляем репозитории и ОС:<br />
<br />
#apt-get update<br />
#apt-get dist-upgrade<br />
<br />
*Устанавливаем необходимые пакеты(MySQL, Apache, OTRS, и конфигурационный файл для apache содержащийся в пакете otrs-apache2):<br /><br />
#apt-get install MySQL-server otrs otrs-apache2<br />
*Включаем автостарт сервисов при загрузке системы<br /><br />
#systemctl enable httpd2<br />
#systemctl enable mysqld<br />
*Читаем файл, с требованиями к настройке сервисов для установки otrs.<br /><br />
#cat /usr/share/doc/otrs-4.0.10/README.ALT.rus<br />
На момент написания данной статьи в данном файле содержалось указание на внесение изменений в настройки MySQL. Для этого любым текстовым редактором в файл /var/lib/mysql/my.cnf добавляем директиву из файла-рекомедации: max_allowed_packet=50M<br /><br />
* включаем использование каталога с расширениями для apache2: <br /><br />
# a2enextra httpd-addon.d<br />
<br />
Кроме того, в пакете apache2 <br />
присутствует 010-httpd-addon.d.conf, содержащий httpd-addon.d=no,<br />
что приводит к отключению httpd-addon.d при запуске a2chkconfig.<br />
Следует переопределить это значение, например, так:<br />
<br />
# echo httpd-addon.d=yes > /etc/httpd2/conf/extra-start.d/999-otrs.conf<br />
<br />
*Запускаем демонов веб-сервера и базы данных:<br /><br />
<br />
#service httpd2 start<br />
#service mysqld start<br />
<br />
*Данный пункт необязательный. Настройка безопасности MySQL сервера. Для настройки безопасности после запуска MySQL необходимо выполнить скрипт<br /><br />
<code>/usr/bin/mysql_secure_installation</code><br /><br />
Скрипт задаст Вам несколько вопросов. <br />
Skip root password for root<br />
По умолчанию пароль для root пустой, поэтому просто нажмите Enter.<br />
<br />
Install new password for root: security<br />
Задайте пароль для root<br />
Do remove an anonymous user<br />
Удалим анонимного пользователя<br />
Do not disallow remote connections<br />
Не запрещаем коннект к базе с удаленных серверов (если, конечно, эта опция вам нужна, в другом случае, запретите ее)<br />
Do remove a test database<br />
Тестовая база нам не нужна - удаляйте ее<br />
Do reload the privileges<br />
Перегрузим привилегии для их активации<br />
<br />
*Открываем браузер, в адресную строку вводим http://ip_вашего_сервера/otrs/installer.pl], следуем инструкциям для инсталляции. На данном этапе Вам понадобится: <br />
#пароль root от MySQL(отсутствует по умолчанию или используйте тот что вы задали в предыдущем пункте)<br />
#настройки почтового ящика на который будут приниматься заявки (поддерживаются POP3 и IMAP),<br />
#настройки сервера SMTP для отправки почты. <br />
#DNS имя хоста.<br />
<br />
{{Category navigation|title=HOWTO|category=HOWTO|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=Etcnet&diff=50834Etcnet2020-11-29T07:37:16Z<p>AntonFarygin: /* Интеграция с systemd */</p>
<hr />
<div>{{DISPLAYTITLE:etcnet}}<br />
{{span|font-size: 180%|Подсказки пользователю /etc/net}}<br />
<br />
{|<br />
|-valign="top"<br />
|Дополнительные страницы:<br />
* [[etcnet/qos|настройка QoS]]<br />
* [[etcnet/firewall|настройка сетевого экрана (firewall)]]<br />
Совсем быстрая настройка «с нуля»:<br />
# сконфигурируйте интерфейсы вручную, как надо;<br />
# запустите {{cmd|/etc/net/scripts/contrib/initconf write}};<br />
# проверьте содержимое подкаталогов {{path|/etc/net/ifaces/}}.<br />
|<br />
{| style="border:1px solid #AAA; background:#F9F9F9; width:280px; margin: 0 0 1em 1em; padding:.2em; text-align:center;" class=noprint<br />
|-<br />
|[[Image:Information.svg|20x20px]]Начиная с [[Branches/p5|пятой ветки]],<br /> <div style="display: inline; color: red;">в ALT Linux может использоваться и<br />[[NetworkManager/feature|NetworkManager]]</div> (используйте <tt>NM_CONTROLLED=no</tt><br />в {{path|$iface/options}}, если хотите использовать etcnet).<br />
|}<br />
|<br />
{| style="border:1px solid #AAA; background:#F9F9F9; width:155px; margin: 0 0 1em 1em; padding:.2em; float: right;" class=noprint<br />
|-<br />
|[[Image:Information.svg|20x20px]] external links:<br />
* [http://packages.altlinux.org/ru/Sisyphus/srpms/etcnet package info]<br />
* [http://git.altlinux.org/people/sbolshakov/packages/?p=etcnet.git;a=summary source git repo]<br />
|}<br />
|}<br />
<br />
<!-- Не убирайте div-ы, на них есть внешние ссылки! --><br />
<div id="quickstart"></div><br />
<br />
== Быстрый старт ==<br />
<div id="docs"></div><br />
<br />
=== Источники информации по /etc/net ===<br />
Обратите внимание, что начиная с версии 0.8.0 документация по /etc/net была собрана из комментариев, расположенных во множестве файлов, в несколько страниц руководств (man). Список всех файлов документации пакета <tt>etcnet</tt> можно получить командой:<br />
<pre>$ rpmquery -d etcnet</pre><br />
<br />
<div id="onecard"></div><br />
<br />
=== Быстрая настройка сетевого интерфейса стандарта Ethernet ===<br />
Для настройки одного сетевого интерфейса следует выполнить следующие шаги:<br />
<br />
Шаг 1: Создать каталог {{path|/etc/net/ifaces/eth0}}. Это каталог конфигурации данного интерфейса (<tt>eth0</tt>), в котором будут храниться файлы с настройками.<br />
<br />
Шаг 2: Определить, какой модуль необходим для вашей сетевой карты. Для этого можно использовать команды: <tt>lspci, lspcidrake, pciscan</tt>.<br />
<br />
Шаг 3: В каталоге конфигурации сетевого интерфейса создать файл <tt>options</tt> и записать в этот файл строку:<br />
<pre>MODULE=<имя модуля></pre> <br />
На данном этапе работу с файлом <tt>options</tt> можно завершить.<br />
<div style='padding:6px;border:1px solid red;'>Шаг 3 имеет смысл только в случае, если модули сетевых карт не грузятся автоматически другими средствами, например посредством udev. Если модуль уже загружен, параметр MODULE бесполезен.</div><br />
<br />
Шаг 4: Выяснить, какой IP-адрес должен быть назначен вашему интерфейсу. Если ваш сетевой интерфейс конфигурируется по DHCP, то в файл {{path|/etc/net/ifaces/eth0/options}} следует записать строку:<br />
<pre>BOOTPROTO=dhcp</pre><br />
и перейти к шагу 7.<br />
<br />
'''Замечание:''' В ряде случаев в файле <tt>options</tt> может понадобиться запись:<br />
<pre>DHCP_HOSTNAME=<имя машины без домена></pre><br />
Эта опция описана в странице руководства <tt>etcnet-options(5)</tt>.<br />
<br />
'''Замечание:''' В конце файла <tt>options</tt> необходимо наличие пустой строки.<br />
<br />
У сетевого интерфейса существуют два взаимосвязанных атрибута: <br />
* IP-адрес;<br />
* сетевая маска (mask). <br />
Шаг 5: Текущие значение адреса можно просмотреть командой:<br />
{{cmd|# /sbin/ip address show}} <br />
Вероятнее всего вы увидите, что интерфейс-петля lo (loopback) уже сконфигурирован с адресом 127.0.0.1/8 (что эквивалентно IP-адресу 127.0.0.1 и маске подсети 255.0.0.0). <tt>/8</tt> означает длину префикса CIDR (Classless InterDomain Routing).<br />
Для задания IP-адреса и маски подсети интерфейса <tt>eth0</tt> необходимо создать файл {{path|/etc/net/ifaces/eth0/ipv4address}}, в который следует записать IP-адрес с длиной маски, например:<br />
<pre>10.0.0.20/24</pre> <br />
<br />
Наиболее популярны маски /24 (т.е. длина префикса CIDR равная 24 эквивалентна маске сети 255.255.255.0 - это одна сеть класса C на 254 хоста) и /30. Для справки приводится таблица соответствия сетевых масок в различных нотациях.<br />
<ref><br />
{|<br />
|<br />
{| class="standard"<br />
|-<br />
!маска<br />в битах!!маска<br />точечно-<br />десятичная<br />
|-<br />
|/32||255.255.255.255<br />
|-<br />
|/31||255.255.255.254<br />
|-<br />
|/30||255.255.255.252<br />
|-<br />
|/29||255.255.255.248<br />
|-<br />
|/28||255.255.255.240<br />
|-<br />
|/27||255.255.255.224<br />
|-<br />
|/26||255.255.255.192<br />
|-<br />
|/25||255.255.255.128<br />
|-<br />
|/24||255.255.255.0<br />
|-<br />
|/23||255.255.254.0<br />
|-<br />
|/22||255.255.252.0<br />
|-<br />
|/21||255.255.248.0<br />
|-<br />
|/20||255.255.240.0<br />
|-<br />
|/19||255.255.224.0<br />
|-<br />
|/18||255.255.192.0<br />
|-<br />
|/17||255.255.128.0<br />
|}<br />
|<br />
| ||<br />
{| class="standard"<br />
|-<br />
!маска<br />в битах!!маска<br />точечно-<br />десятичная<br />
|-<br />
|/16||255.255.0.0<br />
|-<br />
|/15||255.254.0.0<br />
|-<br />
|/14||255.252.0.0<br />
|-<br />
|/13||255.248.0.0<br />
|-<br />
|/12||255.240.0.0<br />
|-<br />
|/11||255.224.0.0<br />
|-<br />
|/10||255.192.0.0<br />
|-<br />
|/9||255.128.0.0<br />
|-<br />
|/8||255.0.0.0<br />
|-<br />
|/7||254.0.0.0<br />
|-<br />
|/6||252.0.0.0<br />
|-<br />
|/5||248.0.0.0<br />
|-<br />
|/4||240.0.0.0<br />
|-<br />
|/3||224.0.0.0<br />
|-<br />
|/2||192.0.0.0<br />
|-<br />
|/1||128.0.0.0<br />
|}<br />
|}<br />
</ref><br />
<br />
Шаг 6: Выяснить адрес вашего шлюза (маршрут по умолчанию). Например, IP-адрес вашего шлюза — <tt>10.0.0.254</tt>. Тогда необходимо создать файл {{path|/etc/net/ifaces/eth0/ipv4route}}, в который записать строку:<br />
<pre>default via 10.0.0.254</pre><br />
Шаг 7: Убедиться, что всё выполнено правильно, выполнив команду:<br />
{{cmd|# service network restart}}<br />
Ваш интерфейс <tt>eth0</tt> должен быть успешно сконфигурирован. Если вы конфигурировали <tt>eth0</tt>, используя DHCP-сервер, но адрес интерфейсу не был назначен, то следует искать сообщение от DHCP-сервера в файле {{path|/var/log/messages}}.<br />
<br />
<div id="ifplugd"></div><br />
<br />
=== Настройка ifplugd ===<br />
Начиная с версии 0.7.10, /etc/net управляет ifplugd самостоятельно. Это было сделано для лучшей интеграции пакетов и для возможности следить за несколькими сетевыми интерфейсами одновременно. Для корректного использования ifplugd необходимо выполнить команду:<br />
# chkconfig ifplugd off<br />
<br />
и назначить переменную <tt>USE_IFPLUGD</tt> (USE_IFPLUGD=yes или USE_IFPLUGD=auto) в файлах <tt>options</tt> соответствующих интерфейсов (<tt>/etc/net/ifaces/<имя интерфейса>/options</tt>). Комментарий по данной переменной дан в странице руководства <tt>etcnet-options(5)</tt>.<br />
<br />
<div id="ppp"></div><br />
<br />
=== Настройка PPP-интерфейса ===<br />
Для настройки обычного модемного PPP-соединения необходимо:<br />
# Создать каталог конфигурации PPP-интерфейса, например, {{path|/etc/net/ifaces/ppp5}}. Вы можете задавать имена PPP-интерфейса вида pppN, pppNN, pppNNN и т. п., где N - любая цифра от 0 до 9;<br />
# Прочитать файл: {{path|/etc/net/ifaces/default/options-ppp}};<br />
# Создать файлы конфигурации. Вероятнее всего вам понадобятся <tt>pppconnect</tt> и <tt>pppdisconnect</tt>, чтобы <tt>pppd</tt> "знал", как дозваниваться и соединяться. Это скрипты для программы <tt>chat(8)</tt>. Кроме этого в файле <tt>pppoptions</tt> можно (часто нужно) перечислить опции <tt>pppd(8)</tt>, определяющие способ авторизации, скорость и название порта и т. п.;<br />
# Заполнить {{path|/etc/ppp/chap-secrets}} или {{path|/etc/ppp/pap-secrets}}.<br />
<br />
{{Attention|Использование опций "persist" и "maxfail 0", которые требуются pppd для непрерывных попыток восстановить интерфейс в случае проблем, может привести к невозможности загрузки системы в случае проблем с соединением. Вариант решения есть в {{altbug|23556#c1}} }}<br />
<br />
==== Настройка USB 3G-модема ====<br />
{{main|Установка и настройка 3G USB модема Huawei E1550}}<br />
<br />
<div id="ppp-pptp-pppoe"></div><br />
<br />
==== Настройка PPTP-интерфейса и PPPoE-интерфейса ====<br />
{{main|VPN (PPTP PPPoE)}}<br />
<br />
Хотя PPtP-соединения могут быть настроены и как обычные PPP-соединения, в /etc/net версии 0.7.10 для удобства пользователей была введена опция <tt>PPPTYPE</tt>. Она может принимать следующие значения:<br />
* <tt>dialup</tt> - обычный PPP-интерфейс.<br />
* <tt>pppoe</tt> - интерфейс PPPoE. Для такого интерфейса необходимо в опции <tt>HOST</tt> указывать имя Ethernet-интерфейса, через который будет производиться работа PPPoE. Побочным положительным эффектом будет то, что этот интерфейс будет при необходимости автоматически подниматься (т.е настраиваться) (см. [[#Зависимости между интерфейсами|Зависимости между интерфейсами]]).<br />
* <tt>pptp</tt> - интерфейс PPTP. Для такого интерфейса необходимо в опции <tt>PPTP_SERVER</tt> указывать имя хоста или IP-адрес PPtP-сервера, к которому будет производиться подключение. Обратите внимание, что хотя такие интерфейсы не имеют опции <tt>HOST</tt>, в большинстве случаев есть необходимость указать в опции <tt>REQUIRES</tt> интерфейс, через который будет достижим хост, указанный в <tt>PPTP_SERVER</tt>.<br />
<br />
См. также [[#Замечания о настройке VPN-подключения и туннелей|Замечания о настройке VPN-подключения и туннелей]].<br />
<br />
<div id="DNSandPPP"></div><br />
<br />
==== DNS и PPP-соединения ====<br />
<div style="display: inline; color: red;">Внимание: здесь описывается проблема, которая на самом деле была создана, а не решена — т.е. ради специфики [https://bugzilla.altlinux.org/show_bug.cgi?id=13789 kppp] была создана чётная ошибка в [https://bugzilla.altlinux.org/show_bug.cgi?id=13773 ppp-common]; последняя уже исправлена.</div><br />
<br />
Довольно долгое время существовала проблема неправильной модификации {{path|/etc/resolv.conf}} при установке PPP-соединений: [https://bugzilla.altlinux.org/show_bug.cgi?id=4249 #4249]. Сейчас она решена, но необходимо дать пояснения. Прежде всего убедитесь, что в файле {{path|/etc/resolv.conf}} есть строка:<br />
<pre># ppp temp entry</pre><br />
Если этой строки нет, то в файле не будут модифицироваться строки nameserver, если только какая-нибудь программа типа kppp это не сделает специально. Если такая строка есть, то {{path|/etc/resolv.conf}} будет модифицироваться в зависимости от значения булевой (логической) переменной RESOLV_MODS, которую необходимо задать в файле {{path|/etc/sysconfig/network}}.<br />
<br />
<div style="display: inline; color: red;">Внимание</div>: при ppp-common >= 0.4-alt1 строки <tt># ppp temp entry</tt> в файле {{path|/etc/resolv.conf}} при отсутствии PPP-соединения, поднятого какой-либо программой-«звонилкой», запущенной от администратора системы (пользователь root) — быть '''не должно'''! Если это есть, следует убрать, чтобы {{cmd|/etc/ppp/ip-up}} занимался обновлением записей про DNS в этом файле.<br />
<br />
<div id="restartreload"></div><br />
<br />
=== restart, reload и другие команды ===<br />
У сервиса <tt>network</tt> имеется ряд команд:<br />
* <tt>start</tt> - запустить все стационарные интерфейсы. hotplug-интерфейсы будут сконфигурированы при поступлении соответствующего вызова от hotplug.<br />
* <tt>startwith <имя профиля> </tt> - старт с указанным именем профиля, а не определённым автоматически.<br />
* <tt>stop</tt> - остановить все стационарные интерфейсы. hotplug-интерфейсы будут расконфигурированы при поступлении соответствующего вызова от hotplug.<br />
* <tt>stopwith <имя профиля> </tt> - стоп с указанным именем профиля, а не определённым автоматически.<br />
* <tt>restart</tt> - эквивалентно <tt>stop</tt> с последующим <tt>start</tt>, как и в большинстве других сервисов.<br />
* <tt>restartwith <имя профиля> </tt> - рестарт в контексте указанного профиля, эквивалентно <tt>stopwith <имя профиля> и startwith <имя профиля></tt>.<br />
* <tt>switchto <имя профиля> </tt> - переключение в указанный профиль, эквивалентно <tt>stop</tt> и <tt>startwith <имя профиля></tt>.<br />
* <tt>reload</tt> - семантически обозначает «актуализировать текущую конфигурацию». Для всех сконфигурированных в настоящий момент интерфейсов будет выполнена реконфигурация при наличии конфигурации.<br />
* <tt>check</tt> - автоматическая проверка конфигурационной базы.<br />
<br />
<div id="bootproto"></div><br />
<br />
=== Протоколы конфигурации адресов ===<br />
С помощью опции <tt>BOOTPROTO</tt> вы можете управлять тем, как у интерфейса будут появляться адреса и маршруты (это относится только к протоколу IPv4, так как протоколы IPv6 и IPX получают адреса только статически).<br />
* <tt>static</tt> — адреса и маршруты будут взяты из <tt>ipv4address</tt> и <tt>ipv4route</tt>.<br />
* <tt>dhcp</tt> — интерфейс будет сконфигурирован по DHCP.<br />
* <tt>ipv4ll</tt> — интерфейс будет сконфигурирован с помощью IPv4LL (link-local), ранее известному как ZCIP (zeroconf IP). Это значит, что из сети 169.254.0.0/16 будет подобран ещё не использованный адрес и назначен на интерфейс.<br />
Существует несколько комбинированных способов:<br />
* <tt>dhcp-static</tt> — если конфигурация по DHCP не удалась, конфигурировать методом static.<br />
* <tt>dhcp-ipv4ll</tt> — если конфигурация по DHCP не удалась, конфигурировать методом ipv4ll.<br />
* <tt>dhcp-ipv4ll-static</tt> — если конфигурация по DHCP не удалась, конфигурировать методом ipv4ll. Если и это не удалось, конфигурировать методом static.<br />
<br />
<div id="internals"></div><br />
<br />
=== Интеграция с systemd, или что делать если не поднимается интерфейс при старте. ===<br />
Начиная с версии 0.9.12 в etcnet добавлен Unit для включения интерфейсов по мере их появления в системе. Это позволяет избежать "гонок", когда сетевая подсистема поднимается раньше, чем ОС загружает драйвера для сетевых устройств.<br />
Для этого нужно выставить <tt>ONBOOT=no</tt> в файле options интерфейса и включить его подъём через systemd при загрузке: <tt>systemctl enable network@<имя интерфейса></tt>.<br />
<br />
== Устройство /etc/net ==<br />
<div id="generalinfo"></div><br />
<br />
=== Общие сведения ===<br />
/etc/net — это система конфигурации сети в Linux, т.е. эта система позволяет администратору Linux достаточно просто произвести настройки сети. Если же вы читаете эту страницу, то, вероятно, у вас возникли трудности с её использованием. Для решения возможных проблем полезно знать:<br />
<br />
<!--# [http://etcnet.org/ http://etcnet.org/] - сайт проекта, на котором можно найти примеры конфигурации и статьи по настройке системы. ?Рекурсия? --><br />
# /etc/net интегрирован в ALT Linux Sisyphus в виде пакетов:<br />
#* {{pkg|etcnet}} - базовые сценарии;<br />
#* {{pkg|etcnet-full}} - виртуальный пакет с зависимостями на все пакеты, которые могут использоваться сценариями /etc/net, с указанием их точных версий;<br />
#* {{pkg|etcnetconf}} - '''прототип''' конфигуратора;<br />
#* {{pkg|etcnet-defaults-desktop}} - умолчания для рабочей станции;<br />
#* {{pkg|etcnet-defaults-server}} - умолчания для сервера; <br />
# Пакеты {{pkg|etcnet}} и {{pkg|net-scripts}} — две конфликтующие реализации «подсистемы конфигурации сети» (network-config-subsystem).<br />
# При установке etcnet вместо net-scripts (или наоборот) сервис <tt>network</tt> оказывается выключенным. Это означает, что при загрузке системы сеть не будет сконфигурирована, что можно проверить командой {{cmd|chkconfig --list network}}. Для быстрого исправления проблемы можно дать команду {{cmd|chkconfig network reset}}.<br />
# etcnet '''НЕ''' импортирует автоматически настройки net-scripts. Если вы только что установили etcnet, и ваши сетевые интерфейсы всё ещё остаются сконфигурированными (несмотря на уже отсутствующий пакет net-scripts), то вы можете запустить сценарий {{cmd|/etc/net/scripts/initconf}}. Он попытается проанализировать текущее состояние интерфейсов и выведет вам результат. Никаких файлов при этом записано не будет. Если вам подходит вывод initconf, то запустите его с параметром write и он проделает то же самое, но уже с сохранением конфигурации.<br />
# Для корректной работы системы в целом необходимо, чтобы содержимое файла {{path|/etc/sysconfig/network}} было корректным.<br />
# Переменные <tt>sysctl</tt> в ОС ALT Linux конфигурируются в следующих местах<ref>{{altbug|26498}}</ref>:<br />
#* {{path|/etc/sysctl.conf}} (глобальные системные);<br />
#* {{path|/etc/sysconfig/network-scripts/sysctl.conf}} (общие сетевые в net-scripts, исходно файл не существует);<br />
#* {{path|/etc/net/sysctl.conf}} (общие сетевые в /etc/net);<br />
#* <tt>/etc/net/ifaces/*/sysctl.conf*</tt> (частные для конкретных интерфейсов или их типов в /etc/net, создаются вручную при необходимости).<br />
Скрипты etcnet используют эти файлы в указанном порядке.<br />
<br />
<div id="options.d"></div><br />
<br />
=== Организация опций /etc/net по умолчанию ===<br />
Методология /etc/net предусматривает несколько шагов наследования опций, первый из которых — загрузка опций по умолчанию. В ранних версиях это происходило из одного файла <tt>/etc/net/options</tt>, сейчас же в вашем распоряжении есть каталог {{path|/etc/net/options.d}}, из которого будут последовательно прочитаны все файлы.<br />
<br />
Иными словами, оригинальный архив etcnet содержит только файл {{path|/etc/net/options.d/00-default}}. Упаковщик etcnet, вместо того, чтобы добавить патч в какой-либо дистрибутив, просто добавляет файл с бОльшим номером, который переопределяет нужные опции.<br />
<br />
Ввиду решения различных задач, администратору системы может не подойти содержание дистрибутивного набора. В этом случае администратор может создать файл с ещё более высоким номером и определить настройки умолчания для своей системы. В результате такого подхода:<br />
# Уменьшается количество патчей (хотя их свойство "отваливаться" от пакета при его упаковке бывает полезным).<br />
# Не изменяются файлы с опциями, принадлежащие пакету. Это делает обновление пакета намного более корректным.<br />
# Можно легко увидеть, какие опции переопределяются на каждом этапе.<br />
<br />
<div id="iftab"></div><br />
<br />
=== Назначение iftab ===<br />
<br />
Начиная с дистрибутивов, основанных на ветках p5 и 5.1, переименование интерфейсов возложено на udev; см. тж. [http://lists.altlinux.org/pipermail/sisyphus/2009-June/340033.html это письмо] и <s>[https://bugzilla.altlinux.org/show_bug.cgi?id=19313 #19313]</s> и [http://packages.altlinux.org/ru/Sisyphus/srpms/wireless-tools/changelog %changelog ifrename]. В дистрибутивах на базе p8 и новее может быть полезным пакет udev-rule-generator-net, который заполняет /etc/udev/rules.d/70-persistent-net.rules. Возможно, следует отказаться от имён интерфейсов вида ethN и использовать, например, etherN ввиду того, что в новом systemd/udev официально сломан механизм переименования. Данное нововведение в ALT пока отменено; см. тж. [https://bugzilla.altlinux.org/32167 #32167].<br />
<br />
Имена сетевых интерфейсов по умолчанию, как правило, содержат их тип (eth, ppp, wifi, ipsec) и индекс: 0 - для первого созданного интерфейса, 1 - для второго и т. д. При этом соответствие автоматически назначенных имён физическим устройствам может не сохраняться.<br />
<br />
Эта особенность неудобна, когда машина с Linux имеет более одного интерфейса каждого типа. Типичными примерами являются маршрутизаторы и ноутбуки. В маршрутизаторах, как правило, используются однотипные сетевые карты и при их замене или изменении порядка на PCI-шине соответствие оказывается нарушенным. В ноутбуках используются ethernet и wifi-устройства с горячим подключением, при этом слотов и карт может быть более чем 1. В этом случае пользователь/администратор скорее всего пожелает закрепить за каждой сменной картой её конфигурацию.<br />
<br />
/etc/net при конфигурации интерфейса использует то имя, под которым он сконфигурирован, а именно имя каталога, в котором хранятся файлы конфигурации интерфейса.<br />
<br />
Для привязки сетевой карты к имени интерфейса в простых случаях можно воспользоваться файлом {{path|/etc/iftab}}, man-страница по формату которого входит в пакет <tt>ifrename</tt> (<tt>iftab(5)</tt>).<br />
<br />
Использование {{path|/etc/iftab}} удобно, поскольку позволяет сохранять традиционные имена интерфейсов (например, eth0), но этот механизм не поддерживает расширенную функциональность /etc/net (в частности, ''профили'' /etc/net).<br />
<br />
Средством, позволяющим использовать все возможности <tt>etcnet</tt>, является файл {{path|/etc/net/iftab}}, обрабатываемый не утилитой <tt>ifrename</tt>, а непосредственно <tt>etcnet</tt>. Синтаксис этого файла совпадает с синтаксисом {{path|/etc/iftab}}. Ограничением же является невозможность использовать стандартные имена интерфейсом (<tt>ethX</tt>, <tt>pppX</tt>), так как переименование интерфейсов происходит уже после конфигурации интерфейса ядром. В случае, если вам необходим {{path|/etc/net/iftab}}, имеет смысл переименовать интерфейсы, давая им либо двухзначные номера (<tt>eth00</tt>, <tt>eth01</tt>...), либо осмысленные названия (<tt>isplink</tt>, <tt>lan</tt>...)<br />
<br />
См. письмо про [http://lists.altlinux.org/pipermail/sisyphus/2009-March/337924.html важность /etc/iftab]<br />
и тж. это письмо про [http://lists.altlinux.org/pipermail/devel/2007-October/065097.html отличия etcnet и сервиса ifrename]:<br />
{{начало цитаты}} Комментарии к письмам этого треда (с некоторыми пояснениями):<br />
<br />
1. «etcnet уже научился менять местами eth0 и eth1?»<br />
<br />
Освоение этого приема обладает сомнительной пользой. Рекомендуется <br />
рассматривать eth0 как временное имя с малым сроком жизни,<br />
а для повышения комфорта пользователей Ethernet-интерфейсы предлагается<br />
называть eth00, eth01, eth02 etc.<br />
<br />
2. «Существование (номинальное) net-scripts вынуждает поддерживать<br />
ряд сервисов, которые иначе могли бы быть упразднены»<br />
<br />
Эти сервисы можно "обезвредить" (отключить) контролем CONFMETHOD<br />
из /etc/sysconfig/network. При этом зависимости на пакет etcnet<br />
не возникнет, только на network-config-subsystem. Примеры таких<br />
пакетов должны быть в Sisyphus.<br />
<br />
3. «после приведения в порядок /etc/udev/rules.d/19-udev-ifrename.rules<br />
нужности в /etc/net/iftab я не заметил»<br />
<br />
Важнейшее принципиальное отличие /etc/net/iftab от /etc/iftab —<br />
нахождение /etc/net/iftab в специальном пространстве имён. Для него<br />
действуют механизмы определения профиля и хоста конфигурации. Это,<br />
например, позволит, при необходимости, составить конфигурацию так, что срочный<br />
ремонт маршрутизатора сведётся к переносу диска (или массива)<br />
из сгоревшего шасси в запасное. Возможны и другие примеры, которые<br />
станут невозможными при помещении iftab в /etc и его прямой<br />
интерпретации.<br />
<br />
Конечно, пользователю единственного ноутбука с одним-двумя сетевыми<br />
интерфейсами такая практика — полный overkill (т.е. такая практика ему не нужна), но его никто и не<br />
заставляет видеть всю подводную часть (т.е. все тонкости работы и настройки). В этом и гибкость.{{конец цитаты}}<br />
<br />
<div id="specifaces"></div><br />
<br />
=== Интерфейсы lo, default и unknown ===<br />
Сразу после установки пакета <tt>etcnet</tt> в каталоге {{path|/etc/net/ifaces}} (в котором хранятся конфигурации интерфейсов) находятся три каталога: <br />
* lo<br />
* default<br />
* unknown<br />
<br />
Интерфейс '''lo''' — стандартная "петля" (loopback), которая должна быть во всякой Linux-системе, поэтому конфигурация для него включена по умолчанию. В остальном он ничем не отличается от любого другого интерфейса и конфигурируется точно так же файлами <tt>options</tt> и <tt>ipv4address</tt>.<br />
<br />
Интерфейс '''default''' — это не интерфейс, а специальный каталог, файлы в котором обрабатываются следующим образом:<br />
* <tt>resolv.conf</tt> — если присутствует, то копируется в {{path|/etc/resolv.conf}}.<br />
* <tt>options</tt> — файл опций, читается после опций по умолчанию.<br />
* <tt>options-<вид интерфейса></tt> — этот файл содержит опции, специфичные для данного вида интерфейсов. Некоторые из них не обязательны и позволяют использовать особенности данного вида интерфейсов, например, <tt>LINKDETECT</tt> в <tt>options-eth</tt>; другие обязательны, например, <tt>HOST</tt> в <tt>options-bri</tt>. Обратите внимание, что эти файлы не рекомендуется редактировать. Если вам нужно задать опцию для интерфейса, то, как правило, это можно сделать в файле <tt>options</tt> в конфигурационном каталоге данного интерфейса. Это облегчит процесс обновления пакета etcnet.<br />
* <tt>sysctl.conf-<вид интерфейса></tt> — файл с переменными sysctl, которые необходимо изменить. Сейчас единственный такой файл — <tt>sysctl.conf-dvb</tt>, который отключает <tt>return path filter</tt>, что всегда нужно в случае асимметричной маршрутизации.<br />
* <tt>iplink-<вид интерфейса></tt> — файл с командами iplink, специфичными для данного вида.<br />
* <tt>selectprofile</tt> — если этот файл исполняемый, то он будет вызван из сценариев <tt>ifup/ifdown</tt>, <tt>setup/shutdown</tt> для того, чтобы вернуть на стандартном выводе имя профиля, которое необходимо использовать. Это позволяет автоматически переключать профили в зависимости от каких-либо условий. В поставку включен пример сценария: {{path|/etc/net/scripts/contrib/selectprofile}}.<br />
* <tt>fw</tt> — каталог с настройками сетевого экрана по умолчанию.<br />
<br />
Интерфейс '''unknown''' — специальная конфигурация, которая будет использована в том случае, когда /etc/net просят сконфигурировать hotplug-интерфейс, для которого не существует каталога конфигурации. Это будет работать только в том случае, если включена опция <tt>ALLOW_UNKNOWN</tt>.<br />
<br />
<div id="broadcast"></div><br />
<br />
=== broadcast address===<br />
<br />
Периодически возникает вопрос: почему после старта /etc/net при запуске <tt>ifconfig</tt> можно видеть <tt>Bcast:0.0.0.0</tt>, хотя при использовании net-scripts это поле было правильным? <br />
<br />
Ответ: net-scripts оперируют адресом, маской, адресом сети и широковещательным адресом, пытаясь определить неизвестные компоненты из известных, а <tt>config-ipv4</tt> просто передаёт утилите <tt>ip</tt> содержимое файла <tt>ipv4address</tt>, не проверяя его содержание.<br />
Важно заметить, что:<br />
* Если <tt>iproute2</tt> изменит свой синтаксис, то с очень вероятно, что администратору будет необходимо редактировать только конфигурационные файлы.<br />
* Не было найдено проблем с «отсутствующим» broadcast address. Он есть в таблице маршрутизации <tt>local</tt>. <br />
* Администратор всегда может назначить адрес broadcast в файле <tt>ipv4address</tt>. Это можно сделать с помощью выражения <tt>broadcast +</tt><ref><br />
Выдержка из файла ip-cref.ps, который входит в документацию пакета iproute2:<br />
<br />
<pre><br />
* broadcast ADDRESS<br />
<br />
the broadcast address on the interface.<br />
It is possible to use the special symbols '+' and '-' instead of the broadcast address. In this case, <br />
the broadcast address is derived by setting/resetting the host bits of the interface prefix.<br />
NB. Unlike ifconfig, the ip utility does not set any broadcast address unless explicitly requested.<br />
</pre><br />
</ref>.<br />
'''Замечание:''' В версии 0.8.0 появилась опция <tt>AUTO_BROADCAST</tt> для автоматического дополнения каждой строки <tt>ipv4address</tt>.<br />
<br />
<div id="never_rmmod"></div><br />
<br />
=== Ядро 2.6 и "пропадающие" интерфейсы ===<br />
Иногда возможна ситуация: Если два интерфейса используют один и тот же модуль ядра, и у них определена опция <tt>MODULE</tt> (то есть скрипты /etc/net сами загружают и выгружают модули), то при опускании (отключении) одного интерфейса пропадает и второй интерфейс. <br />
<br />
Такая ситуация почти наверняка возникает при использовании ядра 2.6, особенностью которого являются значения счётчика ссылок (третий столбец вывода {{cmd|lsmod}}). Когда счетчик оказывается равен нулю (довольно часто), скрипты могут попытаться выгрузить модуль интерфейса, для которого запущен ifdown. И такая выгрузка происходит, несмотря на то, что другой интерфейс, использующий этот же модуль, находится в состоянии UP (т.е. он активен).<br />
<br />
Чтобы заблокировать выгрузку модулей, можно использовать булеву переменную <tt>NEVER_RMMOD</tt>. Возможно, позже это будет происходить автоматически для ядер следующих версий.<br />
<br />
<div id="removables"></div><br />
<br />
=== Cценарии конфигурации сети и hotplug-интерфейсы ===<br />
<br />
==== Cценарии конфигурации сети ====<br />
Существует несколько сценариев конфигурации сети.<br />
<br />
* Первый и самый простой — выполнение {{cmd|service network start}} при старте системы или вручную. При этом требуется только сформировать погруппные (потиповые) списки интерфейсов, подлежащих обработке, и последовательно выполнить требуемые действия. Модули ядра при этом загружаются сценариями /etc/net, при этом имена модулей берутся из опции <tt>MODULE</tt> (в этой опции можно в кавычках перечислить несколько имён и они будут последовательно загружены). Этот метод часто используется на практике и лучше всего подходит для маршрутизаторов. Преимущество метода в том, что вся необходимая информация сконцентрирована в одном месте — каталоге {{path|/etc/net}}. Если опция <tt>MODULE</tt> не определена, то будет предпринята попытка загрузки по имени интерфейса, подразумевая, что файл {{path|/etc/modules.conf}} правильно заполнен.<br />
<br />
* Второй сценарий — реакция на событие <tt>ifplugd</tt>. В предыдущих версиях существовала сложность, так как требовалась синхронная настройка сервиса <tt>ifplugd</tt>. Сейчас логика работы определена, что выражено в том, что /etc/net взяла управление <tt>ifplugd</tt> на себя. В части загрузки модуля этот сценарий не отличается от первого.<br />
<br />
* Третий сценарий — реакция на появление или исчезновение сменного устройства. Для обработки таких событий предназначены сценарии <tt>/etc/net/scripts/{ifup,ifdown}-removable</tt>, которые вызываются из сценариев пакетов hotplug и pcmcia-cs. Сложность заключается в том, что для сменных PCMCIA-карт вызовы могут дублироваться: для одного и того же события первый раз ifup-removable будет вызван из hotplug, второй — из pcmcia-cs. Кроме того, hotplug также реагирует на загрузку модулей ядра для обычных карт PCI и, более того, включает сценарии, которые пытаются загружать модули самостоятельно. В этом контексте /etc/net получает слишком много вызовов от hotplug и по умолчанию их игнорирует (<tt>USE_HOTPLUG=no</tt>).<br />
<br />
* Четвёртый сценарий - реакция на появление сетевого интерфейса через systemd. Такое событие обрабатывается через сервис network@.service, которому в качестве аргумента, следующего за @ нужно передать имя интерфейса. Например - systemctl enable network@eth0. В этом случае интерфейс будет подниматься после его появления в системе, что полезно в некоторых случаях, когда система загружается быстрее появления интерфейсов и на момент запуска сервиса network сетевых интерфейсов в системе ещё нет.<br />
<br />
==== hotplug-интерфейсы ====<br />
Рассмотрим использование hotplug-интерфейсов. <br />
<br />
Пусть администратору необходимо настроить действительно сменную карту. После заполнения {{path|/etc/iftab}} или {{path|/etc/net/iftab}} в файле <tt>options</tt> необходимо будет задать <tt>USE_HOTPLUG=yes</tt>. После этого при получении события от hotplug /etc/net будет работать в том контексте, что модуль в загрузке и выгрузке не нуждается. <br />
<br />
Важно заметить, что '''такой интерфейс будет пропущен при обычном старте сети''', т.к. если он сменный, то единственный достоверный способ узнать, что он присутствует — получить вызов от hotplug. Из факта выполнения {{cmd|service network start}} совсем не следует, что какой-то один или несколько из сконфигурированных hotplug-интерфейсов сейчас в наличии и требуют конфигурации. Если вы хотите вручную расконфигурировать hotplug-интерфейс до его извлечения, используйте команду {{cmd|ifdown}}. Для повторной конфигурации вставьте его ещё раз.<br />
<br />
Также существует опция <tt>USE_PCMCIA</tt>. Если события для вашей карты генерирует pcmcia-cs, то вам нужно её включить. Если события генерируются только hotplug, то используйте опцию <tt>USE_HOTPLUG</tt>.<br />
<br />
<div id="eth0"></div><br />
<br />
=== Проблема стандартных имен интерфейсов (eth0 и др.)===<br />
<br />
При использовании файла {{path|/etc/net/iftab}}, то есть в случае применения сложных конфигураций, возникает следующая проблема:<br />
* При загрузке модулей имена интерфейсов принимают вид eth0, eth1, eth2… Какие именно — в общем случае контролировать нельзя.<br />
* Имя eth0 обладает наибольшей вероятностью оказаться занятым.<br />
* ifrename не может переименовать интерфейс, если целевое имя уже занято (udev использует <tt>ifrename -t</tt>, но это не работает после начальной загрузки, см. руководство к ifrename).<br />
<br />
С учётом вышеизложенного, если {{path|/etc/net/iftab}} содержит тот же набор имён интерфейсов, что уже имеется после загрузки модулей (то есть <tt>eth0</tt>/<tt>eth1</tt> и другие «стандартные» названия), то единственный случай, когда etcnet сможет без ошибок обработать такой файл — изначальное соответствие, не требующее переименования.<br />
<br />
Таким образом, при использовании {{path|/etc/net/iftab}} имеет смысл давать интерфейсам названия, отличные по виду от тех, что назначает ядро. В простых случаях лучше использовать {{path|/etc/udev/rules.d/70-persistent-net.rules}} ({{path|/etc/iftab}} до бранчей p5/5.1).<br />
<br />
<div id="advanced"></div><br />
<br />
== Расширенные возможности ==<br />
<div id="multipleIPs"></div><br />
<br />
=== Несколько IP-адресов или маршрутов на одном интерфейсе ===<br />
<br />
Вы можете помещать произвольное количество IP-адресов в файл <tt>ipv4address</tt> по одному адресу на каждой строке. То же самое относится к статическим маршрутам и файлу <tt>ipv4route</tt>.<br />
<br />
Обратите внимание, что /etc/net не анализирует содержимое этих файлов, а формирует на основе каждой строки командную строку для утилиты {{cmd|ip}}. Это означает, что вы можете помещать в этих файлах произвольные поддерживаемые {{cmd|ip}} опции и они будут обработаны. Например, в файле <tt>ipv4route</tt> можно поместить строку:<br />
<pre>10.0.1.0/24 via 10.0.0.253 metric 50 weight 5 table 100</pre><br />
<br />
<div id="requires"></div><br />
<br />
=== Зависимости между интерфейсами ===<br />
У интерфейсов:<br />
* vlan<br />
* bond <br />
* bri <br />
* teql <br />
входящих в группу зависимых физических, должна быть определена опция <tt>HOST</tt> со списком интерфейсов, необходимых для инициализации текущего интерфейса. Если хост-интерфейс не сконфигурирован при поднятии зависимого интерфейса, то это будет исправлено.<br />
<br />
Кроме обязательной для определённых интерфейсов опции <tt>HOST</tt>, может быть задана и необязательная для всех остальных интерфейсов опция <tt>REQUIRES</tt>. Интерфейсы, перечисленные в этой опции, будут считаться зависимостями текущего интерфейса. Например, по умолчанию попытка сконфигурировать интерфейс А, который зависит от Б и В, приведёт сначала к конфигурации Б и В. Аналогично, при расконфигурации Б или В сначала будет расконфигурирован А.<br />
<br />
Зависимость одного интерфейса от другого не всегда формальна. Например, в сценарии <tt>ifup-pre</tt> одного интерфейса может использоваться команда, которая потребует разрешения DNS-имени, которое может быть разрешено только с помощью <tt>resolv.conf</tt>, инсталлируемого другим интерфейсом. Или это может быть PPPoE/PPtP-интерфейс, требующий Ethernet-интерфейс для работы.<br />
<br />
Для того, чтобы избежать неожиданных сбоев в таких случаях, правильно задавайте опцию <tt>REQUIRES</tt>.<br />
<br />
<div id="postpre"></div><br />
<br />
=== Пользовательские сценарии post и pre ===<br />
Существует возможность поместить в каталог конфигурации интерфейса файлы, которые будут выполнены в определённые моменты. Для этого они должны быть исполняемыми и называться следующим образом:<br />
* <tt>ifup-pre</tt> — для выполнения перед конфигурированием интерфейса.<br />
* <tt>ifup-post</tt> — для выполнения после конфигурирования интерфейса. Например, можно запустить почтовую систему.<br />
* <tt>ifdown-pre</tt> — для выполнения перед расконфигурированием интерфейса. Например, можно остановить почтовую систему.<br />
* <tt>ifdown-post</tt> — для выполнения после расконфигурирования интерфейса.<br />
<br />
Также в версии до 0.8.0 возможно использовать следующие сценарии (они должны быть исполняемыми):<br />
* <tt>/etc/net/scripts/ifup-pre-local</tt><br />
* <tt>/etc/net/scripts/ifup-post-local</tt><br />
* <tt>/etc/net/scripts/ifdown-pre-local</tt><br />
* <tt>/etc/net/scripts/ifdown-post-local</tt><br />
<br />
Они будут вызваны для каждого интерфейса. Начиная с версии 0.8.0 эти сценарии называются так:<br />
* <tt>/etc/net/ifup-pre</tt><br />
* <tt>/etc/net/ifup-post</tt><br />
* <tt>/etc/net/ifdown-pre</tt><br />
* <tt>/etc/net/ifdown-post</tt><br />
Семантика сохранена.<br />
<br />
<div id="iplink"></div><br />
<br />
=== Управление канальными параметрами интерфейсов ===<br />
<br />
Если поместить в конфигурационный каталог интерфейса файл <tt>iplink</tt>, в котором в каждой строке будут записаны команды режима link утилиты {{cmd|ip}}, то они будут выполнены при конфигурации интерфейса. <br />
<br />
Например, если необходимо, чтобы интерфейс net1 имел MAC-адрес aa:bb:cc:dd:ee:ff и MTU 200 байт, то в файл {{path|/etc/net/ifaces/net1/iplink}} нужно поместить следующее:<br />
<pre>address aa:bb:cc:dd:ee:ff<br />
mtu 200</pre><br />
<br />
Обратите внимание, что в этом случае в {{path|/etc/net/iftab}} вам необходимо будет использовать селектор <tt>businfo</tt> или <tt>driver</tt> вместо <tt>mac</tt>.<br />
<br />
<div id="ethtool"></div><br />
<br />
=== Управление физическими параметрами интерфейсов ===<br />
Если поместить в конфигурационный каталог интерфейса файл <tt>ethtool</tt>, в котором будет строка с параметрами программы ethtool, то она будет выполнена при конфигурации интерфейса. <br />
<br />
Например, если есть необходимость, чтобы интерфейс net1 имел скорость 10Мбит/с и авто-согласование скорости было отключено, то в файл {{path|/etc/net/ifaces/net1/ethtool}} нужно поместить следующую строку:<br />
<br />
<pre>speed 10 autoneg off</pre><br />
<br />
<div id="bridge"></div><br />
<br />
=== Настройка Ethernet-моста ===<br />
<br />
Для настройки Ethernet-моста (далее — моста) есть 3 пути: <br />
# Linux bridge посредством bridge-utils<br />
# Linux bridge посредством iproute2<br />
# Openvswitch<br />
<br />
Linux bridge наиболее простая реализация. Если вам не нужно все, что умеет [http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=README;hb=HEAD openvswitch] , то можно использовать Linux bridge.<br />
<br />
==== Linux bridge посредством bridge-utils (до p8 включительно) ====<br />
Перед настройкой Ethernet-моста (далее — моста) с помощью etcnet сначала необходимо убедиться, что установлен пакет bridge-utils. Etcnet использует утилиту brctl для настройки моста, и, если утилита не установлена, то при перезапуске системы сеть станет недоступна. Если интерфейсы, входящие в состав моста, являются единственными физически подключенными и настройка моста происходит с удаленного узла через эти интерфейсы, то требуется соблюдать осторожность, т.к. эти интерфейсы перестанут быть доступны. В случае ошибки в конфигурации потребуется физический доступ к серверу. Для страховки, перед перезапуском сервиса network можно открыть ещё одну консоль и запустить там, например, команду: {{cmd|sleep 500 && reboot}}.<br />
<br />
Также имейте ввиду, что если вы подключаетесь по ssh к серверу через bridge-интерфейс (по его ip-адресу), то по умолчанию при опускании любого интерфейса-члена моста Etcnet так же опустит и сам мост (и ваше подключение пропадет). Чтобы избежать этого, установите в файле {{path|options}} того интерфейса, который нужно опускать, переменную <tt>IFDOWN_CHILDREN=no</tt>. Но учтите, что и включаться в бридж при старте тогда этот интерфейс по умолчанию не будет. <br />
<br />
Предположим, требуется настроить Ethernet-мост, пусть он будет называться <tt>br0</tt>. <br />
Тогда для его настройки необходимо завести каталог {{path|/etc/net/ifaces/br0}} и создать там файлы со следующими данными:<br />
<br />
* <tt>brctl</tt><br />
<br />
<pre> stp AUTO on </pre><br />
<br />
* <tt>ipv4address</tt>:<br />
<pre> 192.168.100.200/24 </pre><br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=bri<br />
HOST='eth0 tap0'<br />
BOOTPROTO=static </pre><br />
<br />
Содержимое файла <tt>brctl</tt> передаётся утилите brctl. <tt>AUTO</tt> означает, что скрипт {{cmd|setup-bri}} самостоятельно определит имя bridge-интерфейса (см. файл {{path|/usr/share/doc/etcnet-*/README.bridge}}). Если же в вашей сети этот мост один и рассылать пакеты протокола STP не нужно, тогда файл brctl с указанной опцией не нужен. По умолчанию [http://xgu.ru/wiki/man:brctl#Spanning_Tree_Protocol_.28.D0.9F.D1.80.D0.BE.D1.82.D0.BE.D0.BA.D0.BE.D0.BB_.D0.BE.D1.81.D1.82.D0.BE.D0.B2.D0.BD.D0.BE.D0.B3.D0.BE_.D0.B4.D0.B5.D1.80.D0.B5.D0.B2.D0.B0.29 STP выключен].<br />
<br />
IP-адрес для интерфейса, как обычно, будет взят из <tt>ipv4address</tt>.<br />
<br />
В опции <tt>HOST</tt> файла <tt>options</tt> нужно указать те интерфейсы, которые будут входить в мост. Если в него будут входить интерфейсы, которые до этого имели IP-адрес (например, eth0), то этот адрес должен быть удалён (например, можно закомментировать содержимое файла {{path|ifaces/eth0/ipv4address}}).<br />
<br />
При старте сети сначала поднимаются интерфейсы, входящие в мост, затем сам мост (автоматически). Для назначения адреса мосту можно также использовать DHCP (<tt>BOOTPROTO=dhcp</tt>). Но при этом важно обратить внимание на параметр <tt>forwarding delay</tt> (man brctl / setfd), так как интерфейс, подключенный к мосту, не сразу входит в режим передачи пакетов, и это может вызвать dhcp таймаут. Версии etcnet в дистрибутивах ALT Linux Server 4 и Desktop 4.1 (0.9.7-alt0.M40/M41) имеют эту недоработку, которая исправлена только в версии 0.9.9-alt1. <br />
Документацию по настройке моста с вопросами и ответами (перевод) можно найти на http://xgu.ru/wiki/Linux_Bridge, а его оригинал доступен на http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge.<br />
<br />
Внимание: инструкция на xgu.ru чуть устарела. Команда<br />
<pre>$ brctl setfd br0 0</pre><br />
не выключает задержку, а лишь приводит к величине задержки по умолчанию (15 или даже 30 секунд). Можно попробовать задать задержку в 1сек для уменьшения времени инициализации сети.<br />
<br />
С пакетом etcnet поставляются примеры конфигурации. Один из них показывает, как из двух ethernet-интерфейсов port0 и port1 можно собрать мост bridge (каталог документации examples/Ethernet-bridge-GRE/).<br />
<br />
Безотносительно к etcnet, следует иметь ввиду проблему, связанную с NAT: <s>[http://bugzilla.kernel.org/show_bug.cgi?id=13079 http://bugzilla.kernel.org/show_bug.cgi?id=13079]</s><br />
<br />
==== Linux bridge посредством iproute2 (начиная с p9) ====<br />
Надо описать, пока только ссылка на дискуссию в момент перехода: https://lists.altlinux.org/pipermail/devel/2018-October/205769.html<br />
==== openvswitch ====<br />
Как настраивать openvswitch, описано [[Etcnet/openvswitch|тут]].<br />
<br />
<div id="vlan"></div><br />
<br />
=== Настройка VLAN ===<br />
<br />
Для настройки 802.1q VLAN (например, id 4094 на eth1) следует, создав каталог {{path|ifaces/eth1.4094}}, поместить в него файлы со следующим содержимым:<br />
<br />
* <tt>ipv4address</tt>:<br />
<pre>192.168.100.200/24</pre><br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=vlan<br />
HOST=eth1<br />
VID=4094<br />
BOOTPROTO=static</pre><br />
<br />
Содержимое переменных <tt>HOST</tt> и <tt>VID</tt> будет передано утилите <tt>vconfig</tt>; использование файла <tt>vlantab</tt> необязательно (и не рекомендуется по причине невозможности использовать ifup для отдельного интерфейса). Пример конфигурации можно найти в каталоге examples/VLAN-without-vlantab/ документации etcnet.<br />
<br />
Следует обратить внимание, что 4094 является верхней допустимой границей идентификатора валидного VLAN, а [http://www.candelatech.com/pipermail/vlan/2004-November/000128.html 4095 используется технически в процессе отбрасывания трафика по неверным VLAN]. (следует отметить, что это не ограничение Linux: [http://en.wikipedia.org/wiki/802.1Q в стандарте под VID отведено 12 бит])<br />
<br />
Обратите внимание, что '''ISC DHCP сервер на интерфейсе VLAN''', скорее всего, у вас не будет работать, пока вы не добавите опцию VLAN_REORDER_HDR=on в настройки vlan интерфейса. Эта опция переведёт vlan интерфейс в режим работы, в котором пакеты на интерфейсе не будут содержать тэгов vlan и их сможет получить dhcpd.<br />
<br />
<br />
'''Для настройки Q-in-Q интерфейса''', например, eth1.123.513 (дважды тегированный трафик: внешняя метка -- 123, внутренняя -- 513) следует файл <tt>options</tt> в каталоге {{path|ifaces/eth1.123.513}} заполнить следующим образом:<br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=vlan<br />
HOST=eth1.123 # "родительский" интерфейс; может называться иначе<br />
VID=513<br />
VLAN_REORDER_HDR=0<br />
BOOTPROTO=static</pre><br />
<br />
Родительский интерфейс должен быть сконфигурирован (можно с или без <tt>BOOTPROTO</tt>, с или без <tt>ipv4address</tt> и т.п.).<br />
<br />
Таким образом, можно каскадировать интерфейсы "как угодно глубоко" (Q-in-Q-in-Q-in-Q....). Необходимо только учитывать, что длина имени интерфейса ограничена (16-ю символами).<br />
<br />
<div id="bonding"></div><br />
<br />
=== Настройка bonding ===<br />
Bonding - объединение нескольких физических сетевых интерфейсов в один логический, для достижения отказоустойчивости, увеличения скорости и балансировки нагрузки. Возможны несколько режимов работы и много параметров для настроек, подробнее см. http://www.linuxfoundation.org/collaborate/workgroups/networking/bonding<br />
<br />
Для создания агрегированного bond-интерфейса средствами etcnet создаем, как обычно, директорию для интерфейса (например, <tt>bond0</tt>) с <tt>options</tt>, <tt>ipv4address</tt>, и прочими необходимыми файлами. В <tt>options</tt> указываем тип интерфейса <tt>bond</tt>, перечисляем в переменной <tt>HOST</tt> родительские интерфейсы, которые будут входить в наш агрегированный интерфейс, указываем в переменной <tt>BONDMODE</tt> режим (по умолчанию 0), и опции для модуля ядра <tt>bonding</tt> в <tt>BONDOPTIONS</tt>.<br><br />
Так, для создания LACP-агрегированного канала (802.3ad), у нас получится такой <tt>options</tt>:<br />
TYPE=bond<br />
ONBOOT=yes<br />
BOOTPROTO=static<br />
HOST="eth0 eth1"<br />
BONDMODE=4<br />
BONDOPTIONS="miimon=100 lacp_rate=1"<br />
Интерфейсы eth0 и eth1 должны тоже быть описаны в etcnet.<br />
<br />
Как правило, для создания агрегированного интерфейса требуется, чтобы входящие в него физические интерфейсы имели одинаковые характеристики - скорость, дуплекс, etc.<br />
<br />
Не стоит указывать режим в переменной <tt>BONDOPTIONS</tt>: попытки изменить какие-то режимоспецифичные параметры до установки правильного режима могут быть отвергнуты. Поэтому, первым делом нужно установить необходимый режим, указав его для этого в <tt>BONDMODE</tt>.<br />
<br />
Информацию о получившемся агрегированном интерфейсе можно посмотреть в {{path|/proc/net/bonding/bond0}}<br />
<br />
<div id="tun/tap"></div><br />
<br />
=== Настройка tun/tap интерфейса ===<br />
<br />
Etcnet поддерживает простое создание интерфейсов типа tun/tap. Это виртуальный тип интерфейсов для передачи пакетов между ядром и программами, который не передает данных через физические устройства.<br />
'''tun''' — это интерфейс типа point-to-point, работающий с кадрами IP.<br />
'''tap''' — интерфейс типа ethernet, работающий с кадрами ethernet.<br />
<br />
Потребуется использование утилиты tunctl, находящейся в одноименном пакете.<br />
Пусть требуется создать и настроить tun/tap интерфейс, например, с именем tap0. Для этого необходимо:<br />
* создать каталог интерфейса:<br />
<br />
/etc/net/ifaces/tap0<br />
<br />
* создать в каталоге интерфейса {{path|/etc/net/ifaces/tap0}} файл настройки <tt>options</tt> со следующим содержанием:<br />
<br />
TYPE=tuntap<br />
TUNTAP_USER=combr<br />
<br />
<br />
<tt>TUNTAP_USER</tt> — это аккаунт или цифровой id пользователя, которому будут даны права на использование интерфейса tap0 (устройство /dev/net/tun).<br />
Этот параметр будет передан утилите <tt>tunctl</tt> как аргумент опции <tt>-u</tt> (см. руководство на tunctl).<br />
С версии ядра 2.6.18 произошли изменения в управлении этим типом интерфейсов, потребовавшие<br />
обязательного применения <tt>tunctl</tt> для разрешения доступа обычных<br />
пользователей к tap-интерфейсам. В предыдущих версиях любой<br />
пользователь, имеющий доступ к <tt>/dev/net/tun</tt>, мог создать любое<br />
количество сетевых интерфейсов с произвольными именами. Начиная с<br />
2.6.18, для создания интерфейса через <tt>/dev/net/tun</tt> требуется<br />
<tt>CAP_NET_ADMIN</tt> (обычно эту привилегию имеет только root), а обычный<br />
пользователь, имеющий доступ к <tt>/dev/net/tun</tt>, может только использовать<br />
уже созданные интерфейсы, к которым разрешён доступ для его uid.<br />
<br />
=== Настройка интерфейса типа OpenVPN ===<br />
<br />
Настройка OpenVPN может быть произведена большим количеством способов и вариантов с разными целями, и достойна отдельной статьи. Здесь, для начала, будет описан вариант openvpn-сервера в режиме bridging.<br />
Для этого надо проделать подготовку:<br />
* создать ключи [http://openvpn.net/index.php/open-source/documentation/howto.html#pki англ. HOWTO]<br />
(до версии 2.3 утилиты easy-rsa шли в составе дистрибутива openvpn, потом отдельно).<br />
* настроить [http://www.altlinux.org/Etcnet#.D0.9D.D0.B0.D1.81.D1.82.D1.80.D0.BE.D0.B9.D0.BA.D0.B0_Ethernet-.D0.BC.D0.BE.D1.81.D1.82.D0.B0 мост] (между внутренним физическим интерфейсом и интерфейсом tap, который будет использовать openvpn) "средствами системы".<br />
<br />
Далее надо сделать так (скрипты etcnet по умолчанию ожидают это):<br />
* создать каталог интерфейса:<br />
<br />
/etc/net/ifaces/tap0<br />
<br />
* создать в каталоге интерфейса {{path|/etc/net/ifaces/tap0}} файл настройки <tt>options</tt> со следующим содержанием:<br />
<br />
TYPE=ovpn<br />
<br />
(необязательно, но желательно указать '''REQUIRES'''=''<имя ethernet-интерфейса>'', с которым будет связан туннель)<br />
<br />
* Конфигурационный файл для openvpn (из примера в пакете openvpn-docs - такой, как /usr/share/doc/openvpn-docs-2.2.2/sample-config-files/server.conf) надо переделать, удалив параметры, которые etcnet подставляет самостоятельно при запуске:<br />
<br />
dev<br />
ca<br />
cert<br />
key<br />
persist-key<br />
persist-tun<br />
<br />
И обязательно добавив параметры, которых по умолчанию в конфиге-примере нет:<br />
<br />
tls-server<br />
script-security 2<br />
<br />
Параметр script-security был введен начиная с версии 2.1_rc9. Поскольку etcnet запускает openvpn так, что в процессе тот запускает скрипт scripts/openvpn.action, который считается "пользовательским", то для этого значение должно быть 2.<br />
<br />
* скопировать в каталог интерфейса ключи и измененный конфиг-файл openvpn.<br />
Файлы надо переименовать (ключи - после easy-rsa) таким образом:<br />
{| align="center" border="1"<br />
|ключ easy-rsa<br />
|ключ etcnet-ovpn<br />
|-<br />
|ca.crt <br />
|ovpnca<br />
|-<br />
|server.crt<br />
|ovpncrt<br />
|-<br />
|server.key<br />
|ovpnkey<br />
|-<br />
|server.conf<br />
|ovpnoptions<br />
|}<br />
<br />
<br />
<br />
После всего этого можно попробовать запустить интерфейс: ifup tun0 (или весь мост, например ifup br0). Но если, например, openvpn считает ошибочной какую-либо опцию, то он молча выйдет с кодом выхода 1, и скрипт ifup ничего не напишет (в логе так же не будет попытки запуска openvpn). Потребуется отладка (например, можно запустить openvpn вручную без параметра --daemon и со всеми параметрами, которые подставил etcnet).<br />
<br />
<div id="wireguard"></div><br />
<br />
=== Настройка WireGuard VPN туннеля ===<br />
<br />
WireGuard используется для быстрого создания VPN туннелей, является более легким и безопасным чем OpenVPN. Для использования wireguard необходимо '''ядро std-def версии 3.10+''', установленный модуль ядра '''kernel-modules-wireguard-std-def''' и пакет '''wireguard-tools'''. Для настройки интерфейса необходимо:<br />
* создать каталог интерфейса {{path|/etc/net/ifaces/wg0}}<br />
* добавить файл с конфигурацией {{path|/etc/net/ifaces/wg0/options}}<br />
<source lang='ini'><br />
TYPE=wg<br />
LISTENPORT=51820<br />
</source><br />
* добавить файл с поддерживающимися wireguard опциями пиров {{path|/etc/net/ifaces/wg0/peers}} (одна строка - один пир)<br />
<source lang='bash'><br />
peer PUBLICPEERKEY allowed-ips IFACESSUBNET endpoint PUBLICIP:ALLOWPORT<br />
</source><br />
* добавить файл содержащий локальные и удаленные ip адреса {{path|/etc/net/ifaces/wg0/ipv4address}}<br />
первым делом указывается выделенная интерфейсу локальная подсеть, после чего указываются соответствия локального и удаленного ip адресов, каждое соответствие с новой строки<br />
<source lang='bash'><br />
10.1.0.0/16<br />
10.1.0.1 10.2.0.1<br />
</source><br />
* добавить файл содержащий приватный ключ {{path|/etc/net/ifaces/wg0/privatekey}}<br />
Ключи могут быть созданы стандартной утилитой wireguard:<br />
<source lang='bash'><br />
$ umask 077<br />
$ wg genkey > privatekey<br />
$ wg pubkey < privatekey > publickey<br />
</source><br />
<br />
<div id="iptun"></div><br />
<br />
=== Настройка и использование IP-туннелей ===<br />
<br />
IP-туннели — средство, позволяющее улучшить IP-сети. Поддерживаются IP-туннели трёх видов: <br />
* IPIP<br />
* GRE<br />
* SIT <br />
* VTI<br />
<br />
Прежде всего следует определить необходимый вид туннеля для решаемой задачи. <br />
<br />
* Туннели '''IPIP''' — самые простые.<br />
<br />
* Туннели '''GRE''' (general incapsulation) обычно используются в маршрутизаторах Cisco. По туннелям этого типа могут передаваться broadcast и multicast пакеты. Кроме того, эти туннели поддерживают контрольные суммы и контроль упорядоченности пакетов. Также GRE-туннели обладают опциональным атрибутом key в виде произвольного 4-байтового числа, который позволяет конфигурировать несколько GRE туннелей между одной парой IP-адресов несущей сети (в отличие от IPIP-туннелей, с которыми это невозможно).<br />
<br />
* Туннели '''SIT''' предназначены для транспортировки пакетов IPv6 через сети IPv4.<br />
<br />
* Туннели '''VTI''' используются для построения IPsec туннелей. Работают используя один из демонов, strongswan или libreswan.<br />
<br />
Тип туннеля определяется опцией <tt>TUNTYPE (ipip, gre, sit, vti)</tt>. По умолчанию <tt>TUNTYPE=ipip</tt>. Кроме типа туннеля для конфигурации всегда требуется адрес удалённого хоста и почти всегда — локальный адрес. Эти адреса определяются опциями <tt>TUNREMOTE</tt> и <tt>TUNLOCAL</tt> соответственно. В некоторых случаях локальный адрес можно не указывать. В этом случае опция <tt>TUNLOCAL</tt> всё равно обязательна, но принимает значение <tt>any</tt>. Не забудьте назначить туннельному интерфейсу адреса и маршруты в соответствующих файлах.<br />
<br />
Пример: Конфигурация GRE-туннеля между 10.0.1.2 и 10.0.2.3 с двумя ключами для исходящих и входящих пакетов, проверкой очерёдности пакетов, TTL 8 и вычислением контрольных сумм. Туннель должен использовать только интерфейс gw1. Пусть имя создаваемого туннеля будет <tt>mytunnel</tt>.<br />
<br />
Тогда необходимо сделать следующие операции:<br />
* Создать каталог туннеля: {{path|/etc/net/ifaces/mytunnel}}<br />
<br />
* Создать в каталоге туннеля файл настроек <tt>options</tt>: {{path|/etc/net/ifaces/mytunnel/options}}<br />
<br />
* Отредактировать файл настроек <tt>options</tt>: <br />
<br />
<source lang="ini"><br />
TYPE=iptun<br />
TUNTYPE=gre<br />
TUNLOCAL=10.0.1.2<br />
TUNREMOTE=10.0.2.3<br />
TUNTTL=8<br />
HOST=gw1<br />
TUNOPTIONS='ttl 64 seq ikey 2020 okey 2030 csum'<br />
</source><br />
<br />
<div id="vpn"></div><br />
<br />
Про <tt>ttl 64</tt>. Если параметр ttl не задан, значение берётся из инкапсулируемого пакета (это надо проверить). В некоторых случаях ttl может получиться слишком мал (например, Quagga формирует OSPF-пакеты с TTL 1).<br />
<br />
Стоит помнить, что имена <tt>tunl0, gre0 и sit0</tt> являются зарезервированными в iproute2 ("base devices") и имеют особое поведение: http://www.liveinternet.ru/users/stasikos/post71435454/<br />
<br />
Процедура создания vti интерфейса стандартна, однако, предварительно необходимо установить и настроить один из демонов (strongswan, libreswan), о том, как это сделать можно найти в соответствующей документации. После чего необходимо создать каталог интерфейса (к примеру он будет называться vti0) {{path|/etc/net/ifaces/vti0}}, и добавить в него файл настроек туннеля {{path|/etc/net/ifaces/vti0/options}}, куда нужно прописать необходимую конфигурацию:<br />
<source lang='ini'><br />
TYPE=iptun<br />
TUNTYPE=vti<br />
TUNLOCAL=119.81.184.173<br />
TUNREMOTE=119.81.177.236<br />
TUNOPTIONS='key 42'<br />
</source><br />
Параметр key должен соответствовать параметру mark, указанному при настройке strongswan/libreswan.<br />
<br />
=== Настройка IPv6 ===<br />
==== Отключение IPv6 ====<br />
<br />
* '''Вариант 1'''<br />
Чтобы отключить IPv6 на всех сетевых интерфейсах в работающей системе с загруженным модулем ipv6, нужно изменить значение параметра ядра net.ipv6.conf.all.disable_ipv6, где 'all' подразумевает все интерфейсы, а net.ipv6.conf.eth0.disable_ipv6 -- отключение протокола IPv6 только на интерфейсе eth0 и т.д.<br />
<pre><br />
sysctl net.ipv6.conf.all.disable_ipv6=1<br />
</pre><br />
Также можно добавить данную директиву в {{path|/etc/sysctl.conf}}:<br />
<source lang="bash"><br />
echo 'net.ipv6.conf.all.disable_ipv6 = 1' >> /etc/sysctl.conf<br />
sysctl -f<br />
</source><br />
<br />
* '''Вариант 2'''<br />
Добавить параметр в командную строку загрузки ядра. Для GRUB2 нужно изменить параметры загрузки ядра в файле {{path|/etc/sysconfig/grub2}}, изменив переменную GRUB_CMDLINE_LINUX_DEFAULT или GRUB_CMDLINE_LINUX<br />
<pre><br />
...<br />
GRUB_CMDLINE_LINUX='failsafe vga=normal ipv6.disable=1'<br />
...<br />
</pre><br />
и обновив конфигурационный файл grub<br />
<source lang="bash"><br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
</source><br />
<br />
* '''Вариант 3'''<br />
<source lang="bash"><br />
echo 'options ipv6 disable=1' >> /etc/modprobe.d/options-local.conf<br />
</source><br />
Вступит в силу только после перезагрузки.<br />
<br />
==== Включение IPv6 ====<br />
<br />
* Во-первых, следует убедиться, что не применяется какой-либо вариант совета из предыдущего пункта. <br />
* Во-вторых, следует проверить значение CONFIG_IPV6 в etcnet. Переменная может быть описана в /etc/net/options.d/*, /etc/net/ifaces/default/*, /etc/net/ifaces/*/options. Наибольший приоритет у описания в ifaces/*/options.<br />
<br />
'''Замечание:''' В etcnet-0.9.10-alt5, в /etc/net/ifaces/default/options содержится CONFIG_IPV6=no<br />
<br />
==== Туннели 6-to-4 ====<br />
<br />
Требуется:<br />
* ядро с поддержкой IPv6 (CONFIG_IPV6 в /boot/config-*; наличие модуля ipv6);<br />
* ядро с поддержкой tun (CONFIG_TUN в /boot/config-*; наличие модуля tun);<br />
* доступность узла 192.88.99.1 - через него маршрутизируется трафик в сети IPv6.<br />
<br />
Далее в {{path|/etc/net/ifaces}} создаётся каталог с названием, например,<br />
tun6to4. В нём создаются файлы:<br />
iplink : <pre><br />
mtu 1472 </pre><br />
<br />
ipv6address : <pre><br />
# first six octets: ipv6calc --ipv4_to_6to4addr $TUNLOCAL<br />
2002:c000:201::1/16 </pre><br />
<br />
ipv6route : <pre><br />
2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 </pre><br />
<br />
options : <pre><br />
TYPE=iptun<br />
TUNTYPE=sit<br />
TUNLOCAL=192.0.2.1<br />
TUNREMOTE=any<br />
TUNOPTIONS="ttl 64"<br />
DONT_FLUSH=yes<br />
CONFIG_IPV6=yes </pre><br />
<br />
Адрес TUNLOCAL в options - имеющийся внешний IPv4, в ipv6address<br />
адрес IPv6 выбирается исходя из него же.<br />
<br />
В настройках iptables должно быть разрешение на приём пакетов протокола<br />
ipv6 на внешний адрес IPv4.<br />
<br />
Далее поднимается интерфейс tun6to4, ну и проверяется доступность <br />
чего-либо в IPv6.<br />
<br />
Туннели 6to4 - это RFC 3964.<br />
Miredo - это реализация протокола Teredo, RFC 4380.<br />
6to4 требует наличия внешнего адреса IPv4.<br />
Teredo не требует наличия внешнего адреса, и может работать через NAT.<br />
Через Teredo не получится получить симметричное соединение, т.е. доступ<br />
в IPv6 будет односторонний, на компьютер в общем случае извне<br />
подключиться не получится.<br />
И Teredo позволяет получить только адрес /32, т.е. для подключения сетей<br />
он мало пригоден.<br />
<br />
этот раздел скопирован из письма рассылки community (c) Nikolay A. Fetisov 8 сентября 2011 12:03:30<br />
<br />
=== Замечания о настройке VPN-подключения и туннелей ===<br />
<br />
Часто при настройке VPN-подключения (под которыми здесь будут подразумеваться все туннельные подключения, то есть подключения поверх IP) не учитывают, что использование опции pppd '<tt>defaultroute</tt>' маршрут по-умолчанию после подключения будет изменен. При этом, если VPN-сервер находится в другой, отличной от клиента, сети, то после подключения (и изменения маршрута по-умолчанию) VPN-сервер становится недоступным, следовательно, недоступными становятся все внешние адреса, и подключение, как правило, прекращается по тайм-ауту.<br />
<br />
Решением, как обычно (и рекомендовано), служит указание ''отдельного'' маршрута на VPN-сервер (или его сеть). Для этого необходимо прописать (в примере - для маршрута через eth0) в {{path|/etc/net/ifaces/eth0/ipv4route}} строку вида:<br />
<br />
10.0.1.0/24 via 10.0.0.1<br />
<br />
В данном примере подразумевается, что VPN-сервер находится в сети 10.0.1.0/24 (например, имеет адрес 10.0.1.1), клиент — в сети 10.0.0.0/24 (и имеет адрес, например, 10.0.0.10), а маршрутизатор имеет адрес 10.0.0.1.<br />
<br />
Теперь, при использовании опции '<tt>defaulroute</tt>' для pppd (которая указывает, что необходимо изменить на вновь созданное подключение маршрут по-умолчанию), даже после замены маршрута по-умолчанию новым, сеть 10.0.1.0, в которой в нашем примере и находится VPN-сервер, останется доступной.<br />
<br />
Как более точечный вариант (применяется в alterator-net-pptp 0.5.x) можно использовать скрипты {{cmd|ifup-pre}} и {{cmd|ifdown-post}} в каталоге конфигурируемого PPP-интерфейса.<br />
<br />
Наример:<br />
<source lang="bash"><br />
#!/bin/sh<br />
# sample /etc/net/ifaces/ppp0/ifup-pre; replace variables yourself<br />
ip route add VPN_SERVER via DEF_GW<br />
</source><br />
<source lang="bash"><br />
#!/bin/sh<br />
# sample /etc/net/ifaces/ppp0/ifdown-post; replace variables yourself<br />
ip route del VPN_SERVER via DEF_GW<br />
</source><br />
<br />
Не забудьте подставить нужные IP-адреса вместо VPN_SERVER и DEF_GW (не сеть, где VPN-сервер, а ее /32 префикс CIDR) и выполнить команду: {{cmd|chmod +x ifup-pre ifdown-post}}<br />
<br />
<div id="iprule"></div><br />
<br />
=== Сложная маршрутизация (или несколько таблиц маршрутизации) ===<br />
<br />
Под «сложной маршрутизацией» подразумевается наличие нескольких таблиц маршрутизации. Для их использования необходимо сконфигурировать правила ядра. В правилах по умолчанию можно увидеть следующее:<br />
<br />
<pre># ip rule show<br />
0: from all lookup local <br />
32766: from all lookup main <br />
32767: from all lookup default</pre><br />
<br />
Для настройки «сложной маршрутизациии» необходимо выполнить следующие операции:<br />
<br />
Шаг 1 : Сами таблицы определены в файле {{path|/etc/iproute2/rt_tables}}. Для создания конфигурации «сложной маршрутизации» необходимо вначале «создать» нужные таблицы в этом файле (если вы хотите использовать имена таблиц, а не числа).<br />
<br />
Шаг 2 : Необходимо заполнить таблицы. В конфигурационном каталоге интерфейса в файле <tt>ipv4route</tt> необходимо добавить маршрутные записи, не забывая указать <tt>table XX</tt>. Важно учитывать, что если строка начинается с режима ip route (add, del, replace, append, change), то по умолчанию будет использован режим <tt>DEFAULT_IPV4ROUTE_CMD</tt> (<tt>append</tt>).<br />
<br />
Шаг 3 : Определить правила в файле <tt>ipv4rule</tt>. Здесь есть особенности, связанные автоматической заменой/добавлением параметров. Если строка не начинается с операции del или add, то нужный режим будет подставлен автоматически. Это подходит для тех случаев, когда вам при "поднятии" интерфейса необходимо добавить правила, а при "опускании" — удалить. Возможность указывать del или add реализована для обратных случаев: если при "поднятии" интерфейса вам необходимо удалить правила, а при "опускании" — добавить. В этом случае add и del будут в нужный момент автоматически заменены на del и add.<br />
<br />
Пример такой конфигурации входит в /etc/net 0.7.12: (каталог документации examples/routing-LARTC-1/)<br />
<br />
=== Простое переключение маршрутов ===<br />
<br />
Пусть имеется eth-интерфейс, который используется постоянно, и настроен маршрут по умолчанию.<br />
Часто бывает необходимость настроить второй маршрут по умолчанию через беспроводной интерфейс,<br />
но с меньшей метрикой, чем у проводного интерфейса.<br />
В этом случае при поднятии WI-FI маршрут по умолчанию «развернется» в нужную сторону.<br />
<br />
Например:<br />
<br />
Для eth-интерфейса файл настроек {{path|/etc/net/ifaces/eth0/ipv4route}} будет таким:<br />
<pre>default via 192.168.3.254 metric 10</pre><br />
а для WI-FI-интерфейса файл настроек {{path|/etc/net/ifaces/ath0/ipv4route}} таким:<br />
<pre>default via 192.168.123.1 metric 5</pre><br />
<br />
<div id="wireless"></div><br />
=== Беспроводный Ethernet (или настройка WI-FI) ===<br />
Большинство беспроводных интерфейсов сейчас представлено системе как интерфейсы Ethernet. Соответственно беспроводный интерфейс будет иметь <b>TYPE=eth</b> (<s>[https://bugzilla.altlinux.org/show_bug.cgi?id=6283 #6283]</s>). Чтобы интерфейс нормально функционировал, необходимо кроме загрузки модуля с параметрами, воспользоваться утилитами {{cmd|iwconfig}} из пакета wireless-tools или {{cmd|wpa_supplicant}} из такого же пакета. Вместо того, чтобы запускать их вручную, можно поместить в конфигурационный каталог интерфейса файл <tt>iwconfig</tt> с командами iwconfig или файл <tt>wpa_supplicant.conf</tt> с конфигурацией wpa_supplicant. Они будут использованы автоматически.<br />
<br />
Пример [http://hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wireless.html конфигурации] (совместно с <tt>[http://ndiswrapper.sourceforge.net/ ndiswrapper]</tt>):<br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/options}}<br />
<pre>TYPE=eth<br />
MODULE=ndiswrapper<br />
NEVER_RMMOD=yes<br />
BOOTPROTO=dhcp<br />
USE_HOTPLUG=no<br />
ONBOOT=no</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/iwconfig}}<br />
<pre>essid default<br />
#key bababababa</pre><br />
<br />
<br />
Еще один пример использования etcnet для настройки беспроводной сети:<br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/options}}<br />
<pre>TYPE=eth<br />
USE_HOTPLUG=NO<br />
BOOTPROTO=static<br />
module=ipw2200<br />
WPA_DRIVER=wext</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/iwconfig}}<br />
<pre>essid homenet<br />
mode 1<br />
ap 00:11:D8:22:AD:0D<br />
channel 3<br />
rate 11M</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}}<br />
<pre>ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=0<br />
eapol_version=1<br />
ap_scan=1<br />
fast_reauth=1<br />
<br />
network={<br />
ssid="homenet"<br />
scan_ssid=1<br />
key_mgmt=WPA-PSK<br />
psk="this is my mega secret password string to wpa supplicant"<br />
}</pre><br />
<br />
Если вы хотите воспользоваться WPS:<br />
# создайте {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}} следующего вида:<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
update_config=1<br />
</pre><br />
# поднимите беспроводной интерфейс (ifup wlan0)<br />
# запустите wpa_cli и дайте команды wps_pbc (после этого нужно соответственно нажать кнопку WPS на точке доступа и подождать окончания обмена данными) и save_config (для записи конфигурации в <tt>wpa_supplicant.conf</tt>). Или же можно воспользоваться утилитой wpa_gui, отображающей процесс более наглядно.<br />
<br />
Пример файла {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}} при подключении к сети, использующей протокол WPA2-PSK(AES)<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=0<br />
eapol_version=1<br />
ap_scan=1<br />
fast_reauth=1<br />
<br />
network={<br />
ssid="home-lg"<br />
bssid=00:1B:11:87:C7:EA<br />
proto=RSN<br />
key_mgmt=WPA-PSK<br />
pairwise=CCMP TKIP<br />
group=CCMP TKIP<br />
psk="this is my mega secret password string to wpa supplicant"<br />
priority=2<br />
}<br />
</pre><br />
<br />
<div id="infiniband"></div><br />
<br />
=== Настройка Infiniband ===<br />
На сейчас ничем не отличается от настройки Ethernet, специфическая поддержка отсутствует (и для [[Infiniband#IP_over_IB|IP-over-IB]] не требуется). Пример конфигурации для Mellanox:<br />
<br />
Файл: <tt>/etc/modules</tt><br />
<pre>mlx4_ib<br />
ib_umad<br />
ib_ipoib</pre><br />
<br />
Файл: <tt>/etc/net/ifaces/ib0/options</tt><br />
<pre>TYPE=eth<br />
BOOTPROTO=dhcp<br />
ONBOOT=yes</pre><br />
<br />
<div id="sysctl"></div><br />
<br />
=== Использование автодополнения в sysctl.conf ===<br />
<br />
В конфигурационном каталоге интерфейса может находиться файл <tt>sysctl.conf</tt>, в котором можно перечислить переменные <tt>sysctl(8)</tt>. Но переменные могут быть как общесистемными, так и относящимися к интерфейсу. Естественно, запись в sysctl.conf настроек вида <tt>net.ipv4.conf.eth0.log_martians = 1</tt> достаточно неудобна, а при переименовании интерфейса велик риск не отредактировать файл <tt>sysctl.conf</tt> соответствующим образом.<br />
<br />
Эта проблема решается следующим способом : производится запись в файл только имени переменной и значение, а система /etc/net сама найдет путь к этой переменной и вызовет <tt>sysctl</tt> с полным именем. <br />
<br />
Пример содержания файла <tt>sysctl.conf</tt>:<br />
<pre>log_martians=1<br />
rp_filter=1</pre><br />
<br />
<div id="profiles"></div><br />
<br />
=== Подключение к Wi-Fi с сертификатом на аппаратном токене ===<br />
Для беспроводного подключения в корпоративных сетях могут использоваться сертификаты, записанные на аппаратном токене, например, Aladdin eToken. Для настройки такого подключения необходимо использовать {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}}.<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=wheel<br />
#eapol_version=1<br />
#ap_scan=2<br />
#fast_reauth=1<br />
pkcs11_engine_path=/usr/lib/openssl/engines/engine_pkcs11.so<br />
pkcs11_module_path=/usr/lib/libeTPkcs11.so<br />
update_config=0<br />
<br />
network={<br />
ssid="test"<br />
key_mgmt=WPA-EAP<br />
pairwise=CCMP TKIP<br />
group=CCMP TKIP<br />
eap=TLS<br />
identity="email@address.ru"<br />
engine_id="pkcs11"<br />
key_id="xxxxxxxxx"<br />
cert_id="xxxxxxxxx"<br />
engine=1<br />
}<br />
</pre><br />
где key_id и cerd_id взяты из вывода команды<br />
<pre><br />
# pkcs11-tool --module /usr/lib/libeTPkcs11.so -O -l<br />
</pre><br />
<br />
Используются оригинальные ("родные") драйвера Aladdin - pkiclient-5.00.28-0, и пакет openssl-engine_pkcs11-0.1.5-alt1.<br />
<br />
=== Профили конфигурации ===<br />
<br />
==== Определение профилей ====<br />
Профиль — именованный вариант конфигурации, в той или иной степени изменяющий базовую конфигурацию системы. Профили могут быть применены, например, для конфигурации ноутбука в разных сетевых окружениях, или при подготовке новой или тестовой конфигурации с возможностью быстрого возврата к старой. Практически профили реализуются следующим образом: для какого-либо из файлов, составляющих общесистемную конфигурацию или конфигурацию интерфейса, создаётся альтернативный вариант, который отличается добавлением в конце названия файла знака # и имени профиля.<br />
<br />
Например, пусть единственное отличие между профилями заключается в том, какой модуль ядра будет загружен для интерфейса eth0. В этом случае файл {{path|/etc/net/ifaces/eth0/options}} необходимо скопировать в {{path|/etc/net/ifaces/eth0/options#profile1}} и изменить значение переменной <tt>MODULE</tt> в одном из них. Далее при использовании конфигурации по умолчанию будет использован файл <tt>options</tt>, а при использовании профиля profile1 — файл <tt>options#profile1</tt>. Если при этом для назначения интерфейсу имени используется файл {{path|/etc/net/iftab}}, то скорее всего необходимо будет создать соответствующий файл {{path|/etc/net/iftab#profile1}}, так как другой модуль ядра указывает на другой физический интерфейс и исходный файл <tt>iftab</tt> работать не будет.<br />
<br />
Профили могут использоваться также и для отключения каких-то параметров конфигурации. Например, если используется файл <tt>ipv4route</tt> для установки маршрутов для интерфейса, то можно создать файл нулевого размера <tt>ipv4route#profile2</tt>, чтобы при использовании профиля profile2 никаких маршрутов не конфигурировалось.<br />
<br />
==== Выбор профиля при загрузке ====<br />
Если при загрузке системы ядру был передан параметр netprofile, то его значение будет использовано как имя профиля по умолчанию. Это может быть использовано для создания собственных пунктов меню загрузчиков LILO и GRUB с заранее определённым профилем сетевой конфигурации. Заданный таким образом профиль может быть далее переопределён другими методами. Следует понимать разницу между различными конфигурациями и различными результатами применения одной конфигурации. Например, если в двух разных сетях используется DHCP, то смысла в разных профилях конфигурации нет.<br />
<br />
Для загрузчика LILO секции <tt>/etc/lilo.conf</tt> могут выглядеть следующим образом:<br />
<pre>image=/boot/vmlinuz-up<br />
label=linux-up home<br />
append=" netprofile=home"<br />
[...]<br />
image=/boot/vmlinuz-up<br />
label=linux-up office<br />
append=" netprofile=office"<br />
[...]</pre><br />
Для приведённого примера необходимо будет создать варианты для файлов, отличающихся в профилях home и office, и можно будет выбирать при загрузке, какой из профилей необходимо использовать. Использование этого метода удобно, если смена сетевого окружения происходит синхронно с загрузкой системы.<br />
<br />
==== Выбор профиля по умолчанию ====<br />
Если требуется, чтобы определенный профиль конфигурации использовался по умолчанию, то необходимо записать его название в файл <tt>/etc/net/profile</tt>. Этот метод имеет приоритет над параметром ядра netprofile. Использование такого способа выбора профиля целесообразно, когда переключение между конфигурациями происходит реже, чем перезагрузка системы.<br />
<br />
==== Смена профиля во время работы ====<br />
Если требуется переконфигурировать сеть без перезагрузки или редактирования файла {{path|/etc/net/profile}}, то следует использовать параметры сервиса network, описанные в разделе [[#restart, reload и другие команды|restart, reload и другие команды]]. Этот метод имеет приоритет над профилем по умолчанию и профилем, выбранным при загрузке. Целесообразно его использовать, если смена сетевого окружения происходит чаще, чем перезагрузка системы.<br />
<br />
==== Определение профиля во время конфигурации интерфейса ====<br />
Если в каталоге конфигурации интерфейса существует исполняемый файл ненулевого размера с именем <tt>selectprofile</tt>, то этот файл будет выполнен и первое слово первой строки его стандартного вывода использовано как имя профиля, которое должно быть использовано для конфигурации данного интерфейса. Этот метод имеет приоритет над всеми остальными методами. Исходной задачей, требующей такого решения, являлось конфигурирование беспроводного интерфейса в зависимости от доступных точек доступа.<br />
<br />
Следует учитывать, что число вызовов файла <tt>selectprofile</tt> может меняться в зависимости от контекста и время его выполнения может быть различным, поэтому при написании такого файла следует учитывать, что первым параметром будет являться имя текущего сценария. В настоящее время это могут быть ifup*, ifdown*, setup* и shutdown*. Для приведённого выше примера имеет смысл реагировать только на вызовы из ifup или ifup-common.<br />
<br />
== См. также ==<br />
* [[Ресолвер]]<br />
<br />
== Примечания ==<br />
<references/><br />
<br />
{{Category navigation|title=etcnet|category=etcnet|sortkey=*}}<br />
[[Категория:WiFi]]<br />
{{Category navigation|title=Wi-Fi|category=WiFi|sortkey={{SUBPAGENAME}}}}<br />
[[Категория:Admin]]<br />
{{Category navigation|title=Системному администратору|category=Admin|sortkey={{SUBPAGENAME}}}}<br />
[[en:etcnet]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=Team/Famous&diff=49551Team/Famous2020-09-16T12:20:45Z<p>AntonFarygin: /* Andrey Cherepanov */</p>
<hr />
<div>== Известные люди ALT Linux Team ==<br />
<br />
Список далеко не полон; сортировка аполитична. Если считаете, что кого-то забыли — допишите.<br />
<br />
=== Aleksey Novodvorsky ===<br />
[http://users.livejournal.com/aen_/profile Алексей Новодворский] — {{man|aen}}<br />
<br />
Сооснователь ООО «Альт Линукс», директор по развитию, некогда школьный учитель математики.<br />
<br />
Добр и чувствителен, порой до обидчивости. Человек большой души, но даже искреннюю критику в свой адрес (особенно в адрес сизифа) порой принимает с очень большим трудом. Впрочем, неискренней тоже хватает.<br />
<br />
В первые годы существования Sisyphus собственноручно поддерживал около трети пакетов в нём, помимо другой деятельности.<br />
<br />
=== Dmitry Levin ===<br />
Дмитрий Левин — {{man|ldv}}<br />
<br />
Генеральный архитектор Sisyphus, главный конструктор ООО «Альт Линукс», математик и вообще хороший человек (если не умудриться вывести из себя).<br />
<br />
Поддерживает базовую систему сизифа, отвечает за инфраструктуру. Замечен как в помощи по написанию [http://tinyurl.com/22fwog безопасного кода] и анализу/исправлению потенциально небезопасного (C, shell…), так и в [http://freeschool.altlinux.ru/wp-content/uploads/2009/01/ldv01.jpg собирании грибов] на LinuxFest :)<br />
<br />
=== Anton Farygin ===<br />
Антон Фарыгин — {{man|rider}}<br />
<br />
Глава обнинского офиса Базальт СПО, сильный технарь и человек. Один из организаторов lrn.ru и linuxfest.ru.<br />
<br />
Способен свернуть горы, при этом не стесняется посоветоваться с коллегами.<br />
<br />
=== Vitaly Lipatov ===<br />
Виталий Липатов — {{man|lav}}<br />
<br />
Генеральный директор [http://etersoft.ru/ ООО Этерсофт], собирает примерно [http://sisyphus.ru/packager/lav/srpms десятую часть] сизифа, для облегчения чего создал [[Etersoft-build-utils howto|etersoft-build-utils]].<br />
<br />
Перед участием в некоторых особо напряжённых темах в smoke-room@ порой помогает почитать его ответы в предыдущих витках.<br />
<br />
=== Sergey Vlasov ===<br />
Сергей Власов — {{man|vsu}}<br />
<br />
Легендарный муромский богатырь. Долгое время сопровождал ядра высочайшего качества в ALT, создал или неисправимо улучшил многие инфраструктурные инструменты.<br />
<br />
Поднимался вопрос об издании трёхтомника трудов — коммитов, changelog’ов и писем в рассылки.<br />
<br />
=== Sergey Turchin ===<br />
Сергей Турчин — {{man|zerg}}<br />
<br />
«Мистер KDE», каковое поддерживает практически в две руки. Если «из коробки» заработала 3D-акселерация на старенькой nvidia — вспоминать добрым словом его же.<br />
<br />
Вполне отзывчив, хотя иногда долго добирается ответить.<br />
<br />
=== Stanislav Ievlev ===<br />
Станислав Иевлев — {{man|inger}}<br />
<br />
Тихий, незаметный и неконфликтный человек, проделавший огромное количество работы по самым разным частям инфраструктуры и дистрибутивов, включая кластерный и RSBAC-дистрибутив, installer, alterator…<br />
<br />
Один из двух людей, наиболее основательно занимавшихся безопасностью пакетной базы и дистрибутивов ALT Linux от самого их начала.<br />
<br />
=== Alexey Gladkov ===<br />
Алексей Гладков — {{man|legion}}<br />
<br />
Участник проекта Mozilla, результаты деятельности которого порой доносит и до сизифа. Источник заметной части оригинальных наработок последних лет, включая [[libshell]], [[mkimage]] и [[make-initrd]]. Много сделал для [[alterator]] и инфраструктуры.<br />
<br />
Крайне тщателен и педантичен; его скрипты бывает полезно почитать для самообразования.<br />
<br />
=== Alexey Tourbin ===<br />
Алексей Турбин — {{man|at}}<br />
<br />
Правая рука ldv@ по работам над инфраструктурой. Поддерживает [[perl]] и толерантность в devel@, хотя на самом деле человек не только грамотный, но и интересный.<br />
<br />
Если исчезает — подождите.<br />
<br />
=== Damir Shayhutdinov ===<br />
[http://los-t.livejournal.com/profile Дамир Шайхутдинов] — {{man|damir}}<br />
<br />
Яркий представитель «новой волны» (после 2005): юморист и профессиональный разработчик на C/C++, который нередко помогал с пониманием и решением проблем как непосредственно с кодом, так и с его [[UpStream/AsNeeded|линковкой]] и упаковкой (особенно на x86_64).<br />
<br />
=== Andrey Rahmatullin ===<br />
[http://wrar.livejournal.com/profile Андрей Рахматуллин] — {{man|wrar}}<br />
<br />
Ещё один яркий представитель «новой волны», и тоже много кому помог с исправлением проблем в коде.<br />
<br />
Иногда его краткие ответы на точно процитированный вопрос напоминали советскую документацию — написана правда, но вот понять это получается только при понимании как всего вопроса, так и всего ответа.<br />
<br />
=== Valery Inozemtsev ===<br />
Валерий Иноземцев — {{man|shrek}}<br />
<br />
На удивление сообразно логину отличается в поведении на (электронной) публике и при личном общении: в переписке бывает невыносим, а вообще же он добрый и умеет улыбаться.<br />
<br />
Отличается быстрой реакцией на баги, нередко оказывающейся WONTFIX, но порой и FIXED нетривиальных проблем. Поддерживает угрожающе много пакетов в сизифе.<br />
<br />
=== Michael Shigorin ===<br />
[http://sdelanounas.ru/blog/shigorin Михаил Шигорин] — {{man|mike}}<br />
<br />
Традиционно больше говорит, чем делает. Пытается влезть в каждую дырку и особенно в каждый конфликт, чем нередко приводит к их раздуванию вместо искомого затухания. Знает лично добрых полкоманды, при необходимости подрабатывает телефонисткой.<br />
<br />
«Админ» с претензией на «манагера»; как разработчик довольно слаб. Порой *долго* отвечает.<br />
<br />
=== Motsyo Gennadi ===<br />
Моцьо Геннадий — {{man|drool}}<br />
<br />
Не соответствует своему логину. Знает много, даже то, о чем не догадывается. Всегда рад помочь, но и не забывает иногда послать в рассылку или на форум. Иногда раздувает много политической шумихи внутри community.<br />
<br />
=== Andrey Cherepanov ===<br />
[http://sibskull.livejournal.com/ Андрей Черепанов] — {{man|cas}}<br />
<br />
Также известен как Skull или Sibskull. Умудряется схватиться за всё и сделать достаточно многое (например, выпуски на [[Branches/p5|p5]]). Модератор [http://forum.altlinux.org/ forum.altlinux.org], был когда-то крайний по [[QA]].<br />
<br />
Терпит много незаслуженных тумаков за других.<br />
<br />
=== Denis Smirnov ===<br />
[http://mithraen.livejournal.com/ Денис Смирнов] — {{man|mithraen}}<br />
<br />
Бывший слакварист и фидошник, затем Mr. Asterisk сизифа. Порой жутко флеймил и даже бросался в крайности, потом хватался за напильник и искупал это.<br />
<br />
=== George Kouryachy ===<br />
[http://frbrgeorge.livejournal.com/ Георгий Курячий] — {{man|george}}<br />
<br />
Бывший BSD-шник, продолжает активно заниматься [http://uneex.ru/LecturesCMC/ образовательной деятельностью] (это [https://www.youtube.com/playlist?list=PL387B38E91536055B надо видеть], жестикуляция непередаваемая).<br />
<br />
Обычно вдруг появляется, вбухивает пачку пакетов в сизиф и ещё одну — писем в рассылки, убегает до следующего подходящего момента. Пакеты в основном образовательные, игрушечные или редкостные.<br />
<br />
=== Kirill Shutemov ===<br />
[http://www.facebook.com/people/Kirill-Shutemov/100000522921177 Кирилл Шутемов] — {{man|kas}}<br />
<br />
Больше делает, чем говорит. Начал с qemu; выручал ldv@ по части gcc и openssl; вместе с legion@ пилил [[make-initrd]]; занимался [[Ports/arm|ARM-портом]].<br />
<br />
На удивление неконфликтный и толковый специалист.<br />
<br />
=== Igor Vlasenko ===<br />
Игорь Власенко — {{man|viy}}<br />
<br />
Более всего известен как автор [[repocop]] и участник [[QA]] Team; также виновен в успешной попытке упаковки [[Java]]-стека в сизиф (путём создания механизма импорта jpackage.org).<br />
<br />
У многих вызывает сильные эмоции — или симпатию, или осуждение.<br />
<br />
=== Eugeny Rostovtsev ===<br />
<span style="border-style: solid; border-width: 1px;">Евгений Ростовцев</span> — {{man|real}}<br />
<br />
Тихо и незаметно тянул огромное количество пакетов в сизифе, существенно пополнив python-подсистему и упаковав немало [[Orphaned#REAL_aka_Eugeny_A._Rostovtsev|научного софта]] (кто с таким сталкивался, тот понимает, насколько это бывает сложно). Покинул нас [http://web.archive.org/web/20151002102035/http://cnit.kemsu.ru/articles/15 осенью 2015] года.<br />
<br />
=== Gleb Fotengauer-Malinovskiy ===<br />
Глеб Фотенгауэр-Малиновский — {{man|glebfm}}<br />
<br />
Начав в компании с тестировщика, стремительно вырос в одного из наиболее ценных специалистов в команде; по сути зам. ldv@ (а в [[Team/Join|принимающих]] так просто по факту). Пожалуй что рекордсмен по количеству [[ports|портов]] альта, к которым приложил руку.<br />
<br />
=== Ivan Melnikov ===<br />
Иван Мельников — {{man|iv}}<br />
<br />
Давний участник команды, порой выручающий по нетривиальным вопросам; забрал у Глеба [[ports/mipsel|mipsel]] и продолжил успешно развивать в качестве вторичной архитектуры.<br />
<br />
=== Yuri Sedunov ===<br />
Юрий Седунов — {{man|aris}}<br />
<br />
Ещё один давний участник, много лет единолично сопровождающий пакеты GNOME и сопредельные, помимо всего прочего. При ''вежливом'' обращении способен помочь в сложных моментах, а вот "эй, ты" склонен игнорировать.<br />
<br />
=== Aleksei Nikiforov ===<br />
Алексей Никифоров — {{man|darktemplar}}<br />
<br />
Яркий представитель молодого обнинского поколения, достаточно грамотный, чтобы умудриться ненароком сломать {{pkg|apt}} двумя выстрелами в собственную ногу из-за спины (виноват оказался апстрим, но всё равно впечатлило). Толковый, но при отсутствии внятного объяснения проблемы может отказываться её видеть; что, впрочем, шире известно как "bug# or didn't happen".<br />
<br />
{{Category navigation|title=Team|category=Team|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=Etcnet&diff=49497Etcnet2020-09-10T05:12:36Z<p>AntonFarygin: /* Cценарии конфигурации сети */</p>
<hr />
<div>{{DISPLAYTITLE:etcnet}}<br />
{{span|font-size: 180%|Подсказки пользователю /etc/net}}<br />
<br />
{|<br />
|-valign="top"<br />
|Дополнительные страницы:<br />
* [[etcnet/qos|настройка QoS]]<br />
* [[etcnet/firewall|настройка сетевого экрана (firewall)]]<br />
Совсем быстрая настройка «с нуля»:<br />
# сконфигурируйте интерфейсы вручную, как надо;<br />
# запустите {{cmd|/etc/net/scripts/contrib/initconf write}};<br />
# проверьте содержимое подкаталогов {{path|/etc/net/ifaces/}}.<br />
|<br />
{| style="border:1px solid #AAA; background:#F9F9F9; width:280px; margin: 0 0 1em 1em; padding:.2em; text-align:center;" class=noprint<br />
|-<br />
|[[Image:Information.svg|20x20px]]Начиная с [[Branches/p5|пятой ветки]],<br /> <div style="display: inline; color: red;">в ALT Linux может использоваться и<br />[[NetworkManager/feature|NetworkManager]]</div> (используйте <tt>NM_CONTROLLED=no</tt><br />в {{path|$iface/options}}, если хотите использовать etcnet).<br />
|}<br />
|<br />
{| style="border:1px solid #AAA; background:#F9F9F9; width:155px; margin: 0 0 1em 1em; padding:.2em; float: right;" class=noprint<br />
|-<br />
|[[Image:Information.svg|20x20px]] external links:<br />
* [http://packages.altlinux.org/ru/Sisyphus/srpms/etcnet package info]<br />
* [http://git.altlinux.org/people/sbolshakov/packages/?p=etcnet.git;a=summary source git repo]<br />
|}<br />
|}<br />
<br />
<!-- Не убирайте div-ы, на них есть внешние ссылки! --><br />
<div id="quickstart"></div><br />
<br />
== Быстрый старт ==<br />
<div id="docs"></div><br />
<br />
=== Источники информации по /etc/net ===<br />
Обратите внимание, что начиная с версии 0.8.0 документация по /etc/net была собрана из комментариев, расположенных во множестве файлов, в несколько страниц руководств (man). Список всех файлов документации пакета <tt>etcnet</tt> можно получить командой:<br />
<pre>$ rpmquery -d etcnet</pre><br />
<br />
<div id="onecard"></div><br />
<br />
=== Быстрая настройка сетевого интерфейса стандарта Ethernet ===<br />
Для настройки одного сетевого интерфейса следует выполнить следующие шаги:<br />
<br />
Шаг 1: Создать каталог {{path|/etc/net/ifaces/eth0}}. Это каталог конфигурации данного интерфейса (<tt>eth0</tt>), в котором будут храниться файлы с настройками.<br />
<br />
Шаг 2: Определить, какой модуль необходим для вашей сетевой карты. Для этого можно использовать команды: <tt>lspci, lspcidrake, pciscan</tt>.<br />
<br />
Шаг 3: В каталоге конфигурации сетевого интерфейса создать файл <tt>options</tt> и записать в этот файл строку:<br />
<pre>MODULE=<имя модуля></pre> <br />
На данном этапе работу с файлом <tt>options</tt> можно завершить.<br />
<div style='padding:6px;border:1px solid red;'>Шаг 3 имеет смысл только в случае, если модули сетевых карт не грузятся автоматически другими средствами, например посредством udev. Если модуль уже загружен, параметр MODULE бесполезен.</div><br />
<br />
Шаг 4: Выяснить, какой IP-адрес должен быть назначен вашему интерфейсу. Если ваш сетевой интерфейс конфигурируется по DHCP, то в файл {{path|/etc/net/ifaces/eth0/options}} следует записать строку:<br />
<pre>BOOTPROTO=dhcp</pre><br />
и перейти к шагу 7.<br />
<br />
'''Замечание:''' В ряде случаев в файле <tt>options</tt> может понадобиться запись:<br />
<pre>DHCP_HOSTNAME=<имя машины без домена></pre><br />
Эта опция описана в странице руководства <tt>etcnet-options(5)</tt>.<br />
<br />
'''Замечание:''' В конце файла <tt>options</tt> необходимо наличие пустой строки.<br />
<br />
У сетевого интерфейса существуют два взаимосвязанных атрибута: <br />
* IP-адрес;<br />
* сетевая маска (mask). <br />
Шаг 5: Текущие значение адреса можно просмотреть командой:<br />
{{cmd|# /sbin/ip address show}} <br />
Вероятнее всего вы увидите, что интерфейс-петля lo (loopback) уже сконфигурирован с адресом 127.0.0.1/8 (что эквивалентно IP-адресу 127.0.0.1 и маске подсети 255.0.0.0). <tt>/8</tt> означает длину префикса CIDR (Classless InterDomain Routing).<br />
Для задания IP-адреса и маски подсети интерфейса <tt>eth0</tt> необходимо создать файл {{path|/etc/net/ifaces/eth0/ipv4address}}, в который следует записать IP-адрес с длиной маски, например:<br />
<pre>10.0.0.20/24</pre> <br />
<br />
Наиболее популярны маски /24 (т.е. длина префикса CIDR равная 24 эквивалентна маске сети 255.255.255.0 - это одна сеть класса C на 254 хоста) и /30. Для справки приводится таблица соответствия сетевых масок в различных нотациях.<br />
<ref><br />
{|<br />
|<br />
{| class="standard"<br />
|-<br />
!маска<br />в битах!!маска<br />точечно-<br />десятичная<br />
|-<br />
|/32||255.255.255.255<br />
|-<br />
|/31||255.255.255.254<br />
|-<br />
|/30||255.255.255.252<br />
|-<br />
|/29||255.255.255.248<br />
|-<br />
|/28||255.255.255.240<br />
|-<br />
|/27||255.255.255.224<br />
|-<br />
|/26||255.255.255.192<br />
|-<br />
|/25||255.255.255.128<br />
|-<br />
|/24||255.255.255.0<br />
|-<br />
|/23||255.255.254.0<br />
|-<br />
|/22||255.255.252.0<br />
|-<br />
|/21||255.255.248.0<br />
|-<br />
|/20||255.255.240.0<br />
|-<br />
|/19||255.255.224.0<br />
|-<br />
|/18||255.255.192.0<br />
|-<br />
|/17||255.255.128.0<br />
|}<br />
|<br />
| ||<br />
{| class="standard"<br />
|-<br />
!маска<br />в битах!!маска<br />точечно-<br />десятичная<br />
|-<br />
|/16||255.255.0.0<br />
|-<br />
|/15||255.254.0.0<br />
|-<br />
|/14||255.252.0.0<br />
|-<br />
|/13||255.248.0.0<br />
|-<br />
|/12||255.240.0.0<br />
|-<br />
|/11||255.224.0.0<br />
|-<br />
|/10||255.192.0.0<br />
|-<br />
|/9||255.128.0.0<br />
|-<br />
|/8||255.0.0.0<br />
|-<br />
|/7||254.0.0.0<br />
|-<br />
|/6||252.0.0.0<br />
|-<br />
|/5||248.0.0.0<br />
|-<br />
|/4||240.0.0.0<br />
|-<br />
|/3||224.0.0.0<br />
|-<br />
|/2||192.0.0.0<br />
|-<br />
|/1||128.0.0.0<br />
|}<br />
|}<br />
</ref><br />
<br />
Шаг 6: Выяснить адрес вашего шлюза (маршрут по умолчанию). Например, IP-адрес вашего шлюза — <tt>10.0.0.254</tt>. Тогда необходимо создать файл {{path|/etc/net/ifaces/eth0/ipv4route}}, в который записать строку:<br />
<pre>default via 10.0.0.254</pre><br />
Шаг 7: Убедиться, что всё выполнено правильно, выполнив команду:<br />
{{cmd|# service network restart}}<br />
Ваш интерфейс <tt>eth0</tt> должен быть успешно сконфигурирован. Если вы конфигурировали <tt>eth0</tt>, используя DHCP-сервер, но адрес интерфейсу не был назначен, то следует искать сообщение от DHCP-сервера в файле {{path|/var/log/messages}}.<br />
<br />
<div id="ifplugd"></div><br />
<br />
=== Настройка ifplugd ===<br />
Начиная с версии 0.7.10, /etc/net управляет ifplugd самостоятельно. Это было сделано для лучшей интеграции пакетов и для возможности следить за несколькими сетевыми интерфейсами одновременно. Для корректного использования ifplugd необходимо выполнить команду:<br />
# chkconfig ifplugd off<br />
<br />
и назначить переменную <tt>USE_IFPLUGD</tt> (USE_IFPLUGD=yes или USE_IFPLUGD=auto) в файлах <tt>options</tt> соответствующих интерфейсов (<tt>/etc/net/ifaces/<имя интерфейса>/options</tt>). Комментарий по данной переменной дан в странице руководства <tt>etcnet-options(5)</tt>.<br />
<br />
<div id="ppp"></div><br />
<br />
=== Настройка PPP-интерфейса ===<br />
Для настройки обычного модемного PPP-соединения необходимо:<br />
# Создать каталог конфигурации PPP-интерфейса, например, {{path|/etc/net/ifaces/ppp5}}. Вы можете задавать имена PPP-интерфейса вида pppN, pppNN, pppNNN и т. п., где N - любая цифра от 0 до 9;<br />
# Прочитать файл: {{path|/etc/net/ifaces/default/options-ppp}};<br />
# Создать файлы конфигурации. Вероятнее всего вам понадобятся <tt>pppconnect</tt> и <tt>pppdisconnect</tt>, чтобы <tt>pppd</tt> "знал", как дозваниваться и соединяться. Это скрипты для программы <tt>chat(8)</tt>. Кроме этого в файле <tt>pppoptions</tt> можно (часто нужно) перечислить опции <tt>pppd(8)</tt>, определяющие способ авторизации, скорость и название порта и т. п.;<br />
# Заполнить {{path|/etc/ppp/chap-secrets}} или {{path|/etc/ppp/pap-secrets}}.<br />
<br />
{{Attention|Использование опций "persist" и "maxfail 0", которые требуются pppd для непрерывных попыток восстановить интерфейс в случае проблем, может привести к невозможности загрузки системы в случае проблем с соединением. Вариант решения есть в {{altbug|23556#c1}} }}<br />
<br />
==== Настройка USB 3G-модема ====<br />
{{main|Установка и настройка 3G USB модема Huawei E1550}}<br />
<br />
<div id="ppp-pptp-pppoe"></div><br />
<br />
==== Настройка PPTP-интерфейса и PPPoE-интерфейса ====<br />
{{main|VPN (PPTP PPPoE)}}<br />
<br />
Хотя PPtP-соединения могут быть настроены и как обычные PPP-соединения, в /etc/net версии 0.7.10 для удобства пользователей была введена опция <tt>PPPTYPE</tt>. Она может принимать следующие значения:<br />
* <tt>dialup</tt> - обычный PPP-интерфейс.<br />
* <tt>pppoe</tt> - интерфейс PPPoE. Для такого интерфейса необходимо в опции <tt>HOST</tt> указывать имя Ethernet-интерфейса, через который будет производиться работа PPPoE. Побочным положительным эффектом будет то, что этот интерфейс будет при необходимости автоматически подниматься (т.е настраиваться) (см. [[#Зависимости между интерфейсами|Зависимости между интерфейсами]]).<br />
* <tt>pptp</tt> - интерфейс PPTP. Для такого интерфейса необходимо в опции <tt>PPTP_SERVER</tt> указывать имя хоста или IP-адрес PPtP-сервера, к которому будет производиться подключение. Обратите внимание, что хотя такие интерфейсы не имеют опции <tt>HOST</tt>, в большинстве случаев есть необходимость указать в опции <tt>REQUIRES</tt> интерфейс, через который будет достижим хост, указанный в <tt>PPTP_SERVER</tt>.<br />
<br />
См. также [[#Замечания о настройке VPN-подключения и туннелей|Замечания о настройке VPN-подключения и туннелей]].<br />
<br />
<div id="DNSandPPP"></div><br />
<br />
==== DNS и PPP-соединения ====<br />
<div style="display: inline; color: red;">Внимание: здесь описывается проблема, которая на самом деле была создана, а не решена — т.е. ради специфики [https://bugzilla.altlinux.org/show_bug.cgi?id=13789 kppp] была создана чётная ошибка в [https://bugzilla.altlinux.org/show_bug.cgi?id=13773 ppp-common]; последняя уже исправлена.</div><br />
<br />
Довольно долгое время существовала проблема неправильной модификации {{path|/etc/resolv.conf}} при установке PPP-соединений: [https://bugzilla.altlinux.org/show_bug.cgi?id=4249 #4249]. Сейчас она решена, но необходимо дать пояснения. Прежде всего убедитесь, что в файле {{path|/etc/resolv.conf}} есть строка:<br />
<pre># ppp temp entry</pre><br />
Если этой строки нет, то в файле не будут модифицироваться строки nameserver, если только какая-нибудь программа типа kppp это не сделает специально. Если такая строка есть, то {{path|/etc/resolv.conf}} будет модифицироваться в зависимости от значения булевой (логической) переменной RESOLV_MODS, которую необходимо задать в файле {{path|/etc/sysconfig/network}}.<br />
<br />
<div style="display: inline; color: red;">Внимание</div>: при ppp-common >= 0.4-alt1 строки <tt># ppp temp entry</tt> в файле {{path|/etc/resolv.conf}} при отсутствии PPP-соединения, поднятого какой-либо программой-«звонилкой», запущенной от администратора системы (пользователь root) — быть '''не должно'''! Если это есть, следует убрать, чтобы {{cmd|/etc/ppp/ip-up}} занимался обновлением записей про DNS в этом файле.<br />
<br />
<div id="restartreload"></div><br />
<br />
=== restart, reload и другие команды ===<br />
У сервиса <tt>network</tt> имеется ряд команд:<br />
* <tt>start</tt> - запустить все стационарные интерфейсы. hotplug-интерфейсы будут сконфигурированы при поступлении соответствующего вызова от hotplug.<br />
* <tt>startwith <имя профиля> </tt> - старт с указанным именем профиля, а не определённым автоматически.<br />
* <tt>stop</tt> - остановить все стационарные интерфейсы. hotplug-интерфейсы будут расконфигурированы при поступлении соответствующего вызова от hotplug.<br />
* <tt>stopwith <имя профиля> </tt> - стоп с указанным именем профиля, а не определённым автоматически.<br />
* <tt>restart</tt> - эквивалентно <tt>stop</tt> с последующим <tt>start</tt>, как и в большинстве других сервисов.<br />
* <tt>restartwith <имя профиля> </tt> - рестарт в контексте указанного профиля, эквивалентно <tt>stopwith <имя профиля> и startwith <имя профиля></tt>.<br />
* <tt>switchto <имя профиля> </tt> - переключение в указанный профиль, эквивалентно <tt>stop</tt> и <tt>startwith <имя профиля></tt>.<br />
* <tt>reload</tt> - семантически обозначает «актуализировать текущую конфигурацию». Для всех сконфигурированных в настоящий момент интерфейсов будет выполнена реконфигурация при наличии конфигурации.<br />
* <tt>check</tt> - автоматическая проверка конфигурационной базы.<br />
<br />
<div id="bootproto"></div><br />
<br />
=== Протоколы конфигурации адресов ===<br />
С помощью опции <tt>BOOTPROTO</tt> вы можете управлять тем, как у интерфейса будут появляться адреса и маршруты (это относится только к протоколу IPv4, так как протоколы IPv6 и IPX получают адреса только статически).<br />
* <tt>static</tt> — адреса и маршруты будут взяты из <tt>ipv4address</tt> и <tt>ipv4route</tt>.<br />
* <tt>dhcp</tt> — интерфейс будет сконфигурирован по DHCP.<br />
* <tt>ipv4ll</tt> — интерфейс будет сконфигурирован с помощью IPv4LL (link-local), ранее известному как ZCIP (zeroconf IP). Это значит, что из сети 169.254.0.0/16 будет подобран ещё не использованный адрес и назначен на интерфейс.<br />
Существует несколько комбинированных способов:<br />
* <tt>dhcp-static</tt> — если конфигурация по DHCP не удалась, конфигурировать методом static.<br />
* <tt>dhcp-ipv4ll</tt> — если конфигурация по DHCP не удалась, конфигурировать методом ipv4ll.<br />
* <tt>dhcp-ipv4ll-static</tt> — если конфигурация по DHCP не удалась, конфигурировать методом ipv4ll. Если и это не удалось, конфигурировать методом static.<br />
<br />
<div id="internals"></div><br />
<br />
=== Интеграция с systemd ===<br />
Начиная с версии 0.9.12 в etcnet добавлен Unit для включения интерфейсов по мере их появления в системе. Это позволяет избежать "гонок", когда сетевая подсистема поднимается раньше, чем ОС загружает драйвера для сетевых устройств.<br />
Для этого нужно выставить <tt>ONBOOT=no</tt> в файле options интерфейса и включить его подъём через systemd при загрузке: <tt>systemctl enable network@<имя интерфейса></tt>.<br />
<br />
== Устройство /etc/net ==<br />
<div id="generalinfo"></div><br />
<br />
=== Общие сведения ===<br />
/etc/net — это система конфигурации сети в Linux, т.е. эта система позволяет администратору Linux достаточно просто произвести настройки сети. Если же вы читаете эту страницу, то, вероятно, у вас возникли трудности с её использованием. Для решения возможных проблем полезно знать:<br />
<br />
<!--# [http://etcnet.org/ http://etcnet.org/] - сайт проекта, на котором можно найти примеры конфигурации и статьи по настройке системы. ?Рекурсия? --><br />
# /etc/net интегрирован в ALT Linux Sisyphus в виде пакетов:<br />
#* {{pkg|etcnet}} - базовые сценарии;<br />
#* {{pkg|etcnet-full}} - виртуальный пакет с зависимостями на все пакеты, которые могут использоваться сценариями /etc/net, с указанием их точных версий;<br />
#* {{pkg|etcnetconf}} - '''прототип''' конфигуратора;<br />
#* {{pkg|etcnet-defaults-desktop}} - умолчания для рабочей станции;<br />
#* {{pkg|etcnet-defaults-server}} - умолчания для сервера; <br />
# Пакеты {{pkg|etcnet}} и {{pkg|net-scripts}} — две конфликтующие реализации «подсистемы конфигурации сети» (network-config-subsystem).<br />
# При установке etcnet вместо net-scripts (или наоборот) сервис <tt>network</tt> оказывается выключенным. Это означает, что при загрузке системы сеть не будет сконфигурирована, что можно проверить командой {{cmd|chkconfig --list network}}. Для быстрого исправления проблемы можно дать команду {{cmd|chkconfig network reset}}.<br />
# etcnet '''НЕ''' импортирует автоматически настройки net-scripts. Если вы только что установили etcnet, и ваши сетевые интерфейсы всё ещё остаются сконфигурированными (несмотря на уже отсутствующий пакет net-scripts), то вы можете запустить сценарий {{cmd|/etc/net/scripts/initconf}}. Он попытается проанализировать текущее состояние интерфейсов и выведет вам результат. Никаких файлов при этом записано не будет. Если вам подходит вывод initconf, то запустите его с параметром write и он проделает то же самое, но уже с сохранением конфигурации.<br />
# Для корректной работы системы в целом необходимо, чтобы содержимое файла {{path|/etc/sysconfig/network}} было корректным.<br />
# Переменные <tt>sysctl</tt> в ОС ALT Linux конфигурируются в следующих местах<ref>{{altbug|26498}}</ref>:<br />
#* {{path|/etc/sysctl.conf}} (глобальные системные);<br />
#* {{path|/etc/sysconfig/network-scripts/sysctl.conf}} (общие сетевые в net-scripts, исходно файл не существует);<br />
#* {{path|/etc/net/sysctl.conf}} (общие сетевые в /etc/net);<br />
#* <tt>/etc/net/ifaces/*/sysctl.conf*</tt> (частные для конкретных интерфейсов или их типов в /etc/net, создаются вручную при необходимости).<br />
Скрипты etcnet используют эти файлы в указанном порядке.<br />
<br />
<div id="options.d"></div><br />
<br />
=== Организация опций /etc/net по умолчанию ===<br />
Методология /etc/net предусматривает несколько шагов наследования опций, первый из которых — загрузка опций по умолчанию. В ранних версиях это происходило из одного файла <tt>/etc/net/options</tt>, сейчас же в вашем распоряжении есть каталог {{path|/etc/net/options.d}}, из которого будут последовательно прочитаны все файлы.<br />
<br />
Иными словами, оригинальный архив etcnet содержит только файл {{path|/etc/net/options.d/00-default}}. Упаковщик etcnet, вместо того, чтобы добавить патч в какой-либо дистрибутив, просто добавляет файл с бОльшим номером, который переопределяет нужные опции.<br />
<br />
Ввиду решения различных задач, администратору системы может не подойти содержание дистрибутивного набора. В этом случае администратор может создать файл с ещё более высоким номером и определить настройки умолчания для своей системы. В результате такого подхода:<br />
# Уменьшается количество патчей (хотя их свойство "отваливаться" от пакета при его упаковке бывает полезным).<br />
# Не изменяются файлы с опциями, принадлежащие пакету. Это делает обновление пакета намного более корректным.<br />
# Можно легко увидеть, какие опции переопределяются на каждом этапе.<br />
<br />
<div id="iftab"></div><br />
<br />
=== Назначение iftab ===<br />
<br />
Начиная с дистрибутивов, основанных на ветках p5 и 5.1, переименование интерфейсов возложено на udev; см. тж. [http://lists.altlinux.org/pipermail/sisyphus/2009-June/340033.html это письмо] и <s>[https://bugzilla.altlinux.org/show_bug.cgi?id=19313 #19313]</s> и [http://packages.altlinux.org/ru/Sisyphus/srpms/wireless-tools/changelog %changelog ifrename]. В дистрибутивах на базе p8 и новее может быть полезным пакет udev-rule-generator-net, который заполняет /etc/udev/rules.d/70-persistent-net.rules. Возможно, следует отказаться от имён интерфейсов вида ethN и использовать, например, etherN ввиду того, что в новом systemd/udev официально сломан механизм переименования. Данное нововведение в ALT пока отменено; см. тж. [https://bugzilla.altlinux.org/32167 #32167].<br />
<br />
Имена сетевых интерфейсов по умолчанию, как правило, содержат их тип (eth, ppp, wifi, ipsec) и индекс: 0 - для первого созданного интерфейса, 1 - для второго и т. д. При этом соответствие автоматически назначенных имён физическим устройствам может не сохраняться.<br />
<br />
Эта особенность неудобна, когда машина с Linux имеет более одного интерфейса каждого типа. Типичными примерами являются маршрутизаторы и ноутбуки. В маршрутизаторах, как правило, используются однотипные сетевые карты и при их замене или изменении порядка на PCI-шине соответствие оказывается нарушенным. В ноутбуках используются ethernet и wifi-устройства с горячим подключением, при этом слотов и карт может быть более чем 1. В этом случае пользователь/администратор скорее всего пожелает закрепить за каждой сменной картой её конфигурацию.<br />
<br />
/etc/net при конфигурации интерфейса использует то имя, под которым он сконфигурирован, а именно имя каталога, в котором хранятся файлы конфигурации интерфейса.<br />
<br />
Для привязки сетевой карты к имени интерфейса в простых случаях можно воспользоваться файлом {{path|/etc/iftab}}, man-страница по формату которого входит в пакет <tt>ifrename</tt> (<tt>iftab(5)</tt>).<br />
<br />
Использование {{path|/etc/iftab}} удобно, поскольку позволяет сохранять традиционные имена интерфейсов (например, eth0), но этот механизм не поддерживает расширенную функциональность /etc/net (в частности, ''профили'' /etc/net).<br />
<br />
Средством, позволяющим использовать все возможности <tt>etcnet</tt>, является файл {{path|/etc/net/iftab}}, обрабатываемый не утилитой <tt>ifrename</tt>, а непосредственно <tt>etcnet</tt>. Синтаксис этого файла совпадает с синтаксисом {{path|/etc/iftab}}. Ограничением же является невозможность использовать стандартные имена интерфейсом (<tt>ethX</tt>, <tt>pppX</tt>), так как переименование интерфейсов происходит уже после конфигурации интерфейса ядром. В случае, если вам необходим {{path|/etc/net/iftab}}, имеет смысл переименовать интерфейсы, давая им либо двухзначные номера (<tt>eth00</tt>, <tt>eth01</tt>...), либо осмысленные названия (<tt>isplink</tt>, <tt>lan</tt>...)<br />
<br />
См. письмо про [http://lists.altlinux.org/pipermail/sisyphus/2009-March/337924.html важность /etc/iftab]<br />
и тж. это письмо про [http://lists.altlinux.org/pipermail/devel/2007-October/065097.html отличия etcnet и сервиса ifrename]:<br />
{{начало цитаты}} Комментарии к письмам этого треда (с некоторыми пояснениями):<br />
<br />
1. «etcnet уже научился менять местами eth0 и eth1?»<br />
<br />
Освоение этого приема обладает сомнительной пользой. Рекомендуется <br />
рассматривать eth0 как временное имя с малым сроком жизни,<br />
а для повышения комфорта пользователей Ethernet-интерфейсы предлагается<br />
называть eth00, eth01, eth02 etc.<br />
<br />
2. «Существование (номинальное) net-scripts вынуждает поддерживать<br />
ряд сервисов, которые иначе могли бы быть упразднены»<br />
<br />
Эти сервисы можно "обезвредить" (отключить) контролем CONFMETHOD<br />
из /etc/sysconfig/network. При этом зависимости на пакет etcnet<br />
не возникнет, только на network-config-subsystem. Примеры таких<br />
пакетов должны быть в Sisyphus.<br />
<br />
3. «после приведения в порядок /etc/udev/rules.d/19-udev-ifrename.rules<br />
нужности в /etc/net/iftab я не заметил»<br />
<br />
Важнейшее принципиальное отличие /etc/net/iftab от /etc/iftab —<br />
нахождение /etc/net/iftab в специальном пространстве имён. Для него<br />
действуют механизмы определения профиля и хоста конфигурации. Это,<br />
например, позволит, при необходимости, составить конфигурацию так, что срочный<br />
ремонт маршрутизатора сведётся к переносу диска (или массива)<br />
из сгоревшего шасси в запасное. Возможны и другие примеры, которые<br />
станут невозможными при помещении iftab в /etc и его прямой<br />
интерпретации.<br />
<br />
Конечно, пользователю единственного ноутбука с одним-двумя сетевыми<br />
интерфейсами такая практика — полный overkill (т.е. такая практика ему не нужна), но его никто и не<br />
заставляет видеть всю подводную часть (т.е. все тонкости работы и настройки). В этом и гибкость.{{конец цитаты}}<br />
<br />
<div id="specifaces"></div><br />
<br />
=== Интерфейсы lo, default и unknown ===<br />
Сразу после установки пакета <tt>etcnet</tt> в каталоге {{path|/etc/net/ifaces}} (в котором хранятся конфигурации интерфейсов) находятся три каталога: <br />
* lo<br />
* default<br />
* unknown<br />
<br />
Интерфейс '''lo''' — стандартная "петля" (loopback), которая должна быть во всякой Linux-системе, поэтому конфигурация для него включена по умолчанию. В остальном он ничем не отличается от любого другого интерфейса и конфигурируется точно так же файлами <tt>options</tt> и <tt>ipv4address</tt>.<br />
<br />
Интерфейс '''default''' — это не интерфейс, а специальный каталог, файлы в котором обрабатываются следующим образом:<br />
* <tt>resolv.conf</tt> — если присутствует, то копируется в {{path|/etc/resolv.conf}}.<br />
* <tt>options</tt> — файл опций, читается после опций по умолчанию.<br />
* <tt>options-<вид интерфейса></tt> — этот файл содержит опции, специфичные для данного вида интерфейсов. Некоторые из них не обязательны и позволяют использовать особенности данного вида интерфейсов, например, <tt>LINKDETECT</tt> в <tt>options-eth</tt>; другие обязательны, например, <tt>HOST</tt> в <tt>options-bri</tt>. Обратите внимание, что эти файлы не рекомендуется редактировать. Если вам нужно задать опцию для интерфейса, то, как правило, это можно сделать в файле <tt>options</tt> в конфигурационном каталоге данного интерфейса. Это облегчит процесс обновления пакета etcnet.<br />
* <tt>sysctl.conf-<вид интерфейса></tt> — файл с переменными sysctl, которые необходимо изменить. Сейчас единственный такой файл — <tt>sysctl.conf-dvb</tt>, который отключает <tt>return path filter</tt>, что всегда нужно в случае асимметричной маршрутизации.<br />
* <tt>iplink-<вид интерфейса></tt> — файл с командами iplink, специфичными для данного вида.<br />
* <tt>selectprofile</tt> — если этот файл исполняемый, то он будет вызван из сценариев <tt>ifup/ifdown</tt>, <tt>setup/shutdown</tt> для того, чтобы вернуть на стандартном выводе имя профиля, которое необходимо использовать. Это позволяет автоматически переключать профили в зависимости от каких-либо условий. В поставку включен пример сценария: {{path|/etc/net/scripts/contrib/selectprofile}}.<br />
* <tt>fw</tt> — каталог с настройками сетевого экрана по умолчанию.<br />
<br />
Интерфейс '''unknown''' — специальная конфигурация, которая будет использована в том случае, когда /etc/net просят сконфигурировать hotplug-интерфейс, для которого не существует каталога конфигурации. Это будет работать только в том случае, если включена опция <tt>ALLOW_UNKNOWN</tt>.<br />
<br />
<div id="broadcast"></div><br />
<br />
=== broadcast address===<br />
<br />
Периодически возникает вопрос: почему после старта /etc/net при запуске <tt>ifconfig</tt> можно видеть <tt>Bcast:0.0.0.0</tt>, хотя при использовании net-scripts это поле было правильным? <br />
<br />
Ответ: net-scripts оперируют адресом, маской, адресом сети и широковещательным адресом, пытаясь определить неизвестные компоненты из известных, а <tt>config-ipv4</tt> просто передаёт утилите <tt>ip</tt> содержимое файла <tt>ipv4address</tt>, не проверяя его содержание.<br />
Важно заметить, что:<br />
* Если <tt>iproute2</tt> изменит свой синтаксис, то с очень вероятно, что администратору будет необходимо редактировать только конфигурационные файлы.<br />
* Не было найдено проблем с «отсутствующим» broadcast address. Он есть в таблице маршрутизации <tt>local</tt>. <br />
* Администратор всегда может назначить адрес broadcast в файле <tt>ipv4address</tt>. Это можно сделать с помощью выражения <tt>broadcast +</tt><ref><br />
Выдержка из файла ip-cref.ps, который входит в документацию пакета iproute2:<br />
<br />
<pre><br />
* broadcast ADDRESS<br />
<br />
the broadcast address on the interface.<br />
It is possible to use the special symbols '+' and '-' instead of the broadcast address. In this case, <br />
the broadcast address is derived by setting/resetting the host bits of the interface prefix.<br />
NB. Unlike ifconfig, the ip utility does not set any broadcast address unless explicitly requested.<br />
</pre><br />
</ref>.<br />
'''Замечание:''' В версии 0.8.0 появилась опция <tt>AUTO_BROADCAST</tt> для автоматического дополнения каждой строки <tt>ipv4address</tt>.<br />
<br />
<div id="never_rmmod"></div><br />
<br />
=== Ядро 2.6 и "пропадающие" интерфейсы ===<br />
Иногда возможна ситуация: Если два интерфейса используют один и тот же модуль ядра, и у них определена опция <tt>MODULE</tt> (то есть скрипты /etc/net сами загружают и выгружают модули), то при опускании (отключении) одного интерфейса пропадает и второй интерфейс. <br />
<br />
Такая ситуация почти наверняка возникает при использовании ядра 2.6, особенностью которого являются значения счётчика ссылок (третий столбец вывода {{cmd|lsmod}}). Когда счетчик оказывается равен нулю (довольно часто), скрипты могут попытаться выгрузить модуль интерфейса, для которого запущен ifdown. И такая выгрузка происходит, несмотря на то, что другой интерфейс, использующий этот же модуль, находится в состоянии UP (т.е. он активен).<br />
<br />
Чтобы заблокировать выгрузку модулей, можно использовать булеву переменную <tt>NEVER_RMMOD</tt>. Возможно, позже это будет происходить автоматически для ядер следующих версий.<br />
<br />
<div id="removables"></div><br />
<br />
=== Cценарии конфигурации сети и hotplug-интерфейсы ===<br />
<br />
==== Cценарии конфигурации сети ====<br />
Существует несколько сценариев конфигурации сети.<br />
<br />
* Первый и самый простой — выполнение {{cmd|service network start}} при старте системы или вручную. При этом требуется только сформировать погруппные (потиповые) списки интерфейсов, подлежащих обработке, и последовательно выполнить требуемые действия. Модули ядра при этом загружаются сценариями /etc/net, при этом имена модулей берутся из опции <tt>MODULE</tt> (в этой опции можно в кавычках перечислить несколько имён и они будут последовательно загружены). Этот метод часто используется на практике и лучше всего подходит для маршрутизаторов. Преимущество метода в том, что вся необходимая информация сконцентрирована в одном месте — каталоге {{path|/etc/net}}. Если опция <tt>MODULE</tt> не определена, то будет предпринята попытка загрузки по имени интерфейса, подразумевая, что файл {{path|/etc/modules.conf}} правильно заполнен.<br />
<br />
* Второй сценарий — реакция на событие <tt>ifplugd</tt>. В предыдущих версиях существовала сложность, так как требовалась синхронная настройка сервиса <tt>ifplugd</tt>. Сейчас логика работы определена, что выражено в том, что /etc/net взяла управление <tt>ifplugd</tt> на себя. В части загрузки модуля этот сценарий не отличается от первого.<br />
<br />
* Третий сценарий — реакция на появление или исчезновение сменного устройства. Для обработки таких событий предназначены сценарии <tt>/etc/net/scripts/{ifup,ifdown}-removable</tt>, которые вызываются из сценариев пакетов hotplug и pcmcia-cs. Сложность заключается в том, что для сменных PCMCIA-карт вызовы могут дублироваться: для одного и того же события первый раз ifup-removable будет вызван из hotplug, второй — из pcmcia-cs. Кроме того, hotplug также реагирует на загрузку модулей ядра для обычных карт PCI и, более того, включает сценарии, которые пытаются загружать модули самостоятельно. В этом контексте /etc/net получает слишком много вызовов от hotplug и по умолчанию их игнорирует (<tt>USE_HOTPLUG=no</tt>).<br />
<br />
* Четвёртый сценарий - реакция на появление сетевого интерфейса через systemd. Такое событие обрабатывается через сервис network@.service, которому в качестве аргумента, следующего за @ нужно передать имя интерфейса. Например - systemctl enable network@eth0. В этом случае интерфейс будет подниматься после его появления в системе, что полезно в некоторых случаях, когда система загружается быстрее появления интерфейсов и на момент запуска сервиса network сетевых интерфейсов в системе ещё нет.<br />
<br />
==== hotplug-интерфейсы ====<br />
Рассмотрим использование hotplug-интерфейсов. <br />
<br />
Пусть администратору необходимо настроить действительно сменную карту. После заполнения {{path|/etc/iftab}} или {{path|/etc/net/iftab}} в файле <tt>options</tt> необходимо будет задать <tt>USE_HOTPLUG=yes</tt>. После этого при получении события от hotplug /etc/net будет работать в том контексте, что модуль в загрузке и выгрузке не нуждается. <br />
<br />
Важно заметить, что '''такой интерфейс будет пропущен при обычном старте сети''', т.к. если он сменный, то единственный достоверный способ узнать, что он присутствует — получить вызов от hotplug. Из факта выполнения {{cmd|service network start}} совсем не следует, что какой-то один или несколько из сконфигурированных hotplug-интерфейсов сейчас в наличии и требуют конфигурации. Если вы хотите вручную расконфигурировать hotplug-интерфейс до его извлечения, используйте команду {{cmd|ifdown}}. Для повторной конфигурации вставьте его ещё раз.<br />
<br />
Также существует опция <tt>USE_PCMCIA</tt>. Если события для вашей карты генерирует pcmcia-cs, то вам нужно её включить. Если события генерируются только hotplug, то используйте опцию <tt>USE_HOTPLUG</tt>.<br />
<br />
<div id="eth0"></div><br />
<br />
=== Проблема стандартных имен интерфейсов (eth0 и др.)===<br />
<br />
При использовании файла {{path|/etc/net/iftab}}, то есть в случае применения сложных конфигураций, возникает следующая проблема:<br />
* При загрузке модулей имена интерфейсов принимают вид eth0, eth1, eth2… Какие именно — в общем случае контролировать нельзя.<br />
* Имя eth0 обладает наибольшей вероятностью оказаться занятым.<br />
* ifrename не может переименовать интерфейс, если целевое имя уже занято (udev использует <tt>ifrename -t</tt>, но это не работает после начальной загрузки, см. руководство к ifrename).<br />
<br />
С учётом вышеизложенного, если {{path|/etc/net/iftab}} содержит тот же набор имён интерфейсов, что уже имеется после загрузки модулей (то есть <tt>eth0</tt>/<tt>eth1</tt> и другие «стандартные» названия), то единственный случай, когда etcnet сможет без ошибок обработать такой файл — изначальное соответствие, не требующее переименования.<br />
<br />
Таким образом, при использовании {{path|/etc/net/iftab}} имеет смысл давать интерфейсам названия, отличные по виду от тех, что назначает ядро. В простых случаях лучше использовать {{path|/etc/udev/rules.d/70-persistent-net.rules}} ({{path|/etc/iftab}} до бранчей p5/5.1).<br />
<br />
<div id="advanced"></div><br />
<br />
== Расширенные возможности ==<br />
<div id="multipleIPs"></div><br />
<br />
=== Несколько IP-адресов или маршрутов на одном интерфейсе ===<br />
<br />
Вы можете помещать произвольное количество IP-адресов в файл <tt>ipv4address</tt> по одному адресу на каждой строке. То же самое относится к статическим маршрутам и файлу <tt>ipv4route</tt>.<br />
<br />
Обратите внимание, что /etc/net не анализирует содержимое этих файлов, а формирует на основе каждой строки командную строку для утилиты {{cmd|ip}}. Это означает, что вы можете помещать в этих файлах произвольные поддерживаемые {{cmd|ip}} опции и они будут обработаны. Например, в файле <tt>ipv4route</tt> можно поместить строку:<br />
<pre>10.0.1.0/24 via 10.0.0.253 metric 50 weight 5 table 100</pre><br />
<br />
<div id="requires"></div><br />
<br />
=== Зависимости между интерфейсами ===<br />
У интерфейсов:<br />
* vlan<br />
* bond <br />
* bri <br />
* teql <br />
входящих в группу зависимых физических, должна быть определена опция <tt>HOST</tt> со списком интерфейсов, необходимых для инициализации текущего интерфейса. Если хост-интерфейс не сконфигурирован при поднятии зависимого интерфейса, то это будет исправлено.<br />
<br />
Кроме обязательной для определённых интерфейсов опции <tt>HOST</tt>, может быть задана и необязательная для всех остальных интерфейсов опция <tt>REQUIRES</tt>. Интерфейсы, перечисленные в этой опции, будут считаться зависимостями текущего интерфейса. Например, по умолчанию попытка сконфигурировать интерфейс А, который зависит от Б и В, приведёт сначала к конфигурации Б и В. Аналогично, при расконфигурации Б или В сначала будет расконфигурирован А.<br />
<br />
Зависимость одного интерфейса от другого не всегда формальна. Например, в сценарии <tt>ifup-pre</tt> одного интерфейса может использоваться команда, которая потребует разрешения DNS-имени, которое может быть разрешено только с помощью <tt>resolv.conf</tt>, инсталлируемого другим интерфейсом. Или это может быть PPPoE/PPtP-интерфейс, требующий Ethernet-интерфейс для работы.<br />
<br />
Для того, чтобы избежать неожиданных сбоев в таких случаях, правильно задавайте опцию <tt>REQUIRES</tt>.<br />
<br />
<div id="postpre"></div><br />
<br />
=== Пользовательские сценарии post и pre ===<br />
Существует возможность поместить в каталог конфигурации интерфейса файлы, которые будут выполнены в определённые моменты. Для этого они должны быть исполняемыми и называться следующим образом:<br />
* <tt>ifup-pre</tt> — для выполнения перед конфигурированием интерфейса.<br />
* <tt>ifup-post</tt> — для выполнения после конфигурирования интерфейса. Например, можно запустить почтовую систему.<br />
* <tt>ifdown-pre</tt> — для выполнения перед расконфигурированием интерфейса. Например, можно остановить почтовую систему.<br />
* <tt>ifdown-post</tt> — для выполнения после расконфигурирования интерфейса.<br />
<br />
Также в версии до 0.8.0 возможно использовать следующие сценарии (они должны быть исполняемыми):<br />
* <tt>/etc/net/scripts/ifup-pre-local</tt><br />
* <tt>/etc/net/scripts/ifup-post-local</tt><br />
* <tt>/etc/net/scripts/ifdown-pre-local</tt><br />
* <tt>/etc/net/scripts/ifdown-post-local</tt><br />
<br />
Они будут вызваны для каждого интерфейса. Начиная с версии 0.8.0 эти сценарии называются так:<br />
* <tt>/etc/net/ifup-pre</tt><br />
* <tt>/etc/net/ifup-post</tt><br />
* <tt>/etc/net/ifdown-pre</tt><br />
* <tt>/etc/net/ifdown-post</tt><br />
Семантика сохранена.<br />
<br />
<div id="iplink"></div><br />
<br />
=== Управление канальными параметрами интерфейсов ===<br />
<br />
Если поместить в конфигурационный каталог интерфейса файл <tt>iplink</tt>, в котором в каждой строке будут записаны команды режима link утилиты {{cmd|ip}}, то они будут выполнены при конфигурации интерфейса. <br />
<br />
Например, если необходимо, чтобы интерфейс net1 имел MAC-адрес aa:bb:cc:dd:ee:ff и MTU 200 байт, то в файл {{path|/etc/net/ifaces/net1/iplink}} нужно поместить следующее:<br />
<pre>address aa:bb:cc:dd:ee:ff<br />
mtu 200</pre><br />
<br />
Обратите внимание, что в этом случае в {{path|/etc/net/iftab}} вам необходимо будет использовать селектор <tt>businfo</tt> или <tt>driver</tt> вместо <tt>mac</tt>.<br />
<br />
<div id="ethtool"></div><br />
<br />
=== Управление физическими параметрами интерфейсов ===<br />
Если поместить в конфигурационный каталог интерфейса файл <tt>ethtool</tt>, в котором будет строка с параметрами программы ethtool, то она будет выполнена при конфигурации интерфейса. <br />
<br />
Например, если есть необходимость, чтобы интерфейс net1 имел скорость 10Мбит/с и авто-согласование скорости было отключено, то в файл {{path|/etc/net/ifaces/net1/ethtool}} нужно поместить следующую строку:<br />
<br />
<pre>speed 10 autoneg off</pre><br />
<br />
<div id="bridge"></div><br />
<br />
=== Настройка Ethernet-моста ===<br />
<br />
Для настройки Ethernet-моста (далее — моста) есть 3 пути: <br />
# Linux bridge посредством bridge-utils<br />
# Linux bridge посредством iproute2<br />
# Openvswitch<br />
<br />
Linux bridge наиболее простая реализация. Если вам не нужно все, что умеет [http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=README;hb=HEAD openvswitch] , то можно использовать Linux bridge.<br />
<br />
==== Linux bridge посредством bridge-utils (до p8 включительно) ====<br />
Перед настройкой Ethernet-моста (далее — моста) с помощью etcnet сначала необходимо убедиться, что установлен пакет bridge-utils. Etcnet использует утилиту brctl для настройки моста, и, если утилита не установлена, то при перезапуске системы сеть станет недоступна. Если интерфейсы, входящие в состав моста, являются единственными физически подключенными и настройка моста происходит с удаленного узла через эти интерфейсы, то требуется соблюдать осторожность, т.к. эти интерфейсы перестанут быть доступны. В случае ошибки в конфигурации потребуется физический доступ к серверу. Для страховки, перед перезапуском сервиса network можно открыть ещё одну консоль и запустить там, например, команду: {{cmd|sleep 500 && reboot}}.<br />
<br />
Также имейте ввиду, что если вы подключаетесь по ssh к серверу через bridge-интерфейс (по его ip-адресу), то по умолчанию при опускании любого интерфейса-члена моста Etcnet так же опустит и сам мост (и ваше подключение пропадет). Чтобы избежать этого, установите в файле {{path|options}} того интерфейса, который нужно опускать, переменную <tt>IFDOWN_CHILDREN=no</tt>. Но учтите, что и включаться в бридж при старте тогда этот интерфейс по умолчанию не будет. <br />
<br />
Предположим, требуется настроить Ethernet-мост, пусть он будет называться <tt>br0</tt>. <br />
Тогда для его настройки необходимо завести каталог {{path|/etc/net/ifaces/br0}} и создать там файлы со следующими данными:<br />
<br />
* <tt>brctl</tt><br />
<br />
<pre> stp AUTO on </pre><br />
<br />
* <tt>ipv4address</tt>:<br />
<pre> 192.168.100.200/24 </pre><br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=bri<br />
HOST='eth0 tap0'<br />
BOOTPROTO=static </pre><br />
<br />
Содержимое файла <tt>brctl</tt> передаётся утилите brctl. <tt>AUTO</tt> означает, что скрипт {{cmd|setup-bri}} самостоятельно определит имя bridge-интерфейса (см. файл {{path|/usr/share/doc/etcnet-*/README.bridge}}). Если же в вашей сети этот мост один и рассылать пакеты протокола STP не нужно, тогда файл brctl с указанной опцией не нужен. По умолчанию [http://xgu.ru/wiki/man:brctl#Spanning_Tree_Protocol_.28.D0.9F.D1.80.D0.BE.D1.82.D0.BE.D0.BA.D0.BE.D0.BB_.D0.BE.D1.81.D1.82.D0.BE.D0.B2.D0.BD.D0.BE.D0.B3.D0.BE_.D0.B4.D0.B5.D1.80.D0.B5.D0.B2.D0.B0.29 STP выключен].<br />
<br />
IP-адрес для интерфейса, как обычно, будет взят из <tt>ipv4address</tt>.<br />
<br />
В опции <tt>HOST</tt> файла <tt>options</tt> нужно указать те интерфейсы, которые будут входить в мост. Если в него будут входить интерфейсы, которые до этого имели IP-адрес (например, eth0), то этот адрес должен быть удалён (например, можно закомментировать содержимое файла {{path|ifaces/eth0/ipv4address}}).<br />
<br />
При старте сети сначала поднимаются интерфейсы, входящие в мост, затем сам мост (автоматически). Для назначения адреса мосту можно также использовать DHCP (<tt>BOOTPROTO=dhcp</tt>). Но при этом важно обратить внимание на параметр <tt>forwarding delay</tt> (man brctl / setfd), так как интерфейс, подключенный к мосту, не сразу входит в режим передачи пакетов, и это может вызвать dhcp таймаут. Версии etcnet в дистрибутивах ALT Linux Server 4 и Desktop 4.1 (0.9.7-alt0.M40/M41) имеют эту недоработку, которая исправлена только в версии 0.9.9-alt1. <br />
Документацию по настройке моста с вопросами и ответами (перевод) можно найти на http://xgu.ru/wiki/Linux_Bridge, а его оригинал доступен на http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge.<br />
<br />
Внимание: инструкция на xgu.ru чуть устарела. Команда<br />
<pre>$ brctl setfd br0 0</pre><br />
не выключает задержку, а лишь приводит к величине задержки по умолчанию (15 или даже 30 секунд). Можно попробовать задать задержку в 1сек для уменьшения времени инициализации сети.<br />
<br />
С пакетом etcnet поставляются примеры конфигурации. Один из них показывает, как из двух ethernet-интерфейсов port0 и port1 можно собрать мост bridge (каталог документации examples/Ethernet-bridge-GRE/).<br />
<br />
Безотносительно к etcnet, следует иметь ввиду проблему, связанную с NAT: <s>[http://bugzilla.kernel.org/show_bug.cgi?id=13079 http://bugzilla.kernel.org/show_bug.cgi?id=13079]</s><br />
<br />
==== Linux bridge посредством iproute2 (начиная с p9) ====<br />
Надо описать, пока только ссылка на дискуссию в момент перехода: https://lists.altlinux.org/pipermail/devel/2018-October/205769.html<br />
==== openvswitch ====<br />
Как настраивать openvswitch, описано [[Etcnet/openvswitch|тут]].<br />
<br />
<div id="vlan"></div><br />
<br />
=== Настройка VLAN ===<br />
<br />
Для настройки 802.1q VLAN (например, id 4094 на eth1) следует, создав каталог {{path|ifaces/eth1.4094}}, поместить в него файлы со следующим содержимым:<br />
<br />
* <tt>ipv4address</tt>:<br />
<pre>192.168.100.200/24</pre><br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=vlan<br />
HOST=eth1<br />
VID=4094<br />
BOOTPROTO=static</pre><br />
<br />
Содержимое переменных <tt>HOST</tt> и <tt>VID</tt> будет передано утилите <tt>vconfig</tt>; использование файла <tt>vlantab</tt> необязательно (и не рекомендуется по причине невозможности использовать ifup для отдельного интерфейса). Пример конфигурации можно найти в каталоге examples/VLAN-without-vlantab/ документации etcnet.<br />
<br />
Следует обратить внимание, что 4094 является верхней допустимой границей идентификатора валидного VLAN, а [http://www.candelatech.com/pipermail/vlan/2004-November/000128.html 4095 используется технически в процессе отбрасывания трафика по неверным VLAN]. (следует отметить, что это не ограничение Linux: [http://en.wikipedia.org/wiki/802.1Q в стандарте под VID отведено 12 бит])<br />
<br />
Обратите внимание, что '''ISC DHCP сервер на интерфейсе VLAN''', скорее всего, у вас не будет работать, пока вы не добавите опцию VLAN_REORDER_HDR=on в настройки vlan интерфейса. Эта опция переведёт vlan интерфейс в режим работы, в котором пакеты на интерфейсе не будут содержать тэгов vlan и их сможет получить dhcpd.<br />
<br />
<br />
'''Для настройки Q-in-Q интерфейса''', например, eth1.123.513 (дважды тегированный трафик: внешняя метка -- 123, внутренняя -- 513) следует файл <tt>options</tt> в каталоге {{path|ifaces/eth1.123.513}} заполнить следующим образом:<br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=vlan<br />
HOST=eth1.123 # "родительский" интерфейс; может называться иначе<br />
VID=513<br />
VLAN_REORDER_HDR=0<br />
BOOTPROTO=static</pre><br />
<br />
Родительский интерфейс должен быть сконфигурирован (можно с или без <tt>BOOTPROTO</tt>, с или без <tt>ipv4address</tt> и т.п.).<br />
<br />
Таким образом, можно каскадировать интерфейсы "как угодно глубоко" (Q-in-Q-in-Q-in-Q....). Необходимо только учитывать, что длина имени интерфейса ограничена (16-ю символами).<br />
<br />
<div id="bonding"></div><br />
<br />
=== Настройка bonding ===<br />
Bonding - объединение нескольких физических сетевых интерфейсов в один логический, для достижения отказоустойчивости, увеличения скорости и балансировки нагрузки. Возможны несколько режимов работы и много параметров для настроек, подробнее см. http://www.linuxfoundation.org/collaborate/workgroups/networking/bonding<br />
<br />
Для создания агрегированного bond-интерфейса средствами etcnet создаем, как обычно, директорию для интерфейса (например, <tt>bond0</tt>) с <tt>options</tt>, <tt>ipv4address</tt>, и прочими необходимыми файлами. В <tt>options</tt> указываем тип интерфейса <tt>bond</tt>, перечисляем в переменной <tt>HOST</tt> родительские интерфейсы, которые будут входить в наш агрегированный интерфейс, указываем в переменной <tt>BONDMODE</tt> режим (по умолчанию 0), и опции для модуля ядра <tt>bonding</tt> в <tt>BONDOPTIONS</tt>.<br><br />
Так, для создания LACP-агрегированного канала (802.3ad), у нас получится такой <tt>options</tt>:<br />
TYPE=bond<br />
ONBOOT=yes<br />
BOOTPROTO=static<br />
HOST="eth0 eth1"<br />
BONDMODE=4<br />
BONDOPTIONS="miimon=100 lacp_rate=1"<br />
Интерфейсы eth0 и eth1 должны тоже быть описаны в etcnet.<br />
<br />
Как правило, для создания агрегированного интерфейса требуется, чтобы входящие в него физические интерфейсы имели одинаковые характеристики - скорость, дуплекс, etc.<br />
<br />
Не стоит указывать режим в переменной <tt>BONDOPTIONS</tt>: попытки изменить какие-то режимоспецифичные параметры до установки правильного режима могут быть отвергнуты. Поэтому, первым делом нужно установить необходимый режим, указав его для этого в <tt>BONDMODE</tt>.<br />
<br />
Информацию о получившемся агрегированном интерфейсе можно посмотреть в {{path|/proc/net/bonding/bond0}}<br />
<br />
<div id="tun/tap"></div><br />
<br />
=== Настройка tun/tap интерфейса ===<br />
<br />
Etcnet поддерживает простое создание интерфейсов типа tun/tap. Это виртуальный тип интерфейсов для передачи пакетов между ядром и программами, который не передает данных через физические устройства.<br />
'''tun''' — это интерфейс типа point-to-point, работающий с кадрами IP.<br />
'''tap''' — интерфейс типа ethernet, работающий с кадрами ethernet.<br />
<br />
Потребуется использование утилиты tunctl, находящейся в одноименном пакете.<br />
Пусть требуется создать и настроить tun/tap интерфейс, например, с именем tap0. Для этого необходимо:<br />
* создать каталог интерфейса:<br />
<br />
/etc/net/ifaces/tap0<br />
<br />
* создать в каталоге интерфейса {{path|/etc/net/ifaces/tap0}} файл настройки <tt>options</tt> со следующим содержанием:<br />
<br />
TYPE=tuntap<br />
TUNTAP_USER=combr<br />
<br />
<br />
<tt>TUNTAP_USER</tt> — это аккаунт или цифровой id пользователя, которому будут даны права на использование интерфейса tap0 (устройство /dev/net/tun).<br />
Этот параметр будет передан утилите <tt>tunctl</tt> как аргумент опции <tt>-u</tt> (см. руководство на tunctl).<br />
С версии ядра 2.6.18 произошли изменения в управлении этим типом интерфейсов, потребовавшие<br />
обязательного применения <tt>tunctl</tt> для разрешения доступа обычных<br />
пользователей к tap-интерфейсам. В предыдущих версиях любой<br />
пользователь, имеющий доступ к <tt>/dev/net/tun</tt>, мог создать любое<br />
количество сетевых интерфейсов с произвольными именами. Начиная с<br />
2.6.18, для создания интерфейса через <tt>/dev/net/tun</tt> требуется<br />
<tt>CAP_NET_ADMIN</tt> (обычно эту привилегию имеет только root), а обычный<br />
пользователь, имеющий доступ к <tt>/dev/net/tun</tt>, может только использовать<br />
уже созданные интерфейсы, к которым разрешён доступ для его uid.<br />
<br />
=== Настройка интерфейса типа OpenVPN ===<br />
<br />
Настройка OpenVPN может быть произведена большим количеством способов и вариантов с разными целями, и достойна отдельной статьи. Здесь, для начала, будет описан вариант openvpn-сервера в режиме bridging.<br />
Для этого надо проделать подготовку:<br />
* создать ключи [http://openvpn.net/index.php/open-source/documentation/howto.html#pki англ. HOWTO]<br />
(до версии 2.3 утилиты easy-rsa шли в составе дистрибутива openvpn, потом отдельно).<br />
* настроить [http://www.altlinux.org/Etcnet#.D0.9D.D0.B0.D1.81.D1.82.D1.80.D0.BE.D0.B9.D0.BA.D0.B0_Ethernet-.D0.BC.D0.BE.D1.81.D1.82.D0.B0 мост] (между внутренним физическим интерфейсом и интерфейсом tap, который будет использовать openvpn) "средствами системы".<br />
<br />
Далее надо сделать так (скрипты etcnet по умолчанию ожидают это):<br />
* создать каталог интерфейса:<br />
<br />
/etc/net/ifaces/tap0<br />
<br />
* создать в каталоге интерфейса {{path|/etc/net/ifaces/tap0}} файл настройки <tt>options</tt> со следующим содержанием:<br />
<br />
TYPE=ovpn<br />
<br />
(необязательно, но желательно указать '''REQUIRES'''=''<имя ethernet-интерфейса>'', с которым будет связан туннель)<br />
<br />
* Конфигурационный файл для openvpn (из примера в пакете openvpn-docs - такой, как /usr/share/doc/openvpn-docs-2.2.2/sample-config-files/server.conf) надо переделать, удалив параметры, которые etcnet подставляет самостоятельно при запуске:<br />
<br />
dev<br />
ca<br />
cert<br />
key<br />
persist-key<br />
persist-tun<br />
<br />
И обязательно добавив параметры, которых по умолчанию в конфиге-примере нет:<br />
<br />
tls-server<br />
script-security 2<br />
<br />
Параметр script-security был введен начиная с версии 2.1_rc9. Поскольку etcnet запускает openvpn так, что в процессе тот запускает скрипт scripts/openvpn.action, который считается "пользовательским", то для этого значение должно быть 2.<br />
<br />
* скопировать в каталог интерфейса ключи и измененный конфиг-файл openvpn.<br />
Файлы надо переименовать (ключи - после easy-rsa) таким образом:<br />
{| align="center" border="1"<br />
|ключ easy-rsa<br />
|ключ etcnet-ovpn<br />
|-<br />
|ca.crt <br />
|ovpnca<br />
|-<br />
|server.crt<br />
|ovpncrt<br />
|-<br />
|server.key<br />
|ovpnkey<br />
|-<br />
|server.conf<br />
|ovpnoptions<br />
|}<br />
<br />
<br />
<br />
После всего этого можно попробовать запустить интерфейс: ifup tun0 (или весь мост, например ifup br0). Но если, например, openvpn считает ошибочной какую-либо опцию, то он молча выйдет с кодом выхода 1, и скрипт ifup ничего не напишет (в логе так же не будет попытки запуска openvpn). Потребуется отладка (например, можно запустить openvpn вручную без параметра --daemon и со всеми параметрами, которые подставил etcnet).<br />
<br />
<div id="wireguard"></div><br />
<br />
=== Настройка WireGuard VPN туннеля ===<br />
<br />
WireGuard используется для быстрого создания VPN туннелей, является более легким и безопасным чем OpenVPN. Для использования wireguard необходимо '''ядро std-def версии 3.10+''', установленный модуль ядра '''kernel-modules-wireguard-std-def''' и пакет '''wireguard-tools'''. Для настройки интерфейса необходимо:<br />
* создать каталог интерфейса {{path|/etc/net/ifaces/wg0}}<br />
* добавить файл с конфигурацией {{path|/etc/net/ifaces/wg0/options}}<br />
<source lang='ini'><br />
TYPE=wg<br />
LISTENPORT=51820<br />
</source><br />
* добавить файл с поддерживающимися wireguard опциями пиров {{path|/etc/net/ifaces/wg0/peers}} (одна строка - один пир)<br />
<source lang='bash'><br />
peer PUBLICPEERKEY allowed-ips IFACESSUBNET endpoint PUBLICIP:ALLOWPORT<br />
</source><br />
* добавить файл содержащий локальные и удаленные ip адреса {{path|/etc/net/ifaces/wg0/ipv4address}}<br />
первым делом указывается выделенная интерфейсу локальная подсеть, после чего указываются соответствия локального и удаленного ip адресов, каждое соответствие с новой строки<br />
<source lang='bash'><br />
10.1.0.0/16<br />
10.1.0.1 10.2.0.1<br />
</source><br />
* добавить файл содержащий приватный ключ {{path|/etc/net/ifaces/wg0/privatekey}}<br />
Ключи могут быть созданы стандартной утилитой wireguard:<br />
<source lang='bash'><br />
$ umask 077<br />
$ wg genkey > privatekey<br />
$ wg pubkey < privatekey > publickey<br />
</source><br />
<br />
<div id="iptun"></div><br />
<br />
=== Настройка и использование IP-туннелей ===<br />
<br />
IP-туннели — средство, позволяющее улучшить IP-сети. Поддерживаются IP-туннели трёх видов: <br />
* IPIP<br />
* GRE<br />
* SIT <br />
* VTI<br />
<br />
Прежде всего следует определить необходимый вид туннеля для решаемой задачи. <br />
<br />
* Туннели '''IPIP''' — самые простые.<br />
<br />
* Туннели '''GRE''' (general incapsulation) обычно используются в маршрутизаторах Cisco. По туннелям этого типа могут передаваться broadcast и multicast пакеты. Кроме того, эти туннели поддерживают контрольные суммы и контроль упорядоченности пакетов. Также GRE-туннели обладают опциональным атрибутом key в виде произвольного 4-байтового числа, который позволяет конфигурировать несколько GRE туннелей между одной парой IP-адресов несущей сети (в отличие от IPIP-туннелей, с которыми это невозможно).<br />
<br />
* Туннели '''SIT''' предназначены для транспортировки пакетов IPv6 через сети IPv4.<br />
<br />
* Туннели '''VTI''' используются для построения IPsec туннелей. Работают используя один из демонов, strongswan или libreswan.<br />
<br />
Тип туннеля определяется опцией <tt>TUNTYPE (ipip, gre, sit, vti)</tt>. По умолчанию <tt>TUNTYPE=ipip</tt>. Кроме типа туннеля для конфигурации всегда требуется адрес удалённого хоста и почти всегда — локальный адрес. Эти адреса определяются опциями <tt>TUNREMOTE</tt> и <tt>TUNLOCAL</tt> соответственно. В некоторых случаях локальный адрес можно не указывать. В этом случае опция <tt>TUNLOCAL</tt> всё равно обязательна, но принимает значение <tt>any</tt>. Не забудьте назначить туннельному интерфейсу адреса и маршруты в соответствующих файлах.<br />
<br />
Пример: Конфигурация GRE-туннеля между 10.0.1.2 и 10.0.2.3 с двумя ключами для исходящих и входящих пакетов, проверкой очерёдности пакетов, TTL 8 и вычислением контрольных сумм. Туннель должен использовать только интерфейс gw1. Пусть имя создаваемого туннеля будет <tt>mytunnel</tt>.<br />
<br />
Тогда необходимо сделать следующие операции:<br />
* Создать каталог туннеля: {{path|/etc/net/ifaces/mytunnel}}<br />
<br />
* Создать в каталоге туннеля файл настроек <tt>options</tt>: {{path|/etc/net/ifaces/mytunnel/options}}<br />
<br />
* Отредактировать файл настроек <tt>options</tt>: <br />
<br />
<source lang="ini"><br />
TYPE=iptun<br />
TUNTYPE=gre<br />
TUNLOCAL=10.0.1.2<br />
TUNREMOTE=10.0.2.3<br />
TUNTTL=8<br />
HOST=gw1<br />
TUNOPTIONS='ttl 64 seq ikey 2020 okey 2030 csum'<br />
</source><br />
<br />
<div id="vpn"></div><br />
<br />
Про <tt>ttl 64</tt>. Если параметр ttl не задан, значение берётся из инкапсулируемого пакета (это надо проверить). В некоторых случаях ttl может получиться слишком мал (например, Quagga формирует OSPF-пакеты с TTL 1).<br />
<br />
Стоит помнить, что имена <tt>tunl0, gre0 и sit0</tt> являются зарезервированными в iproute2 ("base devices") и имеют особое поведение: http://www.liveinternet.ru/users/stasikos/post71435454/<br />
<br />
Процедура создания vti интерфейса стандартна, однако, предварительно необходимо установить и настроить один из демонов (strongswan, libreswan), о том, как это сделать можно найти в соответствующей документации. После чего необходимо создать каталог интерфейса (к примеру он будет называться vti0) {{path|/etc/net/ifaces/vti0}}, и добавить в него файл настроек туннеля {{path|/etc/net/ifaces/vti0/options}}, куда нужно прописать необходимую конфигурацию:<br />
<source lang='ini'><br />
TYPE=iptun<br />
TUNTYPE=vti<br />
TUNLOCAL=119.81.184.173<br />
TUNREMOTE=119.81.177.236<br />
TUNOPTIONS='key 42'<br />
</source><br />
Параметр key должен соответствовать параметру mark, указанному при настройке strongswan/libreswan.<br />
<br />
=== Настройка IPv6 ===<br />
==== Отключение IPv6 ====<br />
<br />
* '''Вариант 1'''<br />
Чтобы отключить IPv6 на всех сетевых интерфейсах в работающей системе с загруженным модулем ipv6, нужно изменить значение параметра ядра net.ipv6.conf.all.disable_ipv6, где 'all' подразумевает все интерфейсы, а net.ipv6.conf.eth0.disable_ipv6 -- отключение протокола IPv6 только на интерфейсе eth0 и т.д.<br />
<pre><br />
sysctl net.ipv6.conf.all.disable_ipv6=1<br />
</pre><br />
Также можно добавить данную директиву в {{path|/etc/sysctl.conf}}:<br />
<source lang="bash"><br />
echo 'net.ipv6.conf.all.disable_ipv6 = 1' >> /etc/sysctl.conf<br />
sysctl -f<br />
</source><br />
<br />
* '''Вариант 2'''<br />
Добавить параметр в командную строку загрузки ядра. Для GRUB2 нужно изменить параметры загрузки ядра в файле {{path|/etc/sysconfig/grub2}}, изменив переменную GRUB_CMDLINE_LINUX_DEFAULT или GRUB_CMDLINE_LINUX<br />
<pre><br />
...<br />
GRUB_CMDLINE_LINUX='failsafe vga=normal ipv6.disable=1'<br />
...<br />
</pre><br />
и обновив конфигурационный файл grub<br />
<source lang="bash"><br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
</source><br />
<br />
* '''Вариант 3'''<br />
<source lang="bash"><br />
echo 'options ipv6 disable=1' >> /etc/modprobe.d/options-local.conf<br />
</source><br />
Вступит в силу только после перезагрузки.<br />
<br />
==== Включение IPv6 ====<br />
<br />
* Во-первых, следует убедиться, что не применяется какой-либо вариант совета из предыдущего пункта. <br />
* Во-вторых, следует проверить значение CONFIG_IPV6 в etcnet. Переменная может быть описана в /etc/net/options.d/*, /etc/net/ifaces/default/*, /etc/net/ifaces/*/options. Наибольший приоритет у описания в ifaces/*/options.<br />
<br />
'''Замечание:''' В etcnet-0.9.10-alt5, в /etc/net/ifaces/default/options содержится CONFIG_IPV6=no<br />
<br />
==== Туннели 6-to-4 ====<br />
<br />
Требуется:<br />
* ядро с поддержкой IPv6 (CONFIG_IPV6 в /boot/config-*; наличие модуля ipv6);<br />
* ядро с поддержкой tun (CONFIG_TUN в /boot/config-*; наличие модуля tun);<br />
* доступность узла 192.88.99.1 - через него маршрутизируется трафик в сети IPv6.<br />
<br />
Далее в {{path|/etc/net/ifaces}} создаётся каталог с названием, например,<br />
tun6to4. В нём создаются файлы:<br />
iplink : <pre><br />
mtu 1472 </pre><br />
<br />
ipv6address : <pre><br />
# first six octets: ipv6calc --ipv4_to_6to4addr $TUNLOCAL<br />
2002:c000:201::1/16 </pre><br />
<br />
ipv6route : <pre><br />
2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 </pre><br />
<br />
options : <pre><br />
TYPE=iptun<br />
TUNTYPE=sit<br />
TUNLOCAL=192.0.2.1<br />
TUNREMOTE=any<br />
TUNOPTIONS="ttl 64"<br />
DONT_FLUSH=yes<br />
CONFIG_IPV6=yes </pre><br />
<br />
Адрес TUNLOCAL в options - имеющийся внешний IPv4, в ipv6address<br />
адрес IPv6 выбирается исходя из него же.<br />
<br />
В настройках iptables должно быть разрешение на приём пакетов протокола<br />
ipv6 на внешний адрес IPv4.<br />
<br />
Далее поднимается интерфейс tun6to4, ну и проверяется доступность <br />
чего-либо в IPv6.<br />
<br />
Туннели 6to4 - это RFC 3964.<br />
Miredo - это реализация протокола Teredo, RFC 4380.<br />
6to4 требует наличия внешнего адреса IPv4.<br />
Teredo не требует наличия внешнего адреса, и может работать через NAT.<br />
Через Teredo не получится получить симметричное соединение, т.е. доступ<br />
в IPv6 будет односторонний, на компьютер в общем случае извне<br />
подключиться не получится.<br />
И Teredo позволяет получить только адрес /32, т.е. для подключения сетей<br />
он мало пригоден.<br />
<br />
этот раздел скопирован из письма рассылки community (c) Nikolay A. Fetisov 8 сентября 2011 12:03:30<br />
<br />
=== Замечания о настройке VPN-подключения и туннелей ===<br />
<br />
Часто при настройке VPN-подключения (под которыми здесь будут подразумеваться все туннельные подключения, то есть подключения поверх IP) не учитывают, что использование опции pppd '<tt>defaultroute</tt>' маршрут по-умолчанию после подключения будет изменен. При этом, если VPN-сервер находится в другой, отличной от клиента, сети, то после подключения (и изменения маршрута по-умолчанию) VPN-сервер становится недоступным, следовательно, недоступными становятся все внешние адреса, и подключение, как правило, прекращается по тайм-ауту.<br />
<br />
Решением, как обычно (и рекомендовано), служит указание ''отдельного'' маршрута на VPN-сервер (или его сеть). Для этого необходимо прописать (в примере - для маршрута через eth0) в {{path|/etc/net/ifaces/eth0/ipv4route}} строку вида:<br />
<br />
10.0.1.0/24 via 10.0.0.1<br />
<br />
В данном примере подразумевается, что VPN-сервер находится в сети 10.0.1.0/24 (например, имеет адрес 10.0.1.1), клиент — в сети 10.0.0.0/24 (и имеет адрес, например, 10.0.0.10), а маршрутизатор имеет адрес 10.0.0.1.<br />
<br />
Теперь, при использовании опции '<tt>defaulroute</tt>' для pppd (которая указывает, что необходимо изменить на вновь созданное подключение маршрут по-умолчанию), даже после замены маршрута по-умолчанию новым, сеть 10.0.1.0, в которой в нашем примере и находится VPN-сервер, останется доступной.<br />
<br />
Как более точечный вариант (применяется в alterator-net-pptp 0.5.x) можно использовать скрипты {{cmd|ifup-pre}} и {{cmd|ifdown-post}} в каталоге конфигурируемого PPP-интерфейса.<br />
<br />
Наример:<br />
<source lang="bash"><br />
#!/bin/sh<br />
# sample /etc/net/ifaces/ppp0/ifup-pre; replace variables yourself<br />
ip route add VPN_SERVER via DEF_GW<br />
</source><br />
<source lang="bash"><br />
#!/bin/sh<br />
# sample /etc/net/ifaces/ppp0/ifdown-post; replace variables yourself<br />
ip route del VPN_SERVER via DEF_GW<br />
</source><br />
<br />
Не забудьте подставить нужные IP-адреса вместо VPN_SERVER и DEF_GW (не сеть, где VPN-сервер, а ее /32 префикс CIDR) и выполнить команду: {{cmd|chmod +x ifup-pre ifdown-post}}<br />
<br />
<div id="iprule"></div><br />
<br />
=== Сложная маршрутизация (или несколько таблиц маршрутизации) ===<br />
<br />
Под «сложной маршрутизацией» подразумевается наличие нескольких таблиц маршрутизации. Для их использования необходимо сконфигурировать правила ядра. В правилах по умолчанию можно увидеть следующее:<br />
<br />
<pre># ip rule show<br />
0: from all lookup local <br />
32766: from all lookup main <br />
32767: from all lookup default</pre><br />
<br />
Для настройки «сложной маршрутизациии» необходимо выполнить следующие операции:<br />
<br />
Шаг 1 : Сами таблицы определены в файле {{path|/etc/iproute2/rt_tables}}. Для создания конфигурации «сложной маршрутизации» необходимо вначале «создать» нужные таблицы в этом файле (если вы хотите использовать имена таблиц, а не числа).<br />
<br />
Шаг 2 : Необходимо заполнить таблицы. В конфигурационном каталоге интерфейса в файле <tt>ipv4route</tt> необходимо добавить маршрутные записи, не забывая указать <tt>table XX</tt>. Важно учитывать, что если строка начинается с режима ip route (add, del, replace, append, change), то по умолчанию будет использован режим <tt>DEFAULT_IPV4ROUTE_CMD</tt> (<tt>append</tt>).<br />
<br />
Шаг 3 : Определить правила в файле <tt>ipv4rule</tt>. Здесь есть особенности, связанные автоматической заменой/добавлением параметров. Если строка не начинается с операции del или add, то нужный режим будет подставлен автоматически. Это подходит для тех случаев, когда вам при "поднятии" интерфейса необходимо добавить правила, а при "опускании" — удалить. Возможность указывать del или add реализована для обратных случаев: если при "поднятии" интерфейса вам необходимо удалить правила, а при "опускании" — добавить. В этом случае add и del будут в нужный момент автоматически заменены на del и add.<br />
<br />
Пример такой конфигурации входит в /etc/net 0.7.12: (каталог документации examples/routing-LARTC-1/)<br />
<br />
=== Простое переключение маршрутов ===<br />
<br />
Пусть имеется eth-интерфейс, который используется постоянно, и настроен маршрут по умолчанию.<br />
Часто бывает необходимость настроить второй маршрут по умолчанию через беспроводной интерфейс,<br />
но с меньшей метрикой, чем у проводного интерфейса.<br />
В этом случае при поднятии WI-FI маршрут по умолчанию «развернется» в нужную сторону.<br />
<br />
Например:<br />
<br />
Для eth-интерфейса файл настроек {{path|/etc/net/ifaces/eth0/ipv4route}} будет таким:<br />
<pre>default via 192.168.3.254 metric 10</pre><br />
а для WI-FI-интерфейса файл настроек {{path|/etc/net/ifaces/ath0/ipv4route}} таким:<br />
<pre>default via 192.168.123.1 metric 5</pre><br />
<br />
<div id="wireless"></div><br />
=== Беспроводный Ethernet (или настройка WI-FI) ===<br />
Большинство беспроводных интерфейсов сейчас представлено системе как интерфейсы Ethernet. Соответственно беспроводный интерфейс будет иметь <b>TYPE=eth</b> (<s>[https://bugzilla.altlinux.org/show_bug.cgi?id=6283 #6283]</s>). Чтобы интерфейс нормально функционировал, необходимо кроме загрузки модуля с параметрами, воспользоваться утилитами {{cmd|iwconfig}} из пакета wireless-tools или {{cmd|wpa_supplicant}} из такого же пакета. Вместо того, чтобы запускать их вручную, можно поместить в конфигурационный каталог интерфейса файл <tt>iwconfig</tt> с командами iwconfig или файл <tt>wpa_supplicant.conf</tt> с конфигурацией wpa_supplicant. Они будут использованы автоматически.<br />
<br />
Пример [http://hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wireless.html конфигурации] (совместно с <tt>[http://ndiswrapper.sourceforge.net/ ndiswrapper]</tt>):<br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/options}}<br />
<pre>TYPE=eth<br />
MODULE=ndiswrapper<br />
NEVER_RMMOD=yes<br />
BOOTPROTO=dhcp<br />
USE_HOTPLUG=no<br />
ONBOOT=no</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/iwconfig}}<br />
<pre>essid default<br />
#key bababababa</pre><br />
<br />
<br />
Еще один пример использования etcnet для настройки беспроводной сети:<br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/options}}<br />
<pre>TYPE=eth<br />
USE_HOTPLUG=NO<br />
BOOTPROTO=static<br />
module=ipw2200<br />
WPA_DRIVER=wext</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/iwconfig}}<br />
<pre>essid homenet<br />
mode 1<br />
ap 00:11:D8:22:AD:0D<br />
channel 3<br />
rate 11M</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}}<br />
<pre>ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=0<br />
eapol_version=1<br />
ap_scan=1<br />
fast_reauth=1<br />
<br />
network={<br />
ssid="homenet"<br />
scan_ssid=1<br />
key_mgmt=WPA-PSK<br />
psk="this is my mega secret password string to wpa supplicant"<br />
}</pre><br />
<br />
Если вы хотите воспользоваться WPS:<br />
# создайте {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}} следующего вида:<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
update_config=1<br />
</pre><br />
# поднимите беспроводной интерфейс (ifup wlan0)<br />
# запустите wpa_cli и дайте команды wps_pbc (после этого нужно соответственно нажать кнопку WPS на точке доступа и подождать окончания обмена данными) и save_config (для записи конфигурации в <tt>wpa_supplicant.conf</tt>). Или же можно воспользоваться утилитой wpa_gui, отображающей процесс более наглядно.<br />
<br />
Пример файла {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}} при подключении к сети, использующей протокол WPA2-PSK(AES)<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=0<br />
eapol_version=1<br />
ap_scan=1<br />
fast_reauth=1<br />
<br />
network={<br />
ssid="home-lg"<br />
bssid=00:1B:11:87:C7:EA<br />
proto=RSN<br />
key_mgmt=WPA-PSK<br />
pairwise=CCMP TKIP<br />
group=CCMP TKIP<br />
psk="this is my mega secret password string to wpa supplicant"<br />
priority=2<br />
}<br />
</pre><br />
<br />
<div id="infiniband"></div><br />
<br />
=== Настройка Infiniband ===<br />
На сейчас ничем не отличается от настройки Ethernet, специфическая поддержка отсутствует (и для [[Infiniband#IP_over_IB|IP-over-IB]] не требуется). Пример конфигурации для Mellanox:<br />
<br />
Файл: <tt>/etc/modules</tt><br />
<pre>mlx4_ib<br />
ib_umad<br />
ib_ipoib</pre><br />
<br />
Файл: <tt>/etc/net/ifaces/ib0/options</tt><br />
<pre>TYPE=eth<br />
BOOTPROTO=dhcp<br />
ONBOOT=yes</pre><br />
<br />
<div id="sysctl"></div><br />
<br />
=== Использование автодополнения в sysctl.conf ===<br />
<br />
В конфигурационном каталоге интерфейса может находиться файл <tt>sysctl.conf</tt>, в котором можно перечислить переменные <tt>sysctl(8)</tt>. Но переменные могут быть как общесистемными, так и относящимися к интерфейсу. Естественно, запись в sysctl.conf настроек вида <tt>net.ipv4.conf.eth0.log_martians = 1</tt> достаточно неудобна, а при переименовании интерфейса велик риск не отредактировать файл <tt>sysctl.conf</tt> соответствующим образом.<br />
<br />
Эта проблема решается следующим способом : производится запись в файл только имени переменной и значение, а система /etc/net сама найдет путь к этой переменной и вызовет <tt>sysctl</tt> с полным именем. <br />
<br />
Пример содержания файла <tt>sysctl.conf</tt>:<br />
<pre>log_martians=1<br />
rp_filter=1</pre><br />
<br />
<div id="profiles"></div><br />
<br />
=== Подключение к Wi-Fi с сертификатом на аппаратном токене ===<br />
Для беспроводного подключения в корпоративных сетях могут использоваться сертификаты, записанные на аппаратном токене, например, Aladdin eToken. Для настройки такого подключения необходимо использовать {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}}.<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=wheel<br />
#eapol_version=1<br />
#ap_scan=2<br />
#fast_reauth=1<br />
pkcs11_engine_path=/usr/lib/openssl/engines/engine_pkcs11.so<br />
pkcs11_module_path=/usr/lib/libeTPkcs11.so<br />
update_config=0<br />
<br />
network={<br />
ssid="test"<br />
key_mgmt=WPA-EAP<br />
pairwise=CCMP TKIP<br />
group=CCMP TKIP<br />
eap=TLS<br />
identity="email@address.ru"<br />
engine_id="pkcs11"<br />
key_id="xxxxxxxxx"<br />
cert_id="xxxxxxxxx"<br />
engine=1<br />
}<br />
</pre><br />
где key_id и cerd_id взяты из вывода команды<br />
<pre><br />
# pkcs11-tool --module /usr/lib/libeTPkcs11.so -O -l<br />
</pre><br />
<br />
Используются оригинальные ("родные") драйвера Aladdin - pkiclient-5.00.28-0, и пакет openssl-engine_pkcs11-0.1.5-alt1.<br />
<br />
=== Профили конфигурации ===<br />
<br />
==== Определение профилей ====<br />
Профиль — именованный вариант конфигурации, в той или иной степени изменяющий базовую конфигурацию системы. Профили могут быть применены, например, для конфигурации ноутбука в разных сетевых окружениях, или при подготовке новой или тестовой конфигурации с возможностью быстрого возврата к старой. Практически профили реализуются следующим образом: для какого-либо из файлов, составляющих общесистемную конфигурацию или конфигурацию интерфейса, создаётся альтернативный вариант, который отличается добавлением в конце названия файла знака # и имени профиля.<br />
<br />
Например, пусть единственное отличие между профилями заключается в том, какой модуль ядра будет загружен для интерфейса eth0. В этом случае файл {{path|/etc/net/ifaces/eth0/options}} необходимо скопировать в {{path|/etc/net/ifaces/eth0/options#profile1}} и изменить значение переменной <tt>MODULE</tt> в одном из них. Далее при использовании конфигурации по умолчанию будет использован файл <tt>options</tt>, а при использовании профиля profile1 — файл <tt>options#profile1</tt>. Если при этом для назначения интерфейсу имени используется файл {{path|/etc/net/iftab}}, то скорее всего необходимо будет создать соответствующий файл {{path|/etc/net/iftab#profile1}}, так как другой модуль ядра указывает на другой физический интерфейс и исходный файл <tt>iftab</tt> работать не будет.<br />
<br />
Профили могут использоваться также и для отключения каких-то параметров конфигурации. Например, если используется файл <tt>ipv4route</tt> для установки маршрутов для интерфейса, то можно создать файл нулевого размера <tt>ipv4route#profile2</tt>, чтобы при использовании профиля profile2 никаких маршрутов не конфигурировалось.<br />
<br />
==== Выбор профиля при загрузке ====<br />
Если при загрузке системы ядру был передан параметр netprofile, то его значение будет использовано как имя профиля по умолчанию. Это может быть использовано для создания собственных пунктов меню загрузчиков LILO и GRUB с заранее определённым профилем сетевой конфигурации. Заданный таким образом профиль может быть далее переопределён другими методами. Следует понимать разницу между различными конфигурациями и различными результатами применения одной конфигурации. Например, если в двух разных сетях используется DHCP, то смысла в разных профилях конфигурации нет.<br />
<br />
Для загрузчика LILO секции <tt>/etc/lilo.conf</tt> могут выглядеть следующим образом:<br />
<pre>image=/boot/vmlinuz-up<br />
label=linux-up home<br />
append=" netprofile=home"<br />
[...]<br />
image=/boot/vmlinuz-up<br />
label=linux-up office<br />
append=" netprofile=office"<br />
[...]</pre><br />
Для приведённого примера необходимо будет создать варианты для файлов, отличающихся в профилях home и office, и можно будет выбирать при загрузке, какой из профилей необходимо использовать. Использование этого метода удобно, если смена сетевого окружения происходит синхронно с загрузкой системы.<br />
<br />
==== Выбор профиля по умолчанию ====<br />
Если требуется, чтобы определенный профиль конфигурации использовался по умолчанию, то необходимо записать его название в файл <tt>/etc/net/profile</tt>. Этот метод имеет приоритет над параметром ядра netprofile. Использование такого способа выбора профиля целесообразно, когда переключение между конфигурациями происходит реже, чем перезагрузка системы.<br />
<br />
==== Смена профиля во время работы ====<br />
Если требуется переконфигурировать сеть без перезагрузки или редактирования файла {{path|/etc/net/profile}}, то следует использовать параметры сервиса network, описанные в разделе [[#restart, reload и другие команды|restart, reload и другие команды]]. Этот метод имеет приоритет над профилем по умолчанию и профилем, выбранным при загрузке. Целесообразно его использовать, если смена сетевого окружения происходит чаще, чем перезагрузка системы.<br />
<br />
==== Определение профиля во время конфигурации интерфейса ====<br />
Если в каталоге конфигурации интерфейса существует исполняемый файл ненулевого размера с именем <tt>selectprofile</tt>, то этот файл будет выполнен и первое слово первой строки его стандартного вывода использовано как имя профиля, которое должно быть использовано для конфигурации данного интерфейса. Этот метод имеет приоритет над всеми остальными методами. Исходной задачей, требующей такого решения, являлось конфигурирование беспроводного интерфейса в зависимости от доступных точек доступа.<br />
<br />
Следует учитывать, что число вызовов файла <tt>selectprofile</tt> может меняться в зависимости от контекста и время его выполнения может быть различным, поэтому при написании такого файла следует учитывать, что первым параметром будет являться имя текущего сценария. В настоящее время это могут быть ifup*, ifdown*, setup* и shutdown*. Для приведённого выше примера имеет смысл реагировать только на вызовы из ifup или ifup-common.<br />
<br />
== См. также ==<br />
* [[Ресолвер]]<br />
<br />
== Примечания ==<br />
<references/><br />
<br />
{{Category navigation|title=etcnet|category=etcnet|sortkey=*}}<br />
[[Категория:WiFi]]<br />
{{Category navigation|title=Wi-Fi|category=WiFi|sortkey={{SUBPAGENAME}}}}<br />
[[Категория:Admin]]<br />
{{Category navigation|title=Системному администратору|category=Admin|sortkey={{SUBPAGENAME}}}}<br />
[[en:etcnet]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=Fleet_Commander&diff=49054Fleet Commander2020-08-08T21:33:19Z<p>AntonFarygin: /* Проблемы связанные с использованием */</p>
<hr />
<div>[[Файл:fc_ico.png.png|frameless|right]]<br />
'''Fleet commander''' - это инструмент для управления и развертывания профилей в большой сети пользователей и рабочих станций.<br />
<br />
Fleet Commander состоит из трех компонентов:<br />
*плагин FreeIPA, который позволяет хранить профили на контроллере домена<br />
*плагин Cockpit, отвечающий за администрирование и предоставляющий интерфейс<br />
*служба на стороне клиента, которая работает на каждом узле сети.<br />
<br />
Fleet Commander использует libvirt и KVM для запуска сеанса виртуального рабочего стола, который позволяет пользователю в реальном времени редактировать конфигурацию приложений в системе шаблонов, которая будет применена на клиентах.<br />
<br />
== Установка и настройка Fleet Commander ==<br />
Как уже говорилось выше, Fleet Commander состоит из трех компонентов. Рассмотрим пример развертывания Fleet Commander на четырех машинах:<br />
<br />
''admin, client, template, libvirt host''.<br />
<br />
===Установка и настройка Fleet Commander Admin===<br />
Предварительно необходимо установить и настроить FreeIPA сервер, с созданием домашнего каталога (добавить опцию ''--mkhomedir''). Инструкцию по установке FreeIPA сервера можно посмотреть в [[FreeIPA| соответствующем разделе]].<br />
<br />
Далее установим необходимые пакеты<br />
# apt-get install freeipa-desktop-profile cockpit<br />
и запустим<br />
# systemctl start cockpit<br />
<br />
web-интерфейс Cockpit будет доступен по адресу<br />
http://localhost:9090/<br />
<br />
вход осуществляется по логину указанному при установке FreeIPA сервера.<br />
<br />
Установим Fleet Commander плагирн для Cockpit<br />
# apt-get install fleet-commander-admin<br />
<br />
после перезагрузки демона Cockpit на web-интерфейсе появится доступ к настройке Fleet Commander.<br />
<br />
Настроить Fleet Commander достаточно один раз при первом запуске. Окно настроек выглядит следующим образом:<br />
<br>[[Файл:fc_settings2.png|450px]]<br><br />
<br />
Fleet Commander позволяет установить глобальную политику для определения того, как применять несколько профилей: ''к конкретному пользователю, к группе, к хосту, к группе хостов''. По умолчанию это ''User-Group-Host-Hostgroup''.<br />
<br />
В форму настройки необходимо ввести адрес и имя пользователя libvirt-хоста для подключения. Если пользователь не является привилегированным, то переключаем <code>''Libvirt mode''</code> в режим сеанса.<br />
<br />
Для запуска live-сессии необходимо работающее ssh-соединение с libvirt хостом. Fleet Commander генерирует собственный открытый ключ, который необходимо добавить в ''.ssh/authorized_keys'' для соответствующего пользователя на libvirt хосте. Это можно сделать с помощью <code>''Install public key''</code> на форме настройки, при этом будет необходимо ввести пароль пользователя. Пароль используется только для установки ключа и нигде не хранится.<br />
<br />
==== Работа с профилями ====<br />
После настройки Fleet Commander Admin необходимо создать и настроить профиль. Редактирование профиля производится из этого же интерфейса. После нажатия <code>''Add Profile''</code> появится форма настройки профиля:<br />
<br>[[Файл:profile_settings1.png|400px]]<br><br />
<br />
Форма настройки профиля содержит следующие поля:<br />
*<code>''Name''</code> - имя профиля<br />
*<code>''Description''</code> - описание профиля<br />
*<code>''Priority''</code> - приоритет профиля<br />
*<code>''Users''</code> - пользователи, к которым будет применен профиль<br />
*<code>''Groups''</code> - группы, к которым будет применен профиль<br />
*<code>''Hosts''</code> - хосты, к которым будет применен профиль<br />
*<code>''Host groups''</code> - группы хостов, к которым будет применен профиль<br />
<br />
Если не указан ни один хост или группа хостов, то профиль будет применен к каждому хосту состоящему в домене.<br />
<br />
После редактирования профиля сохраним изменения и перейдем к настройка libvirt хоста.<br />
<br />
=== Настройка libvirt-хоста ===<br />
В качестве libvirt-хоста может выступать как отдельная машина, так и машина с Fleet Commander Admin.<br />
<br />
Установим необходимый пакет<br />
# apt-get install libvirt<br />
<br />
и запустим его сервис<br />
# systemctl enable libvirtd.service<br />
# systemctl start libvirtd.service<br />
<br />
Если есть необходимость использовать привилегированного пользователя libvirt хоста, то необходимо разрешить root-доступ по ssh. Для этого в конфигурационном файле ''/etc/openssh/sshd_config'' нужно указать <code>''PermitRootLogin yes''</code> и перезагрузить ssh-сервис:<br />
# systemctl restart sshd.service<br />
<br />
=== Настройка шаблона ===<br />
Шаблон это отдельная машина с запущенным на ней Fleet Commander Logger. Шаблон запускается на "админской" машине в live-сессии. Логгер отслеживает сделанные изменения в шаблоне и сохраняет их.<br />
<br />
Если в качестве libvirt хоста используется FreeIPA сервер, то шаблон необходимо иметь на нем же.<br />
<br />
На template-машине достаточно установить логгер:<br />
# apt-get install fleet-commander-logger<br />
<br />
После выключения шаблона можно попробовать запустить live-сессию. Для этого в web-интерфейсе cocpkit'а необходимо нажать <code>''Edit''</code> напротив нужного профиля и внизу всплывшего окна кнопку <code>''Live session''</code>. В появившейся форме будет список всех доступных шаблонов, кликнув по шаблону он начнет загружаться.<br />
<br />
=== Установка и настройка Fleet Commander Client ===<br />
Клиентская машина должна быть введена в домен, как установить и настроить FreeIPA Client можно посмотреть в [[FreeIPA| соответствующем разделе]].<br />
<br />
Установим необходимый пакет:<br />
# apt-get install fleet-commander-client<br />
<br />
Создадим доменного пользователя. Это можно сделать как через консоль, так и через web-интерфейс по адресу FreeIPA сервера, войдя под "админской" учетной записью.<br />
<br />
== Устранение неполадок Fleet Commander ==<br />
Для отлавливания любых ошибок возникших во время работы Fleet Commander Admin необходимо добавить <code>''log_level = debug''</code> в <br>''/etc/xdg/fleet-commander-admin.conf''. Возникшие ошибки можно отследить используя ''journalctl''.<br />
<br />
=== Can’t initialize Fleet Commander ===<br />
Проверьте установлен ли ''freeipa-desktop-profile'', если нет, то установите. Часто такая ошибка может возникнуть в случае отсутствия домашнего каталога, если установка FreeIPA Server была запущена без опции ''--mkhomedir''. Для решения данной проблемы можно воспользоваться командой:<br />
# mkhomedir_helper `username`<br />
<br />
Если вышеприведенные способы не помогают, проверьте есть ли у администратора доступ к командам интерфейса:<br />
# ipa console<br />
(Custom IPA interactive Python console)<br />
>>'deskprofileconfig_show' in api.Command<br />
False<br />
<br />
В этом случае кэш пользователя должен быть удален, это можно сделать добавив <code>''force_schema_check = True''</code> в ''/etc/ipa/fleetcommander.conf'' в секцию ''[global]''.<br />
<br />
=== Не заходит под доменным пользователем ===<br />
После создания доменного пользователя и попытки входа может возникнуть ошибка недоступности домашнего каталога. Обычно помогает выполнение<br />
# ssh -l `username` localhost<br />
<br />
после чего попытка входа под доменным пользователем удается.<br />
<br />
=== Error getting domain list ===<br />
Ошибка, которая возникает при попытки подключения к live-сессии. Обычно проблема связана с неправильной конфигурацией libvirt-хоста. Проверьте установлен и запущен ли libvirt-client на libvirt хосте.<br />
<br />
== Использование Fleet Commander ==<br />
Администрирование происходит через Cockpit web-интерфейс. Откроем ''http://localhost:9090/fleet-commander-admin'' и запустим live-сессию ''(Edit -> Live session)''. Появится окно выбора машины для загрузки в live-сессии. Необходимо выбрать машину на которой установлен Fleet Commander Logger и запустить ее. Загруженная машина является шаблоном, все сделанные на ней изменения будут отловлены логгером, сохранены и применены на клиентских системах.<br />
<br />
Fleet Commander работает со следующими приложениями:<br />
* GSettings<br />
* LibreOffice<br />
* Chromium<br />
* Chrome<br />
* Firefox<br />
* NetworkManager<br />
<br />
Проверим работу Fleet Commander. На загруженной машине с логгером запустим chromium, и сделаем пару изменений: добавим закладку ''https://www.altlinux.org'' и в настройках браузера поставим галочку <code>''Показывать кнопку "Главная страница"''</code>. После чего в web-интерфейсе Cockpit нажмем <code>''Review and submit''</code>. Должно появиться окно со списком сделанных изменений:<br />
<br>[[Файл:fc_logger_changes.png|350px]]<br><br />
<br />
В списке изменений можно выбрать как все изменения, так и частичные, установив галочку напротив нужного. После выбора сохраним изменения.<br />
<br />
Теперь можно проверить, как изменения применились на клиенте. Загрузим клиентскую машину, войдем в систему под доменным пользователем и запустим chromium (он должен быть предварительно установлен). Сделанные изменения успешно применились и доменный пользователь не сможет их отменить.<br />
<br />
[[Файл:chrom_set.png|500px|left]]<br />
[[Файл:chrom_bkm.png|350px|center]]<br><br />
<br />
=== Проблемы связанные с использованием ===<br />
В текущей версии Fleet Commander выявлены некоторые проблемы, в том числе и уязвимости. О них мы поговорим ниже.<br />
<br />
* ''Незащищенный профиль Firefox и Chromium.'' Владельцем создаваемого Fleet Commander'ом профиля для Firefox и Chromium является доменный пользователь. Поэтому, он может изменить его модификатор доступа и соответственно содержимое файла.<br />
<br />
* ''Отлавливаются не все настройки Chromium.'' Fleet Commander имеет свою встроенную политику настроек Chromium, которые отслеживаются логгером, остальные настройки игнорируются.<br />
<br />
* ''Не отслеживаются настройки Firefox.'' Логгер не всегда правильно определяет путь до профиля настроек Firefox, поэтому не может отследить изменения в настройках.<br />
<br />
* ''Логгер не сбрасывает изменения.'' После сохранения изменений и завершения работы с шаблоном, шаблон должен восстанавливаться до первоначального состояния, т.е. сбрасывать все сделанные администратором изменения. На текущий момент такое поведение сломано и шаблон сохраняет все проделанные изменения в каждой сессии.<br />
<br />
* ''Возможны различные ошибки в работе с GSettings.''<br />
<br />
Так же для корректной работы Fleet Commander с Firefox необходимо добавить <code>''pref("toolkit.policies.perUserDir", true)''</code> в <br>''/usr/lib64/firefox/browser/defaults/preferences/all-altlinux.js''.<br />
<br />
[[Категория:Корпоративная инфраструктура]]<br />
[[Категория:HOWTO]]<br />
<br />
{{Category navigation|title=Корпоративная инфраструктура|category=Корпоративная инфраструктура|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=KVM&diff=48900KVM2020-07-29T12:19:27Z<p>AntonFarygin: </p>
<hr />
<div>См.тж. [[Настройка_сети_в_KVM]] и [[Создание профиля KVM]]<br />
== Команды для управления QEMU-KVM ==<br />
<pre><br />
virsh -c qemu:///system list --all #листинг<br />
virsh -c qemu:///system start vsrv1 #пуск<br />
virsh -c qemu:///system shutdown vsrv1 #shutdown<br />
virsh -c qemu:///system destroy vsrv1 #выключить по питанию<br />
virsh -c qemu:///system undefine vsrv1 #удалить (конифг тоже удаляется)<br />
virsh -c qemu:///system autostart vsrv1 #добавить в автозагрузку<br />
virsh -c qemu:///system autostart --disable # удалить из автозагрузки<br />
virsh -c qemu:///system qemu-monitor-command win2008std-32bit help --hmp # запустить команду в qemu мониторе<br />
virsh -c qemu:///system define /etc/libvirt/qemu/mirror.xml # обновить информацию о виртуальной машине.<br />
</pre><br />
Чтобы постоянно не вводить <code>-c qemu:///system</code> можно добавить:<br />
<pre>export LIBVIRT_DEFAULT_URI=qemu:///system</pre><br />
<br />
== Расположение основных конфигов ==<br />
* /etc/libvirt/qemu.conf - основной конфиг qemu. Тут задаём параметры vnc сервера.<br />
* /etc/libvirt/qemu/ - папка для хранения конфигов, в том числе и виртуальных машин.<br />
<br />
== Создание VPS ==<br />
VPS можно создавать с разными виртуальными устройствами. Можно использовать по умолчанию, а можно использовать virtio. Последние считаются наилучшим вариантом для Windows OS. Поэтому ВСЕГДА стараемся сделать так, как надо. Если не получается - тогда как обычно.<br />
Для новой системы со сразу установленными значениями virtio в конфиге необходимо в процессе установки добавить драйверы. Качаем iso с драйверами:<br />
wget https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso<br />
(ссылка верна на 27 октября 2016 г., в дальнейшем можно заглянуть на [https://fedoraproject.org/wiki/Windows_Virtio_Drivers#Direct_download вики проекта] или в старый [http://alt.fedoraproject.org/pub/alt/virtio-win/latest/ каталог загрузок] и скачать имеющийся там virtio-win*.iso)<br />
<br />
=== Создание VPS Windows с поддержкой virtio ===<br />
* создаем LVM раздел нужного размера:<br />
<pre><br />
/sbin/lvcreate -L 10G -n win2008 main<br />
</pre><br />
* coздаем конфиг VPS:<br />
<pre><br />
virt-install --connect=qemu:///system -n test_win2008 -r 1024 --boot cdrom --disk path=/dev/main/test_win2008,bus=virtio \<br />
--disk path=/vz/template/virtio-win-1.1.16.vfd,device=floppy --cdrom=/var/lib/vz/template/SW_DVD5_Windows_Svr_DC_Ent_Std_2008_Russian_32bit_MLF_X14-26782.ISO \<br />
--network bridge:breth0,model=virtio --graphics vnc,password=123,listen=0.0.0.0 --os-type=windows --os-variant=win2k8 --arch=i686 --cpu host -v --autostart<br />
</pre><br />
<br />
где:<br><br />
-n test_win2008 - имя VPS <br><br />
-r 1024 - к-во выделяемой памяти <br><br />
-v использовать аппаратную виртуализацию <br><br />
--arch=i686 - используемая архитектура <br><br />
--cpu host - передает в VPS все возможности процессора хостовой системы. Применять с осторожностью, т.к. при переносе на другой сервер при отличии винда может ругаться.<br />
<br />
'''NB''' Для полного списка задаваемых параметров смотрим man-страницу по virt-install(1)<br />
<br />
Также подключаем флоппи-диск с драйверами для virtio. При установке система не увидит жесткий диск, на который будет устанавливаться, и нужно выбрать драйвер для диска с флопика. Там же располагаются драйвера для сетевой карты.<br />
*''Windows Server 2003 и Windows XP'' Нажимаем F6 и ставим драйвера.<br />
*''Windows 2008'' Доходим до окна разбивки дисков и выбираем "Загрузить Драйвер".<br />
<br />
=== Создание VPS без virtio ===<br />
Windows 2008 32bit на LVM:<br />
<br />
<pre><br />
/sbin/lvcreate -L 10G -n win2008 main<br />
<br />
virt-install --connect=qemu:///system -n win2008 -r 1024 --disk path=/dev/main/win2008 --cdrom=/mnt/images/windows2008.ISO --accelerate \<br />
--vnc --noautoconsole -v --network bridge:breth0 --os-type=windows --vcpus=1 --noapic --os-variant=win2k8 --arch=i686<br />
</pre><br />
ALT Linux x86_64 на LVM :<br />
<br />
<pre><br />
/sbin/lvcreate -L10G -n altlinux main<br />
<br />
virt-install --connect qemu:///system --name altlinux --ram 512 --disk path=/dev/main/altlinux --network=bridge:breth0 --vnc --os-type=linux \<br />
--os-variant=rhel6 --cdrom /mnt/images/altlinux-x86_64.iso --accelerate --noautoconsole --vcpus=1 --arch=x86_64<br />
</pre><br />
<br />
FreeBSD 8.1 на LVM :<br />
<br />
<pre><br />
/sbin/lvcreate -L20G -n freebsd main<br />
<br />
virt-install --connect qemu:///system --name freebsd --ram 512 --disk path=/dev/main/freebsd --network=bridge:breth0 --graphics vnc,password=rootSD,listen=0.0.0.0 \<br />
--os-type unix --os-variant=freebsd8 --cdrom /var/lib/vz/template/FreeBSD-8.1-RELEASE-i386-disc1.iso --accelerate --noautoconsole --vcpus=1 --arch=i686<br />
</pre><br />
После запуска команды создания VPS смотрим через netstat, какой номер порта добавился в список открытых портов, подключаемся через VNC к хардноде к этому порту (например '''vncviewer test.domain.com:5902''' ) и вводим пароль указанный в строке "'''vnc,password='''"<br />
<br />
== Удаление VPS ==<br />
<br />
Выполняем остановку и удаление VPS в KVM:<br />
<pre><br />
virsh -c qemu:///system destroy test_vps #выключить по питанию<br />
virsh -c qemu:///system undefine test_vps #удалить (конифг тоже удаляется)<br />
</pre><br />
И удаляем раздел LVM:<br />
<pre><br />
/sbin/lvremove /dev/main/test_vps<br />
</pre><br />
<br />
== Управление ресурсами ==<br />
Нужно настроить cgroups. В случае systemd это уже должно быть сделано автоматом.<br />
<br />
Проверить наличие в /etc/libvirt/qemu.xml<br />
<pre><br />
cgroup_controllers = [ "cpu", "devices", "memory", "cpuset", "blkio" ]<br />
cgroup_device_acl = [<br />
"/dev/null", "/dev/full", "/dev/zero",<br />
"/dev/random", "/dev/urandom",<br />
"/dev/ptmx", "/dev/kvm", "/dev/kqemu",<br />
"/dev/rtc", "/dev/hpet", "/dev/net/tun",<br />
]<br />
</pre><br />
<br />
Назначить нужные ресурсы через:<br />
<br />
<pre><br />
$ virsh schedinfo --set cpu_shares=1024 alt_guest<br />
$ virsh blkiotune alt_guest --weight 1024<br />
</pre><br />
<br />
==Проброс PCI-устройств внутрь домена==<br />
В /etc/libvirt/qemu.conf активируем<br />
<pre><br />
relaxed_acs_check = 1<br />
</pre><br />
Получение нужной информации о NIC<br />
<pre><br />
# lspci -vn <br />
...<br />
0e:00.0 0200: 14e4:1659 (rev 21)<br />
Subsystem: 103c:7031<br />
Physical Slot: 3<br />
Flags: fast devsel, IRQ 17<br />
Memory at fdff0000 (64-bit, non-prefetchable) [size=64K]<br />
[virtual] Expansion ROM at d0100000 [disabled] [size=64K]<br />
Capabilities: [48] Power Management version 2<br />
Capabilities: [50] Vital Product Data<br />
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+<br />
Capabilities: [d0] Express Endpoint, MSI 00<br />
Capabilities: [100] Advanced Error Reporting<br />
Capabilities: [13c] Virtual Channel <?><br />
Capabilities: [160] Device Serial Number 00-19-bb-ff-fe-ce-87-dc<br />
Capabilities: [16c] Power Budgeting <?><br />
Kernel modules: tg3<br />
<br />
# lspci -t<br />
-[0000:00]-+-00.0<br />
+-02.0-[09-12]--+-00.0-[0a-11]--+-00.0-[0b-0d]----00.0-[0c]----08.0<br />
| | +-01.0-[0e-10]----00.0<br />
| | \-02.0-[11]--<br />
| \-00.3-[12]--<br />
+-03.0-[06-08]----00.0<br />
+-04.0-[13-15]--<br />
+-05.0-[16]--<br />
+-06.0-[17-19]--<br />
+-07.0-[1a]--<br />
+-10.0<br />
+-10.1<br />
+-10.2<br />
+-11.0<br />
+-13.0<br />
+-15.0<br />
+-16.0<br />
+-1c.0-[02-03]----00.0-[03]----00.0<br />
+-1c.1-[04-05]----00.0-[05]----00.0<br />
+-1d.0<br />
+-1d.1<br />
+-1d.2<br />
+-1d.3<br />
+-1d.7<br />
+-1e.0-[01]--+-03.0<br />
| +-04.0<br />
| +-04.2<br />
| +-04.4<br />
| \-04.6<br />
+-1f.0<br />
\-1f.1<br />
</pre><br />
Отвязываем устройство от HN<br />
<pre><br />
# echo 0000:0e:00.0 > /sys/bus/pci/drivers/tg3/unbind<br />
</pre><br />
<br />
В xml домена добавляем<br />
<pre><br />
<hostdev mode='subsystem' type='pci' managed='yes'><br />
<source><br />
<address domain='0x0000' bus='0x0e' slot='0x00' function='0x0'/><br />
</source><br />
</hostdev><br />
</pre><br />
и запускаем домен<br />
<pre><br />
virsh # start PXE-server<br />
error: Failed to start domain PXE-server<br />
error: internal error Process exited while reading console log output: char device redirected to /dev/pts/4<br />
No IOMMU found. Unable to assign device "hostdev0"<br />
qemu-kvm: -device pci-assign,host=0e:00.0,id=hostdev0,configfd=30,bus=pci.0,addr=0x5: Device 'pci-assign' could not be initialized<br />
</pre><br />
No IOMMU found говорит о том, что аппаратная платформа не поддерживает виртуализацию ввода/вывода.<br />
==Проброс единственной видеокарты с GPU внутрь домена==<br />
Добавить в qemu.conf для виртуальной машины в раздел features:<br />
<pre><br />
<kvm><br />
<hidden state='on'/><br />
</kvm><br />
</pre><br />
<br />
Тип CPU изменить на passthrough (CPU в виртуальной машине будет полностью соответствовать CPU а хост-системе):<br />
<pre><br />
<cpu mode='host-passthrough' check='partial'/><br />
</pre><br />
<br />
В параметры ядра хост системы добавить:<br />
<pre><br />
nomodeset nofb video=video=vesafb:off,efifb:off intel_iommu=on iommu=pt pcie_acs_override=downstream,multifunction vfio-pci.disable_vga=1 vfio-pci.ids=<список pciid устройств, которые нужно виртуализировать><br />
</pre><br />
pcie_acs_override=downstream,multifunction нужно только в том случае, если видеокарта попадает в одну IOMMU GROUP с другими устройствами. <br />
<br />
В загрузку модулей добавить vfio-pci:<br />
<pre><br />
echo vfio-pci >>/etc/modules<br />
</pre><br />
<br />
далее, если у вас возникает такая (или подобная) ошибка:<br />
<pre><br />
vfio-pci 0000:01:00.0: BAR 3: can't reserve [mem 0xd0000000-0xd1ffffff 64bit pref]<br />
</pre><br />
<br />
То нужно посмотреть в содержимое /proc/iomem на предмет того, кто использует данную область памяти. Если это окажется BOOTFB, то рецепт простой:<br />
склонировать себе https://github.com/furkanmustafa/forcefully-remove-bootfb<br />
скомпилировать модуль ядра, предварительно установив kernel-headers-modules-std-def:<br />
<pre><br />
make -C /usr/src/<версия вашего ядра>/ M=/root/forcefully-remove-bootfb/build src=/root/forcefully-remove-bootfb modules<br />
</pre><br />
Ну и дальше действовать по инструкции с https://github.com/furkanmustafa/forcefully-remove-bootfb<br />
<br />
После освобождения памяти, можно запустить виртуальную машину, предварительно добавив в неё нужное PCI устройство (или устройства):<br />
<pre><br />
<hostdev mode='subsystem' type='pci' managed='yes'><br />
<source><br />
<address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/><br />
</source><br />
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/><br />
</hostdev><br />
<hostdev mode='subsystem' type='pci' managed='yes'><br />
<source><br />
<address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/><br />
</source><br />
<address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/><br />
</hostdev><br />
<hostdev mode='subsystem' type='pci' managed='yes'><br />
<source><br />
<address domain='0x0000' bus='0x01' slot='0x00' function='0x2'/><br />
</source><br />
<address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/><br />
</hostdev><br />
<hostdev mode='subsystem' type='pci' managed='yes'><br />
<source><br />
<address domain='0x0000' bus='0x01' slot='0x00' function='0x3'/><br />
</source><br />
<address type='pci' domain='0x0000' bus='0x00' slot='0x0d' function='0x0'/><br />
</hostdev><br />
</pre><br />
<br />
Внутри виртуальной машины переданный GPU будет вторым устройством и его можно использовать для offload расчётных операций.<br />
<br />
== Tips ==<br />
<br />
=== Сменить диск в приводе на VPS без перезагрузки ===<br />
<br />
<pre><br />
virsh -c qemu:///system attach-disk --type cdrom --mode readonly win2003 /vz/template/SW_CD_Windows_Svr_Std_2003_.ISO hdc<br />
</pre><br />
http://www.e-faux.com/references:applications:libvirt:cdrom_hotplug<br />
<br />
=== Отправка комбинаций клавиш ===<br />
<br />
Часто бывает нужно переключиться в окне kvm на вторую виртуальную консоль из графического режима.<br />
<br />
# Нажимаем '''Ctrl+Alt+2''' (именно 2, а не F2)<br />
# В консоли QEMU вводим команду: <br />
sendkey ctrl-alt-f2<br />
# Нажимаем '''Ctrl+Alt+1''' для возращения из консоли уже на вторую виртуальную консоль. Возврат в X.org: '''Alt+F7'''<br />
<br />
=== Получение файлов из образа qcow2 ===<br />
<br />
Подключение:<br />
<br />
losetup -f lxde-p5.qcow2<br />
kpartx -a /dev/loop0<br />
mount /dev/mapper/loop0p2 /mnt # монтирование второго раздела<br />
<br />
Отключение:<br />
umount /mnt<br />
kpartx -d /dev/loop0<br />
losetup -d /dev/loop0<br />
<br />
== Полезные ссылки ==<br />
* http://en.wikibooks.org/wiki/QEMU/Images<br />
* [http://umgum.com/acpi-windows2003-shutdown ACPI + MS Windows 2003 shutdown]<br />
* [http://habrahabr.ru/post/122425 Управление ресурсами через cgroups]<br />
* [http://www.opennet.ru/openforum/vsluhforumID3/109974.html#14 Что такое QEMU, KVM, libvirt и как они соотносятся]<br />
<br />
[[Категория:Руководства]]<br />
[[Категория:KVM]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=Etcnet&diff=48701Etcnet2020-06-27T07:10:20Z<p>AntonFarygin: /* Настройка VLAN */</p>
<hr />
<div>{{DISPLAYTITLE:etcnet}}<br />
{{span|font-size: 180%|Подсказки пользователю /etc/net}}<br />
<br />
{|<br />
|-valign="top"<br />
|Дополнительные страницы:<br />
* [[etcnet/qos|настройка QoS]]<br />
* [[etcnet/firewall|настройка сетевого экрана (firewall)]]<br />
Совсем быстрая настройка «с нуля»:<br />
# сконфигурируйте интерфейсы вручную, как надо;<br />
# запустите {{cmd|/etc/net/scripts/contrib/initconf write}};<br />
# проверьте содержимое подкаталогов {{path|/etc/net/ifaces/}}.<br />
|<br />
{| style="border:1px solid #AAA; background:#F9F9F9; width:280px; margin: 0 0 1em 1em; padding:.2em; text-align:center;" class=noprint<br />
|-<br />
|[[Image:Information.svg|20x20px]]Начиная с [[Branches/p5|пятой ветки]],<br /> <div style="display: inline; color: red;">в ALT Linux может использоваться и<br />[[NetworkManager/feature|NetworkManager]]</div> (используйте <tt>NM_CONTROLLED=no</tt><br />в {{path|$iface/options}}, если хотите использовать etcnet).<br />
|}<br />
|<br />
{| style="border:1px solid #AAA; background:#F9F9F9; width:155px; margin: 0 0 1em 1em; padding:.2em; float: right;" class=noprint<br />
|-<br />
|[[Image:Information.svg|20x20px]] external links:<br />
* [http://packages.altlinux.org/ru/Sisyphus/srpms/etcnet package info]<br />
* [http://git.altlinux.org/people/sbolshakov/packages/?p=etcnet.git;a=summary source git repo]<br />
|}<br />
|}<br />
<br />
<!-- Не убирайте div-ы, на них есть внешние ссылки! --><br />
<div id="quickstart"></div><br />
<br />
== Быстрый старт ==<br />
<div id="docs"></div><br />
<br />
=== Источники информации по /etc/net ===<br />
Обратите внимание, что начиная с версии 0.8.0 документация по /etc/net была собрана из комментариев, расположенных во множестве файлов, в несколько страниц руководств (man). Список всех файлов документации пакета <tt>etcnet</tt> можно получить командой:<br />
<pre>$ rpmquery -d etcnet</pre><br />
<br />
<div id="onecard"></div><br />
<br />
=== Быстрая настройка сетевого интерфейса стандарта Ethernet ===<br />
Для настройки одного сетевого интерфейса следует выполнить следующие шаги:<br />
<br />
Шаг 1: Создать каталог {{path|/etc/net/ifaces/eth0}}. Это каталог конфигурации данного интерфейса (<tt>eth0</tt>), в котором будут храниться файлы с настройками.<br />
<br />
Шаг 2: Определить, какой модуль необходим для вашей сетевой карты. Для этого можно использовать команды: <tt>lspci, lspcidrake, pciscan</tt>.<br />
<br />
Шаг 3: В каталоге конфигурации сетевого интерфейса создать файл <tt>options</tt> и записать в этот файл строку:<br />
<pre>MODULE=<имя модуля></pre> <br />
На данном этапе работу с файлом <tt>options</tt> можно завершить.<br />
<div style='padding:6px;border:1px solid red;'>Шаг 3 имеет смысл только в случае, если модули сетевых карт не грузятся автоматически другими средствами, например посредством udev. Если модуль уже загружен, параметр MODULE бесполезен.</div><br />
<br />
Шаг 4: Выяснить, какой IP-адрес должен быть назначен вашему интерфейсу. Если ваш сетевой интерфейс конфигурируется по DHCP, то в файл {{path|/etc/net/ifaces/eth0/options}} следует записать строку:<br />
<pre>BOOTPROTO=dhcp</pre><br />
и перейти к шагу 7.<br />
<br />
'''Замечание:''' В ряде случаев в файле <tt>options</tt> может понадобиться запись:<br />
<pre>DHCP_HOSTNAME=<имя машины без домена></pre><br />
Эта опция описана в странице руководства <tt>etcnet-options(5)</tt>.<br />
<br />
'''Замечание:''' В конце файла <tt>options</tt> необходимо наличие пустой строки.<br />
<br />
У сетевого интерфейса существуют два взаимосвязанных атрибута: <br />
* IP-адрес;<br />
* сетевая маска (mask). <br />
Шаг 5: Текущие значение адреса можно просмотреть командой:<br />
{{cmd|# /sbin/ip address show}} <br />
Вероятнее всего вы увидите, что интерфейс-петля lo (loopback) уже сконфигурирован с адресом 127.0.0.1/8 (что эквивалентно IP-адресу 127.0.0.1 и маске подсети 255.0.0.0). <tt>/8</tt> означает длину префикса CIDR (Classless InterDomain Routing).<br />
Для задания IP-адреса и маски подсети интерфейса <tt>eth0</tt> необходимо создать файл {{path|/etc/net/ifaces/eth0/ipv4address}}, в который следует записать IP-адрес с длиной маски, например:<br />
<pre>10.0.0.20/24</pre> <br />
<br />
Наиболее популярны маски /24 (т.е. длина префикса CIDR равная 24 эквивалентна маске сети 255.255.255.0 - это одна сеть класса C на 254 хоста) и /30. Для справки приводится таблица соответствия сетевых масок в различных нотациях.<br />
<ref><br />
{|<br />
|<br />
{| class="standard"<br />
|-<br />
!маска<br />в битах!!маска<br />точечно-<br />десятичная<br />
|-<br />
|/32||255.255.255.255<br />
|-<br />
|/31||255.255.255.254<br />
|-<br />
|/30||255.255.255.252<br />
|-<br />
|/29||255.255.255.248<br />
|-<br />
|/28||255.255.255.240<br />
|-<br />
|/27||255.255.255.224<br />
|-<br />
|/26||255.255.255.192<br />
|-<br />
|/25||255.255.255.128<br />
|-<br />
|/24||255.255.255.0<br />
|-<br />
|/23||255.255.254.0<br />
|-<br />
|/22||255.255.252.0<br />
|-<br />
|/21||255.255.248.0<br />
|-<br />
|/20||255.255.240.0<br />
|-<br />
|/19||255.255.224.0<br />
|-<br />
|/18||255.255.192.0<br />
|-<br />
|/17||255.255.128.0<br />
|}<br />
|<br />
| ||<br />
{| class="standard"<br />
|-<br />
!маска<br />в битах!!маска<br />точечно-<br />десятичная<br />
|-<br />
|/16||255.255.0.0<br />
|-<br />
|/15||255.254.0.0<br />
|-<br />
|/14||255.252.0.0<br />
|-<br />
|/13||255.248.0.0<br />
|-<br />
|/12||255.240.0.0<br />
|-<br />
|/11||255.224.0.0<br />
|-<br />
|/10||255.192.0.0<br />
|-<br />
|/9||255.128.0.0<br />
|-<br />
|/8||255.0.0.0<br />
|-<br />
|/7||254.0.0.0<br />
|-<br />
|/6||252.0.0.0<br />
|-<br />
|/5||248.0.0.0<br />
|-<br />
|/4||240.0.0.0<br />
|-<br />
|/3||224.0.0.0<br />
|-<br />
|/2||192.0.0.0<br />
|-<br />
|/1||128.0.0.0<br />
|}<br />
|}<br />
</ref><br />
<br />
Шаг 6: Выяснить адрес вашего шлюза (маршрут по умолчанию). Например, IP-адрес вашего шлюза — <tt>10.0.0.254</tt>. Тогда необходимо создать файл {{path|/etc/net/ifaces/eth0/ipv4route}}, в который записать строку:<br />
<pre>default via 10.0.0.254</pre><br />
Шаг 7: Убедиться, что всё выполнено правильно, выполнив команду:<br />
{{cmd|# service network restart}}<br />
Ваш интерфейс <tt>eth0</tt> должен быть успешно сконфигурирован. Если вы конфигурировали <tt>eth0</tt>, используя DHCP-сервер, но адрес интерфейсу не был назначен, то следует искать сообщение от DHCP-сервера в файле {{path|/var/log/messages}}.<br />
<br />
<div id="ifplugd"></div><br />
<br />
=== Настройка ifplugd ===<br />
Начиная с версии 0.7.10, /etc/net управляет ifplugd самостоятельно. Это было сделано для лучшей интеграции пакетов и для возможности следить за несколькими сетевыми интерфейсами одновременно. Для корректного использования ifplugd необходимо выполнить команду:<br />
# chkconfig ifplugd off<br />
<br />
и назначить переменную <tt>USE_IFPLUGD</tt> (USE_IFPLUGD=yes или USE_IFPLUGD=auto) в файлах <tt>options</tt> соответствующих интерфейсов (<tt>/etc/net/ifaces/<имя интерфейса>/options</tt>). Комментарий по данной переменной дан в странице руководства <tt>etcnet-options(5)</tt>.<br />
<br />
<div id="ppp"></div><br />
<br />
=== Настройка PPP-интерфейса ===<br />
Для настройки обычного модемного PPP-соединения необходимо:<br />
# Создать каталог конфигурации PPP-интерфейса, например, {{path|/etc/net/ifaces/ppp5}}. Вы можете задавать имена PPP-интерфейса вида pppN, pppNN, pppNNN и т. п., где N - любая цифра от 0 до 9;<br />
# Прочитать файл: {{path|/etc/net/ifaces/default/options-ppp}};<br />
# Создать файлы конфигурации. Вероятнее всего вам понадобятся <tt>pppconnect</tt> и <tt>pppdisconnect</tt>, чтобы <tt>pppd</tt> "знал", как дозваниваться и соединяться. Это скрипты для программы <tt>chat(8)</tt>. Кроме этого в файле <tt>pppoptions</tt> можно (часто нужно) перечислить опции <tt>pppd(8)</tt>, определяющие способ авторизации, скорость и название порта и т. п.;<br />
# Заполнить {{path|/etc/ppp/chap-secrets}} или {{path|/etc/ppp/pap-secrets}}.<br />
<br />
{{Attention|Использование опций "persist" и "maxfail 0", которые требуются pppd для непрерывных попыток восстановить интерфейс в случае проблем, может привести к невозможности загрузки системы в случае проблем с соединением. Вариант решения есть в {{altbug|23556#c1}} }}<br />
<br />
==== Настройка USB 3G-модема ====<br />
{{main|Установка и настройка 3G USB модема Huawei E1550}}<br />
<br />
<div id="ppp-pptp-pppoe"></div><br />
<br />
==== Настройка PPTP-интерфейса и PPPoE-интерфейса ====<br />
{{main|VPN (PPTP PPPoE)}}<br />
<br />
Хотя PPtP-соединения могут быть настроены и как обычные PPP-соединения, в /etc/net версии 0.7.10 для удобства пользователей была введена опция <tt>PPPTYPE</tt>. Она может принимать следующие значения:<br />
* <tt>dialup</tt> - обычный PPP-интерфейс.<br />
* <tt>pppoe</tt> - интерфейс PPPoE. Для такого интерфейса необходимо в опции <tt>HOST</tt> указывать имя Ethernet-интерфейса, через который будет производиться работа PPPoE. Побочным положительным эффектом будет то, что этот интерфейс будет при необходимости автоматически подниматься (т.е настраиваться) (см. [[#Зависимости между интерфейсами|Зависимости между интерфейсами]]).<br />
* <tt>pptp</tt> - интерфейс PPTP. Для такого интерфейса необходимо в опции <tt>PPTP_SERVER</tt> указывать имя хоста или IP-адрес PPtP-сервера, к которому будет производиться подключение. Обратите внимание, что хотя такие интерфейсы не имеют опции <tt>HOST</tt>, в большинстве случаев есть необходимость указать в опции <tt>REQUIRES</tt> интерфейс, через который будет достижим хост, указанный в <tt>PPTP_SERVER</tt>.<br />
<br />
См. также [[#Замечания о настройке VPN-подключения и туннелей|Замечания о настройке VPN-подключения и туннелей]].<br />
<br />
<div id="DNSandPPP"></div><br />
<br />
==== DNS и PPP-соединения ====<br />
<div style="display: inline; color: red;">Внимание: здесь описывается проблема, которая на самом деле была создана, а не решена — т.е. ради специфики [https://bugzilla.altlinux.org/show_bug.cgi?id=13789 kppp] была создана чётная ошибка в [https://bugzilla.altlinux.org/show_bug.cgi?id=13773 ppp-common]; последняя уже исправлена.</div><br />
<br />
Довольно долгое время существовала проблема неправильной модификации {{path|/etc/resolv.conf}} при установке PPP-соединений: [https://bugzilla.altlinux.org/show_bug.cgi?id=4249 #4249]. Сейчас она решена, но необходимо дать пояснения. Прежде всего убедитесь, что в файле {{path|/etc/resolv.conf}} есть строка:<br />
<pre># ppp temp entry</pre><br />
Если этой строки нет, то в файле не будут модифицироваться строки nameserver, если только какая-нибудь программа типа kppp это не сделает специально. Если такая строка есть, то {{path|/etc/resolv.conf}} будет модифицироваться в зависимости от значения булевой (логической) переменной RESOLV_MODS, которую необходимо задать в файле {{path|/etc/sysconfig/network}}.<br />
<br />
<div style="display: inline; color: red;">Внимание</div>: при ppp-common >= 0.4-alt1 строки <tt># ppp temp entry</tt> в файле {{path|/etc/resolv.conf}} при отсутствии PPP-соединения, поднятого какой-либо программой-«звонилкой», запущенной от администратора системы (пользователь root) — быть '''не должно'''! Если это есть, следует убрать, чтобы {{cmd|/etc/ppp/ip-up}} занимался обновлением записей про DNS в этом файле.<br />
<br />
<div id="restartreload"></div><br />
<br />
=== restart, reload и другие команды ===<br />
У сервиса <tt>network</tt> имеется ряд команд:<br />
* <tt>start</tt> - запустить все стационарные интерфейсы. hotplug-интерфейсы будут сконфигурированы при поступлении соответствующего вызова от hotplug.<br />
* <tt>startwith <имя профиля> </tt> - старт с указанным именем профиля, а не определённым автоматически.<br />
* <tt>stop</tt> - остановить все стационарные интерфейсы. hotplug-интерфейсы будут расконфигурированы при поступлении соответствующего вызова от hotplug.<br />
* <tt>stopwith <имя профиля> </tt> - стоп с указанным именем профиля, а не определённым автоматически.<br />
* <tt>restart</tt> - эквивалентно <tt>stop</tt> с последующим <tt>start</tt>, как и в большинстве других сервисов.<br />
* <tt>restartwith <имя профиля> </tt> - рестарт в контексте указанного профиля, эквивалентно <tt>stopwith <имя профиля> и startwith <имя профиля></tt>.<br />
* <tt>switchto <имя профиля> </tt> - переключение в указанный профиль, эквивалентно <tt>stop</tt> и <tt>startwith <имя профиля></tt>.<br />
* <tt>reload</tt> - семантически обозначает «актуализировать текущую конфигурацию». Для всех сконфигурированных в настоящий момент интерфейсов будет выполнена реконфигурация при наличии конфигурации.<br />
* <tt>check</tt> - автоматическая проверка конфигурационной базы.<br />
<br />
<div id="bootproto"></div><br />
<br />
=== Протоколы конфигурации адресов ===<br />
С помощью опции <tt>BOOTPROTO</tt> вы можете управлять тем, как у интерфейса будут появляться адреса и маршруты (это относится только к протоколу IPv4, так как протоколы IPv6 и IPX получают адреса только статически).<br />
* <tt>static</tt> — адреса и маршруты будут взяты из <tt>ipv4address</tt> и <tt>ipv4route</tt>.<br />
* <tt>dhcp</tt> — интерфейс будет сконфигурирован по DHCP.<br />
* <tt>ipv4ll</tt> — интерфейс будет сконфигурирован с помощью IPv4LL (link-local), ранее известному как ZCIP (zeroconf IP). Это значит, что из сети 169.254.0.0/16 будет подобран ещё не использованный адрес и назначен на интерфейс.<br />
Существует несколько комбинированных способов:<br />
* <tt>dhcp-static</tt> — если конфигурация по DHCP не удалась, конфигурировать методом static.<br />
* <tt>dhcp-ipv4ll</tt> — если конфигурация по DHCP не удалась, конфигурировать методом ipv4ll.<br />
* <tt>dhcp-ipv4ll-static</tt> — если конфигурация по DHCP не удалась, конфигурировать методом ipv4ll. Если и это не удалось, конфигурировать методом static.<br />
<br />
<div id="internals"></div><br />
<br />
=== Интеграция с systemd ===<br />
Начиная с версии 0.9.12 в etcnet добавлен Unit для включения интерфейсов по мере их появления в системе. Это позволяет избежать "гонок", когда сетевая подсистема поднимается раньше, чем ОС загружает драйвера для сетевых устройств.<br />
Для этого нужно выставить <tt>ONBOOT=no</tt> в файле options интерфейса и включить его подъём через systemd при загрузке: <tt>systemctl enable network@<имя интерфейса></tt>.<br />
<br />
== Устройство /etc/net ==<br />
<div id="generalinfo"></div><br />
<br />
=== Общие сведения ===<br />
/etc/net — это система конфигурации сети в Linux, т.е. эта система позволяет администратору Linux достаточно просто произвести настройки сети. Если же вы читаете эту страницу, то, вероятно, у вас возникли трудности с её использованием. Для решения возможных проблем полезно знать:<br />
<br />
<!--# [http://etcnet.org/ http://etcnet.org/] - сайт проекта, на котором можно найти примеры конфигурации и статьи по настройке системы. ?Рекурсия? --><br />
# /etc/net интегрирован в ALT Linux Sisyphus в виде пакетов:<br />
#* {{pkg|etcnet}} - базовые сценарии;<br />
#* {{pkg|etcnet-full}} - виртуальный пакет с зависимостями на все пакеты, которые могут использоваться сценариями /etc/net, с указанием их точных версий;<br />
#* {{pkg|etcnetconf}} - '''прототип''' конфигуратора;<br />
#* {{pkg|etcnet-defaults-desktop}} - умолчания для рабочей станции;<br />
#* {{pkg|etcnet-defaults-server}} - умолчания для сервера; <br />
# Пакеты {{pkg|etcnet}} и {{pkg|net-scripts}} — две конфликтующие реализации «подсистемы конфигурации сети» (network-config-subsystem).<br />
# При установке etcnet вместо net-scripts (или наоборот) сервис <tt>network</tt> оказывается выключенным. Это означает, что при загрузке системы сеть не будет сконфигурирована, что можно проверить командой {{cmd|chkconfig --list network}}. Для быстрого исправления проблемы можно дать команду {{cmd|chkconfig network reset}}.<br />
# etcnet '''НЕ''' импортирует автоматически настройки net-scripts. Если вы только что установили etcnet, и ваши сетевые интерфейсы всё ещё остаются сконфигурированными (несмотря на уже отсутствующий пакет net-scripts), то вы можете запустить сценарий {{cmd|/etc/net/scripts/initconf}}. Он попытается проанализировать текущее состояние интерфейсов и выведет вам результат. Никаких файлов при этом записано не будет. Если вам подходит вывод initconf, то запустите его с параметром write и он проделает то же самое, но уже с сохранением конфигурации.<br />
# Для корректной работы системы в целом необходимо, чтобы содержимое файла {{path|/etc/sysconfig/network}} было корректным.<br />
# Переменные <tt>sysctl</tt> в ОС ALT Linux конфигурируются в следующих местах<ref>{{altbug|26498}}</ref>:<br />
#* {{path|/etc/sysctl.conf}} (глобальные системные);<br />
#* {{path|/etc/sysconfig/network-scripts/sysctl.conf}} (общие сетевые в net-scripts, исходно файл не существует);<br />
#* {{path|/etc/net/sysctl.conf}} (общие сетевые в /etc/net);<br />
#* <tt>/etc/net/ifaces/*/sysctl.conf*</tt> (частные для конкретных интерфейсов или их типов в /etc/net, создаются вручную при необходимости).<br />
Скрипты etcnet используют эти файлы в указанном порядке.<br />
<br />
<div id="options.d"></div><br />
<br />
=== Организация опций /etc/net по умолчанию ===<br />
Методология /etc/net предусматривает несколько шагов наследования опций, первый из которых — загрузка опций по умолчанию. В ранних версиях это происходило из одного файла <tt>/etc/net/options</tt>, сейчас же в вашем распоряжении есть каталог {{path|/etc/net/options.d}}, из которого будут последовательно прочитаны все файлы.<br />
<br />
Иными словами, оригинальный архив etcnet содержит только файл {{path|/etc/net/options.d/00-default}}. Упаковщик etcnet, вместо того, чтобы добавить патч в какой-либо дистрибутив, просто добавляет файл с бОльшим номером, который переопределяет нужные опции.<br />
<br />
Ввиду решения различных задач, администратору системы может не подойти содержание дистрибутивного набора. В этом случае администратор может создать файл с ещё более высоким номером и определить настройки умолчания для своей системы. В результате такого подхода:<br />
# Уменьшается количество патчей (хотя их свойство "отваливаться" от пакета при его упаковке бывает полезным).<br />
# Не изменяются файлы с опциями, принадлежащие пакету. Это делает обновление пакета намного более корректным.<br />
# Можно легко увидеть, какие опции переопределяются на каждом этапе.<br />
<br />
<div id="iftab"></div><br />
<br />
=== Назначение iftab ===<br />
<br />
Начиная с дистрибутивов, основанных на ветках p5 и 5.1, переименование интерфейсов возложено на udev; см. тж. [http://lists.altlinux.org/pipermail/sisyphus/2009-June/340033.html это письмо] и <s>[https://bugzilla.altlinux.org/show_bug.cgi?id=19313 #19313]</s> и [http://packages.altlinux.org/ru/Sisyphus/srpms/wireless-tools/changelog %changelog ifrename]. В дистрибутивах на базе p8 и новее может быть полезным пакет udev-rule-generator-net, который заполняет /etc/udev/rules.d/70-persistent-net.rules. Возможно, следует отказаться от имён интерфейсов вида ethN и использовать, например, etherN ввиду того, что в новом systemd/udev официально сломан механизм переименования. Данное нововведение в ALT пока отменено; см. тж. [https://bugzilla.altlinux.org/32167 #32167].<br />
<br />
Имена сетевых интерфейсов по умолчанию, как правило, содержат их тип (eth, ppp, wifi, ipsec) и индекс: 0 - для первого созданного интерфейса, 1 - для второго и т. д. При этом соответствие автоматически назначенных имён физическим устройствам может не сохраняться.<br />
<br />
Эта особенность неудобна, когда машина с Linux имеет более одного интерфейса каждого типа. Типичными примерами являются маршрутизаторы и ноутбуки. В маршрутизаторах, как правило, используются однотипные сетевые карты и при их замене или изменении порядка на PCI-шине соответствие оказывается нарушенным. В ноутбуках используются ethernet и wifi-устройства с горячим подключением, при этом слотов и карт может быть более чем 1. В этом случае пользователь/администратор скорее всего пожелает закрепить за каждой сменной картой её конфигурацию.<br />
<br />
/etc/net при конфигурации интерфейса использует то имя, под которым он сконфигурирован, а именно имя каталога, в котором хранятся файлы конфигурации интерфейса.<br />
<br />
Для привязки сетевой карты к имени интерфейса в простых случаях можно воспользоваться файлом {{path|/etc/iftab}}, man-страница по формату которого входит в пакет <tt>ifrename</tt> (<tt>iftab(5)</tt>).<br />
<br />
Использование {{path|/etc/iftab}} удобно, поскольку позволяет сохранять традиционные имена интерфейсов (например, eth0), но этот механизм не поддерживает расширенную функциональность /etc/net (в частности, ''профили'' /etc/net).<br />
<br />
Средством, позволяющим использовать все возможности <tt>etcnet</tt>, является файл {{path|/etc/net/iftab}}, обрабатываемый не утилитой <tt>ifrename</tt>, а непосредственно <tt>etcnet</tt>. Синтаксис этого файла совпадает с синтаксисом {{path|/etc/iftab}}. Ограничением же является невозможность использовать стандартные имена интерфейсом (<tt>ethX</tt>, <tt>pppX</tt>), так как переименование интерфейсов происходит уже после конфигурации интерфейса ядром. В случае, если вам необходим {{path|/etc/net/iftab}}, имеет смысл переименовать интерфейсы, давая им либо двухзначные номера (<tt>eth00</tt>, <tt>eth01</tt>...), либо осмысленные названия (<tt>isplink</tt>, <tt>lan</tt>...)<br />
<br />
См. письмо про [http://lists.altlinux.org/pipermail/sisyphus/2009-March/337924.html важность /etc/iftab]<br />
и тж. это письмо про [http://lists.altlinux.org/pipermail/devel/2007-October/065097.html отличия etcnet и сервиса ifrename]:<br />
{{начало цитаты}} Комментарии к письмам этого треда (с некоторыми пояснениями):<br />
<br />
1. «etcnet уже научился менять местами eth0 и eth1?»<br />
<br />
Освоение этого приема обладает сомнительной пользой. Рекомендуется <br />
рассматривать eth0 как временное имя с малым сроком жизни,<br />
а для повышения комфорта пользователей Ethernet-интерфейсы предлагается<br />
называть eth00, eth01, eth02 etc.<br />
<br />
2. «Существование (номинальное) net-scripts вынуждает поддерживать<br />
ряд сервисов, которые иначе могли бы быть упразднены»<br />
<br />
Эти сервисы можно "обезвредить" (отключить) контролем CONFMETHOD<br />
из /etc/sysconfig/network. При этом зависимости на пакет etcnet<br />
не возникнет, только на network-config-subsystem. Примеры таких<br />
пакетов должны быть в Sisyphus.<br />
<br />
3. «после приведения в порядок /etc/udev/rules.d/19-udev-ifrename.rules<br />
нужности в /etc/net/iftab я не заметил»<br />
<br />
Важнейшее принципиальное отличие /etc/net/iftab от /etc/iftab —<br />
нахождение /etc/net/iftab в специальном пространстве имён. Для него<br />
действуют механизмы определения профиля и хоста конфигурации. Это,<br />
например, позволит, при необходимости, составить конфигурацию так, что срочный<br />
ремонт маршрутизатора сведётся к переносу диска (или массива)<br />
из сгоревшего шасси в запасное. Возможны и другие примеры, которые<br />
станут невозможными при помещении iftab в /etc и его прямой<br />
интерпретации.<br />
<br />
Конечно, пользователю единственного ноутбука с одним-двумя сетевыми<br />
интерфейсами такая практика — полный overkill (т.е. такая практика ему не нужна), но его никто и не<br />
заставляет видеть всю подводную часть (т.е. все тонкости работы и настройки). В этом и гибкость.{{конец цитаты}}<br />
<br />
<div id="specifaces"></div><br />
<br />
=== Интерфейсы lo, default и unknown ===<br />
Сразу после установки пакета <tt>etcnet</tt> в каталоге {{path|/etc/net/ifaces}} (в котором хранятся конфигурации интерфейсов) находятся три каталога: <br />
* lo<br />
* default<br />
* unknown<br />
<br />
Интерфейс '''lo''' — стандартная "петля" (loopback), которая должна быть во всякой Linux-системе, поэтому конфигурация для него включена по умолчанию. В остальном он ничем не отличается от любого другого интерфейса и конфигурируется точно так же файлами <tt>options</tt> и <tt>ipv4address</tt>.<br />
<br />
Интерфейс '''default''' — это не интерфейс, а специальный каталог, файлы в котором обрабатываются следующим образом:<br />
* <tt>resolv.conf</tt> — если присутствует, то копируется в {{path|/etc/resolv.conf}}.<br />
* <tt>options</tt> — файл опций, читается после опций по умолчанию.<br />
* <tt>options-<вид интерфейса></tt> — этот файл содержит опции, специфичные для данного вида интерфейсов. Некоторые из них не обязательны и позволяют использовать особенности данного вида интерфейсов, например, <tt>LINKDETECT</tt> в <tt>options-eth</tt>; другие обязательны, например, <tt>HOST</tt> в <tt>options-bri</tt>. Обратите внимание, что эти файлы не рекомендуется редактировать. Если вам нужно задать опцию для интерфейса, то, как правило, это можно сделать в файле <tt>options</tt> в конфигурационном каталоге данного интерфейса. Это облегчит процесс обновления пакета etcnet.<br />
* <tt>sysctl.conf-<вид интерфейса></tt> — файл с переменными sysctl, которые необходимо изменить. Сейчас единственный такой файл — <tt>sysctl.conf-dvb</tt>, который отключает <tt>return path filter</tt>, что всегда нужно в случае асимметричной маршрутизации.<br />
* <tt>iplink-<вид интерфейса></tt> — файл с командами iplink, специфичными для данного вида.<br />
* <tt>selectprofile</tt> — если этот файл исполняемый, то он будет вызван из сценариев <tt>ifup/ifdown</tt>, <tt>setup/shutdown</tt> для того, чтобы вернуть на стандартном выводе имя профиля, которое необходимо использовать. Это позволяет автоматически переключать профили в зависимости от каких-либо условий. В поставку включен пример сценария: {{path|/etc/net/scripts/contrib/selectprofile}}.<br />
* <tt>fw</tt> — каталог с настройками сетевого экрана по умолчанию.<br />
<br />
Интерфейс '''unknown''' — специальная конфигурация, которая будет использована в том случае, когда /etc/net просят сконфигурировать hotplug-интерфейс, для которого не существует каталога конфигурации. Это будет работать только в том случае, если включена опция <tt>ALLOW_UNKNOWN</tt>.<br />
<br />
<div id="broadcast"></div><br />
<br />
=== broadcast address===<br />
<br />
Периодически возникает вопрос: почему после старта /etc/net при запуске <tt>ifconfig</tt> можно видеть <tt>Bcast:0.0.0.0</tt>, хотя при использовании net-scripts это поле было правильным? <br />
<br />
Ответ: net-scripts оперируют адресом, маской, адресом сети и широковещательным адресом, пытаясь определить неизвестные компоненты из известных, а <tt>config-ipv4</tt> просто передаёт утилите <tt>ip</tt> содержимое файла <tt>ipv4address</tt>, не проверяя его содержание.<br />
Важно заметить, что:<br />
* Если <tt>iproute2</tt> изменит свой синтаксис, то с очень вероятно, что администратору будет необходимо редактировать только конфигурационные файлы.<br />
* Не было найдено проблем с «отсутствующим» broadcast address. Он есть в таблице маршрутизации <tt>local</tt>. <br />
* Администратор всегда может назначить адрес broadcast в файле <tt>ipv4address</tt>. Это можно сделать с помощью выражения <tt>broadcast +</tt><ref><br />
Выдержка из файла ip-cref.ps, который входит в документацию пакета iproute2:<br />
<br />
<pre><br />
* broadcast ADDRESS<br />
<br />
the broadcast address on the interface.<br />
It is possible to use the special symbols '+' and '-' instead of the broadcast address. In this case, <br />
the broadcast address is derived by setting/resetting the host bits of the interface prefix.<br />
NB. Unlike ifconfig, the ip utility does not set any broadcast address unless explicitly requested.<br />
</pre><br />
</ref>.<br />
'''Замечание:''' В версии 0.8.0 появилась опция <tt>AUTO_BROADCAST</tt> для автоматического дополнения каждой строки <tt>ipv4address</tt>.<br />
<br />
<div id="never_rmmod"></div><br />
<br />
=== Ядро 2.6 и "пропадающие" интерфейсы ===<br />
Иногда возможна ситуация: Если два интерфейса используют один и тот же модуль ядра, и у них определена опция <tt>MODULE</tt> (то есть скрипты /etc/net сами загружают и выгружают модули), то при опускании (отключении) одного интерфейса пропадает и второй интерфейс. <br />
<br />
Такая ситуация почти наверняка возникает при использовании ядра 2.6, особенностью которого являются значения счётчика ссылок (третий столбец вывода {{cmd|lsmod}}). Когда счетчик оказывается равен нулю (довольно часто), скрипты могут попытаться выгрузить модуль интерфейса, для которого запущен ifdown. И такая выгрузка происходит, несмотря на то, что другой интерфейс, использующий этот же модуль, находится в состоянии UP (т.е. он активен).<br />
<br />
Чтобы заблокировать выгрузку модулей, можно использовать булеву переменную <tt>NEVER_RMMOD</tt>. Возможно, позже это будет происходить автоматически для ядер следующих версий.<br />
<br />
<div id="removables"></div><br />
<br />
=== Cценарии конфигурации сети и hotplug-интерфейсы ===<br />
<br />
==== Cценарии конфигурации сети ====<br />
Существует несколько сценариев конфигурации сети.<br />
<br />
* Первый и самый простой — выполнение {{cmd|service network start}} при старте системы или вручную. При этом требуется только сформировать погруппные (потиповые) списки интерфейсов, подлежащих обработке, и последовательно выполнить требуемые действия. Модули ядра при этом загружаются сценариями /etc/net, при этом имена модулей берутся из опции <tt>MODULE</tt> (в этой опции можно в кавычках перечислить несколько имён и они будут последовательно загружены). Этот метод часто используется на практике и лучше всего подходит для маршрутизаторов. Преимущество метода в том, что вся необходимая информация сконцентрирована в одном месте — каталоге {{path|/etc/net}}. Если опция <tt>MODULE</tt> не определена, то будет предпринята попытка загрузки по имени интерфейса, подразумевая, что файл {{path|/etc/modules.conf}} правильно заполнен.<br />
<br />
* Второй сценарий — реакция на событие <tt>ifplugd</tt>. В предыдущих версиях существовала сложность, так как требовалась синхронная настройка сервиса <tt>ifplugd</tt>. Сейчас логика работы определена, что выражено в том, что /etc/net взяла управление <tt>ifplugd</tt> на себя. В части загрузки модуля этот сценарий не отличается от первого.<br />
<br />
* Третий сценарий — реакция на появление или исчезновение сменного устройства. Для обработки таких событий предназначены сценарии <tt>/etc/net/scripts/{ifup,ifdown}-removable</tt>, которые вызываются из сценариев пакетов hotplug и pcmcia-cs. Сложность заключается в том, что для сменных PCMCIA-карт вызовы могут дублироваться: для одного и того же события первый раз ifup-removable будет вызван из hotplug, второй — из pcmcia-cs. Кроме того, hotplug также реагирует на загрузку модулей ядра для обычных карт PCI и, более того, включает сценарии, которые пытаются загружать модули самостоятельно. В этом контексте /etc/net получает слишком много вызовов от hotplug и по умолчанию их игнорирует (<tt>USE_HOTPLUG=no</tt>).<br />
<br />
==== hotplug-интерфейсы ====<br />
Рассмотрим использование hotplug-интерфейсов. <br />
<br />
Пусть администратору необходимо настроить действительно сменную карту. После заполнения {{path|/etc/iftab}} или {{path|/etc/net/iftab}} в файле <tt>options</tt> необходимо будет задать <tt>USE_HOTPLUG=yes</tt>. После этого при получении события от hotplug /etc/net будет работать в том контексте, что модуль в загрузке и выгрузке не нуждается. <br />
<br />
Важно заметить, что '''такой интерфейс будет пропущен при обычном старте сети''', т.к. если он сменный, то единственный достоверный способ узнать, что он присутствует — получить вызов от hotplug. Из факта выполнения {{cmd|service network start}} совсем не следует, что какой-то один или несколько из сконфигурированных hotplug-интерфейсов сейчас в наличии и требуют конфигурации. Если вы хотите вручную расконфигурировать hotplug-интерфейс до его извлечения, используйте команду {{cmd|ifdown}}. Для повторной конфигурации вставьте его ещё раз.<br />
<br />
Также существует опция <tt>USE_PCMCIA</tt>. Если события для вашей карты генерирует pcmcia-cs, то вам нужно её включить. Если события генерируются только hotplug, то используйте опцию <tt>USE_HOTPLUG</tt>.<br />
<br />
<div id="eth0"></div><br />
<br />
=== Проблема стандартных имен интерфейсов (eth0 и др.)===<br />
<br />
При использовании файла {{path|/etc/net/iftab}}, то есть в случае применения сложных конфигураций, возникает следующая проблема:<br />
* При загрузке модулей имена интерфейсов принимают вид eth0, eth1, eth2… Какие именно — в общем случае контролировать нельзя.<br />
* Имя eth0 обладает наибольшей вероятностью оказаться занятым.<br />
* ifrename не может переименовать интерфейс, если целевое имя уже занято (udev использует <tt>ifrename -t</tt>, но это не работает после начальной загрузки, см. руководство к ifrename).<br />
<br />
С учётом вышеизложенного, если {{path|/etc/net/iftab}} содержит тот же набор имён интерфейсов, что уже имеется после загрузки модулей (то есть <tt>eth0</tt>/<tt>eth1</tt> и другие «стандартные» названия), то единственный случай, когда etcnet сможет без ошибок обработать такой файл — изначальное соответствие, не требующее переименования.<br />
<br />
Таким образом, при использовании {{path|/etc/net/iftab}} имеет смысл давать интерфейсам названия, отличные по виду от тех, что назначает ядро. В простых случаях лучше использовать {{path|/etc/udev/rules.d/70-persistent-net.rules}} ({{path|/etc/iftab}} до бранчей p5/5.1).<br />
<br />
<div id="advanced"></div><br />
<br />
== Расширенные возможности ==<br />
<div id="multipleIPs"></div><br />
<br />
=== Несколько IP-адресов или маршрутов на одном интерфейсе ===<br />
<br />
Вы можете помещать произвольное количество IP-адресов в файл <tt>ipv4address</tt> по одному адресу на каждой строке. То же самое относится к статическим маршрутам и файлу <tt>ipv4route</tt>.<br />
<br />
Обратите внимание, что /etc/net не анализирует содержимое этих файлов, а формирует на основе каждой строки командную строку для утилиты {{cmd|ip}}. Это означает, что вы можете помещать в этих файлах произвольные поддерживаемые {{cmd|ip}} опции и они будут обработаны. Например, в файле <tt>ipv4route</tt> можно поместить строку:<br />
<pre>10.0.1.0/24 via 10.0.0.253 metric 50 weight 5 table 100</pre><br />
<br />
<div id="requires"></div><br />
<br />
=== Зависимости между интерфейсами ===<br />
У интерфейсов:<br />
* vlan<br />
* bond <br />
* bri <br />
* teql <br />
входящих в группу зависимых физических, должна быть определена опция <tt>HOST</tt> со списком интерфейсов, необходимых для инициализации текущего интерфейса. Если хост-интерфейс не сконфигурирован при поднятии зависимого интерфейса, то это будет исправлено.<br />
<br />
Кроме обязательной для определённых интерфейсов опции <tt>HOST</tt>, может быть задана и необязательная для всех остальных интерфейсов опция <tt>REQUIRES</tt>. Интерфейсы, перечисленные в этой опции, будут считаться зависимостями текущего интерфейса. Например, по умолчанию попытка сконфигурировать интерфейс А, который зависит от Б и В, приведёт сначала к конфигурации Б и В. Аналогично, при расконфигурации Б или В сначала будет расконфигурирован А.<br />
<br />
Зависимость одного интерфейса от другого не всегда формальна. Например, в сценарии <tt>ifup-pre</tt> одного интерфейса может использоваться команда, которая потребует разрешения DNS-имени, которое может быть разрешено только с помощью <tt>resolv.conf</tt>, инсталлируемого другим интерфейсом. Или это может быть PPPoE/PPtP-интерфейс, требующий Ethernet-интерфейс для работы.<br />
<br />
Для того, чтобы избежать неожиданных сбоев в таких случаях, правильно задавайте опцию <tt>REQUIRES</tt>.<br />
<br />
<div id="postpre"></div><br />
<br />
=== Пользовательские сценарии post и pre ===<br />
Существует возможность поместить в каталог конфигурации интерфейса файлы, которые будут выполнены в определённые моменты. Для этого они должны быть исполняемыми и называться следующим образом:<br />
* <tt>ifup-pre</tt> — для выполнения перед конфигурированием интерфейса.<br />
* <tt>ifup-post</tt> — для выполнения после конфигурирования интерфейса. Например, можно запустить почтовую систему.<br />
* <tt>ifdown-pre</tt> — для выполнения перед расконфигурированием интерфейса. Например, можно остановить почтовую систему.<br />
* <tt>ifdown-post</tt> — для выполнения после расконфигурирования интерфейса.<br />
<br />
Также в версии до 0.8.0 возможно использовать следующие сценарии (они должны быть исполняемыми):<br />
* <tt>/etc/net/scripts/ifup-pre-local</tt><br />
* <tt>/etc/net/scripts/ifup-post-local</tt><br />
* <tt>/etc/net/scripts/ifdown-pre-local</tt><br />
* <tt>/etc/net/scripts/ifdown-post-local</tt><br />
<br />
Они будут вызваны для каждого интерфейса. Начиная с версии 0.8.0 эти сценарии называются так:<br />
* <tt>/etc/net/ifup-pre</tt><br />
* <tt>/etc/net/ifup-post</tt><br />
* <tt>/etc/net/ifdown-pre</tt><br />
* <tt>/etc/net/ifdown-post</tt><br />
Семантика сохранена.<br />
<br />
<div id="iplink"></div><br />
<br />
=== Управление канальными параметрами интерфейсов ===<br />
<br />
Если поместить в конфигурационный каталог интерфейса файл <tt>iplink</tt>, в котором в каждой строке будут записаны команды режима link утилиты {{cmd|ip}}, то они будут выполнены при конфигурации интерфейса. <br />
<br />
Например, если необходимо, чтобы интерфейс net1 имел MAC-адрес aa:bb:cc:dd:ee:ff и MTU 200 байт, то в файл {{path|/etc/net/ifaces/net1/iplink}} нужно поместить следующее:<br />
<pre>address aa:bb:cc:dd:ee:ff<br />
mtu 200</pre><br />
<br />
Обратите внимание, что в этом случае в {{path|/etc/net/iftab}} вам необходимо будет использовать селектор <tt>businfo</tt> или <tt>driver</tt> вместо <tt>mac</tt>.<br />
<br />
<div id="ethtool"></div><br />
<br />
=== Управление физическими параметрами интерфейсов ===<br />
Если поместить в конфигурационный каталог интерфейса файл <tt>ethtool</tt>, в котором будет строка с параметрами программы ethtool, то она будет выполнена при конфигурации интерфейса. <br />
<br />
Например, если есть необходимость, чтобы интерфейс net1 имел скорость 10Мбит/с и авто-согласование скорости было отключено, то в файл {{path|/etc/net/ifaces/net1/ethtool}} нужно поместить следующую строку:<br />
<br />
<pre>speed 10 autoneg off</pre><br />
<br />
<div id="bridge"></div><br />
<br />
=== Настройка Ethernet-моста ===<br />
<br />
Для настройки Ethernet-моста (далее — моста) есть 3 пути: <br />
# Linux bridge посредством bridge-utils<br />
# Linux bridge посредством iproute2<br />
# Openvswitch<br />
<br />
Linux bridge наиболее простая реализация. Если вам не нужно все, что умеет [http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=README;hb=HEAD openvswitch] , то можно использовать Linux bridge.<br />
<br />
==== Linux bridge посредством bridge-utils (до p8 включительно) ====<br />
Перед настройкой Ethernet-моста (далее — моста) с помощью etcnet сначала необходимо убедиться, что установлен пакет bridge-utils. Etcnet использует утилиту brctl для настройки моста, и, если утилита не установлена, то при перезапуске системы сеть станет недоступна. Если интерфейсы, входящие в состав моста, являются единственными физически подключенными и настройка моста происходит с удаленного узла через эти интерфейсы, то требуется соблюдать осторожность, т.к. эти интерфейсы перестанут быть доступны. В случае ошибки в конфигурации потребуется физический доступ к серверу. Для страховки, перед перезапуском сервиса network можно открыть ещё одну консоль и запустить там, например, команду: {{cmd|sleep 500 && reboot}}.<br />
<br />
Также имейте ввиду, что если вы подключаетесь по ssh к серверу через bridge-интерфейс (по его ip-адресу), то по умолчанию при опускании любого интерфейса-члена моста Etcnet так же опустит и сам мост (и ваше подключение пропадет). Чтобы избежать этого, установите в файле {{path|options}} того интерфейса, который нужно опускать, переменную <tt>IFDOWN_CHILDREN=no</tt>. Но учтите, что и включаться в бридж при старте тогда этот интерфейс по умолчанию не будет. <br />
<br />
Предположим, требуется настроить Ethernet-мост, пусть он будет называться <tt>br0</tt>. <br />
Тогда для его настройки необходимо завести каталог {{path|/etc/net/ifaces/br0}} и создать там файлы со следующими данными:<br />
<br />
* <tt>brctl</tt><br />
<br />
<pre> stp AUTO on </pre><br />
<br />
* <tt>ipv4address</tt>:<br />
<pre> 192.168.100.200/24 </pre><br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=bri<br />
HOST='eth0 tap0'<br />
BOOTPROTO=static </pre><br />
<br />
Содержимое файла <tt>brctl</tt> передаётся утилите brctl. <tt>AUTO</tt> означает, что скрипт {{cmd|setup-bri}} самостоятельно определит имя bridge-интерфейса (см. файл {{path|/usr/share/doc/etcnet-*/README.bridge}}). Если же в вашей сети этот мост один и рассылать пакеты протокола STP не нужно, тогда файл brctl с указанной опцией не нужен. По умолчанию [http://xgu.ru/wiki/man:brctl#Spanning_Tree_Protocol_.28.D0.9F.D1.80.D0.BE.D1.82.D0.BE.D0.BA.D0.BE.D0.BB_.D0.BE.D1.81.D1.82.D0.BE.D0.B2.D0.BD.D0.BE.D0.B3.D0.BE_.D0.B4.D0.B5.D1.80.D0.B5.D0.B2.D0.B0.29 STP выключен].<br />
<br />
IP-адрес для интерфейса, как обычно, будет взят из <tt>ipv4address</tt>.<br />
<br />
В опции <tt>HOST</tt> файла <tt>options</tt> нужно указать те интерфейсы, которые будут входить в мост. Если в него будут входить интерфейсы, которые до этого имели IP-адрес (например, eth0), то этот адрес должен быть удалён (например, можно закомментировать содержимое файла {{path|ifaces/eth0/ipv4address}}).<br />
<br />
При старте сети сначала поднимаются интерфейсы, входящие в мост, затем сам мост (автоматически). Для назначения адреса мосту можно также использовать DHCP (<tt>BOOTPROTO=dhcp</tt>). Но при этом важно обратить внимание на параметр <tt>forwarding delay</tt> (man brctl / setfd), так как интерфейс, подключенный к мосту, не сразу входит в режим передачи пакетов, и это может вызвать dhcp таймаут. Версии etcnet в дистрибутивах ALT Linux Server 4 и Desktop 4.1 (0.9.7-alt0.M40/M41) имеют эту недоработку, которая исправлена только в версии 0.9.9-alt1. <br />
Документацию по настройке моста с вопросами и ответами (перевод) можно найти на http://xgu.ru/wiki/Linux_Bridge, а его оригинал доступен на http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge.<br />
<br />
Внимание: инструкция на xgu.ru чуть устарела. Команда<br />
<pre>$ brctl setfd br0 0</pre><br />
не выключает задержку, а лишь приводит к величине задержки по умолчанию (15 или даже 30 секунд). Можно попробовать задать задержку в 1сек для уменьшения времени инициализации сети.<br />
<br />
С пакетом etcnet поставляются примеры конфигурации. Один из них показывает, как из двух ethernet-интерфейсов port0 и port1 можно собрать мост bridge (каталог документации examples/Ethernet-bridge-GRE/).<br />
<br />
Безотносительно к etcnet, следует иметь ввиду проблему, связанную с NAT: <s>[http://bugzilla.kernel.org/show_bug.cgi?id=13079 http://bugzilla.kernel.org/show_bug.cgi?id=13079]</s><br />
<br />
==== Linux bridge посредством iproute2 (начиная с p9) ====<br />
Надо описать, пока только ссылка на дискуссию в момент перехода: https://lists.altlinux.org/pipermail/devel/2018-October/205769.html<br />
==== openvswitch ====<br />
Как настраивать openvswitch, описано [[Etcnet/openvswitch|тут]].<br />
<br />
<div id="vlan"></div><br />
<br />
=== Настройка VLAN ===<br />
<br />
Для настройки 802.1q VLAN (например, id 4094 на eth1) следует, создав каталог {{path|ifaces/eth1.4094}}, поместить в него файлы со следующим содержимым:<br />
<br />
* <tt>ipv4address</tt>:<br />
<pre>192.168.100.200/24</pre><br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=vlan<br />
HOST=eth1<br />
VID=4094<br />
BOOTPROTO=static</pre><br />
<br />
Содержимое переменных <tt>HOST</tt> и <tt>VID</tt> будет передано утилите <tt>vconfig</tt>; использование файла <tt>vlantab</tt> необязательно (и не рекомендуется по причине невозможности использовать ifup для отдельного интерфейса). Пример конфигурации можно найти в каталоге examples/VLAN-without-vlantab/ документации etcnet.<br />
<br />
Следует обратить внимание, что 4094 является верхней допустимой границей идентификатора валидного VLAN, а [http://www.candelatech.com/pipermail/vlan/2004-November/000128.html 4095 используется технически в процессе отбрасывания трафика по неверным VLAN]. (следует отметить, что это не ограничение Linux: [http://en.wikipedia.org/wiki/802.1Q в стандарте под VID отведено 12 бит])<br />
<br />
Обратите внимание, что '''ISC DHCP сервер на интерфейсе VLAN''', скорее всего, у вас не будет работать, пока вы не добавите опцию VLAN_REORDER_HDR=on в настройки vlan интерфейса. Эта опция переведёт vlan интерфейс в режим работы, в котором пакеты на интерфейсе не будут содержать тэгов vlan и их сможет получить dhcpd.<br />
<br />
<br />
'''Для настройки Q-in-Q интерфейса''', например, eth1.123.513 (дважды тегированный трафик: внешняя метка -- 123, внутренняя -- 513) следует файл <tt>options</tt> в каталоге {{path|ifaces/eth1.123.513}} заполнить следующим образом:<br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=vlan<br />
HOST=eth1.123 # "родительский" интерфейс; может называться иначе<br />
VID=513<br />
VLAN_REORDER_HDR=0<br />
BOOTPROTO=static</pre><br />
<br />
Родительский интерфейс должен быть сконфигурирован (можно с или без <tt>BOOTPROTO</tt>, с или без <tt>ipv4address</tt> и т.п.).<br />
<br />
Таким образом, можно каскадировать интерфейсы "как угодно глубоко" (Q-in-Q-in-Q-in-Q....). Необходимо только учитывать, что длина имени интерфейса ограничена (16-ю символами).<br />
<br />
<div id="bonding"></div><br />
<br />
=== Настройка bonding ===<br />
Bonding - объединение нескольких физических сетевых интерфейсов в один логический, для достижения отказоустойчивости, увеличения скорости и балансировки нагрузки. Возможны несколько режимов работы и много параметров для настроек, подробнее см. http://www.linuxfoundation.org/collaborate/workgroups/networking/bonding<br />
<br />
Для создания агрегированного bond-интерфейса средствами etcnet создаем, как обычно, директорию для интерфейса (например, <tt>bond0</tt>) с <tt>options</tt>, <tt>ipv4address</tt>, и прочими необходимыми файлами. В <tt>options</tt> указываем тип интерфейса <tt>bond</tt>, перечисляем в переменной <tt>HOST</tt> родительские интерфейсы, которые будут входить в наш агрегированный интерфейс, указываем в переменной <tt>BONDMODE</tt> режим (по умолчанию 0), и опции для модуля ядра <tt>bonding</tt> в <tt>BONDOPTIONS</tt>.<br><br />
Так, для создания LACP-агрегированного канала (802.3ad), у нас получится такой <tt>options</tt>:<br />
TYPE=bond<br />
ONBOOT=yes<br />
BOOTPROTO=static<br />
HOST="eth0 eth1"<br />
BONDMODE=4<br />
BONDOPTIONS="miimon=100 lacp_rate=1"<br />
Интерфейсы eth0 и eth1 должны тоже быть описаны в etcnet.<br />
<br />
Как правило, для создания агрегированного интерфейса требуется, чтобы входящие в него физические интерфейсы имели одинаковые характеристики - скорость, дуплекс, etc.<br />
<br />
Не стоит указывать режим в переменной <tt>BONDOPTIONS</tt>: попытки изменить какие-то режимоспецифичные параметры до установки правильного режима могут быть отвергнуты. Поэтому, первым делом нужно установить необходимый режим, указав его для этого в <tt>BONDMODE</tt>.<br />
<br />
Информацию о получившемся агрегированном интерфейсе можно посмотреть в {{path|/proc/net/bonding/bond0}}<br />
<br />
<div id="tun/tap"></div><br />
<br />
=== Настройка tun/tap интерфейса ===<br />
<br />
Etcnet поддерживает простое создание интерфейсов типа tun/tap. Это виртуальный тип интерфейсов для передачи пакетов между ядром и программами, который не передает данных через физические устройства.<br />
'''tun''' — это интерфейс типа point-to-point, работающий с кадрами IP.<br />
'''tap''' — интерфейс типа ethernet, работающий с кадрами ethernet.<br />
<br />
Потребуется использование утилиты tunctl, находящейся в одноименном пакете.<br />
Пусть требуется создать и настроить tun/tap интерфейс, например, с именем tap0. Для этого необходимо:<br />
* создать каталог интерфейса:<br />
<br />
/etc/net/ifaces/tap0<br />
<br />
* создать в каталоге интерфейса {{path|/etc/net/ifaces/tap0}} файл настройки <tt>options</tt> со следующим содержанием:<br />
<br />
TYPE=tuntap<br />
TUNTAP_USER=combr<br />
<br />
<br />
<tt>TUNTAP_USER</tt> — это аккаунт или цифровой id пользователя, которому будут даны права на использование интерфейса tap0 (устройство /dev/net/tun).<br />
Этот параметр будет передан утилите <tt>tunctl</tt> как аргумент опции <tt>-u</tt> (см. руководство на tunctl).<br />
С версии ядра 2.6.18 произошли изменения в управлении этим типом интерфейсов, потребовавшие<br />
обязательного применения <tt>tunctl</tt> для разрешения доступа обычных<br />
пользователей к tap-интерфейсам. В предыдущих версиях любой<br />
пользователь, имеющий доступ к <tt>/dev/net/tun</tt>, мог создать любое<br />
количество сетевых интерфейсов с произвольными именами. Начиная с<br />
2.6.18, для создания интерфейса через <tt>/dev/net/tun</tt> требуется<br />
<tt>CAP_NET_ADMIN</tt> (обычно эту привилегию имеет только root), а обычный<br />
пользователь, имеющий доступ к <tt>/dev/net/tun</tt>, может только использовать<br />
уже созданные интерфейсы, к которым разрешён доступ для его uid.<br />
<br />
=== Настройка интерфейса типа OpenVPN ===<br />
<br />
Настройка OpenVPN может быть произведена большим количеством способов и вариантов с разными целями, и достойна отдельной статьи. Здесь, для начала, будет описан вариант openvpn-сервера в режиме bridging.<br />
Для этого надо проделать подготовку:<br />
* создать ключи [http://openvpn.net/index.php/open-source/documentation/howto.html#pki англ. HOWTO]<br />
(до версии 2.3 утилиты easy-rsa шли в составе дистрибутива openvpn, потом отдельно).<br />
* настроить [http://www.altlinux.org/Etcnet#.D0.9D.D0.B0.D1.81.D1.82.D1.80.D0.BE.D0.B9.D0.BA.D0.B0_Ethernet-.D0.BC.D0.BE.D1.81.D1.82.D0.B0 мост] (между внутренним физическим интерфейсом и интерфейсом tap, который будет использовать openvpn) "средствами системы".<br />
<br />
Далее надо сделать так (скрипты etcnet по умолчанию ожидают это):<br />
* создать каталог интерфейса:<br />
<br />
/etc/net/ifaces/tap0<br />
<br />
* создать в каталоге интерфейса {{path|/etc/net/ifaces/tap0}} файл настройки <tt>options</tt> со следующим содержанием:<br />
<br />
TYPE=ovpn<br />
<br />
(необязательно, но желательно указать '''REQUIRES'''=''<имя ethernet-интерфейса>'', с которым будет связан туннель)<br />
<br />
* Конфигурационный файл для openvpn (из примера в пакете openvpn-docs - такой, как /usr/share/doc/openvpn-docs-2.2.2/sample-config-files/server.conf) надо переделать, удалив параметры, которые etcnet подставляет самостоятельно при запуске:<br />
<br />
dev<br />
ca<br />
cert<br />
key<br />
persist-key<br />
persist-tun<br />
<br />
И обязательно добавив параметры, которых по умолчанию в конфиге-примере нет:<br />
<br />
tls-server<br />
script-security 2<br />
<br />
Параметр script-security был введен начиная с версии 2.1_rc9. Поскольку etcnet запускает openvpn так, что в процессе тот запускает скрипт scripts/openvpn.action, который считается "пользовательским", то для этого значение должно быть 2.<br />
<br />
* скопировать в каталог интерфейса ключи и измененный конфиг-файл openvpn.<br />
Файлы надо переименовать (ключи - после easy-rsa) таким образом:<br />
{| align="center" border="1"<br />
|ключ easy-rsa<br />
|ключ etcnet-ovpn<br />
|-<br />
|ca.crt <br />
|ovpnca<br />
|-<br />
|server.crt<br />
|ovpncrt<br />
|-<br />
|server.key<br />
|ovpnkey<br />
|-<br />
|server.conf<br />
|ovpnoptions<br />
|}<br />
<br />
<br />
<br />
После всего этого можно попробовать запустить интерфейс: ifup tun0 (или весь мост, например ifup br0). Но если, например, openvpn считает ошибочной какую-либо опцию, то он молча выйдет с кодом выхода 1, и скрипт ifup ничего не напишет (в логе так же не будет попытки запуска openvpn). Потребуется отладка (например, можно запустить openvpn вручную без параметра --daemon и со всеми параметрами, которые подставил etcnet).<br />
<br />
<div id="wireguard"></div><br />
<br />
=== Настройка WireGuard VPN туннеля ===<br />
<br />
WireGuard используется для быстрого создания VPN туннелей, является более легким и безопасным чем OpenVPN. Для использования wireguard необходимо '''ядро версии 3.10+''' и установленные модули ядра '''wireguard-std-def''', '''wireguard-un-def'''. Для настройки интерфейса необходимо:<br />
* создать каталог интерфейса {{path|/etc/net/ifaces/wg0}}<br />
* добавить файл с конфигурацией {{path|/etc/net/ifaces/wg0/options}}<br />
<source lang='ini'><br />
TYPE=wg<br />
LISTENPORT=51820<br />
</source><br />
* добавить файл с поддерживающимися wireguard опциями пиров {{path|/etc/net/ifaces/wg0/options}} (одна строка - один пир)<br />
<source lang='bash'><br />
peer PUBLICPEERKEY allowed-ips IFACESSUBNET endpoint PUBLICIP:ALLOWPORT<br />
</source><br />
* добавить файл содержащий локальные и удаленные ip адреса {{path|/etc/net/ifaces/wg0/ipv4address}}<br />
первым делом указывается выделенная интерфейсу локальная подсеть, после чего указываются соответствия локального и удаленного ip адресов, каждое соответствие с новой строки<br />
<source lang='bash'><br />
10.1.0.0/16<br />
10.1.0.1 10.2.0.1<br />
</source><br />
* добавить файл содержащий приватный ключ {{path|/etc/net/ifaces/wg0/privatekey}}<br />
Ключи могут быть созданы стандартной утилитой wireguard:<br />
<source lang='bash'><br />
$ umask 077<br />
$ wg genkey > privatekey<br />
$ wg pubkey < privatekey > publickey<br />
</source><br />
<br />
<div id="iptun"></div><br />
<br />
=== Настройка и использование IP-туннелей ===<br />
<br />
IP-туннели — средство, позволяющее улучшить IP-сети. Поддерживаются IP-туннели трёх видов: <br />
* IPIP<br />
* GRE<br />
* SIT <br />
* VTI<br />
<br />
Прежде всего следует определить необходимый вид туннеля для решаемой задачи. <br />
<br />
* Туннели '''IPIP''' — самые простые.<br />
<br />
* Туннели '''GRE''' (general incapsulation) обычно используются в маршрутизаторах Cisco. По туннелям этого типа могут передаваться broadcast и multicast пакеты. Кроме того, эти туннели поддерживают контрольные суммы и контроль упорядоченности пакетов. Также GRE-туннели обладают опциональным атрибутом key в виде произвольного 4-байтового числа, который позволяет конфигурировать несколько GRE туннелей между одной парой IP-адресов несущей сети (в отличие от IPIP-туннелей, с которыми это невозможно).<br />
<br />
* Туннели '''SIT''' предназначены для транспортировки пакетов IPv6 через сети IPv4.<br />
<br />
* Туннели '''VTI''' используются для построения IPsec туннелей. Работают используя один из демонов, strongswan или libreswan.<br />
<br />
Тип туннеля определяется опцией <tt>TUNTYPE (ipip, gre, sit, vti)</tt>. По умолчанию <tt>TUNTYPE=ipip</tt>. Кроме типа туннеля для конфигурации всегда требуется адрес удалённого хоста и почти всегда — локальный адрес. Эти адреса определяются опциями <tt>TUNREMOTE</tt> и <tt>TUNLOCAL</tt> соответственно. В некоторых случаях локальный адрес можно не указывать. В этом случае опция <tt>TUNLOCAL</tt> всё равно обязательна, но принимает значение <tt>any</tt>. Не забудьте назначить туннельному интерфейсу адреса и маршруты в соответствующих файлах.<br />
<br />
Пример: Конфигурация GRE-туннеля между 10.0.1.2 и 10.0.2.3 с двумя ключами для исходящих и входящих пакетов, проверкой очерёдности пакетов, TTL 8 и вычислением контрольных сумм. Туннель должен использовать только интерфейс gw1. Пусть имя создаваемого туннеля будет <tt>mytunnel</tt>.<br />
<br />
Тогда необходимо сделать следующие операции:<br />
* Создать каталог туннеля: {{path|/etc/net/ifaces/mytunnel}}<br />
<br />
* Создать в каталоге туннеля файл настроек <tt>options</tt>: {{path|/etc/net/ifaces/mytunnel/options}}<br />
<br />
* Отредактировать файл настроек <tt>options</tt>: <br />
<br />
<source lang="ini"><br />
TYPE=iptun<br />
TUNTYPE=gre<br />
TUNLOCAL=10.0.1.2<br />
TUNREMOTE=10.0.2.3<br />
TUNTTL=8<br />
HOST=gw1<br />
TUNOPTIONS='ttl 64 seq ikey 2020 okey 2030 csum'<br />
</source><br />
<br />
<div id="vpn"></div><br />
<br />
Про <tt>ttl 64</tt>. Если параметр ttl не задан, значение берётся из инкапсулируемого пакета (это надо проверить). В некоторых случаях ttl может получиться слишком мал (например, Quagga формирует OSPF-пакеты с TTL 1).<br />
<br />
Стоит помнить, что имена <tt>tunl0, gre0 и sit0</tt> являются зарезервированными в iproute2 ("base devices") и имеют особое поведение: http://www.liveinternet.ru/users/stasikos/post71435454/<br />
<br />
Процедура создания vti интерфейса стандартна, однако, предварительно необходимо установить и настроить один из демонов (strongswan, libreswan), о том, как это сделать можно найти в соответствующей документации. После чего необходимо создать каталог интерфейса (к примеру он будет называться vti0) {{path|/etc/net/ifaces/vti0}}, и добавить в него файл настроек туннеля {{path|/etc/net/ifaces/vti0/options}}, куда нужно прописать необходимую конфигурацию:<br />
<source lang='ini'><br />
TYPE=iptun<br />
TUNTYPE=vti<br />
TUNLOCAL=119.81.184.173<br />
TUNREMOTE=119.81.177.236<br />
TUNOPTIONS='key 42'<br />
</source><br />
Параметр key должен соответствовать параметру mark, указанному при настройке strongswan/libreswan.<br />
<br />
=== Настройка IPv6 ===<br />
==== Отключение IPv6 ====<br />
<br />
* '''Вариант 1'''<br />
Чтобы отключить IPv6 на всех сетевых интерфейсах в работающей системе с загруженным модулем ipv6, нужно изменить значение параметра ядра net.ipv6.conf.all.disable_ipv6, где 'all' подразумевает все интерфейсы, а net.ipv6.conf.eth0.disable_ipv6 -- отключение протокола IPv6 только на интерфейсе eth0 и т.д.<br />
<pre><br />
sysctl net.ipv6.conf.all.disable_ipv6=1<br />
</pre><br />
Также можно добавить данную директиву в {{path|/etc/sysctl.conf}}:<br />
<source lang="bash"><br />
echo 'net.ipv6.conf.all.disable_ipv6 = 1' >> /etc/sysctl.conf<br />
sysctl -f<br />
</source><br />
<br />
* '''Вариант 2'''<br />
Добавить параметр в командную строку загрузки ядра. Для GRUB2 нужно изменить параметры загрузки ядра в файле {{path|/etc/sysconfig/grub2}}, изменив переменную GRUB_CMDLINE_LINUX_DEFAULT или GRUB_CMDLINE_LINUX<br />
<pre><br />
...<br />
GRUB_CMDLINE_LINUX='failsafe vga=normal ipv6.disable=1'<br />
...<br />
</pre><br />
и обновив конфигурационный файл grub<br />
<source lang="bash"><br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
</source><br />
<br />
* '''Вариант 3'''<br />
<source lang="bash"><br />
echo 'options ipv6 disable=1' >> /etc/modprobe.d/options-local.conf<br />
</source><br />
Вступит в силу только после перезагрузки.<br />
<br />
==== Включение IPv6 ====<br />
<br />
* Во-первых, следует убедиться, что не применяется какой-либо вариант совета из предыдущего пункта. <br />
* Во-вторых, следует проверить значение CONFIG_IPV6 в etcnet. Переменная может быть описана в /etc/net/options.d/*, /etc/net/ifaces/default/*, /etc/net/ifaces/*/options. Наибольший приоритет у описания в ifaces/*/options.<br />
<br />
'''Замечание:''' В etcnet-0.9.10-alt5, в /etc/net/ifaces/default/options содержится CONFIG_IPV6=no<br />
<br />
==== Туннели 6-to-4 ====<br />
<br />
Требуется:<br />
* ядро с поддержкой IPv6 (CONFIG_IPV6 в /boot/config-*; наличие модуля ipv6);<br />
* ядро с поддержкой tun (CONFIG_TUN в /boot/config-*; наличие модуля tun);<br />
* доступность узла 192.88.99.1 - через него маршрутизируется трафик в сети IPv6.<br />
<br />
Далее в {{path|/etc/net/ifaces}} создаётся каталог с названием, например,<br />
tun6to4. В нём создаются файлы:<br />
iplink : <pre><br />
mtu 1472 </pre><br />
<br />
ipv6address : <pre><br />
# first six octets: ipv6calc --ipv4_to_6to4addr $TUNLOCAL<br />
2002:c000:201::1/16 </pre><br />
<br />
ipv6route : <pre><br />
2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 </pre><br />
<br />
options : <pre><br />
TYPE=iptun<br />
TUNTYPE=sit<br />
TUNLOCAL=192.0.2.1<br />
TUNREMOTE=any<br />
TUNOPTIONS="ttl 64"<br />
DONT_FLUSH=yes<br />
CONFIG_IPV6=yes </pre><br />
<br />
Адрес TUNLOCAL в options - имеющийся внешний IPv4, в ipv6address<br />
адрес IPv6 выбирается исходя из него же.<br />
<br />
В настройках iptables должно быть разрешение на приём пакетов протокола<br />
ipv6 на внешний адрес IPv4.<br />
<br />
Далее поднимается интерфейс tun6to4, ну и проверяется доступность <br />
чего-либо в IPv6.<br />
<br />
Туннели 6to4 - это RFC 3964.<br />
Miredo - это реализация протокола Teredo, RFC 4380.<br />
6to4 требует наличия внешнего адреса IPv4.<br />
Teredo не требует наличия внешнего адреса, и может работать через NAT.<br />
Через Teredo не получится получить симметричное соединение, т.е. доступ<br />
в IPv6 будет односторонний, на компьютер в общем случае извне<br />
подключиться не получится.<br />
И Teredo позволяет получить только адрес /32, т.е. для подключения сетей<br />
он мало пригоден.<br />
<br />
этот раздел скопирован из письма рассылки community (c) Nikolay A. Fetisov 8 сентября 2011 12:03:30<br />
<br />
=== Замечания о настройке VPN-подключения и туннелей ===<br />
<br />
Часто при настройке VPN-подключения (под которыми здесь будут подразумеваться все туннельные подключения, то есть подключения поверх IP) не учитывают, что использование опции pppd '<tt>defaultroute</tt>' маршрут по-умолчанию после подключения будет изменен. При этом, если VPN-сервер находится в другой, отличной от клиента, сети, то после подключения (и изменения маршрута по-умолчанию) VPN-сервер становится недоступным, следовательно, недоступными становятся все внешние адреса, и подключение, как правило, прекращается по тайм-ауту.<br />
<br />
Решением, как обычно (и рекомендовано), служит указание ''отдельного'' маршрута на VPN-сервер (или его сеть). Для этого необходимо прописать (в примере - для маршрута через eth0) в {{path|/etc/net/ifaces/eth0/ipv4route}} строку вида:<br />
<br />
10.0.1.0/24 via 10.0.0.1<br />
<br />
В данном примере подразумевается, что VPN-сервер находится в сети 10.0.1.0/24 (например, имеет адрес 10.0.1.1), клиент — в сети 10.0.0.0/24 (и имеет адрес, например, 10.0.0.10), а маршрутизатор имеет адрес 10.0.0.1.<br />
<br />
Теперь, при использовании опции '<tt>defaulroute</tt>' для pppd (которая указывает, что необходимо изменить на вновь созданное подключение маршрут по-умолчанию), даже после замены маршрута по-умолчанию новым, сеть 10.0.1.0, в которой в нашем примере и находится VPN-сервер, останется доступной.<br />
<br />
Как более точечный вариант (применяется в alterator-net-pptp 0.5.x) можно использовать скрипты {{cmd|ifup-pre}} и {{cmd|ifdown-post}} в каталоге конфигурируемого PPP-интерфейса.<br />
<br />
Наример:<br />
<source lang="bash"><br />
#!/bin/sh<br />
# sample /etc/net/ifaces/ppp0/ifup-pre; replace variables yourself<br />
ip route add VPN_SERVER via DEF_GW<br />
</source><br />
<source lang="bash"><br />
#!/bin/sh<br />
# sample /etc/net/ifaces/ppp0/ifdown-post; replace variables yourself<br />
ip route del VPN_SERVER via DEF_GW<br />
</source><br />
<br />
Не забудьте подставить нужные IP-адреса вместо VPN_SERVER и DEF_GW (не сеть, где VPN-сервер, а ее /32 префикс CIDR) и выполнить команду: {{cmd|chmod +x ifup-pre ifdown-post}}<br />
<br />
<div id="iprule"></div><br />
<br />
=== Сложная маршрутизация (или несколько таблиц маршрутизации) ===<br />
<br />
Под «сложной маршрутизацией» подразумевается наличие нескольких таблиц маршрутизации. Для их использования необходимо сконфигурировать правила ядра. В правилах по умолчанию можно увидеть следующее:<br />
<br />
<pre># ip rule show<br />
0: from all lookup local <br />
32766: from all lookup main <br />
32767: from all lookup default</pre><br />
<br />
Для настройки «сложной маршрутизациии» необходимо выполнить следующие операции:<br />
<br />
Шаг 1 : Сами таблицы определены в файле {{path|/etc/iproute2/rt_tables}}. Для создания конфигурации «сложной маршрутизации» необходимо вначале «создать» нужные таблицы в этом файле (если вы хотите использовать имена таблиц, а не числа).<br />
<br />
Шаг 2 : Необходимо заполнить таблицы. В конфигурационном каталоге интерфейса в файле <tt>ipv4route</tt> необходимо добавить маршрутные записи, не забывая указать <tt>table XX</tt>. Важно учитывать, что если строка начинается с режима ip route (add, del, replace, append, change), то по умолчанию будет использован режим <tt>DEFAULT_IPV4ROUTE_CMD</tt> (<tt>append</tt>).<br />
<br />
Шаг 3 : Определить правила в файле <tt>ipv4rule</tt>. Здесь есть особенности, связанные автоматической заменой/добавлением параметров. Если строка не начинается с операции del или add, то нужный режим будет подставлен автоматически. Это подходит для тех случаев, когда вам при "поднятии" интерфейса необходимо добавить правила, а при "опускании" — удалить. Возможность указывать del или add реализована для обратных случаев: если при "поднятии" интерфейса вам необходимо удалить правила, а при "опускании" — добавить. В этом случае add и del будут в нужный момент автоматически заменены на del и add.<br />
<br />
Пример такой конфигурации входит в /etc/net 0.7.12: (каталог документации examples/routing-LARTC-1/)<br />
<br />
=== Простое переключение маршрутов ===<br />
<br />
Пусть имеется eth-интерфейс, который используется постоянно, и настроен маршрут по умолчанию.<br />
Часто бывает необходимость настроить второй маршрут по умолчанию через беспроводной интерфейс,<br />
но с меньшей метрикой, чем у проводного интерфейса.<br />
В этом случае при поднятии WI-FI маршрут по умолчанию «развернется» в нужную сторону.<br />
<br />
Например:<br />
<br />
Для eth-интерфейса файл настроек {{path|/etc/net/ifaces/eth0/ipv4route}} будет таким:<br />
<pre>default via 192.168.3.254 metric 10</pre><br />
а для WI-FI-интерфейса файл настроек {{path|/etc/net/ifaces/ath0/ipv4route}} таким:<br />
<pre>default via 192.168.123.1 metric 5</pre><br />
<br />
<div id="wireless"></div><br />
=== Беспроводный Ethernet (или настройка WI-FI) ===<br />
Большинство беспроводных интерфейсов сейчас представлено системе как интерфейсы Ethernet. Соответственно беспроводный интерфейс будет иметь <b>TYPE=eth</b> (<s>[https://bugzilla.altlinux.org/show_bug.cgi?id=6283 #6283]</s>). Чтобы интерфейс нормально функционировал, необходимо кроме загрузки модуля с параметрами, воспользоваться утилитами {{cmd|iwconfig}} из пакета wireless-tools или {{cmd|wpa_supplicant}} из такого же пакета. Вместо того, чтобы запускать их вручную, можно поместить в конфигурационный каталог интерфейса файл <tt>iwconfig</tt> с командами iwconfig или файл <tt>wpa_supplicant.conf</tt> с конфигурацией wpa_supplicant. Они будут использованы автоматически.<br />
<br />
Пример [http://hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wireless.html конфигурации] (совместно с <tt>[http://ndiswrapper.sourceforge.net/ ndiswrapper]</tt>):<br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/options}}<br />
<pre>TYPE=eth<br />
MODULE=ndiswrapper<br />
NEVER_RMMOD=yes<br />
BOOTPROTO=dhcp<br />
USE_HOTPLUG=no<br />
ONBOOT=no</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/iwconfig}}<br />
<pre>essid default<br />
#key bababababa</pre><br />
<br />
<br />
Еще один пример использования etcnet для настройки беспроводной сети:<br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/options}}<br />
<pre>TYPE=eth<br />
USE_HOTPLUG=NO<br />
BOOTPROTO=static<br />
module=ipw2200<br />
WPA_DRIVER=wext</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/iwconfig}}<br />
<pre>essid homenet<br />
mode 1<br />
ap 00:11:D8:22:AD:0D<br />
channel 3<br />
rate 11M</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}}<br />
<pre>ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=0<br />
eapol_version=1<br />
ap_scan=1<br />
fast_reauth=1<br />
<br />
network={<br />
ssid="homenet"<br />
scan_ssid=1<br />
key_mgmt=WPA-PSK<br />
psk="this is my mega secret password string to wpa supplicant"<br />
}</pre><br />
<br />
Если вы хотите воспользоваться WPS:<br />
# создайте {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}} следующего вида:<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
update_config=1<br />
</pre><br />
# поднимите беспроводной интерфейс (ifup wlan0)<br />
# запустите wpa_cli и дайте команды wps_pbc (после этого нужно соответственно нажать кнопку WPS на точке доступа и подождать окончания обмена данными) и save_config (для записи конфигурации в <tt>wpa_supplicant.conf</tt>). Или же можно воспользоваться утилитой wpa_gui, отображающей процесс более наглядно.<br />
<br />
Пример файла {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}} при подключении к сети, использующей протокол WPA2-PSK(AES)<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=0<br />
eapol_version=1<br />
ap_scan=1<br />
fast_reauth=1<br />
<br />
network={<br />
ssid="home-lg"<br />
bssid=00:1B:11:87:C7:EA<br />
proto=RSN<br />
key_mgmt=WPA-PSK<br />
pairwise=CCMP TKIP<br />
group=CCMP TKIP<br />
psk="this is my mega secret password string to wpa supplicant"<br />
priority=2<br />
}<br />
</pre><br />
<br />
<div id="infiniband"></div><br />
<br />
=== Настройка Infiniband ===<br />
На сейчас ничем не отличается от настройки Ethernet, специфическая поддержка отсутствует (и для [[Infiniband#IP_over_IB|IP-over-IB]] не требуется). Пример конфигурации для Mellanox:<br />
<br />
Файл: <tt>/etc/modules</tt><br />
<pre>mlx4_ib<br />
ib_umad<br />
ib_ipoib</pre><br />
<br />
Файл: <tt>/etc/net/ifaces/ib0/options</tt><br />
<pre>TYPE=eth<br />
BOOTPROTO=dhcp<br />
ONBOOT=yes</pre><br />
<br />
<div id="sysctl"></div><br />
<br />
=== Использование автодополнения в sysctl.conf ===<br />
<br />
В конфигурационном каталоге интерфейса может находиться файл <tt>sysctl.conf</tt>, в котором можно перечислить переменные <tt>sysctl(8)</tt>. Но переменные могут быть как общесистемными, так и относящимися к интерфейсу. Естественно, запись в sysctl.conf настроек вида <tt>net.ipv4.conf.eth0.log_martians = 1</tt> достаточно неудобна, а при переименовании интерфейса велик риск не отредактировать файл <tt>sysctl.conf</tt> соответствующим образом.<br />
<br />
Эта проблема решается следующим способом : производится запись в файл только имени переменной и значение, а система /etc/net сама найдет путь к этой переменной и вызовет <tt>sysctl</tt> с полным именем. <br />
<br />
Пример содержания файла <tt>sysctl.conf</tt>:<br />
<pre>log_martians=1<br />
rp_filter=1</pre><br />
<br />
<div id="profiles"></div><br />
<br />
=== Подключение к Wi-Fi с сертификатом на аппаратном токене ===<br />
Для беспроводного подключения в корпоративных сетях могут использоваться сертификаты, записанные на аппаратном токене, например, Aladdin eToken. Для настройки такого подключения необходимо использовать {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}}.<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=wheel<br />
#eapol_version=1<br />
#ap_scan=2<br />
#fast_reauth=1<br />
pkcs11_engine_path=/usr/lib/openssl/engines/engine_pkcs11.so<br />
pkcs11_module_path=/usr/lib/libeTPkcs11.so<br />
update_config=0<br />
<br />
network={<br />
ssid="test"<br />
key_mgmt=WPA-EAP<br />
pairwise=CCMP TKIP<br />
group=CCMP TKIP<br />
eap=TLS<br />
identity="email@address.ru"<br />
engine_id="pkcs11"<br />
key_id="xxxxxxxxx"<br />
cert_id="xxxxxxxxx"<br />
engine=1<br />
}<br />
</pre><br />
где key_id и cerd_id взяты из вывода команды<br />
<pre><br />
# pkcs11-tool --module /usr/lib/libeTPkcs11.so -O -l<br />
</pre><br />
<br />
Используются оригинальные ("родные") драйвера Aladdin - pkiclient-5.00.28-0, и пакет openssl-engine_pkcs11-0.1.5-alt1.<br />
<br />
=== Профили конфигурации ===<br />
<br />
==== Определение профилей ====<br />
Профиль — именованный вариант конфигурации, в той или иной степени изменяющий базовую конфигурацию системы. Профили могут быть применены, например, для конфигурации ноутбука в разных сетевых окружениях, или при подготовке новой или тестовой конфигурации с возможностью быстрого возврата к старой. Практически профили реализуются следующим образом: для какого-либо из файлов, составляющих общесистемную конфигурацию или конфигурацию интерфейса, создаётся альтернативный вариант, который отличается добавлением в конце названия файла знака # и имени профиля.<br />
<br />
Например, пусть единственное отличие между профилями заключается в том, какой модуль ядра будет загружен для интерфейса eth0. В этом случае файл {{path|/etc/net/ifaces/eth0/options}} необходимо скопировать в {{path|/etc/net/ifaces/eth0/options#profile1}} и изменить значение переменной <tt>MODULE</tt> в одном из них. Далее при использовании конфигурации по умолчанию будет использован файл <tt>options</tt>, а при использовании профиля profile1 — файл <tt>options#profile1</tt>. Если при этом для назначения интерфейсу имени используется файл {{path|/etc/net/iftab}}, то скорее всего необходимо будет создать соответствующий файл {{path|/etc/net/iftab#profile1}}, так как другой модуль ядра указывает на другой физический интерфейс и исходный файл <tt>iftab</tt> работать не будет.<br />
<br />
Профили могут использоваться также и для отключения каких-то параметров конфигурации. Например, если используется файл <tt>ipv4route</tt> для установки маршрутов для интерфейса, то можно создать файл нулевого размера <tt>ipv4route#profile2</tt>, чтобы при использовании профиля profile2 никаких маршрутов не конфигурировалось.<br />
<br />
==== Выбор профиля при загрузке ====<br />
Если при загрузке системы ядру был передан параметр netprofile, то его значение будет использовано как имя профиля по умолчанию. Это может быть использовано для создания собственных пунктов меню загрузчиков LILO и GRUB с заранее определённым профилем сетевой конфигурации. Заданный таким образом профиль может быть далее переопределён другими методами. Следует понимать разницу между различными конфигурациями и различными результатами применения одной конфигурации. Например, если в двух разных сетях используется DHCP, то смысла в разных профилях конфигурации нет.<br />
<br />
Для загрузчика LILO секции <tt>/etc/lilo.conf</tt> могут выглядеть следующим образом:<br />
<pre>image=/boot/vmlinuz-up<br />
label=linux-up home<br />
append=" netprofile=home"<br />
[...]<br />
image=/boot/vmlinuz-up<br />
label=linux-up office<br />
append=" netprofile=office"<br />
[...]</pre><br />
Для приведённого примера необходимо будет создать варианты для файлов, отличающихся в профилях home и office, и можно будет выбирать при загрузке, какой из профилей необходимо использовать. Использование этого метода удобно, если смена сетевого окружения происходит синхронно с загрузкой системы.<br />
<br />
==== Выбор профиля по умолчанию ====<br />
Если требуется, чтобы определенный профиль конфигурации использовался по умолчанию, то необходимо записать его название в файл <tt>/etc/net/profile</tt>. Этот метод имеет приоритет над параметром ядра netprofile. Использование такого способа выбора профиля целесообразно, когда переключение между конфигурациями происходит реже, чем перезагрузка системы.<br />
<br />
==== Смена профиля во время работы ====<br />
Если требуется переконфигурировать сеть без перезагрузки или редактирования файла {{path|/etc/net/profile}}, то следует использовать параметры сервиса network, описанные в разделе [[#restart, reload и другие команды|restart, reload и другие команды]]. Этот метод имеет приоритет над профилем по умолчанию и профилем, выбранным при загрузке. Целесообразно его использовать, если смена сетевого окружения происходит чаще, чем перезагрузка системы.<br />
<br />
==== Определение профиля во время конфигурации интерфейса ====<br />
Если в каталоге конфигурации интерфейса существует исполняемый файл ненулевого размера с именем <tt>selectprofile</tt>, то этот файл будет выполнен и первое слово первой строки его стандартного вывода использовано как имя профиля, которое должно быть использовано для конфигурации данного интерфейса. Этот метод имеет приоритет над всеми остальными методами. Исходной задачей, требующей такого решения, являлось конфигурирование беспроводного интерфейса в зависимости от доступных точек доступа.<br />
<br />
Следует учитывать, что число вызовов файла <tt>selectprofile</tt> может меняться в зависимости от контекста и время его выполнения может быть различным, поэтому при написании такого файла следует учитывать, что первым параметром будет являться имя текущего сценария. В настоящее время это могут быть ifup*, ifdown*, setup* и shutdown*. Для приведённого выше примера имеет смысл реагировать только на вызовы из ifup или ifup-common.<br />
<br />
== См. также ==<br />
* [[Ресолвер]]<br />
<br />
== Примечания ==<br />
<references/><br />
<br />
{{Category navigation|title=etcnet|category=etcnet|sortkey=*}}<br />
[[Категория:WiFi]]<br />
{{Category navigation|title=Wi-Fi|category=WiFi|sortkey={{SUBPAGENAME}}}}<br />
[[Категория:Admin]]<br />
{{Category navigation|title=Системному администратору|category=Admin|sortkey={{SUBPAGENAME}}}}<br />
[[en:etcnet]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=Etcnet&diff=48693Etcnet2020-06-26T19:11:45Z<p>AntonFarygin: /* Настройка VLAN */</p>
<hr />
<div>{{DISPLAYTITLE:etcnet}}<br />
{{span|font-size: 180%|Подсказки пользователю /etc/net}}<br />
<br />
{|<br />
|-valign="top"<br />
|Дополнительные страницы:<br />
* [[etcnet/qos|настройка QoS]]<br />
* [[etcnet/firewall|настройка сетевого экрана (firewall)]]<br />
Совсем быстрая настройка «с нуля»:<br />
# сконфигурируйте интерфейсы вручную, как надо;<br />
# запустите {{cmd|/etc/net/scripts/contrib/initconf write}};<br />
# проверьте содержимое подкаталогов {{path|/etc/net/ifaces/}}.<br />
|<br />
{| style="border:1px solid #AAA; background:#F9F9F9; width:280px; margin: 0 0 1em 1em; padding:.2em; text-align:center;" class=noprint<br />
|-<br />
|[[Image:Information.svg|20x20px]]Начиная с [[Branches/p5|пятой ветки]],<br /> <div style="display: inline; color: red;">в ALT Linux может использоваться и<br />[[NetworkManager/feature|NetworkManager]]</div> (используйте <tt>NM_CONTROLLED=no</tt><br />в {{path|$iface/options}}, если хотите использовать etcnet).<br />
|}<br />
|<br />
{| style="border:1px solid #AAA; background:#F9F9F9; width:155px; margin: 0 0 1em 1em; padding:.2em; float: right;" class=noprint<br />
|-<br />
|[[Image:Information.svg|20x20px]] external links:<br />
* [http://packages.altlinux.org/ru/Sisyphus/srpms/etcnet package info]<br />
* [http://git.altlinux.org/people/sbolshakov/packages/?p=etcnet.git;a=summary source git repo]<br />
|}<br />
|}<br />
<br />
<!-- Не убирайте div-ы, на них есть внешние ссылки! --><br />
<div id="quickstart"></div><br />
<br />
== Быстрый старт ==<br />
<div id="docs"></div><br />
<br />
=== Источники информации по /etc/net ===<br />
Обратите внимание, что начиная с версии 0.8.0 документация по /etc/net была собрана из комментариев, расположенных во множестве файлов, в несколько страниц руководств (man). Список всех файлов документации пакета <tt>etcnet</tt> можно получить командой:<br />
<pre>$ rpmquery -d etcnet</pre><br />
<br />
<div id="onecard"></div><br />
<br />
=== Быстрая настройка сетевого интерфейса стандарта Ethernet ===<br />
Для настройки одного сетевого интерфейса следует выполнить следующие шаги:<br />
<br />
Шаг 1: Создать каталог {{path|/etc/net/ifaces/eth0}}. Это каталог конфигурации данного интерфейса (<tt>eth0</tt>), в котором будут храниться файлы с настройками.<br />
<br />
Шаг 2: Определить, какой модуль необходим для вашей сетевой карты. Для этого можно использовать команды: <tt>lspci, lspcidrake, pciscan</tt>.<br />
<br />
Шаг 3: В каталоге конфигурации сетевого интерфейса создать файл <tt>options</tt> и записать в этот файл строку:<br />
<pre>MODULE=<имя модуля></pre> <br />
На данном этапе работу с файлом <tt>options</tt> можно завершить.<br />
<div style='padding:6px;border:1px solid red;'>Шаг 3 имеет смысл только в случае, если модули сетевых карт не грузятся автоматически другими средствами, например посредством udev. Если модуль уже загружен, параметр MODULE бесполезен.</div><br />
<br />
Шаг 4: Выяснить, какой IP-адрес должен быть назначен вашему интерфейсу. Если ваш сетевой интерфейс конфигурируется по DHCP, то в файл {{path|/etc/net/ifaces/eth0/options}} следует записать строку:<br />
<pre>BOOTPROTO=dhcp</pre><br />
и перейти к шагу 7.<br />
<br />
'''Замечание:''' В ряде случаев в файле <tt>options</tt> может понадобиться запись:<br />
<pre>DHCP_HOSTNAME=<имя машины без домена></pre><br />
Эта опция описана в странице руководства <tt>etcnet-options(5)</tt>.<br />
<br />
'''Замечание:''' В конце файла <tt>options</tt> необходимо наличие пустой строки.<br />
<br />
У сетевого интерфейса существуют два взаимосвязанных атрибута: <br />
* IP-адрес;<br />
* сетевая маска (mask). <br />
Шаг 5: Текущие значение адреса можно просмотреть командой:<br />
{{cmd|# /sbin/ip address show}} <br />
Вероятнее всего вы увидите, что интерфейс-петля lo (loopback) уже сконфигурирован с адресом 127.0.0.1/8 (что эквивалентно IP-адресу 127.0.0.1 и маске подсети 255.0.0.0). <tt>/8</tt> означает длину префикса CIDR (Classless InterDomain Routing).<br />
Для задания IP-адреса и маски подсети интерфейса <tt>eth0</tt> необходимо создать файл {{path|/etc/net/ifaces/eth0/ipv4address}}, в который следует записать IP-адрес с длиной маски, например:<br />
<pre>10.0.0.20/24</pre> <br />
<br />
Наиболее популярны маски /24 (т.е. длина префикса CIDR равная 24 эквивалентна маске сети 255.255.255.0 - это одна сеть класса C на 254 хоста) и /30. Для справки приводится таблица соответствия сетевых масок в различных нотациях.<br />
<ref><br />
{|<br />
|<br />
{| class="standard"<br />
|-<br />
!маска<br />в битах!!маска<br />точечно-<br />десятичная<br />
|-<br />
|/32||255.255.255.255<br />
|-<br />
|/31||255.255.255.254<br />
|-<br />
|/30||255.255.255.252<br />
|-<br />
|/29||255.255.255.248<br />
|-<br />
|/28||255.255.255.240<br />
|-<br />
|/27||255.255.255.224<br />
|-<br />
|/26||255.255.255.192<br />
|-<br />
|/25||255.255.255.128<br />
|-<br />
|/24||255.255.255.0<br />
|-<br />
|/23||255.255.254.0<br />
|-<br />
|/22||255.255.252.0<br />
|-<br />
|/21||255.255.248.0<br />
|-<br />
|/20||255.255.240.0<br />
|-<br />
|/19||255.255.224.0<br />
|-<br />
|/18||255.255.192.0<br />
|-<br />
|/17||255.255.128.0<br />
|}<br />
|<br />
| ||<br />
{| class="standard"<br />
|-<br />
!маска<br />в битах!!маска<br />точечно-<br />десятичная<br />
|-<br />
|/16||255.255.0.0<br />
|-<br />
|/15||255.254.0.0<br />
|-<br />
|/14||255.252.0.0<br />
|-<br />
|/13||255.248.0.0<br />
|-<br />
|/12||255.240.0.0<br />
|-<br />
|/11||255.224.0.0<br />
|-<br />
|/10||255.192.0.0<br />
|-<br />
|/9||255.128.0.0<br />
|-<br />
|/8||255.0.0.0<br />
|-<br />
|/7||254.0.0.0<br />
|-<br />
|/6||252.0.0.0<br />
|-<br />
|/5||248.0.0.0<br />
|-<br />
|/4||240.0.0.0<br />
|-<br />
|/3||224.0.0.0<br />
|-<br />
|/2||192.0.0.0<br />
|-<br />
|/1||128.0.0.0<br />
|}<br />
|}<br />
</ref><br />
<br />
Шаг 6: Выяснить адрес вашего шлюза (маршрут по умолчанию). Например, IP-адрес вашего шлюза — <tt>10.0.0.254</tt>. Тогда необходимо создать файл {{path|/etc/net/ifaces/eth0/ipv4route}}, в который записать строку:<br />
<pre>default via 10.0.0.254</pre><br />
Шаг 7: Убедиться, что всё выполнено правильно, выполнив команду:<br />
{{cmd|# service network restart}}<br />
Ваш интерфейс <tt>eth0</tt> должен быть успешно сконфигурирован. Если вы конфигурировали <tt>eth0</tt>, используя DHCP-сервер, но адрес интерфейсу не был назначен, то следует искать сообщение от DHCP-сервера в файле {{path|/var/log/messages}}.<br />
<br />
<div id="ifplugd"></div><br />
<br />
=== Настройка ifplugd ===<br />
Начиная с версии 0.7.10, /etc/net управляет ifplugd самостоятельно. Это было сделано для лучшей интеграции пакетов и для возможности следить за несколькими сетевыми интерфейсами одновременно. Для корректного использования ifplugd необходимо выполнить команду:<br />
# chkconfig ifplugd off<br />
<br />
и назначить переменную <tt>USE_IFPLUGD</tt> (USE_IFPLUGD=yes или USE_IFPLUGD=auto) в файлах <tt>options</tt> соответствующих интерфейсов (<tt>/etc/net/ifaces/<имя интерфейса>/options</tt>). Комментарий по данной переменной дан в странице руководства <tt>etcnet-options(5)</tt>.<br />
<br />
<div id="ppp"></div><br />
<br />
=== Настройка PPP-интерфейса ===<br />
Для настройки обычного модемного PPP-соединения необходимо:<br />
# Создать каталог конфигурации PPP-интерфейса, например, {{path|/etc/net/ifaces/ppp5}}. Вы можете задавать имена PPP-интерфейса вида pppN, pppNN, pppNNN и т. п., где N - любая цифра от 0 до 9;<br />
# Прочитать файл: {{path|/etc/net/ifaces/default/options-ppp}};<br />
# Создать файлы конфигурации. Вероятнее всего вам понадобятся <tt>pppconnect</tt> и <tt>pppdisconnect</tt>, чтобы <tt>pppd</tt> "знал", как дозваниваться и соединяться. Это скрипты для программы <tt>chat(8)</tt>. Кроме этого в файле <tt>pppoptions</tt> можно (часто нужно) перечислить опции <tt>pppd(8)</tt>, определяющие способ авторизации, скорость и название порта и т. п.;<br />
# Заполнить {{path|/etc/ppp/chap-secrets}} или {{path|/etc/ppp/pap-secrets}}.<br />
<br />
{{Attention|Использование опций "persist" и "maxfail 0", которые требуются pppd для непрерывных попыток восстановить интерфейс в случае проблем, может привести к невозможности загрузки системы в случае проблем с соединением. Вариант решения есть в {{altbug|23556#c1}} }}<br />
<br />
==== Настройка USB 3G-модема ====<br />
{{main|Установка и настройка 3G USB модема Huawei E1550}}<br />
<br />
<div id="ppp-pptp-pppoe"></div><br />
<br />
==== Настройка PPTP-интерфейса и PPPoE-интерфейса ====<br />
{{main|VPN (PPTP PPPoE)}}<br />
<br />
Хотя PPtP-соединения могут быть настроены и как обычные PPP-соединения, в /etc/net версии 0.7.10 для удобства пользователей была введена опция <tt>PPPTYPE</tt>. Она может принимать следующие значения:<br />
* <tt>dialup</tt> - обычный PPP-интерфейс.<br />
* <tt>pppoe</tt> - интерфейс PPPoE. Для такого интерфейса необходимо в опции <tt>HOST</tt> указывать имя Ethernet-интерфейса, через который будет производиться работа PPPoE. Побочным положительным эффектом будет то, что этот интерфейс будет при необходимости автоматически подниматься (т.е настраиваться) (см. [[#Зависимости между интерфейсами|Зависимости между интерфейсами]]).<br />
* <tt>pptp</tt> - интерфейс PPTP. Для такого интерфейса необходимо в опции <tt>PPTP_SERVER</tt> указывать имя хоста или IP-адрес PPtP-сервера, к которому будет производиться подключение. Обратите внимание, что хотя такие интерфейсы не имеют опции <tt>HOST</tt>, в большинстве случаев есть необходимость указать в опции <tt>REQUIRES</tt> интерфейс, через который будет достижим хост, указанный в <tt>PPTP_SERVER</tt>.<br />
<br />
См. также [[#Замечания о настройке VPN-подключения и туннелей|Замечания о настройке VPN-подключения и туннелей]].<br />
<br />
<div id="DNSandPPP"></div><br />
<br />
==== DNS и PPP-соединения ====<br />
<div style="display: inline; color: red;">Внимание: здесь описывается проблема, которая на самом деле была создана, а не решена — т.е. ради специфики [https://bugzilla.altlinux.org/show_bug.cgi?id=13789 kppp] была создана чётная ошибка в [https://bugzilla.altlinux.org/show_bug.cgi?id=13773 ppp-common]; последняя уже исправлена.</div><br />
<br />
Довольно долгое время существовала проблема неправильной модификации {{path|/etc/resolv.conf}} при установке PPP-соединений: [https://bugzilla.altlinux.org/show_bug.cgi?id=4249 #4249]. Сейчас она решена, но необходимо дать пояснения. Прежде всего убедитесь, что в файле {{path|/etc/resolv.conf}} есть строка:<br />
<pre># ppp temp entry</pre><br />
Если этой строки нет, то в файле не будут модифицироваться строки nameserver, если только какая-нибудь программа типа kppp это не сделает специально. Если такая строка есть, то {{path|/etc/resolv.conf}} будет модифицироваться в зависимости от значения булевой (логической) переменной RESOLV_MODS, которую необходимо задать в файле {{path|/etc/sysconfig/network}}.<br />
<br />
<div style="display: inline; color: red;">Внимание</div>: при ppp-common >= 0.4-alt1 строки <tt># ppp temp entry</tt> в файле {{path|/etc/resolv.conf}} при отсутствии PPP-соединения, поднятого какой-либо программой-«звонилкой», запущенной от администратора системы (пользователь root) — быть '''не должно'''! Если это есть, следует убрать, чтобы {{cmd|/etc/ppp/ip-up}} занимался обновлением записей про DNS в этом файле.<br />
<br />
<div id="restartreload"></div><br />
<br />
=== restart, reload и другие команды ===<br />
У сервиса <tt>network</tt> имеется ряд команд:<br />
* <tt>start</tt> - запустить все стационарные интерфейсы. hotplug-интерфейсы будут сконфигурированы при поступлении соответствующего вызова от hotplug.<br />
* <tt>startwith <имя профиля> </tt> - старт с указанным именем профиля, а не определённым автоматически.<br />
* <tt>stop</tt> - остановить все стационарные интерфейсы. hotplug-интерфейсы будут расконфигурированы при поступлении соответствующего вызова от hotplug.<br />
* <tt>stopwith <имя профиля> </tt> - стоп с указанным именем профиля, а не определённым автоматически.<br />
* <tt>restart</tt> - эквивалентно <tt>stop</tt> с последующим <tt>start</tt>, как и в большинстве других сервисов.<br />
* <tt>restartwith <имя профиля> </tt> - рестарт в контексте указанного профиля, эквивалентно <tt>stopwith <имя профиля> и startwith <имя профиля></tt>.<br />
* <tt>switchto <имя профиля> </tt> - переключение в указанный профиль, эквивалентно <tt>stop</tt> и <tt>startwith <имя профиля></tt>.<br />
* <tt>reload</tt> - семантически обозначает «актуализировать текущую конфигурацию». Для всех сконфигурированных в настоящий момент интерфейсов будет выполнена реконфигурация при наличии конфигурации.<br />
* <tt>check</tt> - автоматическая проверка конфигурационной базы.<br />
<br />
<div id="bootproto"></div><br />
<br />
=== Протоколы конфигурации адресов ===<br />
С помощью опции <tt>BOOTPROTO</tt> вы можете управлять тем, как у интерфейса будут появляться адреса и маршруты (это относится только к протоколу IPv4, так как протоколы IPv6 и IPX получают адреса только статически).<br />
* <tt>static</tt> — адреса и маршруты будут взяты из <tt>ipv4address</tt> и <tt>ipv4route</tt>.<br />
* <tt>dhcp</tt> — интерфейс будет сконфигурирован по DHCP.<br />
* <tt>ipv4ll</tt> — интерфейс будет сконфигурирован с помощью IPv4LL (link-local), ранее известному как ZCIP (zeroconf IP). Это значит, что из сети 169.254.0.0/16 будет подобран ещё не использованный адрес и назначен на интерфейс.<br />
Существует несколько комбинированных способов:<br />
* <tt>dhcp-static</tt> — если конфигурация по DHCP не удалась, конфигурировать методом static.<br />
* <tt>dhcp-ipv4ll</tt> — если конфигурация по DHCP не удалась, конфигурировать методом ipv4ll.<br />
* <tt>dhcp-ipv4ll-static</tt> — если конфигурация по DHCP не удалась, конфигурировать методом ipv4ll. Если и это не удалось, конфигурировать методом static.<br />
<br />
<div id="internals"></div><br />
<br />
=== Интеграция с systemd ===<br />
Начиная с версии 0.9.12 в etcnet добавлен Unit для включения интерфейсов по мере их появления в системе. Это позволяет избежать "гонок", когда сетевая подсистема поднимается раньше, чем ОС загружает драйвера для сетевых устройств.<br />
Для этого нужно выставить <tt>ONBOOT=no</tt> в файле options интерфейса и включить его подъём через systemd при загрузке: <tt>systemctl enable network@<имя интерфейса></tt>.<br />
<br />
== Устройство /etc/net ==<br />
<div id="generalinfo"></div><br />
<br />
=== Общие сведения ===<br />
/etc/net — это система конфигурации сети в Linux, т.е. эта система позволяет администратору Linux достаточно просто произвести настройки сети. Если же вы читаете эту страницу, то, вероятно, у вас возникли трудности с её использованием. Для решения возможных проблем полезно знать:<br />
<br />
<!--# [http://etcnet.org/ http://etcnet.org/] - сайт проекта, на котором можно найти примеры конфигурации и статьи по настройке системы. ?Рекурсия? --><br />
# /etc/net интегрирован в ALT Linux Sisyphus в виде пакетов:<br />
#* {{pkg|etcnet}} - базовые сценарии;<br />
#* {{pkg|etcnet-full}} - виртуальный пакет с зависимостями на все пакеты, которые могут использоваться сценариями /etc/net, с указанием их точных версий;<br />
#* {{pkg|etcnetconf}} - '''прототип''' конфигуратора;<br />
#* {{pkg|etcnet-defaults-desktop}} - умолчания для рабочей станции;<br />
#* {{pkg|etcnet-defaults-server}} - умолчания для сервера; <br />
# Пакеты {{pkg|etcnet}} и {{pkg|net-scripts}} — две конфликтующие реализации «подсистемы конфигурации сети» (network-config-subsystem).<br />
# При установке etcnet вместо net-scripts (или наоборот) сервис <tt>network</tt> оказывается выключенным. Это означает, что при загрузке системы сеть не будет сконфигурирована, что можно проверить командой {{cmd|chkconfig --list network}}. Для быстрого исправления проблемы можно дать команду {{cmd|chkconfig network reset}}.<br />
# etcnet '''НЕ''' импортирует автоматически настройки net-scripts. Если вы только что установили etcnet, и ваши сетевые интерфейсы всё ещё остаются сконфигурированными (несмотря на уже отсутствующий пакет net-scripts), то вы можете запустить сценарий {{cmd|/etc/net/scripts/initconf}}. Он попытается проанализировать текущее состояние интерфейсов и выведет вам результат. Никаких файлов при этом записано не будет. Если вам подходит вывод initconf, то запустите его с параметром write и он проделает то же самое, но уже с сохранением конфигурации.<br />
# Для корректной работы системы в целом необходимо, чтобы содержимое файла {{path|/etc/sysconfig/network}} было корректным.<br />
# Переменные <tt>sysctl</tt> в ОС ALT Linux конфигурируются в следующих местах<ref>{{altbug|26498}}</ref>:<br />
#* {{path|/etc/sysctl.conf}} (глобальные системные);<br />
#* {{path|/etc/sysconfig/network-scripts/sysctl.conf}} (общие сетевые в net-scripts, исходно файл не существует);<br />
#* {{path|/etc/net/sysctl.conf}} (общие сетевые в /etc/net);<br />
#* <tt>/etc/net/ifaces/*/sysctl.conf*</tt> (частные для конкретных интерфейсов или их типов в /etc/net, создаются вручную при необходимости).<br />
Скрипты etcnet используют эти файлы в указанном порядке.<br />
<br />
<div id="options.d"></div><br />
<br />
=== Организация опций /etc/net по умолчанию ===<br />
Методология /etc/net предусматривает несколько шагов наследования опций, первый из которых — загрузка опций по умолчанию. В ранних версиях это происходило из одного файла <tt>/etc/net/options</tt>, сейчас же в вашем распоряжении есть каталог {{path|/etc/net/options.d}}, из которого будут последовательно прочитаны все файлы.<br />
<br />
Иными словами, оригинальный архив etcnet содержит только файл {{path|/etc/net/options.d/00-default}}. Упаковщик etcnet, вместо того, чтобы добавить патч в какой-либо дистрибутив, просто добавляет файл с бОльшим номером, который переопределяет нужные опции.<br />
<br />
Ввиду решения различных задач, администратору системы может не подойти содержание дистрибутивного набора. В этом случае администратор может создать файл с ещё более высоким номером и определить настройки умолчания для своей системы. В результате такого подхода:<br />
# Уменьшается количество патчей (хотя их свойство "отваливаться" от пакета при его упаковке бывает полезным).<br />
# Не изменяются файлы с опциями, принадлежащие пакету. Это делает обновление пакета намного более корректным.<br />
# Можно легко увидеть, какие опции переопределяются на каждом этапе.<br />
<br />
<div id="iftab"></div><br />
<br />
=== Назначение iftab ===<br />
<br />
Начиная с дистрибутивов, основанных на ветках p5 и 5.1, переименование интерфейсов возложено на udev; см. тж. [http://lists.altlinux.org/pipermail/sisyphus/2009-June/340033.html это письмо] и <s>[https://bugzilla.altlinux.org/show_bug.cgi?id=19313 #19313]</s> и [http://packages.altlinux.org/ru/Sisyphus/srpms/wireless-tools/changelog %changelog ifrename]. В дистрибутивах на базе p8 и новее может быть полезным пакет udev-rule-generator-net, который заполняет /etc/udev/rules.d/70-persistent-net.rules. Возможно, следует отказаться от имён интерфейсов вида ethN и использовать, например, etherN ввиду того, что в новом systemd/udev официально сломан механизм переименования. Данное нововведение в ALT пока отменено; см. тж. [https://bugzilla.altlinux.org/32167 #32167].<br />
<br />
Имена сетевых интерфейсов по умолчанию, как правило, содержат их тип (eth, ppp, wifi, ipsec) и индекс: 0 - для первого созданного интерфейса, 1 - для второго и т. д. При этом соответствие автоматически назначенных имён физическим устройствам может не сохраняться.<br />
<br />
Эта особенность неудобна, когда машина с Linux имеет более одного интерфейса каждого типа. Типичными примерами являются маршрутизаторы и ноутбуки. В маршрутизаторах, как правило, используются однотипные сетевые карты и при их замене или изменении порядка на PCI-шине соответствие оказывается нарушенным. В ноутбуках используются ethernet и wifi-устройства с горячим подключением, при этом слотов и карт может быть более чем 1. В этом случае пользователь/администратор скорее всего пожелает закрепить за каждой сменной картой её конфигурацию.<br />
<br />
/etc/net при конфигурации интерфейса использует то имя, под которым он сконфигурирован, а именно имя каталога, в котором хранятся файлы конфигурации интерфейса.<br />
<br />
Для привязки сетевой карты к имени интерфейса в простых случаях можно воспользоваться файлом {{path|/etc/iftab}}, man-страница по формату которого входит в пакет <tt>ifrename</tt> (<tt>iftab(5)</tt>).<br />
<br />
Использование {{path|/etc/iftab}} удобно, поскольку позволяет сохранять традиционные имена интерфейсов (например, eth0), но этот механизм не поддерживает расширенную функциональность /etc/net (в частности, ''профили'' /etc/net).<br />
<br />
Средством, позволяющим использовать все возможности <tt>etcnet</tt>, является файл {{path|/etc/net/iftab}}, обрабатываемый не утилитой <tt>ifrename</tt>, а непосредственно <tt>etcnet</tt>. Синтаксис этого файла совпадает с синтаксисом {{path|/etc/iftab}}. Ограничением же является невозможность использовать стандартные имена интерфейсом (<tt>ethX</tt>, <tt>pppX</tt>), так как переименование интерфейсов происходит уже после конфигурации интерфейса ядром. В случае, если вам необходим {{path|/etc/net/iftab}}, имеет смысл переименовать интерфейсы, давая им либо двухзначные номера (<tt>eth00</tt>, <tt>eth01</tt>...), либо осмысленные названия (<tt>isplink</tt>, <tt>lan</tt>...)<br />
<br />
См. письмо про [http://lists.altlinux.org/pipermail/sisyphus/2009-March/337924.html важность /etc/iftab]<br />
и тж. это письмо про [http://lists.altlinux.org/pipermail/devel/2007-October/065097.html отличия etcnet и сервиса ifrename]:<br />
{{начало цитаты}} Комментарии к письмам этого треда (с некоторыми пояснениями):<br />
<br />
1. «etcnet уже научился менять местами eth0 и eth1?»<br />
<br />
Освоение этого приема обладает сомнительной пользой. Рекомендуется <br />
рассматривать eth0 как временное имя с малым сроком жизни,<br />
а для повышения комфорта пользователей Ethernet-интерфейсы предлагается<br />
называть eth00, eth01, eth02 etc.<br />
<br />
2. «Существование (номинальное) net-scripts вынуждает поддерживать<br />
ряд сервисов, которые иначе могли бы быть упразднены»<br />
<br />
Эти сервисы можно "обезвредить" (отключить) контролем CONFMETHOD<br />
из /etc/sysconfig/network. При этом зависимости на пакет etcnet<br />
не возникнет, только на network-config-subsystem. Примеры таких<br />
пакетов должны быть в Sisyphus.<br />
<br />
3. «после приведения в порядок /etc/udev/rules.d/19-udev-ifrename.rules<br />
нужности в /etc/net/iftab я не заметил»<br />
<br />
Важнейшее принципиальное отличие /etc/net/iftab от /etc/iftab —<br />
нахождение /etc/net/iftab в специальном пространстве имён. Для него<br />
действуют механизмы определения профиля и хоста конфигурации. Это,<br />
например, позволит, при необходимости, составить конфигурацию так, что срочный<br />
ремонт маршрутизатора сведётся к переносу диска (или массива)<br />
из сгоревшего шасси в запасное. Возможны и другие примеры, которые<br />
станут невозможными при помещении iftab в /etc и его прямой<br />
интерпретации.<br />
<br />
Конечно, пользователю единственного ноутбука с одним-двумя сетевыми<br />
интерфейсами такая практика — полный overkill (т.е. такая практика ему не нужна), но его никто и не<br />
заставляет видеть всю подводную часть (т.е. все тонкости работы и настройки). В этом и гибкость.{{конец цитаты}}<br />
<br />
<div id="specifaces"></div><br />
<br />
=== Интерфейсы lo, default и unknown ===<br />
Сразу после установки пакета <tt>etcnet</tt> в каталоге {{path|/etc/net/ifaces}} (в котором хранятся конфигурации интерфейсов) находятся три каталога: <br />
* lo<br />
* default<br />
* unknown<br />
<br />
Интерфейс '''lo''' — стандартная "петля" (loopback), которая должна быть во всякой Linux-системе, поэтому конфигурация для него включена по умолчанию. В остальном он ничем не отличается от любого другого интерфейса и конфигурируется точно так же файлами <tt>options</tt> и <tt>ipv4address</tt>.<br />
<br />
Интерфейс '''default''' — это не интерфейс, а специальный каталог, файлы в котором обрабатываются следующим образом:<br />
* <tt>resolv.conf</tt> — если присутствует, то копируется в {{path|/etc/resolv.conf}}.<br />
* <tt>options</tt> — файл опций, читается после опций по умолчанию.<br />
* <tt>options-<вид интерфейса></tt> — этот файл содержит опции, специфичные для данного вида интерфейсов. Некоторые из них не обязательны и позволяют использовать особенности данного вида интерфейсов, например, <tt>LINKDETECT</tt> в <tt>options-eth</tt>; другие обязательны, например, <tt>HOST</tt> в <tt>options-bri</tt>. Обратите внимание, что эти файлы не рекомендуется редактировать. Если вам нужно задать опцию для интерфейса, то, как правило, это можно сделать в файле <tt>options</tt> в конфигурационном каталоге данного интерфейса. Это облегчит процесс обновления пакета etcnet.<br />
* <tt>sysctl.conf-<вид интерфейса></tt> — файл с переменными sysctl, которые необходимо изменить. Сейчас единственный такой файл — <tt>sysctl.conf-dvb</tt>, который отключает <tt>return path filter</tt>, что всегда нужно в случае асимметричной маршрутизации.<br />
* <tt>iplink-<вид интерфейса></tt> — файл с командами iplink, специфичными для данного вида.<br />
* <tt>selectprofile</tt> — если этот файл исполняемый, то он будет вызван из сценариев <tt>ifup/ifdown</tt>, <tt>setup/shutdown</tt> для того, чтобы вернуть на стандартном выводе имя профиля, которое необходимо использовать. Это позволяет автоматически переключать профили в зависимости от каких-либо условий. В поставку включен пример сценария: {{path|/etc/net/scripts/contrib/selectprofile}}.<br />
* <tt>fw</tt> — каталог с настройками сетевого экрана по умолчанию.<br />
<br />
Интерфейс '''unknown''' — специальная конфигурация, которая будет использована в том случае, когда /etc/net просят сконфигурировать hotplug-интерфейс, для которого не существует каталога конфигурации. Это будет работать только в том случае, если включена опция <tt>ALLOW_UNKNOWN</tt>.<br />
<br />
<div id="broadcast"></div><br />
<br />
=== broadcast address===<br />
<br />
Периодически возникает вопрос: почему после старта /etc/net при запуске <tt>ifconfig</tt> можно видеть <tt>Bcast:0.0.0.0</tt>, хотя при использовании net-scripts это поле было правильным? <br />
<br />
Ответ: net-scripts оперируют адресом, маской, адресом сети и широковещательным адресом, пытаясь определить неизвестные компоненты из известных, а <tt>config-ipv4</tt> просто передаёт утилите <tt>ip</tt> содержимое файла <tt>ipv4address</tt>, не проверяя его содержание.<br />
Важно заметить, что:<br />
* Если <tt>iproute2</tt> изменит свой синтаксис, то с очень вероятно, что администратору будет необходимо редактировать только конфигурационные файлы.<br />
* Не было найдено проблем с «отсутствующим» broadcast address. Он есть в таблице маршрутизации <tt>local</tt>. <br />
* Администратор всегда может назначить адрес broadcast в файле <tt>ipv4address</tt>. Это можно сделать с помощью выражения <tt>broadcast +</tt><ref><br />
Выдержка из файла ip-cref.ps, который входит в документацию пакета iproute2:<br />
<br />
<pre><br />
* broadcast ADDRESS<br />
<br />
the broadcast address on the interface.<br />
It is possible to use the special symbols '+' and '-' instead of the broadcast address. In this case, <br />
the broadcast address is derived by setting/resetting the host bits of the interface prefix.<br />
NB. Unlike ifconfig, the ip utility does not set any broadcast address unless explicitly requested.<br />
</pre><br />
</ref>.<br />
'''Замечание:''' В версии 0.8.0 появилась опция <tt>AUTO_BROADCAST</tt> для автоматического дополнения каждой строки <tt>ipv4address</tt>.<br />
<br />
<div id="never_rmmod"></div><br />
<br />
=== Ядро 2.6 и "пропадающие" интерфейсы ===<br />
Иногда возможна ситуация: Если два интерфейса используют один и тот же модуль ядра, и у них определена опция <tt>MODULE</tt> (то есть скрипты /etc/net сами загружают и выгружают модули), то при опускании (отключении) одного интерфейса пропадает и второй интерфейс. <br />
<br />
Такая ситуация почти наверняка возникает при использовании ядра 2.6, особенностью которого являются значения счётчика ссылок (третий столбец вывода {{cmd|lsmod}}). Когда счетчик оказывается равен нулю (довольно часто), скрипты могут попытаться выгрузить модуль интерфейса, для которого запущен ifdown. И такая выгрузка происходит, несмотря на то, что другой интерфейс, использующий этот же модуль, находится в состоянии UP (т.е. он активен).<br />
<br />
Чтобы заблокировать выгрузку модулей, можно использовать булеву переменную <tt>NEVER_RMMOD</tt>. Возможно, позже это будет происходить автоматически для ядер следующих версий.<br />
<br />
<div id="removables"></div><br />
<br />
=== Cценарии конфигурации сети и hotplug-интерфейсы ===<br />
<br />
==== Cценарии конфигурации сети ====<br />
Существует несколько сценариев конфигурации сети.<br />
<br />
* Первый и самый простой — выполнение {{cmd|service network start}} при старте системы или вручную. При этом требуется только сформировать погруппные (потиповые) списки интерфейсов, подлежащих обработке, и последовательно выполнить требуемые действия. Модули ядра при этом загружаются сценариями /etc/net, при этом имена модулей берутся из опции <tt>MODULE</tt> (в этой опции можно в кавычках перечислить несколько имён и они будут последовательно загружены). Этот метод часто используется на практике и лучше всего подходит для маршрутизаторов. Преимущество метода в том, что вся необходимая информация сконцентрирована в одном месте — каталоге {{path|/etc/net}}. Если опция <tt>MODULE</tt> не определена, то будет предпринята попытка загрузки по имени интерфейса, подразумевая, что файл {{path|/etc/modules.conf}} правильно заполнен.<br />
<br />
* Второй сценарий — реакция на событие <tt>ifplugd</tt>. В предыдущих версиях существовала сложность, так как требовалась синхронная настройка сервиса <tt>ifplugd</tt>. Сейчас логика работы определена, что выражено в том, что /etc/net взяла управление <tt>ifplugd</tt> на себя. В части загрузки модуля этот сценарий не отличается от первого.<br />
<br />
* Третий сценарий — реакция на появление или исчезновение сменного устройства. Для обработки таких событий предназначены сценарии <tt>/etc/net/scripts/{ifup,ifdown}-removable</tt>, которые вызываются из сценариев пакетов hotplug и pcmcia-cs. Сложность заключается в том, что для сменных PCMCIA-карт вызовы могут дублироваться: для одного и того же события первый раз ifup-removable будет вызван из hotplug, второй — из pcmcia-cs. Кроме того, hotplug также реагирует на загрузку модулей ядра для обычных карт PCI и, более того, включает сценарии, которые пытаются загружать модули самостоятельно. В этом контексте /etc/net получает слишком много вызовов от hotplug и по умолчанию их игнорирует (<tt>USE_HOTPLUG=no</tt>).<br />
<br />
==== hotplug-интерфейсы ====<br />
Рассмотрим использование hotplug-интерфейсов. <br />
<br />
Пусть администратору необходимо настроить действительно сменную карту. После заполнения {{path|/etc/iftab}} или {{path|/etc/net/iftab}} в файле <tt>options</tt> необходимо будет задать <tt>USE_HOTPLUG=yes</tt>. После этого при получении события от hotplug /etc/net будет работать в том контексте, что модуль в загрузке и выгрузке не нуждается. <br />
<br />
Важно заметить, что '''такой интерфейс будет пропущен при обычном старте сети''', т.к. если он сменный, то единственный достоверный способ узнать, что он присутствует — получить вызов от hotplug. Из факта выполнения {{cmd|service network start}} совсем не следует, что какой-то один или несколько из сконфигурированных hotplug-интерфейсов сейчас в наличии и требуют конфигурации. Если вы хотите вручную расконфигурировать hotplug-интерфейс до его извлечения, используйте команду {{cmd|ifdown}}. Для повторной конфигурации вставьте его ещё раз.<br />
<br />
Также существует опция <tt>USE_PCMCIA</tt>. Если события для вашей карты генерирует pcmcia-cs, то вам нужно её включить. Если события генерируются только hotplug, то используйте опцию <tt>USE_HOTPLUG</tt>.<br />
<br />
<div id="eth0"></div><br />
<br />
=== Проблема стандартных имен интерфейсов (eth0 и др.)===<br />
<br />
При использовании файла {{path|/etc/net/iftab}}, то есть в случае применения сложных конфигураций, возникает следующая проблема:<br />
* При загрузке модулей имена интерфейсов принимают вид eth0, eth1, eth2… Какие именно — в общем случае контролировать нельзя.<br />
* Имя eth0 обладает наибольшей вероятностью оказаться занятым.<br />
* ifrename не может переименовать интерфейс, если целевое имя уже занято (udev использует <tt>ifrename -t</tt>, но это не работает после начальной загрузки, см. руководство к ifrename).<br />
<br />
С учётом вышеизложенного, если {{path|/etc/net/iftab}} содержит тот же набор имён интерфейсов, что уже имеется после загрузки модулей (то есть <tt>eth0</tt>/<tt>eth1</tt> и другие «стандартные» названия), то единственный случай, когда etcnet сможет без ошибок обработать такой файл — изначальное соответствие, не требующее переименования.<br />
<br />
Таким образом, при использовании {{path|/etc/net/iftab}} имеет смысл давать интерфейсам названия, отличные по виду от тех, что назначает ядро. В простых случаях лучше использовать {{path|/etc/udev/rules.d/70-persistent-net.rules}} ({{path|/etc/iftab}} до бранчей p5/5.1).<br />
<br />
<div id="advanced"></div><br />
<br />
== Расширенные возможности ==<br />
<div id="multipleIPs"></div><br />
<br />
=== Несколько IP-адресов или маршрутов на одном интерфейсе ===<br />
<br />
Вы можете помещать произвольное количество IP-адресов в файл <tt>ipv4address</tt> по одному адресу на каждой строке. То же самое относится к статическим маршрутам и файлу <tt>ipv4route</tt>.<br />
<br />
Обратите внимание, что /etc/net не анализирует содержимое этих файлов, а формирует на основе каждой строки командную строку для утилиты {{cmd|ip}}. Это означает, что вы можете помещать в этих файлах произвольные поддерживаемые {{cmd|ip}} опции и они будут обработаны. Например, в файле <tt>ipv4route</tt> можно поместить строку:<br />
<pre>10.0.1.0/24 via 10.0.0.253 metric 50 weight 5 table 100</pre><br />
<br />
<div id="requires"></div><br />
<br />
=== Зависимости между интерфейсами ===<br />
У интерфейсов:<br />
* vlan<br />
* bond <br />
* bri <br />
* teql <br />
входящих в группу зависимых физических, должна быть определена опция <tt>HOST</tt> со списком интерфейсов, необходимых для инициализации текущего интерфейса. Если хост-интерфейс не сконфигурирован при поднятии зависимого интерфейса, то это будет исправлено.<br />
<br />
Кроме обязательной для определённых интерфейсов опции <tt>HOST</tt>, может быть задана и необязательная для всех остальных интерфейсов опция <tt>REQUIRES</tt>. Интерфейсы, перечисленные в этой опции, будут считаться зависимостями текущего интерфейса. Например, по умолчанию попытка сконфигурировать интерфейс А, который зависит от Б и В, приведёт сначала к конфигурации Б и В. Аналогично, при расконфигурации Б или В сначала будет расконфигурирован А.<br />
<br />
Зависимость одного интерфейса от другого не всегда формальна. Например, в сценарии <tt>ifup-pre</tt> одного интерфейса может использоваться команда, которая потребует разрешения DNS-имени, которое может быть разрешено только с помощью <tt>resolv.conf</tt>, инсталлируемого другим интерфейсом. Или это может быть PPPoE/PPtP-интерфейс, требующий Ethernet-интерфейс для работы.<br />
<br />
Для того, чтобы избежать неожиданных сбоев в таких случаях, правильно задавайте опцию <tt>REQUIRES</tt>.<br />
<br />
<div id="postpre"></div><br />
<br />
=== Пользовательские сценарии post и pre ===<br />
Существует возможность поместить в каталог конфигурации интерфейса файлы, которые будут выполнены в определённые моменты. Для этого они должны быть исполняемыми и называться следующим образом:<br />
* <tt>ifup-pre</tt> — для выполнения перед конфигурированием интерфейса.<br />
* <tt>ifup-post</tt> — для выполнения после конфигурирования интерфейса. Например, можно запустить почтовую систему.<br />
* <tt>ifdown-pre</tt> — для выполнения перед расконфигурированием интерфейса. Например, можно остановить почтовую систему.<br />
* <tt>ifdown-post</tt> — для выполнения после расконфигурирования интерфейса.<br />
<br />
Также в версии до 0.8.0 возможно использовать следующие сценарии (они должны быть исполняемыми):<br />
* <tt>/etc/net/scripts/ifup-pre-local</tt><br />
* <tt>/etc/net/scripts/ifup-post-local</tt><br />
* <tt>/etc/net/scripts/ifdown-pre-local</tt><br />
* <tt>/etc/net/scripts/ifdown-post-local</tt><br />
<br />
Они будут вызваны для каждого интерфейса. Начиная с версии 0.8.0 эти сценарии называются так:<br />
* <tt>/etc/net/ifup-pre</tt><br />
* <tt>/etc/net/ifup-post</tt><br />
* <tt>/etc/net/ifdown-pre</tt><br />
* <tt>/etc/net/ifdown-post</tt><br />
Семантика сохранена.<br />
<br />
<div id="iplink"></div><br />
<br />
=== Управление канальными параметрами интерфейсов ===<br />
<br />
Если поместить в конфигурационный каталог интерфейса файл <tt>iplink</tt>, в котором в каждой строке будут записаны команды режима link утилиты {{cmd|ip}}, то они будут выполнены при конфигурации интерфейса. <br />
<br />
Например, если необходимо, чтобы интерфейс net1 имел MAC-адрес aa:bb:cc:dd:ee:ff и MTU 200 байт, то в файл {{path|/etc/net/ifaces/net1/iplink}} нужно поместить следующее:<br />
<pre>address aa:bb:cc:dd:ee:ff<br />
mtu 200</pre><br />
<br />
Обратите внимание, что в этом случае в {{path|/etc/net/iftab}} вам необходимо будет использовать селектор <tt>businfo</tt> или <tt>driver</tt> вместо <tt>mac</tt>.<br />
<br />
<div id="ethtool"></div><br />
<br />
=== Управление физическими параметрами интерфейсов ===<br />
Если поместить в конфигурационный каталог интерфейса файл <tt>ethtool</tt>, в котором будет строка с параметрами программы ethtool, то она будет выполнена при конфигурации интерфейса. <br />
<br />
Например, если есть необходимость, чтобы интерфейс net1 имел скорость 10Мбит/с и авто-согласование скорости было отключено, то в файл {{path|/etc/net/ifaces/net1/ethtool}} нужно поместить следующую строку:<br />
<br />
<pre>speed 10 autoneg off</pre><br />
<br />
<div id="bridge"></div><br />
<br />
=== Настройка Ethernet-моста ===<br />
<br />
Для настройки Ethernet-моста (далее — моста) есть 3 пути: <br />
# Linux bridge посредством bridge-utils<br />
# Linux bridge посредством iproute2<br />
# Openvswitch<br />
<br />
Linux bridge наиболее простая реализация. Если вам не нужно все, что умеет [http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=README;hb=HEAD openvswitch] , то можно использовать Linux bridge.<br />
<br />
==== Linux bridge посредством bridge-utils (до p8 включительно) ====<br />
Перед настройкой Ethernet-моста (далее — моста) с помощью etcnet сначала необходимо убедиться, что установлен пакет bridge-utils. Etcnet использует утилиту brctl для настройки моста, и, если утилита не установлена, то при перезапуске системы сеть станет недоступна. Если интерфейсы, входящие в состав моста, являются единственными физически подключенными и настройка моста происходит с удаленного узла через эти интерфейсы, то требуется соблюдать осторожность, т.к. эти интерфейсы перестанут быть доступны. В случае ошибки в конфигурации потребуется физический доступ к серверу. Для страховки, перед перезапуском сервиса network можно открыть ещё одну консоль и запустить там, например, команду: {{cmd|sleep 500 && reboot}}.<br />
<br />
Также имейте ввиду, что если вы подключаетесь по ssh к серверу через bridge-интерфейс (по его ip-адресу), то по умолчанию при опускании любого интерфейса-члена моста Etcnet так же опустит и сам мост (и ваше подключение пропадет). Чтобы избежать этого, установите в файле {{path|options}} того интерфейса, который нужно опускать, переменную <tt>IFDOWN_CHILDREN=no</tt>. Но учтите, что и включаться в бридж при старте тогда этот интерфейс по умолчанию не будет. <br />
<br />
Предположим, требуется настроить Ethernet-мост, пусть он будет называться <tt>br0</tt>. <br />
Тогда для его настройки необходимо завести каталог {{path|/etc/net/ifaces/br0}} и создать там файлы со следующими данными:<br />
<br />
* <tt>brctl</tt><br />
<br />
<pre> stp AUTO on </pre><br />
<br />
* <tt>ipv4address</tt>:<br />
<pre> 192.168.100.200/24 </pre><br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=bri<br />
HOST='eth0 tap0'<br />
BOOTPROTO=static </pre><br />
<br />
Содержимое файла <tt>brctl</tt> передаётся утилите brctl. <tt>AUTO</tt> означает, что скрипт {{cmd|setup-bri}} самостоятельно определит имя bridge-интерфейса (см. файл {{path|/usr/share/doc/etcnet-*/README.bridge}}). Если же в вашей сети этот мост один и рассылать пакеты протокола STP не нужно, тогда файл brctl с указанной опцией не нужен. По умолчанию [http://xgu.ru/wiki/man:brctl#Spanning_Tree_Protocol_.28.D0.9F.D1.80.D0.BE.D1.82.D0.BE.D0.BA.D0.BE.D0.BB_.D0.BE.D1.81.D1.82.D0.BE.D0.B2.D0.BD.D0.BE.D0.B3.D0.BE_.D0.B4.D0.B5.D1.80.D0.B5.D0.B2.D0.B0.29 STP выключен].<br />
<br />
IP-адрес для интерфейса, как обычно, будет взят из <tt>ipv4address</tt>.<br />
<br />
В опции <tt>HOST</tt> файла <tt>options</tt> нужно указать те интерфейсы, которые будут входить в мост. Если в него будут входить интерфейсы, которые до этого имели IP-адрес (например, eth0), то этот адрес должен быть удалён (например, можно закомментировать содержимое файла {{path|ifaces/eth0/ipv4address}}).<br />
<br />
При старте сети сначала поднимаются интерфейсы, входящие в мост, затем сам мост (автоматически). Для назначения адреса мосту можно также использовать DHCP (<tt>BOOTPROTO=dhcp</tt>). Но при этом важно обратить внимание на параметр <tt>forwarding delay</tt> (man brctl / setfd), так как интерфейс, подключенный к мосту, не сразу входит в режим передачи пакетов, и это может вызвать dhcp таймаут. Версии etcnet в дистрибутивах ALT Linux Server 4 и Desktop 4.1 (0.9.7-alt0.M40/M41) имеют эту недоработку, которая исправлена только в версии 0.9.9-alt1. <br />
Документацию по настройке моста с вопросами и ответами (перевод) можно найти на http://xgu.ru/wiki/Linux_Bridge, а его оригинал доступен на http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge.<br />
<br />
Внимание: инструкция на xgu.ru чуть устарела. Команда<br />
<pre>$ brctl setfd br0 0</pre><br />
не выключает задержку, а лишь приводит к величине задержки по умолчанию (15 или даже 30 секунд). Можно попробовать задать задержку в 1сек для уменьшения времени инициализации сети.<br />
<br />
С пакетом etcnet поставляются примеры конфигурации. Один из них показывает, как из двух ethernet-интерфейсов port0 и port1 можно собрать мост bridge (каталог документации examples/Ethernet-bridge-GRE/).<br />
<br />
Безотносительно к etcnet, следует иметь ввиду проблему, связанную с NAT: <s>[http://bugzilla.kernel.org/show_bug.cgi?id=13079 http://bugzilla.kernel.org/show_bug.cgi?id=13079]</s><br />
<br />
==== Linux bridge посредством iproute2 (начиная с p9) ====<br />
Надо описать, пока только ссылка на дискуссию в момент перехода: https://lists.altlinux.org/pipermail/devel/2018-October/205769.html<br />
==== openvswitch ====<br />
Как настраивать openvswitch, описано [[Etcnet/openvswitch|тут]].<br />
<br />
<div id="vlan"></div><br />
<br />
=== Настройка VLAN ===<br />
<br />
Для настройки 802.1q VLAN (например, id 4094 на eth1) следует, создав каталог {{path|ifaces/eth1.4094}}, поместить в него файлы со следующим содержимым:<br />
<br />
* <tt>ipv4address</tt>:<br />
<pre>192.168.100.200/24</pre><br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=vlan<br />
HOST=eth1<br />
VID=4094<br />
BOOTPROTO=static</pre><br />
<br />
Содержимое переменных <tt>HOST</tt> и <tt>VID</tt> будет передано утилите <tt>vconfig</tt>; использование файла <tt>vlantab</tt> необязательно (и не рекомендуется по причине невозможности использовать ifup для отдельного интерфейса). Пример конфигурации можно найти в каталоге examples/VLAN-without-vlantab/ документации etcnet.<br />
<br />
Следует обратить внимание, что 4094 является верхней допустимой границей идентификатора валидного VLAN, а [http://www.candelatech.com/pipermail/vlan/2004-November/000128.html 4095 используется технически в процессе отбрасывания трафика по неверным VLAN]. (следует отметить, что это не ограничение Linux: [http://en.wikipedia.org/wiki/802.1Q в стандарте под VID отведено 12 бит])<br />
<br />
<br />
Обратите внимание, что '''ISC DHCP сервер на интерфейсе VLAN''', скорее всего, у вас не будет не работать, пока вы не добавите опцию VLAN_REORDER_HDR=on в настройки vlan интерфейса. Эта опция переведёт vlan интерфейс в режим работы, в котором пакеты на интерфейсе не будут содержать тэгов vlan и их сможет получить dhcpd. <br />
<br />
<br />
'''Для настройки Q-in-Q интерфейса''', например, eth1.123.513 (дважды тегированный трафик: внешняя метка -- 123, внутренняя -- 513) следует файл <tt>options</tt> в каталоге {{path|ifaces/eth1.123.513}} заполнить следующим образом:<br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=vlan<br />
HOST=eth1.123 # "родительский" интерфейс; может называться иначе<br />
VID=513<br />
VLAN_REORDER_HDR=0<br />
BOOTPROTO=static</pre><br />
<br />
Родительский интерфейс должен быть сконфигурирован (можно с или без <tt>BOOTPROTO</tt>, с или без <tt>ipv4address</tt> и т.п.).<br />
<br />
Таким образом, можно каскадировать интерфейсы "как угодно глубоко" (Q-in-Q-in-Q-in-Q....). Необходимо только учитывать, что длина имени интерфейса ограничена (16-ю символами).<br />
<br />
<div id="bonding"></div><br />
<br />
=== Настройка bonding ===<br />
Bonding - объединение нескольких физических сетевых интерфейсов в один логический, для достижения отказоустойчивости, увеличения скорости и балансировки нагрузки. Возможны несколько режимов работы и много параметров для настроек, подробнее см. http://www.linuxfoundation.org/collaborate/workgroups/networking/bonding<br />
<br />
Для создания агрегированного bond-интерфейса средствами etcnet создаем, как обычно, директорию для интерфейса (например, <tt>bond0</tt>) с <tt>options</tt>, <tt>ipv4address</tt>, и прочими необходимыми файлами. В <tt>options</tt> указываем тип интерфейса <tt>bond</tt>, перечисляем в переменной <tt>HOST</tt> родительские интерфейсы, которые будут входить в наш агрегированный интерфейс, указываем в переменной <tt>BONDMODE</tt> режим (по умолчанию 0), и опции для модуля ядра <tt>bonding</tt> в <tt>BONDOPTIONS</tt>.<br><br />
Так, для создания LACP-агрегированного канала (802.3ad), у нас получится такой <tt>options</tt>:<br />
TYPE=bond<br />
ONBOOT=yes<br />
BOOTPROTO=static<br />
HOST="eth0 eth1"<br />
BONDMODE=4<br />
BONDOPTIONS="miimon=100 lacp_rate=1"<br />
Интерфейсы eth0 и eth1 должны тоже быть описаны в etcnet.<br />
<br />
Как правило, для создания агрегированного интерфейса требуется, чтобы входящие в него физические интерфейсы имели одинаковые характеристики - скорость, дуплекс, etc.<br />
<br />
Не стоит указывать режим в переменной <tt>BONDOPTIONS</tt>: попытки изменить какие-то режимоспецифичные параметры до установки правильного режима могут быть отвергнуты. Поэтому, первым делом нужно установить необходимый режим, указав его для этого в <tt>BONDMODE</tt>.<br />
<br />
Информацию о получившемся агрегированном интерфейсе можно посмотреть в {{path|/proc/net/bonding/bond0}}<br />
<br />
<div id="tun/tap"></div><br />
<br />
=== Настройка tun/tap интерфейса ===<br />
<br />
Etcnet поддерживает простое создание интерфейсов типа tun/tap. Это виртуальный тип интерфейсов для передачи пакетов между ядром и программами, который не передает данных через физические устройства.<br />
'''tun''' — это интерфейс типа point-to-point, работающий с кадрами IP.<br />
'''tap''' — интерфейс типа ethernet, работающий с кадрами ethernet.<br />
<br />
Потребуется использование утилиты tunctl, находящейся в одноименном пакете.<br />
Пусть требуется создать и настроить tun/tap интерфейс, например, с именем tap0. Для этого необходимо:<br />
* создать каталог интерфейса:<br />
<br />
/etc/net/ifaces/tap0<br />
<br />
* создать в каталоге интерфейса {{path|/etc/net/ifaces/tap0}} файл настройки <tt>options</tt> со следующим содержанием:<br />
<br />
TYPE=tuntap<br />
TUNTAP_USER=combr<br />
<br />
<br />
<tt>TUNTAP_USER</tt> — это аккаунт или цифровой id пользователя, которому будут даны права на использование интерфейса tap0 (устройство /dev/net/tun).<br />
Этот параметр будет передан утилите <tt>tunctl</tt> как аргумент опции <tt>-u</tt> (см. руководство на tunctl).<br />
С версии ядра 2.6.18 произошли изменения в управлении этим типом интерфейсов, потребовавшие<br />
обязательного применения <tt>tunctl</tt> для разрешения доступа обычных<br />
пользователей к tap-интерфейсам. В предыдущих версиях любой<br />
пользователь, имеющий доступ к <tt>/dev/net/tun</tt>, мог создать любое<br />
количество сетевых интерфейсов с произвольными именами. Начиная с<br />
2.6.18, для создания интерфейса через <tt>/dev/net/tun</tt> требуется<br />
<tt>CAP_NET_ADMIN</tt> (обычно эту привилегию имеет только root), а обычный<br />
пользователь, имеющий доступ к <tt>/dev/net/tun</tt>, может только использовать<br />
уже созданные интерфейсы, к которым разрешён доступ для его uid.<br />
<br />
=== Настройка интерфейса типа OpenVPN ===<br />
<br />
Настройка OpenVPN может быть произведена большим количеством способов и вариантов с разными целями, и достойна отдельной статьи. Здесь, для начала, будет описан вариант openvpn-сервера в режиме bridging.<br />
Для этого надо проделать подготовку:<br />
* создать ключи [http://openvpn.net/index.php/open-source/documentation/howto.html#pki англ. HOWTO]<br />
(до версии 2.3 утилиты easy-rsa шли в составе дистрибутива openvpn, потом отдельно).<br />
* настроить [http://www.altlinux.org/Etcnet#.D0.9D.D0.B0.D1.81.D1.82.D1.80.D0.BE.D0.B9.D0.BA.D0.B0_Ethernet-.D0.BC.D0.BE.D1.81.D1.82.D0.B0 мост] (между внутренним физическим интерфейсом и интерфейсом tap, который будет использовать openvpn) "средствами системы".<br />
<br />
Далее надо сделать так (скрипты etcnet по умолчанию ожидают это):<br />
* создать каталог интерфейса:<br />
<br />
/etc/net/ifaces/tap0<br />
<br />
* создать в каталоге интерфейса {{path|/etc/net/ifaces/tap0}} файл настройки <tt>options</tt> со следующим содержанием:<br />
<br />
TYPE=ovpn<br />
<br />
(необязательно, но желательно указать '''REQUIRES'''=''<имя ethernet-интерфейса>'', с которым будет связан туннель)<br />
<br />
* Конфигурационный файл для openvpn (из примера в пакете openvpn-docs - такой, как /usr/share/doc/openvpn-docs-2.2.2/sample-config-files/server.conf) надо переделать, удалив параметры, которые etcnet подставляет самостоятельно при запуске:<br />
<br />
dev<br />
ca<br />
cert<br />
key<br />
persist-key<br />
persist-tun<br />
<br />
И обязательно добавив параметры, которых по умолчанию в конфиге-примере нет:<br />
<br />
tls-server<br />
script-security 2<br />
<br />
Параметр script-security был введен начиная с версии 2.1_rc9. Поскольку etcnet запускает openvpn так, что в процессе тот запускает скрипт scripts/openvpn.action, который считается "пользовательским", то для этого значение должно быть 2.<br />
<br />
* скопировать в каталог интерфейса ключи и измененный конфиг-файл openvpn.<br />
Файлы надо переименовать (ключи - после easy-rsa) таким образом:<br />
{| align="center" border="1"<br />
|ключ easy-rsa<br />
|ключ etcnet-ovpn<br />
|-<br />
|ca.crt <br />
|ovpnca<br />
|-<br />
|server.crt<br />
|ovpncrt<br />
|-<br />
|server.key<br />
|ovpnkey<br />
|-<br />
|server.conf<br />
|ovpnoptions<br />
|}<br />
<br />
<br />
<br />
После всего этого можно попробовать запустить интерфейс: ifup tun0 (или весь мост, например ifup br0). Но если, например, openvpn считает ошибочной какую-либо опцию, то он молча выйдет с кодом выхода 1, и скрипт ifup ничего не напишет (в логе так же не будет попытки запуска openvpn). Потребуется отладка (например, можно запустить openvpn вручную без параметра --daemon и со всеми параметрами, которые подставил etcnet).<br />
<br />
<div id="wireguard"></div><br />
<br />
=== Настройка WireGuard VPN туннеля ===<br />
<br />
WireGuard используется для быстрого создания VPN туннелей, является более легким и безопасным чем OpenVPN. Для использования wireguard необходимо '''ядро версии 3.10+''' и установленные модули ядра '''wireguard-std-def''', '''wireguard-un-def'''. Для настройки интерфейса необходимо:<br />
* создать каталог интерфейса {{path|/etc/net/ifaces/wg0}}<br />
* добавить файл с конфигурацией {{path|/etc/net/ifaces/wg0/options}}<br />
<source lang='ini'><br />
TYPE=wg<br />
LISTENPORT=51820<br />
</source><br />
* добавить файл с поддерживающимися wireguard опциями пиров {{path|/etc/net/ifaces/wg0/options}} (одна строка - один пир)<br />
<source lang='bash'><br />
peer PUBLICPEERKEY allowed-ips IFACESSUBNET endpoint PUBLICIP:ALLOWPORT<br />
</source><br />
* добавить файл содержащий локальные и удаленные ip адреса {{path|/etc/net/ifaces/wg0/ipv4address}}<br />
первым делом указывается выделенная интерфейсу локальная подсеть, после чего указываются соответствия локального и удаленного ip адресов, каждое соответствие с новой строки<br />
<source lang='bash'><br />
10.1.0.0/16<br />
10.1.0.1 10.2.0.1<br />
</source><br />
* добавить файл содержащий приватный ключ {{path|/etc/net/ifaces/wg0/privatekey}}<br />
Ключи могут быть созданы стандартной утилитой wireguard:<br />
<source lang='bash'><br />
$ umask 077<br />
$ wg genkey > privatekey<br />
$ wg pubkey < privatekey > publickey<br />
</source><br />
<br />
<div id="iptun"></div><br />
<br />
=== Настройка и использование IP-туннелей ===<br />
<br />
IP-туннели — средство, позволяющее улучшить IP-сети. Поддерживаются IP-туннели трёх видов: <br />
* IPIP<br />
* GRE<br />
* SIT <br />
* VTI<br />
<br />
Прежде всего следует определить необходимый вид туннеля для решаемой задачи. <br />
<br />
* Туннели '''IPIP''' — самые простые.<br />
<br />
* Туннели '''GRE''' (general incapsulation) обычно используются в маршрутизаторах Cisco. По туннелям этого типа могут передаваться broadcast и multicast пакеты. Кроме того, эти туннели поддерживают контрольные суммы и контроль упорядоченности пакетов. Также GRE-туннели обладают опциональным атрибутом key в виде произвольного 4-байтового числа, который позволяет конфигурировать несколько GRE туннелей между одной парой IP-адресов несущей сети (в отличие от IPIP-туннелей, с которыми это невозможно).<br />
<br />
* Туннели '''SIT''' предназначены для транспортировки пакетов IPv6 через сети IPv4.<br />
<br />
* Туннели '''VTI''' используются для построения IPsec туннелей. Работают используя один из демонов, strongswan или libreswan.<br />
<br />
Тип туннеля определяется опцией <tt>TUNTYPE (ipip, gre, sit, vti)</tt>. По умолчанию <tt>TUNTYPE=ipip</tt>. Кроме типа туннеля для конфигурации всегда требуется адрес удалённого хоста и почти всегда — локальный адрес. Эти адреса определяются опциями <tt>TUNREMOTE</tt> и <tt>TUNLOCAL</tt> соответственно. В некоторых случаях локальный адрес можно не указывать. В этом случае опция <tt>TUNLOCAL</tt> всё равно обязательна, но принимает значение <tt>any</tt>. Не забудьте назначить туннельному интерфейсу адреса и маршруты в соответствующих файлах.<br />
<br />
Пример: Конфигурация GRE-туннеля между 10.0.1.2 и 10.0.2.3 с двумя ключами для исходящих и входящих пакетов, проверкой очерёдности пакетов, TTL 8 и вычислением контрольных сумм. Туннель должен использовать только интерфейс gw1. Пусть имя создаваемого туннеля будет <tt>mytunnel</tt>.<br />
<br />
Тогда необходимо сделать следующие операции:<br />
* Создать каталог туннеля: {{path|/etc/net/ifaces/mytunnel}}<br />
<br />
* Создать в каталоге туннеля файл настроек <tt>options</tt>: {{path|/etc/net/ifaces/mytunnel/options}}<br />
<br />
* Отредактировать файл настроек <tt>options</tt>: <br />
<br />
<source lang="ini"><br />
TYPE=iptun<br />
TUNTYPE=gre<br />
TUNLOCAL=10.0.1.2<br />
TUNREMOTE=10.0.2.3<br />
TUNTTL=8<br />
HOST=gw1<br />
TUNOPTIONS='ttl 64 seq ikey 2020 okey 2030 csum'<br />
</source><br />
<br />
<div id="vpn"></div><br />
<br />
Про <tt>ttl 64</tt>. Если параметр ttl не задан, значение берётся из инкапсулируемого пакета (это надо проверить). В некоторых случаях ttl может получиться слишком мал (например, Quagga формирует OSPF-пакеты с TTL 1).<br />
<br />
Стоит помнить, что имена <tt>tunl0, gre0 и sit0</tt> являются зарезервированными в iproute2 ("base devices") и имеют особое поведение: http://www.liveinternet.ru/users/stasikos/post71435454/<br />
<br />
Процедура создания vti интерфейса стандартна, однако, предварительно необходимо установить и настроить один из демонов (strongswan, libreswan), о том, как это сделать можно найти в соответствующей документации. После чего необходимо создать каталог интерфейса (к примеру он будет называться vti0) {{path|/etc/net/ifaces/vti0}}, и добавить в него файл настроек туннеля {{path|/etc/net/ifaces/vti0/options}}, куда нужно прописать необходимую конфигурацию:<br />
<source lang='ini'><br />
TYPE=iptun<br />
TUNTYPE=vti<br />
TUNLOCAL=119.81.184.173<br />
TUNREMOTE=119.81.177.236<br />
TUNOPTIONS='key 42'<br />
</source><br />
Параметр key должен соответствовать параметру mark, указанному при настройке strongswan/libreswan.<br />
<br />
=== Настройка IPv6 ===<br />
==== Отключение IPv6 ====<br />
<br />
* '''Вариант 1'''<br />
Чтобы отключить IPv6 на всех сетевых интерфейсах в работающей системе с загруженным модулем ipv6, нужно изменить значение параметра ядра net.ipv6.conf.all.disable_ipv6, где 'all' подразумевает все интерфейсы, а net.ipv6.conf.eth0.disable_ipv6 -- отключение протокола IPv6 только на интерфейсе eth0 и т.д.<br />
<pre><br />
sysctl net.ipv6.conf.all.disable_ipv6=1<br />
</pre><br />
Также можно добавить данную директиву в {{path|/etc/sysctl.conf}}:<br />
<source lang="bash"><br />
echo 'net.ipv6.conf.all.disable_ipv6 = 1' >> /etc/sysctl.conf<br />
sysctl -f<br />
</source><br />
<br />
* '''Вариант 2'''<br />
Добавить параметр в командную строку загрузки ядра. Для GRUB2 нужно изменить параметры загрузки ядра в файле {{path|/etc/sysconfig/grub2}}, изменив переменную GRUB_CMDLINE_LINUX_DEFAULT или GRUB_CMDLINE_LINUX<br />
<pre><br />
...<br />
GRUB_CMDLINE_LINUX='failsafe vga=normal ipv6.disable=1'<br />
...<br />
</pre><br />
и обновив конфигурационный файл grub<br />
<source lang="bash"><br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
</source><br />
<br />
* '''Вариант 3'''<br />
<source lang="bash"><br />
echo 'options ipv6 disable=1' >> /etc/modprobe.d/options-local.conf<br />
</source><br />
Вступит в силу только после перезагрузки.<br />
<br />
==== Включение IPv6 ====<br />
<br />
* Во-первых, следует убедиться, что не применяется какой-либо вариант совета из предыдущего пункта. <br />
* Во-вторых, следует проверить значение CONFIG_IPV6 в etcnet. Переменная может быть описана в /etc/net/options.d/*, /etc/net/ifaces/default/*, /etc/net/ifaces/*/options. Наибольший приоритет у описания в ifaces/*/options.<br />
<br />
'''Замечание:''' В etcnet-0.9.10-alt5, в /etc/net/ifaces/default/options содержится CONFIG_IPV6=no<br />
<br />
==== Туннели 6-to-4 ====<br />
<br />
Требуется:<br />
* ядро с поддержкой IPv6 (CONFIG_IPV6 в /boot/config-*; наличие модуля ipv6);<br />
* ядро с поддержкой tun (CONFIG_TUN в /boot/config-*; наличие модуля tun);<br />
* доступность узла 192.88.99.1 - через него маршрутизируется трафик в сети IPv6.<br />
<br />
Далее в {{path|/etc/net/ifaces}} создаётся каталог с названием, например,<br />
tun6to4. В нём создаются файлы:<br />
iplink : <pre><br />
mtu 1472 </pre><br />
<br />
ipv6address : <pre><br />
# first six octets: ipv6calc --ipv4_to_6to4addr $TUNLOCAL<br />
2002:c000:201::1/16 </pre><br />
<br />
ipv6route : <pre><br />
2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 </pre><br />
<br />
options : <pre><br />
TYPE=iptun<br />
TUNTYPE=sit<br />
TUNLOCAL=192.0.2.1<br />
TUNREMOTE=any<br />
TUNOPTIONS="ttl 64"<br />
DONT_FLUSH=yes<br />
CONFIG_IPV6=yes </pre><br />
<br />
Адрес TUNLOCAL в options - имеющийся внешний IPv4, в ipv6address<br />
адрес IPv6 выбирается исходя из него же.<br />
<br />
В настройках iptables должно быть разрешение на приём пакетов протокола<br />
ipv6 на внешний адрес IPv4.<br />
<br />
Далее поднимается интерфейс tun6to4, ну и проверяется доступность <br />
чего-либо в IPv6.<br />
<br />
Туннели 6to4 - это RFC 3964.<br />
Miredo - это реализация протокола Teredo, RFC 4380.<br />
6to4 требует наличия внешнего адреса IPv4.<br />
Teredo не требует наличия внешнего адреса, и может работать через NAT.<br />
Через Teredo не получится получить симметричное соединение, т.е. доступ<br />
в IPv6 будет односторонний, на компьютер в общем случае извне<br />
подключиться не получится.<br />
И Teredo позволяет получить только адрес /32, т.е. для подключения сетей<br />
он мало пригоден.<br />
<br />
этот раздел скопирован из письма рассылки community (c) Nikolay A. Fetisov 8 сентября 2011 12:03:30<br />
<br />
=== Замечания о настройке VPN-подключения и туннелей ===<br />
<br />
Часто при настройке VPN-подключения (под которыми здесь будут подразумеваться все туннельные подключения, то есть подключения поверх IP) не учитывают, что использование опции pppd '<tt>defaultroute</tt>' маршрут по-умолчанию после подключения будет изменен. При этом, если VPN-сервер находится в другой, отличной от клиента, сети, то после подключения (и изменения маршрута по-умолчанию) VPN-сервер становится недоступным, следовательно, недоступными становятся все внешние адреса, и подключение, как правило, прекращается по тайм-ауту.<br />
<br />
Решением, как обычно (и рекомендовано), служит указание ''отдельного'' маршрута на VPN-сервер (или его сеть). Для этого необходимо прописать (в примере - для маршрута через eth0) в {{path|/etc/net/ifaces/eth0/ipv4route}} строку вида:<br />
<br />
10.0.1.0/24 via 10.0.0.1<br />
<br />
В данном примере подразумевается, что VPN-сервер находится в сети 10.0.1.0/24 (например, имеет адрес 10.0.1.1), клиент — в сети 10.0.0.0/24 (и имеет адрес, например, 10.0.0.10), а маршрутизатор имеет адрес 10.0.0.1.<br />
<br />
Теперь, при использовании опции '<tt>defaulroute</tt>' для pppd (которая указывает, что необходимо изменить на вновь созданное подключение маршрут по-умолчанию), даже после замены маршрута по-умолчанию новым, сеть 10.0.1.0, в которой в нашем примере и находится VPN-сервер, останется доступной.<br />
<br />
Как более точечный вариант (применяется в alterator-net-pptp 0.5.x) можно использовать скрипты {{cmd|ifup-pre}} и {{cmd|ifdown-post}} в каталоге конфигурируемого PPP-интерфейса.<br />
<br />
Наример:<br />
<source lang="bash"><br />
#!/bin/sh<br />
# sample /etc/net/ifaces/ppp0/ifup-pre; replace variables yourself<br />
ip route add VPN_SERVER via DEF_GW<br />
</source><br />
<source lang="bash"><br />
#!/bin/sh<br />
# sample /etc/net/ifaces/ppp0/ifdown-post; replace variables yourself<br />
ip route del VPN_SERVER via DEF_GW<br />
</source><br />
<br />
Не забудьте подставить нужные IP-адреса вместо VPN_SERVER и DEF_GW (не сеть, где VPN-сервер, а ее /32 префикс CIDR) и выполнить команду: {{cmd|chmod +x ifup-pre ifdown-post}}<br />
<br />
<div id="iprule"></div><br />
<br />
=== Сложная маршрутизация (или несколько таблиц маршрутизации) ===<br />
<br />
Под «сложной маршрутизацией» подразумевается наличие нескольких таблиц маршрутизации. Для их использования необходимо сконфигурировать правила ядра. В правилах по умолчанию можно увидеть следующее:<br />
<br />
<pre># ip rule show<br />
0: from all lookup local <br />
32766: from all lookup main <br />
32767: from all lookup default</pre><br />
<br />
Для настройки «сложной маршрутизациии» необходимо выполнить следующие операции:<br />
<br />
Шаг 1 : Сами таблицы определены в файле {{path|/etc/iproute2/rt_tables}}. Для создания конфигурации «сложной маршрутизации» необходимо вначале «создать» нужные таблицы в этом файле (если вы хотите использовать имена таблиц, а не числа).<br />
<br />
Шаг 2 : Необходимо заполнить таблицы. В конфигурационном каталоге интерфейса в файле <tt>ipv4route</tt> необходимо добавить маршрутные записи, не забывая указать <tt>table XX</tt>. Важно учитывать, что если строка начинается с режима ip route (add, del, replace, append, change), то по умолчанию будет использован режим <tt>DEFAULT_IPV4ROUTE_CMD</tt> (<tt>append</tt>).<br />
<br />
Шаг 3 : Определить правила в файле <tt>ipv4rule</tt>. Здесь есть особенности, связанные автоматической заменой/добавлением параметров. Если строка не начинается с операции del или add, то нужный режим будет подставлен автоматически. Это подходит для тех случаев, когда вам при "поднятии" интерфейса необходимо добавить правила, а при "опускании" — удалить. Возможность указывать del или add реализована для обратных случаев: если при "поднятии" интерфейса вам необходимо удалить правила, а при "опускании" — добавить. В этом случае add и del будут в нужный момент автоматически заменены на del и add.<br />
<br />
Пример такой конфигурации входит в /etc/net 0.7.12: (каталог документации examples/routing-LARTC-1/)<br />
<br />
=== Простое переключение маршрутов ===<br />
<br />
Пусть имеется eth-интерфейс, который используется постоянно, и настроен маршрут по умолчанию.<br />
Часто бывает необходимость настроить второй маршрут по умолчанию через беспроводной интерфейс,<br />
но с меньшей метрикой, чем у проводного интерфейса.<br />
В этом случае при поднятии WI-FI маршрут по умолчанию «развернется» в нужную сторону.<br />
<br />
Например:<br />
<br />
Для eth-интерфейса файл настроек {{path|/etc/net/ifaces/eth0/ipv4route}} будет таким:<br />
<pre>default via 192.168.3.254 metric 10</pre><br />
а для WI-FI-интерфейса файл настроек {{path|/etc/net/ifaces/ath0/ipv4route}} таким:<br />
<pre>default via 192.168.123.1 metric 5</pre><br />
<br />
<div id="wireless"></div><br />
=== Беспроводный Ethernet (или настройка WI-FI) ===<br />
Большинство беспроводных интерфейсов сейчас представлено системе как интерфейсы Ethernet. Соответственно беспроводный интерфейс будет иметь <b>TYPE=eth</b> (<s>[https://bugzilla.altlinux.org/show_bug.cgi?id=6283 #6283]</s>). Чтобы интерфейс нормально функционировал, необходимо кроме загрузки модуля с параметрами, воспользоваться утилитами {{cmd|iwconfig}} из пакета wireless-tools или {{cmd|wpa_supplicant}} из такого же пакета. Вместо того, чтобы запускать их вручную, можно поместить в конфигурационный каталог интерфейса файл <tt>iwconfig</tt> с командами iwconfig или файл <tt>wpa_supplicant.conf</tt> с конфигурацией wpa_supplicant. Они будут использованы автоматически.<br />
<br />
Пример [http://hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wireless.html конфигурации] (совместно с <tt>[http://ndiswrapper.sourceforge.net/ ndiswrapper]</tt>):<br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/options}}<br />
<pre>TYPE=eth<br />
MODULE=ndiswrapper<br />
NEVER_RMMOD=yes<br />
BOOTPROTO=dhcp<br />
USE_HOTPLUG=no<br />
ONBOOT=no</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/iwconfig}}<br />
<pre>essid default<br />
#key bababababa</pre><br />
<br />
<br />
Еще один пример использования etcnet для настройки беспроводной сети:<br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/options}}<br />
<pre>TYPE=eth<br />
USE_HOTPLUG=NO<br />
BOOTPROTO=static<br />
module=ipw2200<br />
WPA_DRIVER=wext</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/iwconfig}}<br />
<pre>essid homenet<br />
mode 1<br />
ap 00:11:D8:22:AD:0D<br />
channel 3<br />
rate 11M</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}}<br />
<pre>ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=0<br />
eapol_version=1<br />
ap_scan=1<br />
fast_reauth=1<br />
<br />
network={<br />
ssid="homenet"<br />
scan_ssid=1<br />
key_mgmt=WPA-PSK<br />
psk="this is my mega secret password string to wpa supplicant"<br />
}</pre><br />
<br />
Если вы хотите воспользоваться WPS:<br />
# создайте {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}} следующего вида:<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
update_config=1<br />
</pre><br />
# поднимите беспроводной интерфейс (ifup wlan0)<br />
# запустите wpa_cli и дайте команды wps_pbc (после этого нужно соответственно нажать кнопку WPS на точке доступа и подождать окончания обмена данными) и save_config (для записи конфигурации в <tt>wpa_supplicant.conf</tt>). Или же можно воспользоваться утилитой wpa_gui, отображающей процесс более наглядно.<br />
<br />
Пример файла {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}} при подключении к сети, использующей протокол WPA2-PSK(AES)<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=0<br />
eapol_version=1<br />
ap_scan=1<br />
fast_reauth=1<br />
<br />
network={<br />
ssid="home-lg"<br />
bssid=00:1B:11:87:C7:EA<br />
proto=RSN<br />
key_mgmt=WPA-PSK<br />
pairwise=CCMP TKIP<br />
group=CCMP TKIP<br />
psk="this is my mega secret password string to wpa supplicant"<br />
priority=2<br />
}<br />
</pre><br />
<br />
<div id="infiniband"></div><br />
<br />
=== Настройка Infiniband ===<br />
На сейчас ничем не отличается от настройки Ethernet, специфическая поддержка отсутствует (и для [[Infiniband#IP_over_IB|IP-over-IB]] не требуется). Пример конфигурации для Mellanox:<br />
<br />
Файл: <tt>/etc/modules</tt><br />
<pre>mlx4_ib<br />
ib_umad<br />
ib_ipoib</pre><br />
<br />
Файл: <tt>/etc/net/ifaces/ib0/options</tt><br />
<pre>TYPE=eth<br />
BOOTPROTO=dhcp<br />
ONBOOT=yes</pre><br />
<br />
<div id="sysctl"></div><br />
<br />
=== Использование автодополнения в sysctl.conf ===<br />
<br />
В конфигурационном каталоге интерфейса может находиться файл <tt>sysctl.conf</tt>, в котором можно перечислить переменные <tt>sysctl(8)</tt>. Но переменные могут быть как общесистемными, так и относящимися к интерфейсу. Естественно, запись в sysctl.conf настроек вида <tt>net.ipv4.conf.eth0.log_martians = 1</tt> достаточно неудобна, а при переименовании интерфейса велик риск не отредактировать файл <tt>sysctl.conf</tt> соответствующим образом.<br />
<br />
Эта проблема решается следующим способом : производится запись в файл только имени переменной и значение, а система /etc/net сама найдет путь к этой переменной и вызовет <tt>sysctl</tt> с полным именем. <br />
<br />
Пример содержания файла <tt>sysctl.conf</tt>:<br />
<pre>log_martians=1<br />
rp_filter=1</pre><br />
<br />
<div id="profiles"></div><br />
<br />
=== Подключение к Wi-Fi с сертификатом на аппаратном токене ===<br />
Для беспроводного подключения в корпоративных сетях могут использоваться сертификаты, записанные на аппаратном токене, например, Aladdin eToken. Для настройки такого подключения необходимо использовать {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}}.<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=wheel<br />
#eapol_version=1<br />
#ap_scan=2<br />
#fast_reauth=1<br />
pkcs11_engine_path=/usr/lib/openssl/engines/engine_pkcs11.so<br />
pkcs11_module_path=/usr/lib/libeTPkcs11.so<br />
update_config=0<br />
<br />
network={<br />
ssid="test"<br />
key_mgmt=WPA-EAP<br />
pairwise=CCMP TKIP<br />
group=CCMP TKIP<br />
eap=TLS<br />
identity="email@address.ru"<br />
engine_id="pkcs11"<br />
key_id="xxxxxxxxx"<br />
cert_id="xxxxxxxxx"<br />
engine=1<br />
}<br />
</pre><br />
где key_id и cerd_id взяты из вывода команды<br />
<pre><br />
# pkcs11-tool --module /usr/lib/libeTPkcs11.so -O -l<br />
</pre><br />
<br />
Используются оригинальные ("родные") драйвера Aladdin - pkiclient-5.00.28-0, и пакет openssl-engine_pkcs11-0.1.5-alt1.<br />
<br />
=== Профили конфигурации ===<br />
<br />
==== Определение профилей ====<br />
Профиль — именованный вариант конфигурации, в той или иной степени изменяющий базовую конфигурацию системы. Профили могут быть применены, например, для конфигурации ноутбука в разных сетевых окружениях, или при подготовке новой или тестовой конфигурации с возможностью быстрого возврата к старой. Практически профили реализуются следующим образом: для какого-либо из файлов, составляющих общесистемную конфигурацию или конфигурацию интерфейса, создаётся альтернативный вариант, который отличается добавлением в конце названия файла знака # и имени профиля.<br />
<br />
Например, пусть единственное отличие между профилями заключается в том, какой модуль ядра будет загружен для интерфейса eth0. В этом случае файл {{path|/etc/net/ifaces/eth0/options}} необходимо скопировать в {{path|/etc/net/ifaces/eth0/options#profile1}} и изменить значение переменной <tt>MODULE</tt> в одном из них. Далее при использовании конфигурации по умолчанию будет использован файл <tt>options</tt>, а при использовании профиля profile1 — файл <tt>options#profile1</tt>. Если при этом для назначения интерфейсу имени используется файл {{path|/etc/net/iftab}}, то скорее всего необходимо будет создать соответствующий файл {{path|/etc/net/iftab#profile1}}, так как другой модуль ядра указывает на другой физический интерфейс и исходный файл <tt>iftab</tt> работать не будет.<br />
<br />
Профили могут использоваться также и для отключения каких-то параметров конфигурации. Например, если используется файл <tt>ipv4route</tt> для установки маршрутов для интерфейса, то можно создать файл нулевого размера <tt>ipv4route#profile2</tt>, чтобы при использовании профиля profile2 никаких маршрутов не конфигурировалось.<br />
<br />
==== Выбор профиля при загрузке ====<br />
Если при загрузке системы ядру был передан параметр netprofile, то его значение будет использовано как имя профиля по умолчанию. Это может быть использовано для создания собственных пунктов меню загрузчиков LILO и GRUB с заранее определённым профилем сетевой конфигурации. Заданный таким образом профиль может быть далее переопределён другими методами. Следует понимать разницу между различными конфигурациями и различными результатами применения одной конфигурации. Например, если в двух разных сетях используется DHCP, то смысла в разных профилях конфигурации нет.<br />
<br />
Для загрузчика LILO секции <tt>/etc/lilo.conf</tt> могут выглядеть следующим образом:<br />
<pre>image=/boot/vmlinuz-up<br />
label=linux-up home<br />
append=" netprofile=home"<br />
[...]<br />
image=/boot/vmlinuz-up<br />
label=linux-up office<br />
append=" netprofile=office"<br />
[...]</pre><br />
Для приведённого примера необходимо будет создать варианты для файлов, отличающихся в профилях home и office, и можно будет выбирать при загрузке, какой из профилей необходимо использовать. Использование этого метода удобно, если смена сетевого окружения происходит синхронно с загрузкой системы.<br />
<br />
==== Выбор профиля по умолчанию ====<br />
Если требуется, чтобы определенный профиль конфигурации использовался по умолчанию, то необходимо записать его название в файл <tt>/etc/net/profile</tt>. Этот метод имеет приоритет над параметром ядра netprofile. Использование такого способа выбора профиля целесообразно, когда переключение между конфигурациями происходит реже, чем перезагрузка системы.<br />
<br />
==== Смена профиля во время работы ====<br />
Если требуется переконфигурировать сеть без перезагрузки или редактирования файла {{path|/etc/net/profile}}, то следует использовать параметры сервиса network, описанные в разделе [[#restart, reload и другие команды|restart, reload и другие команды]]. Этот метод имеет приоритет над профилем по умолчанию и профилем, выбранным при загрузке. Целесообразно его использовать, если смена сетевого окружения происходит чаще, чем перезагрузка системы.<br />
<br />
==== Определение профиля во время конфигурации интерфейса ====<br />
Если в каталоге конфигурации интерфейса существует исполняемый файл ненулевого размера с именем <tt>selectprofile</tt>, то этот файл будет выполнен и первое слово первой строки его стандартного вывода использовано как имя профиля, которое должно быть использовано для конфигурации данного интерфейса. Этот метод имеет приоритет над всеми остальными методами. Исходной задачей, требующей такого решения, являлось конфигурирование беспроводного интерфейса в зависимости от доступных точек доступа.<br />
<br />
Следует учитывать, что число вызовов файла <tt>selectprofile</tt> может меняться в зависимости от контекста и время его выполнения может быть различным, поэтому при написании такого файла следует учитывать, что первым параметром будет являться имя текущего сценария. В настоящее время это могут быть ifup*, ifdown*, setup* и shutdown*. Для приведённого выше примера имеет смысл реагировать только на вызовы из ifup или ifup-common.<br />
<br />
== См. также ==<br />
* [[Ресолвер]]<br />
<br />
== Примечания ==<br />
<references/><br />
<br />
{{Category navigation|title=etcnet|category=etcnet|sortkey=*}}<br />
[[Категория:WiFi]]<br />
{{Category navigation|title=Wi-Fi|category=WiFi|sortkey={{SUBPAGENAME}}}}<br />
[[Категория:Admin]]<br />
{{Category navigation|title=Системному администратору|category=Admin|sortkey={{SUBPAGENAME}}}}<br />
[[en:etcnet]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=Etcnet&diff=48692Etcnet2020-06-26T18:42:47Z<p>AntonFarygin: /* Настройка VLAN */</p>
<hr />
<div>{{DISPLAYTITLE:etcnet}}<br />
{{span|font-size: 180%|Подсказки пользователю /etc/net}}<br />
<br />
{|<br />
|-valign="top"<br />
|Дополнительные страницы:<br />
* [[etcnet/qos|настройка QoS]]<br />
* [[etcnet/firewall|настройка сетевого экрана (firewall)]]<br />
Совсем быстрая настройка «с нуля»:<br />
# сконфигурируйте интерфейсы вручную, как надо;<br />
# запустите {{cmd|/etc/net/scripts/contrib/initconf write}};<br />
# проверьте содержимое подкаталогов {{path|/etc/net/ifaces/}}.<br />
|<br />
{| style="border:1px solid #AAA; background:#F9F9F9; width:280px; margin: 0 0 1em 1em; padding:.2em; text-align:center;" class=noprint<br />
|-<br />
|[[Image:Information.svg|20x20px]]Начиная с [[Branches/p5|пятой ветки]],<br /> <div style="display: inline; color: red;">в ALT Linux может использоваться и<br />[[NetworkManager/feature|NetworkManager]]</div> (используйте <tt>NM_CONTROLLED=no</tt><br />в {{path|$iface/options}}, если хотите использовать etcnet).<br />
|}<br />
|<br />
{| style="border:1px solid #AAA; background:#F9F9F9; width:155px; margin: 0 0 1em 1em; padding:.2em; float: right;" class=noprint<br />
|-<br />
|[[Image:Information.svg|20x20px]] external links:<br />
* [http://packages.altlinux.org/ru/Sisyphus/srpms/etcnet package info]<br />
* [http://git.altlinux.org/people/sbolshakov/packages/?p=etcnet.git;a=summary source git repo]<br />
|}<br />
|}<br />
<br />
<!-- Не убирайте div-ы, на них есть внешние ссылки! --><br />
<div id="quickstart"></div><br />
<br />
== Быстрый старт ==<br />
<div id="docs"></div><br />
<br />
=== Источники информации по /etc/net ===<br />
Обратите внимание, что начиная с версии 0.8.0 документация по /etc/net была собрана из комментариев, расположенных во множестве файлов, в несколько страниц руководств (man). Список всех файлов документации пакета <tt>etcnet</tt> можно получить командой:<br />
<pre>$ rpmquery -d etcnet</pre><br />
<br />
<div id="onecard"></div><br />
<br />
=== Быстрая настройка сетевого интерфейса стандарта Ethernet ===<br />
Для настройки одного сетевого интерфейса следует выполнить следующие шаги:<br />
<br />
Шаг 1: Создать каталог {{path|/etc/net/ifaces/eth0}}. Это каталог конфигурации данного интерфейса (<tt>eth0</tt>), в котором будут храниться файлы с настройками.<br />
<br />
Шаг 2: Определить, какой модуль необходим для вашей сетевой карты. Для этого можно использовать команды: <tt>lspci, lspcidrake, pciscan</tt>.<br />
<br />
Шаг 3: В каталоге конфигурации сетевого интерфейса создать файл <tt>options</tt> и записать в этот файл строку:<br />
<pre>MODULE=<имя модуля></pre> <br />
На данном этапе работу с файлом <tt>options</tt> можно завершить.<br />
<div style='padding:6px;border:1px solid red;'>Шаг 3 имеет смысл только в случае, если модули сетевых карт не грузятся автоматически другими средствами, например посредством udev. Если модуль уже загружен, параметр MODULE бесполезен.</div><br />
<br />
Шаг 4: Выяснить, какой IP-адрес должен быть назначен вашему интерфейсу. Если ваш сетевой интерфейс конфигурируется по DHCP, то в файл {{path|/etc/net/ifaces/eth0/options}} следует записать строку:<br />
<pre>BOOTPROTO=dhcp</pre><br />
и перейти к шагу 7.<br />
<br />
'''Замечание:''' В ряде случаев в файле <tt>options</tt> может понадобиться запись:<br />
<pre>DHCP_HOSTNAME=<имя машины без домена></pre><br />
Эта опция описана в странице руководства <tt>etcnet-options(5)</tt>.<br />
<br />
'''Замечание:''' В конце файла <tt>options</tt> необходимо наличие пустой строки.<br />
<br />
У сетевого интерфейса существуют два взаимосвязанных атрибута: <br />
* IP-адрес;<br />
* сетевая маска (mask). <br />
Шаг 5: Текущие значение адреса можно просмотреть командой:<br />
{{cmd|# /sbin/ip address show}} <br />
Вероятнее всего вы увидите, что интерфейс-петля lo (loopback) уже сконфигурирован с адресом 127.0.0.1/8 (что эквивалентно IP-адресу 127.0.0.1 и маске подсети 255.0.0.0). <tt>/8</tt> означает длину префикса CIDR (Classless InterDomain Routing).<br />
Для задания IP-адреса и маски подсети интерфейса <tt>eth0</tt> необходимо создать файл {{path|/etc/net/ifaces/eth0/ipv4address}}, в который следует записать IP-адрес с длиной маски, например:<br />
<pre>10.0.0.20/24</pre> <br />
<br />
Наиболее популярны маски /24 (т.е. длина префикса CIDR равная 24 эквивалентна маске сети 255.255.255.0 - это одна сеть класса C на 254 хоста) и /30. Для справки приводится таблица соответствия сетевых масок в различных нотациях.<br />
<ref><br />
{|<br />
|<br />
{| class="standard"<br />
|-<br />
!маска<br />в битах!!маска<br />точечно-<br />десятичная<br />
|-<br />
|/32||255.255.255.255<br />
|-<br />
|/31||255.255.255.254<br />
|-<br />
|/30||255.255.255.252<br />
|-<br />
|/29||255.255.255.248<br />
|-<br />
|/28||255.255.255.240<br />
|-<br />
|/27||255.255.255.224<br />
|-<br />
|/26||255.255.255.192<br />
|-<br />
|/25||255.255.255.128<br />
|-<br />
|/24||255.255.255.0<br />
|-<br />
|/23||255.255.254.0<br />
|-<br />
|/22||255.255.252.0<br />
|-<br />
|/21||255.255.248.0<br />
|-<br />
|/20||255.255.240.0<br />
|-<br />
|/19||255.255.224.0<br />
|-<br />
|/18||255.255.192.0<br />
|-<br />
|/17||255.255.128.0<br />
|}<br />
|<br />
| ||<br />
{| class="standard"<br />
|-<br />
!маска<br />в битах!!маска<br />точечно-<br />десятичная<br />
|-<br />
|/16||255.255.0.0<br />
|-<br />
|/15||255.254.0.0<br />
|-<br />
|/14||255.252.0.0<br />
|-<br />
|/13||255.248.0.0<br />
|-<br />
|/12||255.240.0.0<br />
|-<br />
|/11||255.224.0.0<br />
|-<br />
|/10||255.192.0.0<br />
|-<br />
|/9||255.128.0.0<br />
|-<br />
|/8||255.0.0.0<br />
|-<br />
|/7||254.0.0.0<br />
|-<br />
|/6||252.0.0.0<br />
|-<br />
|/5||248.0.0.0<br />
|-<br />
|/4||240.0.0.0<br />
|-<br />
|/3||224.0.0.0<br />
|-<br />
|/2||192.0.0.0<br />
|-<br />
|/1||128.0.0.0<br />
|}<br />
|}<br />
</ref><br />
<br />
Шаг 6: Выяснить адрес вашего шлюза (маршрут по умолчанию). Например, IP-адрес вашего шлюза — <tt>10.0.0.254</tt>. Тогда необходимо создать файл {{path|/etc/net/ifaces/eth0/ipv4route}}, в который записать строку:<br />
<pre>default via 10.0.0.254</pre><br />
Шаг 7: Убедиться, что всё выполнено правильно, выполнив команду:<br />
{{cmd|# service network restart}}<br />
Ваш интерфейс <tt>eth0</tt> должен быть успешно сконфигурирован. Если вы конфигурировали <tt>eth0</tt>, используя DHCP-сервер, но адрес интерфейсу не был назначен, то следует искать сообщение от DHCP-сервера в файле {{path|/var/log/messages}}.<br />
<br />
<div id="ifplugd"></div><br />
<br />
=== Настройка ifplugd ===<br />
Начиная с версии 0.7.10, /etc/net управляет ifplugd самостоятельно. Это было сделано для лучшей интеграции пакетов и для возможности следить за несколькими сетевыми интерфейсами одновременно. Для корректного использования ifplugd необходимо выполнить команду:<br />
# chkconfig ifplugd off<br />
<br />
и назначить переменную <tt>USE_IFPLUGD</tt> (USE_IFPLUGD=yes или USE_IFPLUGD=auto) в файлах <tt>options</tt> соответствующих интерфейсов (<tt>/etc/net/ifaces/<имя интерфейса>/options</tt>). Комментарий по данной переменной дан в странице руководства <tt>etcnet-options(5)</tt>.<br />
<br />
<div id="ppp"></div><br />
<br />
=== Настройка PPP-интерфейса ===<br />
Для настройки обычного модемного PPP-соединения необходимо:<br />
# Создать каталог конфигурации PPP-интерфейса, например, {{path|/etc/net/ifaces/ppp5}}. Вы можете задавать имена PPP-интерфейса вида pppN, pppNN, pppNNN и т. п., где N - любая цифра от 0 до 9;<br />
# Прочитать файл: {{path|/etc/net/ifaces/default/options-ppp}};<br />
# Создать файлы конфигурации. Вероятнее всего вам понадобятся <tt>pppconnect</tt> и <tt>pppdisconnect</tt>, чтобы <tt>pppd</tt> "знал", как дозваниваться и соединяться. Это скрипты для программы <tt>chat(8)</tt>. Кроме этого в файле <tt>pppoptions</tt> можно (часто нужно) перечислить опции <tt>pppd(8)</tt>, определяющие способ авторизации, скорость и название порта и т. п.;<br />
# Заполнить {{path|/etc/ppp/chap-secrets}} или {{path|/etc/ppp/pap-secrets}}.<br />
<br />
{{Attention|Использование опций "persist" и "maxfail 0", которые требуются pppd для непрерывных попыток восстановить интерфейс в случае проблем, может привести к невозможности загрузки системы в случае проблем с соединением. Вариант решения есть в {{altbug|23556#c1}} }}<br />
<br />
==== Настройка USB 3G-модема ====<br />
{{main|Установка и настройка 3G USB модема Huawei E1550}}<br />
<br />
<div id="ppp-pptp-pppoe"></div><br />
<br />
==== Настройка PPTP-интерфейса и PPPoE-интерфейса ====<br />
{{main|VPN (PPTP PPPoE)}}<br />
<br />
Хотя PPtP-соединения могут быть настроены и как обычные PPP-соединения, в /etc/net версии 0.7.10 для удобства пользователей была введена опция <tt>PPPTYPE</tt>. Она может принимать следующие значения:<br />
* <tt>dialup</tt> - обычный PPP-интерфейс.<br />
* <tt>pppoe</tt> - интерфейс PPPoE. Для такого интерфейса необходимо в опции <tt>HOST</tt> указывать имя Ethernet-интерфейса, через который будет производиться работа PPPoE. Побочным положительным эффектом будет то, что этот интерфейс будет при необходимости автоматически подниматься (т.е настраиваться) (см. [[#Зависимости между интерфейсами|Зависимости между интерфейсами]]).<br />
* <tt>pptp</tt> - интерфейс PPTP. Для такого интерфейса необходимо в опции <tt>PPTP_SERVER</tt> указывать имя хоста или IP-адрес PPtP-сервера, к которому будет производиться подключение. Обратите внимание, что хотя такие интерфейсы не имеют опции <tt>HOST</tt>, в большинстве случаев есть необходимость указать в опции <tt>REQUIRES</tt> интерфейс, через который будет достижим хост, указанный в <tt>PPTP_SERVER</tt>.<br />
<br />
См. также [[#Замечания о настройке VPN-подключения и туннелей|Замечания о настройке VPN-подключения и туннелей]].<br />
<br />
<div id="DNSandPPP"></div><br />
<br />
==== DNS и PPP-соединения ====<br />
<div style="display: inline; color: red;">Внимание: здесь описывается проблема, которая на самом деле была создана, а не решена — т.е. ради специфики [https://bugzilla.altlinux.org/show_bug.cgi?id=13789 kppp] была создана чётная ошибка в [https://bugzilla.altlinux.org/show_bug.cgi?id=13773 ppp-common]; последняя уже исправлена.</div><br />
<br />
Довольно долгое время существовала проблема неправильной модификации {{path|/etc/resolv.conf}} при установке PPP-соединений: [https://bugzilla.altlinux.org/show_bug.cgi?id=4249 #4249]. Сейчас она решена, но необходимо дать пояснения. Прежде всего убедитесь, что в файле {{path|/etc/resolv.conf}} есть строка:<br />
<pre># ppp temp entry</pre><br />
Если этой строки нет, то в файле не будут модифицироваться строки nameserver, если только какая-нибудь программа типа kppp это не сделает специально. Если такая строка есть, то {{path|/etc/resolv.conf}} будет модифицироваться в зависимости от значения булевой (логической) переменной RESOLV_MODS, которую необходимо задать в файле {{path|/etc/sysconfig/network}}.<br />
<br />
<div style="display: inline; color: red;">Внимание</div>: при ppp-common >= 0.4-alt1 строки <tt># ppp temp entry</tt> в файле {{path|/etc/resolv.conf}} при отсутствии PPP-соединения, поднятого какой-либо программой-«звонилкой», запущенной от администратора системы (пользователь root) — быть '''не должно'''! Если это есть, следует убрать, чтобы {{cmd|/etc/ppp/ip-up}} занимался обновлением записей про DNS в этом файле.<br />
<br />
<div id="restartreload"></div><br />
<br />
=== restart, reload и другие команды ===<br />
У сервиса <tt>network</tt> имеется ряд команд:<br />
* <tt>start</tt> - запустить все стационарные интерфейсы. hotplug-интерфейсы будут сконфигурированы при поступлении соответствующего вызова от hotplug.<br />
* <tt>startwith <имя профиля> </tt> - старт с указанным именем профиля, а не определённым автоматически.<br />
* <tt>stop</tt> - остановить все стационарные интерфейсы. hotplug-интерфейсы будут расконфигурированы при поступлении соответствующего вызова от hotplug.<br />
* <tt>stopwith <имя профиля> </tt> - стоп с указанным именем профиля, а не определённым автоматически.<br />
* <tt>restart</tt> - эквивалентно <tt>stop</tt> с последующим <tt>start</tt>, как и в большинстве других сервисов.<br />
* <tt>restartwith <имя профиля> </tt> - рестарт в контексте указанного профиля, эквивалентно <tt>stopwith <имя профиля> и startwith <имя профиля></tt>.<br />
* <tt>switchto <имя профиля> </tt> - переключение в указанный профиль, эквивалентно <tt>stop</tt> и <tt>startwith <имя профиля></tt>.<br />
* <tt>reload</tt> - семантически обозначает «актуализировать текущую конфигурацию». Для всех сконфигурированных в настоящий момент интерфейсов будет выполнена реконфигурация при наличии конфигурации.<br />
* <tt>check</tt> - автоматическая проверка конфигурационной базы.<br />
<br />
<div id="bootproto"></div><br />
<br />
=== Протоколы конфигурации адресов ===<br />
С помощью опции <tt>BOOTPROTO</tt> вы можете управлять тем, как у интерфейса будут появляться адреса и маршруты (это относится только к протоколу IPv4, так как протоколы IPv6 и IPX получают адреса только статически).<br />
* <tt>static</tt> — адреса и маршруты будут взяты из <tt>ipv4address</tt> и <tt>ipv4route</tt>.<br />
* <tt>dhcp</tt> — интерфейс будет сконфигурирован по DHCP.<br />
* <tt>ipv4ll</tt> — интерфейс будет сконфигурирован с помощью IPv4LL (link-local), ранее известному как ZCIP (zeroconf IP). Это значит, что из сети 169.254.0.0/16 будет подобран ещё не использованный адрес и назначен на интерфейс.<br />
Существует несколько комбинированных способов:<br />
* <tt>dhcp-static</tt> — если конфигурация по DHCP не удалась, конфигурировать методом static.<br />
* <tt>dhcp-ipv4ll</tt> — если конфигурация по DHCP не удалась, конфигурировать методом ipv4ll.<br />
* <tt>dhcp-ipv4ll-static</tt> — если конфигурация по DHCP не удалась, конфигурировать методом ipv4ll. Если и это не удалось, конфигурировать методом static.<br />
<br />
<div id="internals"></div><br />
<br />
=== Интеграция с systemd ===<br />
Начиная с версии 0.9.12 в etcnet добавлен Unit для включения интерфейсов по мере их появления в системе. Это позволяет избежать "гонок", когда сетевая подсистема поднимается раньше, чем ОС загружает драйвера для сетевых устройств.<br />
Для этого нужно выставить <tt>ONBOOT=no</tt> в файле options интерфейса и включить его подъём через systemd при загрузке: <tt>systemctl enable network@<имя интерфейса></tt>.<br />
<br />
== Устройство /etc/net ==<br />
<div id="generalinfo"></div><br />
<br />
=== Общие сведения ===<br />
/etc/net — это система конфигурации сети в Linux, т.е. эта система позволяет администратору Linux достаточно просто произвести настройки сети. Если же вы читаете эту страницу, то, вероятно, у вас возникли трудности с её использованием. Для решения возможных проблем полезно знать:<br />
<br />
<!--# [http://etcnet.org/ http://etcnet.org/] - сайт проекта, на котором можно найти примеры конфигурации и статьи по настройке системы. ?Рекурсия? --><br />
# /etc/net интегрирован в ALT Linux Sisyphus в виде пакетов:<br />
#* {{pkg|etcnet}} - базовые сценарии;<br />
#* {{pkg|etcnet-full}} - виртуальный пакет с зависимостями на все пакеты, которые могут использоваться сценариями /etc/net, с указанием их точных версий;<br />
#* {{pkg|etcnetconf}} - '''прототип''' конфигуратора;<br />
#* {{pkg|etcnet-defaults-desktop}} - умолчания для рабочей станции;<br />
#* {{pkg|etcnet-defaults-server}} - умолчания для сервера; <br />
# Пакеты {{pkg|etcnet}} и {{pkg|net-scripts}} — две конфликтующие реализации «подсистемы конфигурации сети» (network-config-subsystem).<br />
# При установке etcnet вместо net-scripts (или наоборот) сервис <tt>network</tt> оказывается выключенным. Это означает, что при загрузке системы сеть не будет сконфигурирована, что можно проверить командой {{cmd|chkconfig --list network}}. Для быстрого исправления проблемы можно дать команду {{cmd|chkconfig network reset}}.<br />
# etcnet '''НЕ''' импортирует автоматически настройки net-scripts. Если вы только что установили etcnet, и ваши сетевые интерфейсы всё ещё остаются сконфигурированными (несмотря на уже отсутствующий пакет net-scripts), то вы можете запустить сценарий {{cmd|/etc/net/scripts/initconf}}. Он попытается проанализировать текущее состояние интерфейсов и выведет вам результат. Никаких файлов при этом записано не будет. Если вам подходит вывод initconf, то запустите его с параметром write и он проделает то же самое, но уже с сохранением конфигурации.<br />
# Для корректной работы системы в целом необходимо, чтобы содержимое файла {{path|/etc/sysconfig/network}} было корректным.<br />
# Переменные <tt>sysctl</tt> в ОС ALT Linux конфигурируются в следующих местах<ref>{{altbug|26498}}</ref>:<br />
#* {{path|/etc/sysctl.conf}} (глобальные системные);<br />
#* {{path|/etc/sysconfig/network-scripts/sysctl.conf}} (общие сетевые в net-scripts, исходно файл не существует);<br />
#* {{path|/etc/net/sysctl.conf}} (общие сетевые в /etc/net);<br />
#* <tt>/etc/net/ifaces/*/sysctl.conf*</tt> (частные для конкретных интерфейсов или их типов в /etc/net, создаются вручную при необходимости).<br />
Скрипты etcnet используют эти файлы в указанном порядке.<br />
<br />
<div id="options.d"></div><br />
<br />
=== Организация опций /etc/net по умолчанию ===<br />
Методология /etc/net предусматривает несколько шагов наследования опций, первый из которых — загрузка опций по умолчанию. В ранних версиях это происходило из одного файла <tt>/etc/net/options</tt>, сейчас же в вашем распоряжении есть каталог {{path|/etc/net/options.d}}, из которого будут последовательно прочитаны все файлы.<br />
<br />
Иными словами, оригинальный архив etcnet содержит только файл {{path|/etc/net/options.d/00-default}}. Упаковщик etcnet, вместо того, чтобы добавить патч в какой-либо дистрибутив, просто добавляет файл с бОльшим номером, который переопределяет нужные опции.<br />
<br />
Ввиду решения различных задач, администратору системы может не подойти содержание дистрибутивного набора. В этом случае администратор может создать файл с ещё более высоким номером и определить настройки умолчания для своей системы. В результате такого подхода:<br />
# Уменьшается количество патчей (хотя их свойство "отваливаться" от пакета при его упаковке бывает полезным).<br />
# Не изменяются файлы с опциями, принадлежащие пакету. Это делает обновление пакета намного более корректным.<br />
# Можно легко увидеть, какие опции переопределяются на каждом этапе.<br />
<br />
<div id="iftab"></div><br />
<br />
=== Назначение iftab ===<br />
<br />
Начиная с дистрибутивов, основанных на ветках p5 и 5.1, переименование интерфейсов возложено на udev; см. тж. [http://lists.altlinux.org/pipermail/sisyphus/2009-June/340033.html это письмо] и <s>[https://bugzilla.altlinux.org/show_bug.cgi?id=19313 #19313]</s> и [http://packages.altlinux.org/ru/Sisyphus/srpms/wireless-tools/changelog %changelog ifrename]. В дистрибутивах на базе p8 и новее может быть полезным пакет udev-rule-generator-net, который заполняет /etc/udev/rules.d/70-persistent-net.rules. Возможно, следует отказаться от имён интерфейсов вида ethN и использовать, например, etherN ввиду того, что в новом systemd/udev официально сломан механизм переименования. Данное нововведение в ALT пока отменено; см. тж. [https://bugzilla.altlinux.org/32167 #32167].<br />
<br />
Имена сетевых интерфейсов по умолчанию, как правило, содержат их тип (eth, ppp, wifi, ipsec) и индекс: 0 - для первого созданного интерфейса, 1 - для второго и т. д. При этом соответствие автоматически назначенных имён физическим устройствам может не сохраняться.<br />
<br />
Эта особенность неудобна, когда машина с Linux имеет более одного интерфейса каждого типа. Типичными примерами являются маршрутизаторы и ноутбуки. В маршрутизаторах, как правило, используются однотипные сетевые карты и при их замене или изменении порядка на PCI-шине соответствие оказывается нарушенным. В ноутбуках используются ethernet и wifi-устройства с горячим подключением, при этом слотов и карт может быть более чем 1. В этом случае пользователь/администратор скорее всего пожелает закрепить за каждой сменной картой её конфигурацию.<br />
<br />
/etc/net при конфигурации интерфейса использует то имя, под которым он сконфигурирован, а именно имя каталога, в котором хранятся файлы конфигурации интерфейса.<br />
<br />
Для привязки сетевой карты к имени интерфейса в простых случаях можно воспользоваться файлом {{path|/etc/iftab}}, man-страница по формату которого входит в пакет <tt>ifrename</tt> (<tt>iftab(5)</tt>).<br />
<br />
Использование {{path|/etc/iftab}} удобно, поскольку позволяет сохранять традиционные имена интерфейсов (например, eth0), но этот механизм не поддерживает расширенную функциональность /etc/net (в частности, ''профили'' /etc/net).<br />
<br />
Средством, позволяющим использовать все возможности <tt>etcnet</tt>, является файл {{path|/etc/net/iftab}}, обрабатываемый не утилитой <tt>ifrename</tt>, а непосредственно <tt>etcnet</tt>. Синтаксис этого файла совпадает с синтаксисом {{path|/etc/iftab}}. Ограничением же является невозможность использовать стандартные имена интерфейсом (<tt>ethX</tt>, <tt>pppX</tt>), так как переименование интерфейсов происходит уже после конфигурации интерфейса ядром. В случае, если вам необходим {{path|/etc/net/iftab}}, имеет смысл переименовать интерфейсы, давая им либо двухзначные номера (<tt>eth00</tt>, <tt>eth01</tt>...), либо осмысленные названия (<tt>isplink</tt>, <tt>lan</tt>...)<br />
<br />
См. письмо про [http://lists.altlinux.org/pipermail/sisyphus/2009-March/337924.html важность /etc/iftab]<br />
и тж. это письмо про [http://lists.altlinux.org/pipermail/devel/2007-October/065097.html отличия etcnet и сервиса ifrename]:<br />
{{начало цитаты}} Комментарии к письмам этого треда (с некоторыми пояснениями):<br />
<br />
1. «etcnet уже научился менять местами eth0 и eth1?»<br />
<br />
Освоение этого приема обладает сомнительной пользой. Рекомендуется <br />
рассматривать eth0 как временное имя с малым сроком жизни,<br />
а для повышения комфорта пользователей Ethernet-интерфейсы предлагается<br />
называть eth00, eth01, eth02 etc.<br />
<br />
2. «Существование (номинальное) net-scripts вынуждает поддерживать<br />
ряд сервисов, которые иначе могли бы быть упразднены»<br />
<br />
Эти сервисы можно "обезвредить" (отключить) контролем CONFMETHOD<br />
из /etc/sysconfig/network. При этом зависимости на пакет etcnet<br />
не возникнет, только на network-config-subsystem. Примеры таких<br />
пакетов должны быть в Sisyphus.<br />
<br />
3. «после приведения в порядок /etc/udev/rules.d/19-udev-ifrename.rules<br />
нужности в /etc/net/iftab я не заметил»<br />
<br />
Важнейшее принципиальное отличие /etc/net/iftab от /etc/iftab —<br />
нахождение /etc/net/iftab в специальном пространстве имён. Для него<br />
действуют механизмы определения профиля и хоста конфигурации. Это,<br />
например, позволит, при необходимости, составить конфигурацию так, что срочный<br />
ремонт маршрутизатора сведётся к переносу диска (или массива)<br />
из сгоревшего шасси в запасное. Возможны и другие примеры, которые<br />
станут невозможными при помещении iftab в /etc и его прямой<br />
интерпретации.<br />
<br />
Конечно, пользователю единственного ноутбука с одним-двумя сетевыми<br />
интерфейсами такая практика — полный overkill (т.е. такая практика ему не нужна), но его никто и не<br />
заставляет видеть всю подводную часть (т.е. все тонкости работы и настройки). В этом и гибкость.{{конец цитаты}}<br />
<br />
<div id="specifaces"></div><br />
<br />
=== Интерфейсы lo, default и unknown ===<br />
Сразу после установки пакета <tt>etcnet</tt> в каталоге {{path|/etc/net/ifaces}} (в котором хранятся конфигурации интерфейсов) находятся три каталога: <br />
* lo<br />
* default<br />
* unknown<br />
<br />
Интерфейс '''lo''' — стандартная "петля" (loopback), которая должна быть во всякой Linux-системе, поэтому конфигурация для него включена по умолчанию. В остальном он ничем не отличается от любого другого интерфейса и конфигурируется точно так же файлами <tt>options</tt> и <tt>ipv4address</tt>.<br />
<br />
Интерфейс '''default''' — это не интерфейс, а специальный каталог, файлы в котором обрабатываются следующим образом:<br />
* <tt>resolv.conf</tt> — если присутствует, то копируется в {{path|/etc/resolv.conf}}.<br />
* <tt>options</tt> — файл опций, читается после опций по умолчанию.<br />
* <tt>options-<вид интерфейса></tt> — этот файл содержит опции, специфичные для данного вида интерфейсов. Некоторые из них не обязательны и позволяют использовать особенности данного вида интерфейсов, например, <tt>LINKDETECT</tt> в <tt>options-eth</tt>; другие обязательны, например, <tt>HOST</tt> в <tt>options-bri</tt>. Обратите внимание, что эти файлы не рекомендуется редактировать. Если вам нужно задать опцию для интерфейса, то, как правило, это можно сделать в файле <tt>options</tt> в конфигурационном каталоге данного интерфейса. Это облегчит процесс обновления пакета etcnet.<br />
* <tt>sysctl.conf-<вид интерфейса></tt> — файл с переменными sysctl, которые необходимо изменить. Сейчас единственный такой файл — <tt>sysctl.conf-dvb</tt>, который отключает <tt>return path filter</tt>, что всегда нужно в случае асимметричной маршрутизации.<br />
* <tt>iplink-<вид интерфейса></tt> — файл с командами iplink, специфичными для данного вида.<br />
* <tt>selectprofile</tt> — если этот файл исполняемый, то он будет вызван из сценариев <tt>ifup/ifdown</tt>, <tt>setup/shutdown</tt> для того, чтобы вернуть на стандартном выводе имя профиля, которое необходимо использовать. Это позволяет автоматически переключать профили в зависимости от каких-либо условий. В поставку включен пример сценария: {{path|/etc/net/scripts/contrib/selectprofile}}.<br />
* <tt>fw</tt> — каталог с настройками сетевого экрана по умолчанию.<br />
<br />
Интерфейс '''unknown''' — специальная конфигурация, которая будет использована в том случае, когда /etc/net просят сконфигурировать hotplug-интерфейс, для которого не существует каталога конфигурации. Это будет работать только в том случае, если включена опция <tt>ALLOW_UNKNOWN</tt>.<br />
<br />
<div id="broadcast"></div><br />
<br />
=== broadcast address===<br />
<br />
Периодически возникает вопрос: почему после старта /etc/net при запуске <tt>ifconfig</tt> можно видеть <tt>Bcast:0.0.0.0</tt>, хотя при использовании net-scripts это поле было правильным? <br />
<br />
Ответ: net-scripts оперируют адресом, маской, адресом сети и широковещательным адресом, пытаясь определить неизвестные компоненты из известных, а <tt>config-ipv4</tt> просто передаёт утилите <tt>ip</tt> содержимое файла <tt>ipv4address</tt>, не проверяя его содержание.<br />
Важно заметить, что:<br />
* Если <tt>iproute2</tt> изменит свой синтаксис, то с очень вероятно, что администратору будет необходимо редактировать только конфигурационные файлы.<br />
* Не было найдено проблем с «отсутствующим» broadcast address. Он есть в таблице маршрутизации <tt>local</tt>. <br />
* Администратор всегда может назначить адрес broadcast в файле <tt>ipv4address</tt>. Это можно сделать с помощью выражения <tt>broadcast +</tt><ref><br />
Выдержка из файла ip-cref.ps, который входит в документацию пакета iproute2:<br />
<br />
<pre><br />
* broadcast ADDRESS<br />
<br />
the broadcast address on the interface.<br />
It is possible to use the special symbols '+' and '-' instead of the broadcast address. In this case, <br />
the broadcast address is derived by setting/resetting the host bits of the interface prefix.<br />
NB. Unlike ifconfig, the ip utility does not set any broadcast address unless explicitly requested.<br />
</pre><br />
</ref>.<br />
'''Замечание:''' В версии 0.8.0 появилась опция <tt>AUTO_BROADCAST</tt> для автоматического дополнения каждой строки <tt>ipv4address</tt>.<br />
<br />
<div id="never_rmmod"></div><br />
<br />
=== Ядро 2.6 и "пропадающие" интерфейсы ===<br />
Иногда возможна ситуация: Если два интерфейса используют один и тот же модуль ядра, и у них определена опция <tt>MODULE</tt> (то есть скрипты /etc/net сами загружают и выгружают модули), то при опускании (отключении) одного интерфейса пропадает и второй интерфейс. <br />
<br />
Такая ситуация почти наверняка возникает при использовании ядра 2.6, особенностью которого являются значения счётчика ссылок (третий столбец вывода {{cmd|lsmod}}). Когда счетчик оказывается равен нулю (довольно часто), скрипты могут попытаться выгрузить модуль интерфейса, для которого запущен ifdown. И такая выгрузка происходит, несмотря на то, что другой интерфейс, использующий этот же модуль, находится в состоянии UP (т.е. он активен).<br />
<br />
Чтобы заблокировать выгрузку модулей, можно использовать булеву переменную <tt>NEVER_RMMOD</tt>. Возможно, позже это будет происходить автоматически для ядер следующих версий.<br />
<br />
<div id="removables"></div><br />
<br />
=== Cценарии конфигурации сети и hotplug-интерфейсы ===<br />
<br />
==== Cценарии конфигурации сети ====<br />
Существует несколько сценариев конфигурации сети.<br />
<br />
* Первый и самый простой — выполнение {{cmd|service network start}} при старте системы или вручную. При этом требуется только сформировать погруппные (потиповые) списки интерфейсов, подлежащих обработке, и последовательно выполнить требуемые действия. Модули ядра при этом загружаются сценариями /etc/net, при этом имена модулей берутся из опции <tt>MODULE</tt> (в этой опции можно в кавычках перечислить несколько имён и они будут последовательно загружены). Этот метод часто используется на практике и лучше всего подходит для маршрутизаторов. Преимущество метода в том, что вся необходимая информация сконцентрирована в одном месте — каталоге {{path|/etc/net}}. Если опция <tt>MODULE</tt> не определена, то будет предпринята попытка загрузки по имени интерфейса, подразумевая, что файл {{path|/etc/modules.conf}} правильно заполнен.<br />
<br />
* Второй сценарий — реакция на событие <tt>ifplugd</tt>. В предыдущих версиях существовала сложность, так как требовалась синхронная настройка сервиса <tt>ifplugd</tt>. Сейчас логика работы определена, что выражено в том, что /etc/net взяла управление <tt>ifplugd</tt> на себя. В части загрузки модуля этот сценарий не отличается от первого.<br />
<br />
* Третий сценарий — реакция на появление или исчезновение сменного устройства. Для обработки таких событий предназначены сценарии <tt>/etc/net/scripts/{ifup,ifdown}-removable</tt>, которые вызываются из сценариев пакетов hotplug и pcmcia-cs. Сложность заключается в том, что для сменных PCMCIA-карт вызовы могут дублироваться: для одного и того же события первый раз ifup-removable будет вызван из hotplug, второй — из pcmcia-cs. Кроме того, hotplug также реагирует на загрузку модулей ядра для обычных карт PCI и, более того, включает сценарии, которые пытаются загружать модули самостоятельно. В этом контексте /etc/net получает слишком много вызовов от hotplug и по умолчанию их игнорирует (<tt>USE_HOTPLUG=no</tt>).<br />
<br />
==== hotplug-интерфейсы ====<br />
Рассмотрим использование hotplug-интерфейсов. <br />
<br />
Пусть администратору необходимо настроить действительно сменную карту. После заполнения {{path|/etc/iftab}} или {{path|/etc/net/iftab}} в файле <tt>options</tt> необходимо будет задать <tt>USE_HOTPLUG=yes</tt>. После этого при получении события от hotplug /etc/net будет работать в том контексте, что модуль в загрузке и выгрузке не нуждается. <br />
<br />
Важно заметить, что '''такой интерфейс будет пропущен при обычном старте сети''', т.к. если он сменный, то единственный достоверный способ узнать, что он присутствует — получить вызов от hotplug. Из факта выполнения {{cmd|service network start}} совсем не следует, что какой-то один или несколько из сконфигурированных hotplug-интерфейсов сейчас в наличии и требуют конфигурации. Если вы хотите вручную расконфигурировать hotplug-интерфейс до его извлечения, используйте команду {{cmd|ifdown}}. Для повторной конфигурации вставьте его ещё раз.<br />
<br />
Также существует опция <tt>USE_PCMCIA</tt>. Если события для вашей карты генерирует pcmcia-cs, то вам нужно её включить. Если события генерируются только hotplug, то используйте опцию <tt>USE_HOTPLUG</tt>.<br />
<br />
<div id="eth0"></div><br />
<br />
=== Проблема стандартных имен интерфейсов (eth0 и др.)===<br />
<br />
При использовании файла {{path|/etc/net/iftab}}, то есть в случае применения сложных конфигураций, возникает следующая проблема:<br />
* При загрузке модулей имена интерфейсов принимают вид eth0, eth1, eth2… Какие именно — в общем случае контролировать нельзя.<br />
* Имя eth0 обладает наибольшей вероятностью оказаться занятым.<br />
* ifrename не может переименовать интерфейс, если целевое имя уже занято (udev использует <tt>ifrename -t</tt>, но это не работает после начальной загрузки, см. руководство к ifrename).<br />
<br />
С учётом вышеизложенного, если {{path|/etc/net/iftab}} содержит тот же набор имён интерфейсов, что уже имеется после загрузки модулей (то есть <tt>eth0</tt>/<tt>eth1</tt> и другие «стандартные» названия), то единственный случай, когда etcnet сможет без ошибок обработать такой файл — изначальное соответствие, не требующее переименования.<br />
<br />
Таким образом, при использовании {{path|/etc/net/iftab}} имеет смысл давать интерфейсам названия, отличные по виду от тех, что назначает ядро. В простых случаях лучше использовать {{path|/etc/udev/rules.d/70-persistent-net.rules}} ({{path|/etc/iftab}} до бранчей p5/5.1).<br />
<br />
<div id="advanced"></div><br />
<br />
== Расширенные возможности ==<br />
<div id="multipleIPs"></div><br />
<br />
=== Несколько IP-адресов или маршрутов на одном интерфейсе ===<br />
<br />
Вы можете помещать произвольное количество IP-адресов в файл <tt>ipv4address</tt> по одному адресу на каждой строке. То же самое относится к статическим маршрутам и файлу <tt>ipv4route</tt>.<br />
<br />
Обратите внимание, что /etc/net не анализирует содержимое этих файлов, а формирует на основе каждой строки командную строку для утилиты {{cmd|ip}}. Это означает, что вы можете помещать в этих файлах произвольные поддерживаемые {{cmd|ip}} опции и они будут обработаны. Например, в файле <tt>ipv4route</tt> можно поместить строку:<br />
<pre>10.0.1.0/24 via 10.0.0.253 metric 50 weight 5 table 100</pre><br />
<br />
<div id="requires"></div><br />
<br />
=== Зависимости между интерфейсами ===<br />
У интерфейсов:<br />
* vlan<br />
* bond <br />
* bri <br />
* teql <br />
входящих в группу зависимых физических, должна быть определена опция <tt>HOST</tt> со списком интерфейсов, необходимых для инициализации текущего интерфейса. Если хост-интерфейс не сконфигурирован при поднятии зависимого интерфейса, то это будет исправлено.<br />
<br />
Кроме обязательной для определённых интерфейсов опции <tt>HOST</tt>, может быть задана и необязательная для всех остальных интерфейсов опция <tt>REQUIRES</tt>. Интерфейсы, перечисленные в этой опции, будут считаться зависимостями текущего интерфейса. Например, по умолчанию попытка сконфигурировать интерфейс А, который зависит от Б и В, приведёт сначала к конфигурации Б и В. Аналогично, при расконфигурации Б или В сначала будет расконфигурирован А.<br />
<br />
Зависимость одного интерфейса от другого не всегда формальна. Например, в сценарии <tt>ifup-pre</tt> одного интерфейса может использоваться команда, которая потребует разрешения DNS-имени, которое может быть разрешено только с помощью <tt>resolv.conf</tt>, инсталлируемого другим интерфейсом. Или это может быть PPPoE/PPtP-интерфейс, требующий Ethernet-интерфейс для работы.<br />
<br />
Для того, чтобы избежать неожиданных сбоев в таких случаях, правильно задавайте опцию <tt>REQUIRES</tt>.<br />
<br />
<div id="postpre"></div><br />
<br />
=== Пользовательские сценарии post и pre ===<br />
Существует возможность поместить в каталог конфигурации интерфейса файлы, которые будут выполнены в определённые моменты. Для этого они должны быть исполняемыми и называться следующим образом:<br />
* <tt>ifup-pre</tt> — для выполнения перед конфигурированием интерфейса.<br />
* <tt>ifup-post</tt> — для выполнения после конфигурирования интерфейса. Например, можно запустить почтовую систему.<br />
* <tt>ifdown-pre</tt> — для выполнения перед расконфигурированием интерфейса. Например, можно остановить почтовую систему.<br />
* <tt>ifdown-post</tt> — для выполнения после расконфигурирования интерфейса.<br />
<br />
Также в версии до 0.8.0 возможно использовать следующие сценарии (они должны быть исполняемыми):<br />
* <tt>/etc/net/scripts/ifup-pre-local</tt><br />
* <tt>/etc/net/scripts/ifup-post-local</tt><br />
* <tt>/etc/net/scripts/ifdown-pre-local</tt><br />
* <tt>/etc/net/scripts/ifdown-post-local</tt><br />
<br />
Они будут вызваны для каждого интерфейса. Начиная с версии 0.8.0 эти сценарии называются так:<br />
* <tt>/etc/net/ifup-pre</tt><br />
* <tt>/etc/net/ifup-post</tt><br />
* <tt>/etc/net/ifdown-pre</tt><br />
* <tt>/etc/net/ifdown-post</tt><br />
Семантика сохранена.<br />
<br />
<div id="iplink"></div><br />
<br />
=== Управление канальными параметрами интерфейсов ===<br />
<br />
Если поместить в конфигурационный каталог интерфейса файл <tt>iplink</tt>, в котором в каждой строке будут записаны команды режима link утилиты {{cmd|ip}}, то они будут выполнены при конфигурации интерфейса. <br />
<br />
Например, если необходимо, чтобы интерфейс net1 имел MAC-адрес aa:bb:cc:dd:ee:ff и MTU 200 байт, то в файл {{path|/etc/net/ifaces/net1/iplink}} нужно поместить следующее:<br />
<pre>address aa:bb:cc:dd:ee:ff<br />
mtu 200</pre><br />
<br />
Обратите внимание, что в этом случае в {{path|/etc/net/iftab}} вам необходимо будет использовать селектор <tt>businfo</tt> или <tt>driver</tt> вместо <tt>mac</tt>.<br />
<br />
<div id="ethtool"></div><br />
<br />
=== Управление физическими параметрами интерфейсов ===<br />
Если поместить в конфигурационный каталог интерфейса файл <tt>ethtool</tt>, в котором будет строка с параметрами программы ethtool, то она будет выполнена при конфигурации интерфейса. <br />
<br />
Например, если есть необходимость, чтобы интерфейс net1 имел скорость 10Мбит/с и авто-согласование скорости было отключено, то в файл {{path|/etc/net/ifaces/net1/ethtool}} нужно поместить следующую строку:<br />
<br />
<pre>speed 10 autoneg off</pre><br />
<br />
<div id="bridge"></div><br />
<br />
=== Настройка Ethernet-моста ===<br />
<br />
Для настройки Ethernet-моста (далее — моста) есть 3 пути: <br />
# Linux bridge посредством bridge-utils<br />
# Linux bridge посредством iproute2<br />
# Openvswitch<br />
<br />
Linux bridge наиболее простая реализация. Если вам не нужно все, что умеет [http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=README;hb=HEAD openvswitch] , то можно использовать Linux bridge.<br />
<br />
==== Linux bridge посредством bridge-utils (до p8 включительно) ====<br />
Перед настройкой Ethernet-моста (далее — моста) с помощью etcnet сначала необходимо убедиться, что установлен пакет bridge-utils. Etcnet использует утилиту brctl для настройки моста, и, если утилита не установлена, то при перезапуске системы сеть станет недоступна. Если интерфейсы, входящие в состав моста, являются единственными физически подключенными и настройка моста происходит с удаленного узла через эти интерфейсы, то требуется соблюдать осторожность, т.к. эти интерфейсы перестанут быть доступны. В случае ошибки в конфигурации потребуется физический доступ к серверу. Для страховки, перед перезапуском сервиса network можно открыть ещё одну консоль и запустить там, например, команду: {{cmd|sleep 500 && reboot}}.<br />
<br />
Также имейте ввиду, что если вы подключаетесь по ssh к серверу через bridge-интерфейс (по его ip-адресу), то по умолчанию при опускании любого интерфейса-члена моста Etcnet так же опустит и сам мост (и ваше подключение пропадет). Чтобы избежать этого, установите в файле {{path|options}} того интерфейса, который нужно опускать, переменную <tt>IFDOWN_CHILDREN=no</tt>. Но учтите, что и включаться в бридж при старте тогда этот интерфейс по умолчанию не будет. <br />
<br />
Предположим, требуется настроить Ethernet-мост, пусть он будет называться <tt>br0</tt>. <br />
Тогда для его настройки необходимо завести каталог {{path|/etc/net/ifaces/br0}} и создать там файлы со следующими данными:<br />
<br />
* <tt>brctl</tt><br />
<br />
<pre> stp AUTO on </pre><br />
<br />
* <tt>ipv4address</tt>:<br />
<pre> 192.168.100.200/24 </pre><br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=bri<br />
HOST='eth0 tap0'<br />
BOOTPROTO=static </pre><br />
<br />
Содержимое файла <tt>brctl</tt> передаётся утилите brctl. <tt>AUTO</tt> означает, что скрипт {{cmd|setup-bri}} самостоятельно определит имя bridge-интерфейса (см. файл {{path|/usr/share/doc/etcnet-*/README.bridge}}). Если же в вашей сети этот мост один и рассылать пакеты протокола STP не нужно, тогда файл brctl с указанной опцией не нужен. По умолчанию [http://xgu.ru/wiki/man:brctl#Spanning_Tree_Protocol_.28.D0.9F.D1.80.D0.BE.D1.82.D0.BE.D0.BA.D0.BE.D0.BB_.D0.BE.D1.81.D1.82.D0.BE.D0.B2.D0.BD.D0.BE.D0.B3.D0.BE_.D0.B4.D0.B5.D1.80.D0.B5.D0.B2.D0.B0.29 STP выключен].<br />
<br />
IP-адрес для интерфейса, как обычно, будет взят из <tt>ipv4address</tt>.<br />
<br />
В опции <tt>HOST</tt> файла <tt>options</tt> нужно указать те интерфейсы, которые будут входить в мост. Если в него будут входить интерфейсы, которые до этого имели IP-адрес (например, eth0), то этот адрес должен быть удалён (например, можно закомментировать содержимое файла {{path|ifaces/eth0/ipv4address}}).<br />
<br />
При старте сети сначала поднимаются интерфейсы, входящие в мост, затем сам мост (автоматически). Для назначения адреса мосту можно также использовать DHCP (<tt>BOOTPROTO=dhcp</tt>). Но при этом важно обратить внимание на параметр <tt>forwarding delay</tt> (man brctl / setfd), так как интерфейс, подключенный к мосту, не сразу входит в режим передачи пакетов, и это может вызвать dhcp таймаут. Версии etcnet в дистрибутивах ALT Linux Server 4 и Desktop 4.1 (0.9.7-alt0.M40/M41) имеют эту недоработку, которая исправлена только в версии 0.9.9-alt1. <br />
Документацию по настройке моста с вопросами и ответами (перевод) можно найти на http://xgu.ru/wiki/Linux_Bridge, а его оригинал доступен на http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge.<br />
<br />
Внимание: инструкция на xgu.ru чуть устарела. Команда<br />
<pre>$ brctl setfd br0 0</pre><br />
не выключает задержку, а лишь приводит к величине задержки по умолчанию (15 или даже 30 секунд). Можно попробовать задать задержку в 1сек для уменьшения времени инициализации сети.<br />
<br />
С пакетом etcnet поставляются примеры конфигурации. Один из них показывает, как из двух ethernet-интерфейсов port0 и port1 можно собрать мост bridge (каталог документации examples/Ethernet-bridge-GRE/).<br />
<br />
Безотносительно к etcnet, следует иметь ввиду проблему, связанную с NAT: <s>[http://bugzilla.kernel.org/show_bug.cgi?id=13079 http://bugzilla.kernel.org/show_bug.cgi?id=13079]</s><br />
<br />
==== Linux bridge посредством iproute2 (начиная с p9) ====<br />
Надо описать, пока только ссылка на дискуссию в момент перехода: https://lists.altlinux.org/pipermail/devel/2018-October/205769.html<br />
==== openvswitch ====<br />
Как настраивать openvswitch, описано [[Etcnet/openvswitch|тут]].<br />
<br />
<div id="vlan"></div><br />
<br />
=== Настройка VLAN ===<br />
<br />
Для настройки 802.1q VLAN (например, id 4094 на eth1) следует, создав каталог {{path|ifaces/eth1.4094}}, поместить в него файлы со следующим содержимым:<br />
<br />
* <tt>ipv4address</tt>:<br />
<pre>192.168.100.200/24</pre><br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=vlan<br />
HOST=eth1<br />
VID=4094<br />
BOOTPROTO=static</pre><br />
<br />
Содержимое переменных <tt>HOST</tt> и <tt>VID</tt> будет передано утилите <tt>vconfig</tt>; использование файла <tt>vlantab</tt> необязательно (и не рекомендуется по причине невозможности использовать ifup для отдельного интерфейса). Пример конфигурации можно найти в каталоге examples/VLAN-without-vlantab/ документации etcnet.<br />
<br />
Следует обратить внимание, что 4094 является верхней допустимой границей идентификатора валидного VLAN, а [http://www.candelatech.com/pipermail/vlan/2004-November/000128.html 4095 используется технически в процессе отбрасывания трафика по неверным VLAN]. (следует отметить, что это не ограничение Linux: [http://en.wikipedia.org/wiki/802.1Q в стандарте под VID отведено 12 бит])<br />
<br />
<br />
Обратите внимание, что '''ISC DHCP сервер на интерфейсе VLAN''', скорее всего, у вас не будет не работать, пока вы не добавите опцию VLAN_REORDER_HDR=off в настройки vlan интерфейса.<br />
<br />
<br />
'''Для настройки Q-in-Q интерфейса''', например, eth1.123.513 (дважды тегированный трафик: внешняя метка -- 123, внутренняя -- 513) следует файл <tt>options</tt> в каталоге {{path|ifaces/eth1.123.513}} заполнить следующим образом:<br />
<br />
* <tt>options</tt>:<br />
<pre> TYPE=vlan<br />
HOST=eth1.123 # "родительский" интерфейс; может называться иначе<br />
VID=513<br />
VLAN_REORDER_HDR=0<br />
BOOTPROTO=static</pre><br />
<br />
Родительский интерфейс должен быть сконфигурирован (можно с или без <tt>BOOTPROTO</tt>, с или без <tt>ipv4address</tt> и т.п.).<br />
<br />
Таким образом, можно каскадировать интерфейсы "как угодно глубоко" (Q-in-Q-in-Q-in-Q....). Необходимо только учитывать, что длина имени интерфейса ограничена (16-ю символами).<br />
<br />
<div id="bonding"></div><br />
<br />
=== Настройка bonding ===<br />
Bonding - объединение нескольких физических сетевых интерфейсов в один логический, для достижения отказоустойчивости, увеличения скорости и балансировки нагрузки. Возможны несколько режимов работы и много параметров для настроек, подробнее см. http://www.linuxfoundation.org/collaborate/workgroups/networking/bonding<br />
<br />
Для создания агрегированного bond-интерфейса средствами etcnet создаем, как обычно, директорию для интерфейса (например, <tt>bond0</tt>) с <tt>options</tt>, <tt>ipv4address</tt>, и прочими необходимыми файлами. В <tt>options</tt> указываем тип интерфейса <tt>bond</tt>, перечисляем в переменной <tt>HOST</tt> родительские интерфейсы, которые будут входить в наш агрегированный интерфейс, указываем в переменной <tt>BONDMODE</tt> режим (по умолчанию 0), и опции для модуля ядра <tt>bonding</tt> в <tt>BONDOPTIONS</tt>.<br><br />
Так, для создания LACP-агрегированного канала (802.3ad), у нас получится такой <tt>options</tt>:<br />
TYPE=bond<br />
ONBOOT=yes<br />
BOOTPROTO=static<br />
HOST="eth0 eth1"<br />
BONDMODE=4<br />
BONDOPTIONS="miimon=100 lacp_rate=1"<br />
Интерфейсы eth0 и eth1 должны тоже быть описаны в etcnet.<br />
<br />
Как правило, для создания агрегированного интерфейса требуется, чтобы входящие в него физические интерфейсы имели одинаковые характеристики - скорость, дуплекс, etc.<br />
<br />
Не стоит указывать режим в переменной <tt>BONDOPTIONS</tt>: попытки изменить какие-то режимоспецифичные параметры до установки правильного режима могут быть отвергнуты. Поэтому, первым делом нужно установить необходимый режим, указав его для этого в <tt>BONDMODE</tt>.<br />
<br />
Информацию о получившемся агрегированном интерфейсе можно посмотреть в {{path|/proc/net/bonding/bond0}}<br />
<br />
<div id="tun/tap"></div><br />
<br />
=== Настройка tun/tap интерфейса ===<br />
<br />
Etcnet поддерживает простое создание интерфейсов типа tun/tap. Это виртуальный тип интерфейсов для передачи пакетов между ядром и программами, который не передает данных через физические устройства.<br />
'''tun''' — это интерфейс типа point-to-point, работающий с кадрами IP.<br />
'''tap''' — интерфейс типа ethernet, работающий с кадрами ethernet.<br />
<br />
Потребуется использование утилиты tunctl, находящейся в одноименном пакете.<br />
Пусть требуется создать и настроить tun/tap интерфейс, например, с именем tap0. Для этого необходимо:<br />
* создать каталог интерфейса:<br />
<br />
/etc/net/ifaces/tap0<br />
<br />
* создать в каталоге интерфейса {{path|/etc/net/ifaces/tap0}} файл настройки <tt>options</tt> со следующим содержанием:<br />
<br />
TYPE=tuntap<br />
TUNTAP_USER=combr<br />
<br />
<br />
<tt>TUNTAP_USER</tt> — это аккаунт или цифровой id пользователя, которому будут даны права на использование интерфейса tap0 (устройство /dev/net/tun).<br />
Этот параметр будет передан утилите <tt>tunctl</tt> как аргумент опции <tt>-u</tt> (см. руководство на tunctl).<br />
С версии ядра 2.6.18 произошли изменения в управлении этим типом интерфейсов, потребовавшие<br />
обязательного применения <tt>tunctl</tt> для разрешения доступа обычных<br />
пользователей к tap-интерфейсам. В предыдущих версиях любой<br />
пользователь, имеющий доступ к <tt>/dev/net/tun</tt>, мог создать любое<br />
количество сетевых интерфейсов с произвольными именами. Начиная с<br />
2.6.18, для создания интерфейса через <tt>/dev/net/tun</tt> требуется<br />
<tt>CAP_NET_ADMIN</tt> (обычно эту привилегию имеет только root), а обычный<br />
пользователь, имеющий доступ к <tt>/dev/net/tun</tt>, может только использовать<br />
уже созданные интерфейсы, к которым разрешён доступ для его uid.<br />
<br />
=== Настройка интерфейса типа OpenVPN ===<br />
<br />
Настройка OpenVPN может быть произведена большим количеством способов и вариантов с разными целями, и достойна отдельной статьи. Здесь, для начала, будет описан вариант openvpn-сервера в режиме bridging.<br />
Для этого надо проделать подготовку:<br />
* создать ключи [http://openvpn.net/index.php/open-source/documentation/howto.html#pki англ. HOWTO]<br />
(до версии 2.3 утилиты easy-rsa шли в составе дистрибутива openvpn, потом отдельно).<br />
* настроить [http://www.altlinux.org/Etcnet#.D0.9D.D0.B0.D1.81.D1.82.D1.80.D0.BE.D0.B9.D0.BA.D0.B0_Ethernet-.D0.BC.D0.BE.D1.81.D1.82.D0.B0 мост] (между внутренним физическим интерфейсом и интерфейсом tap, который будет использовать openvpn) "средствами системы".<br />
<br />
Далее надо сделать так (скрипты etcnet по умолчанию ожидают это):<br />
* создать каталог интерфейса:<br />
<br />
/etc/net/ifaces/tap0<br />
<br />
* создать в каталоге интерфейса {{path|/etc/net/ifaces/tap0}} файл настройки <tt>options</tt> со следующим содержанием:<br />
<br />
TYPE=ovpn<br />
<br />
(необязательно, но желательно указать '''REQUIRES'''=''<имя ethernet-интерфейса>'', с которым будет связан туннель)<br />
<br />
* Конфигурационный файл для openvpn (из примера в пакете openvpn-docs - такой, как /usr/share/doc/openvpn-docs-2.2.2/sample-config-files/server.conf) надо переделать, удалив параметры, которые etcnet подставляет самостоятельно при запуске:<br />
<br />
dev<br />
ca<br />
cert<br />
key<br />
persist-key<br />
persist-tun<br />
<br />
И обязательно добавив параметры, которых по умолчанию в конфиге-примере нет:<br />
<br />
tls-server<br />
script-security 2<br />
<br />
Параметр script-security был введен начиная с версии 2.1_rc9. Поскольку etcnet запускает openvpn так, что в процессе тот запускает скрипт scripts/openvpn.action, который считается "пользовательским", то для этого значение должно быть 2.<br />
<br />
* скопировать в каталог интерфейса ключи и измененный конфиг-файл openvpn.<br />
Файлы надо переименовать (ключи - после easy-rsa) таким образом:<br />
{| align="center" border="1"<br />
|ключ easy-rsa<br />
|ключ etcnet-ovpn<br />
|-<br />
|ca.crt <br />
|ovpnca<br />
|-<br />
|server.crt<br />
|ovpncrt<br />
|-<br />
|server.key<br />
|ovpnkey<br />
|-<br />
|server.conf<br />
|ovpnoptions<br />
|}<br />
<br />
<br />
<br />
После всего этого можно попробовать запустить интерфейс: ifup tun0 (или весь мост, например ifup br0). Но если, например, openvpn считает ошибочной какую-либо опцию, то он молча выйдет с кодом выхода 1, и скрипт ifup ничего не напишет (в логе так же не будет попытки запуска openvpn). Потребуется отладка (например, можно запустить openvpn вручную без параметра --daemon и со всеми параметрами, которые подставил etcnet).<br />
<br />
<div id="wireguard"></div><br />
<br />
=== Настройка WireGuard VPN туннеля ===<br />
<br />
WireGuard используется для быстрого создания VPN туннелей, является более легким и безопасным чем OpenVPN. Для использования wireguard необходимо '''ядро версии 3.10+''' и установленные модули ядра '''wireguard-std-def''', '''wireguard-un-def'''. Для настройки интерфейса необходимо:<br />
* создать каталог интерфейса {{path|/etc/net/ifaces/wg0}}<br />
* добавить файл с конфигурацией {{path|/etc/net/ifaces/wg0/options}}<br />
<source lang='ini'><br />
TYPE=wg<br />
LISTENPORT=51820<br />
</source><br />
* добавить файл с поддерживающимися wireguard опциями пиров {{path|/etc/net/ifaces/wg0/options}} (одна строка - один пир)<br />
<source lang='bash'><br />
peer PUBLICPEERKEY allowed-ips IFACESSUBNET endpoint PUBLICIP:ALLOWPORT<br />
</source><br />
* добавить файл содержащий локальные и удаленные ip адреса {{path|/etc/net/ifaces/wg0/ipv4address}}<br />
первым делом указывается выделенная интерфейсу локальная подсеть, после чего указываются соответствия локального и удаленного ip адресов, каждое соответствие с новой строки<br />
<source lang='bash'><br />
10.1.0.0/16<br />
10.1.0.1 10.2.0.1<br />
</source><br />
* добавить файл содержащий приватный ключ {{path|/etc/net/ifaces/wg0/privatekey}}<br />
Ключи могут быть созданы стандартной утилитой wireguard:<br />
<source lang='bash'><br />
$ umask 077<br />
$ wg genkey > privatekey<br />
$ wg pubkey < privatekey > publickey<br />
</source><br />
<br />
<div id="iptun"></div><br />
<br />
=== Настройка и использование IP-туннелей ===<br />
<br />
IP-туннели — средство, позволяющее улучшить IP-сети. Поддерживаются IP-туннели трёх видов: <br />
* IPIP<br />
* GRE<br />
* SIT <br />
* VTI<br />
<br />
Прежде всего следует определить необходимый вид туннеля для решаемой задачи. <br />
<br />
* Туннели '''IPIP''' — самые простые.<br />
<br />
* Туннели '''GRE''' (general incapsulation) обычно используются в маршрутизаторах Cisco. По туннелям этого типа могут передаваться broadcast и multicast пакеты. Кроме того, эти туннели поддерживают контрольные суммы и контроль упорядоченности пакетов. Также GRE-туннели обладают опциональным атрибутом key в виде произвольного 4-байтового числа, который позволяет конфигурировать несколько GRE туннелей между одной парой IP-адресов несущей сети (в отличие от IPIP-туннелей, с которыми это невозможно).<br />
<br />
* Туннели '''SIT''' предназначены для транспортировки пакетов IPv6 через сети IPv4.<br />
<br />
* Туннели '''VTI''' используются для построения IPsec туннелей. Работают используя один из демонов, strongswan или libreswan.<br />
<br />
Тип туннеля определяется опцией <tt>TUNTYPE (ipip, gre, sit, vti)</tt>. По умолчанию <tt>TUNTYPE=ipip</tt>. Кроме типа туннеля для конфигурации всегда требуется адрес удалённого хоста и почти всегда — локальный адрес. Эти адреса определяются опциями <tt>TUNREMOTE</tt> и <tt>TUNLOCAL</tt> соответственно. В некоторых случаях локальный адрес можно не указывать. В этом случае опция <tt>TUNLOCAL</tt> всё равно обязательна, но принимает значение <tt>any</tt>. Не забудьте назначить туннельному интерфейсу адреса и маршруты в соответствующих файлах.<br />
<br />
Пример: Конфигурация GRE-туннеля между 10.0.1.2 и 10.0.2.3 с двумя ключами для исходящих и входящих пакетов, проверкой очерёдности пакетов, TTL 8 и вычислением контрольных сумм. Туннель должен использовать только интерфейс gw1. Пусть имя создаваемого туннеля будет <tt>mytunnel</tt>.<br />
<br />
Тогда необходимо сделать следующие операции:<br />
* Создать каталог туннеля: {{path|/etc/net/ifaces/mytunnel}}<br />
<br />
* Создать в каталоге туннеля файл настроек <tt>options</tt>: {{path|/etc/net/ifaces/mytunnel/options}}<br />
<br />
* Отредактировать файл настроек <tt>options</tt>: <br />
<br />
<source lang="ini"><br />
TYPE=iptun<br />
TUNTYPE=gre<br />
TUNLOCAL=10.0.1.2<br />
TUNREMOTE=10.0.2.3<br />
TUNTTL=8<br />
HOST=gw1<br />
TUNOPTIONS='ttl 64 seq ikey 2020 okey 2030 csum'<br />
</source><br />
<br />
<div id="vpn"></div><br />
<br />
Про <tt>ttl 64</tt>. Если параметр ttl не задан, значение берётся из инкапсулируемого пакета (это надо проверить). В некоторых случаях ttl может получиться слишком мал (например, Quagga формирует OSPF-пакеты с TTL 1).<br />
<br />
Стоит помнить, что имена <tt>tunl0, gre0 и sit0</tt> являются зарезервированными в iproute2 ("base devices") и имеют особое поведение: http://www.liveinternet.ru/users/stasikos/post71435454/<br />
<br />
Процедура создания vti интерфейса стандартна, однако, предварительно необходимо установить и настроить один из демонов (strongswan, libreswan), о том, как это сделать можно найти в соответствующей документации. После чего необходимо создать каталог интерфейса (к примеру он будет называться vti0) {{path|/etc/net/ifaces/vti0}}, и добавить в него файл настроек туннеля {{path|/etc/net/ifaces/vti0/options}}, куда нужно прописать необходимую конфигурацию:<br />
<source lang='ini'><br />
TYPE=iptun<br />
TUNTYPE=vti<br />
TUNLOCAL=119.81.184.173<br />
TUNREMOTE=119.81.177.236<br />
TUNOPTIONS='key 42'<br />
</source><br />
Параметр key должен соответствовать параметру mark, указанному при настройке strongswan/libreswan.<br />
<br />
=== Настройка IPv6 ===<br />
==== Отключение IPv6 ====<br />
<br />
* '''Вариант 1'''<br />
Чтобы отключить IPv6 на всех сетевых интерфейсах в работающей системе с загруженным модулем ipv6, нужно изменить значение параметра ядра net.ipv6.conf.all.disable_ipv6, где 'all' подразумевает все интерфейсы, а net.ipv6.conf.eth0.disable_ipv6 -- отключение протокола IPv6 только на интерфейсе eth0 и т.д.<br />
<pre><br />
sysctl net.ipv6.conf.all.disable_ipv6=1<br />
</pre><br />
Также можно добавить данную директиву в {{path|/etc/sysctl.conf}}:<br />
<source lang="bash"><br />
echo 'net.ipv6.conf.all.disable_ipv6 = 1' >> /etc/sysctl.conf<br />
sysctl -f<br />
</source><br />
<br />
* '''Вариант 2'''<br />
Добавить параметр в командную строку загрузки ядра. Для GRUB2 нужно изменить параметры загрузки ядра в файле {{path|/etc/sysconfig/grub2}}, изменив переменную GRUB_CMDLINE_LINUX_DEFAULT или GRUB_CMDLINE_LINUX<br />
<pre><br />
...<br />
GRUB_CMDLINE_LINUX='failsafe vga=normal ipv6.disable=1'<br />
...<br />
</pre><br />
и обновив конфигурационный файл grub<br />
<source lang="bash"><br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
</source><br />
<br />
* '''Вариант 3'''<br />
<source lang="bash"><br />
echo 'options ipv6 disable=1' >> /etc/modprobe.d/options-local.conf<br />
</source><br />
Вступит в силу только после перезагрузки.<br />
<br />
==== Включение IPv6 ====<br />
<br />
* Во-первых, следует убедиться, что не применяется какой-либо вариант совета из предыдущего пункта. <br />
* Во-вторых, следует проверить значение CONFIG_IPV6 в etcnet. Переменная может быть описана в /etc/net/options.d/*, /etc/net/ifaces/default/*, /etc/net/ifaces/*/options. Наибольший приоритет у описания в ifaces/*/options.<br />
<br />
'''Замечание:''' В etcnet-0.9.10-alt5, в /etc/net/ifaces/default/options содержится CONFIG_IPV6=no<br />
<br />
==== Туннели 6-to-4 ====<br />
<br />
Требуется:<br />
* ядро с поддержкой IPv6 (CONFIG_IPV6 в /boot/config-*; наличие модуля ipv6);<br />
* ядро с поддержкой tun (CONFIG_TUN в /boot/config-*; наличие модуля tun);<br />
* доступность узла 192.88.99.1 - через него маршрутизируется трафик в сети IPv6.<br />
<br />
Далее в {{path|/etc/net/ifaces}} создаётся каталог с названием, например,<br />
tun6to4. В нём создаются файлы:<br />
iplink : <pre><br />
mtu 1472 </pre><br />
<br />
ipv6address : <pre><br />
# first six octets: ipv6calc --ipv4_to_6to4addr $TUNLOCAL<br />
2002:c000:201::1/16 </pre><br />
<br />
ipv6route : <pre><br />
2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 </pre><br />
<br />
options : <pre><br />
TYPE=iptun<br />
TUNTYPE=sit<br />
TUNLOCAL=192.0.2.1<br />
TUNREMOTE=any<br />
TUNOPTIONS="ttl 64"<br />
DONT_FLUSH=yes<br />
CONFIG_IPV6=yes </pre><br />
<br />
Адрес TUNLOCAL в options - имеющийся внешний IPv4, в ipv6address<br />
адрес IPv6 выбирается исходя из него же.<br />
<br />
В настройках iptables должно быть разрешение на приём пакетов протокола<br />
ipv6 на внешний адрес IPv4.<br />
<br />
Далее поднимается интерфейс tun6to4, ну и проверяется доступность <br />
чего-либо в IPv6.<br />
<br />
Туннели 6to4 - это RFC 3964.<br />
Miredo - это реализация протокола Teredo, RFC 4380.<br />
6to4 требует наличия внешнего адреса IPv4.<br />
Teredo не требует наличия внешнего адреса, и может работать через NAT.<br />
Через Teredo не получится получить симметричное соединение, т.е. доступ<br />
в IPv6 будет односторонний, на компьютер в общем случае извне<br />
подключиться не получится.<br />
И Teredo позволяет получить только адрес /32, т.е. для подключения сетей<br />
он мало пригоден.<br />
<br />
этот раздел скопирован из письма рассылки community (c) Nikolay A. Fetisov 8 сентября 2011 12:03:30<br />
<br />
=== Замечания о настройке VPN-подключения и туннелей ===<br />
<br />
Часто при настройке VPN-подключения (под которыми здесь будут подразумеваться все туннельные подключения, то есть подключения поверх IP) не учитывают, что использование опции pppd '<tt>defaultroute</tt>' маршрут по-умолчанию после подключения будет изменен. При этом, если VPN-сервер находится в другой, отличной от клиента, сети, то после подключения (и изменения маршрута по-умолчанию) VPN-сервер становится недоступным, следовательно, недоступными становятся все внешние адреса, и подключение, как правило, прекращается по тайм-ауту.<br />
<br />
Решением, как обычно (и рекомендовано), служит указание ''отдельного'' маршрута на VPN-сервер (или его сеть). Для этого необходимо прописать (в примере - для маршрута через eth0) в {{path|/etc/net/ifaces/eth0/ipv4route}} строку вида:<br />
<br />
10.0.1.0/24 via 10.0.0.1<br />
<br />
В данном примере подразумевается, что VPN-сервер находится в сети 10.0.1.0/24 (например, имеет адрес 10.0.1.1), клиент — в сети 10.0.0.0/24 (и имеет адрес, например, 10.0.0.10), а маршрутизатор имеет адрес 10.0.0.1.<br />
<br />
Теперь, при использовании опции '<tt>defaulroute</tt>' для pppd (которая указывает, что необходимо изменить на вновь созданное подключение маршрут по-умолчанию), даже после замены маршрута по-умолчанию новым, сеть 10.0.1.0, в которой в нашем примере и находится VPN-сервер, останется доступной.<br />
<br />
Как более точечный вариант (применяется в alterator-net-pptp 0.5.x) можно использовать скрипты {{cmd|ifup-pre}} и {{cmd|ifdown-post}} в каталоге конфигурируемого PPP-интерфейса.<br />
<br />
Наример:<br />
<source lang="bash"><br />
#!/bin/sh<br />
# sample /etc/net/ifaces/ppp0/ifup-pre; replace variables yourself<br />
ip route add VPN_SERVER via DEF_GW<br />
</source><br />
<source lang="bash"><br />
#!/bin/sh<br />
# sample /etc/net/ifaces/ppp0/ifdown-post; replace variables yourself<br />
ip route del VPN_SERVER via DEF_GW<br />
</source><br />
<br />
Не забудьте подставить нужные IP-адреса вместо VPN_SERVER и DEF_GW (не сеть, где VPN-сервер, а ее /32 префикс CIDR) и выполнить команду: {{cmd|chmod +x ifup-pre ifdown-post}}<br />
<br />
<div id="iprule"></div><br />
<br />
=== Сложная маршрутизация (или несколько таблиц маршрутизации) ===<br />
<br />
Под «сложной маршрутизацией» подразумевается наличие нескольких таблиц маршрутизации. Для их использования необходимо сконфигурировать правила ядра. В правилах по умолчанию можно увидеть следующее:<br />
<br />
<pre># ip rule show<br />
0: from all lookup local <br />
32766: from all lookup main <br />
32767: from all lookup default</pre><br />
<br />
Для настройки «сложной маршрутизациии» необходимо выполнить следующие операции:<br />
<br />
Шаг 1 : Сами таблицы определены в файле {{path|/etc/iproute2/rt_tables}}. Для создания конфигурации «сложной маршрутизации» необходимо вначале «создать» нужные таблицы в этом файле (если вы хотите использовать имена таблиц, а не числа).<br />
<br />
Шаг 2 : Необходимо заполнить таблицы. В конфигурационном каталоге интерфейса в файле <tt>ipv4route</tt> необходимо добавить маршрутные записи, не забывая указать <tt>table XX</tt>. Важно учитывать, что если строка начинается с режима ip route (add, del, replace, append, change), то по умолчанию будет использован режим <tt>DEFAULT_IPV4ROUTE_CMD</tt> (<tt>append</tt>).<br />
<br />
Шаг 3 : Определить правила в файле <tt>ipv4rule</tt>. Здесь есть особенности, связанные автоматической заменой/добавлением параметров. Если строка не начинается с операции del или add, то нужный режим будет подставлен автоматически. Это подходит для тех случаев, когда вам при "поднятии" интерфейса необходимо добавить правила, а при "опускании" — удалить. Возможность указывать del или add реализована для обратных случаев: если при "поднятии" интерфейса вам необходимо удалить правила, а при "опускании" — добавить. В этом случае add и del будут в нужный момент автоматически заменены на del и add.<br />
<br />
Пример такой конфигурации входит в /etc/net 0.7.12: (каталог документации examples/routing-LARTC-1/)<br />
<br />
=== Простое переключение маршрутов ===<br />
<br />
Пусть имеется eth-интерфейс, который используется постоянно, и настроен маршрут по умолчанию.<br />
Часто бывает необходимость настроить второй маршрут по умолчанию через беспроводной интерфейс,<br />
но с меньшей метрикой, чем у проводного интерфейса.<br />
В этом случае при поднятии WI-FI маршрут по умолчанию «развернется» в нужную сторону.<br />
<br />
Например:<br />
<br />
Для eth-интерфейса файл настроек {{path|/etc/net/ifaces/eth0/ipv4route}} будет таким:<br />
<pre>default via 192.168.3.254 metric 10</pre><br />
а для WI-FI-интерфейса файл настроек {{path|/etc/net/ifaces/ath0/ipv4route}} таким:<br />
<pre>default via 192.168.123.1 metric 5</pre><br />
<br />
<div id="wireless"></div><br />
=== Беспроводный Ethernet (или настройка WI-FI) ===<br />
Большинство беспроводных интерфейсов сейчас представлено системе как интерфейсы Ethernet. Соответственно беспроводный интерфейс будет иметь <b>TYPE=eth</b> (<s>[https://bugzilla.altlinux.org/show_bug.cgi?id=6283 #6283]</s>). Чтобы интерфейс нормально функционировал, необходимо кроме загрузки модуля с параметрами, воспользоваться утилитами {{cmd|iwconfig}} из пакета wireless-tools или {{cmd|wpa_supplicant}} из такого же пакета. Вместо того, чтобы запускать их вручную, можно поместить в конфигурационный каталог интерфейса файл <tt>iwconfig</tt> с командами iwconfig или файл <tt>wpa_supplicant.conf</tt> с конфигурацией wpa_supplicant. Они будут использованы автоматически.<br />
<br />
Пример [http://hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wireless.html конфигурации] (совместно с <tt>[http://ndiswrapper.sourceforge.net/ ndiswrapper]</tt>):<br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/options}}<br />
<pre>TYPE=eth<br />
MODULE=ndiswrapper<br />
NEVER_RMMOD=yes<br />
BOOTPROTO=dhcp<br />
USE_HOTPLUG=no<br />
ONBOOT=no</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/iwconfig}}<br />
<pre>essid default<br />
#key bababababa</pre><br />
<br />
<br />
Еще один пример использования etcnet для настройки беспроводной сети:<br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/options}}<br />
<pre>TYPE=eth<br />
USE_HOTPLUG=NO<br />
BOOTPROTO=static<br />
module=ipw2200<br />
WPA_DRIVER=wext</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/iwconfig}}<br />
<pre>essid homenet<br />
mode 1<br />
ap 00:11:D8:22:AD:0D<br />
channel 3<br />
rate 11M</pre><br />
<br />
Файл: {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}}<br />
<pre>ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=0<br />
eapol_version=1<br />
ap_scan=1<br />
fast_reauth=1<br />
<br />
network={<br />
ssid="homenet"<br />
scan_ssid=1<br />
key_mgmt=WPA-PSK<br />
psk="this is my mega secret password string to wpa supplicant"<br />
}</pre><br />
<br />
Если вы хотите воспользоваться WPS:<br />
# создайте {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}} следующего вида:<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
update_config=1<br />
</pre><br />
# поднимите беспроводной интерфейс (ifup wlan0)<br />
# запустите wpa_cli и дайте команды wps_pbc (после этого нужно соответственно нажать кнопку WPS на точке доступа и подождать окончания обмена данными) и save_config (для записи конфигурации в <tt>wpa_supplicant.conf</tt>). Или же можно воспользоваться утилитой wpa_gui, отображающей процесс более наглядно.<br />
<br />
Пример файла {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}} при подключении к сети, использующей протокол WPA2-PSK(AES)<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=0<br />
eapol_version=1<br />
ap_scan=1<br />
fast_reauth=1<br />
<br />
network={<br />
ssid="home-lg"<br />
bssid=00:1B:11:87:C7:EA<br />
proto=RSN<br />
key_mgmt=WPA-PSK<br />
pairwise=CCMP TKIP<br />
group=CCMP TKIP<br />
psk="this is my mega secret password string to wpa supplicant"<br />
priority=2<br />
}<br />
</pre><br />
<br />
<div id="infiniband"></div><br />
<br />
=== Настройка Infiniband ===<br />
На сейчас ничем не отличается от настройки Ethernet, специфическая поддержка отсутствует (и для [[Infiniband#IP_over_IB|IP-over-IB]] не требуется). Пример конфигурации для Mellanox:<br />
<br />
Файл: <tt>/etc/modules</tt><br />
<pre>mlx4_ib<br />
ib_umad<br />
ib_ipoib</pre><br />
<br />
Файл: <tt>/etc/net/ifaces/ib0/options</tt><br />
<pre>TYPE=eth<br />
BOOTPROTO=dhcp<br />
ONBOOT=yes</pre><br />
<br />
<div id="sysctl"></div><br />
<br />
=== Использование автодополнения в sysctl.conf ===<br />
<br />
В конфигурационном каталоге интерфейса может находиться файл <tt>sysctl.conf</tt>, в котором можно перечислить переменные <tt>sysctl(8)</tt>. Но переменные могут быть как общесистемными, так и относящимися к интерфейсу. Естественно, запись в sysctl.conf настроек вида <tt>net.ipv4.conf.eth0.log_martians = 1</tt> достаточно неудобна, а при переименовании интерфейса велик риск не отредактировать файл <tt>sysctl.conf</tt> соответствующим образом.<br />
<br />
Эта проблема решается следующим способом : производится запись в файл только имени переменной и значение, а система /etc/net сама найдет путь к этой переменной и вызовет <tt>sysctl</tt> с полным именем. <br />
<br />
Пример содержания файла <tt>sysctl.conf</tt>:<br />
<pre>log_martians=1<br />
rp_filter=1</pre><br />
<br />
<div id="profiles"></div><br />
<br />
=== Подключение к Wi-Fi с сертификатом на аппаратном токене ===<br />
Для беспроводного подключения в корпоративных сетях могут использоваться сертификаты, записанные на аппаратном токене, например, Aladdin eToken. Для настройки такого подключения необходимо использовать {{path|/etc/net/ifaces/wlan0/wpa_supplicant.conf}}.<br />
<pre><br />
ctrl_interface=/var/run/wpa_supplicant<br />
ctrl_interface_group=wheel<br />
#eapol_version=1<br />
#ap_scan=2<br />
#fast_reauth=1<br />
pkcs11_engine_path=/usr/lib/openssl/engines/engine_pkcs11.so<br />
pkcs11_module_path=/usr/lib/libeTPkcs11.so<br />
update_config=0<br />
<br />
network={<br />
ssid="test"<br />
key_mgmt=WPA-EAP<br />
pairwise=CCMP TKIP<br />
group=CCMP TKIP<br />
eap=TLS<br />
identity="email@address.ru"<br />
engine_id="pkcs11"<br />
key_id="xxxxxxxxx"<br />
cert_id="xxxxxxxxx"<br />
engine=1<br />
}<br />
</pre><br />
где key_id и cerd_id взяты из вывода команды<br />
<pre><br />
# pkcs11-tool --module /usr/lib/libeTPkcs11.so -O -l<br />
</pre><br />
<br />
Используются оригинальные ("родные") драйвера Aladdin - pkiclient-5.00.28-0, и пакет openssl-engine_pkcs11-0.1.5-alt1.<br />
<br />
=== Профили конфигурации ===<br />
<br />
==== Определение профилей ====<br />
Профиль — именованный вариант конфигурации, в той или иной степени изменяющий базовую конфигурацию системы. Профили могут быть применены, например, для конфигурации ноутбука в разных сетевых окружениях, или при подготовке новой или тестовой конфигурации с возможностью быстрого возврата к старой. Практически профили реализуются следующим образом: для какого-либо из файлов, составляющих общесистемную конфигурацию или конфигурацию интерфейса, создаётся альтернативный вариант, который отличается добавлением в конце названия файла знака # и имени профиля.<br />
<br />
Например, пусть единственное отличие между профилями заключается в том, какой модуль ядра будет загружен для интерфейса eth0. В этом случае файл {{path|/etc/net/ifaces/eth0/options}} необходимо скопировать в {{path|/etc/net/ifaces/eth0/options#profile1}} и изменить значение переменной <tt>MODULE</tt> в одном из них. Далее при использовании конфигурации по умолчанию будет использован файл <tt>options</tt>, а при использовании профиля profile1 — файл <tt>options#profile1</tt>. Если при этом для назначения интерфейсу имени используется файл {{path|/etc/net/iftab}}, то скорее всего необходимо будет создать соответствующий файл {{path|/etc/net/iftab#profile1}}, так как другой модуль ядра указывает на другой физический интерфейс и исходный файл <tt>iftab</tt> работать не будет.<br />
<br />
Профили могут использоваться также и для отключения каких-то параметров конфигурации. Например, если используется файл <tt>ipv4route</tt> для установки маршрутов для интерфейса, то можно создать файл нулевого размера <tt>ipv4route#profile2</tt>, чтобы при использовании профиля profile2 никаких маршрутов не конфигурировалось.<br />
<br />
==== Выбор профиля при загрузке ====<br />
Если при загрузке системы ядру был передан параметр netprofile, то его значение будет использовано как имя профиля по умолчанию. Это может быть использовано для создания собственных пунктов меню загрузчиков LILO и GRUB с заранее определённым профилем сетевой конфигурации. Заданный таким образом профиль может быть далее переопределён другими методами. Следует понимать разницу между различными конфигурациями и различными результатами применения одной конфигурации. Например, если в двух разных сетях используется DHCP, то смысла в разных профилях конфигурации нет.<br />
<br />
Для загрузчика LILO секции <tt>/etc/lilo.conf</tt> могут выглядеть следующим образом:<br />
<pre>image=/boot/vmlinuz-up<br />
label=linux-up home<br />
append=" netprofile=home"<br />
[...]<br />
image=/boot/vmlinuz-up<br />
label=linux-up office<br />
append=" netprofile=office"<br />
[...]</pre><br />
Для приведённого примера необходимо будет создать варианты для файлов, отличающихся в профилях home и office, и можно будет выбирать при загрузке, какой из профилей необходимо использовать. Использование этого метода удобно, если смена сетевого окружения происходит синхронно с загрузкой системы.<br />
<br />
==== Выбор профиля по умолчанию ====<br />
Если требуется, чтобы определенный профиль конфигурации использовался по умолчанию, то необходимо записать его название в файл <tt>/etc/net/profile</tt>. Этот метод имеет приоритет над параметром ядра netprofile. Использование такого способа выбора профиля целесообразно, когда переключение между конфигурациями происходит реже, чем перезагрузка системы.<br />
<br />
==== Смена профиля во время работы ====<br />
Если требуется переконфигурировать сеть без перезагрузки или редактирования файла {{path|/etc/net/profile}}, то следует использовать параметры сервиса network, описанные в разделе [[#restart, reload и другие команды|restart, reload и другие команды]]. Этот метод имеет приоритет над профилем по умолчанию и профилем, выбранным при загрузке. Целесообразно его использовать, если смена сетевого окружения происходит чаще, чем перезагрузка системы.<br />
<br />
==== Определение профиля во время конфигурации интерфейса ====<br />
Если в каталоге конфигурации интерфейса существует исполняемый файл ненулевого размера с именем <tt>selectprofile</tt>, то этот файл будет выполнен и первое слово первой строки его стандартного вывода использовано как имя профиля, которое должно быть использовано для конфигурации данного интерфейса. Этот метод имеет приоритет над всеми остальными методами. Исходной задачей, требующей такого решения, являлось конфигурирование беспроводного интерфейса в зависимости от доступных точек доступа.<br />
<br />
Следует учитывать, что число вызовов файла <tt>selectprofile</tt> может меняться в зависимости от контекста и время его выполнения может быть различным, поэтому при написании такого файла следует учитывать, что первым параметром будет являться имя текущего сценария. В настоящее время это могут быть ifup*, ifdown*, setup* и shutdown*. Для приведённого выше примера имеет смысл реагировать только на вызовы из ifup или ifup-common.<br />
<br />
== См. также ==<br />
* [[Ресолвер]]<br />
<br />
== Примечания ==<br />
<references/><br />
<br />
{{Category navigation|title=etcnet|category=etcnet|sortkey=*}}<br />
[[Категория:WiFi]]<br />
{{Category navigation|title=Wi-Fi|category=WiFi|sortkey={{SUBPAGENAME}}}}<br />
[[Категория:Admin]]<br />
{{Category navigation|title=Системному администратору|category=Admin|sortkey={{SUBPAGENAME}}}}<br />
[[en:etcnet]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=FreeIPA&diff=48570FreeIPA2020-06-05T11:59:29Z<p>AntonFarygin: /* Установка сервера FreeIPA в режиме CA-less */</p>
<hr />
<div>[[Файл:Freeipa-logo-small.png|frameless|right]]<br />
FreeIPA - это комплексное решение по управлению безопасностью Linux-систем, 389 Directory Server, MIT Kerberos, NTP, DNS, Dogtag. Оно состоит из веб-интерфейса и интерфейса командной строки.<br><br />
FreeIPA является интегрированной системой проверки подлинности и авторизации в сетевой среде Linux, FreeIPA сервер обеспечивает централизованную проверку подлинности, авторизацию и контроль за аккаунтами пользователей сохраняя сведения о пользователе, группах, узлах и других объектах необходимых для обеспечения сетевой безопасности.<br />
<br />
[https://www.freeipa.org/ Сайт проекта], [https://ipa.demo1.freeipa.org/ipa/ui/ демонстрация интерфейса].<br />
<br />
== Установка сервера FreeIPA ==<br />
Устанавливать будем со встроенным DNS сервером и доменом EXAMPLE.TEST в локальной сети 192.168.135.0/24.<br><br />
Для начала отключим ahttpd, работающий на порту 8080, во избежание конфликтов с разворачиваемым tomcat и отключим HTTPS в Apache2:<br />
# service ahttpd stop<br />
# a2dissite 000-default_https<br />
# a2disport https<br />
# service httpd2 condreload<br />
<br />
Установим необходимые пакеты:<br />
<pre># apt-get install freeipa-server freeipa-server-dns</pre><br />
Зададим имя сервера:<br />
<pre># hostnamectl set-hostname ipa.example.test</pre><br />
<br />
Для ускорения установки можно установить демон энтропии haveged:<br />
<pre> # apt-get install haveged<br />
# systemctl enable haveged<br />
# systemctl start haveged </pre><br />
<br />
Запускаем скрипт настройки сервера:<br />
<br />
В пакетном режиме: <br />
# ipa-server-install -U --hostname=$(hostname) -r EXAMPLE.TEST -n example.test -p 12345678 -a 12345678 --setup-dns --no-forwarders --no-reverse<br />
или интерактивно:<br />
<pre># ipa-server-install</pre><br />
<br />
{{Attention|Пароли должны быть не менее 8 символов}}<br />
<br />
Обратите внимание на ответы на вопросы, не совпадающие с предложенными:<br />
Do you want to configure integrated DNS (BIND)? [no]: yes<br />
<br />
остальные вопросы выбираем по умолчанию (можно просто нажать Enter). Так же при установке попросят ввести пароль администратора системы и пароль администратора каталогов.<br><br />
<br />
Для возможности управлять FreeIPA сервером из командной строки необходимо получить билет Kerberos:<br />
<pre># kinit admin</pre><br />
Добавим в DNS запись о нашем сервере времени:<br />
<pre># ipa dnsrecord-add example.test _ntp._udp --srv-priority=0 --srv-weight=100 --srv-port=123 --srv-target=ipa.example.test.</pre><br />
<br />
Проверить работу ntp сервера можно командой:<br />
<pre># ntpdate -q localhost<br />
server 127.0.0.1, stratum 3, offset 0.000018, delay 0.02568<br />
27 Apr 10:27:00 ntpdate[3491]: adjust time server 127.0.0.1 offset 0.000018 sec</pre><br />
<br />
Также доступен веб-интерфейс по адресу: <br />
<pre>https://ipa.example.test/ipa/ui/</pre><br />
<br />
{{Note|Если выдаёт <pre>[error] CalledProcessError: Command '/sbin/systemctl restart httpd2.service' returned non-zero exit status 1</pre><br />
Выполните <br />
# systemctl restart httpd2<br />
Отмените установку: <br />
# ipa-server-install -U --uninstall<br />
и повторите снова.}}<br />
<br />
== Установка сервера FreeIPA в режиме CA-less ==<br />
CA-Less конфигурация требуется в тех случаях, когда у вас по какой-то причине нет возможности развернуть на FreeIPA сервис PKI dogtag. Например, это на данный момент невозможно сделать в некоторых сертифицированных конфигурациях. Если у вас не сертифицированный дистрибутив ALT, то пропустите пункт по настройке CA-Less репликации. <br />
<br />
Установим необходимые пакеты:<br />
<pre># apt-get install freeipa-server freeipa-server-dns</pre><br />
Зададим имя сервера:<br />
<pre># hostnamectl set-hostname ipa.example.test</pre><br />
Подготовим сертификаты для сервера FreeIPA:<br />
<pre># mkdir ~/test_ca</pre><br />
Создадим файл pwdfiles.txt с паролем, например 12345678:<br />
<pre># echo 12345678 > ~/test_ca/pwdfile.txt</pre><br />
Создадим базу данных NSS:<br />
<pre>/usr/bin/certutil -d ~/test_ca -N -f ~/test_ca/pwdfile.txt</pre><br />
Создадим noise файл с рандомом:<br />
<pre># head -c20 /dev/random > ~/test_ca/noise.txt</pre><br />
Экспортируем переменную:<br />
<pre># export CERT_SERIAL=1</pre><br />
Создаем CA сертификат:<br />
<pre># /usr/bin/certutil -d ~/test_ca -S -n "CA" -s "CN=Certificate Authority" -x -t CT,,C -1 -2 -5 -m $CERT_SERIAL -v 120 -z ~/test_ca/noise.txt -f ~/test_ca/pwdfile.txt</pre><br />
Дайте следующие ответы:<br />
<pre> Create key usage extension:<br />
0 - Digital Signature<br />
1 - Non-repudiation<br />
5 - Cert signing key<br />
9 - done<br />
Is this a critical extension [y/N]? y<br />
Create basic constraint extension<br />
Is this a CA certificate [y/N]? y<br />
Enter the path length constraint, enter to skip [<0 for unlimited path]<br />
0<br />
Is this a critical extension [y/N]? y<br />
Extensions:<br />
5 - SSL<br />
6 - S/MIME<br />
7 - Object Signing CA<br />
9 - done<br />
Is this a critical extension [y/N]? n </pre><br />
Создадим запрос сертификата:<br />
<pre># head -c20 /dev/random > ~/test_ca/noise.txt<br />
# /usr/bin/certutil -d ~/test_ca -R -s CN=$HOSTNAME,O=IPA -o /tmp/servercert.req -k rsa -g 2048 -z ~/test_ca/noise.txt -f ~/test_ca/pwdfile.txt -a</pre><br />
Подпишите запрос о выдаче сертификата сервера:<br />
<pre># export CERT_SERIAL=$(($CERT_SERIAL + 1))<br />
# /usr/bin/certutil -d ~/test_ca -C -c "CA" -i /tmp/servercert.req -o /tmp/servercert.pem -m $CERT_SERIAL -v 120 -f ~/test_ca/pwdfile.txt -1 -5 -a</pre><br />
Дайте следующие ответы:<br />
<pre> Create key usage extension:<br />
2 - Key encipherment<br />
9 - done<br />
n - not critical<br />
Create netscape cert type extension:<br />
1 - SSL Server<br />
9 - done<br />
n - not critical</pre><br />
Если вы хотите, вы можете создавать отдельные сертификаты для серверов HTTP и Directory.<br />
<br />
'''Экспорт сертификатов в правильные форматы.'''<br />
Импортируем полученный сертификат:<br />
<pre># /usr/bin/certutil -d ~/test_ca -A -i /tmp/servercert.pem -n Server-Cert -a -t ,,</pre><br />
Экспортируем в PKCS#12:<br />
<pre># /usr/bin/pk12util -o ~/test_ca/servercert.p12 -n Server-Cert -d ~/test_ca -k ~/test_ca/pwdfile.txt -w ~/test_ca/pwdfile.txt</pre><br />
Экспортируйте сертификат CA в формате PEM:<br />
<pre># /usr/bin/certutil -d ~/test_ca -L -n "CA" -a > ~/test_ca/cacert.pem</pre><br />
Теперь установим CA-less IPA:<br />
<pre># export PWD=$(cat ~/test_ca/pwdfile.txt)<br />
# ipa-server-install --http_pkcs ~/test_ca/servercert.p12 --dirsrv_pkcs ~/test_ca/servercert.p12 --http_pin $PWD --dirsrv_pin $PWD --root-ca-file ~/test_ca/cacert.pem</pre><br />
<br />
'''Вы также можете указать при установке опции --pkinit-cert-file=Файл, содержащий сертификат SSL Kerberos KDC и закрытый ключ и --pkinit-pin=Пароль от закрытого ключа Kerberos KDC.'''<br />
<br />
После установки выполните:<br />
<pre>kinit admin</pre><br />
И после убедитесь что команды: <br />
<pre>ipa cert-find<br />
ipa cert-show 1</pre><br />
Не срабатывают и выводят ошибки.<br />
<br />
== Настройка IPA CA-less репликации ==<br />
{{Attention|Перед настройкой репликации необходимо выполнить установку клиента}}<br />
CA-Less конфигурация требуется в тех случаях, когда у вас по какой-то причине нет возможности развернуть на FreeIPA сервис PKI dogtag. Например, это на данный момент невозможно сделать в некоторых сертифицированных конфигурациях. <br />
Если у вас не сертифицированный дистрибутив ALT, то пропустите пункт по настройке CA-Less репликации.<br />
<br />
Чтобы установить реплику, сначала создайте сертификаты для новой машины: создадим запрос сертификата и подпишем запрос о выдаче сертификата сервера и экспортируем сертификаты в правильные форматы, на этот раз задав $HOSTNAME имя хоста будущей реплики. Используйте Replica-Cert вместо Server-Cert и ~/test_ca/replicacert.p12 вместо ~/test_ca/servercert.p12:<br />
Создадим запрос сертификата для реплики:<br />
<pre># head -c20 /dev/random > ~/test_ca/noise.txt<br />
# /usr/bin/certutil -d ~/test_ca -R -s CN=Указать хост будущей реплики,O=IPA -o /tmp/replicacert.req -k rsa -g 2048 -z ~/test_ca/noise.txt -f ~/test_ca/pwdfile.txt -a</pre><br />
Подпишите запрос о выдаче сертификата реплики:<br />
<pre># /usr/bin/certutil -d ~/test_ca -C -c "CA" -i /tmp/replicacert.req -o /tmp/replicacert.pem -m 3 -v 120 -f ~/test_ca/pwdfile.txt -1 -5 -a</pre><br />
Дайте следующие ответы:<br />
<pre> Create key usage extension:<br />
2 - Key encipherment<br />
9 - done<br />
n - not critical<br />
Create netscape cert type extension:<br />
1 - SSL Server<br />
9 - done<br />
n - not critical<br />
</pre><br />
Если вы хотите, вы можете создавать отдельные сертификаты для серверов HTTP и Directory.<br />
<br />
'''Экспорт сертификатов в правильные форматы.'''<br />
<br />
Импортируем полученный сертификат:<br />
<pre># /usr/bin/certutil -d ~/test_ca -A -i /tmp/replicacert.pem -n Replica-Cert -a -t ,,</pre><br />
Экспортируем в PKCS#12:<br />
<pre># /usr/bin/pk12util -o ~/test_ca/replicacert.p12 -n Replica-Cert -d ~/test_ca -k ~/test_ca/pwdfile.txt -w ~/test_ca/pwdfile.txt</pre><br />
'''Для domain-level 1'''<br />
<br />
<pre># ipa-replica-install --http-cert-file ~/test_ca/replicacert.p12 --dirsrv-cert-file ~/test_ca/replicacert.p12</pre><br />
<br />
== Установка FreeIPA клиента и подключение к серверу ==<br />
Установим необходимые пакеты:<br />
<pre># apt-get install freeipa-client libsss_sudo krb5-kinit bind-utils libbind zip</pre><br />
Зададим имя компьютера:<br />
<pre># hostnamectl set-hostname comp01.example.test</pre><br />
Добавим DNS сервер, для этого создадим файл {{path|/etc/net/ifaces/ens19/resolv.conf}} со следующим содержимым:<br />
<pre>nameserver 192.168.135.1</pre><br />
192.168.135.1 - IP-адрес нашего FreeIPA сервера.<br><br />
Укажем службе resolvconf использовать DNS FreeIPA и наш домен для поиска.<br><br />
Для этого в файл {{path|/etc/resolvconf.conf}} добавим/отредактируем следующие параметры:<br />
<pre>interface_order='lo lo[0-9]* lo.* ens19'<br />
search_domains=example.test</pre><br />
Где ens19 -интерфейс на котором доступен FreeIPA сервер, example.test - наш домен.<br><br />
Обновим DNS адреса:<br />
<pre># resolvconf -u</pre><br />
После этого в файле {{path|/etc/resolv.conf}} должны появится строки:<br />
<pre>search example.test<br />
nameserver 192.168.135.1</pre><br />
Запускаем скрипт настройки клиента:<br />
в пакетном режиме:<br />
# ipa-client-install -U -p admin -w 12345678<br />
или интерактивно:<br />
<pre># ipa-client-install</pre><br />
Если все настроено верно скрипт должен выдать такое сообщение:<br />
<pre>'''Discovery was successful!'''<br />
Client hostname: comp02.example.test<br />
Realm: EXAMPLE.TEST<br />
DNS Domain: example.test<br />
IPA Server: ipa.example.test<br />
BaseDN: dc=example,dc=test<br />
Continue to configure the system with these values? [no]:</pre><br />
Отвечаем {{cmd|yes}} вводим имя пользователя, имеющего право вводить машины в домен, и его пароль.<br><br />
<br />
Пример успешного ввода в домен:<br />
<source lang="text">Discovery was successful!<br />
Client hostname: ipa-client1.test1.alt<br />
Realm: TEST1.ALT<br />
DNS Domain: test1.alt<br />
IPA Server: ipa-server.test1.alt<br />
BaseDN: dc=test1,dc=alt<br />
Synchronizing time with KDC...<br />
Attempting to sync time using ntpdate. Will timeout after 15 seconds<br />
Successfully retrieved CA cert<br />
Subject: CN=Certificate Authority,O=TEST1.ALT<br />
Issuer: CN=Certificate Authority,O=TEST1.ALT<br />
Valid From: Wed Feb 15 15:17:45 2017 UTC<br />
Valid Until: Sun Feb 15 15:17:45 2037 UTC<br />
<br />
Enrolled in IPA realm TEST1.ALT<br />
Created /etc/ipa/default.conf<br />
Configured sudoers in /etc/nsswitch.conf<br />
Configured /etc/sssd/sssd.conf<br />
Configured passwd in /etc/nsswitch.conf<br />
Configured group in /etc/nsswitch.conf<br />
Configured gshadow in /etc/nsswitch.conf<br />
Configured services in /etc/nsswitch.conf<br />
Configured netgroup in /etc/nsswitch.conf<br />
Configured shadow in /etc/nsswitch.conf<br />
Configured /etc/nsswitch.conf<br />
Configured PAM system-auth<br />
Configured /etc/krb5.conf for IPA realm TEST1.ALT<br />
trying https://ipa-server.test1.alt/ipa/json<br />
Forwarding 'ping' to json server 'https://ipa-server.test1.alt/ipa/json'<br />
Forwarding 'ca_is_enabled' to json server 'https://ipa-server.test1.alt/ipa/json'<br />
Hostname (ipa-client1.test1.alt) does not have A/AAAA record.<br />
Failed to update DNS records.<br />
Missing A/AAAA record(s) for host ipa-client1.test1.alt: 10.10.10.206.<br />
Missing reverse record(s) for address(es): 10.10.10.206.<br />
Adding SSH public key from /etc/openssh/ssh_host_ecdsa_key.pub<br />
Adding SSH public key from /etc/openssh/ssh_host_ed25519_key.pub<br />
Adding SSH public key from /etc/openssh/ssh_host_dsa_key.pub<br />
Adding SSH public key from /etc/openssh/ssh_host_rsa_key.pub<br />
Forwarding 'host_mod' to json server 'https://ipa-server.test1.alt/ipa/json'<br />
Could not update DNS SSHFP records.<br />
SSSD enabled<br />
Configured /etc/openldap/ldap.conf<br />
NTP enabled<br />
Configured /etc/openssh/ssh_config<br />
Configured /etc/openssh/sshd_config<br />
Configuring test1.alt as NIS domain.<br />
Client configuration complete.</source><br />
<br />
{{Attention|Если при входе в домен возникает такая ошибка:<br />
<pre>Hostname (ipa-client1.test1.alt) does not have A/AAAA record.<br />
Failed to update DNS records.</pre><br />
Проверьте IP-адрес доменного DNS сервера в файле {{path|/etc/resolv.conf}}}}<br />
<br />
В случае возникновения ошибки, необходимо перед повторной установкой запустить процедуру удаления:<br />
# ipa-client-install -U --uninstall<br />
<br />
Для работы sudo-политик для доменных пользователей на клиентской машине необходимо разрешить доступ к sudo:<br />
<pre># control sudo public</pre><br />
=== Вход пользователя ===<br />
<br />
При первом входе пользователя будет запрошен текущий установленный администратором пароль и затем у пользователя запрашивается новый пароль и его подтверждение.<br />
<br />
{{Attention|Если машина до этого была в других доменах или есть проблемы со входом пользователей рекомендуется очистить кэш sssd:<br />
<pre># systemctl stop sssd<br />
# rm -f /var/lib/sss/db/*<br />
# rm -f /var/lib/sss/mc/*<br />
# systemctl start sssd</pre>}}<br />
<br />
== IPA Automount NFS ==<br />
Установим nfs-server: <br />
<pre> apt-get install nfs-server </pre><br />
<br />
Включим SECURE_NFS:<br />
<pre>echo 'SECURE_NFS=yes' >> /etc/sysconfig/nfs</pre><br />
<br />
Добавим сервис в автозапуск:<br />
<pre>systemctl enable --now nfs-server</pre><br />
Добавим список экспорта и применим изменения:<br />
<pre><br />
# mkdir -p /exports/test_share <br />
# echo '/exports/test_share client1.testbc.testbe(rw,no_subtree_check,sec=krb5p)' >> /etc/exports<br />
# exportfs -vra<br />
</pre><br />
На IPA сервере:<br />
<pre># kinit admin</pre><br />
Добавить ipa сервис где nfs.testbc.testbe наш nfs сервер:<br />
<pre># ipa service-add nfs/nfs.testbc.testbe</pre><br />
Добавляем в keytab:<br />
<pre># ipa-getkeytab -s freeipa.testbc.testbe -p nfs/nfs.testbc.testbe -k /etc/krb5.keytab</pre><br />
Проверим наличие:<br />
<pre># klist -k /etc/krb5.keytab<br />
Keytab name: FILE:/etc/krb5.keytab <br />
KVNO Principal <br />
---- ---------- <br />
2 host/nfs.testbc.testbe@TESTBC.TESTBE <br />
1 nfs/nfs.testbc.testbe@TESTBC.TESTBE</pre><br />
Перезапустим nfs сервер:<br />
<pre># systemctl restart nfs-server</pre><br />
Добавим правила автомонтирования:<br />
<pre><br />
# ipa automountmap-add default auto.test<br />
# ipa automountkey-add default --key "/-" --info auto.test auto.master<br />
# ipa automountkey-add default --key "/mnt/testshare" --info "-fstype=nfs4,rw,sec=krb5p,hard nfs.testbc.testbe:/exports/test_share" auto.test<br />
</pre><br />
Удалим пустую карту монтирования:<br />
<pre># ipa automountkey-del --key '/-' --info 'auto.direct' default auto.master</pre><br />
Настройка клиента: <br />
ipa-client-install<br />
Устанавливаем пакет freeipa-client-automount:<br />
<pre> # apt-get install freeipa-client-automount </pre><br />
Проверим доступность nfs:<br />
<pre># showmount -e nfs.testbc.testbe</pre><br />
Настроим автомонтирование:<br />
<pre># ipa-client-automount --location default</pre><br />
На IPA сервере:<br />
Создадим пользователя:<br />
<pre># ipa user-add ipatest --first ipatest --last ipatest</pre><br />
Предоставим пользователю права на запись:<br />
<pre># mkdir /exports/test_share/testdir <br />
# chown ipatest:ipatest /exports/test_share/testdir</pre><br />
Создадим домашнюю папку пользователя на nfs сервере:<br />
<pre># mkhomedir_helper ipatest<br />
# echo '/home client1.testbc.testbe(rw,no_subtree_check,sec=krb5p)' >> /etc/exports <br />
# exportfs -vra<br />
</pre><br />
Добавим правила автомонтирования:<br />
<pre>ipa automountmap-add default auto.home <br />
ipa automountkey-add default --key "/home" --info auto.home auto.master <br />
ipa automountkey-add default --key "*" --info "-fstype=nfs4,rw,sec=krb5p,hard nfs.testbc.testbe:/home/&" auto.home</pre><br />
Проверяем на клиенте:<br />
<pre>$ df -h</pre><br />
Для отладки используйте:<br />
<br />
NFS/autofs/sssd-autofs: <br />
<pre>systemctl stop autofs <br />
automount -fd -vvv</pre> <br />
krb5: <br />
<pre>sed -i '/^GSSD_OPTIONS=/{s/"$/ -vvv"/g}' /etc/sysconfig/nfs<br />
systemctl restart rpc-gssd</pre><br />
<br />
== Настройка репликации ==<br />
<br />
На втором контроллере домена установим необходимые пакеты:<br />
<pre># apt-get install freeipa-client freeipa-server-dns</pre><br />
<br />
Зададим имя сервера:<br />
<pre># hostnamectl set-hostname ipabackup.example.test</pre><br />
<br />
Теперь развернём и настроим клиента:<br />
<pre><br />
# ipa-client-install -d \<br />
--domain=example.test \<br />
--server=ipa.example.test \<br />
--realm=EXAMPLE.TEST \<br />
--principal=admin \<br />
--password=12345678 \<br />
--enable-dns-updates -U<br />
</pre><br />
<br />
После выполнения этой операции хост '''ipabackup.example.test''' должен появиться в веб-интерфейсе FreeIPA. Переходим к настройке репликации LDAP-каталога:<br />
<pre># ipa-replica-install</pre><br />
<br />
Добавляем в DNS второй NTP-сервер:<br />
<pre><br />
# kinit admin<br />
# ipa dnsrecord-add example.test _ntp._udp --srv-priority=0 --srv-weight=100 --srv-port=123 --srv-target=ipabackup.example.test.<br />
</pre><br />
<br />
Настроим репликацию DNS-зон:<br />
<pre># ipa-dns-install</pre><br />
<br />
Наконец, настроим репликацию CA:<br />
<pre># ipa-ca-install</pre><br />
<br />
После настройки и репликации контроллеров посмотреть топологию можно в веб-интерфейсе FreeIPA (IPA Server -> Topology -> Topology Graph).<br />
<br />
<br />
== Настройка доверительных отношений с AD ==<br />
FreeIPA использует Samba для интеграции в Active Directory. Для работы Samba необходим работающий стек IPv6.<br><br />
Начальные данные:<br />
* IP адрес IPA сервера: '''192.168.135.130'''<br />
* Имя IPA сервера: '''dcf'''<br />
* Имя IPA домена: '''domf.testf'''<br />
* NetBIOS имя IPA домена: '''DOMF'''<br />
* IP адрес AD DC: '''192.168.135.150'''<br />
* Имя AD DC: '''dcc'''<br />
* Имя AD домена: '''domc.testc'''<br />
* NetBIOS имя AD домена: '''DOMC'''<br />
<br />
Установим необходимые пакеты:<br />
<pre># apt-get install freeipa-server-trust-ad python-module-sss-murmur samba-winbind</pre><br />
=== Предварительная настройка IPA сервера ===<br />
'''Настроим IPA''' для работы с доверительными отношениями:<br />
<pre># ipa-adtrust-install</pre><br />
Скрипт спросит необходимо ли конфигурировать {{path|slapi-nis}} плагин для поддержки работы старых клиентов (SSSD < 1.9) с пользователем из доверенного домена:<br />
<pre>Enable trusted domains support in slapi-nis? [no]:</pre> <br />
На IPA сервере добавлен хотя бы один пользователь (администратор сервера), поэтому скрипт предложит сгенерировать SID для всех существующих пользователей и груп:<br />
<pre>Do you want to run the ipa-sidgen task? [no]:</pre><br />
Дата и время на серверах должны совпадать.<pre><br />
IPA сервер в своей работе использует следующие порты:<br />
<pre>TCP ports: 80, 88, 443, 389, 636, 88, 464, 53, 135, 138, 139, 445, 1024-1300<br />
UDP ports: 88, 464, 53, 123, 138, 139, 389, 445</pre><br />
Они должны быть открыты и доступны.<br><br />
'''Настроим Samba:'''<br><br />
<pre># net conf setparm global 'dedicated keytab file' /etc/samba/samba.keytab<br />
# systemctl restart ipa</pre><br />
Проверим проходит ли Samba аутентификацию Kerberos со стороны IPA сервера:<br />
<pre># kinit admin<br />
# smbclient -L dcf.domf.testf -k<br />
lp_load_ex: changing to config backend registry<br />
Domain=[DOMF] OS=[Windows 6.1] Server=[Samba 4.5.5]<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (Samba 4.5.5)<br />
Domain=[DOMF] OS=[Windows 6.1] Server=[Samba 4.5.5]<br />
<br />
Server Comment<br />
--------- -------<br />
<br />
Workgroup Master<br />
--------- -------</pre><br />
'''Настроим DNS''' на обоих серверах, чтобы они знали друг о друге:<br><br />
На AD сервере создадим сервер условной пересылки для зоны IPA домена:<br />
<pre>C:\> dnscmd 127.0.0.1 /ZoneAdd domf.testf /Forwarder 192.168.135.130</pre><br />
На IPA сервере так же добавим зону AD домена:<br />
<pre># ipa dnsforwardzone-add domc.testc --forwarder=192.168.135.150 --forward-policy=only</pre><br />
<br />
=== Проверка конфигурации DNS ===<br />
'''На AD сервере:'''<br><br />
Проверим наличие записей для работы сервисов IPA на DNS-сервере AD.<br><br />
1. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:<br />
<pre>C:\>nslookup.exe<br />
> set type=SRV<br />
<br />
> _kerberos._udp.domf.testf.<br />
_kerberos._udp.domf.testf. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 88<br />
svr hostname = dcf.domf.testf.<br />
<br />
> _ldap._tcp.domf.testf.<br />
_ldap._tcp.ipa.example.com SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 389<br />
svr hostname = dcf.domf.testf.</pre><br />
<br />
2. Запись отвечающая за имя Kerberos realm IPA домена:<br />
<pre>C:\>nslookup.exe<br />
> set type=TXT<br />
> _kerberos.domf.testf.<br />
_kerberos.domf.testf. text =<br />
<br />
"DOMF.TESTF"</pre><br />
<br />
3. После выполнения команды {{path|ipa-adtrust-install}} должны появится записи отвечающие за работу сервисов MS DC Kerberos через UDP и LDAP через TCP:<br />
<pre>C:\>nslookup.exe<br />
> set type=SRV<br />
> _kerberos._udp.dc._msdcs.domf.testf.<br />
_kerberos._udp.dc._msdcs.domf.testf. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 88<br />
svr hostname = dcf.domf.testf.<br />
> _ldap._tcp.dc._msdcs.domf.testf.<br />
_ldap._tcp.dc._msdcs.domf.testf. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 389<br />
svr hostname = dcf.domf.testf.</pre><br />
Далее проверим наличие записей для работы сервисов AD на DNS-сервере AD.<br><br />
4. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:<br />
<pre>C:\>nslookup.exe<br />
> set type=SRV<br />
> _kerberos._udp.dc._msdcs.domc.testc.<br />
_kerberos._udp.dc._msdcs.domc.testc. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 88<br />
svr hostname = dcc.domc.testc.<br />
> _ldap._tcp.dc._msdcs.domc.testc.<br />
_ldap._tcp.dc._msdcs.domc.testc. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 389<br />
svr hostname = dcc.domc.testc.</pre><br />
<br />
'''На IPA сервере:'''<br><br />
Проверим наличие записей для работы сервисов IPA на DNS-сервере IPA.<br><br />
1. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:<br />
<pre># dig +short -t SRV _kerberos._udp.domf.testf.<br />
0 100 88 dcf.domf.testf.<br />
<br />
# dig +short -t SRV _ldap._tcp.domf.testf.<br />
0 100 389 dcf.domf.testf.</pre><br />
2. Запись отвечающая за имя Kerberos realm IPA домена:<br />
<pre>dig +short -t TXT _kerberos.domf.testf.<br />
"DOMF.TESTF"</pre><br />
3. После выполнения команды {{path|ipa-adtrust-install}} должны появится записи отвечающие за работу сервисов MS DC Kerberos через UDP и LDAP через TCP:<br />
<pre># dig +short -t SRV _kerberos._udp.dc._msdcs.domf.testf.<br />
0 100 88 dcf.domf.testf.<br />
<br />
# dig +short -t SRV _ldap._tcp.dc._msdcs.domf.testf.<br />
0 100 389 dcf.domf.testf.</pre><br />
Далее проверим наличие записей для работы сервисов AD на DNS-сервере IPA.<br />
4. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:<br />
<pre># dig +short -t SRV _kerberos._udp.dc._msdcs.domc.testc.<br />
0 100 88 dcc.domc.testc.<br />
<br />
# dig +short -t SRV _ldap._tcp.dc._msdcs.domc.testc.<br />
0 100 389 dcc.domc.testc.</pre><br />
{{Attention|Если запись {{cmd|_kerberos._udp.dc._msdcs.domc.testc.}} не доступна проверьте {{cmd|_kerberos._tcp.dc._msdcs.domc.testc.}}}}<br />
<br />
=== Настройка доверия ===<br />
Добавление двунаправленных доверительных отношений леса (Forest Trust) с AD:<br><br />
Имя доменного администратора Windows должно быть на латинице, кириллицу (Администратор) IPA не принимает.<br><br />
<pre># kinit admin<br />
# ipa trust-add --type=ad domc.testc --admin Administrator --password --two-way=true<br />
Active Directory domain administrator's password: <br />
---------------------------------------------------<br />
Added Active Directory trust for realm "domc.testc"<br />
---------------------------------------------------<br />
Realm name: domc.testc<br />
Domain NetBIOS name: DOMC<br />
Domain Security Identifier: S-1-5-21-3611360735-1365415015-3217858865<br />
SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13,<br />
S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18<br />
SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13,<br />
S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18<br />
Trust direction: Two-way trust<br />
Trust type: Active Directory domain<br />
Trust status: Established and verified<br />
</pre><br />
Необходимо ввести пароль Administrator AD.<br><br />
Далее необходимо запросить сервер AD о его доверенных доменах:<br />
<pre># ipa trust-fetch-domains domc.testc<br />
--------------------------------------------<br />
List of trust domains successfully refreshed<br />
--------------------------------------------<br />
Realm name: domd.domc.testc<br />
Domain NetBIOS name: DOMD<br />
Domain Security Identifier: S-1-5-21-2419724241-1549151283-3268040000<br />
------------------------------<br />
Количество вернутых значений 1<br />
------------------------------<br />
</pre><br />
При этом IPA создаст нужные id-диапазоны для доверенных доменов.<br><br />
Если мы добавим в лес еще один домен DOME.TESTE, то необходимо настроить DNS на обоих серверах, чтобы они видели друг друга.<br><br />
И выполнить команду еще раз,чтобы IPA сервер узнал о нем:<br />
<pre># ipa trust-fetch-domains domc.testc<br />
--------------------------------------------<br />
List of trust domains successfully refreshed<br />
--------------------------------------------<br />
Realm name: dome.teste<br />
Domain NetBIOS name: DOME<br />
Domain Security Identifier: S-1-5-21-3615012966-1241218098-4147673574<br />
------------------------------<br />
Количество вернутых значений 1<br />
------------------------------</pre><br />
Найти все доверенные домены можно и с помощью web-интерфейса. Для Перейдем в IPA Server -> Trusts и выберем нужный нам домен:<br><br />
[[Файл:IPATrusts.png|600px]]<br><br />
Нажмём кнопку Fetch domains это обновит список доверенных доменов:<br><br />
[[Файл:IPATrustFetch.png|600px]]<br><br />
<br />
Для того чтобы увидеть список всех доверенных доменов из леса используйте следующую команду:<br />
<pre># ipa trustdomain-find domc.testc<br />
Domain name: domc.testc<br />
Domain NetBIOS name: DOMC<br />
Domain Security Identifier: S-1-5-21-3611360735-1365415015-3217858865<br />
Domain enabled: True<br />
<br />
Domain name: domd.domc.testc<br />
Domain NetBIOS name: DOMD<br />
Domain Security Identifier: S-1-5-21-2419724241-1549151283-3268040000<br />
Domain enabled: True<br />
<br />
Domain name: dome.teste<br />
Domain NetBIOS name: DOME<br />
Domain Security Identifier: S-1-5-21-3615012966-1241218098-4147673574<br />
Domain enabled: True<br />
------------------------------<br />
Количество вернутых значений 3<br />
------------------------------<br />
</pre><br />
<br />
=== Проверка конфигурации Kerberos ===<br />
1. Запросим ticket для IPA пользователя:<br />
<pre># kinit admin</pre><br />
2. Запросим service ticket для сервиса из IPA домена:<br />
<pre># kvno -S host dcf.domf.testf<br />
host/dcf.domf.testf@DOMF.TESTF: kvno = 2</pre><br />
3. Запросим service ticket сервиса из AD домена:<br />
<pre># kvno -S cifs dcc.domc.testc<br />
cifs/dcc.domc.testc@: kvno = 3</pre><br />
Если запрос service ticket для сервиса из AD домена прошел успешно, то у нас должен появиться междоменный ticket-granting ticket, его имя krbtgt/DOMC.TESTC@DOMF.TESTF:<br />
<pre># klist<br />
Ticket cache: KEYRING:persistent:0:0<br />
Default principal: admin@DOMF.TESTF<br />
<br />
Valid starting Expires Service principal<br />
14.02.2017 15:43:46 15.02.2017 01:43:46 cifs/dcc.domc.testc@DOMC.TESTC<br />
14.02.2017 15:43:46 15.02.2017 01:43:46 cifs/dcc.domc.testc@<br />
14.02.2017 15:43:46 15.02.2017 15:42:48 krbtgt/DOMC.TESTC@DOMF.TESTF<br />
14.02.2017 15:43:25 15.02.2017 15:42:48 host/dcf.domf.testf@DOMF.TESTF<br />
14.02.2017 15:42:53 15.02.2017 15:42:48 krbtgt/DOMF.TESTF@DOMF.TESTF</pre><br />
=== Проверка пользователей доверенного домена ===<br />
Проверим имеет ли доступ к пользователям из доверенного домена рабочие станции IPA.<br><br />
Для этого на рабочей станции IPA выполните команду:<br />
<pre># getent passwd u01domc@domc<br />
u01domc@domc.testc:*:328601108:328601108:u01domc:/home/domc.testc/u01domc:</pre><br />
Где u01domc это пользователь из AD домена. Обратите внимание, что не указана оболочка входа. Назначить оболочку входа для пользователей из доверенного домена можно добавив на сервере IPA в файл {{path|/etc/sssd/sssd.conf}} следующую строчку:<br />
<pre>[domain/domf.testf]<br />
...<br />
default_shell = /bin/bash<br />
...</pre><br />
Вывод команды должен стать таким:<br />
<pre># getent passwd u01domc@domc<br />
u01domc@domc.testc:*:328601108:328601108:u01domc:/home/domc.testc/u01domc:/bin/bash</pre><br />
{{Attention|Для корректной работы сервера IPA с пользователями доверенного домена AD необходимо обеспечить доступ сервиса sssd к /etc/krb5.keytab см. [https://bugzilla.altlinux.org/33115 bug 33115]}}<br />
{{Attention|Для входа AD пользователя в ALT рабочую станцию из IPA вводим имя пользователя в формате '''DOMC'''\username или '''DOMC.TESTC'''\username или username@'''domc''' username@'''domc.testc'''}}<br />
{{Attention|Для входа IPA пользователя в windows рабочую станцию из AD вводим имя пользователя в формате '''DOMF.TESTF'''\username}}<br />
<br />
== Создание аккаунта для доступа к LDAP ==<br />
Некоторые сервисы использующие LDAP требуют предварительно настроенной учетной записи. Использование обычной учетной записи пользователя предпочтительней, но не всегда это целесообразно делать. Можно сделать системную учетную запись следующим образом на сервере FreeIPA используя пароль Directory :<br />
<pre># ldapmodify -x -D 'cn=Directory Manager' -W<br />
dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=test<br />
changetype: add<br />
objectclass: account<br />
objectclass: simplesecurityobject<br />
uid: ldapaccount<br />
userPassword: secret123<br />
passwordExpirationTime: 20380119031407Z<br />
nsIdleTimeout: 0<br />
<blank line><br />
^D</pre><br />
Замените пароль на более сложный. Параметр {{path|passwordExpirationTime: 20380119031407Z}} означает, что срок действия пароля неограничен<br />
Причина использования такой учетной записи, а не создание обычной учетной записи пользователя IPA, и использование этой системы заключается в том, что системная учетная запись существует только для привязки к LDAP. Это не настоящий пользователь POSIX, он не может войти в систему и ему не принадлежат файлы. У этого пользователя нет особых прав и он не может ничего записывать какие-либо данные на сервер LDAP FreeIPA, только права на чтение.<br />
<br />
== Добавление расширенных полей в ldap ==<br />
<br />
Если необходимо добавить поля в вашу схему ldap, то реализация этого возможна через команду ldapmodify и добавление своих плагинов для отображения этих полей в WebUi.<br><br />
Обычно файлы модификации схемы являются типом ''.ldif''.<br><br />
Пример:<br><br />
Содержание файла addExtField.ldif <br><br />
<pre>dn: cn=schema<br />
changetype: modify<br />
add: attributeTypes<br />
attributeTypes: ( 2.25.28639311321113238241701611583088740684.14.2.2 NAME 'favoriteColorName' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Extending FreeIPA' )<br />
<br />
dn: cn=schema<br />
changetype: modify<br />
add: attributeTypes<br />
attributeTypes: ( 2.25.28639311321113238241701611583088740684.14.2.3 NAME 'redirects' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Extending FreeIPA')<br />
<br />
dn: cn=schema<br />
changetype: modify<br />
add: attributeTypes<br />
attributeTypes: ( 2.25.28639311321113238241701611583088740684.14.2.4 NAME 'attbool' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 X-ORIGIN 'Extending FreeIPA')<br />
<br />
dn: cn=schema<br />
changetype: modify<br />
add: objectclasses<br />
objectclasses: ( 2.25.28639311321113238241701611583088740684.14.2.1 NAME 'customPerson' SUP person STRUCTURAL MAY ( favoriteColorName $ attbool $ redirects ) X-ORIGIN 'Extending FreeIPA' )</pre><br />
<br />
Детальное пояснение для блока:<br><br />
<br />
<pre>dn: cn=schema<br />
changetype: modify<br />
add: attributeTypes<br />
attributeTypes: ( 2.25.28639311321113238241701611583088740684.14.2.2<br />
NAME 'favoriteColorName'<br />
EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch<br />
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15<br />
X-ORIGIN 'Extending FreeIPA' )</pre><br />
<br />
'''dn''' - dn, в котором будет проводиться изменение. Добавление/удаление классов и т.д.<br><br />
<br />
'''changetype''' - атрибут, отвечающий за тип изменений, которые будут происходить.(add, delete, modify, modrdn)<br><br />
<br />
'''add: attributeTypes''' - добавление атрибута, далее идёт описание атрибута.<br><br />
'''2.25.28639311321113238241701611583088740684.14.2.2''' - уникальный идентификатор атрибута. Можно написать любой.<br><br />
<br />
'''NAME 'favoriteColorName' ''' - По другому можно назвать - primary name. Название атрибута.<br><br />
<br />
'''EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch''' - эти атрибуты заданы для проверки соответствия содержания атрибута правилам caseIgnoreMatch <br><br />
<br />
'''SYNTAX 1.3.6.1.4.1.1466.115.121.1.15''' - OID типа данных <br><br />
<br />
Все изменения в схеме производятся от пользователя - Directory manager.<br><br />
<br />
Изменение схемы ldap:<br />
<br />
<pre>$ ldapmodify -D "cn=Directory Manager" -W -f addExtField.ldif</pre><br />
<br />
После изменения схемы, путем добавления нового objectclass, нужно чтобы эти поля еще можно было редактировать в web-интерфейсе. Для этого необходимо сделать палагин. В примере использовано 3 атрибута, для них сделаем 3 отдельных плагина:<br />
<br />
1. Создание папки:<br />
<pre>mkdir -p /usr/share/ipa/ui/js/plugins/favoriteColorName</pre><br />
<br />
2. Создание самого плагина:<br />
<pre>mcedit /usr/share/ipa/ui/js/plugins/favoriteColorName/favoriteColorName.js</pre><br />
Тело плагина:<br />
<br />
<pre>define(['freeipa/phases','freeipa/user'],<br />
function(phases, user_mod) {<br />
// helper function<br />
function get_item(array, attr, value) {<br />
for (var i=0,l=array.length; i<l; i++) {<br />
if (array[i][attr] === value) return array[i];<br />
}<br />
return null;<br />
}<br />
<br />
var color_plugin = {};<br />
<br />
color_plugin.add_favorite_color = function() {<br />
var facet = get_item(user_mod.entity_spec.facets, '$type', 'details');<br />
var section = get_item(facet.sections, 'name', 'identity');<br />
section.fields.push({<br />
name: 'favoritecolorname',<br />
label: 'Цвет'<br />
});<br />
return true;<br />
};<br />
<br />
phases.on('customization', color_plugin.add_favorite_color);<br />
<br />
return color_plugin;<br />
});</pre><br />
<br />
В схеме бы добавлен атрибут типа boolean, для него можно сделать радиокнопки:<br><br />
<br />
<pre>define(['freeipa/phases','freeipa/user'],<br />
function(phases, user_mod) {<br />
// helper function<br />
function get_item(array, attr, value) {<br />
for (var i=0,l=array.length; i<l; i++) {<br />
if (array[i][attr] === value) return array[i];<br />
}<br />
return null;<br />
}<br />
<br />
var attrbool_plugin = {};<br />
<br />
attrbool_plugin.add_bool = function() {<br />
var facet = get_item(user_mod.entity_spec.facets, '$type', 'details');<br />
var section = get_item(facet.sections, 'name', 'identity');<br />
section.fields.push(<br />
{<br />
$type: 'radio',.<br />
options:[{label:'True',value:'TRUE'},{label:'False',value:'FALSE'}],<br />
label:'Blood type',<br />
name: 'attbool'}<br />
);<br />
return true;<br />
};<br />
<br />
phases.on('customization', attrbool_plugin.add_bool);<br />
<br />
return attrbool_plugin;<br />
});<br />
<br />
</pre><br />
<br />
После необходимо добавить новое поле в "Default user objectclasses" (находится IPA Server -> Configuration) созданный objectclass (customPerson) и появятся поля в web-интерфейсе. Для того чтобы пользователь мог их редактировать, необходимо изменить привилегии в группе ipausers. <br><br />
== Использование haproxy для высокой доступности FreeIPA ==<br />
'''Требуется:''' <br />
<br />
Сервер №1 c freeipa: dc1.testbc.testgl<br />
<br />
Сервер №2 с репликой freeipa: dc2.testbc.testgl<br />
<br />
Сервер №3 с haproxy: haproxy.testbc.testgl<br />
<br />
[[Файл:Схема.png]]<br />
<br />
'''Настройка:'''<br />
<br />
Инструкция для настройки сервера №1 и №2: [[FreeIPA]]<br />
<br />
На сервере №3: <br />
<br />
Установить<br />
<pre># apt-get install haproxy</pre><br />
Сохранить оригинальный конфигурационный файл:<br />
<br />
<pre>cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxyBAK.cfg</pre><br />
Изменить конфигурацию:<br />
<pre><br />
cat << EOF > /etc/haproxy/haproxy.cfg<br />
global<br />
log 127.0.0.1 local2<br />
<br />
chroot /var/lib/haproxy<br />
pidfile /var/run/haproxy.pid<br />
maxconn 4000<br />
user _haproxy<br />
group _haproxy<br />
daemon<br />
<br />
stats socket /var/lib/haproxy/stats<br />
# LDAP and LDAP/STARTTLS<br />
frontend ldap_service_front<br />
mode tcp<br />
bind *:389<br />
description LDAP Service<br />
option socket-stats<br />
option tcpka<br />
timeout client 3600s<br />
default_backend ldap_service_back<br />
<br />
backend ldap_service_back<br />
server ldap-1 dc1.testbc.testgl:389 check fall 1 rise 3 inter 2s weight 150<br />
server ldap-2 dc2.testbc.testgl:389 check fall 1 rise 3 inter 2s weight 100<br />
mode tcp<br />
balance roundrobin<br />
option tcpka<br />
option ldap-check<br />
timeout server 1800s<br />
timeout connect 1s<br />
frontend ldaps_service_front<br />
mode tcp<br />
bind *:636<br />
description LDAP Service<br />
option socket-stats<br />
option tcpka<br />
timeout client 3600s<br />
default_backend ldap_service_back<br />
<br />
backend ldaps_service_back<br />
server ldap-1 dc1.testbc.testgl:636 check fall 1 rise 3 inter 2s weight 150<br />
server ldap-2 dc1.testbc.testgl:636 check fall 1 rise 3 inter 2s weight 150<br />
mode tcp<br />
balance roundrobin<br />
option tcpka<br />
option ssl-hello-chk<br />
timeout server 1800s<br />
EOF<br />
</pre><br />
Запустить сервис haproxy:<br />
<pre>#systemctl start haproxy</pre><br />
Проверить работу можно с помощью ldapsearch сделав один из серверов недоступным:<br />
<pre>ldapsearch -x -h haproxy.testbc.testgl -b dc=testbc,dc=testgl uid=admin</pre><br />
Результат: ldap всегда доступен.<br />
<br />
== Automember rebuild membership ==<br />
<br />
Пользовательские или хост группы можно легко перестроить на основе новых или обновленных правил automember. Команда automember rebuild только добавляет новые отношения для групп, она не удаляет те, которые не соответствуют правилам automember. Недавно добавленная команда вызовет задачу в rebuild automember, создав запись LDAP в cn = automember rebuild membership, cn = tasks, cn = config. Плагин automember в настоящее время проверяет операции Add(добавления), чтобы увидеть, есть ли запись соответствует одному из определенных правил automember. Существующие записи не проверяются когда они изменяются. Чтобы применить правило для всех записей, надо добавить задачу к плагину automember. Создатель задачи обеспечит фильтр поиска и базу. Все совпадающие записи будут проверяться в соответствии с определенными правилами automember, чтобы увидеть если они должны быть добавлены в какие-либо группы. Это позволяет добавить запуск атрибуты(значения) после того, как запись была первоначально добавлена, а затем вызвать задачу(выполнить) обновления automember. Ipa automember-rebuild может использоваться для восстановления членства для всех объектов определенного типа:<br />
<pre><br />
$ ipa automember-rebuild --type=group<br />
$ ipa automember-rebuild --type=hostgroup<br />
</pre><br />
Он также может использоваться для восстановления членства для указанных записей:<br />
<pre><br />
$ ipa automember-rebuild --hosts=HOSTNAME1 --hosts=HOSTNAME2<br />
$ ipa automember-rebuild --users=LOGIN1 --users=LOGIN2<br />
</pre><br />
Добавление новой группы хостов:<br />
<pre><br />
$ ipa hostgroup-add --desc="Web Servers" webservers<br />
</pre><br />
Добавить новый хост:<br />
<pre><br />
$ ipa host-add web1.example.com --force<br />
</pre><br />
Добавить automember rule:<br />
<pre><br />
$ ipa automember-add --type=hostgroup webservers<br />
$ ipa automember-add-condition --key=fqdn --type=hostgroup --inclusive-regex=^web[1-9]+\.example\.com webservers<br />
</pre><br />
Функция automember теперь работает для новых добавленных записей. Если мы добавим новый хост, он будет автоматически помещен в соответствующую группу хостов:<br />
<pre><br />
$ ipa host-add web2.example.com --force<br />
$ ipa hostgroup-show webservers<br />
Host-group: webservers<br />
Description: Web Servers<br />
Member hosts: web2.example.com<br />
</pre><br />
Однако старая запись хоста для web1.example.com по-прежнему не является членом или хост-группой веб-серверов. Введя новые команды automember-rebuild, мы сделаем это возможным:<br />
<pre> <br />
$ ipa automember-rebuild --type=hostgroup<br />
or<br />
$ ipa automember-rebuild --hosts=web1.example.com<br />
</pre><br />
Хост добавится в новую группу:<br />
<pre><br />
$ ipa hostgroup-show webservers<br />
Host-group: webservers<br />
Description: Web Servers<br />
Member hosts: web2.example.com, web1.example.com<br />
</pre><br />
Тоже самое можно сделать в web-интерфейсе.<br />
<br />
== Дополнительные материалы ==<br />
* [https://habrahabr.ru/company/pixonic/blog/325546/ Настройка репликации во FreeIPA 4.4 с domain level 1] — Блог Pixonic на Habrahabr<br />
* [Система централизованного управления авторизацией пользователей на FreeIPA в Docker Система централизованного управления авторизацией пользователей на FreeIPA в Docker] — frol, Habrahabr<br />
<br />
[[Категория:Корпоративная инфраструктура]]<br />
[[Категория:HOWTO]]<br />
<br />
{{Category navigation|title=Корпоративная инфраструктура|category=Корпоративная инфраструктура|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=FreeIPA&diff=48569FreeIPA2020-06-05T11:58:21Z<p>AntonFarygin: /* Настройка IPA CA-less репликации */</p>
<hr />
<div>[[Файл:Freeipa-logo-small.png|frameless|right]]<br />
FreeIPA - это комплексное решение по управлению безопасностью Linux-систем, 389 Directory Server, MIT Kerberos, NTP, DNS, Dogtag. Оно состоит из веб-интерфейса и интерфейса командной строки.<br><br />
FreeIPA является интегрированной системой проверки подлинности и авторизации в сетевой среде Linux, FreeIPA сервер обеспечивает централизованную проверку подлинности, авторизацию и контроль за аккаунтами пользователей сохраняя сведения о пользователе, группах, узлах и других объектах необходимых для обеспечения сетевой безопасности.<br />
<br />
[https://www.freeipa.org/ Сайт проекта], [https://ipa.demo1.freeipa.org/ipa/ui/ демонстрация интерфейса].<br />
<br />
== Установка сервера FreeIPA ==<br />
Устанавливать будем со встроенным DNS сервером и доменом EXAMPLE.TEST в локальной сети 192.168.135.0/24.<br><br />
Для начала отключим ahttpd, работающий на порту 8080, во избежание конфликтов с разворачиваемым tomcat и отключим HTTPS в Apache2:<br />
# service ahttpd stop<br />
# a2dissite 000-default_https<br />
# a2disport https<br />
# service httpd2 condreload<br />
<br />
Установим необходимые пакеты:<br />
<pre># apt-get install freeipa-server freeipa-server-dns</pre><br />
Зададим имя сервера:<br />
<pre># hostnamectl set-hostname ipa.example.test</pre><br />
<br />
Для ускорения установки можно установить демон энтропии haveged:<br />
<pre> # apt-get install haveged<br />
# systemctl enable haveged<br />
# systemctl start haveged </pre><br />
<br />
Запускаем скрипт настройки сервера:<br />
<br />
В пакетном режиме: <br />
# ipa-server-install -U --hostname=$(hostname) -r EXAMPLE.TEST -n example.test -p 12345678 -a 12345678 --setup-dns --no-forwarders --no-reverse<br />
или интерактивно:<br />
<pre># ipa-server-install</pre><br />
<br />
{{Attention|Пароли должны быть не менее 8 символов}}<br />
<br />
Обратите внимание на ответы на вопросы, не совпадающие с предложенными:<br />
Do you want to configure integrated DNS (BIND)? [no]: yes<br />
<br />
остальные вопросы выбираем по умолчанию (можно просто нажать Enter). Так же при установке попросят ввести пароль администратора системы и пароль администратора каталогов.<br><br />
<br />
Для возможности управлять FreeIPA сервером из командной строки необходимо получить билет Kerberos:<br />
<pre># kinit admin</pre><br />
Добавим в DNS запись о нашем сервере времени:<br />
<pre># ipa dnsrecord-add example.test _ntp._udp --srv-priority=0 --srv-weight=100 --srv-port=123 --srv-target=ipa.example.test.</pre><br />
<br />
Проверить работу ntp сервера можно командой:<br />
<pre># ntpdate -q localhost<br />
server 127.0.0.1, stratum 3, offset 0.000018, delay 0.02568<br />
27 Apr 10:27:00 ntpdate[3491]: adjust time server 127.0.0.1 offset 0.000018 sec</pre><br />
<br />
Также доступен веб-интерфейс по адресу: <br />
<pre>https://ipa.example.test/ipa/ui/</pre><br />
<br />
{{Note|Если выдаёт <pre>[error] CalledProcessError: Command '/sbin/systemctl restart httpd2.service' returned non-zero exit status 1</pre><br />
Выполните <br />
# systemctl restart httpd2<br />
Отмените установку: <br />
# ipa-server-install -U --uninstall<br />
и повторите снова.}}<br />
<br />
== Установка сервера FreeIPA в режиме CA-less ==<br />
Установим необходимые пакеты:<br />
<pre># apt-get install freeipa-server freeipa-server-dns</pre><br />
Зададим имя сервера:<br />
<pre># hostnamectl set-hostname ipa.example.test</pre><br />
Подготовим сертификаты для сервера FreeIPA:<br />
<pre># mkdir ~/test_ca</pre><br />
Создадим файл pwdfiles.txt с паролем, например 12345678:<br />
<pre># echo 12345678 > ~/test_ca/pwdfile.txt</pre><br />
Создадим базу данных NSS:<br />
<pre>/usr/bin/certutil -d ~/test_ca -N -f ~/test_ca/pwdfile.txt</pre><br />
Создадим noise файл с рандомом:<br />
<pre># head -c20 /dev/random > ~/test_ca/noise.txt</pre><br />
Экспортируем переменную:<br />
<pre># export CERT_SERIAL=1</pre><br />
Создаем CA сертификат:<br />
<pre># /usr/bin/certutil -d ~/test_ca -S -n "CA" -s "CN=Certificate Authority" -x -t CT,,C -1 -2 -5 -m $CERT_SERIAL -v 120 -z ~/test_ca/noise.txt -f ~/test_ca/pwdfile.txt</pre><br />
Дайте следующие ответы:<br />
<pre> Create key usage extension:<br />
0 - Digital Signature<br />
1 - Non-repudiation<br />
5 - Cert signing key<br />
9 - done<br />
Is this a critical extension [y/N]? y<br />
Create basic constraint extension<br />
Is this a CA certificate [y/N]? y<br />
Enter the path length constraint, enter to skip [<0 for unlimited path]<br />
0<br />
Is this a critical extension [y/N]? y<br />
Extensions:<br />
5 - SSL<br />
6 - S/MIME<br />
7 - Object Signing CA<br />
9 - done<br />
Is this a critical extension [y/N]? n </pre><br />
Создадим запрос сертификата:<br />
<pre># head -c20 /dev/random > ~/test_ca/noise.txt<br />
# /usr/bin/certutil -d ~/test_ca -R -s CN=$HOSTNAME,O=IPA -o /tmp/servercert.req -k rsa -g 2048 -z ~/test_ca/noise.txt -f ~/test_ca/pwdfile.txt -a</pre><br />
Подпишите запрос о выдаче сертификата сервера:<br />
<pre># export CERT_SERIAL=$(($CERT_SERIAL + 1))<br />
# /usr/bin/certutil -d ~/test_ca -C -c "CA" -i /tmp/servercert.req -o /tmp/servercert.pem -m $CERT_SERIAL -v 120 -f ~/test_ca/pwdfile.txt -1 -5 -a</pre><br />
Дайте следующие ответы:<br />
<pre> Create key usage extension:<br />
2 - Key encipherment<br />
9 - done<br />
n - not critical<br />
Create netscape cert type extension:<br />
1 - SSL Server<br />
9 - done<br />
n - not critical</pre><br />
Если вы хотите, вы можете создавать отдельные сертификаты для серверов HTTP и Directory.<br />
<br />
'''Экспорт сертификатов в правильные форматы.'''<br />
Импортируем полученный сертификат:<br />
<pre># /usr/bin/certutil -d ~/test_ca -A -i /tmp/servercert.pem -n Server-Cert -a -t ,,</pre><br />
Экспортируем в PKCS#12:<br />
<pre># /usr/bin/pk12util -o ~/test_ca/servercert.p12 -n Server-Cert -d ~/test_ca -k ~/test_ca/pwdfile.txt -w ~/test_ca/pwdfile.txt</pre><br />
Экспортируйте сертификат CA в формате PEM:<br />
<pre># /usr/bin/certutil -d ~/test_ca -L -n "CA" -a > ~/test_ca/cacert.pem</pre><br />
Теперь установим CA-less IPA:<br />
<pre># export PWD=$(cat ~/test_ca/pwdfile.txt)<br />
# ipa-server-install --http_pkcs ~/test_ca/servercert.p12 --dirsrv_pkcs ~/test_ca/servercert.p12 --http_pin $PWD --dirsrv_pin $PWD --root-ca-file ~/test_ca/cacert.pem</pre><br />
<br />
'''Вы также можете указать при установке опции --pkinit-cert-file=Файл, содержащий сертификат SSL Kerberos KDC и закрытый ключ и --pkinit-pin=Пароль от закрытого ключа Kerberos KDC.'''<br />
<br />
После установки выполните:<br />
<pre>kinit admin</pre><br />
И после убедитесь что команды: <br />
<pre>ipa cert-find<br />
ipa cert-show 1</pre><br />
Не срабатывают и выводят ошибки.<br />
<br />
== Настройка IPA CA-less репликации ==<br />
{{Attention|Перед настройкой репликации необходимо выполнить установку клиента}}<br />
CA-Less конфигурация требуется в тех случаях, когда у вас по какой-то причине нет возможности развернуть на FreeIPA сервис PKI dogtag. Например, это на данный момент невозможно сделать в некоторых сертифицированных конфигурациях. <br />
Если у вас не сертифицированный дистрибутив ALT, то пропустите пункт по настройке CA-Less репликации.<br />
<br />
Чтобы установить реплику, сначала создайте сертификаты для новой машины: создадим запрос сертификата и подпишем запрос о выдаче сертификата сервера и экспортируем сертификаты в правильные форматы, на этот раз задав $HOSTNAME имя хоста будущей реплики. Используйте Replica-Cert вместо Server-Cert и ~/test_ca/replicacert.p12 вместо ~/test_ca/servercert.p12:<br />
Создадим запрос сертификата для реплики:<br />
<pre># head -c20 /dev/random > ~/test_ca/noise.txt<br />
# /usr/bin/certutil -d ~/test_ca -R -s CN=Указать хост будущей реплики,O=IPA -o /tmp/replicacert.req -k rsa -g 2048 -z ~/test_ca/noise.txt -f ~/test_ca/pwdfile.txt -a</pre><br />
Подпишите запрос о выдаче сертификата реплики:<br />
<pre># /usr/bin/certutil -d ~/test_ca -C -c "CA" -i /tmp/replicacert.req -o /tmp/replicacert.pem -m 3 -v 120 -f ~/test_ca/pwdfile.txt -1 -5 -a</pre><br />
Дайте следующие ответы:<br />
<pre> Create key usage extension:<br />
2 - Key encipherment<br />
9 - done<br />
n - not critical<br />
Create netscape cert type extension:<br />
1 - SSL Server<br />
9 - done<br />
n - not critical<br />
</pre><br />
Если вы хотите, вы можете создавать отдельные сертификаты для серверов HTTP и Directory.<br />
<br />
'''Экспорт сертификатов в правильные форматы.'''<br />
<br />
Импортируем полученный сертификат:<br />
<pre># /usr/bin/certutil -d ~/test_ca -A -i /tmp/replicacert.pem -n Replica-Cert -a -t ,,</pre><br />
Экспортируем в PKCS#12:<br />
<pre># /usr/bin/pk12util -o ~/test_ca/replicacert.p12 -n Replica-Cert -d ~/test_ca -k ~/test_ca/pwdfile.txt -w ~/test_ca/pwdfile.txt</pre><br />
'''Для domain-level 1'''<br />
<br />
<pre># ipa-replica-install --http-cert-file ~/test_ca/replicacert.p12 --dirsrv-cert-file ~/test_ca/replicacert.p12</pre><br />
<br />
== Установка FreeIPA клиента и подключение к серверу ==<br />
Установим необходимые пакеты:<br />
<pre># apt-get install freeipa-client libsss_sudo krb5-kinit bind-utils libbind zip</pre><br />
Зададим имя компьютера:<br />
<pre># hostnamectl set-hostname comp01.example.test</pre><br />
Добавим DNS сервер, для этого создадим файл {{path|/etc/net/ifaces/ens19/resolv.conf}} со следующим содержимым:<br />
<pre>nameserver 192.168.135.1</pre><br />
192.168.135.1 - IP-адрес нашего FreeIPA сервера.<br><br />
Укажем службе resolvconf использовать DNS FreeIPA и наш домен для поиска.<br><br />
Для этого в файл {{path|/etc/resolvconf.conf}} добавим/отредактируем следующие параметры:<br />
<pre>interface_order='lo lo[0-9]* lo.* ens19'<br />
search_domains=example.test</pre><br />
Где ens19 -интерфейс на котором доступен FreeIPA сервер, example.test - наш домен.<br><br />
Обновим DNS адреса:<br />
<pre># resolvconf -u</pre><br />
После этого в файле {{path|/etc/resolv.conf}} должны появится строки:<br />
<pre>search example.test<br />
nameserver 192.168.135.1</pre><br />
Запускаем скрипт настройки клиента:<br />
в пакетном режиме:<br />
# ipa-client-install -U -p admin -w 12345678<br />
или интерактивно:<br />
<pre># ipa-client-install</pre><br />
Если все настроено верно скрипт должен выдать такое сообщение:<br />
<pre>'''Discovery was successful!'''<br />
Client hostname: comp02.example.test<br />
Realm: EXAMPLE.TEST<br />
DNS Domain: example.test<br />
IPA Server: ipa.example.test<br />
BaseDN: dc=example,dc=test<br />
Continue to configure the system with these values? [no]:</pre><br />
Отвечаем {{cmd|yes}} вводим имя пользователя, имеющего право вводить машины в домен, и его пароль.<br><br />
<br />
Пример успешного ввода в домен:<br />
<source lang="text">Discovery was successful!<br />
Client hostname: ipa-client1.test1.alt<br />
Realm: TEST1.ALT<br />
DNS Domain: test1.alt<br />
IPA Server: ipa-server.test1.alt<br />
BaseDN: dc=test1,dc=alt<br />
Synchronizing time with KDC...<br />
Attempting to sync time using ntpdate. Will timeout after 15 seconds<br />
Successfully retrieved CA cert<br />
Subject: CN=Certificate Authority,O=TEST1.ALT<br />
Issuer: CN=Certificate Authority,O=TEST1.ALT<br />
Valid From: Wed Feb 15 15:17:45 2017 UTC<br />
Valid Until: Sun Feb 15 15:17:45 2037 UTC<br />
<br />
Enrolled in IPA realm TEST1.ALT<br />
Created /etc/ipa/default.conf<br />
Configured sudoers in /etc/nsswitch.conf<br />
Configured /etc/sssd/sssd.conf<br />
Configured passwd in /etc/nsswitch.conf<br />
Configured group in /etc/nsswitch.conf<br />
Configured gshadow in /etc/nsswitch.conf<br />
Configured services in /etc/nsswitch.conf<br />
Configured netgroup in /etc/nsswitch.conf<br />
Configured shadow in /etc/nsswitch.conf<br />
Configured /etc/nsswitch.conf<br />
Configured PAM system-auth<br />
Configured /etc/krb5.conf for IPA realm TEST1.ALT<br />
trying https://ipa-server.test1.alt/ipa/json<br />
Forwarding 'ping' to json server 'https://ipa-server.test1.alt/ipa/json'<br />
Forwarding 'ca_is_enabled' to json server 'https://ipa-server.test1.alt/ipa/json'<br />
Hostname (ipa-client1.test1.alt) does not have A/AAAA record.<br />
Failed to update DNS records.<br />
Missing A/AAAA record(s) for host ipa-client1.test1.alt: 10.10.10.206.<br />
Missing reverse record(s) for address(es): 10.10.10.206.<br />
Adding SSH public key from /etc/openssh/ssh_host_ecdsa_key.pub<br />
Adding SSH public key from /etc/openssh/ssh_host_ed25519_key.pub<br />
Adding SSH public key from /etc/openssh/ssh_host_dsa_key.pub<br />
Adding SSH public key from /etc/openssh/ssh_host_rsa_key.pub<br />
Forwarding 'host_mod' to json server 'https://ipa-server.test1.alt/ipa/json'<br />
Could not update DNS SSHFP records.<br />
SSSD enabled<br />
Configured /etc/openldap/ldap.conf<br />
NTP enabled<br />
Configured /etc/openssh/ssh_config<br />
Configured /etc/openssh/sshd_config<br />
Configuring test1.alt as NIS domain.<br />
Client configuration complete.</source><br />
<br />
{{Attention|Если при входе в домен возникает такая ошибка:<br />
<pre>Hostname (ipa-client1.test1.alt) does not have A/AAAA record.<br />
Failed to update DNS records.</pre><br />
Проверьте IP-адрес доменного DNS сервера в файле {{path|/etc/resolv.conf}}}}<br />
<br />
В случае возникновения ошибки, необходимо перед повторной установкой запустить процедуру удаления:<br />
# ipa-client-install -U --uninstall<br />
<br />
Для работы sudo-политик для доменных пользователей на клиентской машине необходимо разрешить доступ к sudo:<br />
<pre># control sudo public</pre><br />
=== Вход пользователя ===<br />
<br />
При первом входе пользователя будет запрошен текущий установленный администратором пароль и затем у пользователя запрашивается новый пароль и его подтверждение.<br />
<br />
{{Attention|Если машина до этого была в других доменах или есть проблемы со входом пользователей рекомендуется очистить кэш sssd:<br />
<pre># systemctl stop sssd<br />
# rm -f /var/lib/sss/db/*<br />
# rm -f /var/lib/sss/mc/*<br />
# systemctl start sssd</pre>}}<br />
<br />
== IPA Automount NFS ==<br />
Установим nfs-server: <br />
<pre> apt-get install nfs-server </pre><br />
<br />
Включим SECURE_NFS:<br />
<pre>echo 'SECURE_NFS=yes' >> /etc/sysconfig/nfs</pre><br />
<br />
Добавим сервис в автозапуск:<br />
<pre>systemctl enable --now nfs-server</pre><br />
Добавим список экспорта и применим изменения:<br />
<pre><br />
# mkdir -p /exports/test_share <br />
# echo '/exports/test_share client1.testbc.testbe(rw,no_subtree_check,sec=krb5p)' >> /etc/exports<br />
# exportfs -vra<br />
</pre><br />
На IPA сервере:<br />
<pre># kinit admin</pre><br />
Добавить ipa сервис где nfs.testbc.testbe наш nfs сервер:<br />
<pre># ipa service-add nfs/nfs.testbc.testbe</pre><br />
Добавляем в keytab:<br />
<pre># ipa-getkeytab -s freeipa.testbc.testbe -p nfs/nfs.testbc.testbe -k /etc/krb5.keytab</pre><br />
Проверим наличие:<br />
<pre># klist -k /etc/krb5.keytab<br />
Keytab name: FILE:/etc/krb5.keytab <br />
KVNO Principal <br />
---- ---------- <br />
2 host/nfs.testbc.testbe@TESTBC.TESTBE <br />
1 nfs/nfs.testbc.testbe@TESTBC.TESTBE</pre><br />
Перезапустим nfs сервер:<br />
<pre># systemctl restart nfs-server</pre><br />
Добавим правила автомонтирования:<br />
<pre><br />
# ipa automountmap-add default auto.test<br />
# ipa automountkey-add default --key "/-" --info auto.test auto.master<br />
# ipa automountkey-add default --key "/mnt/testshare" --info "-fstype=nfs4,rw,sec=krb5p,hard nfs.testbc.testbe:/exports/test_share" auto.test<br />
</pre><br />
Удалим пустую карту монтирования:<br />
<pre># ipa automountkey-del --key '/-' --info 'auto.direct' default auto.master</pre><br />
Настройка клиента: <br />
ipa-client-install<br />
Устанавливаем пакет freeipa-client-automount:<br />
<pre> # apt-get install freeipa-client-automount </pre><br />
Проверим доступность nfs:<br />
<pre># showmount -e nfs.testbc.testbe</pre><br />
Настроим автомонтирование:<br />
<pre># ipa-client-automount --location default</pre><br />
На IPA сервере:<br />
Создадим пользователя:<br />
<pre># ipa user-add ipatest --first ipatest --last ipatest</pre><br />
Предоставим пользователю права на запись:<br />
<pre># mkdir /exports/test_share/testdir <br />
# chown ipatest:ipatest /exports/test_share/testdir</pre><br />
Создадим домашнюю папку пользователя на nfs сервере:<br />
<pre># mkhomedir_helper ipatest<br />
# echo '/home client1.testbc.testbe(rw,no_subtree_check,sec=krb5p)' >> /etc/exports <br />
# exportfs -vra<br />
</pre><br />
Добавим правила автомонтирования:<br />
<pre>ipa automountmap-add default auto.home <br />
ipa automountkey-add default --key "/home" --info auto.home auto.master <br />
ipa automountkey-add default --key "*" --info "-fstype=nfs4,rw,sec=krb5p,hard nfs.testbc.testbe:/home/&" auto.home</pre><br />
Проверяем на клиенте:<br />
<pre>$ df -h</pre><br />
Для отладки используйте:<br />
<br />
NFS/autofs/sssd-autofs: <br />
<pre>systemctl stop autofs <br />
automount -fd -vvv</pre> <br />
krb5: <br />
<pre>sed -i '/^GSSD_OPTIONS=/{s/"$/ -vvv"/g}' /etc/sysconfig/nfs<br />
systemctl restart rpc-gssd</pre><br />
<br />
== Настройка репликации ==<br />
<br />
На втором контроллере домена установим необходимые пакеты:<br />
<pre># apt-get install freeipa-client freeipa-server-dns</pre><br />
<br />
Зададим имя сервера:<br />
<pre># hostnamectl set-hostname ipabackup.example.test</pre><br />
<br />
Теперь развернём и настроим клиента:<br />
<pre><br />
# ipa-client-install -d \<br />
--domain=example.test \<br />
--server=ipa.example.test \<br />
--realm=EXAMPLE.TEST \<br />
--principal=admin \<br />
--password=12345678 \<br />
--enable-dns-updates -U<br />
</pre><br />
<br />
После выполнения этой операции хост '''ipabackup.example.test''' должен появиться в веб-интерфейсе FreeIPA. Переходим к настройке репликации LDAP-каталога:<br />
<pre># ipa-replica-install</pre><br />
<br />
Добавляем в DNS второй NTP-сервер:<br />
<pre><br />
# kinit admin<br />
# ipa dnsrecord-add example.test _ntp._udp --srv-priority=0 --srv-weight=100 --srv-port=123 --srv-target=ipabackup.example.test.<br />
</pre><br />
<br />
Настроим репликацию DNS-зон:<br />
<pre># ipa-dns-install</pre><br />
<br />
Наконец, настроим репликацию CA:<br />
<pre># ipa-ca-install</pre><br />
<br />
После настройки и репликации контроллеров посмотреть топологию можно в веб-интерфейсе FreeIPA (IPA Server -> Topology -> Topology Graph).<br />
<br />
<br />
== Настройка доверительных отношений с AD ==<br />
FreeIPA использует Samba для интеграции в Active Directory. Для работы Samba необходим работающий стек IPv6.<br><br />
Начальные данные:<br />
* IP адрес IPA сервера: '''192.168.135.130'''<br />
* Имя IPA сервера: '''dcf'''<br />
* Имя IPA домена: '''domf.testf'''<br />
* NetBIOS имя IPA домена: '''DOMF'''<br />
* IP адрес AD DC: '''192.168.135.150'''<br />
* Имя AD DC: '''dcc'''<br />
* Имя AD домена: '''domc.testc'''<br />
* NetBIOS имя AD домена: '''DOMC'''<br />
<br />
Установим необходимые пакеты:<br />
<pre># apt-get install freeipa-server-trust-ad python-module-sss-murmur samba-winbind</pre><br />
=== Предварительная настройка IPA сервера ===<br />
'''Настроим IPA''' для работы с доверительными отношениями:<br />
<pre># ipa-adtrust-install</pre><br />
Скрипт спросит необходимо ли конфигурировать {{path|slapi-nis}} плагин для поддержки работы старых клиентов (SSSD < 1.9) с пользователем из доверенного домена:<br />
<pre>Enable trusted domains support in slapi-nis? [no]:</pre> <br />
На IPA сервере добавлен хотя бы один пользователь (администратор сервера), поэтому скрипт предложит сгенерировать SID для всех существующих пользователей и груп:<br />
<pre>Do you want to run the ipa-sidgen task? [no]:</pre><br />
Дата и время на серверах должны совпадать.<pre><br />
IPA сервер в своей работе использует следующие порты:<br />
<pre>TCP ports: 80, 88, 443, 389, 636, 88, 464, 53, 135, 138, 139, 445, 1024-1300<br />
UDP ports: 88, 464, 53, 123, 138, 139, 389, 445</pre><br />
Они должны быть открыты и доступны.<br><br />
'''Настроим Samba:'''<br><br />
<pre># net conf setparm global 'dedicated keytab file' /etc/samba/samba.keytab<br />
# systemctl restart ipa</pre><br />
Проверим проходит ли Samba аутентификацию Kerberos со стороны IPA сервера:<br />
<pre># kinit admin<br />
# smbclient -L dcf.domf.testf -k<br />
lp_load_ex: changing to config backend registry<br />
Domain=[DOMF] OS=[Windows 6.1] Server=[Samba 4.5.5]<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (Samba 4.5.5)<br />
Domain=[DOMF] OS=[Windows 6.1] Server=[Samba 4.5.5]<br />
<br />
Server Comment<br />
--------- -------<br />
<br />
Workgroup Master<br />
--------- -------</pre><br />
'''Настроим DNS''' на обоих серверах, чтобы они знали друг о друге:<br><br />
На AD сервере создадим сервер условной пересылки для зоны IPA домена:<br />
<pre>C:\> dnscmd 127.0.0.1 /ZoneAdd domf.testf /Forwarder 192.168.135.130</pre><br />
На IPA сервере так же добавим зону AD домена:<br />
<pre># ipa dnsforwardzone-add domc.testc --forwarder=192.168.135.150 --forward-policy=only</pre><br />
<br />
=== Проверка конфигурации DNS ===<br />
'''На AD сервере:'''<br><br />
Проверим наличие записей для работы сервисов IPA на DNS-сервере AD.<br><br />
1. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:<br />
<pre>C:\>nslookup.exe<br />
> set type=SRV<br />
<br />
> _kerberos._udp.domf.testf.<br />
_kerberos._udp.domf.testf. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 88<br />
svr hostname = dcf.domf.testf.<br />
<br />
> _ldap._tcp.domf.testf.<br />
_ldap._tcp.ipa.example.com SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 389<br />
svr hostname = dcf.domf.testf.</pre><br />
<br />
2. Запись отвечающая за имя Kerberos realm IPA домена:<br />
<pre>C:\>nslookup.exe<br />
> set type=TXT<br />
> _kerberos.domf.testf.<br />
_kerberos.domf.testf. text =<br />
<br />
"DOMF.TESTF"</pre><br />
<br />
3. После выполнения команды {{path|ipa-adtrust-install}} должны появится записи отвечающие за работу сервисов MS DC Kerberos через UDP и LDAP через TCP:<br />
<pre>C:\>nslookup.exe<br />
> set type=SRV<br />
> _kerberos._udp.dc._msdcs.domf.testf.<br />
_kerberos._udp.dc._msdcs.domf.testf. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 88<br />
svr hostname = dcf.domf.testf.<br />
> _ldap._tcp.dc._msdcs.domf.testf.<br />
_ldap._tcp.dc._msdcs.domf.testf. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 389<br />
svr hostname = dcf.domf.testf.</pre><br />
Далее проверим наличие записей для работы сервисов AD на DNS-сервере AD.<br><br />
4. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:<br />
<pre>C:\>nslookup.exe<br />
> set type=SRV<br />
> _kerberos._udp.dc._msdcs.domc.testc.<br />
_kerberos._udp.dc._msdcs.domc.testc. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 88<br />
svr hostname = dcc.domc.testc.<br />
> _ldap._tcp.dc._msdcs.domc.testc.<br />
_ldap._tcp.dc._msdcs.domc.testc. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 389<br />
svr hostname = dcc.domc.testc.</pre><br />
<br />
'''На IPA сервере:'''<br><br />
Проверим наличие записей для работы сервисов IPA на DNS-сервере IPA.<br><br />
1. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:<br />
<pre># dig +short -t SRV _kerberos._udp.domf.testf.<br />
0 100 88 dcf.domf.testf.<br />
<br />
# dig +short -t SRV _ldap._tcp.domf.testf.<br />
0 100 389 dcf.domf.testf.</pre><br />
2. Запись отвечающая за имя Kerberos realm IPA домена:<br />
<pre>dig +short -t TXT _kerberos.domf.testf.<br />
"DOMF.TESTF"</pre><br />
3. После выполнения команды {{path|ipa-adtrust-install}} должны появится записи отвечающие за работу сервисов MS DC Kerberos через UDP и LDAP через TCP:<br />
<pre># dig +short -t SRV _kerberos._udp.dc._msdcs.domf.testf.<br />
0 100 88 dcf.domf.testf.<br />
<br />
# dig +short -t SRV _ldap._tcp.dc._msdcs.domf.testf.<br />
0 100 389 dcf.domf.testf.</pre><br />
Далее проверим наличие записей для работы сервисов AD на DNS-сервере IPA.<br />
4. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:<br />
<pre># dig +short -t SRV _kerberos._udp.dc._msdcs.domc.testc.<br />
0 100 88 dcc.domc.testc.<br />
<br />
# dig +short -t SRV _ldap._tcp.dc._msdcs.domc.testc.<br />
0 100 389 dcc.domc.testc.</pre><br />
{{Attention|Если запись {{cmd|_kerberos._udp.dc._msdcs.domc.testc.}} не доступна проверьте {{cmd|_kerberos._tcp.dc._msdcs.domc.testc.}}}}<br />
<br />
=== Настройка доверия ===<br />
Добавление двунаправленных доверительных отношений леса (Forest Trust) с AD:<br><br />
Имя доменного администратора Windows должно быть на латинице, кириллицу (Администратор) IPA не принимает.<br><br />
<pre># kinit admin<br />
# ipa trust-add --type=ad domc.testc --admin Administrator --password --two-way=true<br />
Active Directory domain administrator's password: <br />
---------------------------------------------------<br />
Added Active Directory trust for realm "domc.testc"<br />
---------------------------------------------------<br />
Realm name: domc.testc<br />
Domain NetBIOS name: DOMC<br />
Domain Security Identifier: S-1-5-21-3611360735-1365415015-3217858865<br />
SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13,<br />
S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18<br />
SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13,<br />
S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18<br />
Trust direction: Two-way trust<br />
Trust type: Active Directory domain<br />
Trust status: Established and verified<br />
</pre><br />
Необходимо ввести пароль Administrator AD.<br><br />
Далее необходимо запросить сервер AD о его доверенных доменах:<br />
<pre># ipa trust-fetch-domains domc.testc<br />
--------------------------------------------<br />
List of trust domains successfully refreshed<br />
--------------------------------------------<br />
Realm name: domd.domc.testc<br />
Domain NetBIOS name: DOMD<br />
Domain Security Identifier: S-1-5-21-2419724241-1549151283-3268040000<br />
------------------------------<br />
Количество вернутых значений 1<br />
------------------------------<br />
</pre><br />
При этом IPA создаст нужные id-диапазоны для доверенных доменов.<br><br />
Если мы добавим в лес еще один домен DOME.TESTE, то необходимо настроить DNS на обоих серверах, чтобы они видели друг друга.<br><br />
И выполнить команду еще раз,чтобы IPA сервер узнал о нем:<br />
<pre># ipa trust-fetch-domains domc.testc<br />
--------------------------------------------<br />
List of trust domains successfully refreshed<br />
--------------------------------------------<br />
Realm name: dome.teste<br />
Domain NetBIOS name: DOME<br />
Domain Security Identifier: S-1-5-21-3615012966-1241218098-4147673574<br />
------------------------------<br />
Количество вернутых значений 1<br />
------------------------------</pre><br />
Найти все доверенные домены можно и с помощью web-интерфейса. Для Перейдем в IPA Server -> Trusts и выберем нужный нам домен:<br><br />
[[Файл:IPATrusts.png|600px]]<br><br />
Нажмём кнопку Fetch domains это обновит список доверенных доменов:<br><br />
[[Файл:IPATrustFetch.png|600px]]<br><br />
<br />
Для того чтобы увидеть список всех доверенных доменов из леса используйте следующую команду:<br />
<pre># ipa trustdomain-find domc.testc<br />
Domain name: domc.testc<br />
Domain NetBIOS name: DOMC<br />
Domain Security Identifier: S-1-5-21-3611360735-1365415015-3217858865<br />
Domain enabled: True<br />
<br />
Domain name: domd.domc.testc<br />
Domain NetBIOS name: DOMD<br />
Domain Security Identifier: S-1-5-21-2419724241-1549151283-3268040000<br />
Domain enabled: True<br />
<br />
Domain name: dome.teste<br />
Domain NetBIOS name: DOME<br />
Domain Security Identifier: S-1-5-21-3615012966-1241218098-4147673574<br />
Domain enabled: True<br />
------------------------------<br />
Количество вернутых значений 3<br />
------------------------------<br />
</pre><br />
<br />
=== Проверка конфигурации Kerberos ===<br />
1. Запросим ticket для IPA пользователя:<br />
<pre># kinit admin</pre><br />
2. Запросим service ticket для сервиса из IPA домена:<br />
<pre># kvno -S host dcf.domf.testf<br />
host/dcf.domf.testf@DOMF.TESTF: kvno = 2</pre><br />
3. Запросим service ticket сервиса из AD домена:<br />
<pre># kvno -S cifs dcc.domc.testc<br />
cifs/dcc.domc.testc@: kvno = 3</pre><br />
Если запрос service ticket для сервиса из AD домена прошел успешно, то у нас должен появиться междоменный ticket-granting ticket, его имя krbtgt/DOMC.TESTC@DOMF.TESTF:<br />
<pre># klist<br />
Ticket cache: KEYRING:persistent:0:0<br />
Default principal: admin@DOMF.TESTF<br />
<br />
Valid starting Expires Service principal<br />
14.02.2017 15:43:46 15.02.2017 01:43:46 cifs/dcc.domc.testc@DOMC.TESTC<br />
14.02.2017 15:43:46 15.02.2017 01:43:46 cifs/dcc.domc.testc@<br />
14.02.2017 15:43:46 15.02.2017 15:42:48 krbtgt/DOMC.TESTC@DOMF.TESTF<br />
14.02.2017 15:43:25 15.02.2017 15:42:48 host/dcf.domf.testf@DOMF.TESTF<br />
14.02.2017 15:42:53 15.02.2017 15:42:48 krbtgt/DOMF.TESTF@DOMF.TESTF</pre><br />
=== Проверка пользователей доверенного домена ===<br />
Проверим имеет ли доступ к пользователям из доверенного домена рабочие станции IPA.<br><br />
Для этого на рабочей станции IPA выполните команду:<br />
<pre># getent passwd u01domc@domc<br />
u01domc@domc.testc:*:328601108:328601108:u01domc:/home/domc.testc/u01domc:</pre><br />
Где u01domc это пользователь из AD домена. Обратите внимание, что не указана оболочка входа. Назначить оболочку входа для пользователей из доверенного домена можно добавив на сервере IPA в файл {{path|/etc/sssd/sssd.conf}} следующую строчку:<br />
<pre>[domain/domf.testf]<br />
...<br />
default_shell = /bin/bash<br />
...</pre><br />
Вывод команды должен стать таким:<br />
<pre># getent passwd u01domc@domc<br />
u01domc@domc.testc:*:328601108:328601108:u01domc:/home/domc.testc/u01domc:/bin/bash</pre><br />
{{Attention|Для корректной работы сервера IPA с пользователями доверенного домена AD необходимо обеспечить доступ сервиса sssd к /etc/krb5.keytab см. [https://bugzilla.altlinux.org/33115 bug 33115]}}<br />
{{Attention|Для входа AD пользователя в ALT рабочую станцию из IPA вводим имя пользователя в формате '''DOMC'''\username или '''DOMC.TESTC'''\username или username@'''domc''' username@'''domc.testc'''}}<br />
{{Attention|Для входа IPA пользователя в windows рабочую станцию из AD вводим имя пользователя в формате '''DOMF.TESTF'''\username}}<br />
<br />
== Создание аккаунта для доступа к LDAP ==<br />
Некоторые сервисы использующие LDAP требуют предварительно настроенной учетной записи. Использование обычной учетной записи пользователя предпочтительней, но не всегда это целесообразно делать. Можно сделать системную учетную запись следующим образом на сервере FreeIPA используя пароль Directory :<br />
<pre># ldapmodify -x -D 'cn=Directory Manager' -W<br />
dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=test<br />
changetype: add<br />
objectclass: account<br />
objectclass: simplesecurityobject<br />
uid: ldapaccount<br />
userPassword: secret123<br />
passwordExpirationTime: 20380119031407Z<br />
nsIdleTimeout: 0<br />
<blank line><br />
^D</pre><br />
Замените пароль на более сложный. Параметр {{path|passwordExpirationTime: 20380119031407Z}} означает, что срок действия пароля неограничен<br />
Причина использования такой учетной записи, а не создание обычной учетной записи пользователя IPA, и использование этой системы заключается в том, что системная учетная запись существует только для привязки к LDAP. Это не настоящий пользователь POSIX, он не может войти в систему и ему не принадлежат файлы. У этого пользователя нет особых прав и он не может ничего записывать какие-либо данные на сервер LDAP FreeIPA, только права на чтение.<br />
<br />
== Добавление расширенных полей в ldap ==<br />
<br />
Если необходимо добавить поля в вашу схему ldap, то реализация этого возможна через команду ldapmodify и добавление своих плагинов для отображения этих полей в WebUi.<br><br />
Обычно файлы модификации схемы являются типом ''.ldif''.<br><br />
Пример:<br><br />
Содержание файла addExtField.ldif <br><br />
<pre>dn: cn=schema<br />
changetype: modify<br />
add: attributeTypes<br />
attributeTypes: ( 2.25.28639311321113238241701611583088740684.14.2.2 NAME 'favoriteColorName' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Extending FreeIPA' )<br />
<br />
dn: cn=schema<br />
changetype: modify<br />
add: attributeTypes<br />
attributeTypes: ( 2.25.28639311321113238241701611583088740684.14.2.3 NAME 'redirects' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Extending FreeIPA')<br />
<br />
dn: cn=schema<br />
changetype: modify<br />
add: attributeTypes<br />
attributeTypes: ( 2.25.28639311321113238241701611583088740684.14.2.4 NAME 'attbool' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 X-ORIGIN 'Extending FreeIPA')<br />
<br />
dn: cn=schema<br />
changetype: modify<br />
add: objectclasses<br />
objectclasses: ( 2.25.28639311321113238241701611583088740684.14.2.1 NAME 'customPerson' SUP person STRUCTURAL MAY ( favoriteColorName $ attbool $ redirects ) X-ORIGIN 'Extending FreeIPA' )</pre><br />
<br />
Детальное пояснение для блока:<br><br />
<br />
<pre>dn: cn=schema<br />
changetype: modify<br />
add: attributeTypes<br />
attributeTypes: ( 2.25.28639311321113238241701611583088740684.14.2.2<br />
NAME 'favoriteColorName'<br />
EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch<br />
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15<br />
X-ORIGIN 'Extending FreeIPA' )</pre><br />
<br />
'''dn''' - dn, в котором будет проводиться изменение. Добавление/удаление классов и т.д.<br><br />
<br />
'''changetype''' - атрибут, отвечающий за тип изменений, которые будут происходить.(add, delete, modify, modrdn)<br><br />
<br />
'''add: attributeTypes''' - добавление атрибута, далее идёт описание атрибута.<br><br />
'''2.25.28639311321113238241701611583088740684.14.2.2''' - уникальный идентификатор атрибута. Можно написать любой.<br><br />
<br />
'''NAME 'favoriteColorName' ''' - По другому можно назвать - primary name. Название атрибута.<br><br />
<br />
'''EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch''' - эти атрибуты заданы для проверки соответствия содержания атрибута правилам caseIgnoreMatch <br><br />
<br />
'''SYNTAX 1.3.6.1.4.1.1466.115.121.1.15''' - OID типа данных <br><br />
<br />
Все изменения в схеме производятся от пользователя - Directory manager.<br><br />
<br />
Изменение схемы ldap:<br />
<br />
<pre>$ ldapmodify -D "cn=Directory Manager" -W -f addExtField.ldif</pre><br />
<br />
После изменения схемы, путем добавления нового objectclass, нужно чтобы эти поля еще можно было редактировать в web-интерфейсе. Для этого необходимо сделать палагин. В примере использовано 3 атрибута, для них сделаем 3 отдельных плагина:<br />
<br />
1. Создание папки:<br />
<pre>mkdir -p /usr/share/ipa/ui/js/plugins/favoriteColorName</pre><br />
<br />
2. Создание самого плагина:<br />
<pre>mcedit /usr/share/ipa/ui/js/plugins/favoriteColorName/favoriteColorName.js</pre><br />
Тело плагина:<br />
<br />
<pre>define(['freeipa/phases','freeipa/user'],<br />
function(phases, user_mod) {<br />
// helper function<br />
function get_item(array, attr, value) {<br />
for (var i=0,l=array.length; i<l; i++) {<br />
if (array[i][attr] === value) return array[i];<br />
}<br />
return null;<br />
}<br />
<br />
var color_plugin = {};<br />
<br />
color_plugin.add_favorite_color = function() {<br />
var facet = get_item(user_mod.entity_spec.facets, '$type', 'details');<br />
var section = get_item(facet.sections, 'name', 'identity');<br />
section.fields.push({<br />
name: 'favoritecolorname',<br />
label: 'Цвет'<br />
});<br />
return true;<br />
};<br />
<br />
phases.on('customization', color_plugin.add_favorite_color);<br />
<br />
return color_plugin;<br />
});</pre><br />
<br />
В схеме бы добавлен атрибут типа boolean, для него можно сделать радиокнопки:<br><br />
<br />
<pre>define(['freeipa/phases','freeipa/user'],<br />
function(phases, user_mod) {<br />
// helper function<br />
function get_item(array, attr, value) {<br />
for (var i=0,l=array.length; i<l; i++) {<br />
if (array[i][attr] === value) return array[i];<br />
}<br />
return null;<br />
}<br />
<br />
var attrbool_plugin = {};<br />
<br />
attrbool_plugin.add_bool = function() {<br />
var facet = get_item(user_mod.entity_spec.facets, '$type', 'details');<br />
var section = get_item(facet.sections, 'name', 'identity');<br />
section.fields.push(<br />
{<br />
$type: 'radio',.<br />
options:[{label:'True',value:'TRUE'},{label:'False',value:'FALSE'}],<br />
label:'Blood type',<br />
name: 'attbool'}<br />
);<br />
return true;<br />
};<br />
<br />
phases.on('customization', attrbool_plugin.add_bool);<br />
<br />
return attrbool_plugin;<br />
});<br />
<br />
</pre><br />
<br />
После необходимо добавить новое поле в "Default user objectclasses" (находится IPA Server -> Configuration) созданный objectclass (customPerson) и появятся поля в web-интерфейсе. Для того чтобы пользователь мог их редактировать, необходимо изменить привилегии в группе ipausers. <br><br />
== Использование haproxy для высокой доступности FreeIPA ==<br />
'''Требуется:''' <br />
<br />
Сервер №1 c freeipa: dc1.testbc.testgl<br />
<br />
Сервер №2 с репликой freeipa: dc2.testbc.testgl<br />
<br />
Сервер №3 с haproxy: haproxy.testbc.testgl<br />
<br />
[[Файл:Схема.png]]<br />
<br />
'''Настройка:'''<br />
<br />
Инструкция для настройки сервера №1 и №2: [[FreeIPA]]<br />
<br />
На сервере №3: <br />
<br />
Установить<br />
<pre># apt-get install haproxy</pre><br />
Сохранить оригинальный конфигурационный файл:<br />
<br />
<pre>cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxyBAK.cfg</pre><br />
Изменить конфигурацию:<br />
<pre><br />
cat << EOF > /etc/haproxy/haproxy.cfg<br />
global<br />
log 127.0.0.1 local2<br />
<br />
chroot /var/lib/haproxy<br />
pidfile /var/run/haproxy.pid<br />
maxconn 4000<br />
user _haproxy<br />
group _haproxy<br />
daemon<br />
<br />
stats socket /var/lib/haproxy/stats<br />
# LDAP and LDAP/STARTTLS<br />
frontend ldap_service_front<br />
mode tcp<br />
bind *:389<br />
description LDAP Service<br />
option socket-stats<br />
option tcpka<br />
timeout client 3600s<br />
default_backend ldap_service_back<br />
<br />
backend ldap_service_back<br />
server ldap-1 dc1.testbc.testgl:389 check fall 1 rise 3 inter 2s weight 150<br />
server ldap-2 dc2.testbc.testgl:389 check fall 1 rise 3 inter 2s weight 100<br />
mode tcp<br />
balance roundrobin<br />
option tcpka<br />
option ldap-check<br />
timeout server 1800s<br />
timeout connect 1s<br />
frontend ldaps_service_front<br />
mode tcp<br />
bind *:636<br />
description LDAP Service<br />
option socket-stats<br />
option tcpka<br />
timeout client 3600s<br />
default_backend ldap_service_back<br />
<br />
backend ldaps_service_back<br />
server ldap-1 dc1.testbc.testgl:636 check fall 1 rise 3 inter 2s weight 150<br />
server ldap-2 dc1.testbc.testgl:636 check fall 1 rise 3 inter 2s weight 150<br />
mode tcp<br />
balance roundrobin<br />
option tcpka<br />
option ssl-hello-chk<br />
timeout server 1800s<br />
EOF<br />
</pre><br />
Запустить сервис haproxy:<br />
<pre>#systemctl start haproxy</pre><br />
Проверить работу можно с помощью ldapsearch сделав один из серверов недоступным:<br />
<pre>ldapsearch -x -h haproxy.testbc.testgl -b dc=testbc,dc=testgl uid=admin</pre><br />
Результат: ldap всегда доступен.<br />
<br />
== Automember rebuild membership ==<br />
<br />
Пользовательские или хост группы можно легко перестроить на основе новых или обновленных правил automember. Команда automember rebuild только добавляет новые отношения для групп, она не удаляет те, которые не соответствуют правилам automember. Недавно добавленная команда вызовет задачу в rebuild automember, создав запись LDAP в cn = automember rebuild membership, cn = tasks, cn = config. Плагин automember в настоящее время проверяет операции Add(добавления), чтобы увидеть, есть ли запись соответствует одному из определенных правил automember. Существующие записи не проверяются когда они изменяются. Чтобы применить правило для всех записей, надо добавить задачу к плагину automember. Создатель задачи обеспечит фильтр поиска и базу. Все совпадающие записи будут проверяться в соответствии с определенными правилами automember, чтобы увидеть если они должны быть добавлены в какие-либо группы. Это позволяет добавить запуск атрибуты(значения) после того, как запись была первоначально добавлена, а затем вызвать задачу(выполнить) обновления automember. Ipa automember-rebuild может использоваться для восстановления членства для всех объектов определенного типа:<br />
<pre><br />
$ ipa automember-rebuild --type=group<br />
$ ipa automember-rebuild --type=hostgroup<br />
</pre><br />
Он также может использоваться для восстановления членства для указанных записей:<br />
<pre><br />
$ ipa automember-rebuild --hosts=HOSTNAME1 --hosts=HOSTNAME2<br />
$ ipa automember-rebuild --users=LOGIN1 --users=LOGIN2<br />
</pre><br />
Добавление новой группы хостов:<br />
<pre><br />
$ ipa hostgroup-add --desc="Web Servers" webservers<br />
</pre><br />
Добавить новый хост:<br />
<pre><br />
$ ipa host-add web1.example.com --force<br />
</pre><br />
Добавить automember rule:<br />
<pre><br />
$ ipa automember-add --type=hostgroup webservers<br />
$ ipa automember-add-condition --key=fqdn --type=hostgroup --inclusive-regex=^web[1-9]+\.example\.com webservers<br />
</pre><br />
Функция automember теперь работает для новых добавленных записей. Если мы добавим новый хост, он будет автоматически помещен в соответствующую группу хостов:<br />
<pre><br />
$ ipa host-add web2.example.com --force<br />
$ ipa hostgroup-show webservers<br />
Host-group: webservers<br />
Description: Web Servers<br />
Member hosts: web2.example.com<br />
</pre><br />
Однако старая запись хоста для web1.example.com по-прежнему не является членом или хост-группой веб-серверов. Введя новые команды automember-rebuild, мы сделаем это возможным:<br />
<pre> <br />
$ ipa automember-rebuild --type=hostgroup<br />
or<br />
$ ipa automember-rebuild --hosts=web1.example.com<br />
</pre><br />
Хост добавится в новую группу:<br />
<pre><br />
$ ipa hostgroup-show webservers<br />
Host-group: webservers<br />
Description: Web Servers<br />
Member hosts: web2.example.com, web1.example.com<br />
</pre><br />
Тоже самое можно сделать в web-интерфейсе.<br />
<br />
== Дополнительные материалы ==<br />
* [https://habrahabr.ru/company/pixonic/blog/325546/ Настройка репликации во FreeIPA 4.4 с domain level 1] — Блог Pixonic на Habrahabr<br />
* [Система централизованного управления авторизацией пользователей на FreeIPA в Docker Система централизованного управления авторизацией пользователей на FreeIPA в Docker] — frol, Habrahabr<br />
<br />
[[Категория:Корпоративная инфраструктура]]<br />
[[Категория:HOWTO]]<br />
<br />
{{Category navigation|title=Корпоративная инфраструктура|category=Корпоративная инфраструктура|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=FreeIPA&diff=48568FreeIPA2020-06-05T11:56:10Z<p>AntonFarygin: /* Настройка IPA CA-less репликации */</p>
<hr />
<div>[[Файл:Freeipa-logo-small.png|frameless|right]]<br />
FreeIPA - это комплексное решение по управлению безопасностью Linux-систем, 389 Directory Server, MIT Kerberos, NTP, DNS, Dogtag. Оно состоит из веб-интерфейса и интерфейса командной строки.<br><br />
FreeIPA является интегрированной системой проверки подлинности и авторизации в сетевой среде Linux, FreeIPA сервер обеспечивает централизованную проверку подлинности, авторизацию и контроль за аккаунтами пользователей сохраняя сведения о пользователе, группах, узлах и других объектах необходимых для обеспечения сетевой безопасности.<br />
<br />
[https://www.freeipa.org/ Сайт проекта], [https://ipa.demo1.freeipa.org/ipa/ui/ демонстрация интерфейса].<br />
<br />
== Установка сервера FreeIPA ==<br />
Устанавливать будем со встроенным DNS сервером и доменом EXAMPLE.TEST в локальной сети 192.168.135.0/24.<br><br />
Для начала отключим ahttpd, работающий на порту 8080, во избежание конфликтов с разворачиваемым tomcat и отключим HTTPS в Apache2:<br />
# service ahttpd stop<br />
# a2dissite 000-default_https<br />
# a2disport https<br />
# service httpd2 condreload<br />
<br />
Установим необходимые пакеты:<br />
<pre># apt-get install freeipa-server freeipa-server-dns</pre><br />
Зададим имя сервера:<br />
<pre># hostnamectl set-hostname ipa.example.test</pre><br />
<br />
Для ускорения установки можно установить демон энтропии haveged:<br />
<pre> # apt-get install haveged<br />
# systemctl enable haveged<br />
# systemctl start haveged </pre><br />
<br />
Запускаем скрипт настройки сервера:<br />
<br />
В пакетном режиме: <br />
# ipa-server-install -U --hostname=$(hostname) -r EXAMPLE.TEST -n example.test -p 12345678 -a 12345678 --setup-dns --no-forwarders --no-reverse<br />
или интерактивно:<br />
<pre># ipa-server-install</pre><br />
<br />
{{Attention|Пароли должны быть не менее 8 символов}}<br />
<br />
Обратите внимание на ответы на вопросы, не совпадающие с предложенными:<br />
Do you want to configure integrated DNS (BIND)? [no]: yes<br />
<br />
остальные вопросы выбираем по умолчанию (можно просто нажать Enter). Так же при установке попросят ввести пароль администратора системы и пароль администратора каталогов.<br><br />
<br />
Для возможности управлять FreeIPA сервером из командной строки необходимо получить билет Kerberos:<br />
<pre># kinit admin</pre><br />
Добавим в DNS запись о нашем сервере времени:<br />
<pre># ipa dnsrecord-add example.test _ntp._udp --srv-priority=0 --srv-weight=100 --srv-port=123 --srv-target=ipa.example.test.</pre><br />
<br />
Проверить работу ntp сервера можно командой:<br />
<pre># ntpdate -q localhost<br />
server 127.0.0.1, stratum 3, offset 0.000018, delay 0.02568<br />
27 Apr 10:27:00 ntpdate[3491]: adjust time server 127.0.0.1 offset 0.000018 sec</pre><br />
<br />
Также доступен веб-интерфейс по адресу: <br />
<pre>https://ipa.example.test/ipa/ui/</pre><br />
<br />
{{Note|Если выдаёт <pre>[error] CalledProcessError: Command '/sbin/systemctl restart httpd2.service' returned non-zero exit status 1</pre><br />
Выполните <br />
# systemctl restart httpd2<br />
Отмените установку: <br />
# ipa-server-install -U --uninstall<br />
и повторите снова.}}<br />
<br />
== Установка сервера FreeIPA в режиме CA-less ==<br />
Установим необходимые пакеты:<br />
<pre># apt-get install freeipa-server freeipa-server-dns</pre><br />
Зададим имя сервера:<br />
<pre># hostnamectl set-hostname ipa.example.test</pre><br />
Подготовим сертификаты для сервера FreeIPA:<br />
<pre># mkdir ~/test_ca</pre><br />
Создадим файл pwdfiles.txt с паролем, например 12345678:<br />
<pre># echo 12345678 > ~/test_ca/pwdfile.txt</pre><br />
Создадим базу данных NSS:<br />
<pre>/usr/bin/certutil -d ~/test_ca -N -f ~/test_ca/pwdfile.txt</pre><br />
Создадим noise файл с рандомом:<br />
<pre># head -c20 /dev/random > ~/test_ca/noise.txt</pre><br />
Экспортируем переменную:<br />
<pre># export CERT_SERIAL=1</pre><br />
Создаем CA сертификат:<br />
<pre># /usr/bin/certutil -d ~/test_ca -S -n "CA" -s "CN=Certificate Authority" -x -t CT,,C -1 -2 -5 -m $CERT_SERIAL -v 120 -z ~/test_ca/noise.txt -f ~/test_ca/pwdfile.txt</pre><br />
Дайте следующие ответы:<br />
<pre> Create key usage extension:<br />
0 - Digital Signature<br />
1 - Non-repudiation<br />
5 - Cert signing key<br />
9 - done<br />
Is this a critical extension [y/N]? y<br />
Create basic constraint extension<br />
Is this a CA certificate [y/N]? y<br />
Enter the path length constraint, enter to skip [<0 for unlimited path]<br />
0<br />
Is this a critical extension [y/N]? y<br />
Extensions:<br />
5 - SSL<br />
6 - S/MIME<br />
7 - Object Signing CA<br />
9 - done<br />
Is this a critical extension [y/N]? n </pre><br />
Создадим запрос сертификата:<br />
<pre># head -c20 /dev/random > ~/test_ca/noise.txt<br />
# /usr/bin/certutil -d ~/test_ca -R -s CN=$HOSTNAME,O=IPA -o /tmp/servercert.req -k rsa -g 2048 -z ~/test_ca/noise.txt -f ~/test_ca/pwdfile.txt -a</pre><br />
Подпишите запрос о выдаче сертификата сервера:<br />
<pre># export CERT_SERIAL=$(($CERT_SERIAL + 1))<br />
# /usr/bin/certutil -d ~/test_ca -C -c "CA" -i /tmp/servercert.req -o /tmp/servercert.pem -m $CERT_SERIAL -v 120 -f ~/test_ca/pwdfile.txt -1 -5 -a</pre><br />
Дайте следующие ответы:<br />
<pre> Create key usage extension:<br />
2 - Key encipherment<br />
9 - done<br />
n - not critical<br />
Create netscape cert type extension:<br />
1 - SSL Server<br />
9 - done<br />
n - not critical</pre><br />
Если вы хотите, вы можете создавать отдельные сертификаты для серверов HTTP и Directory.<br />
<br />
'''Экспорт сертификатов в правильные форматы.'''<br />
Импортируем полученный сертификат:<br />
<pre># /usr/bin/certutil -d ~/test_ca -A -i /tmp/servercert.pem -n Server-Cert -a -t ,,</pre><br />
Экспортируем в PKCS#12:<br />
<pre># /usr/bin/pk12util -o ~/test_ca/servercert.p12 -n Server-Cert -d ~/test_ca -k ~/test_ca/pwdfile.txt -w ~/test_ca/pwdfile.txt</pre><br />
Экспортируйте сертификат CA в формате PEM:<br />
<pre># /usr/bin/certutil -d ~/test_ca -L -n "CA" -a > ~/test_ca/cacert.pem</pre><br />
Теперь установим CA-less IPA:<br />
<pre># export PWD=$(cat ~/test_ca/pwdfile.txt)<br />
# ipa-server-install --http_pkcs ~/test_ca/servercert.p12 --dirsrv_pkcs ~/test_ca/servercert.p12 --http_pin $PWD --dirsrv_pin $PWD --root-ca-file ~/test_ca/cacert.pem</pre><br />
<br />
'''Вы также можете указать при установке опции --pkinit-cert-file=Файл, содержащий сертификат SSL Kerberos KDC и закрытый ключ и --pkinit-pin=Пароль от закрытого ключа Kerberos KDC.'''<br />
<br />
После установки выполните:<br />
<pre>kinit admin</pre><br />
И после убедитесь что команды: <br />
<pre>ipa cert-find<br />
ipa cert-show 1</pre><br />
Не срабатывают и выводят ошибки.<br />
<br />
== Настройка IPA CA-less репликации ==<br />
{{Attention|Перед настройкой репликации необходимо выполнить установку клиента}}<br />
CA-Less конфигурация требуется в тех случаях, когда у вас по какой-то причине нет возможности развернуть на FreeIPA сервис CA certmonger. Например, это на данный момент не возможно сделать в некоторых сертифицированных конфигурациях. <br />
Если у вас не сертифицированный дистрибутив ALT, то пропустите пункт по настройке CA-Less репликации.<br />
<br />
Чтобы установить реплику, сначала создайте сертификаты для новой машины: создадим запрос сертификата и подпишем запрос о выдаче сертификата сервера и экспортируем сертификаты в правильные форматы, на этот раз задав $HOSTNAME имя хоста будущей реплики. Используйте Replica-Cert вместо Server-Cert и ~/test_ca/replicacert.p12 вместо ~/test_ca/servercert.p12:<br />
Создадим запрос сертификата для реплики:<br />
<pre># head -c20 /dev/random > ~/test_ca/noise.txt<br />
# /usr/bin/certutil -d ~/test_ca -R -s CN=Указать хост будущей реплики,O=IPA -o /tmp/replicacert.req -k rsa -g 2048 -z ~/test_ca/noise.txt -f ~/test_ca/pwdfile.txt -a</pre><br />
Подпишите запрос о выдаче сертификата реплики:<br />
<pre># /usr/bin/certutil -d ~/test_ca -C -c "CA" -i /tmp/replicacert.req -o /tmp/replicacert.pem -m 3 -v 120 -f ~/test_ca/pwdfile.txt -1 -5 -a</pre><br />
Дайте следующие ответы:<br />
<pre> Create key usage extension:<br />
2 - Key encipherment<br />
9 - done<br />
n - not critical<br />
Create netscape cert type extension:<br />
1 - SSL Server<br />
9 - done<br />
n - not critical<br />
</pre><br />
Если вы хотите, вы можете создавать отдельные сертификаты для серверов HTTP и Directory.<br />
<br />
'''Экспорт сертификатов в правильные форматы.'''<br />
<br />
Импортируем полученный сертификат:<br />
<pre># /usr/bin/certutil -d ~/test_ca -A -i /tmp/replicacert.pem -n Replica-Cert -a -t ,,</pre><br />
Экспортируем в PKCS#12:<br />
<pre># /usr/bin/pk12util -o ~/test_ca/replicacert.p12 -n Replica-Cert -d ~/test_ca -k ~/test_ca/pwdfile.txt -w ~/test_ca/pwdfile.txt</pre><br />
'''Для domain-level 1'''<br />
<br />
<pre># ipa-replica-install --http-cert-file ~/test_ca/replicacert.p12 --dirsrv-cert-file ~/test_ca/replicacert.p12</pre><br />
<br />
== Установка FreeIPA клиента и подключение к серверу ==<br />
Установим необходимые пакеты:<br />
<pre># apt-get install freeipa-client libsss_sudo krb5-kinit bind-utils libbind zip</pre><br />
Зададим имя компьютера:<br />
<pre># hostnamectl set-hostname comp01.example.test</pre><br />
Добавим DNS сервер, для этого создадим файл {{path|/etc/net/ifaces/ens19/resolv.conf}} со следующим содержимым:<br />
<pre>nameserver 192.168.135.1</pre><br />
192.168.135.1 - IP-адрес нашего FreeIPA сервера.<br><br />
Укажем службе resolvconf использовать DNS FreeIPA и наш домен для поиска.<br><br />
Для этого в файл {{path|/etc/resolvconf.conf}} добавим/отредактируем следующие параметры:<br />
<pre>interface_order='lo lo[0-9]* lo.* ens19'<br />
search_domains=example.test</pre><br />
Где ens19 -интерфейс на котором доступен FreeIPA сервер, example.test - наш домен.<br><br />
Обновим DNS адреса:<br />
<pre># resolvconf -u</pre><br />
После этого в файле {{path|/etc/resolv.conf}} должны появится строки:<br />
<pre>search example.test<br />
nameserver 192.168.135.1</pre><br />
Запускаем скрипт настройки клиента:<br />
в пакетном режиме:<br />
# ipa-client-install -U -p admin -w 12345678<br />
или интерактивно:<br />
<pre># ipa-client-install</pre><br />
Если все настроено верно скрипт должен выдать такое сообщение:<br />
<pre>'''Discovery was successful!'''<br />
Client hostname: comp02.example.test<br />
Realm: EXAMPLE.TEST<br />
DNS Domain: example.test<br />
IPA Server: ipa.example.test<br />
BaseDN: dc=example,dc=test<br />
Continue to configure the system with these values? [no]:</pre><br />
Отвечаем {{cmd|yes}} вводим имя пользователя, имеющего право вводить машины в домен, и его пароль.<br><br />
<br />
Пример успешного ввода в домен:<br />
<source lang="text">Discovery was successful!<br />
Client hostname: ipa-client1.test1.alt<br />
Realm: TEST1.ALT<br />
DNS Domain: test1.alt<br />
IPA Server: ipa-server.test1.alt<br />
BaseDN: dc=test1,dc=alt<br />
Synchronizing time with KDC...<br />
Attempting to sync time using ntpdate. Will timeout after 15 seconds<br />
Successfully retrieved CA cert<br />
Subject: CN=Certificate Authority,O=TEST1.ALT<br />
Issuer: CN=Certificate Authority,O=TEST1.ALT<br />
Valid From: Wed Feb 15 15:17:45 2017 UTC<br />
Valid Until: Sun Feb 15 15:17:45 2037 UTC<br />
<br />
Enrolled in IPA realm TEST1.ALT<br />
Created /etc/ipa/default.conf<br />
Configured sudoers in /etc/nsswitch.conf<br />
Configured /etc/sssd/sssd.conf<br />
Configured passwd in /etc/nsswitch.conf<br />
Configured group in /etc/nsswitch.conf<br />
Configured gshadow in /etc/nsswitch.conf<br />
Configured services in /etc/nsswitch.conf<br />
Configured netgroup in /etc/nsswitch.conf<br />
Configured shadow in /etc/nsswitch.conf<br />
Configured /etc/nsswitch.conf<br />
Configured PAM system-auth<br />
Configured /etc/krb5.conf for IPA realm TEST1.ALT<br />
trying https://ipa-server.test1.alt/ipa/json<br />
Forwarding 'ping' to json server 'https://ipa-server.test1.alt/ipa/json'<br />
Forwarding 'ca_is_enabled' to json server 'https://ipa-server.test1.alt/ipa/json'<br />
Hostname (ipa-client1.test1.alt) does not have A/AAAA record.<br />
Failed to update DNS records.<br />
Missing A/AAAA record(s) for host ipa-client1.test1.alt: 10.10.10.206.<br />
Missing reverse record(s) for address(es): 10.10.10.206.<br />
Adding SSH public key from /etc/openssh/ssh_host_ecdsa_key.pub<br />
Adding SSH public key from /etc/openssh/ssh_host_ed25519_key.pub<br />
Adding SSH public key from /etc/openssh/ssh_host_dsa_key.pub<br />
Adding SSH public key from /etc/openssh/ssh_host_rsa_key.pub<br />
Forwarding 'host_mod' to json server 'https://ipa-server.test1.alt/ipa/json'<br />
Could not update DNS SSHFP records.<br />
SSSD enabled<br />
Configured /etc/openldap/ldap.conf<br />
NTP enabled<br />
Configured /etc/openssh/ssh_config<br />
Configured /etc/openssh/sshd_config<br />
Configuring test1.alt as NIS domain.<br />
Client configuration complete.</source><br />
<br />
{{Attention|Если при входе в домен возникает такая ошибка:<br />
<pre>Hostname (ipa-client1.test1.alt) does not have A/AAAA record.<br />
Failed to update DNS records.</pre><br />
Проверьте IP-адрес доменного DNS сервера в файле {{path|/etc/resolv.conf}}}}<br />
<br />
В случае возникновения ошибки, необходимо перед повторной установкой запустить процедуру удаления:<br />
# ipa-client-install -U --uninstall<br />
<br />
Для работы sudo-политик для доменных пользователей на клиентской машине необходимо разрешить доступ к sudo:<br />
<pre># control sudo public</pre><br />
=== Вход пользователя ===<br />
<br />
При первом входе пользователя будет запрошен текущий установленный администратором пароль и затем у пользователя запрашивается новый пароль и его подтверждение.<br />
<br />
{{Attention|Если машина до этого была в других доменах или есть проблемы со входом пользователей рекомендуется очистить кэш sssd:<br />
<pre># systemctl stop sssd<br />
# rm -f /var/lib/sss/db/*<br />
# rm -f /var/lib/sss/mc/*<br />
# systemctl start sssd</pre>}}<br />
<br />
== IPA Automount NFS ==<br />
Установим nfs-server: <br />
<pre> apt-get install nfs-server </pre><br />
<br />
Включим SECURE_NFS:<br />
<pre>echo 'SECURE_NFS=yes' >> /etc/sysconfig/nfs</pre><br />
<br />
Добавим сервис в автозапуск:<br />
<pre>systemctl enable --now nfs-server</pre><br />
Добавим список экспорта и применим изменения:<br />
<pre><br />
# mkdir -p /exports/test_share <br />
# echo '/exports/test_share client1.testbc.testbe(rw,no_subtree_check,sec=krb5p)' >> /etc/exports<br />
# exportfs -vra<br />
</pre><br />
На IPA сервере:<br />
<pre># kinit admin</pre><br />
Добавить ipa сервис где nfs.testbc.testbe наш nfs сервер:<br />
<pre># ipa service-add nfs/nfs.testbc.testbe</pre><br />
Добавляем в keytab:<br />
<pre># ipa-getkeytab -s freeipa.testbc.testbe -p nfs/nfs.testbc.testbe -k /etc/krb5.keytab</pre><br />
Проверим наличие:<br />
<pre># klist -k /etc/krb5.keytab<br />
Keytab name: FILE:/etc/krb5.keytab <br />
KVNO Principal <br />
---- ---------- <br />
2 host/nfs.testbc.testbe@TESTBC.TESTBE <br />
1 nfs/nfs.testbc.testbe@TESTBC.TESTBE</pre><br />
Перезапустим nfs сервер:<br />
<pre># systemctl restart nfs-server</pre><br />
Добавим правила автомонтирования:<br />
<pre><br />
# ipa automountmap-add default auto.test<br />
# ipa automountkey-add default --key "/-" --info auto.test auto.master<br />
# ipa automountkey-add default --key "/mnt/testshare" --info "-fstype=nfs4,rw,sec=krb5p,hard nfs.testbc.testbe:/exports/test_share" auto.test<br />
</pre><br />
Удалим пустую карту монтирования:<br />
<pre># ipa automountkey-del --key '/-' --info 'auto.direct' default auto.master</pre><br />
Настройка клиента: <br />
ipa-client-install<br />
Устанавливаем пакет freeipa-client-automount:<br />
<pre> # apt-get install freeipa-client-automount </pre><br />
Проверим доступность nfs:<br />
<pre># showmount -e nfs.testbc.testbe</pre><br />
Настроим автомонтирование:<br />
<pre># ipa-client-automount --location default</pre><br />
На IPA сервере:<br />
Создадим пользователя:<br />
<pre># ipa user-add ipatest --first ipatest --last ipatest</pre><br />
Предоставим пользователю права на запись:<br />
<pre># mkdir /exports/test_share/testdir <br />
# chown ipatest:ipatest /exports/test_share/testdir</pre><br />
Создадим домашнюю папку пользователя на nfs сервере:<br />
<pre># mkhomedir_helper ipatest<br />
# echo '/home client1.testbc.testbe(rw,no_subtree_check,sec=krb5p)' >> /etc/exports <br />
# exportfs -vra<br />
</pre><br />
Добавим правила автомонтирования:<br />
<pre>ipa automountmap-add default auto.home <br />
ipa automountkey-add default --key "/home" --info auto.home auto.master <br />
ipa automountkey-add default --key "*" --info "-fstype=nfs4,rw,sec=krb5p,hard nfs.testbc.testbe:/home/&" auto.home</pre><br />
Проверяем на клиенте:<br />
<pre>$ df -h</pre><br />
Для отладки используйте:<br />
<br />
NFS/autofs/sssd-autofs: <br />
<pre>systemctl stop autofs <br />
automount -fd -vvv</pre> <br />
krb5: <br />
<pre>sed -i '/^GSSD_OPTIONS=/{s/"$/ -vvv"/g}' /etc/sysconfig/nfs<br />
systemctl restart rpc-gssd</pre><br />
<br />
== Настройка репликации ==<br />
<br />
На втором контроллере домена установим необходимые пакеты:<br />
<pre># apt-get install freeipa-client freeipa-server-dns</pre><br />
<br />
Зададим имя сервера:<br />
<pre># hostnamectl set-hostname ipabackup.example.test</pre><br />
<br />
Теперь развернём и настроим клиента:<br />
<pre><br />
# ipa-client-install -d \<br />
--domain=example.test \<br />
--server=ipa.example.test \<br />
--realm=EXAMPLE.TEST \<br />
--principal=admin \<br />
--password=12345678 \<br />
--enable-dns-updates -U<br />
</pre><br />
<br />
После выполнения этой операции хост '''ipabackup.example.test''' должен появиться в веб-интерфейсе FreeIPA. Переходим к настройке репликации LDAP-каталога:<br />
<pre># ipa-replica-install</pre><br />
<br />
Добавляем в DNS второй NTP-сервер:<br />
<pre><br />
# kinit admin<br />
# ipa dnsrecord-add example.test _ntp._udp --srv-priority=0 --srv-weight=100 --srv-port=123 --srv-target=ipabackup.example.test.<br />
</pre><br />
<br />
Настроим репликацию DNS-зон:<br />
<pre># ipa-dns-install</pre><br />
<br />
Наконец, настроим репликацию CA:<br />
<pre># ipa-ca-install</pre><br />
<br />
После настройки и репликации контроллеров посмотреть топологию можно в веб-интерфейсе FreeIPA (IPA Server -> Topology -> Topology Graph).<br />
<br />
<br />
== Настройка доверительных отношений с AD ==<br />
FreeIPA использует Samba для интеграции в Active Directory. Для работы Samba необходим работающий стек IPv6.<br><br />
Начальные данные:<br />
* IP адрес IPA сервера: '''192.168.135.130'''<br />
* Имя IPA сервера: '''dcf'''<br />
* Имя IPA домена: '''domf.testf'''<br />
* NetBIOS имя IPA домена: '''DOMF'''<br />
* IP адрес AD DC: '''192.168.135.150'''<br />
* Имя AD DC: '''dcc'''<br />
* Имя AD домена: '''domc.testc'''<br />
* NetBIOS имя AD домена: '''DOMC'''<br />
<br />
Установим необходимые пакеты:<br />
<pre># apt-get install freeipa-server-trust-ad python-module-sss-murmur samba-winbind</pre><br />
=== Предварительная настройка IPA сервера ===<br />
'''Настроим IPA''' для работы с доверительными отношениями:<br />
<pre># ipa-adtrust-install</pre><br />
Скрипт спросит необходимо ли конфигурировать {{path|slapi-nis}} плагин для поддержки работы старых клиентов (SSSD < 1.9) с пользователем из доверенного домена:<br />
<pre>Enable trusted domains support in slapi-nis? [no]:</pre> <br />
На IPA сервере добавлен хотя бы один пользователь (администратор сервера), поэтому скрипт предложит сгенерировать SID для всех существующих пользователей и груп:<br />
<pre>Do you want to run the ipa-sidgen task? [no]:</pre><br />
Дата и время на серверах должны совпадать.<pre><br />
IPA сервер в своей работе использует следующие порты:<br />
<pre>TCP ports: 80, 88, 443, 389, 636, 88, 464, 53, 135, 138, 139, 445, 1024-1300<br />
UDP ports: 88, 464, 53, 123, 138, 139, 389, 445</pre><br />
Они должны быть открыты и доступны.<br><br />
'''Настроим Samba:'''<br><br />
<pre># net conf setparm global 'dedicated keytab file' /etc/samba/samba.keytab<br />
# systemctl restart ipa</pre><br />
Проверим проходит ли Samba аутентификацию Kerberos со стороны IPA сервера:<br />
<pre># kinit admin<br />
# smbclient -L dcf.domf.testf -k<br />
lp_load_ex: changing to config backend registry<br />
Domain=[DOMF] OS=[Windows 6.1] Server=[Samba 4.5.5]<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (Samba 4.5.5)<br />
Domain=[DOMF] OS=[Windows 6.1] Server=[Samba 4.5.5]<br />
<br />
Server Comment<br />
--------- -------<br />
<br />
Workgroup Master<br />
--------- -------</pre><br />
'''Настроим DNS''' на обоих серверах, чтобы они знали друг о друге:<br><br />
На AD сервере создадим сервер условной пересылки для зоны IPA домена:<br />
<pre>C:\> dnscmd 127.0.0.1 /ZoneAdd domf.testf /Forwarder 192.168.135.130</pre><br />
На IPA сервере так же добавим зону AD домена:<br />
<pre># ipa dnsforwardzone-add domc.testc --forwarder=192.168.135.150 --forward-policy=only</pre><br />
<br />
=== Проверка конфигурации DNS ===<br />
'''На AD сервере:'''<br><br />
Проверим наличие записей для работы сервисов IPA на DNS-сервере AD.<br><br />
1. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:<br />
<pre>C:\>nslookup.exe<br />
> set type=SRV<br />
<br />
> _kerberos._udp.domf.testf.<br />
_kerberos._udp.domf.testf. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 88<br />
svr hostname = dcf.domf.testf.<br />
<br />
> _ldap._tcp.domf.testf.<br />
_ldap._tcp.ipa.example.com SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 389<br />
svr hostname = dcf.domf.testf.</pre><br />
<br />
2. Запись отвечающая за имя Kerberos realm IPA домена:<br />
<pre>C:\>nslookup.exe<br />
> set type=TXT<br />
> _kerberos.domf.testf.<br />
_kerberos.domf.testf. text =<br />
<br />
"DOMF.TESTF"</pre><br />
<br />
3. После выполнения команды {{path|ipa-adtrust-install}} должны появится записи отвечающие за работу сервисов MS DC Kerberos через UDP и LDAP через TCP:<br />
<pre>C:\>nslookup.exe<br />
> set type=SRV<br />
> _kerberos._udp.dc._msdcs.domf.testf.<br />
_kerberos._udp.dc._msdcs.domf.testf. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 88<br />
svr hostname = dcf.domf.testf.<br />
> _ldap._tcp.dc._msdcs.domf.testf.<br />
_ldap._tcp.dc._msdcs.domf.testf. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 389<br />
svr hostname = dcf.domf.testf.</pre><br />
Далее проверим наличие записей для работы сервисов AD на DNS-сервере AD.<br><br />
4. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:<br />
<pre>C:\>nslookup.exe<br />
> set type=SRV<br />
> _kerberos._udp.dc._msdcs.domc.testc.<br />
_kerberos._udp.dc._msdcs.domc.testc. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 88<br />
svr hostname = dcc.domc.testc.<br />
> _ldap._tcp.dc._msdcs.domc.testc.<br />
_ldap._tcp.dc._msdcs.domc.testc. SRV service location:<br />
priority = 0<br />
weight = 100<br />
port = 389<br />
svr hostname = dcc.domc.testc.</pre><br />
<br />
'''На IPA сервере:'''<br><br />
Проверим наличие записей для работы сервисов IPA на DNS-сервере IPA.<br><br />
1. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:<br />
<pre># dig +short -t SRV _kerberos._udp.domf.testf.<br />
0 100 88 dcf.domf.testf.<br />
<br />
# dig +short -t SRV _ldap._tcp.domf.testf.<br />
0 100 389 dcf.domf.testf.</pre><br />
2. Запись отвечающая за имя Kerberos realm IPA домена:<br />
<pre>dig +short -t TXT _kerberos.domf.testf.<br />
"DOMF.TESTF"</pre><br />
3. После выполнения команды {{path|ipa-adtrust-install}} должны появится записи отвечающие за работу сервисов MS DC Kerberos через UDP и LDAP через TCP:<br />
<pre># dig +short -t SRV _kerberos._udp.dc._msdcs.domf.testf.<br />
0 100 88 dcf.domf.testf.<br />
<br />
# dig +short -t SRV _ldap._tcp.dc._msdcs.domf.testf.<br />
0 100 389 dcf.domf.testf.</pre><br />
Далее проверим наличие записей для работы сервисов AD на DNS-сервере IPA.<br />
4. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:<br />
<pre># dig +short -t SRV _kerberos._udp.dc._msdcs.domc.testc.<br />
0 100 88 dcc.domc.testc.<br />
<br />
# dig +short -t SRV _ldap._tcp.dc._msdcs.domc.testc.<br />
0 100 389 dcc.domc.testc.</pre><br />
{{Attention|Если запись {{cmd|_kerberos._udp.dc._msdcs.domc.testc.}} не доступна проверьте {{cmd|_kerberos._tcp.dc._msdcs.domc.testc.}}}}<br />
<br />
=== Настройка доверия ===<br />
Добавление двунаправленных доверительных отношений леса (Forest Trust) с AD:<br><br />
Имя доменного администратора Windows должно быть на латинице, кириллицу (Администратор) IPA не принимает.<br><br />
<pre># kinit admin<br />
# ipa trust-add --type=ad domc.testc --admin Administrator --password --two-way=true<br />
Active Directory domain administrator's password: <br />
---------------------------------------------------<br />
Added Active Directory trust for realm "domc.testc"<br />
---------------------------------------------------<br />
Realm name: domc.testc<br />
Domain NetBIOS name: DOMC<br />
Domain Security Identifier: S-1-5-21-3611360735-1365415015-3217858865<br />
SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13,<br />
S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18<br />
SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13,<br />
S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18<br />
Trust direction: Two-way trust<br />
Trust type: Active Directory domain<br />
Trust status: Established and verified<br />
</pre><br />
Необходимо ввести пароль Administrator AD.<br><br />
Далее необходимо запросить сервер AD о его доверенных доменах:<br />
<pre># ipa trust-fetch-domains domc.testc<br />
--------------------------------------------<br />
List of trust domains successfully refreshed<br />
--------------------------------------------<br />
Realm name: domd.domc.testc<br />
Domain NetBIOS name: DOMD<br />
Domain Security Identifier: S-1-5-21-2419724241-1549151283-3268040000<br />
------------------------------<br />
Количество вернутых значений 1<br />
------------------------------<br />
</pre><br />
При этом IPA создаст нужные id-диапазоны для доверенных доменов.<br><br />
Если мы добавим в лес еще один домен DOME.TESTE, то необходимо настроить DNS на обоих серверах, чтобы они видели друг друга.<br><br />
И выполнить команду еще раз,чтобы IPA сервер узнал о нем:<br />
<pre># ipa trust-fetch-domains domc.testc<br />
--------------------------------------------<br />
List of trust domains successfully refreshed<br />
--------------------------------------------<br />
Realm name: dome.teste<br />
Domain NetBIOS name: DOME<br />
Domain Security Identifier: S-1-5-21-3615012966-1241218098-4147673574<br />
------------------------------<br />
Количество вернутых значений 1<br />
------------------------------</pre><br />
Найти все доверенные домены можно и с помощью web-интерфейса. Для Перейдем в IPA Server -> Trusts и выберем нужный нам домен:<br><br />
[[Файл:IPATrusts.png|600px]]<br><br />
Нажмём кнопку Fetch domains это обновит список доверенных доменов:<br><br />
[[Файл:IPATrustFetch.png|600px]]<br><br />
<br />
Для того чтобы увидеть список всех доверенных доменов из леса используйте следующую команду:<br />
<pre># ipa trustdomain-find domc.testc<br />
Domain name: domc.testc<br />
Domain NetBIOS name: DOMC<br />
Domain Security Identifier: S-1-5-21-3611360735-1365415015-3217858865<br />
Domain enabled: True<br />
<br />
Domain name: domd.domc.testc<br />
Domain NetBIOS name: DOMD<br />
Domain Security Identifier: S-1-5-21-2419724241-1549151283-3268040000<br />
Domain enabled: True<br />
<br />
Domain name: dome.teste<br />
Domain NetBIOS name: DOME<br />
Domain Security Identifier: S-1-5-21-3615012966-1241218098-4147673574<br />
Domain enabled: True<br />
------------------------------<br />
Количество вернутых значений 3<br />
------------------------------<br />
</pre><br />
<br />
=== Проверка конфигурации Kerberos ===<br />
1. Запросим ticket для IPA пользователя:<br />
<pre># kinit admin</pre><br />
2. Запросим service ticket для сервиса из IPA домена:<br />
<pre># kvno -S host dcf.domf.testf<br />
host/dcf.domf.testf@DOMF.TESTF: kvno = 2</pre><br />
3. Запросим service ticket сервиса из AD домена:<br />
<pre># kvno -S cifs dcc.domc.testc<br />
cifs/dcc.domc.testc@: kvno = 3</pre><br />
Если запрос service ticket для сервиса из AD домена прошел успешно, то у нас должен появиться междоменный ticket-granting ticket, его имя krbtgt/DOMC.TESTC@DOMF.TESTF:<br />
<pre># klist<br />
Ticket cache: KEYRING:persistent:0:0<br />
Default principal: admin@DOMF.TESTF<br />
<br />
Valid starting Expires Service principal<br />
14.02.2017 15:43:46 15.02.2017 01:43:46 cifs/dcc.domc.testc@DOMC.TESTC<br />
14.02.2017 15:43:46 15.02.2017 01:43:46 cifs/dcc.domc.testc@<br />
14.02.2017 15:43:46 15.02.2017 15:42:48 krbtgt/DOMC.TESTC@DOMF.TESTF<br />
14.02.2017 15:43:25 15.02.2017 15:42:48 host/dcf.domf.testf@DOMF.TESTF<br />
14.02.2017 15:42:53 15.02.2017 15:42:48 krbtgt/DOMF.TESTF@DOMF.TESTF</pre><br />
=== Проверка пользователей доверенного домена ===<br />
Проверим имеет ли доступ к пользователям из доверенного домена рабочие станции IPA.<br><br />
Для этого на рабочей станции IPA выполните команду:<br />
<pre># getent passwd u01domc@domc<br />
u01domc@domc.testc:*:328601108:328601108:u01domc:/home/domc.testc/u01domc:</pre><br />
Где u01domc это пользователь из AD домена. Обратите внимание, что не указана оболочка входа. Назначить оболочку входа для пользователей из доверенного домена можно добавив на сервере IPA в файл {{path|/etc/sssd/sssd.conf}} следующую строчку:<br />
<pre>[domain/domf.testf]<br />
...<br />
default_shell = /bin/bash<br />
...</pre><br />
Вывод команды должен стать таким:<br />
<pre># getent passwd u01domc@domc<br />
u01domc@domc.testc:*:328601108:328601108:u01domc:/home/domc.testc/u01domc:/bin/bash</pre><br />
{{Attention|Для корректной работы сервера IPA с пользователями доверенного домена AD необходимо обеспечить доступ сервиса sssd к /etc/krb5.keytab см. [https://bugzilla.altlinux.org/33115 bug 33115]}}<br />
{{Attention|Для входа AD пользователя в ALT рабочую станцию из IPA вводим имя пользователя в формате '''DOMC'''\username или '''DOMC.TESTC'''\username или username@'''domc''' username@'''domc.testc'''}}<br />
{{Attention|Для входа IPA пользователя в windows рабочую станцию из AD вводим имя пользователя в формате '''DOMF.TESTF'''\username}}<br />
<br />
== Создание аккаунта для доступа к LDAP ==<br />
Некоторые сервисы использующие LDAP требуют предварительно настроенной учетной записи. Использование обычной учетной записи пользователя предпочтительней, но не всегда это целесообразно делать. Можно сделать системную учетную запись следующим образом на сервере FreeIPA используя пароль Directory :<br />
<pre># ldapmodify -x -D 'cn=Directory Manager' -W<br />
dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=test<br />
changetype: add<br />
objectclass: account<br />
objectclass: simplesecurityobject<br />
uid: ldapaccount<br />
userPassword: secret123<br />
passwordExpirationTime: 20380119031407Z<br />
nsIdleTimeout: 0<br />
<blank line><br />
^D</pre><br />
Замените пароль на более сложный. Параметр {{path|passwordExpirationTime: 20380119031407Z}} означает, что срок действия пароля неограничен<br />
Причина использования такой учетной записи, а не создание обычной учетной записи пользователя IPA, и использование этой системы заключается в том, что системная учетная запись существует только для привязки к LDAP. Это не настоящий пользователь POSIX, он не может войти в систему и ему не принадлежат файлы. У этого пользователя нет особых прав и он не может ничего записывать какие-либо данные на сервер LDAP FreeIPA, только права на чтение.<br />
<br />
== Добавление расширенных полей в ldap ==<br />
<br />
Если необходимо добавить поля в вашу схему ldap, то реализация этого возможна через команду ldapmodify и добавление своих плагинов для отображения этих полей в WebUi.<br><br />
Обычно файлы модификации схемы являются типом ''.ldif''.<br><br />
Пример:<br><br />
Содержание файла addExtField.ldif <br><br />
<pre>dn: cn=schema<br />
changetype: modify<br />
add: attributeTypes<br />
attributeTypes: ( 2.25.28639311321113238241701611583088740684.14.2.2 NAME 'favoriteColorName' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Extending FreeIPA' )<br />
<br />
dn: cn=schema<br />
changetype: modify<br />
add: attributeTypes<br />
attributeTypes: ( 2.25.28639311321113238241701611583088740684.14.2.3 NAME 'redirects' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Extending FreeIPA')<br />
<br />
dn: cn=schema<br />
changetype: modify<br />
add: attributeTypes<br />
attributeTypes: ( 2.25.28639311321113238241701611583088740684.14.2.4 NAME 'attbool' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 X-ORIGIN 'Extending FreeIPA')<br />
<br />
dn: cn=schema<br />
changetype: modify<br />
add: objectclasses<br />
objectclasses: ( 2.25.28639311321113238241701611583088740684.14.2.1 NAME 'customPerson' SUP person STRUCTURAL MAY ( favoriteColorName $ attbool $ redirects ) X-ORIGIN 'Extending FreeIPA' )</pre><br />
<br />
Детальное пояснение для блока:<br><br />
<br />
<pre>dn: cn=schema<br />
changetype: modify<br />
add: attributeTypes<br />
attributeTypes: ( 2.25.28639311321113238241701611583088740684.14.2.2<br />
NAME 'favoriteColorName'<br />
EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch<br />
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15<br />
X-ORIGIN 'Extending FreeIPA' )</pre><br />
<br />
'''dn''' - dn, в котором будет проводиться изменение. Добавление/удаление классов и т.д.<br><br />
<br />
'''changetype''' - атрибут, отвечающий за тип изменений, которые будут происходить.(add, delete, modify, modrdn)<br><br />
<br />
'''add: attributeTypes''' - добавление атрибута, далее идёт описание атрибута.<br><br />
'''2.25.28639311321113238241701611583088740684.14.2.2''' - уникальный идентификатор атрибута. Можно написать любой.<br><br />
<br />
'''NAME 'favoriteColorName' ''' - По другому можно назвать - primary name. Название атрибута.<br><br />
<br />
'''EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch''' - эти атрибуты заданы для проверки соответствия содержания атрибута правилам caseIgnoreMatch <br><br />
<br />
'''SYNTAX 1.3.6.1.4.1.1466.115.121.1.15''' - OID типа данных <br><br />
<br />
Все изменения в схеме производятся от пользователя - Directory manager.<br><br />
<br />
Изменение схемы ldap:<br />
<br />
<pre>$ ldapmodify -D "cn=Directory Manager" -W -f addExtField.ldif</pre><br />
<br />
После изменения схемы, путем добавления нового objectclass, нужно чтобы эти поля еще можно было редактировать в web-интерфейсе. Для этого необходимо сделать палагин. В примере использовано 3 атрибута, для них сделаем 3 отдельных плагина:<br />
<br />
1. Создание папки:<br />
<pre>mkdir -p /usr/share/ipa/ui/js/plugins/favoriteColorName</pre><br />
<br />
2. Создание самого плагина:<br />
<pre>mcedit /usr/share/ipa/ui/js/plugins/favoriteColorName/favoriteColorName.js</pre><br />
Тело плагина:<br />
<br />
<pre>define(['freeipa/phases','freeipa/user'],<br />
function(phases, user_mod) {<br />
// helper function<br />
function get_item(array, attr, value) {<br />
for (var i=0,l=array.length; i<l; i++) {<br />
if (array[i][attr] === value) return array[i];<br />
}<br />
return null;<br />
}<br />
<br />
var color_plugin = {};<br />
<br />
color_plugin.add_favorite_color = function() {<br />
var facet = get_item(user_mod.entity_spec.facets, '$type', 'details');<br />
var section = get_item(facet.sections, 'name', 'identity');<br />
section.fields.push({<br />
name: 'favoritecolorname',<br />
label: 'Цвет'<br />
});<br />
return true;<br />
};<br />
<br />
phases.on('customization', color_plugin.add_favorite_color);<br />
<br />
return color_plugin;<br />
});</pre><br />
<br />
В схеме бы добавлен атрибут типа boolean, для него можно сделать радиокнопки:<br><br />
<br />
<pre>define(['freeipa/phases','freeipa/user'],<br />
function(phases, user_mod) {<br />
// helper function<br />
function get_item(array, attr, value) {<br />
for (var i=0,l=array.length; i<l; i++) {<br />
if (array[i][attr] === value) return array[i];<br />
}<br />
return null;<br />
}<br />
<br />
var attrbool_plugin = {};<br />
<br />
attrbool_plugin.add_bool = function() {<br />
var facet = get_item(user_mod.entity_spec.facets, '$type', 'details');<br />
var section = get_item(facet.sections, 'name', 'identity');<br />
section.fields.push(<br />
{<br />
$type: 'radio',.<br />
options:[{label:'True',value:'TRUE'},{label:'False',value:'FALSE'}],<br />
label:'Blood type',<br />
name: 'attbool'}<br />
);<br />
return true;<br />
};<br />
<br />
phases.on('customization', attrbool_plugin.add_bool);<br />
<br />
return attrbool_plugin;<br />
});<br />
<br />
</pre><br />
<br />
После необходимо добавить новое поле в "Default user objectclasses" (находится IPA Server -> Configuration) созданный objectclass (customPerson) и появятся поля в web-интерфейсе. Для того чтобы пользователь мог их редактировать, необходимо изменить привилегии в группе ipausers. <br><br />
== Использование haproxy для высокой доступности FreeIPA ==<br />
'''Требуется:''' <br />
<br />
Сервер №1 c freeipa: dc1.testbc.testgl<br />
<br />
Сервер №2 с репликой freeipa: dc2.testbc.testgl<br />
<br />
Сервер №3 с haproxy: haproxy.testbc.testgl<br />
<br />
[[Файл:Схема.png]]<br />
<br />
'''Настройка:'''<br />
<br />
Инструкция для настройки сервера №1 и №2: [[FreeIPA]]<br />
<br />
На сервере №3: <br />
<br />
Установить<br />
<pre># apt-get install haproxy</pre><br />
Сохранить оригинальный конфигурационный файл:<br />
<br />
<pre>cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxyBAK.cfg</pre><br />
Изменить конфигурацию:<br />
<pre><br />
cat << EOF > /etc/haproxy/haproxy.cfg<br />
global<br />
log 127.0.0.1 local2<br />
<br />
chroot /var/lib/haproxy<br />
pidfile /var/run/haproxy.pid<br />
maxconn 4000<br />
user _haproxy<br />
group _haproxy<br />
daemon<br />
<br />
stats socket /var/lib/haproxy/stats<br />
# LDAP and LDAP/STARTTLS<br />
frontend ldap_service_front<br />
mode tcp<br />
bind *:389<br />
description LDAP Service<br />
option socket-stats<br />
option tcpka<br />
timeout client 3600s<br />
default_backend ldap_service_back<br />
<br />
backend ldap_service_back<br />
server ldap-1 dc1.testbc.testgl:389 check fall 1 rise 3 inter 2s weight 150<br />
server ldap-2 dc2.testbc.testgl:389 check fall 1 rise 3 inter 2s weight 100<br />
mode tcp<br />
balance roundrobin<br />
option tcpka<br />
option ldap-check<br />
timeout server 1800s<br />
timeout connect 1s<br />
frontend ldaps_service_front<br />
mode tcp<br />
bind *:636<br />
description LDAP Service<br />
option socket-stats<br />
option tcpka<br />
timeout client 3600s<br />
default_backend ldap_service_back<br />
<br />
backend ldaps_service_back<br />
server ldap-1 dc1.testbc.testgl:636 check fall 1 rise 3 inter 2s weight 150<br />
server ldap-2 dc1.testbc.testgl:636 check fall 1 rise 3 inter 2s weight 150<br />
mode tcp<br />
balance roundrobin<br />
option tcpka<br />
option ssl-hello-chk<br />
timeout server 1800s<br />
EOF<br />
</pre><br />
Запустить сервис haproxy:<br />
<pre>#systemctl start haproxy</pre><br />
Проверить работу можно с помощью ldapsearch сделав один из серверов недоступным:<br />
<pre>ldapsearch -x -h haproxy.testbc.testgl -b dc=testbc,dc=testgl uid=admin</pre><br />
Результат: ldap всегда доступен.<br />
<br />
== Automember rebuild membership ==<br />
<br />
Пользовательские или хост группы можно легко перестроить на основе новых или обновленных правил automember. Команда automember rebuild только добавляет новые отношения для групп, она не удаляет те, которые не соответствуют правилам automember. Недавно добавленная команда вызовет задачу в rebuild automember, создав запись LDAP в cn = automember rebuild membership, cn = tasks, cn = config. Плагин automember в настоящее время проверяет операции Add(добавления), чтобы увидеть, есть ли запись соответствует одному из определенных правил automember. Существующие записи не проверяются когда они изменяются. Чтобы применить правило для всех записей, надо добавить задачу к плагину automember. Создатель задачи обеспечит фильтр поиска и базу. Все совпадающие записи будут проверяться в соответствии с определенными правилами automember, чтобы увидеть если они должны быть добавлены в какие-либо группы. Это позволяет добавить запуск атрибуты(значения) после того, как запись была первоначально добавлена, а затем вызвать задачу(выполнить) обновления automember. Ipa automember-rebuild может использоваться для восстановления членства для всех объектов определенного типа:<br />
<pre><br />
$ ipa automember-rebuild --type=group<br />
$ ipa automember-rebuild --type=hostgroup<br />
</pre><br />
Он также может использоваться для восстановления членства для указанных записей:<br />
<pre><br />
$ ipa automember-rebuild --hosts=HOSTNAME1 --hosts=HOSTNAME2<br />
$ ipa automember-rebuild --users=LOGIN1 --users=LOGIN2<br />
</pre><br />
Добавление новой группы хостов:<br />
<pre><br />
$ ipa hostgroup-add --desc="Web Servers" webservers<br />
</pre><br />
Добавить новый хост:<br />
<pre><br />
$ ipa host-add web1.example.com --force<br />
</pre><br />
Добавить automember rule:<br />
<pre><br />
$ ipa automember-add --type=hostgroup webservers<br />
$ ipa automember-add-condition --key=fqdn --type=hostgroup --inclusive-regex=^web[1-9]+\.example\.com webservers<br />
</pre><br />
Функция automember теперь работает для новых добавленных записей. Если мы добавим новый хост, он будет автоматически помещен в соответствующую группу хостов:<br />
<pre><br />
$ ipa host-add web2.example.com --force<br />
$ ipa hostgroup-show webservers<br />
Host-group: webservers<br />
Description: Web Servers<br />
Member hosts: web2.example.com<br />
</pre><br />
Однако старая запись хоста для web1.example.com по-прежнему не является членом или хост-группой веб-серверов. Введя новые команды automember-rebuild, мы сделаем это возможным:<br />
<pre> <br />
$ ipa automember-rebuild --type=hostgroup<br />
or<br />
$ ipa automember-rebuild --hosts=web1.example.com<br />
</pre><br />
Хост добавится в новую группу:<br />
<pre><br />
$ ipa hostgroup-show webservers<br />
Host-group: webservers<br />
Description: Web Servers<br />
Member hosts: web2.example.com, web1.example.com<br />
</pre><br />
Тоже самое можно сделать в web-интерфейсе.<br />
<br />
== Дополнительные материалы ==<br />
* [https://habrahabr.ru/company/pixonic/blog/325546/ Настройка репликации во FreeIPA 4.4 с domain level 1] — Блог Pixonic на Habrahabr<br />
* [Система централизованного управления авторизацией пользователей на FreeIPA в Docker Система централизованного управления авторизацией пользователей на FreeIPA в Docker] — frol, Habrahabr<br />
<br />
[[Категория:Корпоративная инфраструктура]]<br />
[[Категория:HOWTO]]<br />
<br />
{{Category navigation|title=Корпоративная инфраструктура|category=Корпоративная инфраструктура|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=InstallFlash&diff=48561InstallFlash2020-06-04T14:05:54Z<p>AntonFarygin: </p>
<hr />
<div>{{Attention|Данная статья актуальна только для старых версий дистрибутивов ALT Linux (< 6.0). О записи на флэшку новых дистрибутивов читайте [[Write|эту статью]].}}<br />
<br />
{{Attention|В некоторых очень редких случаях, например как на Lenovo B570e BIOS не имеет возможности отключения Legacy режима, а в EFI с Linux не работает. При этом режим EFI активируется автоматически, если найден загрузчик EFI. Данная статья поможет установить современные дистрибутивы ALT на такой компьютер в Legacy режиме.}}<br />
<br />
{{h0|Как сделать установочную флешку}}<br />
{{викифицировать}}<br />
<br />
''Имея под рукой установочный DVD/компакт-диск''<br />
<br />
Иногда встречается ситуация, когда установка системы на новый компьютер затыкается на неспособности [[Propagator|пропагатора]] правильно определить и инициализировать дисковую подсистему компьютера, из-за чего не находится образ инсталятора. Или на компьютере банально нет привода компакт-дисков.<br />
Одно из решений этой проблемы — сделать из установочного компакт-диска установочную флешку. Которую можно ещё сделать с образом rescue и [[bootflash/liveFlash|liveFlash]]. И которую всегда можно носить с собой в кармане, в отличие от компакт-диска. :)<br />
<br />
== Пошаговое howto: ==<br />
Предположим, что устройство для нашей флешки — <tt>/dev/sdc</tt>, устройство для раздела на ней — <tt>/dev/sdc1</tt>.<br />
<ol><br />
<li> Берём флешку, от 4Гб для DVD варианта (наверное, с шаманством в области /ALTLlinux и /Metadata можно и меньшего размера) и от 1Гб для компакт-диска.<br />
<li> Если на ней уже есть достаточно большой FAT-раздел, тогда перейдите к пункту 6.<br />
<li> Если с этой флешки смонтированы какие-нибудь разделы (возможно, автоматически) — отмонтируем их.<br />
<li> Запускаем <tt># fdisk /dev/sdc</tt>, сносим все разделы, делаем раздел нужного размера, ставим ему тип C (FAT32) (или E (FAT16) для маленьких разделов, 2Гб и менее).<br />
<li> Делаем файловую систему: <tt># mkfs.vfat -n instflash /dev/sdc1</tt><br />
<li> fdisk’ом делаем наш раздел активным.<br />
<li> Если флешка и сидиром (или его .iso-образ) ещё не смонтированы, то монтируем их.<br />
<li> Копируем на наш раздел с установочного сидирома директории /ALTLinux, /Metadata, /syslinux и файл /altinst (<tt>$ cd /media/dvd; rsync -vr --progress ALTLinux Metadata syslinux altinst /media/instflash/</tt>)<br />
<li> Ставим пакет syslinux, если он ещё не установлен. (<tt># apt-get install syslinux</tt>)<br />
<li> Загоняем на флешку правильный образ MBR, способный к загрузке: <tt># dd if=/usr/lib/syslinux/mbr.bin of=/dev/sdc</tt><br />
<li> Идём на флешку в папку syslinux (<tt>cd /media/instflash/syslinux</tt>), создаем файл <tt>syslinux.cfg</tt> такого вот содержания (можно на основе имеющегося isolinux.cfg):<br />
</li><br />
default linux<br />
prompt 1<br />
timeout 200<br />
gfxboot bootlogo<br />
display boot.msg<br />
implicit 1<br />
<br />
label linux<br />
kernel alt0/vmlinuz<br />
append initrd=alt0/full.cz live fastboot lowmem stagename=/altinst lang=ru_RU<br />
splash=silent splashcount=17 showopts vga=0x314 automatic=method:disk,disk:sda,partition:sda1<br />
label failsafe<br />
kernel alt0/vmlinuz<br />
append initrd=alt0/full.cz live fastboot lowmem stagename=/altinst lang=ru_RU<br />
showopts noapic pci=nomsi acpi=off noload=ahci automatic=method:disk,disk:sda,partition:sda1<br />
<br />
: ''Художественное отступление.'' Флешка при загрузке может определиться, и не как <tt>sda</tt> (вот ещё почему для USB-загрузки лучше как можно меньше модулей пропагатору подсовывать), тогда пропагатор будет спрашивать, что за девайс мы хотим грузить. Надо или там, в пропагаторе, выбрать правильное устройство, или учесть это в этом файле. Или отключить нафик всякие картридеры :)<br />
: ''Художественное отступление 2.'' Пропагатор делает паузу в 5 секунд для инициализации USB-устройств. Особо одарённым флешкам этого может не хватать (<s>[https://bugzilla.altlinux.org/show_bug.cgi?id=13841 #13841]</s>), и тогда пропагатор скажет, что ничего не нашёл, и будет предлагать загрузить какой-нибудь модуль. Загрузите какой-нибудь модуль: флешка к тому времени уже скорее всего распознается.<br />
<li> Записываем загрузчик syslinux: <tt># syslinux -d /syslinux /dev/sdc1</tt><br />
<li> Торжественно несём флешку к непокорной машинке и грузимся с неё. Если пропагатор будет взбрыкивать, нам надо всячески попробовать подсунуть ему раздел нашей флешки, уж как он её там определит. Если будет спрашивать путь к образу для загрузки, можно попробовать просто нажать <nowiki>#Enter#</nowiki>.<br />
<li> Пробуем пройти процесс инсталляции!<br />
<li> Если на стадии применения разбивки дисков будет ругань, что невозможно записать Partition Table на устройстве таком-то и нужно перезагрузиться — перезагружаемся, как только появится графическая морда с выбором языка, переключаемся на вторую консоль (<tt>Ctrl-Alt-F2</tt>), и редактируем конфигурационный файл EVMS (<tt># vi /etc/evms.conf</tt>) — в секции <tt>sysfs_devices</tt> в параметр <tt>exclude</tt> нам надо внести устройства, на которые была ругань (должно получиться что-то вроде <tt>exclude = [ sda* loop* ]</tt>). Переключаемся обратно в седьмую консоль, и пробуем ещё раз установить систему. Должно же наконец получиться! :)<br />
</li><br />
: ''Художественное отступление.'' Неплохо ещё на флеху закинуть образ rescue (и учесть это в sysconf.cfg) — часть инсталлятора, lilo настраивающая, работает иногда со взбрыками и требует ручной доводки из live-системы.<br />
<pre>label rescue<br />
kernel alt0/vmlinuz<br />
append initrd=alt0/full.cz live ramdisk_size=65536 fastboot stagename=/rescue<br />
showopts automatic=method:disk,disk:sda,partition:sda1</pre><br />
</ol><br />
Ну вот вроде и всё. Удачной инсталляции!<br />
<br />
== Использование флешки для начальной загрузки ==<br />
Процедура создания загрузочной флешки, содержащей первую стадию инсталлятора, описана в [http://heap.altlinux.org/alt-docs/modules/install_desktop/index.html официальной документации]<br />
На этапе выбора директории или iso-образа укажите корневой каталог "/"<br />
<br />
== Ссылки по теме: ==<br />
* [[net/install|Альтернативный способ установки системы — по сети]]<br />
* [[InstallFlash/win32|Комментарии по адаптации этой статьи для win32]]<br />
<br />
[[Категория:Историческое]]<br />
{{Category navigation|title=Загрузочная флешка|category=BootFlash|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%90%D0%BB%D1%8C%D1%82_%D0%A0%D0%B0%D0%B1%D0%BE%D1%87%D0%B0%D1%8F_%D1%81%D1%82%D0%B0%D0%BD%D1%86%D0%B8%D1%8F_%D0%9A_8&diff=44742Альт Рабочая станция К 82019-05-22T13:08:39Z<p>AntonFarygin: /* Сроки выпуска и поддержка */</p>
<hr />
<div>== Продукт ==<br />
Альт Рабочая станция К 8 — многофункциональное решение для корпоративных рабочих станций, основанное на среде KDE 5.<br />
Рабочая станция К 8 интегрирована с сервером Альт Сервер 8.<br />
<br />
== Платформа ==<br />
[[Branches/p8|Восьмая платформа]]<br />
<br />
=== Основные преимущества ===<br />
* Графическая рабочая среда KDE5 — мощное и универсальное решение для начинающих и искушенных пользователей.<br />
* Широкий выбор различных программ для профессиональной и домашней работы в сети Интернет, с документами, со сложной графикой и анимацией, для обработки звука и видео и образования.<br />
* Подключение к инфраструктуре и различным сервисам сети подразделения и предприятия.<br />
* Включает приложения для отдыха и развлечений: вы можете поиграть сами и с детьми, посмотреть фильмы и послушать музыку, пообщаться с друзьями в социальных сетях, форумах и чатах.<br />
* Привычное оформление "из коробки", готовое к использованию сразу после установки.<br />
<br />
== Сроки выпуска и поддержка ==<br />
Выпуск 8.3 — ''' 19 апреля 2019 года'''<br />
Срок окончания поддержки обновлений безопасности - 3 года с момента покупки.<br />
<br />
== Изменения версии 8.3 ==<br />
<br />
Примечания:<br />
* В VirtualBox некорректно работает режим EFI. Не используйте его.<br />
Добавлено:<br />
* Возможность установки без аппаратной клавиатуры.<br />
* Установка на LVM и шифрованные разделы LUKS.<br />
* Сервис, облегчающий генерацию энтропии для случайных чисел rngd, включенный по умолчанию.<br />
* Установка на тома LVM по умолчанию.<br />
* Сервис синхронизации времени OpenNTPD заменён на chrony.<br />
* Эксперементальный модуль KDE для слежения за заполненностью оперативной пямяти.<br />
* Драйвер Wi-Fi для Realtek RTL8723DE.<br />
* Инструмент управления разделами жёсткого диска GParted заменён на KDE Partition Manager.<br />
* Поддержка установки на системы с 32-хбитным EFI.<br />
* Поддержка виртуализации - включение необходимых сервисов при установке внутри виртуальной машины.<br />
* Автоматическое подключение локального хранилища паролей KDE.<br />
* Поддержка системы протоколирования работы audit в pam_passwdqc.<br />
* Уведомление о заканчивающемся сроке действия пароля в инструменте обновления доменного тикета krb5-ticket-watcher.<br />
* Создание шифрованных носителей в утилите форматирования USB носителей quick-usb-formatter.<br />
* Добавлены шрифты google-crosextra-caladea и google-crosextra-carlito.<br />
* Реализованы всплывающие подсказки пунктов главного меню.<br />
* Добавлено автоматическое обновление микрокода CPU.<br />
* Поддержка NVIDIA OpenCL.<br />
* Возможность смены пароля с истекшим сроком действия при входе в систему, как для локального так и для доменного пользователя.<br />
Обновлено:<br />
* Ядро Linux 4.19.33 .<br />
* Mesa 18.0.5 .<br />
* xorg-server 1.19.7 с драйверами.<br />
* LibreOffice 6.1 с файловыми диалогами KDE5.<br />
* Драйверы NVIDIA 410.104, 390.116, 340.107, 304.137 .<br />
* KDE SC: Frameworks 5.48.0, Plasma 5.12.8, Applications 18.04.3 .<br />
* Среда запуска win32-приложений WINE 4.2 .<br />
* Qt 5.9.6 .<br />
Исправлено:<br />
* Существенно улучшены переводы справки и интерфейса приложений на русский язык нашей командой переводчиков.<br />
* Ошибка при отсутствии свободного места при установке на LVM.<br />
* Подключение существующих NTFS-разделов при установке.<br />
* Загрузка Live-образов большого размера в 32-хбитных сборках.<br />
* Автоустановка на LVM.<br />
* Поиск по закладкам в krunner (ALT+F2 в KDE) .<br />
* Некорректное создание папок на рабочем столе.<br />
* Некорректное поведение значков рабочего стола при перетаскивании.<br />
* Падение Plasma при настройке виджета Комиксы.<br />
* Некоректное поведение настроек виджетов мониторинга.<br />
* Исправлена установка в режиме EFI (при этом вскрылась проблема в реализации EFI в VirtualBox).<br />
* Зависание Plasma при нарушении связи со смонтированными сетевыми файловыми системами.<br />
* Навигация по разделам справки khelpcenter.<br />
* Увеличен размер окна для ввода пароля к wifi.<br />
* Невозможность прочесть усеченные элементы выпадающего списка krunner .<br />
* Настройка виджета Погода.<br />
* Работа виджета Словарь.<br />
* Предпросмотр языковых настроек локали при включении "настроить форматы отдельно".<br />
* Чрезмерное потребление памяти в Okular.<br />
* Отправка документа по электронной почте из LibreOffice при использовании Thunderbird.<br />
* Работа Bumblebee (NVIDIA Optimus).<br />
* Запуск установки на некоторых видеокартах Intel.<br />
* Улучшена поддержка встроенной графики Intel и AMD (Ryzen) (добавлена поддержка современных чипсетов, актуальных на момент выхода дистрибутива)<br />
* Улучшено определение сменных загрузочных носителей и сетевых карт при установке и в LiveCD.<br />
<br />
== Изменения версии 8.2 ==<br />
<br />
* Рабочая среда KDE SC: Plasma 5.10.4, Frameworks 5.37.0, Applications 17.04.3.<br />
* Ядро Linux 4.9.50<br />
* Драверы NVIDIA 375.82, 340.102, 304.135<br />
* Mesa 17.1.9<br />
* Qt 5.7.1<br />
* Веб-браузер Firefox ESR 52.3<br />
* Cреда запуска win32-приложений WINE 2.16<br />
* Редактор растровой графики GIMP 2.8.20<br />
* Редактор векторной графики Inkscape 0.92.1<br />
* Виртуальная машина VirtualBox 5.1.24<br />
* Исправлено сохранение сессии в LiveCD.<br />
* Исправлен запуск установки на различных видеокартах.<br />
* Больше программ портировано на KF5.<br />
* Произведена адаптация к экранам высокого разрешения.<br />
* Исправлена загрузка с LVM.<br />
<br />
== Изменения версии 8.1 ==<br />
<br />
* Рабочая среда KDE SC: Plasma 5.8.3, Frameworks 5.28.0, Applications 16.08.01 .<br />
* Ядро Linux 4.4.34<br />
* Драйверы NVIDIA 367.57, 340.98, 304.131<br />
* Офисный пакет LibreOffice 5.2<br />
* Веб-браузер Firefox ESR 45.5.0<br />
* Cреда запуска win32-приложений WINE 1.9.23<br />
* Редактор растровой графики GIMP 2.8.16<br />
* Cистема вёрстки Scribus 1.4.5<br />
* Редактор векторной графики Inkscape 0.91<br />
* 3D-редактор Blender 2.77a<br />
* VoIP-клиент Ring 2.3.0<br />
* Виртуальная машина VirtualBox 5.1.6<br />
* Клиенты службы каталогов, облачных систем хранения данных, мониторинга и резервного копирования<br />
<br />
<div id="hardware"></div><br />
<br />
== Требования к оборудованию ==<br />
Для платформ i586, x86_64:<br />
* Минимум 512 МБ ОЗУ. Рекомендуется от 2ГБ.<br />
* Минимум 20 ГБ свободного места на жестком диске.<br />
* Видеокарта с 3D-ускорением: NVIDIA >= GF 6000 (optimus поддерживается), Intel (кроме i8xx, Poulsbo), AMD/ATI. Рекомендуется NVIDIA >= GT 400.<br />
<br />
== Форматы поставки ==<br />
Дистрибутив поставляется для архитектур i586 и x86_64 в двух вариантах:<br />
* образ DVD с возможностью загрузки в режимах: установка, LiveCD/восстановление;<br />
* образ DVD с возможностью загрузки в режиме LiveCD с сохранением сессий;<br />
<br />
Все образы являются гибридными, то есть пригодны для записи как на DVD-диски, так и на USB-флеш-диски.<br />
Запись на USB-флеш диски осуществляется утилитой dd (на весь диск целиком, а не на раздел, то есть, например, не на /dev/sdb1, а на '''/dev/sdb''') в соответствии с [[Write|инструкцией по записи образов.]]<br />
<br />
== Скачать образы ==<br />
BitTorrent:<br />
* http://torrent.altlinux.org<br />
<br />
Для перечисленных ниже ресурсов доступ по ftp:// и http:// взаимозаменяем:<br />
* http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/images/kworkstation/ (основной сервер)<br />
* http://mirror.yandex.ru/altlinux/p8/images/kworkstation/<br />
<br />
<br />
{|class="standard"<br />
!Образ<br />
!Описание<br />
!Размер<br />
!Контрольная сумма MD5<br />
|-<br />
|[[Файл:DVD.png]][[Файл:Flash.png]] <tt>[http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/images/kworkstation/alt-kworkstation-8.3-install-x86_64.iso alt-kworkstation-8.3-install-x86_64.iso]</tt><br />
|Гибридный установочный DVD+LiveCD (x86_64), [http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/images/kworkstation/alt-kworkstation-8.3-install-x86_64.iso.txt список файлов]<br />
|align="right"|<tt>3,7 ГБ</tt><br />
|<tt>d718a9b63fd5eda29ba2dad718485bf3</tt><br />
|-<br />
|[[Файл:DVD.png]][[Файл:Flash.png]] <tt>[http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/images/kworkstation/alt-kworkstation-8.3-install-i586.iso alt-kworkstation-8.3-install-i586.iso]</tt><br />
|Гибридный установочный DVD+LiveCD (i586), [http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/images/kworkstation/alt-kworkstation-8.3-install-i586.iso.txt список файлов]<br />
|align="right"|<tt>3,5 ГБ</tt><br />
|<tt>6cf2173397f3dd820f5e8ccc65964fd3</tt><br />
|-<br />
|[[Файл:DVD.png]][[Файл:Flash.png]] <tt>[http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/images/kworkstation/alt-kworkstation-8.3-live-x86_64.iso alt-kworkstation-8.3-live-x86_64.iso]</tt><br />
|Гибридный LiveCD (x86_64)<br />
|align="right"|<tt>2,4 ГБ</tt><br />
|<tt>5e3ad3328aebcfbcbd675f1232113a65</tt><br />
|-<br />
|[[Файл:DVD.png]][[Файл:Flash.png]] <tt>[http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/images/kworkstation/alt-kworkstation-8.3-live-i586.iso alt-kworkstation-8.3-live-i586.iso]</tt><br />
|Гибридный LiveCD (i586)<br />
|align="right"|<tt>2,3 ГБ</tt><br />
|<tt>8bd2e361357795e9895659c33cdfbc05</tt><br />
|-<br />
|}<br />
<br />
{{Attention|UNetbootin и UltraISO портят загрузку, штатные способы записи гибридных образов на CD/DVD и USB Flash описаны [[write|в инструкции]].}}<br />
<br />
== Известные проблемы ==<br />
<br />
''Проблема'': Установка зависает на этапе "Сохранение настроек". При этом присутствует видеоадаптер NVIDIA. <br />
<blockquote>''Решение'': При установке добавить [https://www.altlinux.org/%D0%A4%D0%B0%D0%B9%D0%BB:KWorkstation-8-install-start.png параметр загрузки] modprobe.blacklist=nouveau .</blockquote><br />
<br />
''Проблема'': После установки получается неправильный часовой пояс.<br />
<blockquote>''Решение'': Произвести дополнительную настройку времени. Подробности в [http://bugs.altlinux.org/32510 BUG#32510].</blockquote><br />
<br />
''Проблема'': После настройки не печатает принтер производителя HP. <br />
<blockquote>''Решение'': Удалите настройки этого принтера и воспользуйтесь утилитами '''hp-setup''', '''hp-testpage''' и '''hp-plugin'''.</blockquote><br />
<br />
''Проблема'': Текст выглядит недостаточно чётким.<br />
<blockquote>''Решение'': Убедитесь, что вывод от команды '''xdpyinfo | grep dimensions''' соответствует действительности.</blockquote><br />
<blockquote>''Решение'': В файле '''~/.config/kdeglobals''' удалите всю секцию '''KScreen'''.</blockquote><br />
<br />
{{#dpl:<br />
|category = Relnotes/81<br />
|order = ascending}}<br />
<br />
== Советы ==<br />
{{#dpl:<br />
|category = CookBook/8/KDE<br />
|order = ascending}}<br />
<br />
== Снимки экрана ==<br />
<br />
<gallery perrow="4"><br />
Image:KWorkstation-8-install-start.png|Меню загрузочного диска<br />
Image:KWorkstation-8-desktop.png|Запущенная система<br />
Image:KWorkstation-8-lvm-1.png|Выбор установки на LVM<br />
Image:KWorkstation-8-lvm-2.png|Разметка дисков для LVM<br />
Image:KWorkstation-8-ram.png|Слежение за оперативной памятью<br />
Image:KWorkstation-8-libreoffice.png|Поддержка KDE5 в LibreOffice<br />
</gallery><br />
<br />
<br />
{{Category navigation|title=Releases/81|category=Releases/81|sortkey={{SUBPAGENAME}}}}<br />
{{Category navigation|title=Дистрибутивы|category=Дистрибутивы}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%90%D0%BB%D1%8C%D1%82_%D0%A0%D0%B0%D0%B1%D0%BE%D1%87%D0%B0%D1%8F_%D1%81%D1%82%D0%B0%D0%BD%D1%86%D0%B8%D1%8F_%D0%9A_8&diff=44738Альт Рабочая станция К 82019-05-21T11:17:27Z<p>AntonFarygin: /* Изменения версии 8.3 */</p>
<hr />
<div>== Продукт ==<br />
Альт Рабочая станция К 8 — многофункциональное решение для корпоративных рабочих станций, основанное на среде KDE 5.<br />
Рабочая станция К 8 интегрирована с сервером Альт Сервер 8.<br />
<br />
== Платформа ==<br />
[[Branches/p8|Восьмая платформа]]<br />
<br />
=== Основные преимущества ===<br />
* Графическая рабочая среда KDE5 — мощное и универсальное решение для начинающих и искушенных пользователей.<br />
* Широкий выбор различных программ для профессиональной и домашней работы в сети Интернет, с документами, со сложной графикой и анимацией, для обработки звука и видео и образования.<br />
* Подключение к инфраструктуре и различным сервисам сети подразделения и предприятия.<br />
* Включает приложения для отдыха и развлечений: вы можете поиграть сами и с детьми, посмотреть фильмы и послушать музыку, пообщаться с друзьями в социальных сетях, форумах и чатах.<br />
* Привычное оформление "из коробки", готовое к использованию сразу после установки.<br />
<br />
== Сроки выпуска и поддержка ==<br />
Выпуск 8.1 — '''23 ноября 2016 года'''<br />
Срок окончания поддержки (если иное не предусмотрено условиями поставки): '''16 декабря 2019 года''', но не ранее полугода с момента выпуска Альт 9.<br />
<br />
== Изменения версии 8.3 ==<br />
<br />
Примечания:<br />
* В VirtualBox некорректно работает режим EFI. Не используйте его.<br />
Добавлено:<br />
* Возможность установки без аппаратной клавиатуры.<br />
* Установка на LVM и шифрованные разделы LUKS.<br />
* Сервис, облегчающий генерацию энтропии для случайных чисел rngd, включенный по умолчанию.<br />
* Установка на тома LVM по умолчанию.<br />
* Сервис синхронизации времени OpenNTPD заменён на chrony.<br />
* Эксперементальный модуль KDE для слежения за заполненностью оперативной пямяти.<br />
* Драйвер Wi-Fi для Realtek RTL8723DE.<br />
* Инструмент управления разделами жёсткого диска GParted заменён на KDE Partition Manager.<br />
* Поддержка установки на системы с 32-хбитным EFI.<br />
* Поддержка виртуализации - включение необходимых сервисов при установке внутри виртуальной машины.<br />
* Автоматическое подключение локального хранилища паролей KDE.<br />
* Поддержка системы протоколирования работы audit в pam_passwdqc.<br />
* Уведомление о заканчивающемся сроке действия пароля в инструменте обновления доменного тикета krb5-ticket-watcher.<br />
* Создание шифрованных носителей в утилите форматирования USB носителей quick-usb-formatter.<br />
* Добавлены шрифты google-crosextra-caladea и google-crosextra-carlito.<br />
* Реализованы всплывающие подсказки пунктов главного меню.<br />
* Добавлено автоматическое обновление микрокода CPU.<br />
* Поддержка NVIDIA OpenCL.<br />
* Возможность смены пароля с истекшим сроком действия при входе в систему, как для локального так и для доменного пользователя.<br />
Обновлено:<br />
* Ядро Linux 4.19.33 .<br />
* Mesa 18.0.5 .<br />
* xorg-server 1.19.7 с драйверами.<br />
* LibreOffice 6.1 с файловыми диалогами KDE5.<br />
* Драйверы NVIDIA 410.104, 390.116, 340.107, 304.137 .<br />
* KDE SC: Frameworks 5.48.0, Plasma 5.12.8, Applications 18.04.3 .<br />
* Среда запуска win32-приложений WINE 4.2 .<br />
* Qt 5.9.6 .<br />
Исправлено:<br />
* Существенно улучшены переводы справки и интерфейса приложений на русский язык нашей командой переводчиков.<br />
* Ошибка при отсутствии свободного места при установке на LVM.<br />
* Подключение существующих NTFS-разделов при установке.<br />
* Загрузка Live-образов большого размера в 32-хбитных сборках.<br />
* Автоустановка на LVM.<br />
* Поиск по закладкам в krunner (ALT+F2 в KDE) .<br />
* Некорректное создание папок на рабочем столе.<br />
* Некорректное поведение значков рабочего стола при перетаскивании.<br />
* Падение Plasma при настройке виджета Комиксы.<br />
* Некоректное поведение настроек виджетов мониторинга.<br />
* Исправлена установка в режиме EFI (при этом вскрылась проблема в реализации EFI в VirtualBox).<br />
* Зависание Plasma при нарушении связи со смонтированными сетевыми файловыми системами.<br />
* Навигация по разделам справки khelpcenter.<br />
* Увеличен размер окна для ввода пароля к wifi.<br />
* Невозможность прочесть усеченные элементы выпадающего списка krunner .<br />
* Настройка виджета Погода.<br />
* Работа виджета Словарь.<br />
* Предпросмотр языковых настроек локали при включении "настроить форматы отдельно".<br />
* Чрезмерное потребление памяти в Okular.<br />
* Отправка документа по электронной почте из LibreOffice при использовании Thunderbird.<br />
* Работа Bumblebee (NVIDIA Optimus).<br />
* Запуск установки на некоторых видеокартах Intel.<br />
* Улучшена поддержка встроенной графики Intel и AMD (Ryzen) (добавлена поддержка современных чипсетов, актуальных на момент выхода дистрибутива)<br />
* Улучшено определение сменных загрузочных носителей и сетевых карт при установке и в LiveCD.<br />
<br />
== Изменения версии 8.2 ==<br />
<br />
* Рабочая среда KDE SC: Plasma 5.10.4, Frameworks 5.37.0, Applications 17.04.3.<br />
* Ядро Linux 4.9.50<br />
* Драверы NVIDIA 375.82, 340.102, 304.135<br />
* Mesa 17.1.9<br />
* Qt 5.7.1<br />
* Веб-браузер Firefox ESR 52.3<br />
* Cреда запуска win32-приложений WINE 2.16<br />
* Редактор растровой графики GIMP 2.8.20<br />
* Редактор векторной графики Inkscape 0.92.1<br />
* Виртуальная машина VirtualBox 5.1.24<br />
* Исправлено сохранение сессии в LiveCD.<br />
* Исправлен запуск установки на различных видеокартах.<br />
* Больше программ портировано на KF5.<br />
* Произведена адаптация к экранам высокого разрешения.<br />
* Исправлена загрузка с LVM.<br />
<br />
== Изменения версии 8.1 ==<br />
<br />
* Рабочая среда KDE SC: Plasma 5.8.3, Frameworks 5.28.0, Applications 16.08.01 .<br />
* Ядро Linux 4.4.34<br />
* Драйверы NVIDIA 367.57, 340.98, 304.131<br />
* Офисный пакет LibreOffice 5.2<br />
* Веб-браузер Firefox ESR 45.5.0<br />
* Cреда запуска win32-приложений WINE 1.9.23<br />
* Редактор растровой графики GIMP 2.8.16<br />
* Cистема вёрстки Scribus 1.4.5<br />
* Редактор векторной графики Inkscape 0.91<br />
* 3D-редактор Blender 2.77a<br />
* VoIP-клиент Ring 2.3.0<br />
* Виртуальная машина VirtualBox 5.1.6<br />
* Клиенты службы каталогов, облачных систем хранения данных, мониторинга и резервного копирования<br />
<br />
<div id="hardware"></div><br />
<br />
== Требования к оборудованию ==<br />
Для платформ i586, x86_64:<br />
* Минимум 512 МБ ОЗУ. Рекомендуется от 2ГБ.<br />
* Минимум 20 ГБ свободного места на жестком диске.<br />
* Видеокарта с 3D-ускорением: NVIDIA >= GF 6000 (optimus поддерживается), Intel (кроме i8xx, Poulsbo), AMD/ATI. Рекомендуется NVIDIA >= GT 400.<br />
<br />
== Форматы поставки ==<br />
Дистрибутив поставляется для архитектур i586 и x86_64 в двух вариантах:<br />
* образ DVD с возможностью загрузки в режимах: установка, LiveCD/восстановление;<br />
* образ DVD с возможностью загрузки в режиме LiveCD с сохранением сессий;<br />
<br />
Все образы являются гибридными, то есть пригодны для записи как на DVD-диски, так и на USB-флеш-диски.<br />
Запись на USB-флеш диски осуществляется утилитой dd (на весь диск целиком, а не на раздел, то есть, например, не на /dev/sdb1, а на '''/dev/sdb''') в соответствии с [[Write|инструкцией по записи образов.]]<br />
<br />
== Скачать образы ==<br />
BitTorrent:<br />
* http://torrent.altlinux.org<br />
<br />
Для перечисленных ниже ресурсов доступ по ftp:// и http:// взаимозаменяем:<br />
* http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/images/kworkstation/ (основной сервер)<br />
* http://mirror.yandex.ru/altlinux/p8/images/kworkstation/<br />
<br />
<br />
{|class="standard"<br />
!Образ<br />
!Описание<br />
!Размер<br />
!Контрольная сумма MD5<br />
|-<br />
|[[Файл:DVD.png]][[Файл:Flash.png]] <tt>[http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/images/kworkstation/alt-kworkstation-8.3-install-x86_64.iso alt-kworkstation-8.3-install-x86_64.iso]</tt><br />
|Гибридный установочный DVD+LiveCD (x86_64), [http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/images/kworkstation/alt-kworkstation-8.3-install-x86_64.iso.txt список файлов]<br />
|align="right"|<tt>3,7 ГБ</tt><br />
|<tt>d718a9b63fd5eda29ba2dad718485bf3</tt><br />
|-<br />
|[[Файл:DVD.png]][[Файл:Flash.png]] <tt>[http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/images/kworkstation/alt-kworkstation-8.3-install-i586.iso alt-kworkstation-8.3-install-i586.iso]</tt><br />
|Гибридный установочный DVD+LiveCD (i586), [http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/images/kworkstation/alt-kworkstation-8.3-install-i586.iso.txt список файлов]<br />
|align="right"|<tt>3,5 ГБ</tt><br />
|<tt>6cf2173397f3dd820f5e8ccc65964fd3</tt><br />
|-<br />
|[[Файл:DVD.png]][[Файл:Flash.png]] <tt>[http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/images/kworkstation/alt-kworkstation-8.3-live-x86_64.iso alt-kworkstation-8.3-live-x86_64.iso]</tt><br />
|Гибридный LiveCD (x86_64)<br />
|align="right"|<tt>2,4 ГБ</tt><br />
|<tt>5e3ad3328aebcfbcbd675f1232113a65</tt><br />
|-<br />
|[[Файл:DVD.png]][[Файл:Flash.png]] <tt>[http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/images/kworkstation/alt-kworkstation-8.3-live-i586.iso alt-kworkstation-8.3-live-i586.iso]</tt><br />
|Гибридный LiveCD (i586)<br />
|align="right"|<tt>2,3 ГБ</tt><br />
|<tt>8bd2e361357795e9895659c33cdfbc05</tt><br />
|-<br />
|}<br />
<br />
{{Attention|UNetbootin и UltraISO портят загрузку, штатные способы записи гибридных образов на CD/DVD и USB Flash описаны [[write|в инструкции]].}}<br />
<br />
== Известные проблемы ==<br />
<br />
''Проблема'': Установка зависает на этапе "Сохранение настроек". При этом присутствует видеоадаптер NVIDIA. <br />
<blockquote>''Решение'': При установке добавить [https://www.altlinux.org/%D0%A4%D0%B0%D0%B9%D0%BB:KWorkstation-8-install-start.png параметр загрузки] modprobe.blacklist=nouveau .</blockquote><br />
<br />
''Проблема'': После установки получается неправильный часовой пояс.<br />
<blockquote>''Решение'': Произвести дополнительную настройку времени. Подробности в [http://bugs.altlinux.org/32510 BUG#32510].</blockquote><br />
<br />
''Проблема'': После настройки не печатает принтер производителя HP. <br />
<blockquote>''Решение'': Удалите настройки этого принтера и воспользуйтесь утилитами '''hp-setup''', '''hp-testpage''' и '''hp-plugin'''.</blockquote><br />
<br />
''Проблема'': Текст выглядит недостаточно чётким.<br />
<blockquote>''Решение'': Убедитесь, что вывод от команды '''xdpyinfo | grep dimensions''' соответствует действительности.</blockquote><br />
<blockquote>''Решение'': В файле '''~/.config/kdeglobals''' удалите всю секцию '''KScreen'''.</blockquote><br />
<br />
{{#dpl:<br />
|category = Relnotes/81<br />
|order = ascending}}<br />
<br />
== Советы ==<br />
{{#dpl:<br />
|category = CookBook/8/KDE<br />
|order = ascending}}<br />
<br />
== Снимки экрана ==<br />
<br />
<gallery perrow="4"><br />
Image:KWorkstation-8-install-start.png|Меню загрузочного диска<br />
Image:KWorkstation-8-desktop.png|Запущенная система<br />
Image:KWorkstation-8-lvm-1.png|Выбор установки на LVM<br />
Image:KWorkstation-8-lvm-2.png|Разметка дисков для LVM<br />
Image:KWorkstation-8-ram.png|Слежение за оперативной памятью<br />
Image:KWorkstation-8-libreoffice.png|Поддержка KDE5 в LibreOffice<br />
</gallery><br />
<br />
<br />
{{Category navigation|title=Releases/81|category=Releases/81|sortkey={{SUBPAGENAME}}}}<br />
{{Category navigation|title=Дистрибутивы|category=Дистрибутивы}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=PVE&diff=44725PVE2019-05-20T04:05:35Z<p>AntonFarygin: </p>
<hr />
<div>= Что это такое =<br />
Proxmox Virtual Environment (PVE) — средство управления виртуальными окружениями на базе гипервизора [[ruwp:KVM|KVM]] и системы контейнерной изоляции [[ruwp:LXC|LXC]]. Строго говоря, PVE это не система виртуализации, а инструментарий управления средой, в которой выполняются виртуальные окружения KVM и LXC. Основными компонентами среды являются:<br />
<br />
* физические серверы, на которых выполняются процессы гипервизора KVM, и процессы, работающие в контейнерах LXC;<br />
* хранилища данных, в которых хранятся образы установочных дисков, образы дисков виртуальных машин KVM и файлы, доступные из контейнеров LXC;<br />
* виртуальные сетевые коммутаторы, к которым подключаются сетевые интерфейсы виртуальных окружений.<br />
<br />
= Как это устроено =<br />
Собственно PVE состоит из веб-интерфейса, распределённого хранилища данных конфигурации виртуальных окружений, а также утилит конфигурирования, работающих в командной строке. Все эти инструменты предназначены только для управления средой выполнения виртуальных окружений. За формирование среды отвечают компоненты системы, не входящие непосредственно в состав PVE. В первую очередь это сетевая и дисковая подсистемы, а также механизмы аутентификации.<br />
<br />
== Веб-интерфейс ==<br />
Веб-интерфейс пользователя PVE предназначен для решения следующих задач:<br />
<br />
* создание, удаление, настройка виртуальных окружений;<br />
* управление физическими серверами;<br />
* мониторинг активности виртуальных окружений и использования ресурсов среды;<br />
* фиксация состояний (snapshot-ы), создание резервных копий и шаблонов виртуальных окружений, восстановление виртуальных окружений из резервных копий.<br />
<br />
Кроме решения пользовательских задач, веб-интерфейс PVE можно использовать ещё и для встраивания в интегрированные системы управления — например, в панели управления хостингом. Для этого он имеет развитый RESTful API с JSON в качестве основного формата данных.<br />
<br />
Для аутентификации пользователей веб-интерфейса можно использовать как собственные механизмы PVE, так и PAM. Использование PAM даёт возможность, например, интегрировать PVE в домен аутентификации.<br />
<br />
== Хранилище данных ==<br />
В случае локальной установки PVE для размещения данных виртуальных окружений можно дополнительно ничего не настраивать и использовать локальную файловую систему сервера. Но в случае кластера из нескольких серверов имеет смысл настроить сетевую или распределённую сетевую файловую систему, обеспечивающую параллельный доступ к файлам со всех серверов, на которых выполняются процессы виртуальных окружений. В качестве таких файловых систем могут выступать, например, [[ruwp:NFS|NFS]] или [[ruwp:CEPH|CEPH]].<br />
==== Подключение общего хранилища iSCSI (Multipath) с использованием LVM ====<br />
Настройка iSCSI-target на базе ALT подробно описана в [[GFS2 на iSCSI с Multipath#.D0.9D.D0.B0.D1.81.D1.82.D1.80.D0.BE.D0.B9.D0.BA.D0.B0_iSCSI_target|этой статье]].<br><br />
{{Attention|iSCSI initiator настраивается средствами ALT PVE.<br> Сервис iscsid запускается средствами ALT PVE и не должен присутствовать в атозагрузке}}<br />
Исходные данные:<br><br />
* Настроенный кластер ALT PVE<br />
* Настроенный iSCSI target<br />
Для добавления iSCSI устройства надо зайти в web-интерфейс ALT PVE в раздел Datacenter -> Storage -> Add -> iSCSI:<br><br />
[[Файл:Add iSCSI.png|Добавление iSCSI-устройства]]<br />
*ID: Имя добавляемого устройства, может быть любым, но изменить его позже нельзя<br />
*Portal: Адрес iSCSI сервера<br />
*Target: Выпадающий список ресурсов, отдаваемых iSCSI сервером<br />
*Nodes: Каким нодам будет доступно данное хранилище<br />
*Enable: Вкл/Выкл хранилище<br />
*Use LUNs directly: Использование LUN напрямую, галочку надо снять<br />
Ту же процедуру надо проделать для второго адреса iSCSI сервера.<br><br />
После этого на всех нодах появятся два блочных устройства.<br><br />
Далее необходимо настроить Multipath по этой [[GFS2 на iSCSI с Multipath#.D0.9D.D0.B0.D1.81.D1.82.D1.80.D0.BE.D0.B9.D0.BA.D0.B0_Multipath|инструкции]]<br><br />
Далее переходим в консоль на любой ноде для настройки LVM.<br><br />
Для корректной работы LVM и Multipath говорим LVM не сканировать наши iSCSI-диски (sd*):<br><br />
В файл {{path|/etc/lvm/lvm.conf}} добавляем:<br />
<pre>devices {<br />
...<br />
filter = [ "r|/dev/sd|" ]<br />
...<br />
}</pre><br />
Инициализируем блочные устройства для использования в LVM:<br />
<pre># pvcreate /dev/mapper/mpatha</pre><br />
Создаём группу томов 'sharedsv':<br />
<pre># vgcreate sharedsv /dev/mapper/mpatha</pre><br />
Далее переходим в web-интерфейс ALT PVE в раздел Datacenter -> Storage -> Add -> LVM:<br><br />
[[Файл:ALT PVE add LVM.png]]<br />
*ID: Имя добавляемого устройства, может быть любым, но изменить его позже нельзя<br />
*Base Storage: Выбираем 'Existing volume groups'<br />
*Volume group: Выпадающий список LVM разделов, выбираем созданный нами 'sharedsv'<br />
*Content: Что разрешено хранить на данном хранилище<br />
*Nodes: Каким нодам будет доступно данное хранилище<br />
*Enable: Вкл/Выкл хранилище<br />
*Shared: Делает хранилище доступным для всех нод<br />
При таком подключении LVM хранилище общедоступно, виртуальные машины могут хранить на нем образы дисков и доступна Online-миграция виртуальных машин между нодами.<br />
<br />
== Сетевая подсистема ==<br />
В отличие от хранилища данных, сетевая подсистема требует специальной настройки даже в случае локальной установки PVE. Это обусловлено тем, что сетевые интерфейсы виртуальных окружений должны подключаться к какому-то виртуальному же устройству, обеспечивающему соединение с общей сетью передачи данных. Обычно в качестве такого устройства выступает Ethernet-мост.<br />
<br />
= Установка и настройка PVE =<br />
В качестве сервера для развёртывания PVE нужно использовать серверверный дистрибутив Альт на базе 8-й платформы и доустановить необходимые пакеты штатным способом любым штатным способом ({{cmd|apt-get}}, {{cmd|aptitude}}, {{cmd|synaptic}}) установить пакет {{cmd|pve-manager}}. Все необходимые компоненты при этом будут установлены автоматически. Также следует убедиться в том, что пакет systemd обновлён до версии, находящейся в репозитории P8.<br />
<br />
Рассмотрим настройку кластера PVE. Локальную установку будем считать частным случаем кластера из одного узла.<br />
<br />
== Настройка сетевой подсистемы ==<br />
: Если в файле options интерфейса не задан TYPE=, pve-manager завершается с ошибкой<br />
<br />
Сначала на всех узлах кластера настроим Ethernet-мост в соответствии с [[Etcnet#Настройка Ethernet-моста|руководством]]:<br />
<br />
<pre><br />
# mkdir /etc/net/ifaces/vmbr0<br />
# mv /etc/net/ifaces/eth0/* /etc/net/ifaces/vmbr0/<br />
# cp /etc/net/ifaces/vmbr0/options /etc/net/ifaces/eth0/<br />
# cat <<EOF > /etc/net/ifaces/vmbr0/options<br />
BOOTPROTO=static<br />
CONFIG_WIRELESS=no<br />
CONFIG_IPV4=yes<br />
HOST='eth0'<br />
ONBOOT=yes<br />
TYPE=bri<br />
EOF<br />
# cat <<EOF > /etc/net/ifaces/vmbr0/brctl<br />
stp AUTO off<br />
setfd AUTO 0<br />
EOF<br />
</pre><br />
<br />
Имя интерфейса, обозначенного здесь как eth0, следует указать в соответствии с реальной конфигурацией сервера.<br />
<br />
При установленных пакетах {{pkg|alterator-net-eth}} и {{pkg|alterator-net-bridge}} вместо всего этого можно просто воспользоваться web-интерфейсом.<br />
<br />
Основная часть разработки PVE ведётся под ОС Debian, и в связи с этим в свежих версиях PVE иногда возникают забавные нюансы. Так в текущей версии конфигурация Ethernet-мостов и информация о временны́х зонах считывается из специфичных для Debian и его производных конфигурационных файлов {{path|/etc/network/interfaces}} и {{path|/etc/timezone}}. Поэтому, пока ошибка не исправлена, настройки придётся продублировать:<br />
<br />
<pre><br />
# mkdir /etc/network<br />
# printf "\nauto vmbr0\n\tiface vmbr0 inet static\n\taddress 10.0.0.251\n\tnetmask 255.255.255.0\n\tgateway 10.0.0.1\n\tbridge_ports eth0\n\tbridge_stp off\n\tbridge_fd 0\n" >> /etc/network/interfaces<br />
# . /etc/sysconfig/clock<br />
# echo $ZONE > /etc/timezone<br />
# ln -sf /usr/share/zoneinfo/$ZONE /etc/localtime<br />
</pre><br />
<br />
Далее необходимо обеспечить взаимно однозначное прямое и обратное преобразование имён для всех узлов кластера. Крайне желательно использовать DNS, но в крайнем случае можно обойтись соответствующими записями в локальных файлах {{path|/etc/hosts}}:<br />
<br />
<pre><br />
# echo "10.0.0.251 pve1.localdomain pve1" >> /etc/hosts<br />
# echo "10.0.0.252 pve2.localdomain pve2" >> /etc/hosts<br />
</pre><br />
<br />
При этом имя машины '''НЕ''' должно присутствовать в файле /etc/hosts, разрешающимся в 127.0.0.1!<br />
<br />
== Настройка взаимодействия компонентов PVE ==<br />
В качестве транспорта для передачи команд между узлами кластера применяется протокол SSH. Если мы настраиваем локальную установку PVE, ничего специального делать не нужно, а если узлов в кластере будет несколько, необходимо на каждом узле разрешить передачу переменной окружения {{path|LC_PVE_TICKET}}:<br />
<br />
<pre><br />
# N=$(($(sed -n '/^AcceptEnv/{=}' /etc/openssh/sshd_config | tail -1) + 1)); sed -i "${N}i AcceptEnv LC_PVE_TICKET\n" /etc/openssh/sshd_config<br />
# N=$(($(sed -n '/^[[:space:]]*SendEnv/{=}' /etc/openssh/ssh_config | tail -1) + 1)); sed -i "${N}i \ \ \ \ SendEnv LC_PVE_TICKET\n" /etc/openssh/ssh_config<br />
# systemctl restart sshd<br />
</pre><br />
<br />
Кроме того, для передачи команд между узлами кластера необходимо обеспечить взаимную беспарольную аутентификацию пользователя root. Это можно сделать вручную, а можно при добавлении нового узла в кластер PVE разрешить на «ведущем» узле вход пользователя root по паролю и ввести пароль. После этого взаимная беспарольная аутентификация root будет настроена автоматически утилитами PVE, и вход root по паролю можно будет снова отключить.<br />
<br />
Важно понимать, что в сконфигурированном кластере PVE все узлы равноправны. «Ведущим», «головным» и так далее один из узлов становится только в момент добавления в кластер нового узла. После добавления новый узел может стать таким же ведущим при проведении следующей процедуры добавления очередного узла в кластер.<br />
<br />
Теперь осталось настроить ещё два компонента системы, которые утилиты PVE пока не могут полностью автоматически настроить при запуске кластера. Это демон {{cmd|rrdcached}}, отвечающий за хранение данных мониторинга активности подсистем кластера, и {{cmd|corosync}} — комплекс ПО, обеспечивающий в пределах кластера элементы высокой доступности.<br />
<br />
<pre><br />
# cp /usr/share/doc/pve-cluster/rrdcached.sysconfig /etc/sysconfig/rrdcached<br />
# mkdir -p /var/lib/rrdcached/{db,journal}<br />
# rm -f /etc/corosync/corosync.conf<br />
</pre><br />
<br />
Конфигурационный файл {{cmd|corosync}} после этого будет создан автоматически при инициализации кластера PVE.<br />
<br />
== Запуск служб кластера ==<br />
Запускаем службы кластера и настраиваем их автоматический запуск при старте узла:<br />
<br />
<pre><br />
# systemctl start syslogd ntpd rrdcached ksmtuned crond lxcfs openvswitch nfs-client.target<br />
# systemctl enable syslogd ntpd rrdcached ksmtuned crond lxcfs openvswitch nfs-client.target<br />
</pre><br />
<br />
Далее, на «головном» (см. выше) узле кластера выполняем команды собственно инициализации конкретного кластера PVE, в данном случае — «mypve»:<br />
<br />
<pre><br />
# systemctl start pve-cluster<br />
# pvecm create mypve<br />
</pre><br />
<br />
На «подчинённых» (см. выше) узлах:<br />
<br />
<pre><br />
# systemctl start corosync pve-cluster<br />
# pvecm add <головной_узел><br />
</pre><br />
<br />
Далее, запускаем остальные службы и добавляем их в список служб, запускаемых при старте узла:<br />
<br />
<pre><br />
# systemctl start lxc lxc-net lxc-monitord pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy<br />
# systemctl enable corosync lxc lxc-net lxc-monitord pve-cluster pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy pve-guests<br />
</pre><br />
<br />
Дальнейшие настройки кластера удобно делать через веб интерфейс.<br />
<br />
[[Файл:Pve-first-login.png|900px|Экран входа пользователя в веб-интерфейс PVE]]<br />
<br />
= Применение PVE =<br />
<br />
В ходе работы с веб-интерфейсом PVE оператору приходится иметь дело со следующими основными объектами: физическими узлами, виртуальными окружениями, хранилищами данных и субъектами авторизации. Так как PVE является средством управления виртуальными окружениями, рассматривать взаимодействие компонентов мы будем относительно них. Виртуальные окружения под управлением PVE бывают двух типов: полностью виртуализированные, управляемые гипервизором kvm, и изолированные окружения выполняющиеся непосредственно на основном ядре ОС физического узла. Первые в терминах PVE называются VM (виртуальные машины), а вторые — CT (контейнеры, ConTainers). Начнём с VM.<br />
<br />
== VM: виртуальные машины kvm ==<br />
<br />
Виртуальные машины, управляемые гипервизором kvm, с точки зрения операционной системы физического узла, на котором они выполняются, представляют собой один процесс гипервизора kvm. Они взаимодействуют с физическим оборудованием не напрямую, а только через гипервизор. Всё оборудование, которое доступно операционной системе внутри виртуальной машины, включая процессор и память, является виртуальным. Даже виртуальная сетевая карта подключается виртуальным кабелем к виртуальному коммутатору. Дисковые контроллеры тоже являются виртуальными, а дисковые накопители обычно представляют собой файлы на файловой системе физического узла, на котором выполняется процесс гипервизора.<br />
<br />
=== Хранилища данных ===<br />
<br />
В случае, когда PVE управляет не одним физическим узлом, а кластером физических узлов, должна обеспечиваться возможность миграции VM с одного физического узла на другой. Миграция представляет собой заморозку состояния VM на одном узле, перенос данных и конфигурации на другой узел, и разморозку состояния VM на новом месте. Так как виртуальные дисковые накопители VM могут занимать значительный объём, удобно в пределах среды виртуализации PVE оперировать не локальными файловыми системами физических узлов, а хранилищами данных, доступными со всех узлов кластера. Кроме того, очень удобно, когда образы загрузочных инсталляционных дисков ОС, которые мы развёртываем на виртуальных машинах, также были доступны сразу на всех узлах кластера. Чтобы не приходилось копировать сотни мегабайт файлов .iso с машины на машину, когда нам захочется развернуть несколько однотипных VM на разных физических узлах.<br />
<br />
Хранилищами данных удобно управлять через веб-интерфейс. В качестве бэкенда хранилищ PVE может использовать:<br />
<br />
* сетевые файловые системы, в том числе распределённые: NFS, CEPH, GlusterFS;<br />
* локальные системы управления дисковыми томами: LVM, ZFS;<br />
* удалённые (iSCSI) и локальные дисковые тома;<br />
* локальные дисковые каталоги.<br />
<br />
Сетевые файловые системы подходят для организации распределённых хранилищ данных, доступных со всех узлов кластера. Остальные могут использоваться только в качестве локальных хранилищ, доступных в пределах одного узла.<br />
<br />
[[Файл:Pve-storage-types.png|900px|Выбор бэкенда хранилища данных]]<br />
<br />
При создании каждому хранилищу данных присваивается роль или набор ролей. Например, хранение контейнеров, образов виртуальных дисков, файлов .iso и так далее. Список возможных ролей зависит от бэкенда хранилища. Например, для NFS или каталога локальной файловой системы доступны любые роли или наборы ролей.<br />
<br />
[[Файл:Pve-storage-roles.png|900px|Выбор ролей хранилища данных]]<br />
<br />
Сразу после инициализации кластера в пределах каждого из узлов нам доступно одно локальное хранилище данных. Этого уже вполне достаточно для начала работы.<br />
<br />
=== Создание виртуальной машины ===<br />
<br />
Прежде чем создать в интерфейсе PVE виртуальную машину (VM), необходимо определиться со следующими моментами:<br />
<br />
* откуда будет загружен инсталлятор ОС, которую мы будем устанавливать внутрь виртуальной машины;<br />
* на каком физическом узле будет выполняться процесс гипервизора kvm;<br />
* на каком хранилище данных будут располагаться образы дисков виртуальной машины.<br />
<br />
Все остальные параметры VM относятся к конфигурации виртуального компьютера и могут быть определены по ходу процесса создания VM.<br />
<br />
Так как хранилища данных у нас пока только локальные, определимся с физическим узлом на котором будет создано виртуальное окружение. Чтобы установить ОС на виртуальную машину, расположенную на этом узле, нужно обеспечить возможность загрузки инсталлятора на этой виртуальной машине. Для этого загрузим ISO-образ инсталлятора в хранилище данных выбранного физического узла. Это также удобно делать через веб-интерфейс.<br />
<br />
[[Файл:Pve-iso-pick.png|900px|Загрузка файла .iso в хранилище данных]]<br />
<br />
Теперь, когда все предварительные действия выполнены, нажимаем в веб-интерфейсе PVE кнопку «Создать VM» в правом верхнем углу.<br />
<br />
[[Файл:Pve-vm-create-basic.png|900px|Добавление новой виртуальной машины]]<br />
<br />
Процесс создания VM оформлен в виде «мастера», привычного для пользователей систем управления виртуальными машинами. Проходя по очереди по вкладкам, выбираем, соответственно, уникальное имя VM, шаблон настроек ОС, файл .iso, с которого будет загружаться инсталлятор ОС, тип дискового контроллера, формат и размер образа виртуального жёсткого диска, хранилище данных, на котором он будет располагаться, количество ядер процессора и размер оперативной памяти и так далее. Отдельное внимание обратим на настройки типа подключения дисковых накопителей настройки доступа к сети.<br />
<br />
=== Настройка сетевых подключений ===<br />
<br />
Существует два основных способа подключения VM к сети:<br />
<br />
* через трансляцию сетевых адресов;<br />
* через ethernet-мост.<br />
<br />
Первый способ рекомендуется к использованию в ситуациях, когда мы не планируем использовать виртуальную машину в качестве сервера каких-нибудь сетевых протоколов. Например, когда мы просто хотим протестировать процесс инсталляции ОС. Механизм NAT будет настроен автоматически, без дополнительных действий оператора, достаточно будет просто в процессе создания виртуальной машины поставить радиокнопку на вкладке «Сеть» в положение «NAT mode».<br />
<br />
В процессе настройки гостевой ОС нужно будет выбрать автоматический вариант настройки сетевых адресов по протоколу DHCP. Со стороны гипервизора kvm будет поднят сервер DHCP, который выдаст гостевой системе сетевой адрес и маршруты. Также, со стороны гипервизора будет автоматически настроена трансляция всех адресов выданных встроенным сервером DHCP. Таким образом приложения, работающие в гостевой ОС, получат доступ ко всем сетям, к которым имеет доступ ОС физического узла, причём со стороны этих сетей они будут маскироваться под адресом самого физического узла.<br />
<br />
Второй способ подключения рекомендуется во всех остальных ситуациях. В этом случае, учитывая настройки, сделанные нами при установке PVE, сетевой интерфейс виртуальной машины будет подключён к тому же самому виртуальному коммутатору, что и сетевой интерфейс физического узла. То есть, настройки сетевой подсистемы виртуальной машины зависят от конфигурации той самой сети, в которой находится физический узел. Например, если в этой сети работает сервер DHCP, который сможет выдать нужный адрес виртуальной машине, можно указать автоматический вариант конфигурации. Если нет — придётся настраивать вручную. В отличие от первого способа, где ручной вариант настроек не предполагается (хотя, и возможен).<br />
<br />
[[Файл:Pve-vm-create-net.png|900px|Настройки доступа в сеть виртуальной машины]]<br />
<br />
=== VirtIO ===<br />
<br />
Настраивая сетевое подключение, обращаем внимание также и на то, что в списке сетевых карт, которые может эмулировать гипервизор kvm, есть пункт «VirtIO (paravirtualized)». Это специальный интерфейс, задачей которого является снижение накладных расходов на эмуляцию физической сетевой карты и реализацию драйвера для работы с ней. Между производителями современных операционных систем и произоводителями современных гипервизоров существует договорённость о поддержке единого интерфейса VirtIO, который со стороны гостевой ОС выглядит как очень простая и производительная сетевая карта, а со стороны гипервизора — как прямой интерфейс к сетевому драйверу гостевой ОС. Таким образом, производительность существенно вырастает за счёт того, что не нужно больше эмулировать несуществующее железо. Если про гостевую ОС точно известно, что она поддерживает VirtIO, имеет смысл использовать именно эту «сетевую карту».<br />
<br />
Кстати, реализация VirtIO существует также и для другого интерфейса между виртуальной ОС и гипервизором, критичного к скорости передачи данных — для дисковых накопителей. Там рекомендации точно такие же — если уверенность в поддержке со стороны гостевой ОС есть, включаем.<br />
<br />
=== Удалённый доступ к виртуальной машине ===<br />
<br />
После того, как выбор параметров виртуальной машины закончен и нажата кнопка «Завершить», виртуальная машина создана. Теперь нужно получить удалённый доступ к её консоли. В PVE для удалённый доступ к «физической» консоли виртуальной машины используется протокол VNC. В качестве клиента выступает приложение на Javascript, интегрированное в окно браузера.<br />
=== Миграция виртуальных машин из VMware в ALT PVE ===<br />
Этот раздел описывает миграцию виртуальных машин из VMware в ALT PVE, на примере виртуальной машины с Windows 7.<br><br />
'''Подготовка операционной системы Windows'''<br><br />
Необходимо сделать так, чтобы система грузилась с дисков в режиме IDE.<br><br />
'''Подготовка образа диска'''<br><br />
Предположим что файл с образом диска называется win7.vmdk<br><br />
С помощью vmware-vdiskmanager (утилита поставляется в комплекте с VMWare Workstation) Вам необходимо преобразовать Ваш образ диска в тип "single growable virtual disk". Для этого в перейдите в папку с образами дисков и выполните следующую команду:<br />
<pre>"C:\Program Files\VMware\VMware Server\vmware-vdiskmanager" -r win7.vmdk -t 0 win7-pve.vmdk</pre><br />
'''Подключение образа диска к виртуальной машине на основе Directory Storage'''<br><br />
Создайте новую виртуальную машину KVM, используя web-интерфейс ALT PVE, но не запускайте её. Посмотрите VMID, созданной виртуальной машины (например 100).<br><br />
Скопируйте преобразованный образ win7-pve.vmdk в директорию с образами виртуальных машин <pre>/var/lib/vz/images/VMID</pre> (для этого можно воспользоваться WinSCP).<br><br />
Преобразуйте файл win7-pve.vmdk в qemu формат:<br />
<pre># qemu-img convert -f vmdk win7-pve.vmdk -O qcow2 win7-pve.qcow2</pre><br />
Для подключения образа диска к созданной виртуальной машине Вам необходимо добавить в конфигурационный файл {{path|/etc/pve/nodes/node01/qemu-server/VMID.conf}} виртуальной машины следующую строчку:<br />
<pre>unused0: locald:100/win7-pve.qcow2.qcow2</pre><br />
где 100 это VMID, а locald это имя хранилища в ALT PVE. Далее перейдите в web-интерфейс ALT PVE на вкладку Hardware, созданной виртуальной машины. В списке устройств вы увидите неиспользуемый жесткий диск, щелкните на него, выберете режим IDE и нажмите кнопку Add:<br><br />
[[Файл:Alt pve add disk.jpg|600px]]<br><br />
'''Подключение образа диска к виртуальной машине на основе LVM Storage'''<br><br />
Создайте виртуальную машину используя web-интерфейс ALT PVE с диском большего размера,чем диск в образе vmdk. Посмотреть размер диска в образе можно командой:<br />
<pre># qemu-img info win7-pve.vmdk <br />
image: win7-pve.vmdk<br />
file format: vmdk<br />
virtual size: 127G (136365211648 bytes)<br />
disk size: 8.5G<br />
cluster_size: 65536<br />
Format specific information:<br />
cid: 3098509145<br />
parent cid: 4294967295<br />
create type: monolithicSparse<br />
extents:<br />
[0]:<br />
virtual size: 136365211648<br />
filename: win7-pve.vmdk<br />
cluster size: 65536<br />
format:</pre><br />
В данном случае необходимо создать диск в режиме IDE размером не меньше 127GB, не запускайте виртуальную машину.<br><br />
Скопируйте преобразованный образ win7-pve.vmdk на нужную ноду кластера.<br><br />
Перейдите в консоль ноды кластера и посмотрите как называется LVM диск созданной виртуальной машины (он должен быть в статусе ACTIVE):<br />
<pre># lvscan<br />
ACTIVE '/dev/sharedsv/vm-101-disk-1' [130,00 GiB] inherit</pre><br />
Далее необходимо сконвертировать образ vdmk в raw формат непосредственно на LVM-устройство:<br />
<pre># qemu-img convert -f vmdk win7-pve.vmdk -O raw /dev/sharedsv/vm-101-disk-1</pre><br />
'''Подключение образа диска к виртуальной машине на основе CEPH Storage'''<br><br />
Создайте виртуальную машину используя web-интерфейс ALT PVE с диском большего размера,чем диск в образе vmdk.<br><br />
Скопируйте преобразованный образ win7-pve.vmdk на нужную ноду кластера.<br><br />
Перейдите в консоль ноды кластера. Имя нужного пула можно посмотреть на вкладке Datacenter->Storage->rbd-storage:<br><br />
[[Файл:Alt pve rbd pool.jpg|500px]]<br><br />
Нам необходимо отобразить образ из пула CEPH в локальное блочное устройство:<br />
<pre># rbd map rbd01/vm-100-disk-1<br />
/dev/rbd0</pre><br />
Далее необходимо сконвертировать образ vdmk в raw формат непосредственно на отображенное устройство:<br />
<pre># qemu-img convert -f vmdk win7-pve.vmdk -O raw /dev/rbd0</pre><br />
'''Проблемы с образом VMware'''<br><br />
Кроме того Ваш образ диска может быть в формате flat, тогда при попытке конвертировать его вы получите ошибку "Operation not permitted". Вы можете посмотреть настоящий формат вашего .vdmk файла с помощью команды "file". Если файл в формате flat то вы получите примерно такой вывод:<br />
<pre># file myVMwFlatImage-pre.vmdk<br />
myVMwFlatImage-pre.vmdk: x86 boot sector; partition 1: ID=0x83, active, starthead 1,<br />
startsector 63, 208782 sectors; partition 2: ID=0x8e, starthead 0, startsector 208845,<br />
16563015 sectors, code offset 0x48</pre><br />
Очень просто конвертировать такой файл из .vdmk в .qcow2 просто убрав параметр "-f vdmk" из предыдущей команды, предоставив qemu-img автоматически определить формат исходного файла:<br />
<pre># qemu-img convert myVMwFlatImage-pve.vmdk -O qcow2 myVMwFlatImage-pve.qcow2</pre><br />
Если ваша виртуальная машина KVM стартует, но не грузится с ошибкой "booting from hard disk...boot failed: not a bootable disk", то попробуйте при конвертировании вместо типа диска "single growable virtual disk" тип "preallocated virtual disk". Для этого в командной строке запустите vmvare-vdiskmanager без параметров, Вы увидите справку по работе с командой. Тип диска при конвертации задает параметр -t <disk-type>:<br />
<pre>Disk types:<br />
0 : single growable virtual disk<br />
1 : growable virtual disk split in 2GB files<br />
2 : preallocated virtual disk<br />
3 : preallocated virtual disk split in 2GB files<br />
4 : preallocated ESX-type virtual disk<br />
5 : compressed disk optimized for streaming</pre><br />
Нам нужно выбрать тип 2:<br />
<pre>vmware-vdiskmanager -r whatever.vmdk -t 2 whatever-pve.vmdk</pre><br />
Имейте ввиду, что при этом vmware-vdiskmanager создаст два файла. Первый файл {{path|whatever-pve.vmdk}} очень маленький, это обычный текстовый файл со ссылкой на образ. Второй файл {{path|whatever-pve-flat.vmdk}}, который имеет размер всего Вашего виртуального диска и именно его надо конвертировать в kvm.<br><br />
'''Адаптация новой виртуальной машины KVM'''<br />
*Проверьте режим работы жесткого диска для Windows - IDE, для Linux SCSI<br />
*Режим VIRTIO жесткого диска:<br />
**Режим VIRTIO также доступен для Windows, но сразу загрузиться в этом режиме система не может<br />
**Загрузитесь сначала в режиме IDE и выключите машину, добавьте еще один диск в режиме VIRTIO и включите машину, Windows установит нужные драйвера<br />
**Выключите машину<br />
**Измените режим основного диска с IDE на VIRTIO<br />
**Загрузите систему, которая должна применить VIRTIO драйвер и выдать сообщение, что драйвер от RedHat<br />
*Включите виртуальную машину<br />
*Первое включение займет какое-то время пока будут загружены необходимые драйвера<br />
*Драйвера VIRTIO для Windows можно скачать [https://fedoraproject.org/wiki/Windows_Virtio_Drivers здесь]<br />
<br />
== Контейнеры (CT) ==<br />
<br />
В отличие от виртуальной машины, которая с точки зрения ОС, запущенной на физическом узле, представляет собой один процесс гипервизора, процессы контейнера выполняются на том же самом ядре, что и остальные процессы ОС. То есть, если мы запустим VM и CT на одном и том же физическом узле PVE, процессы CT будут выполняться «рядом» с процессами гипервизора. Разница будет только в применении к процессам контейнеров механизмов изоляции — пространств имён (Namespaces) и групп управления (CGroups) — работающих на уровне ядра Linux.<br />
<br />
Существует несколько реализаций изолированных контейнеров, базирующихся на этих механизмах. Например [https://openvz.org OpenVZ] и [https://linuxcontainers.org LXC], которые отличаются развитостью и проработанностью механизмов управления. В PVE версий 4+ используется реализация LXC (до 3 версии использовалась OpenVZ), обёрнутая дополнительным собственным пользовательским интерфейсом, делающим процесс создания и обслуживания контейнеров ещё более удобным.<br />
<br />
Процесс создания контейнера во многом схож с процессом создания виртуальной машины. Разница в том, что создание контейнера соответствует созданию VM и одновременно установке туда операционной системы. Эквивалентом инсталляционному диску является шаблон, из которого разворачивается контейнер. Это архив, содержащий корневую файловую систему будущего контейнера. Примеры шаблонов контейнеров можно найти на [http://download.proxmox.com/images/system/ сайте разработчиков PVE] и в [https://openvz.org/Download/template/precreated коллекции шаблонов OpenVZ].<br />
<br />
Важно помнить, что [[Шаблоны для развёртывания CT в PVE|шаблоны, пригодные для развёртывания CT в PVE]], имеют собственную нотацию имён, отличающуюся от таковых, например, в OpenVZ. Поэтому перед загрузкой очередного шаблона в хранилище PVE не забываем переименовать его соответствующим образом.<br />
<br />
[[Файл:Pve-template-load.png|900px|Загрузка шаблона контейнера]]<br />
<br />
Почти весь процесс «инсталляции» сводится к распаковке шаблона. Оставшаяся часть процесса инсталляции заключается в том, чтобы придать распакованному образу корневой файловой системы уникальные черты, отличающие его от других таких же контейнеров, созданных, возможно, из этого же самого шаблона.<br />
<br />
Уникальность контейнера обеспечивается на двух уровнях: первый уровень это уникальный идентификатор контейнера в пределах ОС физического узла, в которой разворачиваются контейнеры. Это число, как правило больше ста. PVE автоматизированным образом ведёт учёт идентификаторов и при создании контейнера не позволит выбрать уже занятый. Кстати, в пределах кластера PVE идентификаторы VM и СТ составляют единое пространство идентификаторов.<br />
<br />
Второй уровень уникальности контейнера — строго говоря, не обязательный — это сетевые настройки: IP-адрес и имя узла. Обеспечивать уникальность на этом уровне не обязательно, так как у нас может быть несколько контейнеров с одинаковым именем узла, адресом IP, и даже MAC-адресом. Просто они будут запускаться в разное время. Но следить за этим будет уже не PVE, а оператор. PVE только обеспечивает возможность задания сетевых настроек контейнера при его создании.<br />
<br />
[[Файл:Pve-ct-create-net.png|900px|Сетевые настройки контейнера]]<br />
<br />
Основная задача CT, в отличие от VM — не запуск полноценной ОС в виртуальной машине, а запуск отдельного приложения или сетевой службы в изолированном окружении. Поэтому доступ для обслуживания CT, как правило, удобнее осуществлять через обычный терминал — то есть, уже без участия интерфейса PVE. Для этого внутри контейнера настраивают серверную часть SSH, VNC или наоборот — клиентскую часть X-протокола. Впрочем, веб-интерфейс предоставляет для CT, так же, кстати, как и для физических узлов консоль. Обычную текстовую консоль UNIX.<br />
<br />
[[Файл:Pve-node-console.png|900px|Доступ к консоли через веб-интерфейс]]<br />
<br />
== Обслуживание виртуальных окружений ==<br />
<br />
Кроме создания, удаления и получения доступа к консоли существует ещё ряд важных задач по работе с виртуальными окружениями, которые веб-интерфейс PVE позволяет успешно решать. Это в первую очередь сбор статистики по расходованию ресурсов кластера PVE, управление доступом к объектам виртуальной инфраструктуры, и обеспечение бесперебойной работы в случае сбоев.<br />
<br />
=== Статистика ===<br />
<br />
В течение всего времени работы кластера PVE собирает статистику по широкому спектру параметров, характеризующих различные виды нагрузки на физические узлы, хранилища данных и виртуальные окружения. Статистическая информация собирается, хранится, и может быть в любой момент представлена в виде графиков и диаграмм.<br />
<br />
[[Файл:Pve-stats-node.png|900px|Данные о нагрузке на узел]]<br />
<br />
Такой наглядный способ представления может быть полезен не только для оценки текущего состояния работы системы, но и для оценки тенденций изменения характера нагрузок. Поэтому, при выборе узла, на который мы планируем добавить очередное виртуальное окружение в кластер, бывает полезно заглянуть не только в выпадающий список узлов со значениями текущих показателей нагрузки, но и в графики распределения нагрузки по времени суток и дням недели. Может оказаться, что узел, наименее нагруженный в данный момент, бо́льшую часть времени работает под максимальной нагрузкой.<br />
<br />
=== Управление доступом ===<br />
<br />
Как уже упоминалось в руководстве по установке, PVE может использовать любые базы данных пользовательских учётных записей, доступные через механизм PAM. Например, базы локальных пользователей физических узлов кластера. Кроме того, у PVE есть ещё и своя база данных учётных записей пользователей и групп. Все эти пользователи и группы являются полноправными субъектами доступа к объектам кластера. Объектами доступа являются физические узлы и хранилища данных. Полномочия субъектов доступа настраиваются через механизм ролей.<br />
<br />
[[Файл:Pve-user-as-role.png|900px|Список возможных ролей пользователя]]<br />
<br />
Для упрощения разграничения доступа в PVE существует ещё один уровень объектов доступа, функционально аналогичный группам — пулы. В состав пула могут входить виртуальные окружения и некоторые виды хранилищ данных. Доступ к пулам регулируется так же через механизм назначения ролей.<br />
<br />
=== Резервное копирование ===<br />
<br />
На радость системным администраторам PVE имеет встроенную систему резервного копирования. Добавить очередной пункт в расписание снятия резервных копий состояния виртуальных окружений и хранилищ данных можно буквально «в несколько кликов».<br />
<br />
[[Файл:Pve-backup-setup.png|900px|Настройка расписания резервного копирования]]<br />
<br />
Важно не забыть предварительно добавить хранилище, у которого будет роль хранилища для резервных копий.<br />
<br />
Формат и режим снятия резервных копий могут быть разными. Это могут быть образы остановленных виртуальных окружений, находящихся в консистентном состоянии, или снапшоты, сделанные «на лету». В последнем случае работоспособность сервисов, запущенных внутри виртуального окружения, после восстановления из резервной копии не гарантируется.<br />
<br />
=== Снапшоты ===<br />
<br />
Кроме снятия резервных копий, снапшоты используются и просто для фиксации состояния виртуального окружения. Для фиксации снапшотов есть специальный пункт в меню виртуального окружения в интерфейсе PVE.<br />
<br />
[[Файл:Pve-snapshot-setup.png|900px|Снятие снапшота]]<br />
<br />
= Ссылки =<br />
* [http://www.proxmox.com/ Официальный сайт]<br />
* [[:ruwp:Proxmox_Virtual_Environment|Proxmox VE]]<br />
<br />
[[Категория:Admin]]<br />
[[Категория:Миграция]]<br />
{{Category navigation|title=ПО уровня предприятия|category=Enterprise Software|sortkey={{SUBPAGENAME}}}}</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%A7%D1%82%D0%BE_%D1%82%D0%B0%D0%BA%D0%BE%D0%B5_Sisyphus%3F&diff=44480Что такое Sisyphus?2019-04-09T06:15:44Z<p>AntonFarygin: /* Sisyphus и дистрибутивы ALT Linux */</p>
<hr />
<div>{{Улучшение}}<br />
__TOC__<br />
<br />
=== Введение ===<br />
<br />
[[Sisyphus|Sisyphus]] (Сизиф) — это разрабатываемый [[ALT Linux Team]] проект, целью которого является развитие [[Репозиторий СПО|репозитория свободного ПО]] для удобной разработки на его основе дистрибутивов и других решений.<br />
<br />
Проект Sisyphus включает следующие компоненты:<br />
<br />
* собственно репозиторий ПО (rpm- и src.rpm-пакеты);<br />
* инструментарий для подготовки и тестирования программных пакетов (hasher, gear, git; sisyphus_check, qa-robot, repocop; etc);<br />
* инструментарий обеспечения целостности репозитория (apt);<br />
* инструментарий для разработки конечных решений и, в частности, дистрибутивов (mkimage, Alterator, Installer).<br />
<br />
В настоящий момент Sisyphus доступен для архитектур x86, x86_64, aarch64, armh, RISC-V, MIPS, Эльбрус и ведется работа по портированию на другие платформы.<br />
<br />
=== Назначение Sisyphus ===<br />
Sisyphus прежде всего предназначен для использования в качестве основы для разработки продуктов/решений для конечных пользователей:<br />
* разработка дистрибутивов общего назначения (например, ALT Server, ALT Workstation);<br />
* разработка специализированных дистрибутивов (OEM решения, ALT СП, ИВК Кольчуга и другие);<br />
* разработка дополнений к существующим дистрибутивам;<br />
* разработка решений для использования на виртуальных машинах (например, шаблоны OpenVZ, docker и т.д.).<br />
<br />
Пожалуй, самым распространённым вариантом на сегодня является создание [[Компания «Базальт СПО»|компанией «Базальт СПО»]] линейки [[Releases|дистрибутивов ALT ]].<br />
<br />
=== Чем не является Sisyphus ===<br />
Достаточно важно понимать, чем Sisyphus точно ''не является'', чтобы по ошибке не создать себе больших проблем.<br />
* Sisyphus ''не является'' самостоятельным дистрибутивом. Несмотря на наличие [[regular|регулярных сборок]].<br />
* Sisyphus ''не является'' обновлениями для дистрибутивов. Для этого есть официальные ''updates''.<br />
* Sisyphus ''не является'' дополнением к дистрибутивам. Для этого есть ''backports''.<br />
* Sisyphus ''не является'' стабильным решением для применения в mission critical задачах. Для этого есть дистрибутивы.<br />
<br />
=== Кому и зачем нужен Sisyphus ===<br />
<br />
Косвенные варианты пока не рассматриваем, но они тоже есть.<br />
<br />
==== Разработчикам решений на базе Linux ====<br />
Sisyphus можно использовать в качестве основы для создания собственных решений — репозиториев, дистрибутивов и т. д.<br />
<br />
Используя Sisyphus, разработчик получает в своё распоряжение большую базу подготовленных и в достаточной мере протестированных пакетов и набор полезных инструментов (''hasher'', ''gear'', ''mkimage'', etc), существенно сокращающих время на создание готового решения.<br />
<br />
Достаточно логичным вариантом оказывается участие таких разработчиков в ALT Linux Team, что позволяет более активно влиять на направление развития проекта Sisyphus и, как следствие, получающихся на его основе продуктов. Таким образом можно существенно сократить затраты (временные, финансовые, человеческие) на создание конечного решения.<br />
<br />
==== Продвинутым пользователям ====<br />
Если пользователь не входит в Team, то ему Sisyphus может быть полезен в следующих случаях:<br />
<br />
* Можно взять отдельные пакеты, которые отсутствуют или устарели в дистрибутиве. Только сперва рекомендуется хорошо подумать, потом проверить отсутствие в backports, а уж потом брать (и то обычно лучше src.rpm, каковой и бэкпортить сборкой в бинарном окружении целевого дистрибутива).<br />
* Можно почувствовать себя «в струе», на своей шкуре ощущая, как развивается свободный софт и какие новшества (включая грабли) светят в ближайших релизах :-)<br />
<br />
=== Зачем участвовать в работе над Sisyphus ===<br />
<br />
Участие в разработке Sisyphus дает возможность непосредственно влиять на вектор развития проекта и производных от него решений. Как следствие, возможность получить более качественный продукт и/или снизить затраты на разработку своих решений. Например, можно опубликовать сборку необходимого пакета и получить в ближайшем стабильном дистрибутиве этот пакет «из коробки».<br />
<br />
=== Как разрабатывается Sisyphus ===<br />
См. [[Sisyphus|основную страницу]] и далее по разделам.<br />
<br />
==== Основные инструменты для подготовки пакетов ====<br />
* [[rpm]]<br />
** [[rpm/AutoReq]]<br />
* [[hasher]]<br />
* [[git]]<br />
* [[gear]]<br />
* [[Etersoft-build-utils|etersoft-build-utils]] — набор скриптов, автоматизирующий рутинные действия мантейнера<br />
* [[apt]] (apt-rpm)<br />
* [[sisyphus_check|sisyphus_check]]<br />
* [[repocop]] — платформа для запуска интеграционных тестов над пакетами<br />
* qa-robot<br />
* [[mkimage]]<br />
<br />
==== Нормативные документы (полиси) ====<br />
Чтобы обеспечить некоторую упорядоченность в развитии проекта, существует ряд [[:Категория:Нормативные документы|нормативных документов]], регламентирующих различные (чаще технологические) аспекты разработки.<br />
<br />
=== Как присоединиться к разработке Sisyphus ===<br />
Для присоединения к разработке Sisyphus достаточно пройти процедуру [[Join|вступления в ALT Linux Team]].<br />
<br />
Процедура состоит из идентификации кандидата — регистрации GPG и ssh-ключей, и проверки уровня технической подготовки — тестового задания, обычно состоящего из сборки пакета по правилам Sisyphus.<br />
<br />
Тестовое задание может варьироваться для разных кандидатов: желающих заниматься преимущественно поддержанием пакетов в репозитории, документированием, дизайном, тестированием и т. д.<br />
<br />
=== Взаимосвязь Сизифа с другими сущностями ===<br />
<br />
Так как Sisyphus является не [http://absurdopedia.wikia.com/wiki/Сферический_конь_в_вакууме сферическим конём в вакууме], а прежде всего инструментарием, то должны быть связи между ним, его потребителями и конечными продуктами/решениями.<br />
<br />
==== Sisyphus и ALT Linux Team ====<br />
Разработкой проекта Sisyphus занимается независимая команда ALT Linux Team.<br />
Sisyphus является главным продуктом, создаваемым командой.<br />
<br />
==== Sisyphus и компания «Базальт СПО» ====<br />
Разработка Sisyphus происходит при заметной поддержке (технической, организационной и т. д.) со стороны компании «Базальт СПО».<br />
Собственно, большая часть сотрудников компании также является участниками ALT Linux Team и занимается разработкой Sisyphus.<br />
<br />
==== Sisyphus и дистрибутивы ALT Linux ====<br />
Компания «Базальт СПО», среди прочего, выпускает дистрибутивы операционной системы Linux, которые создаются на основе стабильных срезов репозитория Sisyphus.<br />
<br />
Процесс превращения нестабильного Сизифа в стабильный дистрибутив приблизительно описывается такой схемой:<br />
: '''Постоянно меняющийся Sisyphus''' {{==)}} '''[[Branches/Release|стабилизация Sisyphus]]''' {{==)}} '''создание [[Branches|стабильной ветки]]''' {{==)}} '''готовый дистрибутив (или линейка)'''<br />
<br />
==== Решения других разработчиков ====<br />
На базе Sisyphus построено некоторое количество публично доступных сторонних решений:<br />
<br />
* Дистрибутив для терминальных серверов [[LTSP|ALT Linux Terminal]];<br />
* Решение для IP-АТС — [http://seiros.ru SeirosPBX];<br />
* Прошивка для маршрутизаторов — [http://radlinux.org RAD Linux];<br />
* Наверняка есть и другие.<br />
<br />
=== Лирические мнения ===<br />
<br />
{{Начало цитаты}}<br />
> Однако и на Sisyphus можно прекрасно работать, просто риск кривых обновлений<br /><br />
> гораздо выше. Если обновляться редко, то разницы по большому счёту нет.<br /><br />
Нет! Сизифа надо бояться, он все сломает.<br />
Это было официальное сообщение.<br />
{{Конец цитаты|источник=[http://forum.altlinux.org/index.php/topic,47.msg460.html#msg460 aen@]}}<br />
<br />
{{Начало цитаты}}<br />
Сизиф не надо бояться или только уважать. Нужно принять как факт то, что где-то существуют заводы, на которых плавят руду и льют металл, чтобы потом из него сделать необходимые детали и уже из них товары народного потребления. Нужно ли бояться заводов и работяг, каждый день рискующих сгореть в домне? Вряд ли. В цеху может кто-то и матерком покрыть, особенно если тот, кого кроют, не соблюдает технику безопасности. В процессе отлива могут быть и опасные этапы, когда лучше и не подходить близко. Так и здесь, только жизнь этих работяг и подходы «к станку» у всех на виду.<br />
<br />
Если относиться к доступной всем внутренней жизни цеха с пониманием и твёрдо оценивать собственные возможности, то пользоваться Сизифом можно. Но между «можно» и «нужно» — бездна, которая должна быть заполнена собственной мыслительной деятельностью, с учётом собственной ситуации и потенциальных результатов.<br />
<br />
Не надо только делать из нормального трудового процесса жупел или символ чего-либо.<br />
{{Конец цитаты|источник=[http://forum.altlinux.org/index.php/topic,47.msg652.html#msg652 ab@]}}<br />
<br />
{{Начало цитаты}}<br />
Перейти на Sisyphus стоит, если:<br />
* вы знаете, что вы делаете.<br />
* вы умеете исправлять то, что вы не знаете, что делает<br />
* вы программист<br />
* у вас есть достаточно времени, чтобы исправлять то, что вы не знаете, что делает<br />
* ваше желание участвовать в разработке настолько велико, что перевешивает все остальные пункты<br />
{{Конец цитаты|источник=[http://forum.altlinux.org/index.php/topic,47.msg1000.html#msg1000 rider@]}}<br />
<br />
=== Миф о Сизифе ===<br />
Sisyphus (Сизиф) — персонаж греческой мифологии. Миф о Сизифе, который непрерывно катил в гору камни, символизирует постоянный труд команды по усовершенствованию решений, заложенных в репозиторий. Миф можно найти в любой соответствующей книжке, а для начинающих рекомендуем А.&nbsp;Куна. [http://www.philosophy.ru/library/camus/01/0.html «Миф о Сизифе»] — философское эссе Альбера Камю.<br />
<br />
— На миф о Сизифе ссылалось [http://lists.altlinux.org/pipermail/community/2000-December/420763.html объявление проекта] в 2000 году; ссылается и [http://docs.altlinux.org/archive/p5/office-server/#id2527344 документация] времён [[Пятая платформа|Пятой платформы]].<br />
<br />
[[Категория:Sisyphus|*]]</div>AntonFaryginhttps://www.altlinux.org/index.php?title=%D0%A7%D1%82%D0%BE_%D1%82%D0%B0%D0%BA%D0%BE%D0%B5_Sisyphus%3F&diff=44479Что такое Sisyphus?2019-04-09T06:14:59Z<p>AntonFarygin: /* Sisyphus и компания «Альт Линукс» */</p>
<hr />
<div>{{Улучшение}}<br />
__TOC__<br />
<br />
=== Введение ===<br />
<br />
[[Sisyphus|Sisyphus]] (Сизиф) — это разрабатываемый [[ALT Linux Team]] проект, целью которого является развитие [[Репозиторий СПО|репозитория свободного ПО]] для удобной разработки на его основе дистрибутивов и других решений.<br />
<br />
Проект Sisyphus включает следующие компоненты:<br />
<br />
* собственно репозиторий ПО (rpm- и src.rpm-пакеты);<br />
* инструментарий для подготовки и тестирования программных пакетов (hasher, gear, git; sisyphus_check, qa-robot, repocop; etc);<br />
* инструментарий обеспечения целостности репозитория (apt);<br />
* инструментарий для разработки конечных решений и, в частности, дистрибутивов (mkimage, Alterator, Installer).<br />
<br />
В настоящий момент Sisyphus доступен для архитектур x86, x86_64, aarch64, armh, RISC-V, MIPS, Эльбрус и ведется работа по портированию на другие платформы.<br />
<br />
=== Назначение Sisyphus ===<br />
Sisyphus прежде всего предназначен для использования в качестве основы для разработки продуктов/решений для конечных пользователей:<br />
* разработка дистрибутивов общего назначения (например, ALT Server, ALT Workstation);<br />
* разработка специализированных дистрибутивов (OEM решения, ALT СП, ИВК Кольчуга и другие);<br />
* разработка дополнений к существующим дистрибутивам;<br />
* разработка решений для использования на виртуальных машинах (например, шаблоны OpenVZ, docker и т.д.).<br />
<br />
Пожалуй, самым распространённым вариантом на сегодня является создание [[Компания «Базальт СПО»|компанией «Базальт СПО»]] линейки [[Releases|дистрибутивов ALT ]].<br />
<br />
=== Чем не является Sisyphus ===<br />
Достаточно важно понимать, чем Sisyphus точно ''не является'', чтобы по ошибке не создать себе больших проблем.<br />
* Sisyphus ''не является'' самостоятельным дистрибутивом. Несмотря на наличие [[regular|регулярных сборок]].<br />
* Sisyphus ''не является'' обновлениями для дистрибутивов. Для этого есть официальные ''updates''.<br />
* Sisyphus ''не является'' дополнением к дистрибутивам. Для этого есть ''backports''.<br />
* Sisyphus ''не является'' стабильным решением для применения в mission critical задачах. Для этого есть дистрибутивы.<br />
<br />
=== Кому и зачем нужен Sisyphus ===<br />
<br />
Косвенные варианты пока не рассматриваем, но они тоже есть.<br />
<br />
==== Разработчикам решений на базе Linux ====<br />
Sisyphus можно использовать в качестве основы для создания собственных решений — репозиториев, дистрибутивов и т. д.<br />
<br />
Используя Sisyphus, разработчик получает в своё распоряжение большую базу подготовленных и в достаточной мере протестированных пакетов и набор полезных инструментов (''hasher'', ''gear'', ''mkimage'', etc), существенно сокращающих время на создание готового решения.<br />
<br />
Достаточно логичным вариантом оказывается участие таких разработчиков в ALT Linux Team, что позволяет более активно влиять на направление развития проекта Sisyphus и, как следствие, получающихся на его основе продуктов. Таким образом можно существенно сократить затраты (временные, финансовые, человеческие) на создание конечного решения.<br />
<br />
==== Продвинутым пользователям ====<br />
Если пользователь не входит в Team, то ему Sisyphus может быть полезен в следующих случаях:<br />
<br />
* Можно взять отдельные пакеты, которые отсутствуют или устарели в дистрибутиве. Только сперва рекомендуется хорошо подумать, потом проверить отсутствие в backports, а уж потом брать (и то обычно лучше src.rpm, каковой и бэкпортить сборкой в бинарном окружении целевого дистрибутива).<br />
* Можно почувствовать себя «в струе», на своей шкуре ощущая, как развивается свободный софт и какие новшества (включая грабли) светят в ближайших релизах :-)<br />
<br />
=== Зачем участвовать в работе над Sisyphus ===<br />
<br />
Участие в разработке Sisyphus дает возможность непосредственно влиять на вектор развития проекта и производных от него решений. Как следствие, возможность получить более качественный продукт и/или снизить затраты на разработку своих решений. Например, можно опубликовать сборку необходимого пакета и получить в ближайшем стабильном дистрибутиве этот пакет «из коробки».<br />
<br />
=== Как разрабатывается Sisyphus ===<br />
См. [[Sisyphus|основную страницу]] и далее по разделам.<br />
<br />
==== Основные инструменты для подготовки пакетов ====<br />
* [[rpm]]<br />
** [[rpm/AutoReq]]<br />
* [[hasher]]<br />
* [[git]]<br />
* [[gear]]<br />
* [[Etersoft-build-utils|etersoft-build-utils]] — набор скриптов, автоматизирующий рутинные действия мантейнера<br />
* [[apt]] (apt-rpm)<br />
* [[sisyphus_check|sisyphus_check]]<br />
* [[repocop]] — платформа для запуска интеграционных тестов над пакетами<br />
* qa-robot<br />
* [[mkimage]]<br />
<br />
==== Нормативные документы (полиси) ====<br />
Чтобы обеспечить некоторую упорядоченность в развитии проекта, существует ряд [[:Категория:Нормативные документы|нормативных документов]], регламентирующих различные (чаще технологические) аспекты разработки.<br />
<br />
=== Как присоединиться к разработке Sisyphus ===<br />
Для присоединения к разработке Sisyphus достаточно пройти процедуру [[Join|вступления в ALT Linux Team]].<br />
<br />
Процедура состоит из идентификации кандидата — регистрации GPG и ssh-ключей, и проверки уровня технической подготовки — тестового задания, обычно состоящего из сборки пакета по правилам Sisyphus.<br />
<br />
Тестовое задание может варьироваться для разных кандидатов: желающих заниматься преимущественно поддержанием пакетов в репозитории, документированием, дизайном, тестированием и т. д.<br />
<br />
=== Взаимосвязь Сизифа с другими сущностями ===<br />
<br />
Так как Sisyphus является не [http://absurdopedia.wikia.com/wiki/Сферический_конь_в_вакууме сферическим конём в вакууме], а прежде всего инструментарием, то должны быть связи между ним, его потребителями и конечными продуктами/решениями.<br />
<br />
==== Sisyphus и ALT Linux Team ====<br />
Разработкой проекта Sisyphus занимается независимая команда ALT Linux Team.<br />
Sisyphus является главным продуктом, создаваемым командой.<br />
<br />
==== Sisyphus и компания «Базальт СПО» ====<br />
Разработка Sisyphus происходит при заметной поддержке (технической, организационной и т. д.) со стороны компании «Базальт СПО».<br />
Собственно, большая часть сотрудников компании также является участниками ALT Linux Team и занимается разработкой Sisyphus.<br />
<br />
==== Sisyphus и дистрибутивы ALT Linux ====<br />
Компания «Альт Линукс», среди прочего, выпускает дистрибутивы Linux, которые создаются на основе Sisyphus.<br />
<br />
Процесс превращения нестабильного Сизифа в стабильный дистрибутив приблизительно описывается такой схемой:<br />
: '''Постоянно меняющийся Sisyphus''' {{==)}} '''[[Branches/Release|стабилизация Sisyphus]]''' {{==)}} '''создание [[Branches|стабильной ветки]]''' {{==)}} '''готовый дистрибутив (или линейка)'''<br />
<br />
==== Решения других разработчиков ====<br />
На базе Sisyphus построено некоторое количество публично доступных сторонних решений:<br />
<br />
* Дистрибутив для терминальных серверов [[LTSP|ALT Linux Terminal]];<br />
* Решение для IP-АТС — [http://seiros.ru SeirosPBX];<br />
* Прошивка для маршрутизаторов — [http://radlinux.org RAD Linux];<br />
* Наверняка есть и другие.<br />
<br />
=== Лирические мнения ===<br />
<br />
{{Начало цитаты}}<br />
> Однако и на Sisyphus можно прекрасно работать, просто риск кривых обновлений<br /><br />
> гораздо выше. Если обновляться редко, то разницы по большому счёту нет.<br /><br />
Нет! Сизифа надо бояться, он все сломает.<br />
Это было официальное сообщение.<br />
{{Конец цитаты|источник=[http://forum.altlinux.org/index.php/topic,47.msg460.html#msg460 aen@]}}<br />
<br />
{{Начало цитаты}}<br />
Сизиф не надо бояться или только уважать. Нужно принять как факт то, что где-то существуют заводы, на которых плавят руду и льют металл, чтобы потом из него сделать необходимые детали и уже из них товары народного потребления. Нужно ли бояться заводов и работяг, каждый день рискующих сгореть в домне? Вряд ли. В цеху может кто-то и матерком покрыть, особенно если тот, кого кроют, не соблюдает технику безопасности. В процессе отлива могут быть и опасные этапы, когда лучше и не подходить близко. Так и здесь, только жизнь этих работяг и подходы «к станку» у всех на виду.<br />
<br />
Если относиться к доступной всем внутренней жизни цеха с пониманием и твёрдо оценивать собственные возможности, то пользоваться Сизифом можно. Но между «можно» и «нужно» — бездна, которая должна быть заполнена собственной мыслительной деятельностью, с учётом собственной ситуации и потенциальных результатов.<br />
<br />
Не надо только делать из нормального трудового процесса жупел или символ чего-либо.<br />
{{Конец цитаты|источник=[http://forum.altlinux.org/index.php/topic,47.msg652.html#msg652 ab@]}}<br />
<br />
{{Начало цитаты}}<br />
Перейти на Sisyphus стоит, если:<br />
* вы знаете, что вы делаете.<br />
* вы умеете исправлять то, что вы не знаете, что делает<br />
* вы программист<br />
* у вас есть достаточно времени, чтобы исправлять то, что вы не знаете, что делает<br />
* ваше желание участвовать в разработке настолько велико, что перевешивает все остальные пункты<br />
{{Конец цитаты|источник=[http://forum.altlinux.org/index.php/topic,47.msg1000.html#msg1000 rider@]}}<br />
<br />
=== Миф о Сизифе ===<br />
Sisyphus (Сизиф) — персонаж греческой мифологии. Миф о Сизифе, который непрерывно катил в гору камни, символизирует постоянный труд команды по усовершенствованию решений, заложенных в репозиторий. Миф можно найти в любой соответствующей книжке, а для начинающих рекомендуем А.&nbsp;Куна. [http://www.philosophy.ru/library/camus/01/0.html «Миф о Сизифе»] — философское эссе Альбера Камю.<br />
<br />
— На миф о Сизифе ссылалось [http://lists.altlinux.org/pipermail/community/2000-December/420763.html объявление проекта] в 2000 году; ссылается и [http://docs.altlinux.org/archive/p5/office-server/#id2527344 документация] времён [[Пятая платформа|Пятой платформы]].<br />
<br />
[[Категория:Sisyphus|*]]</div>AntonFarygin