title: utf-8(7)

summary: ASCII\-совместимая многобайтовая юникодная кодировка

text:
# utf-8(7)

## ИМЯ
UTF-8 - ASCII-совместимая многобайтовая юникодная кодировка

## ОПИСАНИЕ
Набор символов Unicode 3.0 занимает 16-битное кодовое пространство. Наиболее распространённая юникодная кодировка, известная как UCS-2, содержит последовательности 16-битных слов. Закодированные таким образом строки могут состоять из частей 16-битных символов например, '\0' или '/', которые имеют специальное значение в именах файлов и других параметрах функций библиотеки языка Си. Кроме того, большинство утилит UNIX предназначено для обработки ASCII-файлов и не может воспринимать 16-битные слова как символы. По этим причинам UCS-2 является неподходящей кодировкой Юникода для имён файлов, текстовых файлов, переменных окружения и т.д. Набор ISO Universal Character Set (UCS), расширенный набор Юникода, занимает более 31-битного кодового пространства, а используемая для него кодировка UCS-4 (последовательность 32-битных слов) имеет те же недостатки, что и описанные выше.

Кодировка UTF-8 для представления Юникода и UCS лишена этих недостатков и поэтому в UNIX-подобных операционных системах используется наиболее часто.

### Свойства
Кодировка UTF-8 обладает следующими полезными свойствами:

*

UCS-символы с кодами от 0x00000000 до 0x0000007f (стандартный набор US-ASCII) кодируются как байты с кодами от 0x00 до 0x7f (для совместимости с кодовой таблицей ASCII). Это означает, что файлы и строки, содержащие только 7-битные ASCII-символы, будут иметь одинаковое представление как в ASCII так и в UTF-8.

*

Все UCS-символы с кодами больше чем 0x7f кодируются как многобайтовые последовательности, содержащие только байты в диапазоне от 0x80 до 0xfd, так что ASCII-байты не могут оказаться частью другого символа и, как следствие, не будет проблем с использованием '\0' или '/'.

*

Сохраняется лексикографический порядок сортировки строк как в кодировке UCS-4.

*

При помощи UTF-8 могут быть закодированы все 2^31 значения UCS.

*

В кодировке UTF-8 никогда не используются байты с кодами 0xc0, 0xc1, 0xfe и 0xff.

*

Первый байт многобайтовой последовательности, представляющей один не ASCII UCS-символ, всегда находится в диапазоне от 0xc2 до 0xfd и указывает на длину многобайтовой последовательности. Все последующие байты в многобайтовой последовательности находятся в диапазоне от 0x80 до 0xbf. Это позволяет облегчить ресинхронизацию, устраняет необходимость учитывать состояние кодировки (statelessness) и делает кодировку независимой от пропущенных байтов.

*

Символы UCS, закодированные в UTF-8, могут занимать до шести байтов, однако в стандарте Юникода не определены символы выше 0x10ffff, поэтому в UTF-8 юникодные символы могут иметь максимальный размер 4 байта.

### Кодирование
Приведённые ниже последовательности байтов используются для отображения символа. Конкретная последовательность зависит от номера символа в кодировке UCS:

0x00000000 - 0x0000007F:

0xxxxxxx

0x00000080 - 0x000007FF:

110xxxxx 10xxxxxx

0x00000800 - 0x0000FFFF:

1110xxxx 10xxxxxx 10xxxxxx

0x00010000 - 0x001FFFFF:

11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

0x00200000 - 0x03FFFFFF:

111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

0x04000000 - 0x7FFFFFFF:

1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

Позиции битов, обозначенные как xxx, заполняются соответствующими битами из кода символа в двоичном виде, наиболее значимый бит первый (прямой порядок байт).Используется самая короткая из возможных многобайтовых последовательностей, которые могут представить код символа.

Значения кодов UCS 0xd00–0xdfff (суррогаты UTF-16), а также 0xfffe и 0xffff (не символьные значения UCS), не должны появляться в потоках UTF-8. Согласно RFC 3629 точки выше U+10FFFF не должны использоваться, что ограничивает символы четырьмя байтами.

### Пример
Символ Юникода с кодом 0xa9 = 1010 1001 (знак авторского права) кодируется в UTF-8 как

11000010 10101001 = 0xc2 0xa9

а символ с кодом 0x2260 = 0010 0010 0110 0000 (знак неравенства) кодируется так:

11100010 10001001 10100000 = 0xe2 0x89 0xa0

### Замечания к применению
Например, с помощью

export LANG=en_GB.UTF-8

пользователи должны выбрать локаль UTF-8 для включения поддержки UTF-8 в приложениях.

Программы, в которых учитывается используемая пользователем кодировка, должны всегда устанавливать локаль с помощью

setlocale(LC_CTYPE, "")

и затем проверять выражением

strcmp(nl_langinfo(CODESET), "UTF-8") == 0

что локаль UTF-8 выбрана и во всех стандартных текстовых потоках ввода и вывода, на терминалах, в содержимом простых текстовых файлов, именах файлов и переменных окружения будет использоваться кодировка UTF-8.

Программисты, привыкшие к однобайтовым кодировкам, таким как, US-ASCII или ISO 8859, должны учесть, что два предположения, действовавших ранее, в локалях UTF-8 не работают. Первое: один байт теперь не обязательно соответствует одному символу. Второе: современные эмуляторы терминала в режиме UTF-8 также поддерживают китайские, японские и корейские символы двойной ширины (double-width characters), а также комбинированные символы без пробелов, и вывод одного символа необязательно смещает курсор на одну позицию, как это было в ASCII. Для подсчёта количества символов и позиций курсора нужно использовать библиотечные функции, такие как mbsrtowcs(3) и wcswidth(3).

Стандартной ESC-последовательностью для переключения из схемы кодировки ISO 2022 (используется в терминалах VT100) в UTF-8 является ESC % G ("\x1b%G"). Соответственно, обратной последовательностью для переключения из UTF-8 в ISO 2022 будет ESC % @ ("\x1b%@"). Остальные последовательности ISO 2022 (такие, как переключение в наборы G0 и G1) в режиме UTF-8 не работают.

### Безопасность
Стандарты Юникода и UCS требуют, чтобы генераторы UTF-8 использовали самую короткую возможную форму представления символов, то есть создание двухбайтной последовательности с первым байтом, равным 0xc0, запрещено. В стандарте Unicode 3.1 это правило расширено и запрещает программам воспринимать не самую короткую форму при вводе. Это сделано из соображений безопасности: если вводимые пользователем символы проверяются системой безопасности на возможные нарушения, то программам остаётся проверить только ASCII версии символов «/../», «;» или NUL, так как для этих символов может быть очень много не ASCII способов представления при не самом коротком кодировании в UTF-8.

### Стандарты
ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9.

## СМОТРИТЕ ТАКЖЕ
locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7)


package: man-pages-ru

title: uts_namespaces(7)

summary: обзор пространств имён UTS в Linux

text:
# uts_namespaces(7)

## ИМЯ
namespaces - обзор пространств имён UTS в Linux

## ОПИСАНИЕ
Пространства имён UTS изолируют два системных идентификатора: имя узла и доменное имя NIS. Эти идентификаторы задаются с помощью sethostname(2) и setdomainname(2), и могут быть получены с помощью uname(2), gethostname(2) и getdomainname(2).

Когда процесс создаёт новое пространство имён UTS с помощью clone(2) или unshare(2) с флагом CLONE_NEWUTS, имя узла и домен нового пространства имён UTS копируются из соответствующих значений в пространство имён UTS вызывающего.

Для использования пространств имён UTS требуется, чтобы ядро было собрано с параметром CONFIG_UTS_NS.

## СМОТРИТЕ ТАКЖЕ
nsenter(1), unshare(1), clone(2), getdomainname(2), gethostname(2), setns(2), uname(2), unshare(2), namespaces(7)


vdso

title: vdso(7)

text:
# vdso(7)

## ИМЯ
vdso - обзор виртуального динамически компонуемого общего объекта ELF

## ОБЗОР
\#include <sys/auxv.h>

void *vdso = (uintptr_t) getauxval(AT_SYSINFO_EHDR);

## ОПИСАНИЕ
«vDSO» (virtual dynamic shared object, виртуальный динамический общий объект) — это маленькая общая библиотека, которую ядро автоматически отображает в адресное пространство всех приложений пользовательского пространства. Обычно, приложениям она не нужна, так как vDSO, чаще всего, вызывается из библиотеки C. Вы можете использовать стандартные функции как обычно, а библиотека C самостоятельно позаботится об использовании возможностей vDSO.

И всё же, зачем нужна vDSO? Есть несколько системных вызовов ядра, которые используются в пользовательском коде настолько часто, что это сильно влияет на общую производительность. Это происходит из-за частого повторения вызовов, а также затрат на переключение контекста, которые возникают при выходе из пользовательского пространства и входа в ядро.

Оставшаяся часть этой документации предназначена для любопытных и/или авторов библиотеки C, а не для обычных разработчиков. Если вы попытаетесь вызвать vDSO в своём приложении не через библиотеку C, то, наиболее вероятно, сделаете это неправильно.

### В качестве примера
Выполнение системных вызовов может быть медленным. В 32-битных системах x86 вы можете использовать программное прерывание (int $0x80), чтобы заставить ядро выполнить системный вызов. Однако, эта инструкция очень затратна: она проходит по полному маршруту обработки прерываний в микрокоде процессора, а также в ядре. Новые процессоры содержат более быстрые инструкции (но обратно совместимые) для запуска системных вызовов. Вместо того, чтобы требовать от библиотеки C выяснения во время выполнения есть ли такая возможность, библиотека C может использовать функции, предоставляемые ядром в vDSO.

Заметим, что можно запутаться в терминологии. В системах x86 функция vDSO, используемая для определения предпочтительного метода выполнения системного вызова, называется «__kernel_vsyscall», но в x86-64 термин «vsyscall» также ссылается на устаревший метод запроса ядра о времени или на каком ЦП выполняется вызывающий.

Одним из наиболее часто используемых системных вызовов является gettimeofday(2). Данный вызов используется прямо в приложениях, а также неявно из библиотеки C. Метка времени, временной цикл или опрос — для всего этого часто нужно знать сколько времени в данный момент. Также, это информация не секретна — многие приложения с любыми правами (root или любого не привилегированного пользователя) получат одинаковый ответ. Поэтому ядро размещает информацию, требуемую для ответа на этот вопрос, в памяти процесса. Теперь системный вызов gettimeofday(2) заменяется на вызов обычной функции и доступ к памяти.

### Нахождение vDSO
Базовый адрес vDSO (если есть) передаётся ядром каждой программе во вспомогательном векторе инициализации (смотрите getauxval(3)) через тег AT_SYSINFO_EHDR.

Вы не должны рассчитывать на то, что vDSO отображается в каком-то определённом месте карты пользовательской памяти. Обычно, базовый адрес во время выполнения выбирается произвольным образом каждый раз при создании нового образа процесса (с помощью execve(2)). Это делается в целях безопасности для предотвращения атак «возврат в libc».

Для некоторых архитектур также существует тег AT_SYSINFO. Он используется только для нахождения точки входа vsyscall и часто отсутствует или равен 0 (то есть недоступен). Этот тег — атавизм первых версий vDSO (смотрите История ниже) и не должен использоваться.

### Формат файла
Так как vDSO — полноценный образ ELF, вы можете искать в нём символы. Это позволяет добавлять новые символы в новых версиях ядра и библиотеке C находить доступные свойства во время выполнения с различными версиями ядер. Зачастую, библиотека C выполняет обнаружение при первом вызове и затем кэширует результат для последующих вызовов.

Все символы имеют версии (в формате версий GNU). Это позволяет ядру обновлять сигнатуру функции без нарушения обратной совместимости. Смена версии означает изменение аргументов функции или возвращаемого значения. Таким образом, при поиске символа в vDSO, вы всегда должны включать версию для нахождения ожидаемого ABI.

Обычно, vDSO удовлетворяет соглашению об именовании, начиная все символы с «__vdso_» или «__kernel_», для их выделения среди других стандартных символов. Например, функция «gettimeofday» называется «__vdso_gettimeofday».

Для вызова этих функций используйте стандартные соглашения о вызове языка Си. Учитывать поведение регистров и стека не требуется.

## ЗАМЕЧАНИЯ

### Исходный код
Код vDSO автоматически компилируется и компонуется при сборке ядра. Обычно, его можно найти в каталоге соответствующей архитектуры:

find arch/$ARCH/ -name '*vdso*.so*' -o -name '*gate*.so*'

### Имена vDSO
Имя vDSO отличается на разных архитектурах. Часто его можно увидеть в выводе утилит, подобных ldd(1) из glibc. Точное имя не должно влиять на код, поэтому жёстко оно нигде не задаётся.

ABI пользователя

имя vDSO

_

aarch64

linux-vdso.so.1

arm

linux-vdso.so.1

ia64

linux-gate.so.1

mips

linux-vdso.so.1

ppc/32

linux-vdso32.so.1

ppc/64

linux-vdso64.so.1

riscv

linux-vdso.so.1

s390

linux-vdso32.so.1

s390x

linux-vdso64.so.1

sh

linux-gate.so.1

i386

linux-gate.so.1

x86-64

linux-vdso.so.1

x86/x32

linux-vdso.so.1

### strace(1), seccomp(2) и vDSO
При трассировке системных вызовов с помощью strace(1), символы (системные вызовы), экспортируемые vDSO, не показываются в результате трассировки. Также данные системные вызовы будут невидимы в фильтрах seccomp(2).

## ЗАМЕЧАНИЯ ДЛЯ РАЗЛИЧНЫХ АРХИТЕКТУР
Далее приведены замечания по vDSO для различных архитектур.

Заметим, что используемая vDSO основывается на ABI вашего кода пользовательского пространства, а не на ABI ядра. Например, когда вы запускаете 32-битный исполняемый файл ELF на i386, то вы получаете ту же vDSO независимо от того, выполняете ли вы его под 32-битном ядром на i386 или под 64-битном ядром под x86-64. Таким образом, для определения нужного раздела ниже нужно использовать имя ABI пользовательского пространства.

### Функции на ARM
В таблице ниже перечислены символы, экспортируемые vDSO.

символ

версия

_

__vdso_gettimeofday

LINUX_2.6 (экспортируется начиная с Linux 4.1)

__vdso_clock_gettime

LINUX_2.6 (экспортируется начиная с Linux 4.1)

Также, перенос ARM содержит страницу кода со вспомогательными функциями. Так как это просто страница с кодом, информация ELF отсутствует и поиск функций невозможен и неизвестны их версии. Хотя в коде есть функции нескольких версий.

Эта страница с кодом хорошо описана в документации к ядру и в ней есть всё, что вам нужно знать: Documentation/arm/kernel_user_helpers.txt.

### Функции на aarch64
В таблице ниже перечислены символы, экспортируемые vDSO.

символ

версия

_

__kernel_rt_sigreturn

LINUX_2.6.39

__kernel_gettimeofday

LINUX_2.6.39

__kernel_clock_gettime

LINUX_2.6.39

__kernel_clock_getres

LINUX_2.6.39

### Функции на bfin (Blackfin) (перенос удалён в Linux 4.17)
Так как в этом ЦП отсутствует устройство управления памятью (MMU), на данной архитектуре не создаётся vDSO в обычном понимании. Вместо этого, ядро отображает несколько функций в постоянное расположение в памяти. Приложения пользовательского пространства могут вызывать их из этой области напрямую. Здесь отсутствует обратная совместимость кроме как слежение за кодами операций (sniffing raw opcodes), но для таких встраиваемых ЦП это нормально — некоторые форматы объектов, запускаемых на нём, даже не основаны на ELF (например, bFLT/FLAT).

Эта страница с кодом хорошо описана в открытой документации:

http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:fixed-code

### Функции на mips
В таблице ниже перечислены символы, экспортируемые vDSO.

символ

версия

_

__kernel_gettimeofday

LINUX_2.6 (экспортируется начиная с Linux 4.4)

__kernel_clock_gettime

LINUX_2.6 (экспортируется начиная с Linux 4.4)

### Функции на ia64 (Itanium)
В таблице ниже перечислены символы, экспортируемые vDSO.

символ

версия

_

__kernel_sigtramp

LINUX_2.5

__kernel_syscall_via_break

LINUX_2.5

__kernel_syscall_via_epc

LINUX_2.5

Перенос на Itanium, в некоторой степени, неоднозначный. Кроме vDSO, показанной выше, также есть «легковесные системные вызовы» (также называемые как «быстрые syscall» или «fsys»). Вы можете вызвать их через вспомогательную функцию vDSO __kernel_syscall_via_epc. Перечисленные здесь системные вызовы имеют ту же семантику, как если бы вызывались напрямую через syscall(2), поэтому обратитесь к соответствующей документации по каждому из них. В таблице ниже перечислены функции, доступные через этот механизм.

функция

_

clock_gettime

getcpu

getpid

getppid

gettimeofday

set_tid_address

### Функции на parisc (hppa)
Перенос parisc содержит страницу кода со вспомогательными функциями, называемую шлюзовой (gateway) страницей. Вместо того, чтобы использовать обычный вспомогательный вектор ELF, передаётся адрес страницы для обработки через регистр SR2. Права на страницу таковы, что простое выполнение этих адресов автоматически выполняется с правами ядра и не в пространстве пользователя. Подобный способ применяется в HP-UX.

Так как это просто страница с кодом, информация ELF отсутствует и поиск функций невозможен и неизвестны их версии. Просто вызывайте функцию по соответствующему смещению через инструкцию ветвления, например:

ble <смещение>(%sr2, %r0)

смещение

функция

_

00b0

lws_entry (операции CAS)

00e0

set_thread_pointer (используется в glibc)

0100

linux_gateway_entry (syscall)

### Функции на ppc/32
В таблице ниже перечислены символы, экспортируемые vDSO. Функции, помеченные *, доступны только в ядре PowerPC64 (64-бита).

символ

версия

_

__kernel_clock_getres

LINUX_2.6.15

__kernel_clock_gettime

LINUX_2.6.15

__kernel_datapage_offset

LINUX_2.6.15

__kernel_get_syscall_map

LINUX_2.6.15

__kernel_get_tbfreq

LINUX_2.6.15

__kernel_getcpu *

LINUX_2.6.15

__kernel_gettimeofday

LINUX_2.6.15

__kernel_sigtramp_rt32

LINUX_2.6.15

__kernel_sigtramp32

LINUX_2.6.15

__kernel_sync_dicache

LINUX_2.6.15

__kernel_sync_dicache_p5

LINUX_2.6.15

Часы CLOCK_REALTIME_COARSE и CLOCK_MONOTONIC_COARSE не поддерживаются в интерфейсах __kernel_clock_getres и __kernel_clock_gettime; ядро вернется к использованию реального системного вызова.

### Функции на ppc/64
В таблице ниже перечислены символы, экспортируемые vDSO.

символ

версия

_

__kernel_clock_getres

LINUX_2.6.15

__kernel_clock_gettime

LINUX_2.6.15

__kernel_datapage_offset

LINUX_2.6.15

__kernel_get_syscall_map

LINUX_2.6.15

__kernel_get_tbfreq

LINUX_2.6.15

__kernel_getcpu

LINUX_2.6.15

__kernel_gettimeofday

LINUX_2.6.15

__kernel_sigtramp_rt64

LINUX_2.6.15

__kernel_sync_dicache

LINUX_2.6.15

__kernel_sync_dicache_p5

LINUX_2.6.15

Часы CLOCK_REALTIME_COARSE и CLOCK_MONOTONIC_COARSE не поддерживаются в интерфейсах __kernel_clock_getres и __kernel_clock_gettime; ядро вернется к использованию реального системного вызова.

### Функции на riscv
В таблице ниже перечислены символы, экспортируемые vDSO.

символ

версия

_

__kernel_rt_sigreturn

LINUX_4.15

__kernel_gettimeofday

LINUX_4.15

__kernel_clock_gettime

LINUX_4.15

__kernel_clock_getres

LINUX_4.15

__kernel_getcpu

LINUX_4.15

__kernel_flush_icache

LINUX_4.15

### Функции на s390
В таблице ниже перечислены символы, экспортируемые vDSO.

символ

версия

_

__kernel_clock_getres

LINUX_2.6.29

__kernel_clock_gettime

LINUX_2.6.29

__kernel_gettimeofday

LINUX_2.6.29

### Функции на s390x
В таблице ниже перечислены символы, экспортируемые vDSO.

символ

версия

_

__kernel_clock_getres

LINUX_2.6.29

__kernel_clock_gettime

LINUX_2.6.29

__kernel_gettimeofday

LINUX_2.6.29

### Функции на sh (SuperH)
В таблице ниже перечислены символы, экспортируемые vDSO.

символ

версия

_

__kernel_rt_sigreturn

LINUX_2.6

__kernel_sigreturn

LINUX_2.6

__kernel_vsyscall

LINUX_2.6

### Функции на i386
В таблице ниже перечислены символы, экспортируемые vDSO.

символ

версия

_

__kernel_sigreturn

LINUX_2.5

__kernel_rt_sigreturn

LINUX_2.5

__kernel_vsyscall

LINUX_2.5

__vdso_clock_gettime

LINUX_2.6 (экспортируется начиная с Linux 3.15)

__vdso_gettimeofday

LINUX_2.6 (экспортируется начиная с Linux 3.15)

__vdso_time

LINUX_2.6 (экспортируется начиная с Linux 3.15)

### Функции x86-64
В таблице ниже перечислены символы, экспортируемые vDSO. Все эти символы также доступны без префикса «__vdso_», но вы не должны пользоваться этим, применяйте имена, перечисленные ниже.

символ

версия

_

__vdso_clock_gettime

LINUX_2.6

__vdso_getcpu

LINUX_2.6

__vdso_gettimeofday

LINUX_2.6

__vdso_time

LINUX_2.6

### Функции на x86/x32
В таблице ниже перечислены символы, экспортируемые vDSO.

символ

версия

_

__vdso_clock_gettime

LINUX_2.6

__vdso_getcpu

LINUX_2.6

__vdso_gettimeofday

LINUX_2.6

__vdso_time

LINUX_2.6

### История
Первоначально vDSO представляла собой одну функцию — vsyscall. В старых ядрах вы можете видеть это имя в карте памяти процесса вместо «vdso». Со временем, люди поняли, что этот механизм является отличным способом перенести больше возможностей в пользовательское пространство, результатом чего стала vDSO в текущем виде.

## СМОТРИТЕ ТАКЖЕ
syscalls(2), getauxval(3), proc(5)

Документация, примеры и исходный код в дереве исходного кода Linux:

```
Documentation/ABI/stable/vdso
Documentation/ia64/fsys.txt
Documentation/vDSO/* (содержит примеры использования vDSO)
find arch/ -iname '*vdso*' -o -iname '*gate*'
```


vsock

title: vsock(7)

summary: семейство адресов Linux VSOCK

text:
# vsock(7)

## ИМЯ
vsock - семейство адресов Linux VSOCK

## ОБЗОР
\#include <sys/socket.h>

\#include <linux/vm_sockets.h>

stream_socket = socket(AF_VSOCK, SOCK_STREAM, 0);

datagram_socket = socket(AF_VSOCK, SOCK_DGRAM, 0);

## ОПИСАНИЕ
Семейство адресов VSOCK обеспечивают взаимодействие между виртуальными машинами и узлом, на котором они выполняются. Данное адресное семейство используется гостевыми агентами и службами супервизора, которым необходим канал связи, не зависящий от настроек сети виртуальной машины.

Возможные типы сокета: SOCK_STREAM и SOCK_DGRAM. Тип SOCK_STREAM предоставляет байтовые потоки с установлением соединения и упорядоченной доставкой. Тип SOCK_DGRAM предоставляет службу датаграмных пакетов без установления соединения и негарантированной доставкой и порядком. Доступность типов сокета зависит от используемого супервизора.

Новый сокет создаётся с помощью вызова

```
socket(AF_VSOCK, socket_type, 0);
```

Когда процесс хочет установить соединение, он вызывает connect(2) с нужным адресом сокета назначения. Сокет автоматически привязывается к свободному порту, если этого ещё не было.

Процесс может слушать входящие соединения на привязанном первым адресе сокета с помощью bind(2) и вызвав после этого listen(2).

Данные передаются с помощью семейств системных вызовов send(2) или write(2), а принимаются семействами системных вызовов recv(2) или read(2).

### Формат адреса
Адрес сокета определяется как комбинация 32-битного идентификатора контекста (CID) и 32-битного номера порта. В CID задаётся источник или назначение, то есть виртуальная машина или узел. Номер порта определяет службу, выполняемую в определённой машине.

```
struct sockaddr_vm {

    sa_family_t    svm_family;     /* семейство адресов: AF_VSOCK */

    unsigned short svm_reserved1;

    unsigned int   svm_port;       /* номер порта в порядке байт узла */

    unsigned int   svm_cid;        /* адрес в порядке байт узла */
};
```

Значение svm_family всегда равно AF_VSOCK. Значение svm_reserved1 всегда равно to 0. Значение svm_port содержит номер порта в порядке байт узла. Номера портов меньше 1024 называются привилегированными портами. Только процесс с мандатом CAP_NET_BIND_SERVICE может вызывать bind(2) с такими номерами.

Существует несколько специальных адресов: VMADDR_CID_ANY (-1U) означает любой адрес при привязывании; VMADDR_CID_HYPERVISOR (0) зарезервирован для служб встроенных в супервизор; VMADDR_CID_RESERVED (1) не должен использоваться; VMADDR_CID_HOST (2) общеизвестный (well-known) адрес узла.

Специальная константа VMADDR_PORT_ANY (-1U) означает любой порт для связывания.

### Живая миграция
На сокеты действует живая миграния виртуальных машин. Соединённые сокеты SOCK_STREAM становятся отключёнными, если виртуальная машина мигрирует на новый узел. Когда это происходит приложения должны выполнить переподключение.

Локальный CID при живой миграции может измениться, если старый CID недоступен на новом узле. Привязанные сокеты автоматически обновляются новым CID.

### Вызовы ioctl
IOCTL_VM_SOCKETS_GET_LOCAL_CID

Получить CID локальной машины. Аргументом является указатель на unsigned int.

```
ioctl(socket, IOCTL_VM_SOCKETS_GET_LOCAL_CID, &cid);

```

Рассматривать использование VMADDR_CID_ANY при привязывании, вместо получения локального CID с помощью IOCTL_VM_SOCKETS_GET_LOCAL_CID.

## ОШИБКИ
EACCES

Невозможно привязаться к привилегированному порту не имея мандата CAP_NET_BIND_SERVICE.

EADDRINUSE

Не могу привязаться к порту, который уже используется.

EADDRNOTAVAIL

Не удалось найти свободный порт для привязки или невозможно привязаться к нелокальному CID.

EINVAL

Некорректные параметры. Сюда относятся: попытка привязать уже привязанный сокет, указание некорректной структуры sockaddr_vm и ошибки проверки правильности входных данных.

ENOPROTOOPT

Недопустимый параметр сокета в setsockopt(2) или getsockopt(2).

ENOTCONN

Невозможно выполнить действие с неподключённым сокетом.

EOPNOTSUPP

Операция не поддерживается. Сюда относятся: флаг MSG_OOB, не реализованный для семейства вызовов send(2), и MSG_PEEK для семейства вызовов recv(2).

EPROTONOSUPPORT

Некорректный номер протокола сокета. Протокол всегда должен быть равен 0.

ESOCKTNOSUPPORT

Неподдерживаемый тип сокета в socket(2). Допускаются только SOCK_STREAM и SOCK_DGRAM.

## ВЕРСИИ
Поддержка для VMware (VMCI) доступна начиная с Linux 3.9. KVM (virtio) поддерживается начиная с Linux 4.8. Hyper-V поддерживается начиная с Linux 4.14.

## СМОТРИТЕ ТАКЖЕ
bind(2), connect(2), listen(2), recv(2), send(2), socket(2), capabilities(7)


title: x25(7)

summary: интерфейс протокола ITU\-T X.25/ISO\-8208

text:
# x25(7)

## ИМЯ
x25 - интерфейс протокола ITU-T X.25/ISO-8208

## ОБЗОР
\#include <sys/socket.h>

\#include <linux/x25.h>

x25_socket = socket(AF_X25, SOCK_SEQPACKET, 0);

## ОПИСАНИЕ
Сокеты X25 предоставляют интерфейс для пакетного слоя протокола X.25. Это позволяет приложениям связываться через открытые сети передачи данных X.25 в соответствии с рекомендациями Международного Телекоммуникационного Общества (International Telecommunication Union) по X.25 (режим X.25 DTE-DCE). Сокеты X25 также можно использовать для связи без наличия промежуточной сети X.25 (режим X.25 DTE-DTE) как описано в стандарте ISO-8208.

При работе выполняется сохранение границ сообщения — вызов read(2) вернёт кусок данных той же величины, что записала в сокет в помощью write(2) сторона-партнёр. Когда это необходимо, ядро следит за сегментированием и перебирает (reassembling) длинные сообщения руководствуясь появлением бита M в X.25. Не существует жёсткого ограничения на максимальный размер сообщения. Однако, переборка длинного сообщения может закончиться неудачно, если возникнет временная нехватка системных ресурсов или когда включатся другие ограничения (например, на память сокета или размер буфера). Если возникает такая ситуация, то соединение X.25 разрывается.

### Адреса сокетов
Для представления сетевого адреса в семействе адресов сокета AF_X25 используется структура struct sockaddr_x25, которая описана в рекомендации ITU-T X.121.

```
struct sockaddr_x25 {

    sa_family_t sx25_family;    /* должно быть AF_X25 */

    x25_address sx25_addr;      /* адрес X.121 */
};
```

В sx25_addr содержится массив символов x25_addr[], который интерпретируется как строка, завершающаяся null. Значение sx25_addr.x25_addr[] содержит до 15-ти (не считая завершающего байта null) ASCII, из которых формируется адрес X.121. Разрешаются только десятичные цифры от «0» до «9».

### Параметры сокета
Специальные параметры сокета X.25 могут быть установлены с помощью setsockopt(2) и прочитаны с помощью getsockopt(2), если в аргументе level указать значение SOL_X25:

X25_QBITINCL

Управляет доступностью пользователю бита Q в X.25 (Qualified Data Bit — бит пригодности данных). В качестве аргумента указывается целое число. Если указан 0 (по умолчанию), то бит Q никогда не устанавливается в исходящих пакетах, а во входящих бит Q игнорируется. Если указана 1, то каждое прочитываемое или записываемое в сокет сообщение предваряется дополнительным байтом. Для данных, которые читаются из сокета, нулевой первый байт говорит означает, что биты Q в соответствующих входящих пакетах данных не установлены. Если первый байт имеет значение 1, то это говорит о том, что в соответствующих входящих пакетах данных установлены биты Q. Если первый байт данных, записанный в сокет, имеет значение 1, то для соответствующих исходящих пакетов данных будет установлен бит Q. Если первый байт имеет значение 0, то бит Q установлен не будет.

## ВЕРСИИ
Семейство протоколов AF_X25 впервые реализовано в Linux 2.2.

## ДЕФЕКТЫ
Имеются в наличии, так как реализация PLP X.25 помечена как CONFIG_EXPERIMENTAL.

Данная справочная страница не полна.

Пока не существует заголовочных файлов, предназначенных для использования в приложениях; вам необходимо включать заголовочный файл ядра <linux/x25.h>. CONFIG_EXPERIMENTAL также может неявно означать, что будущие версии данного интерфейса не будут двоично совместимы.

События X.25 N-Reset пока не передаются пользовательскому процессу. Поэтому, если случится сброс соединения, данные могут быть потеряны без уведомления.

## СМОТРИТЕ ТАКЖЕ
socket(2), socket(7)

Jonathan Simon Naylor: «The Re-Analysis and Re-Implementation of X.25». URL: ftp://ftp.pspt.fi/pub/ham/linux/ax25/x25doc.tgz.


xattr

title: xattr(7)

summary: расширенные атрибуты

text:
# xattr(7)

## ИМЯ
xattr - расширенные атрибуты

## ОПИСАНИЕ
Расширенные атрибуты представляют собой пары имя:значение, которые постоянно связаны с файлами и каталогами, подобно тому как строки окружения связаны с процессом. Атрибут может быть определён или не определён. Если он определён, то его значение может быть или пустым, или не пустым.

Расширенные атрибуты дополняют обычные атрибуты, которые связаны со всеми inode в файловой системе (т. е., данные stat(2)). Часто они используются для предоставления дополнительных возможностей файловой системы, например, дополнительные возможности безопасности, такие как списки контроля доступа (ACL), могут быть реализованы через расширенные атрибуты.

Пользователи, у которых доступ к поиску для файла или каталога могут использовать listxattr(2) для получения списка имён атрибутов, определённых для этого файла или каталога.

Расширенные атрибуты доступны как атомарные объекты. При чтении (getxattr(2)) возвращается всё значение атрибута и происходит его сохранение в буфер. При записи (setxattr(2)) происходит замещение старого значения на новое.

Место под расширенные атрибуты может быть учтено в дисковой квоте владельца файла и файловой группы.

### Пространства имён расширенных атрибутов
Имена атрибутов представляют собой строки с null в конце. Имя атрибута всегда указывается в полной форме — пространство_имён.атрибут, например, user.mime_type, trusted.md5sum, system.posix_acl_access или security.selinux.

Механизм пространства имён используется для определения различных классов расширенных атрибутов. Эти различные классы существуют по нескольким причинам; например, права доступа и мандаты, требуемые для работы с расширенными атрибутами в одном пространстве имён, могут отличаться в другом.

В настоящее время определены следующие классы: security, system, trusted и user. В будущем могут появиться дополнительные классы.

### Расширенные атрибуты безопасности
Пространство имён атрибутов безопасности используется модулями безопасности ядра, такими как Security Enhanced Linux, а также для реализации мандатов файлов (смотрите capabilities(7)). Доступ на чтение и запись атрибутов безопасности зависит от политики, реализуемой модулем безопасности для каждого атрибута безопасности. Если модуль безопасности не загружен, то все процессы могут читать расширенные атрибуты безопасности, а запись доступна только процессам с мандатом CAP_SYS_ADMIN.

### Системные расширенные атрибуты
Системные расширенные атрибуты используются ядром для хранения системных объектов, таких как списки контроля доступа. Доступ на чтение и запись системных атрибутов зависит от политики, реализованной файловой системой ядром для каждого системного атрибута.

### Доверительные расширенные атрибуты
Доверительные расширенные атрибуты видимы и доступны только для процессов с мандатом CAP_SYS_ADMIN. Атрибуты этого класса используются при реализации механизмов в пользовательском пространстве (т. е., вне ядра) для хранения информации в расширенных атрибутах, к которым у обычных процессов не должно быть доступа.

### Пользовательские расширенные атрибуты
Пользовательские расширенные атрибуты могут быть назначены файлам и каталогам для хранения произвольной дополнительной информации, такой как тип mime, используемый набор символов или кодировка файла. Права доступа к пользовательским атрибутам определяется битами прав файлов: для получения значения атрибута требуется право на чтение, а для изменения значения атрибута требуется право на запись.

Биты прав по разному учитываются между обычными файлами и каталогами и специальными файлами и символическими ссылками. У обычных файлов и каталогов битами прав определяется доступ к содержимому файлов, а у специальных файлов ими определяется доступ к устройству, которое описывает специальный файл. Файловые права на символические ссылки не используются при проверке доступа. Эти различия позволили бы пользователям использовать ресурсы файловой системы без учёта выделенных дисковых квот для группы или всем остальным, имеющим доступ на запись в специальные файлы и каталоги.

По этой причине пользовательские расширенные атрибуты разрешены только для обычных файлов и каталогов, а доступ к пользовательским расширенным атрибутам разрешён только владельцу и пользователям с соответствующими мандатами для каталогов с установленным закрепляющим битом (описание закрепляющего бита смотрите в справочной странице chmod(1)).

### Различия с файловой системой
Ядро и файловая система могут ограничивать максимальное количество и размер расширенных атрибутов, которые можно связать с файлом. size of extended attributes that can be associated with a file. VFS налагает ограничение на длину имени атрибута в 255 байт и на значение атрибута в 64 КБ. Размер возвращаемого списка имён атрибутов также ограничивается 64 КБ (смотрите раздел ДЕФЕКТЫ в listxattr(2)).

Для использования пользовательских расширенных атрибутов в некоторых файловых системах, таких как Reiserfs (и, исторически, ext2 и ext3), требуется, чтобы файловая система была смонтирована с параметром монтирования user_xattr.

В текущих реализациях файловых систем ext2, ext3 и ext4 общее количество байт, используемое для имён и значений расширенных атрибутов всех файлов, должно помещаться в один блок файловой системы (1024, 2048 или 4096 байт, в зависимости от размера блока, указанного при создании файловой системы).

В реализациях файловых систем Btrfs, XFS и Reiserfs нет ограничения на количество расширенных атрибутов, связанных с файлом, а для хранения информации о расширенных атрибутах на диске используются масштабируемые алгоритмы.

В реализациях файловых систем JFS, XFS и Reiserfs ограничение на количество байт, используемых для значения EA, задаётся потолком VFS.

В реализации файловой системы Btrfs общее количество байт, используемое для имени, значения и расходов реализации, ограничено значением файловой системы nodesize (по умолчанию 16 КБ).

## СООТВЕТСТВИЕ СТАНДАРТАМ
Расширенные атрибуты не описаны в POSIX.1, но некоторых других системах (например, BSD и Solaris) есть подобное свойство.

## ЗАМЕЧАНИЯ
Так как файловые системы, на которых хранятся расширенные атрибуты, также могут использоваться на архитектурах с разным порядком байт и размером машинного слова, нужно позаботиться о том, чтобы сохраняемые значения атрибутов были в архитектуро-независимом формате.

Прежде эта страница называлась attr(5).

## СМОТРИТЕ ТАКЖЕ
getfattr(1), setfattr(1), getxattr(2), ioctl_iflags(2), listxattr(2), removexattr(2), setxattr(2), acl(5), capabilities(7) selinux(8)


audit.rules

package: man-pages-ru-extra

title: audit.rules(7)

text:
# audit.rules(7)

## ИМЯ
audit.rules - набор правил, загруженных в подсистему аудита ядра

## ОПИСАНИE
audit.rules - файл, содержащий правила аудита, которые будут загружаться скриптом инициализации демона аудита при каждом запуске демона. Для выполнения этой операции используется программа auditctl. Синтаксис для правил в основном такой же, как при вводе команды auditctl в командной строке, за исключением того, что не нужно вводить имя команды auditctl. Правила аудита бывают трех видов: управление, файловая система и системные вызовы.

### Управление
Команды управления обычно включают в себя настройку системы аудита, а не указание того, что нужно отслеживать. Эти команды обычно включают в себя удаление всех правил, установку размера очереди невыполненных заданий ядра, установку режима сбоя, установку предела частоты событий или команду auditctl - игнорировать синтаксические ошибки в правилах и продолжать загрузку. Как правило, эти правила находятся вверху файла правил.

### Файловая система
Правила файловой системы иногда называются точками наблюдения. Эти правила используются для аудита доступа к определенным файлам или каталогам. Если путь, указанный в правиле наблюдения, является каталогом, то используемое правило применяется рекурсивно до конца дерева каталогов, исключая любые каталоги, которые могут быть точками монтирования. Синтаксис этих точек наблюдения обычно соответствует следующему формату:

```
-w путь_к_файлу -p права_доступа -k ключевое_слово
```

гда права_доступа могут принмать следующие значения:

r

- чтение

w

- запись

x

- исполнение

a

- изменение атрибута

Точки доступа также могут быть созданы с использованием формата системного вызова, описанного ниже, который обеспечивает большую гибкость и возможности. Используя правила системных вызовов, можно использовать параметр path и dir соответственно перед конкретным файлом или каталогом. Также следует отметить, что рекурсивное наблюдение за каталогом будет остановлено, если подкаталогом окажется точка монтирования. Используя правило -q можно сделать монтируемое поддерево эквивалентным просматриваемому каталогу.

### Системные вызовы
Правила системных вызовов загружаются в соответствующий механизм, который перехватывает каждый системный вызов, создаваемый всеми программами в системе. Поэтому очень важно использовать правила системных вызовов только тогда, когда это необходимо, поскольку они влияют на производительность. Однако производительность можно повысить, объединив системные вызовы в одно правило тогда, когда это возможно.

В ядре Linux доступно 4 вида списков или фильтров, как их иногда называют. Это: task, exit, user и exclude.

Список task проверяется только в системных вызовах fork() или clone(). Он редко используется на практике.

Список exit применяется когда необходимо создать событие для аудита, привязанное к точкам выхода из системных вызовов.

Список user используется ядром, чтобы отфильтровать события приходящие из пользовательского пространства. По умолчанию любое событие, происходящее в пространстве пользователя, отслеживается. Если есть какие-то события, которые не нужно отслеживать, то это, то место, где они могут быть удалены. Для просмотра допустимых полей см. auditctl(8).

Фильтр exclude используется, чтобы отфильтровывать ненужные события. Msgtype и ряд атрибутов субъекта могут использоваться для сообщения ядру, какие типы сообщений не нужно записывать. Этот фильтр может удалить событие в целом и не избирателен ни к какому другому атрибуту. Фильтры user и exit лучше подходят для выборочного аудита событий. Поле действие игнорируется для этого фильтра, значение по умолчанию "never" ("никогда").

Правила системных вызовов имеют вид:

```
-a действие,список -S системный_вызов -F поле=значение -k ключевое_слово
```

Параметр -a указывает, что правило нужно добавить в конец списка правил. Также следует указать, к какому списку правил оно относится, и какое действие предпринимать при его срабатывании. Допустимые действия:

always

- всегда создавать событие

never

- никогда не создавать событие

Действие и список разделяются запятой, без пробела. Допустимые списки: task, exit, user и exclude. Их значение было объяснено ранее.

Далее в правиле обычно указывается параметр -S. Значение этого параметра может быть именем или номером системного вызова. Для удобства чтения почти всегда используется имя системного вызова. В правиле можно указать более одного системного вызова, указав еще один параметр -S. При отправке в ядро поля системного вызова помещаются в маску, чтобы одно сравнение могло определить, представляет ли системный вызов интерес. Таким образом, использование нескольких системных вызовов в одном правиле очень эффективно. При указании имени системного вызова auditctl будет искать имя в таблице системных вызовов и преобразовывать его в номер. Это приводит к некоторым проблемам в двухархитектурных системах. Номера системных вызовов на 32- и 64-битных системах не всегда совпадают. Таким образом, чтобы решить эту проблему, как правило, нужно разбить правило на 2, одно из которых указывает -F arch=b32, а другое -F arch=b64. Этот параметр должен быть записан перед параметром -S, чтобы auditctl просматривал правильную таблицу системных вызовов.

После указания системного вызова, в правиле обычно указывают один или несколько параметров -F. Для просмотра всех допустимых полей смотри руководство auditctl(8).

Система аудита считает что идентификатор пользователя - это неотрицательные числа. Система аудита использует число -1, чтобы указать, что логин не установлен. При выводе оно будет отображаться как 4294967295. При написании правила, для поиска всех действительных пользователей системы, нужно заглянуть в файл /etc/login.defs, чтобы увидеть, где начинаются учетные записи пользователей. Например, если UID_MIN равен 500, также необходимо принять во внимание то, что представление без знака числа -1, также больше 500. Эту проблему можно решить с помощью следующего фрагмента правила:

```
-F auid>=500 -F auid!=4294967295
```

Оба эти условия должны быть истиной.

Последнее, что нужно знать о правилах системных вызовов, то что к правилу можно добавить ключевое поле, которое представляет собой текстовую строку произвольной формы, добавляемую к событию, чтобы помочь определить его значение. Более подробно это обсуждается в разделе ПРИМЕЧАНИЯ.

## ПРИМЕЧАНИЯ
Целью аудита является возможность проводить расследование (периодически или всякий раз, когда происходит инцидент). Несколько простых шагов в планировании могут сделать эту работу проще. Хороший совет - использовать ключевые слова в точках наблюдения и правилах системных вызовов, чтобы придать правилу смысл. Если правила связаны или вместе отвечают определенному требованию, присвойте им общее ключевое слово. Ключевое слово можно использовать во время просмотра журналов, чтобы выбрать только результаты с определенным значением.

Проведение расследования обычно начинается с вывода основного отчета, чтобы получить представление о том, что происходит в системе. Этот отчет в основном пказывает события, которые жестко запрограммированы системой аудита, таких как вход/выход, использование процедуры аутентификации, системные аномалии, сколько пользователей имеют доступ к системе и обнаружил ли SELinux какие-либо AVC.

```
aureport --start this-week
```

Посмотрев отчет, вы, вероятно, захотите получить второе представление о правилах, которые запускались. Здесь становятся важными ключи. Вывести сводный отчет о ключах можно следующим образом:

```
aureport --start this-week --key --summary
```

Это даст упорядоченный список ключей, связанных с запускаемыми правилами. Например, при наличии такого правила аудита системного вызова (правило срабатывает при сбое открытия файлов с помощью EPERM, для него задано ключевое поле access):

```
-a always,exit -F arch=b64 -S open -S openat -F exit=-EPERM -k access
```

Затем можно изолировать эти ошибки с помощью ausearch и направить результаты в aureport для отображения. Предположим, расследование обнаружило множество событий типа "отказано в доступе". Для того чтобы просмотреть файлы, к которым была предпринята попытка несанкционированного доступа, можно выполнить следующую команду:

```
ausearch --start this-week -k access --raw | aureport --file --summary
```

В результате будет получен упорядоченный список, показывающий, доступ к каким файлам заканчивался ошибкой EPERM. Предположим, что вы хотите узнать, какие пользователи предпринимали неудачную попытку доступа, для этого следует выполнить команду:

```
ausearch --start this-week -k access --raw | aureport --user --summary
```

Если ваше расследование показало много неудачных обращений к конкретному файлу, вы можете запустить следующий отчет, чтобы узнать, кто обращался к файлу:

ausearch --start this-week -k access -f /path-to/file --raw | aureport --user -i

Этот отчет покажет попытки доступа отдельно для каждого пользователя. Если нужно увидеть конкретное событие аудита, о котором сообщается, необходимо просмотреть значения даты, времени и номера события. Предполагая, что номер события 822 и оно произошло 09/01/2009 в 2:30 команда будет выглядеть следующим образом:

```
ausearch --start 09/01/2009 02:30 -a 822 -i --just-one
```

Эта команда выведет первое событие за указанную дату и время, с соответствующим идентификатором события, и интерпретирует числовые значения в удобочитаемые значения.

Самым важным шагом к выполнению такого анализа является настройка ключевых полей, при написании правил. Следует также отметить, что с любым правилом может быть связано несколько ключевых полей.

## СООБЩЕНИЯ ОБ ОШИБКАХ
Если вы не получаете события по правилам системных вызовов, которые, по вашему мнению, должны быть выполнены, попробуйте запустить тестовую программу под strace, чтобы вы могли видеть системные вызовы. Есть вероятность, что вы определили неверный системный вызов.

Если вы получите следующее предупреждение от auditctl: "32/64 bit syscall mismatch in line XX, you should specify an arch", это означает, что вы указали правило системного вызова в системе с двумя архитектурами, где системный вызов имеет разные номера для 32- и 64-битных интерфейсов. Это означает, что на одном из этих интерфейсов вы, вероятно, проверяете неверный системный вызов. Для решения этой проблемы, перепишите правило как два правила, определяя предполагаемую архитектуру для каждого правила. Например, правило:

```
-always,exit -S openat -k access
```

может быть переписано как:

```
-always,exit -F arch=b32 -S openat -k access
-always,exit -F arch=b64 -S openat -k access
```

Если вы получите предупреждение: "entry rules deprecated, changing to exit rule", это означает, что у вас есть правило, предназначенное для фильтрации записей, но этот фильтр больше не доступен. Auditctl переместил ваше правило в фильтр exit, чтобы оно не потерялось. Для решения этой проблемы, чтобы больше не получать этого предупреждение, вам нужно изменить нарушающее правило с entry на exit.

## ПРИМЕРЫ
Следующее правило показывает, как проводить аудит неудачного доступа к файлам, связанного с проблемами прав доступа. Обратите внимание, что для каждой архитектуры требуется два правила, поскольку доступ к файлу может завершиться с двумя разными кодами ошибок, указывающими на проблемы с правами доступа.

```
-a always,exit -F arch=b32 -S open -S openat -F exit=-EACCES -k access
-a always,exit -F arch=b32 -S open -S openat -F exit=-EPERM -k access
-a always,exit -F arch=b64 -S open -S openat -F exit=-EACCES -k access
-a always,exit -F arch=b64 -S open -S openat -F exit=-EPERM -k access
```

## СМ. ТАКЖЕ
auditctl(8), auditd(8).

## АВТОР
Стив Граб (Steve Grubb)

## ПЕРЕВОД
Перевод с английского Elena Mishina <lepata@altlinux.org> 2019


ldp

title: ldp(7)

text:
# ldp(7)

## ИМЯ
LDP - Введение в Проект Документации Linux (Linux Documentation Project), помощь, руководства и документы

## ОБЗОР
Проект Документации Linux (сокращеное английское название LDP) предоставляет сообществу Linux разные виды свободных и бесплатных ресурсов документации, включая руководства, FAQ (список часто задаваемых вопросов), HOWTO и страницы руководства man.

## АВТОРЫ
Различные документы в архивах LDP сопровождаются отдельными авторами, которые указываются в начале каждого документа HOWTO. Если у вас есть какие-либо вопросы или дополнения к документу, мы призываем вас напрямую связаться с авторами.

## WEB-СТРАНИЦЫ
LDP имеет свой собтвенный web-сайт и поддерживает множество разных проектов переводов, которые связаны с главным web-сайтом LDP, адрес которого

http://www.tldp.org/

вы, возможно, захотите добавить к своим загладкам.

## СТРАНИЦЫ РУКОВОДСТВА MAN
Существует web-страница с информацией о состоянии и переводах страниц руководства man по адресу

http://www.win.tue.nl/~aeb/linux/man/

## СПИСКИ РАССЫЛКИ
LDP имеет несколько списков рассылки, таких как

<announce@en.tlpd.org>

Анонсы проекта LDP

<discuss@en.tldp.org>

Общая дискуссия по проекту LDP

<docbook@en.tldp.org>

Вопросы об использовании DocBook

Информацию о том, как подписаться на эти списки рассылки, смотрите на указаннм выше сайте.

Если вы интересуетесь как написать ваш документ для проекта LDP с помощью DocBook, то, верояно, вы захотите также подписаться на один из списков рассылки OASIS DocBook. Информацию о том как это сделать, смотрите по адресу http://docbook.org/mailinglist/index.html.

## ФАЙЛЫ
Большинство дистрибутивов включают в установку документы HOWTO и mini-HOWTO

/usr/doc/ (старое место для документации)

/usr/share/doc/ (новое место для документации)

/usr/share/doc/HOWTO/ (файлы HOWTO)

/usr/share/doc/HOWTO/mini/ (файлы mini-HOWTO)

## СМОТРИ ТАКЖЕ
man(1), xman(1x), info(1)

страницы info, которые можно прочитать с помощью emacs(1) или info(1)

## ПЕРЕВОД
Перевёл с английского Виктор Вислобоков <corochoone@perm.ru> 2005