11.4 Запуск NIS Сервера
После такого многого теоретического techno-babble, это - время,
чтобы очитстить наши руки от грязной работы с конфигурации. В этом
разделе, мы опишем конфигурацию NIS сервера. Если имеется уже NIS запуск
сервера на вашей сети, Вы не должны будете установить ваш собственный
сервер; в этом случае, то Вы можете безопасно пропускать этот раздел.
<> Note that if you are just going to experiment with the
server, make sure you don't set it up for a NIS domain
name that is already in use on your network. This may
disrupt the entire network service and make a lot of peo-
ple very unhappy, and very angry.
В настоящее время используются два NIS сервера, свободно
доступные для Linux, один содержится в yps пакете Tobias Reber's, и
другой в Peter Erikson's ypserv package. Это не должно иметь
значение, который Вы запускаете, независимо
от того, используете ли Вы NYS или NIS клиентский код, который
находится в libc в настоящее время. Во время этой записи, цифра для
обработки NIS подчиненных серверов, кажется, более полной в yps. Так что,
если Вы должны иметь дело с подчиненными серверами, yps мог бы быть лучшим
выбором.
После установки программы сервера (ypserv) в /usr/sbkn, Вы должны
создать каталог, который будет проводить отображение, регистрируемо
на Вашем сервере. При установке NIS области для brewery domain,
отображения шло бы к /var/yp/brewery. Сервер определяет обслуживало ли это
частную NIS область, проверяя есть ли каталог отображений. Если Вы
блокируете обслуживание для некоторой NIS области, удостоверитесь удален
ли каталог также.
Отображения обычно сохраняются в картотеках DBM, чтобы ускорить
поиски. Они создаются от главы, регистрирующей использование программ,
называемой makedbm (для Tobias' сервер) или dbmload (для сервера
Peter's). Они не могут быть изменчивыми. Преобразовани е главы
регистрирует в форму parseable dbmload обычно требуя некоторого awk
или sed, которые имеют тенденцию, чтобы быть немного утомительными к
типу. Следовательно, Peter Eriksson's Ypserv пакет содержит Формирование
который делает всю работу за Вас. Вы должны установить это как
Формирование файла в вашем отображении, и отредактировать это, чтобы
отразить отображения которые Вы хотите распределить. В вершине
файла Вы наход услуги Ypserv. По умолчанию, просмотры линии что -
нибудь вроде этого:
all: ethers hosts networks protocols rpc services passwd group netid
Если Вы не хотите производить ethers.byname и ethers.byaddr
отображения, например, просто удалите предпосылку эфиров из этого
правила.Чтобы проверить вашу установку, это может удовлетворять тому,
чтобы начать с только одного или двух отображении, подобно услугам. *
Отображения.
После редактирования Формирования файла, в то время как Вы
находитесь в каталоге отображений, набирите "make". Это автоматически
генерирует и устанавливать отображения. Вы должны удостовериться, чтобы
модифицировать отображения всякий раз, когда Вы изменяете главный файл,
иначе изменения останутся невидимыми для сети.
Следующий раздел объясняет, кгк конфигурировать NIS клиентский код.
Если ваша установка не работает, Вы должны пробовать выяснить или любые
запросы достигнут вашего сервера или нет. Если Вы точно определяете
команду -D, флажок линии к NYS серверу, то это печатает сообщения отладки
на консоли относительно всех входящих запросов NIS, и возвращенных
результатов. Они должны дать Вам подсказку относительно того, где задача
находится. Tobias' сервер не имеет никакой такой опци
11.5 Установка NIS Клиента с NYS
Через остаток от этой главы, мы опишем конфигурацию NIS клиента.
Ваш первый шаг должен быть - сообщить NYS который сервер
использован для NIS обслуживания, устанавливая это в файле конфигурации
/etc/yp.conf. Очень прост типовой файл для множества сети Winery's может
выглядеть следующим образом:
# yp.conf - YP configuration for NYS library.
#
domainname winery
server vbardolino
Первая формулировка сообщает всей NIS клиентуре, что они
принадлежат к Winery NIS области. Если Вы упускаете эту линию, NYS
использует название области, которой Вы приписывали вашу систему через
команду domainname. Сервер формулировки называется NIS сервером. Конечно,
IP адреса адресуются к vbardolino, и должны быть хостом в файле хоста; в
качестве альтернативы, Вы можете использовать адрес IP непосредственно с
формулировкой сервера.
В форме, показанной выше, команда сервера сообщает, чтобы NYS
использовал именованный сервер любой NIS области которой может быть. Если,
однако, Вы перемещаете вашу машину между различными NIS областями
часто, то Вы возможно захотите сохранить информацию для отдельных
областей в картотеке yp.conf. Вы можете иметь информацию относительно
серверов для различных NIS областей в Yp.conf, прибавляя NIS название
области к формулировке сервера. Для образца, Вы могли бы измен"типовой
файл для портативной ЭВМ, чтобы это выглядило подобно этому:
# yp.conf - YP configuration for NYS library.
#
server vbardolino winery
server vstout brewery
Это позволяет Вам выдать портативную ЭВМ в любой из двух областей,
просто при установке желательной NIS области при начальной загрузке
введите команду названия.
После создания этого базисного файла конфигурации, и уверенности
в том это - всемирно - читаемый, Вы запустить ваш первый критерий,
чтобы проверить, можете ли Вы подсоединиться к вашему серверу.
Удостоверитесь, что выбрано отображение вашего сервеа, подобно
hosts.byname, и испытанию, чтобы восстановить, используя ypcat утилиту.
Ypcat, подобно всем другим административным NIS инструментальным
средствам, должен жить в /usr/sbin.
# ypcat hosts.byname
191.72.2.2 vbeaujolais vbeaujolais.linus.lxnet.org
191.72.2.3 vbardolino vbardolino.linus.lxnet.org
191.72.1.1 vlager vlager.linus.lxnet.org
191.72.2.1 vlager vlager.linus.lxnet.org
191.72.1.2 vstout vstout.linus.lxnet.org
191.72.1.3 vale vale.linus.lxnet.org
191.72.2.4 vchianti vchianti.linus.lxnet.org
Вывод, который Вы получаете, должен быть на подобие вышепоказанного.
Если Вы получаете сообщение об ошибках взамен, которое говорит "Can't
bind to server which serves domain" или что-нибудь на подобие, затем
или NIS название области, которое не имеет сервер соответствия,
определенный в yp.conf, или сервер - unreachable по некоторым
причинам. В последнем случае, удостоверитесь в том, что ping множеству
производится положительный результат, и что это действительно запу Вы
можете проверить последний, используя rpcinfo, который должен произвести
следующий вывод:
# rpcinfo -u serverhost ypserv
program 100004 version 2 ready and waiting
11.6 Выбор правых отображений
Удостоверьтесь в том, что Вы можете достичь NIS сервера, Вы должны
решить который конфигурационный файл, чтобы заменить или увеличить с
NIS отображениями. Обычно, Вы захотите использовать NIS отображения
для множества и функций поиска пароля. Вышеупомяну тый особенно полезен,
если Вы не запускаете BIND. Последний разрешает всем
пользователям зарегестрироваться на их account из любой системы в NIS
области; это обычно требует разделения центрального /местного к Это
объяснено подробно в разделе 11.7 ниже. Другое отображение, подобно
services.byname, не такое драматическое увеличение, но сохраняют Вас
от некоторой работы редактирования, если Вы устанавливаете любые
сетевые приложения которые используют сервисное название, то это не в
стандартном файле услуг.
Вообще, Вы хотите иметь некоторую свободу выбора когда поиск-
функция использует локальные файлы, и когда это делает запрос NIS
сервера. NYS позволяет Вам сконфигурировать порядок, в котором функция
обращается к этим услугам. Это управляется через картотеку
/etc/nsswitch.conf, который замещает обслуживание названия, но
конечно не ограничивает название обслуживание. Для любой из функций
поиска данных это содержит линию, именующие услуги, чтобы использовать.
Правильный порядок услуг зависит от типа данных. Это вряд ли
то, что services.byname отображение будет содержать отличие входов
из тех в локальном файле услуг; это может только содержать больше. Так
хороший выбор может быть, чтобы сделать запрос локальных файлов сначала, и
проверять NIS только если сервисное название не было найдено. Hostname
информация, с другой стороны, может изменятся пченю часто, так, чтобы DNS
или NIS сервер всегда имел наиболее точный accoun файл сохран как
дублиррование, если DNS и NIS терпел неудачу. В этом случае, Вы захотели
бы проверить локальный последний файл.
Пример ниже показывает, как сконфигурировать gethostbyname
(2), gethostByaddr (2), и getservbyname функции (2) как описано выше. Они
будут перечисленны как услуги по очереди; если поиск идет хорошо, то
результат будет возвращен, иначе следующее обслуживание осуждено.
# small sample /etc/nsswitch.conf
#
hosts: nis dns files
services: files nis
Полный список услуг, которые могут использоваться с записью в
Nsswitch.conf файле показыны ниже. Фактические отображения, файлы,
серверы и вещи, которые делают запрос зависят от названия записи.
Nisplus или nis + использует NIS + сервер для этой области.
Локализация сервера получена из картотеки /etc/nis.conf.
Nis Использует текущий NIS сервер этой области. Локализация сервера
делал запрос, сконфигурированный в картотеке yp.conf как показано в
предыдущем разделе. Для записи множеств, отображения Hosts.byname и
hosts.byaddr делают запрос.
dns использует DNS сервер. Этот служебный тип полезен только для
записи хоста. Сервера делающие запрос, все еще определяются в соответствии
cо стандартом resolv.conf файла.
files использует локальный файл, такой как /etc/hosts файл для хост
записи.
dbm ищет информацию из DBM файлов, размещенных в /var/dbm. Имя,
используемое для файла - соответствующего NIS отображение.
В настоящее время, NYS поддерживает следующие nsswitch.conf записи:
hosts,
networks, passwd, group, shadow, gshadow, services, protocols, rpc, и
др. Другие записи возможно могут быть добавленны.
Рисунок 11.6 показывает более полный пример, который демонстрирует
другую
&осогенность nsswitch.conf: ключевое слово [NOTFOUND=return] в записях
хостов сообщила бы NYS - вернуться, если желаемый пункт не был найден в NIS
или в DNS база данных. То есть NYS продолжит искать локальные файлы, только
если обращения к NIS и DNS серверам терпят неудачу по какой-либо другой
причине. Локальные файлы будут затем только использоваться при начальной
загрузке и как backup, когда NIS сервер выключен.
11.7 Использование passwd и группы Maps
Одно из главных приложений NIS находится в синхронизации пользователя
и account информации относительно всех множеств в NIS области. К концу, Вы
обычно хранит только малый локальный файл /etc/passwd, к которому
добавлена site-wide информация из NIS отображений. Однако, просто
предоставления возможности NIS поиска для этого обслуживания в
nsswitch.conf не вполне достаточно.
Полагаясь на информацию пароля, распределенную NIS, Вы сначала должны
удостовериться, что числовая идентичность пользователя всех пользователей,
которые у Вас есть в Вашем локальном passwd файлесоответствуют идеи NIS
сервера относительно идентичности пользователя. Вы возможно захотите
использовать это для других целей также, подобно установке NFS значений от
других хостов на вашей сети.
# /etc/nsswitch.conf
#
hosts: nis dns [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files
services: files nis
protocols: files nis
rpc: files nis
Рисунок 17. Примерный nsswitch.conf файл.
Если любая из числовых идентичности в /etc/passwd или /etc/group
отклоняется от тех, которые в maps, то Вы должны скорректировать файл
ownerships для всех файлов, которые принадлежат этому пользователю. Сначала
Вы должны заменить все uids и gids в passwd и в группах новых значений;
затем найдите вуе фвйлы, которые принадлежат пользователям и былы только
что изменены, и в заключение замените их ownerships. Примите новости
используемые для того, чтобы иметь идентичность пользователя была бы 9, и
okir имел бы идентичность пользователя 103, которые были заменены на
некоторое другое значение; Вы могли бы затем выпорлнить следующие команды:
# find / -uid 9 -print >/tmp/uid.9
# find / -uid 103 -print >/tmp/uid.103
# cat /tmp/uid.9 | xargs chown news
# cat /tmp/uid.103 | xargs chown okir
Важно то, что Вы выполняете эти команды с новым, установленным passwd
файлом, и что Вы собираете все имена файлов прежде, чем Вы изменените
ownership любого из них. Для того, чтобы модифицировать ownerships группы
файлов, Вы должны использовать похожую команду.
Сделав это, численный uid's и gid's на вашей системе согласиться с
теми хостами, которые расположенны в Вашей NIS области. Следующий шаг будет
- прибавить линии конфигурации к nsswitch.conf, который включают NIS поиски
для пользователя и информации группы:
# /etc/nsswitch.conf - passwd and group treatment
passwd: nis files
group: nis files
Это заставляет команду входа в систему, и всех ее друзей сначала
сделать запрос NIS maps, когда пользователь пробует log in, и если этот
поиск терпит неудачу - обратно обращается к локальным файлам. Обычно, Вы
удалите почти всех пользователей из Вашего локального файла, и только
оставите записи для root и generic accounts подобно почте. Это потому, что
некоторые насущные задачи системы могут требовать к map uids имя
пользователя или наоборот. Например, административный cron job может
выполнить команду su, для того чтобы временно стать новостями, или UUCP
подсистема может отправлять по почте отчет состояния. Если новости и
uucp не имеют вход в локальный файл passwd, то эти jobs будут, к сожалению,
терпеть неудачу в течение&NIS"brownout.
Имеются две большие проблемы: с одной стороны, установка, как уже
было описано в начале, до сих пор работает только для наборов программ
входа в систему, которые не используют теневой пароль, подобно тем, что
включены в util-linux пакет. Путаница при использовании теневых паролей с
NIS будет объяснена ниже. С другой стороны, команды входа в систему - не
единственые, которые обращаются к passwd файлу - посмотрите на команду ls,
которую большинство людей использует почти постоянно.
При выполнении длинной распечатки, ls выделит символические имена для
пользователя и группу владельцев файла; то есть для каждого uid и gid это
представляет собой целую схватку, это должно сделать запрос на NIS сервер,
только один раз. Это ужасно замедлит выполнение, если ваша локальная сеть -
clogged, или, еще хуже, когда NIS сервер не на той же самой сети, для
этого датаграммы должны пройти через программу маршрутизации.
Но пока это еще не вся история. Вообразите, что случится если
пользователь захочет изменить свой пароль. Обычно, она вызовет passwd,
который считает новый пароль и модифицирует локальный файл passwd. Это
невозможно сделать с NIS, так как с тех пор файл локально больше не
доступен, но если пользователи подсоединились к NIS серверу, и вдруг
захотели изменить пароль, то дляч этого, к сожалению нет опции. Поэтому,
NIS обеспечивает отпуск в замене для passwd, называемого yppasswd, который
делает аналогичную вещь в присутствии NIS. Для изменения пароля на хост
сервере, но в контакт с yppasswdd daemon на том же самом хосте через RPC, и
обеспечивает его модифицируемой информацией пароля. Обычно, Вы
устанавливаете yppasswd для нормальной программы, делая что - нибудь вроде
этого:
# cd /bin
# mv passwd passwd.old
# ln yppasswd passwd
В то же самое время Вы должны установить rpc.yppasswdd на сервер и
запустить его из rc.inet2. Это эффективно слроет любые искожения NIS от
ваших пользователей.
11.8 Использование NIS с Shadow Support
Не имеется никакой NIS поддержки для мест, которые используют теневой
вход в систему набора программ. John F. Haugh, автор теневого набора
программ, недавно выпущенной версии теневых библиотечных функций, описанных
GNU библиотекой GPL к comp.sources.misc. Это уже имеет некоторую поддержку
для NIS, но она пока еще не полна, и файлы пока еще не добавлены к
стандарной библиотеке для C. С другой стороны, при публикации информации из
/etc/shadow через NIS вид поражения цели теневого набора программ.
Хотя NYS функции поиска пароля не используют shadow.byname map или
что - либо аналогичное, очевидно NYS поддерживает использование локального
/etc/shadow файла. Когда NYS реализация getpwnam обращается к просмотру
информации, связанной с данным login именем, средства, точно определенные
passwd записью в nsswitch.conf делают запрос. Nis обслуживание будет просто
искать имя в passwd.byname map на NIS сервере. Обслуживание файлов, однако,
проверит, существует ли /etc/shadow, и если существует, то попробует
открыть это. Если ни один из файлов не присутствует, или если пользователь
не имеет привилегию root, то происходит возвращение к обычной работе поиска
информации пользователя в /etc/passwd. Однако, если теневой файл существует
и может быть открыт, то NYS извлечет пароль пользователя из shadow.
Getpwuid функция соответственно выполняется. В этом режиме, binaries,
компилируемый с NYS, будет иметь дело с локальной установкой теневого
набора программ.
11.9 Использование традиционного NIS кода.
Если Вы используете код клиента, который находится в стандарте libc,
то конфигурация NIS клиента немного отлична. С одной стороны, это
использует ypbind daemon для того, чтобы передать информацию для активных
серверов скорее чем считывать эту информацию из файла конфигурации. Вы
следовательно должны удостоверится в том, что бужет запущен ypbind при
начальной загрузке. Он должен быть вызван после установленной NIS области,
и RPC portmapper тоже должен быть запущен. Вызов ypcat нужен для того,
чтобы проверить работает ли сервер так, как он должен (см. выше).
Недавно, имелось некоторое число bug reports, которые сообщают, что
NIS терпит неудачу, сообщая при этом: "clntudp create: RPC: portmapper
failure - RPC: unable to receive''.
Это все из-за несовместимого изменения в способе, как ypbind
связывается с библиотечными функциям. Получая последние источники для NIS
утилит и перетранслируя их, должна быть исправлена эта задача. (5)
Также, способ традиционного NIS решает это, как соединить NIS
информацию с этим из локальных файлов отклоняемую от используемого NYS.
Например, чтобы использовать NIS отображение пароля, Вы должны включить
следующую линию где-нибудь в Вашем /etc/passwd map:
+: *:0:0:::
Это маркирует место где функции поиска пароля "вставляют" NIS
отображения. Вставка подобной линии (минус последние два двоеточия) в
/etc/group делают тот же самое для group. * maps. Для того, чтобы
использовать hosts.* maps, распределенные NIS, измените order line в
host.conf файле. Например, если Вы хотите использовать NIS, DNS, и файл
/etc/hosts (в том порядке), то Вы должны изменить эту линию на:
order yp bind hosts
Традиционная NIS реализация не поддерживает никакие другие
отображения в настоящее время.
5. Источник для yp-linux может быть получен из ftp.uniрaderborn.de в
каталоге /pub/Linux/LOCAL.
12. Сетевая файловая система (NFS)
NFS, the network file system, является возможно наиболее видной
сетью услуг, использующей RPC. Это позволяет обращаться к файлам на
отдаленных хостах точно
тем же самым способом, как пользователь обратился бы к любым"
локальным файлам. Сделано возможным смешением kernel функциональных
возможностей на клиентской стороне (которая использует отдаленную файловую
систему) и NFS сервер на стороне сервера (который обеспечивает файл
данных). Этот доступ к файлу полностью очевиден клиенту, и работает через
все разнообразие серверов и архитектуры хостов.
NFS предлагает ряд преимуществ:
+ Данные, к которым обращаются все пользователи, могут быть сохранены
на центральном хосте, с клиенами устанавливающими этот каталог при
начальной загрузке. Например, Вы можете сохранить все accounts
пользователей на одном хосте, и иметь все хосты на Вашем сетевом mount
/home от того хоста. Если оно установлено бок о бок с NIS, то пользователи
могут затем войти в любую систему, и все еще работать на одном множестве
файлов.
+ Данные, потребляющие большие количества дискового пространства
могут быть сохранены в единственном хосте. Например, все файлы и программы
относящиеся к LaTeX и METAFONT могут быть сохранены и поддерживаться в
одном месте.
+ Административно-управленческая информация может быть сохранена в
адинственном хосте. Нет нужды использовать rcp для того, чтобы установить
тот же самый глупый файл на 20 различных машин.
Linux NFS - в значительной степени работа Rick Sladkey, (1), кто
написал NFS
kernel код и большие части NFS сервера. Последний, выводил из unfsd
пространства пользователя NFS сервер, первоначально написанный Mark Shand,
и hnfs Harris NFS сервер, написанный Donald Becker.
Давайте теперь посмотрим том, как NFS работает: клиент может
запросить установить каталог от отдаленного хоста на локальном каталоге тем
же способом, и он может установить физическое устройство. Однако,
синтаксис, используемый для того, чтобы точно определить отличен ли
отдаленный каталог. Например, чтобы mount /home хост vlager к /users на
vale, администратор выпустил бы следующую команду на vale: (2)
"
1. Rick может быть найден в jrs@world.std.com.
# mount -t nfs vlager:/home /users
mount затем попробует соединиться с mountd, устанавленный с daemon на
vlager через RPC. Сервер проверит, разрешается ли vale повысить каталог, и
если так, вернет это к file handle. Этот handle файл будет использоваться
во всех последовательных запросах к картотекам ниже /users.
Когда кто -то обращается к файлу над NFS, kernel места RPC вызовут
nfsd (NFS daemon) на машине сервера. Это обращение берет handle файл, имя
файла, к которому обращаются, и user's user и идентичность группы как
параметры. Они используются в определении прав доступа к точно
определенному файлу. Чтобы предотвратить от несанкционированного чтения или
модифицирования файла, пользователь и идентичность группы должны быть теме
же самыми на обоих хостах.
На большинстве Un*x реализаций, NFS функциональные возможности обоих
клиентов и сервер выполнены как kernel уровень daemons, которые начаты из
пространства пользователя при начальной загрузке системы. Они - NFS daemon
(nfsd) на хосте сервера, и блок ввода - вывода Daemon (biod) выполняющийся
на клиентском хосте. Чтобы улучшить производительность, biod выполняет
асинхронный ввод - вывод, используя чтение - вперед и запись-назад; также,
несколько nfsd daemons обычно запускается совместно.
NFS реализация Linux, немного отлична в этом самом клиентском коде,
крепко объединена в файловой системе (VFS) уровень ядра и не требует
дополнительного управления через biod. С другой стороны код сервера
запускается полностью в пространстве пользователя, так, чтобы при запуске
нескольких копий сервера в одно и то же время было бы почти невозможным из-
за синхронизации. Linux NFS, в настоящее время также существует отсутствие
чтения - вперед и записи-назад, но Rick Sladkey планирует исправит этот
недостатолк в ближайшее время. (3)
Самая гольъая проблема с Linux NFS кодом - то, что Linux kernel
версии 1.0 не способен распределить память в кусках больших чем 4k; как
следствие, сетевой код не может обрабатывать датаграммы большие чем
приблизительно 3500 байтов после вычитания размера заголовка и т.д. Это
значит, что передача к и из NFS daemons выполняющейся на системах, которые
используют большие UDP датаграммы по умолчанию (например 8k на SunOS)
должны быть уменьшенны в размере искуственно. Этот причиняет вред
характеристике под влиянием некоторых обстоятельств. (4) Этот предел входит
в поздние Linux-1.1 ядра, и клиентский код был
модифицирован для того, чтобы пользоваться этим преимуществом.
2. Заметьте, что Вы можете опустить -t nfs аргумент, потому что mount
видит из двоеточия то, что это определяет NFS объем.
3. Задача с write-behind - то, что kernel буфер кэша индексирован
парами device/inode, и следовательно не может использоваться для nfs-
установленных файловых систем.
12.1 Подготовка NFS
Прежде, чем Вы можете использовать NFS, будь это сервер или клиент,
Вы должны удостовериться, что Ваше ядро имеет NFS поддержку, компилируемую
в. Более новые ядра для этого имеют простой интерфейс на proc файловой
системе, файл /proc/filesystems, который Вы можете отобразить используя
cat:
$ cat /proc/filesystems
minix
ext2
msdos
nodev proc
nodev nfs
Если nfs отсутствует из этого списка, то Вы должны скомпилировать
Ваше собственное ядро с включенным NFS. Конфигурирование kernel сетевых
опций объяснено в разделе " Kernel конфигурация " главы 4 ..
Для более старых ядер до 1.1 Linux, самый простой способ выяснять
имеет ли ваше ядро включенную NFS поддержку - фактически попробовать
установить NFS файловую систему. Для этого, Вы могли бы создать каталог
ниже /tmp, и&поптобовать установить локальный каталог на нем:
# mkdir /tmp/test
# mount localhost:/etc /tmp/test
Если эта попытка установки выдает сообщениее об ошибках выводя, "fs
type nfs no supported by kernel'', то Вы не должны делать новое ядро с
включенной NFS. Любые другие сообщения об ошибках полностью безобидны, так
как Вы пока еще не сконфигурировали NFS daemons на вашем множестве.
12.2 Установка NFS значения
4. Как мне объяснил Alan Cox: NFS спецификация требует сервер к
потоку при каждой записи на диск прежде, чем он успевает вернуть
подтверждение. Так как BSD ядра только способны к, установленным по размеру
страницей, записям (4K), записанным по 4 куска по 1k каждый в bsd-based
NFS, серверу получает в результате 4 операции записи по 4k каждый.
NFS значения (5) установлены таким же способом, как и обычные
файловые системы
установленны. Вы вызываете mount, используя следующий синтаксис:
# mount -t nfs nfs volume local dir options
Nfs значение дано как отдаленный хост: отдаленная директория. С тех
пор как эта совокупность условных знаков является уникальной в NFS файловых
системах, то Вы можете не учитывать nfs опцию -t.
Имеется ряд дополнительных опций, которые Вы можете точно определить
установив над mounting NFS значение. Они могут также быть даны -o
переключателем в командной строке, или в области опций /etc/fstab записей
для значения. В обоих случаях, составные опции отделены друг от друга
запятыми. Опции, точно определенные на командной строке всегда отменяют те,
что были даны в файле fstab.
Типовая запись в /etc/fstab могла бы быть такой:
# volume mount point type options
news:/usr/spool/news /usr/spool/news nfs timeo=14,intr
Этот значение может затем быть установлено при использовании
# mount news:/usr/spool/news
В отсутствии fstab записи, NFS устанавливает просмотр вызовов
большинства uglier. Например, предположим, что Вы устанавливаете home
каталоги Ваших пользователей
из машины, называемой moonshot, которая использует заданный по
умолчанию размер блока равный 4k для операции чтения - записи. Вы могли бы
уменьшить размер блока до 2k, чтобы подойти под размер Linux(овских)
датаграмм введя следующую команду:
# mount moonshot:/home /home -o rsize=2048,wsize=2048
5. Никто не говорит "файловая система", потому что здесь не
существует подходящей файловой системы.
Список всех допустимых опций полностью описан в руководстве по
Nfs(5), которая идет вместе с Rick Sladkey's NFS-aware mount tool,
который может быть найден в Util-linux пакете Rik Faith). Следующее -
незавершенный список тех, которые Вы возможно захотели бы использовать:
rsize=n и wsize=n - они точно определяют датаграмный размер,
используемый NFS
клиентурой при чтении и записи запросов, соответственно. В
настоящее время они определенны по умолчанию - 1024 байтам,
из-за предела на UDP размере датаграммы, описанном выше.
timeo=n - это устанавливает время (в десятках секунд), сколько NFS
клиент будет ждать запрос,
чтобы завершить работу. Значения по умолчанию - 0.7 секунды.
hard - точно маркирует этот объем как hard-mounted. Это включено по
умолчанию.
soft - soft-mount драйвер ( противоположный hard-mounted).
intr - позволяет сигнализировать о том, что надо прервать NFS вызов.
Полезно для прерывания выполнения, когда сервер не
отвечает.
Кроме rsize и wsize, все эти опции обращаются к клиенту, если сервер
стал временно недостижим. Они работают вместе следующим способом: всякий
раз, когда клиент ппсылвет запрос к NFS серверу, он ожидает, что операция
закончится после данного интервала (точно установленным в опции блокировки
по времени). Если никакого подтверждения не получено внутри этого
промежутка времени, то появится так называемая minor timeout
(незначительная остановка по времени), и операция повторится, но уже с
интервалом блокировки по времени вдвое большим. После достижения
максимальной блокировки по времени - 60 секунд, происходит глобальная
блокировка по времени.
По умолчанию, глобальная блокировка по времени заставит клиента
напечатать сообщение на консоль и начинать все снова. В принципе это может
продолжаться вечно. Значения, которые упрямо повторяют операцию до тех пор
пока сервер не становится доступным, называются hard-mounted. В
противоположность им, soft-mounted значения генерируют ошибку ввода -
вывода для вызова процесс всякий раз, когда происходит глобальная
блокировка по времени. Из-за того, что write-behind вводится буферным
кэшем, то это условие ошибки не распространяется непосредственно на процесс
прежде, чем это вызовет функцию записи 2 в следующий раз, так как программа
никогда не сможет убедиться в том что операция записи к soft-mounted
значению имела место вообще.
Поставили ли Вы hard- или soft-mount значение - это не только вопрос
вкуса, но также и то, что Вы должны сделать с тем сортом информации,
которую Вы хотите получить от этого значения. Например, если Вы
устанавливаете ваши Х программы NFS, Вы конечно не хотели бы, чтобы ваш X
сеанс шел бы "бешено" только потому, что кто -то привел сеть к останову,
запустив семь копий xv в одно и тоже время, или скажем, вытащив Ethernet
разъем на некоторый момент. Используя hard-mounting, Вы удостоверяетесь в
том, что ваш компьютер будет ждать, пока не появится возможность заново
восстановить контакт с вашим nfs-сервером. С другой стороны, non-critical
данные, типа nfs-mounted news partititons или FTP врхив может быть также
soft-mounted, так что это не повесит ваш сеанс в случае, если отдаленная
машина должна стать временно "недостигаемой", или просто быть выключенной.
Если ваша сетевая связь с сервером - flakey или проходит через программу
маршрутизации, то Вы может также увеличивать начальную блокировку по
времени, используя опцию timeo, или hard-mount значение, но позволяйте
сигнализировать прерывание вызова NFS, так чтобы Вы могли прервать любой
hanging file access.
Обычно, mountd daemon будет иным способом следить, которые каталоги
были установлены, и какими хостами. Эта информация может быть отображена
при использовании программы showmount, которая также включена в NFS пакет
сервера. Linux mountd не делает этого.
12.3 NFS daemon(область)
Если Вы хотите обеспечить NFS обслуживание другим хостам, то Вы
должны запустить nfsd и mountd daemons на вашей машине. Как rpc-основанные
программы, они не управляются inetd, но запускаются при начальной загрузке,
и регестрируют сами себя непосредственно с portmapper. Следовательно, Вы
должны удостовериться в том, что они запущенны только после того, как
rpc.portmap выполнилось. Обычно, Вы должны включить следующие две линии в
вашем rc.inet2 script:
if [ -x /usr/sbin/rpc.mountd ]; then
/usr/sbin/rpc.mountd; echo -n " mountd"
fi
if [ -x /usr/sbin/rpc.nfsd ]; then
/usr/sbin/rpc.nfsd; echo -n " nfsd"
if
Информация монопольного использования файлов NFS daemon обеспечивает
своей клиентуре, обычно содержащей только численного пользователя и
идентичность группы. Если и клиент и сервер подсоединят того же самого
пользователя и группу имен с этой самой численной идентичностью, то им
обязательно скажут разделить то же самое пространство uid/gid. Для примера,
когда Вы используете NIS, чтобы распределить passwd информацию всем хостам
на вашей LAN.
&
" В некоторых случаях, они не соответствуют. Достаточно
модифицированного uid's и gid's клиента, чтобы соответствовать таковому
серверу, Вы может использовать ugidd mapping daemon, чтобы работать
вокруг этого. Использование map daemon опцию объяснено ниже, Вы может
сообщить nfsd отобразить uid/gid пространство сервера к пространству
uid/gid клиента при помощи ugidd на клиента.
ugidd - rpc-основанный сервер, и запущен из rc.inet2 точно также как
и nfsd и mountd.
if [ -x /usr/sbin/rpc.ugidd ]; then
/usr/sbin/rpc.ugidd; echo -n " ugidd"
fi
12.4 файл экспорта
В то время как вышеупомянутые опции обращаются к NFS конфигурации
клиента,
имеется различное множество опций на стороне сервера при выборе
конфигурации
per-client. Эти опции должны быть установленны в /etc/exports файле.
По умолчанию, mountd не позволяет кому угодно устанавливать каталоги
из локального хоста, которое является довольно разумной позицией. Для того,
чтобы разрешить одному или большему количеству хостов установливать nfs
каталог, то это должно быть экспортированно, то есть должно быть определено
в файле экспорта. Типовой файл может выглядеть следующим образом:
# exports file for vlager
/home vale(rw) vstout(rw) vlight(rw)
/usr/X386 vale(ro) vstout(ro) vlight(ro)
/usr/TeX vale(ro) vstout(ro) vlight(ro)
/ vale(rw,no root squash)
/home/ftp (ro)
Каждая линия определяет каталог, и хост, которому позволенно
установить его. Имя хоста - обычно полностью квалифицированное название
области, но может содержать * и ? универсальные символы, которые действуют
способом при котором они действуют сомместно с Bourne оболочкой. Например,
lab*.foo.com соответствует lab01.foo.com также как и laber.foo.com. Если
никакое имя хоста не дано, как с каталогом /home/ftp в приоере выше, то
любому хосту позволено установить этот каталог.
При проверке клиентского хоста против файла экспорта, mountd будет
искать hostname клиента используя gethostbyaddr(2) вызов. С DNS, этот вызов
возвращает каноническиий hostname клиента, так что Вы должны удостовериться
в том не используется ли псевдонимы в экспорте. Без использования DNS,
возвращенное имя -
первый hostname, найденный в файле хоста, которая соответствует
адресу клиента.
Имя хоста сопровождается произвольным, отделенным запятой, списком
флагов, приложенных в скобках. Эти флаги могут принимать следующие
значения:
insecure - разрешает не-опознанный доступ из этой машины.
unix-rpc - требует unix-области RPC установление подлинности из этой
машины.Оно просто
требует, чтобы все запросы происходили из зарезервированного
internet порта (то есть номер порта должен быть меньше чем 1024). Эта
опция определена по умолчанию.
secure-rpc - требует secure RPC установления подлинности от этой
машины. Это пока еще
не осуществленно. См. Sun's документацию по Secure RPC.
kerberos - требует Kerberos установления подлинности на доступ из
этой машины. Это тоже
пока еще не осуществленно. См. MIT документацию по Kerberos
опознавательной системе.
root squash - это особенность защиты, которая отвергает super user на
точно
установленных хостах любых специальных прав доступа, отображая
запросы из uid
0 на клиенте к uid 65534 (-2) на сервер. Этот uid не должен
быть связан ни с каким пользователем.
no root squash - не делает запросы отображения из uid 0. Эта опция
включена по
умолчанию.
ro - устанавливает значение read-only на файловую архитектуру. Эта
опция включена по умолчанию.
rw - устанавливает значение rgad-write на файловую архитектуру.
link relative - преобразовывает абсолютные символьные связи (где link
contents начинается с наклонной черты вправо) в относительные связи вводя
необходимое число ../, чтобы добраться из каталога содержащего связь к root
на сервере. Эта опция имеет смысл только тогда, когда целая файловая
система хоста установлена, или некоторые из связей не могли бы быть нигде,
или даже хуже, файлы на которые они никогда не указывали.
Эта опция определена по умолчанию.
link absolute оставляет вся символьные связи какими они и были
(нормальное поведение для Sun-supplied NFS серверов).
map identity - map identity опция сообщает серверу, чтобы он принял
того клиента, который использует теже самые uid's и gid's как и сервер. Эта
опция определена по умолчанию.
map daemon Эта опция сообщает NFS серверу принять, что клиента и
сервер не разделяют то же самое пространство uid/gid. nfsd затем построит
список идентичности отбора между клиентом и сервером, запрашивая client's
ugidd daemon.
Ошибка, анализирующая файл экспорта сообщает daemon syslogd's
оборудованию всякий раз, когда nfsd или mountd запущен.
Заметьте, что имена хостов получены из IP адреса клиента обратным
отбором, так что Вы должны иметь правильно сконфигурированное решающее
устройство. Если Вы используете BIND и очень security-conscious, то Вы
должны включить spoof проверку в Вашем host.conf файле.
12.5 Linux Automounter
Иногда, это расточительно для установки всех NFS значений
пользователей, к которым возможно хотят обратиться.; или же из-за острого
числа зачений которые должны быть установленны, или из-за времени, которое
требовалось бы при запуске. Жизнеспособный вариантдля этого - так
называемый automounter. Это - daemon, которая атоматически и понятно
устанавливает любое NFS значение как необходимо, и неустанавливает их ,
если они не были использованны в течении некоторого времени. Одна из умных
вещей относительно automounter - то, что возможно установить определенное
значение из любых мест. Например, Вы можете сохранить копии Ваших Х
программ и файлов поддержки на двух или трех хостах, и все
другин хосты устанавленные через NFS. При использовании automounter,
Вы можете точно определить всех трех из них, чтобы быть установленными на
/usr/X386; automounter затем попробует установить любой из них, пока одна
из попыток установки не преуспевает.
Automounter, обычно используемый с Linux называется amd. Сначала он
был написан Jan-Simon Pendry и был перенесен на Linux Rick Sladkey. Текущая
версия amd-5.3.
Описание amd - вне этой главы; для хорошего описания, пожалуйста,
обратитесь к источникам; они содержат файл texinfo с очень подробной
информацией.
13. Управление Taylor UUCP
13.1 Хронология
UUCP был разработан в конце семидесятых Mike Lesk в AT&T Bell
Laboratories, чтобы обеспечить простое соединение по модему. Так как
большинство людей, которые хотят иметь email и новости Usenet на своей
домашней машине все еще связываются через модемы, UUCP стал очень
популярен. Хотя имеется много реализаций, разработанных для различных
аппаратных платформ и операционных систем, все они совместимы с высокой
степенью.
Однако, как это случилось с большинством программного обеспечения,
которое так или иначе стало "стандартом" за эти годы, нет такого UUCP,
который можно было бы назвать подлинным UUCP. Он подвергался постепенному
процессу эволюции начиная с первой версии, которая была разработана в
1976.В настоящее время имеются две основных разновидности, которые
отличаются в основном поддержкой аппаратных средств и конфигурацией.Крпме
них существуют различные реализации, немного отличающиеся деталями
элементами.
Одна разновидность - это так называемая " Версия 2 UUCP ", которая
датируется 1977 годом и реализована Mike Lesk, David A. Novitz, и Greg
Chesson. Она все еще используется, хотя и устарела. Недавние реализации
Версии 2 обеспечивают многие из возможностей более новой разновидности
UUCP.
Вторая разновидность была разработана в 1983, и обычно упоминается
как BNU (Basic Networking Utilities(базисные утилиты работы с сетями)),
HoneyDanBer UUCP, или HDB для краткости. Название получено из имен авторов,
P. Honeyman, D. A.Novitz, и B. E. Redman. HDB был задуман, чтобы устранить
некоторые из неточностей Версии 2 UUCP. Например, были добавлены новые
протоколы передачи, и буферный каталог был разбит так, что теперь имеется
каталог для каждого компьютера, с которым Вы связываетесь через UUCP.
Реализация UUCP, в настоящее время распространяемого с Linux - Taylor
UUCP 1.04, (1), является версией,которую описывает эта глава. Версия Taylor
UUCP 1.04 была выпущена в феврале 1993. Кроме традиционных файлов
конфигурации, Taylor UUCP может быть скомпилирована так , чтобы понимать
новый стиль - a.k.a. " Taylor " - файлы конфигурации.
Версия 1.05 была выпущена недавно, и скоро будет поставляться на
большинстве дистрибутивов. Различия между этими версиями обычно затрагивают
возможности, которые Вы никогда не будете использовать, так что Вы сможете
конфигурировать Taylor UUCP 1.05 используя информацию из этой книги.
1.Написано Ian Taylor, 1993.
С большинства дистрибутивов Linux, Taylor UUCP обычно компилируется
совместимым с BNU, или Taylor схемой конфигурации, или с обоими. Так как
последний намного более гибок, и, возможно, проще для понимания, чем
довольно часто запутанные файлы конфигурации BNU, ниже я буду описывать
схему Taylor.
Цель этой главы не в том, чтобы дать Вао исчерпывающее описание опций
командной строки для команд UUCP, а в том, чтобы дать Вам введение в
установку работающего узла UUCP. Первый раздел дает введение в то, как
UUCP осуществляет удаленное выполнение и передачу файла. Если Вы не новичок
в UUCP, Вы можете пропустить этот раздел и перейти к разделу 13.3, который
объясняет различные файлы, используемые для установки UUCP.
Мы примем, что Вы знакомы с пользовательскими программами набора
программ UUCP - uucp и uux. Для описания обратитесь пожалуйста к страницам
руководства.
Кроме общедоступных программ - uux и uucp, набор программ UUCP
содержит ряд команд, используемых только для административных целей. Они
используются для контроля траффика UUCP через ваш узел, удаления старых
регистрационных файлов, или для компиляции статистики. Они не будут описаны
здесь, потому что они периферийные к основным задачам UUCP. Кроме того, они
хорошо документированы и довольно легки для понимания. Однако, имеется
третий класс, который включает рабочие программы UUCP. Они называются
uucico (где cico обозначает copy-in copy-out), и uuxqt, которая выполняет
работы, посланные из удаленных систем.
13.1.1 Подробная информация о UUCP
Если Вы в этой главе не найдете то, что хотите, прочитайте
документацию,которая поставляется с пакетом. Это набор texinfo файлов,
которые описывают установку с использованием Taylor схемы конфигурации.
Texinfo может быть преобразован в DVI и GNU файлы информации, использующим
tex и makeinfo, соответственно.
Если Вы хотите использовать файлы конфигурации BNU (или даже Версии
2), есть очень хорошая книга - " Управление UUCP и Usenet " ([GETST
"reilly-uucp"]). Другой хороший источник информации об UUCP для Linux -
Vince Skahan's UUCP-HOWTO , который можно взять на comp.os.linux.announce.
Имеется также newsgroup для обсуждения UUCP - comp.mail.uucp. Если у
Вас есть специфические вопросы о Taylor UUCP, может быть лучше задать их
тжм, чем на группах comp.os.linux.
13.2 Введение
13.2.1 Обзор Передач UUCP и удаленного запуска
Ключ к пониманию UUCP - понятие задачи. Каждая передача, которую
пользователь инициализирует с помощью uucp или uux, называется задачей.
Она состоит из программы,которая будет выполнена на удаленной системе, и
набора файлов, которые будут перемещены между системами. Одна из этих
частей может отсутствовать.
Например,примем, что на вашей ЭВМ Вы выдали следующую команду,
которая заставляет UUCP копировать файл netguide.ps на ЭВМ pablo, и
выполнить команду lpr, чтобы напечатать файл.
# $ Uux -r pablo! Lpr! Netguide.ps
UUCP не вызывает удаленную систему немедленно, чтобы выполнить задачу
(иначе Вы могли это сделать kermit). Вместо этого он временно сохраняет
описание задачи на удаленной системе. Это называется буферизацией задачи.
Каталог, в котором сохраняется задача,называется буферным каталогом и
обычно находится в /var/spool/uucp. В нашем примере, описание задачи
содержало бы информацию относительно удаленной команды, которая будет
выполнена (lpr), пользователя, который запросил выполнение, и пары других
предметов. В дополнение к описанию задачи, UUCP должен сохранить входной
файл (netguide.ps).
Точное расположение и наименование буферных файлов может изменяться
в зависимости от некоторых опций времени компиляции. HDB-совместимые UUCP
вообще сохраняют буферные файлы в каталоге, именованном
/var/spool/uucp/site, где site - имя удаленной машины. Скомпилированный для
Taylor конфигурации, UUCP создаст подкаталоги в /var/spool/uucp/site для
различных типов буферных файлов.
Через определенные интервалы UUCP связывается с удаленной системой.
Когда соединение установлено, UUCP передает файлы, описывающие задачу, плюс
все входные файлы. Входящие задачи не будут выполнены немедленно, а только
после разрыва уоединения . Это делает программа uuxqt, которая также
заботится о пересылке любых задач, если они предназначены для другой
машины.
Для различия между важными и менее важными задачами, UUCP с каждой
задачей связывает уровень приоритета . Это - один знак, в пределах от 0 до
9, от А до Z, и через z, в уменьшающемся старшинстве. Почта обычно
записывается в буферный файл с приоритетом B или C, в то время как новости
записываются с приоритетом N. Работы с более высоким приоритетом передаются
раньше. Приоритеты могут быть назначены используя опцию -g при вызове uucp
или uux.
Вы можете также запретить передачу задач с приоритетом ниже данного в
определенное время. Это также называется максимальным приоритетом буфера,
позволяемым в течение диалога ( по умолчанию z). Обратите внимание на
терминологическую неоднозначность : файл перемещен только, если он имеет
приоритет выше максимального приоритета буфера.
13.2.2 Внутренние работы uucico
Чтобы понять, почему uucico должен знать некоторые вещи, приведем
быстрое описание того, как фактически происходит соединение с удаленной
системой.
Когда Вы выполняете uucico -s система из командной строки, сначала
происходит физическое соединение.Принимаемые действия зависят от типа
открываемого соединения. Например, при использовании телефонной линии, она
должна найти модем, и набрать номер.Если используется TCP, uucico должна
вызвать функцию gethostbyname (3), чтобы преобразовать имя в сетевой адрес,
выяснить, какой порт открывать, и связать адрес с соответствующим
гнездом(socket).
После того, как соединение было установлено, должна выполниться
процедура идентификации пользователя. Она состоит из запроса удаленной
системой, имени, и, возможно, пароля.Все это называется "login chat".
Процедура идентификации выполняется или обычным getty/login набором
программ, или - на гнездах TCP - непосредственно uucico . Если разрешение
на вход получено, удаленная систзма запускает uucico. Локальная копия
uucico, которая инициализировала соединение, назначается главной, удаленная
- подчиненной.
Затем следует фаза рукопожатия(handshake phase): главный посылает
cвое hostname и некоторые флаги. Подчиненная система проверяет, имеет ли
hostname право входить в неё, посылать и принимать файлы, и т.д.. Флаги
описывают (кроме всего прочего) максимальный приоритет буферизации
передаваемых файлов. Если возможно, счет диалога, или проверка порядкового
номера обращения происходит здесь. Благодаря этой возможностью, оба
поддерживают счет успешных соединений, которые сравниваются. Если они не
соответствуют, рукопожатиe прерывается. Это помогает защищать себя от
самозванцев.
В заключение, uucico пытаеться установить общий протокол передачи.
Этот протокол обеспечивает способ перемещения данных, проверку на
непротиворечивость, и повторную передачу в случае ошибки. Имеется
потребность в различных протоколах из-за отличающихся типов обеспечиваемых
соединений. Например, телефонные линии требуют " безопасный " протокол,
который включает в себя жестокую проверку ошибок, в то время как передача
TCP по существу надежна и может использовать более эффективный протокол,
который предшествует наиболее тщательной проверке ошибок.
После того,как рукопожатие устновлено,начинается фактическая фаза
передачи . Обе системы включают выбранный драйвер протокола. Драйверы,
возможно, выполняют свою специфическую инициализацию.
Сначала главная система посылает все файлы, поставленные в очередь
для передачи на удаленную систему, приоритет буферизации которых является
достаточно высоким. Когда передача завершена, она сообщает об этом
подчиненной системе, подчиненный может теперь отключиться или принимать
диалог. Это - изменение ролей(назначений): теперь удаленная система
становится главной, а локальная становится подчиненной. Новый хозяин теперь
посылает файлы. Когда передача завершена, обе программы обмениваются
заключительными сообщениями, и закрывают соединение.
Мы не будем вникать во все детали: пожалуйста обратитесь или к
исходным текстам или к любой хорошей книге об UUCP для этого.Есть также
действительно старинная статья, касающаяся сети, написанной David A.
Novitz, которая дает детализированное описание протокола UUCP. Taylor UUCP
FAQ также обсуждает некоторые подробности UUCP. Это всегда есть на
comp.mail.uucp.
13.2.3 Опции командной строки uucico
Этот раздел описывает наиболее важные опции командной строки для
uucico. Для полного списка, пожалуйста обратитесь к странице руководства
uucico(1).
-s системный вызов по имени системы, если нет запрета в
соответствии c ограничениями времени обращения.
-S системный вызов по имени системы безоговорочно.
-r1 запукает uucico в режиме главного. Это опция по
умолчанию,когда -s или -S заданы. Опция -r1 заставляет
uucico пробовать вызывать все системы в sys", если не
запрещено обращение и не настало ограничение
времени повторения.
-r0 запускает uucico в режиме подчинённого. Это - значение по
умолчанию,когда -s или -S не заданы. В непривилегированном
режиме, любой стандартный ввод - вывод соединяется с
последовательным портом, порт TCP используется если опция -p
задана.
YYY
-x typy, -X type Включают отладку заданного типа.Несколько типов
могут быть разделены запятой.Следующие типы допустимы:
abnormal, chat,handshake,uucp-proto, proto, port, config, spooldir,
execute,incoming, outgoing. Использование all включает все опции
Для совместимости с другими реализациями UUCP,взамен может быть
определен номер, который включает отладку для первых n предметов"из
вышеупомянутого списка.
Отладочные сообщения будут регистрироваться в файле DEBUG в
/var/spool/uucp.
Назад | Содержание | Вперед
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
