rapidfx: переводы
Installing Inferno Software / Установка ОС Inferno
→Every inferno process has an associated user name. At boot time the user name is set equal to your login
name on the host operating system. The user name is used by wm/logon to select the home directory, and by
other programs like mount when it searches for certificates. (It can also control permission for file access on
the local system in native Inferno and some hosted Inferno configurations.) When you attach to a server on
another system the user name in the authenticating certificate can be used by the remote file service to set
the user name appropriately there.?
To create a new user, copy the directory /usr/inferno into /usr/username. If the user is to have access
to services on the network, make an authentication server entry using changelogin(8). The user can change
the stored secret using passwd(1), if desired. Having logged in for the first time, the user should generate a
default public/private key set using getauthinfo(8). (The authentication services must be running some-
where.)
The wm window manager program wm/logon allows a user to login to the local Inferno system as an Inferno
user (different from the host user name). Its use is shown next.
name on the host operating system. The user name is used by wm/logon to select the home directory, and by
other programs like mount when it searches for certificates. (It can also control permission for file access on
the local system in native Inferno and some hosted Inferno configurations.) When you attach to a server on
another system the user name in the authenticating certificate can be used by the remote file service to set
the user name appropriately there.?
To create a new user, copy the directory /usr/inferno into /usr/username. If the user is to have access
to services on the network, make an authentication server entry using changelogin(8). The user can change
the stored secret using passwd(1), if desired. Having logged in for the first time, the user should generate a
default public/private key set using getauthinfo(8). (The authentication services must be running some-
where.)
The wm window manager program wm/logon allows a user to login to the local Inferno system as an Inferno
user (different from the host user name). Its use is shown next.
0 Каждый процесс Inferno ассоциирован с именем определенного пользователя. Во время загрузки имя пользователя устанавливается в ваше login-имя основной ОС. Имя пользователя импользуется wm/logon для выбора домашнего каталога, и другими программами типа mount когда он ищет сертификаты. (Они так же имеют установленные права доступа основной ОС или нативно запущенной ОС Inferno.) Когда вы присоединяетесь к серверу другой системы, имя пользователя в аутентификационном сертификате берется удаленным файловым сервисом для установления соответствующего пользовательского имени.
Для создания нового пользователя, скопируйте каталог /usr/inferno в /usr/username. Если пользователь имеет доступ к сервисам сети, создайте запись на сервере аутентификации при помощи changelogin(8). Пользователь может изменить хранящийся секрет при помощи passwd(1), если пожелает. Когда пользователь залогинивается в первый раз, он должен сгенерировать пару публичный/приватный ключ при помощи getauthinfo(8). (При этом аутентификационный сервис должен быть уже где-то запущен.)
Программа оконного менеджера wm, wm/logon позволяет пользователю авторизоваться на локальной системе Inferno, как другой Inferno-пользователь (имя которого отличается от имени пользователя основной ОС). Ее использование показано дальше.
Для создания нового пользователя, скопируйте каталог /usr/inferno в /usr/username. Если пользователь имеет доступ к сервисам сети, создайте запись на сервере аутентификации при помощи changelogin(8). Пользователь может изменить хранящийся секрет при помощи passwd(1), если пожелает. Когда пользователь залогинивается в первый раз, он должен сгенерировать пару публичный/приватный ключ при помощи getauthinfo(8). (При этом аутентификационный сервис должен быть уже где-то запущен.)
Программа оконного менеджера wm, wm/logon позволяет пользователю авторизоваться на локальной системе Inferno, как другой Inferno-пользователь (имя которого отличается от имени пользователя основной ОС). Ее использование показано дальше.
→makes an authenticated connection to the machine given by serveraddr, then engages SHA1 hashing for mes-
sage digesting and 256-bitRC4 for encryption.
It mounts the namespace served by serveraddr?s Styx service on the local Inferno directory /n/remote.
sage digesting and 256-bitRC4 for encryption.
It mounts the namespace served by serveraddr?s Styx service on the local Inferno directory /n/remote.
0 устанавливает аутентифицированное соединение с машиной заданной serveraddr, и запускает хэширование SHA1 с подписыванием сообщений (дайджестом), и 256-битное шифрование RC4. Эта команда монтирует пространство имен обслуживаемое на указанной машине serveraddr сервисом Styx, в локальный каталог Inferno /n/remote.
→For example,
0 Например,
→All connections made by Inferno are authenticated. The default connection made by mount is authenticated
but uses neither encryption nor secure digests. You can pass an argument to mount to specify a more secure
connection: its -C option gives it a hashing and an encryption algorithm to be applied to the connection.
Step 12d: Make a secure authenticated connection.
but uses neither encryption nor secure digests. You can pass an argument to mount to specify a more secure
connection: its -C option gives it a hashing and an encryption algorithm to be applied to the connection.
Step 12d: Make a secure authenticated connection.
0 Все соединения устанавливаемые Inferno аутентифицированы. По умолчанию соединения устанавлевыемые mount аутентифицированы, но не используют ни шифрование, ни подписывание сообщений. Вы можете передать аргументы mount для указания безопасного соединения: опция -C включает хэширование и применяет алгоритм шифрования к соединению.
Шаг 12d: Создание безопасного аутентифицированного соединения
Шаг 12d: Создание безопасного аутентифицированного соединения
→You can confirm that it has gone by running
0 Вы можете убедиться что содержимое пропало запустив
→should reveal the files and directories in the namespace being served by the server. Those files are now also
visible in the namespace of your shell. You will notice that these changes only affect the shell in which you
ran the mount command ? other windows are unaffected. You can create, remove or modify files and direc-
tories in and under /n/remote much as you can any other file or directory in your namespace. In fact, in
general, a process does not need to know whether a file actually resides locally or remotely. You can
unmount the mounted directory with unmount. Type
visible in the namespace of your shell. You will notice that these changes only affect the shell in which you
ran the mount command ? other windows are unaffected. You can create, remove or modify files and direc-
tories in and under /n/remote much as you can any other file or directory in your namespace. In fact, in
general, a process does not need to know whether a file actually resides locally or remotely. You can
unmount the mounted directory with unmount. Type
0 должно выдать файлы и каталоги в пространстве имен облуживаемом сервером. Все эти файлы теперь также видны в пространестве имен вашего командного интерпретатора.
Мы должны отметить, что эти изменения оказывают влияние только на тот интерпретатор в котором вы выполнили команду mount, все остальные окна остаются без изменений. Вы можете создавать, удалять или изменять файлы и каталоги ниже /n/remote так, как вы могли бы поступить со своими файлами. Фактически, процессу не надо знать где в действительности расположен файл локально или уаленно. Вы можете размонтировать смонтированную директорию при помощи команды unmount. Выполните
Мы должны отметить, что эти изменения оказывают влияние только на тот интерпретатор в котором вы выполнили команду mount, все остальные окна остаются без изменений. Вы можете создавать, удалять или изменять файлы и каталоги ниже /n/remote так, как вы могли бы поступить со своими файлами. Фактически, процессу не надо знать где в действительности расположен файл локально или уаленно. Вы можете размонтировать смонтированную директорию при помощи команды unmount. Выполните
→Where serveraddr is the IP address of the server or a name that the host can resolve to the IP address of the
server. Now
server. Now
0 Где serveraddr это IP адрес сервера или имя хоста которое может быть соотнесено с IP адресом сервера.
Теперь
Теперь
→You can now mount the server?s name space onto the client?s directory /n/remote by typing
0 Вы можете примонтировать пространство имен сервера в каталог клиента /n/remote набрав
→The script svc/net on the server started fundamental name services and also a Styx file service. That can
also be started separately using svc/styx. In either case the namespace that is served is the one in which
the command was invoked. Now you can test the service.
Confirm that /n/remote is an empty directory by typing
also be started separately using svc/styx. In either case the namespace that is served is the one in which
the command was invoked. Now you can test the service.
Confirm that /n/remote is an empty directory by typing
0 Скрипт svc/net запускает на сервере фундаментальный сервис имен и файловый сервис Styx. Он так же может быть запущен отдельно при помощи svc/styx. В любом случае пространство имен имен которое он будет обслуживать является тем же самым из которого был вызван скрипт. Теперь вы можете протестировать сервис.
Убедимся что каталог /n/remote пуст, набрав следующее
Убедимся что каталог /n/remote пуст, набрав следующее
→Use the current machine?s hostname. Getauthinfo stores the certificate in the file
/usr/user/keyring/keyname where user is the name in /dev/user and keyname is the argument given to
getauthinfo. Again, answer yes to the question that asks if you want to save the certificate in a file.
Now that both client and server have a certificate obtained from the same signer it is possible to establish a
secure connection between them. Note that getting keys and certificates with getauthinfo is normally done
just once (or at most once per server when the default key is not used). In short, all the work done up to
now need not be repeated. After this, provided the keys were saved to a keyring file, as many authenti-
cated connections can be made as desired until the certificate expires (which by default is whenever the
password entry was set to expire). Also note that the certificates for different machines can have different
signers, and one can even use different certificates for the same machine when the remote user name is to
differ (the -f option of getauthinfo can then be useful to force an appropriate keyring name).
Step 12c: Make an authenticated connection.
/usr/user/keyring/keyname where user is the name in /dev/user and keyname is the argument given to
getauthinfo. Again, answer yes to the question that asks if you want to save the certificate in a file.
Now that both client and server have a certificate obtained from the same signer it is possible to establish a
secure connection between them. Note that getting keys and certificates with getauthinfo is normally done
just once (or at most once per server when the default key is not used). In short, all the work done up to
now need not be repeated. After this, provided the keys were saved to a keyring file, as many authenti-
cated connections can be made as desired until the certificate expires (which by default is whenever the
password entry was set to expire). Also note that the certificates for different machines can have different
signers, and one can even use different certificates for the same machine when the remote user name is to
differ (the -f option of getauthinfo can then be useful to force an appropriate keyring name).
Step 12c: Make an authenticated connection.
0 Используйте имя хоста текущей машины. Getauthinfo хранит сертификаты в файле /usr/user/keyring/keyname где имя пользователя соответствует имени в /dev/user и keyname это аргумент переданный getauthinfo. Еще раз, ответьте yes на вопрос в котором спрашивается хотите ли вы сохранить сертификат в файл.
Теперь когда ба и клиент и сервер имеют сертификаты полученные от одного signer, становится возможным установление соединения между ними. Обратите внимание, что получение ключей и сертификатов с помощью getauthinfo делается только один раз (или по одному разу на тот случай если не используется ключ по умолчанию.) Короче, вся работа завершена и не требуется ее повторять. После этого, предоставленные ключи записанные в файл keyring могут создать столько аутентифицированных соединений, сколько нужно пока сертификат не будет просрочен (это зависит от того когда была установлена дата истечения срока действия пароля). Так же обратите внимание на то, что разные машины могут иметь разные центры выдачи сертификатов, и каждый может использовать различные сертификаты для одной машины когда различаются имена удаленных пользователей (опция -f getauthinfo полезна в случае принудительного выбора соответствующего имени keyring).
Шаг 12c: Установление аутентифицированного соединения.
Теперь когда ба и клиент и сервер имеют сертификаты полученные от одного signer, становится возможным установление соединения между ними. Обратите внимание, что получение ключей и сертификатов с помощью getauthinfo делается только один раз (или по одному разу на тот случай если не используется ключ по умолчанию.) Короче, вся работа завершена и не требуется ее повторять. После этого, предоставленные ключи записанные в файл keyring могут создать столько аутентифицированных соединений, сколько нужно пока сертификат не будет просрочен (это зависит от того когда была установлена дата истечения срока действия пароля). Так же обратите внимание на то, что разные машины могут иметь разные центры выдачи сертификатов, и каждый может использовать различные сертификаты для одной машины когда различаются имена удаленных пользователей (опция -f getauthinfo полезна в случае принудительного выбора соответствующего имени keyring).
Шаг 12c: Установление аутентифицированного соединения.
→Obtain a certificate for the client in the same way as on the server. We shall obtain a certificate for use with
a specific server by storing it in a file whose name exactly matches the network address of the server
a specific server by storing it in a file whose name exactly matches the network address of the server
0 Получение сертификата для клиента, то же, что и для сервера. Мы должны получить сертификат для взаимодействия с определенным сервером сохранив его в файле которое точно совпадает сетевым адресом сервера
→The connection server is fundamental to the Inferno network. Once networking is set up, when subse-
quently starting up a client you should start cs before starting the window system. Note that if you are run-
ning the Inferno instance as a server, or combined server and client, the svc/net that starts the network
services automatically starts cs, and you need not do so explicitly.
Step 12b: Generate a client certificate.
quently starting up a client you should start cs before starting the window system. Note that if you are run-
ning the Inferno instance as a server, or combined server and client, the svc/net that starts the network
services automatically starts cs, and you need not do so explicitly.
Step 12b: Generate a client certificate.
0 Сервер соединений основа сети Inferno. Когда сеть устанавливается, подпроцессы компонентов запускающие клиентов должен запустить cs перед стартом оконной системы. Заметьте, что если вы запускаете Inferno как сервер, или как комбинацию клиент и сервер, svc/net который стартует сетевые сервисы автоматически запустит cs, и вам не надо делать этого специально.
Шаг 12b: Генерация клиентского сертификата.
Шаг 12b: Генерация клиентского сертификата.
→Each line corresponds to a network connection: the connection name, the name of the user running the
server, the address of the local end of the connection, the address of the remote end of the connection, and
the connection status. The connection name is actually the protocol and conversation directory in /net.
The connection addresses are all of the form host!port for these IP based services, and the remote addresses
are not filled in because they all represent listening services that are in the Announced state. In this exam-
ple the fourth line shows a TCP service listening on port 6673. Examining /lib/ndb/inferno with grep
(see grep(1)) shows that the listener on port 6675 is the Inferno registry service
server, the address of the local end of the connection, the address of the remote end of the connection, and
the connection status. The connection name is actually the protocol and conversation directory in /net.
The connection addresses are all of the form host!port for these IP based services, and the remote addresses
are not filled in because they all represent listening services that are in the Announced state. In this exam-
ple the fourth line shows a TCP service listening on port 6673. Examining /lib/ndb/inferno with grep
(see grep(1)) shows that the listener on port 6675 is the Inferno registry service
0 Каждая строка относится к сетевому соединению: имя соединения, имя пользователя запустившего сервер, адрес локального конца соединения, адрес удаленного конца соединения, и статус соеинения. Именем соединения в действительности является протоколом и соответствующий каталог в /net.
Адрес соединения представлен в виде host!port для этого сервиса основанного на IP, а удаленные адреса не заполнены потому что они все они представлены прослушивающими срвисами в состояниии Announced. В этом примере четыре строки показываютTCP сервис слушает на порту 6673. Просмотрев /lib/ndb/inferno при помощи grep (смотри grep(1)) увидим, что на порту 6675 прослушивает Inferno-сервис registry
Адрес соединения представлен в виде host!port для этого сервиса основанного на IP, а удаленные адреса не заполнены потому что они все они представлены прослушивающими срвисами в состояниии Announced. В этом примере четыре строки показываютTCP сервис слушает на порту 6673. Просмотрев /lib/ndb/inferno при помощи grep (смотри grep(1)) увидим, что на порту 6675 прослушивает Inferno-сервис registry
→As mentioned above, in a full Inferno network the authentication services will usually be run on a secured
machine of their own (the signer), and the ordinary network services such as file service are not run on a
signer. If you are, however, using one machine for all functions, you can get the right effect by starting
another instance of emu, to act as an Inferno host that is not a signer. This one will run the services of a pri-
mary file server and the site registry(4).
Commands described in svc(8) start listeners for various local network services. (The commands are actu-
ally shell scripts.) As we saw above, svc/auth starts the services on a signer.
Here we shall start the usual set of services.
Step 12a: Start the network listener services.
machine of their own (the signer), and the ordinary network services such as file service are not run on a
signer. If you are, however, using one machine for all functions, you can get the right effect by starting
another instance of emu, to act as an Inferno host that is not a signer. This one will run the services of a pri-
mary file server and the site registry(4).
Commands described in svc(8) start listeners for various local network services. (The commands are actu-
ally shell scripts.) As we saw above, svc/auth starts the services on a signer.
Here we shall start the usual set of services.
Step 12a: Start the network listener services.
0 Как отмечалось раньше, в полной сети Inferno аутентификационные сервисы обычно запускаются на надежно защищенной машине, где запущен только сервис signer. Если для всех функций используется одна машина, вы можете достичь правильного эффекта запустив другую копию emu, чтобы выступать в роли Inferno хоста, а не signer. Он заупустит сервисы первичного файл-сервера и службу registry(4).
Команды описанные в svc(8) запускают процессы для различных сетевых сервисов. (Эти команды в действительности скрипты оболочки.) Как мы видели выше, svc/auth стартует службы на signer.
Теперь мы запустим обычный набор сервисов.
Шаг 12a: Запуск сетевых прослушивающих сервисов.
Команды описанные в svc(8) запускают процессы для различных сетевых сервисов. (Эти команды в действительности скрипты оболочки.) Как мы видели выше, svc/auth стартует службы на signer.
Теперь мы запустим обычный набор сервисов.
Шаг 12a: Запуск сетевых прослушивающих сервисов.
→Getauthinfo will prompt for the address of your signer (you can often just use its host name or even
localhost) and for a remote username and password combination. Getauthinfo will connect to the inflogin
service on the signer and authenticate you against its user and password database, /keydb/keys, using the
username and password that you entered above. Answer yes to the question that asks if you want to save
the certificate in a file. Getauthinfo will save a certificate in the file /usr/user/keyring/default where
user is the name in /dev/user.
localhost) and for a remote username and password combination. Getauthinfo will connect to the inflogin
service on the signer and authenticate you against its user and password database, /keydb/keys, using the
username and password that you entered above. Answer yes to the question that asks if you want to save
the certificate in a file. Getauthinfo will save a certificate in the file /usr/user/keyring/default where
user is the name in /dev/user.
0 Getauthinfo запросит адрес вашего signer (зачастую вы можете использовать имя хоста или даже localhost) и имя удаленного пользователя и пароль. Getauthinfo соединяется с сервисом inflogin машины-signer'а и аутентифицирет, в базе данных /keydb/keys, вас этими именем и паролем которые вы указали выше. Ответив yes на запрос о том, желаете ли вы записать сертификат в файл. Getauthinfo сохранит сертификат в файле /usr/user/keyring/default где user является тем же именем что и в /dev/user.
→On the server machine (or in the ?server? window), use getauthinfo(8) to obtain a certificate and save it in a
file named default by running
file named default by running
0 На машине-сервере (или в окне "сервера") воспользуйтесь командой getauthinfo(8) для получения сертификата и сохранения его в файле названном default, путем запуска:
→ls /net
0 ls /net
→To establish a secure connection between two Inferno machines, each needs to present a public key with a
certificate signed by a common signer. We shall make two public/private key sets, one for the server and
one for a client (they differ only in where they are stored). We shall do the server first, because the usual
network services require the server possess some keys before they can start. We shall then start those ser-
vices, and finally sort out the client.
Step 11a: Start the connection service.
The server still needs to make contact with the signer, so we need to start the basic connection service cs(8).
If you are using the same instance of emu in which you invoked svc/auth above, you should skip this
step. To check, you should see a new file in the /net directory called cs. Run the command
certificate signed by a common signer. We shall make two public/private key sets, one for the server and
one for a client (they differ only in where they are stored). We shall do the server first, because the usual
network services require the server possess some keys before they can start. We shall then start those ser-
vices, and finally sort out the client.
Step 11a: Start the connection service.
The server still needs to make contact with the signer, so we need to start the basic connection service cs(8).
If you are using the same instance of emu in which you invoked svc/auth above, you should skip this
step. To check, you should see a new file in the /net directory called cs. Run the command
0 Для установления безопасного соединения между двумя Inferno-машинами, каждая из них нуждается в публичном ключе с сертификатом подписанным общим signer. Мы сделаем два набора публичных/приватных ключей, один для сервера, другой для клиента (их разница только в том, что хранятся они в разных местах). Мы должны сделать это сначала для сервера, поскольку обычные сетевые сервисы требуют чтобы сервер хранил несколько ключей перед тем как они будут запущены. Затем мы запустим эти сервисы, и наконец отсортируем клиентов.
Шаг 11a: Запуск сервиса соединений
Сервер все еще нуждается в установлении связи с signer, так что нам надо запустить основной сервис соединений cs(8). Если вы воспользуетесь той же копией emu в которой вы запустили раньше svc/auth, вы можете пропустить этот шаг. Для проверки, вы может убедиться что появился новый файл cs в директории /net. Запустите команду
Шаг 11a: Запуск сервиса соединений
Сервер все еще нуждается в установлении связи с signer, так что нам надо запустить основной сервис соединений cs(8). Если вы воспользуетесь той же копией emu в которой вы запустили раньше svc/auth, вы можете пропустить этот шаг. Для проверки, вы может убедиться что появился новый файл cs в директории /net. Запустите команду
→You will be prompted to supply a secret (ie, password or pass phrase) and expiration date. The expiration
date will be used as the maximum expiration date of authentication certificates granted to that user.
Changelogin (see changelogin(8)) accesses the name space generated by keyfs(4), which has just been started
above by svc/auth. A user can later change the stored secret using the passwd(1) command. For the
signer to generate a certificate there must be at least one entry in the password file. If you are not sure at
this stage of the names of the users that you want to authenticate then create an entry for the user inferno
and yourself.
date will be used as the maximum expiration date of authentication certificates granted to that user.
Changelogin (see changelogin(8)) accesses the name space generated by keyfs(4), which has just been started
above by svc/auth. A user can later change the stored secret using the passwd(1) command. For the
signer to generate a certificate there must be at least one entry in the password file. If you are not sure at
this stage of the names of the users that you want to authenticate then create an entry for the user inferno
and yourself.
0 У вас попросят набрать секрет (это может быть пароль или ключавая фраза) и дату истечения срока действия пароля. Эта дата будет использоваться как крайний срок действия сертификата выданного пользователю.
Changelogin (смотри changelogin(8)) получает доступ к пространству имен созданному keyfs(4), запущенному при старте svc/auth. Пользователь может позже изменить хранимый секрет при помощи команды passwd(1). Для signer генерирующего сертификат должна существовать хотя бы одна записть в файле паролей. Если на этом этапе вы не знаете имена пользователей которых вы хотите аутентифицировать, тогда создайте записи для пользователя inferno и для себя.
Changelogin (смотри changelogin(8)) получает доступ к пространству имен созданному keyfs(4), запущенному при старте svc/auth. Пользователь может позже изменить хранимый секрет при помощи команды passwd(1). Для signer генерирующего сертификат должна существовать хотя бы одна записть в файле паролей. Если на этом этапе вы не знаете имена пользователей которых вы хотите аутентифицировать, тогда создайте записи для пользователя inferno и для себя.
→For each user to be authenticated by the signer run
0 Для каждого пользователя проверяемого signer запустите
Резюме
- Пол:
- мужчина
- Родной язык:
- русский
- С нами:
- с 13 апреля 2009 г. (6395 дней)
- Деятельность:
-
1085 версий перевода
с общим рейтингом 0
3 комментария
Карма: 2 (оценок: 2)