Installing Inferno Software / Установка ОС Inferno: Chapter 1

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

rapidfx 01.05.09 в 16:59

В сети Inferno обычно одна машина действует как сервер аутентификации. Все другие системы играют роли серверов и клиентов как и требуется от них: любая система может импортировать некоторые ресурсы (или никакие), одновременно, и разные в разных пространствах имен. В следующих разделах, мы опишем три четко различимые разные машины: сервер аутентификации (signer); сервер (экспортирующий ресурсы); и клиент (импортирующий ресурсы).
С Inferno, вы можете достичь схожего эффекта на еинственной машине запустив одновременно несколько экземпляров emu. Это самы простой путь ознакомиться с процессом (и также избежать установки системы на нескольких машинах). Это является ценным , позднее при установке безопасного сервера аутентификации, особенно если вы пользуетесь Windows на файловой системе FAT, когда защита файлов основной ОС ограничена.
Мы должны теперь сконфигурировать Inferno для реализации каждой из функций перечисленных выше:

rapidfx 01.05.09 в 17:12

* изменить сетевую базу данных для того чтобы найти локальные сетевые ресурсы
* установить систему аутентификации, особенно сервер аутентификации "signer"
* запустить сетевые сервисы (два разных набора: один для аутентификационного сервиса и другой для всех остальных сетевых сервисов)

rapidfx 01.05.09 в 17:14

9. Файлы сетевых баз данных

j1m 23.04.09 в 09:14

И в хостед и в нативном режимах, Inferno пользуется коллекцией текстовых файлов в подробной форме хранящей все детали сетевой конфигурации и сервисов. Когда Inferno запущена поверх ОС, Inferno получает большинство данных из основной операционной системы, и база данных содержит специфичную для Inferno данные.
Файл /lib/ndb/local является корневым хранилищем сетевой базы данных. Его формат определяется в ndb(6), но по сути является набором пар атрибут/значение в форме атрибут=значение.
Имена атрибутов и большинтсва значений чувствительны к регистру. Соответствующие пары атрибут/значение сгруппированы в базе данных по "вхождениям" (проводкам/статьям). Вхождение может состоять из одной или нескольких строк: первая строка начинается с не пробельного символа, любая вложенная последовательность строк в которых вхождения начинаются с пробела (или табуляции).

rapidfx 01.05.09 в 17:35

9.1. Параметры системы/сайта

rapidfx 01.05.09 в 17:36

Версия файла /lib/ndb/local записываемая во время инсталяции имеет вид:

rapidfx 01.05.09 в 17:36

database=
file=/lib/ndb/local
file=/lib/ndb/dns
file=/lib/ndb/inferno
file=/lib/ndb/common
infernosite=
#dnsdomain=ваш.домен.com
#dns=1.2.3.4 # resolver
SIGNER=your_Inferno_signer_here
FILESERVER=your_Inferno_fileserver_here
smtp=your_smtpserver_here
pop3=your_pop3server_here
registry=your_registry_server

j1m 23.04.09 в 09:15

Индивидуальные файлы формирующие базу перечислены по порядку во вхождениях базы данных. Они пока могут быть проигнорированы. Вхождение помеченное как infernosite= определяет отображение (mapping) из символических имен хостов в форме $service в имя хоста, имя домена, или числовой интернет адрес. Например, приложение которое нуждается в сервисе аутентификации будет ссылаться на $SIGNER и сервис имен Inferno оттранслирует в момент выполнения в соответствующее сетевое имя этого окружения. Следовательно, вхождения выше нуждаются в исправлении для данной системы. (Пункты которые закоментированы не являются необходимыми, когда хост сам выполняет функцию DNS-резолвера, вместо собственного dns(8) в Inferno.)
Например, наш пункт infernosite в файле local может выглядеть следующим образом:

rapidfx 01.05.09 в 17:54

infernosite=
dnsdomain=vitanuova.com
dns=200.1.1.11 # resolver
SIGNER=doppio
FILESERVER=doppio
smtp=doppio
pop3=doppio
registry=doppio

j1m 23.04.09 в 09:15

где doppio является именем хоста которое предлагает сервисы Inferno, и 200.1.1.11 это Internet-адресс локального DNS-резолвера.

rapidfx 01.05.09 в 17:56

Шаг 9a: Внесение данных по-умолчанию для вашего сайта

rapidfx 01.05.09 в 17:57

Важнейшими именами являются:

rapidfx 01.05.09 в 18:02

SIGNER - имя хоста или домена, или адрес машины которая будет играть роль "signer" (центр авторизации - CA).
registry - регистратора имен или адресов машин которые предоставляютлокальный динамический сервис registry(4).
FILESERVER - первичный файловый сервер (в действительности требующийся только тем клиентам, которые не имеют своего файлового хранилища)

rapidfx 01.05.09 в 18:06

Все другие используются специфическими приложениями такими как acme(1) mail или ftpfs(4).
Если вы используете одиночную машину как signer и клиент/сервер, поестите ее имя во все эти три вхождения.

rapidfx 01.05.09 в 18:08

9.2. Сервер соединений cs(8) и трансляция имен

rapidfx 01.05.09 в 18:09

Сервер соединений cs(8) пользуется сетевой базой данных и другими данными (которые например, преоставляет основная ОС и серверы DNS) для преобразования символических сетевых имен или сервисов в инструкции для соединения с указанным сервисом. В хостед-режиме, сеть и имена сервисов передаются через основную ОС для преобразования числовых IP адресов и номеров портов. Если основной ОС не удается преобразовать имя сервиса, сервер соединений попытается преобразовать имя используя отображение (mapping) сервисов и имен протоколов в номера портов в соответствии с файлом /lib/ndb/inferno:

rapidfx 01.05.09 в 18:16

tcp=infgamelogin port=6660 # inferno games login service
tcp=styx port=6666 # main file service
tcp=mpeg port=6667 # mpeg stream
tcp=rstyx port=6668 # remote invocation
tcp=infdb port=6669 # database server
tcp=infweb port=6670 # inferno web server
tcp=infsigner port=6671 # inferno signing services
tcp=infcsigner port=6672 # inferno countersigner
tcp=inflogin port=6673 # inferno credential service
tcp=infsds port=6674 # software download
tcp=registry port=6675 # registry(4)
udp=virgil port=2202 # naming service

j1m 23.04.09 в 09:20

Пока оставим этот файл как есть. Вам потребуется изменить его только в том случае, если вы добавите новый статически сконфигурированный сервис Inferno. (Сервисы которые запускаются динамически могут использовать registry(4), менеджер регистраций позволяет найти сервис по его описанию)

rapidfx 01.05.09 в 18:20

10. Настройка Signer

j1m 23.04.09 в 09:16

Перед тем как Inferno-машина сможет аутентифицировать установленное безопасное соединение к другому Inferno-сервису на другой машине, каждая система должна получить сертификат из одного источника - центра сертификации (CA). Мы поговорим здесь только об одном CA на систему, хотя фактически все зависит от специфики приложения или задачи группы. Например, Inferno-версия игрового сервера автоматически запускает собственный CA для хранения идентификаторов и ключей используемых игровым сервисом отдельно от основносй системы, позволяя пользователям без суеты формировать их собственную игровую группу. Для использования аутентифицированных соединений с первичным файловым сервисом нам надо установить доверенную выдачу сертификатов для пользователей (signer) (смотрите createsignerkey(8) and logind(8)).
Выберите Inferno-машину для выполнения функции signer. Если она первая или единственная машина вашей сети, тогда создайте signer на ней. (Будет более наглядным, если вы заупстите отдельно еще одну копию emu и оставите ее в консольном режиме, без запуска графической системы.) Позднее вы можете передать эту функцию другой машине.

rapidfx 02.05.09 в 07:57

Шаг 10a: Создание пустого файла паролей

rapidfx 01.05.09 в 18:31

Сервер аутентификации проверяет подлинность пользователя путем проверки того, что пользователь знает общий секрет (пароль). (В действительности секрет не используется напрямую, вместо этого передается полученное от него зашифрованное значение.) Файл /keydb/keys содержит эти секреты; он зашифрован с ипользованием пароля или фразы известной только менеджеру сервера аутентификации. После установки Inferno этот файл должен существовать и и быть доступным для чтения только вам ()или пользователям которые запускают сервис аутентификации. На signer-машине наберите:

rapidfx 03.05.09 в 07:05

ls -l /keydb/keys

j1m 23.04.09 в 09:16

Вы должны увидеть что-то вроде этого:

j1m 23.04.09 в 09:16

--rw------- M 7772 yourname inf 0 Jun 12 03:08 /keydb/keys

j1m 23.04.09 в 09:16

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

rapidfx 01.05.09 в 18:33

cp /dev/null /keydb/keys; chmod 600 /keydb/keys

j1m 23.04.09 в 09:17

для их правильной установки.

Шаг 10b: Генерирование ключа signer/центра авторизации

rapidfx 01.05.09 в 18:34

Далее, на машине signer, выполните

rapidfx 01.05.09 в 18:35

auth/createsignerkey name

j1m 23.04.09 в 09:17

В качестве имени укажите сетевое имя signer-машины. Это может быть полное доменное имя FQDN хоста или короткое имя. Это значение будет фигурировать в качестве имени signer в каждом сертификате генерируемом signer. Createsignerkey создает пару публичный/приватый ключей которые используются signer для выдачи сертификатов. Они храняться в /keydb/signerkey; убедитесь что правами на этот файл обладает только пользователь запускающий сервис аутентификации:

rapidfx 03.05.09 в 07:14

; ls -l /keydb/signerkey
--rw------- M 32685 secrets inf 1010 Jul 07 2000 /keydb/signerkey

j1m 23.04.09 в 09:17

Используйте chmod() чтобы установить режим чтения и записи только для владельца:

j1m 23.04.09 в 09:18

chmod 600 /keydb/signerkey

Шаг 10c: Запуск сетевых сервисов аутентификации

j1m 23.04.09 в 09:19

Находясь в консоли signer, наберите

rapidfx 01.05.09 в 18:35

svc/auth

j1m 23.04.09 в 09:19

Этот скрипт (смотри svc(8)) что файлы /keydb/keys и /keydb/signerkey существуют, и затем запускает программу keyfs(4), которая управляет файлом ключей. Она запрашивает пароль (ключевую фразу) которой вы хотите защитить свой файл ключей:

rapidfx 03.05.09 в 07:17

; svc/auth
Key:
Confirm key:

j1m 23.04.09 в 09:19

Приглашение появляется дважды для подтверждения. Если подтверждение успешно прошло, запускается сетевой сервис использующийся Inferno для аутентификации локальныйх и удаленных пользоватлей и хостов. (Если произошел сбой подтверждения, попробуйте снова заупстить svc/auth.)
Вы можете проверить что они запущены набрав:

rapidfx 03.05.09 в 07:20

ps

j1m 23.04.09 в 09:21

которая должна показать что-то вроде этого:

j1m 23.04.09 в 10:21

1 1 john release 74K Sh[$Sys]
3 2 john alt 15K Cs
10 9 john recv 25K Keyfs
11 9 john release 44K Styx[$Sys]
12 9 john recv 25K Keyfs
14 1 john alt 8K Listen
16 1 john release 8K Listen[$Sys]
18 1 john alt 9K Listen
20 1 john release 9K Listen[$Sys]
22 1 john alt 9K Listen
24 1 john release 9K Listen[$Sys]
26 1 john alt 8K Listen
28 1 john release 8K Listen[$Sys]
29 1 john ready 73K Ps[$Sys]

j1m 23.04.09 в 09:21

В списке должны присутствовать процессы Keyfs и Listen.

Шаг 10d: Ввод имен пользователей и секретных данных.

j1m 23.04.09 в 09:22

Для каждого пользователя проверяемого signer запустите

rapidfx 03.05.09 в 07:21

auth/changelogin username

j1m 23.04.09 в 09:22

У вас попросят набрать секрет (это может быть пароль или ключавая фраза) и дату истечения срока действия пароля. Эта дата будет использоваться как крайний срок действия сертификата выданного пользователю.
Changelogin (смотри changelogin(8)) получает доступ к пространству имен созданному keyfs(4), запущенному при старте svc/auth. Пользователь может позже изменить хранимый секрет при помощи команды passwd(1). Для signer генерирующего сертификат должна существовать хотя бы одна записть в файле паролей. Если на этом этапе вы не знаете имена пользователей которых вы хотите аутентифицировать, тогда создайте записи для пользователя inferno и для себя.

rapidfx 03.05.09 в 07:30

11. Создание безопасного соединения

j1m 23.04.09 в 09:23

Для установления безопасного соединения между двумя Inferno-машинами, каждая из них нуждается в публичном ключе с сертификатом подписанным общим signer. Мы сделаем два набора публичных/приватных ключей, один для сервера, другой для клиента (их разница только в том, что хранятся они в разных местах). Мы должны сделать это сначала для сервера, поскольку обычные сетевые сервисы требуют чтобы сервер хранил несколько ключей перед тем как они будут запущены. Затем мы запустим эти сервисы, и наконец отсортируем клиентов.

Шаг 11a: Запуск сервиса соединений
Сервер все еще нуждается в установлении связи с signer, так что нам надо запустить основной сервис соединений cs(8). Если вы воспользуетесь той же копией emu в которой вы запустили раньше svc/auth, вы можете пропустить этот шаг. Для проверки, вы может убедиться что появился новый файл cs в директории /net. Запустите команду

rapidfx 03.05.09 в 07:42

ls /net

rapidfx 03.05.09 в 07:42